Writing to your radio

A write replaces; it does not merge

This is the one idea to carry into everything below. AesApp WebCPS does not send the radio a list of your changes — it sends the whole codeplug, and the radio clears the codeplug area as it commits, keeping only what arrived in that session. Anything not sent is not left politely alone. It is gone.

That is the radio's behaviour rather than a choice anyone made here, and it is why the write has to be complete every time. After a write the radio holds exactly the codeplug AesApp WebCPS sent. Not your old codeplug with your edits laid on top.

Two things sit outside that on purpose. Your radio's factory settings — serial number, band plan — are refused, so a codeplug write can never move your band plan out from under you. And the digital contact database is left alone unless you tick it, in which case it goes over separately once the codeplug is safely committed.

What actually reaches the radio

Your edits reach the radio, including the parts that feel peripheral — general settings, the DTMF, 2-Tone and 5-Tone tables, FM broadcast presets, roaming and the encryption key tables all travel over the cable on the shipped models.

There are exceptions, and they are per-model: the AM air-band list, for instance, is carried by the direct write on the D890UV only. Where a section cannot travel that way, your edits still round-trip into the downloaded .rdt, so the factory CPS can put them on the radio for you. The Baofeng DM-32UV and the Radtel RT-4D have no file format, so on those two there is no such fallback: an edit reaches the radio through the write or not at all. Each tab in the editor states which of the two applies to your radio — trust the tab rather than your memory of this page, because these exceptions shrink over time and the tab is the first thing to notice.

The write is built from your project and nothing else. Nothing is read from the radio first, so a setting AesApp WebCPS does not model goes out as the project holds it — from the codeplug you imported or read, or from a factory default when the project was started from scratch — and not as your radio happens to have it today. A project that began as a read of this very radio loses nothing that way. One that began somewhere else may reset a setting or two that no tab shows you.

The Baofeng DM-32UV and the Radtel RT-4D work differently. Their write carries each section whole, and the parts of a section AesApp WebCPS does not model come from what the radio holds: the project's copy of the radio — the read the project was made from, or the read its last write took — or, for a project started from scratch, the vendor CPS's new-file blank. Tick Read the radio first in the write dialog to build over a fresh read instead.

The safety floor

Writing a codeplug cannot brick your radio, and it is worth saying plainly because the fear is the main reason people put this off. A codeplug write goes to codeplug addresses and nowhere else, and it refuses the factory settings area outright. Firmware flashing is a different tool entirely, which this dialog cannot reach. The worst realistic outcome here is a codeplug you have to put back — a spoiled evening, not a dead radio.

Keeping a way back

There is no version history for what is on the radio. Once a write commits, whatever was in that memory is gone — and the write dialog does not read a backup first. It used to; the write has since been proven on every shipped model, each write is read back and compared, and the extra minute bought very little.

So if the radio holds something you could not rebuild, capture it before you open the write dialog. On the Projects page, Read from radio and then Import as project. That gives you a complete, editable copy of the radio as it stands, and writing that project back is your undo. The same dialog offers Download backup.json, a raw copy of what was read; treat that file as sensitive, because any AES or ARC4 keys in your codeplug are in it in the clear. An .rdt saved from the factory CPS does the same job.

Putting a radio back

Open the project you read from the radio and write it. That is the whole procedure, and it is the same write as any other — checked, committed and read back.

If a write stops partway

The write is committed by a single command at the very end. Everything before that is preparation; everything after it is on the radio. So where you stopped decides what you are looking at, and the dialog tells you where that was twice over: the stage label, and two progress bars. The upper bar is the whole job — a stretch each for Write codeplug, Write contacts when you ticked them, and Verify, each in its own colour, with the radio's reboots counted in. The lower bar is the step in hand, in the same colour.

One honest warning: a pulled cable does not announce itself. An unplug turns up later as a timeout that looks like any other write error, and you cannot tell a lost link from a part-written commit by looking at the radio. Treat every interrupted write the same way, and verify or rewrite before you trust it on the air.

Names the file cannot hold

Each radio shows its names in its own character set, and WebCPS stores a name the way the radio will show it. The AT-D878UVII, AT-D578UV(III) Plus and AT-D168UV take Chinese, Cyrillic and Greek (the AT-D168UV no Cyrillic: it shows it blank) but write a Latin letter plainly: type Café or München and the list says Cafe and Muenchen, because the full-width é those radios have reads as Cafe with a gap. Talk-group names are plain ASCII on every AnyTone model, which is all their .rdt holds.

The AT-D890UV shows almost any script, but its .rdt holds only Western European characters. So its names keep to those, unless you turn on Unicode names beside the project's firmware version. With it on, a name can be written in any script the radio shows, and the project goes to the radio through this write only: Build .rdt and Clone are off, and say why, until you turn it off again. Turn it off and the names the file cannot hold are spelled in the characters it can when you next build. A Read from radio of an AT-D890UV holding such names offers to keep them, which turns the setting on for the new project.

Why a write gets refused

Checks on the codeplug

When the dialog opens, the server checks the project and lists anything blocking under Fix these before writing to the radio:. The same checks run again when you prepare. The ones people actually hit:

• Add at least one zone before writing to the radio — a zoneless codeplug is rejected here, as it is by the factory CPS.
• Add at least one radio ID before writing to the radio — an empty Radio ID list is refused even for analog-only use.
• Digital channels with no Radio ID, or one the project does not define. Every D-Digital and D+A TX D channel needs one to transmit. The one exception: a write that overrides the radio identity goes out with a single Radio ID that every channel uses, so the project's own Radio IDs stop mattering — a missing list included. The dialog then shows these as a notice rather than a refusal, and the write goes ahead once the override is on.
• Add at least one channel before building a codeplug — VFO A and B do not count.
• Blank or non-numeric frequencies, an over-long scan list, out-of-range scan timers.

Warnings do not block, but do read them. An empty zone, or a channel naming a talk group that is not in the table, describes a radio that is going to surprise you later.

Checks against the radio in front of you

• Wrong model. The radio's reported model has to match the project's. Every name a model answers to is accepted, rebadges included; anything else fails closed rather than guessing.
• Band-plan mismatch. The radio accepts only channels inside its own band plan, so a mismatched write can quietly drop the out-of-plan ones. The factory CPS refuses that write, and so does the dialog: the band plan check step names both plans — Mismatch — the codeplug is … — and the confirm box stays locked. Line the two up: move the radio with Change Radio Bandplan on the Settings tab, or move the file — see RDT Band Plan Updater. If you know the mismatch is harmless, tick Skip band plan verification and the write goes ahead regardless. When one side is unknown — a project with no recorded band plan, say — there is nothing to compare, and the step says so rather than blocking you.

A write can also be refused because you have used your plan's radio writes for the day, a counter that resets at midnight UTC. About AesApp WebCPS covers what a plan allows.

Writing someone else's codeplug

A shared or public codeplug can go straight to your own radio without cloning it first. The dialog will ask for your DMR ID and callsign before it prepares anything, and the reason is on-air rather than administrative.

A codeplug carries its author's identity: their DMR ID and callsign in the Radio ID list, their callsign in the APRS settings. Write it unchanged and your radio transmits as them — every call and every beacon logged against another operator's licence. So your own identity goes in as the write is built — the Radio ID list becomes a single record, your DMR ID named with your callsign, which every channel uses, and the APRS call sign becomes yours, SSID included if you gave one — and a write that does not carry them is refused. The shared project itself is untouched. This works on every AnyTone model, for the .rdt download and the radio write alike. A shared Baofeng DM-32UV or Radtel RT-4D codeplug is written by its owner only: those two cannot stamp your identity into the write, and they have no file to download or clone.

Your own codeplug, another identity

On your own codeplug the same step is there as an option, just as it is when you build an .rdt. Tick Optional: override the radio identity for this write, give a callsign and DMR ID, and that one write goes out under them — useful for programming a second radio, or a family member's, from one project. What goes out is the same as above: one Radio ID, used by every channel, and that callsign in APRS. The project is not changed, and neither is its Master ID record. Leave the box unticked and the codeplug is written exactly as it stands.

Browser and cable

Talking to a radio needs a browser with Web Serial, a USB data cable, and the radio powered on and in PC mode before you connect. About AesApp WebCPS lists which browsers qualify, and When it goes wrong sorts the failures by kind.