How to tell the four kinds of failure apart, what the common messages mean, and what to do when the write succeeded but the radio still will not key up.

Most of the time the message on screen already names the fault. This page is for when it does not — when you cannot tell whether the problem is the cable, the codeplug, the band plan, or the radio itself.

Four kinds of failure

Work out which kind you have before you change anything. It decides whether the radio needs recovering, whether retrying can possibly help, and what anyone helping you will need to see.

Kind	How you know, in one glance	What state the radio is in
A. The browser never reached the radio	No port chooser appeared, or the connect attempt failed before the radio's model and version were printed beside the connect button.	Untouched. Nothing was sent to it, and the failure leaves no record on our server.
B. Reachable, then a step failed	The model and version line appeared, and then the prepare, the write or the read-back check failed.	Depends on the step. A failed prepare happens on our server, so it leaves the radio untouched. Only a failure during the write itself can leave a partial codeplug.
C. AesApp WebCPS refused	A refusal, not a failure: a list under `Fix these before writing to the radio:`, a message beginning `Cannot write:`, a model mismatch, or a limit.	Untouched. The refusal is deliberate and the message says what to fix.
D. Everything succeeded and the radio misbehaves	The write reported done — often done and verified — and the radio still will not do what you programmed.	Written. Nothing failed. See the last section.

Kind C is the least alarming of the four: it is the app telling you something about your codeplug, and the fix is an edit. Kind A is nearly always the cable, the port, or the radio not being in PC mode. Kind B deserves a careful read, because the write failed and the read-back did not match are different events with different consequences.

The write dialog does not read a backup of your radio. If the radio holds something you could not rebuild, read it into a project before you write — Read from radio on the Projects page — and that project is what you write back if you ever need to. See Writing to your radio.

The messages you are most likely holding

Each of these is quoted from the app. Search on the fragment in code; the full message may carry your radio's model, a count, or a reference code.

Message	What it means	What to do
`This browser can’t talk to a radio over USB`	Kind A. The browser has no way to open a serial port (Safari never has one), so the connect button is disabled before anything is tried.	Open the page in desktop Chrome, Edge, Opera or Firefox 151 or newer. Signed in, you can also write with the AesApp desktop app, which the write dialog offers in a browser like this one. About AesApp WebCPS lists the browsers.
`unexpected PROGRAM response (expected 51 58 06). Is the radio in PC mode?`, usually after `Connect failed:`	Kind A. A port opened, but whatever is on the other end did not answer the way an AnyTone radio does.	Check the radio is in PC mode, that it is a data cable and not a charge-only one, and that no other CPS or terminal is holding the port.
`does not match this` … `project`, after `Connected radio`	Kind C, and the one refusal that looks like a connection failure: the model line does appear, then the radio is disconnected again. It identified itself as a different model from the one this project is for.	Open the project for that radio, or convert this one. The radio was not written.
`Fix these before writing to the radio:` with a list under it	Kind C. A pre-flight check of the codeplug ran before the port was even opened.	Fix every listed item in the editor and reopen the write dialog.
`Add at least one zone before writing to the radio` / `Add at least one radio ID before writing to the radio`	Kind C. Neither is advice: the factory CPS refuses the same two codeplugs, and the radio-ID requirement applies even to an analog-only codeplug.	Add one on the `Zones` or `Radio IDs` tab.
`Prepare failed:`	Kind B. The work ran on our server, not on the radio, so nothing was sent. The rest of the line is either a plain reason or a reference code.	Retry once. If it repeats, send the reference and the project link.
`Mismatch — the codeplug is` … / `Write data is ready, but the band plan check failed`	Kind C. The plan the radio is running differs from the plan the codeplug carries, and the radio accepts only channels inside its own plan, so a write can lose the out-of-plan ones. The factory CPS refuses the same write.	Align the two, either end. Move the radio with `Change Radio Bandplan` on the `Settings` tab; or change the codeplug: pick the `Band Plan`, then click `Save Codeplug Bandplan` — choosing alone changes nothing. RDT Band Plan Updater covers which end to move, and does the same to a file with no project. Writing anyway is allowed, and sometimes right: tick `Skip band plan verification`.
`Write failed:` … `— the codeplug may be partial.`	Kind B, during the codeplug phase. The transfer stopped before the codeplug was committed.	Connect the radio again, prepare and write again — and do it before you use the radio, which may be holding a part-written codeplug until you do.
`Codeplug written OK, but the digital-contact write failed:`	Kind B, but only the second phase. The codeplug itself is committed and intact; the contact database is incomplete.	Run the write again to redo the contacts. The codeplug does not need recovering.
`Write committed but verify FAILED:`	Kind B. The codeplug went to the radio, was committed, and read back different.	Treat the radio as suspect. Write it again, and report it either way — this is the single most useful failure you can send us.
`Write committed, but could not verify automatically (the radio may have reinitialised).`	Not a failure. The write was committed; the re-read afterwards could not run.	Power-cycle the radio and check it. Read it back if you want proof.
`Daily limit reached:` / `Daily guest limit reached:` / `Monthly limit reached:` / `tier allows` …	Kind C. An allowance, not a fault. The message names the limit and when it resets.	Signed in, your remaining allowance is under `Usage` in the account menu. The guest allowance is counted per network, and signing in raises it. Plans are on About AesApp WebCPS.
`Your session has expired, so this table could not be refreshed.`	You are signed out. Edits already saved are safe; new ones will not save.	Sign in again from the prompt. Unsaved rows in an open editor are kept if you cancel.

Two messages that are not ours

Band Error! comes from the factory Windows CPS, usually followed by Write Data Failed. It means the band plan in the file does not match the one the radio is running, and it says nothing at all about the contents of your file — a perfectly good codeplug gets it too. This is the same mismatch AesApp WebCPS checks for before it writes, and the fix is the same: make the two plans agree, then write.

On the AT-D168UV that same message has a second cause, and it is a confusing one. The radio can get into a state where every further USB write is refused with Band Error! — including rewriting a codeplug that had just been written successfully a minute earlier. A hand power-cycle plus unlocking at the handset clears it.

Where a power-on password is edited on the AT-D168UV, AesApp WebCPS warns you: Writing a set power-on password locks this radio against ALL further USB writes until you power-cycle it and unlock at the handset. So if a 168 suddenly refuses every write, power-cycle and unlock it before you go hunting for a dead cable.

Get_FileData_Ver_Error is the factory CPS refusing to open a .rdt at all — it loads nothing, so the file never reached the radio and nothing is at risk. If a file AesApp WebCPS built does this, it is a bug on our side: send us the project link rather than trying to repair the file.

What a reference code is, and is not

Some failures end with Please try again — if it keeps happening, quote reference and eight hex characters. That happens when something inside the app failed unexpectedly — a codeplug build, a write preparation, an import, a clone, a conversion, a CSV export. The detail behind it is written to our log rather than shown to you.

Quoting the reference is worth doing: it finds exactly one log line, and that line carries what you were doing and what went wrong. What it does not carry is your account, your browser, the page you were on or what you clicked. So a reference on its own says a build failed and not much more — send it with the context below.

Every failure gets its own code. If you retried three times you are holding three, and they are three separate occurrences. Send them all rather than picking one.
No code does not mean no record. Messages you can act on — a validation list, an empty zone list, a limit — are shown in full and carry no code on purpose. They are answers, not faults.
Connect failures and Web Serial problems never reach us. They happen entirely in your browser and leave nothing behind, so describe those yourself.
A failed write and a failed verify do reach us, and are kept so they can be investigated. For those the project link is the key, not a reference. A write that was merely unverifiable is not kept — it is not a failure.

The write succeeded and the radio still will not key up

Nothing failed here, so there is no message to read and nothing to search for. This is the frustrating one, and it is nearly always in the list below. Work down it in order.

Power-cycle the radio. The success message asks you to, and it is skipped more often than anything else here. The write session left the radio in PC mode; a power cycle returns it to normal operation.
The channel is in no zone. Symptom: the channel exists in AesApp WebCPS and you cannot find it on the radio. Channels are put into zones from the channel editor's Zones field. AesApp WebCPS warns you about a zone with no channels, but not about a channel in no zone, so this one is yours to check.
PTT Prohibit is On. Symptom: the radio ignores the PTT completely on that channel, while receive is fine. This is the CPS's receive-only flag. Set it Off in the channel editor.
Busy Lock/TX Permit is holding transmit off. Symptom: PTT does nothing while the channel is busy, or while the incoming colour code does not match. The factory CPS labels this control two different ways, which is why AesApp WebCPS shows both names in one label and why the options change when you change Type. On an analog channel the loosest setting is Off; on a digital channel it is Always, and the AT-D878UVII, AT-D578UV(III) Plus and AT-D168UV do not offer Off there at all.
The transmit frequency is outside the band plan the radio is running. Symptom: transmit is refused across a whole band while other channels are fine — or those channels never appeared after the write. The radio enforces its own limits, and AesApp WebCPS compares the codeplug's plan with the radio's plan, not each individual frequency. Fix: on the Settings tab pick a Band Plan that covers your frequencies and click Save Codeplug Bandplan, move the radio onto it with Change Radio Bandplan, then write again. The write dialog prints the radio's current plan beside the connect button.
Colour code, time slot or contact is wrong for the repeater. Symptom: you key up and the repeater does not open, or it opens and nobody hears you on the talkgroup you expected. Set Color Code, Timeslot and DMR Contact to the repeater's published values. A contact whose name is not in the Talk Groups table is not written — the channel keeps whatever the template had, and the app warns you about that before the build.
You transmit fine but hear nothing. DMR RX Group List is what a channel listens to; without the right receive group the traffic is never passed to you. Separately, Talk Around set On transmits on the receive frequency, so a repeater never hears you.
Encryption is on. AES Digital Encryption or ARC4 Encryption Code set on a channel means you transmit and nobody without the same key decodes it. From the other end it looks exactly like a dead transmitter.

If a channel is missing from the radio entirely and the read-back check passed, suspect the band plan before you suspect the write. How AesApp WebCPS works explains why zones and lists behave the way they do.

Asking for help

Use the Help link in the top bar. It opens the AesApp group, where questions and bug reports go.

Six facts make a report answerable. Without them the first reply is only going to ask for them, and you will have lost a day:

The link to the project. The URL identifies your codeplug on the server, which is what everything else is looked up from.
The radio's model and the version string beside it, exactly as the write dialog printed them, plus the band plan shown there. Copy that line rather than retyping it — and note that the firmware version worth quoting is the one the radio's own menu shows, which is not the same thing.
The message, copied. The whole line, as text. A description of a message cannot be searched for; the message itself can.
Any reference codes — all of them if you retried.
Which of the four kinds it was. Did the model line ever appear? Did the write start? Did the check run?
Whether you have a copy of what the radio held before — a project read from it, or an .rdt.

You do not need to attach the codeplug — the project link is enough. Do not post encryption keys, or screenshots showing them.

When it goes wrong