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 help at all, and what anyone else will need from you.

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 firmware 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 firmware line appeared, and then the backup read, the prepare, the write or the read-back check failed.	Depends on the step. A failed backup read is a pure read and a failed prepare happens on our server, so both leave the radio untouched. Only a failure during the write itself can leave a partial codeplug.
C. ChannelBuddy 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. Some refusals come before you connect, others right after the model line.	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: 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 backup you read at step 2 is two things at once: your restore point, and the base the write is built on so the radio's un-modelled data survives. Skip it and a failed write has nothing to restore from and settings ChannelBuddy does not model may reset. On the AT-D168UV and the AT-D578UVII you cannot skip it at all — the prepare step stays disabled until a backup has been read, because on those models the backup is the write base. 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
`Web Serial isn't available in this browser.`	Kind A. The browser has no way to open a serial port, so the connect button is disabled before anything is tried.	Use a browser that can talk to a radio, over HTTPS or `http://localhost`. About lists which.
`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 holds the port.
`does not match this` … `project`, after `Connected radio`	Kind C, and the one refusal that looks like a connection failure: the model and firmware line does appear, then the radio is disconnected again. It identified itself as a different model from the one this project is for, and the memory maps differ.	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. These two are not advice: the factory CPS refuses the same two codeplugs (measured on the `AT-D890UV`, both before the transfer even starts), and the radio-ID gate applies even to an analog-only codeplug.	Add one on the `Zones` or `Radio IDs` tab.
`Backup failed:`	Kind B, but a read only. Nothing was written; the radio is untouched.	Retry. On the `AT-D168UV` and `AT-D578UVII` you must get a backup before you can go on; on the other models you can prepare without one, at the cost described above.
`Prepare failed:`	Kind B. The build ran on our server, not on the radio, so nothing was sent. The rest of the line is either a plain reason or an internal failure with a reference code.	Retry once. If it repeats, send the reference and the project link.
`Cannot write: this radio is on band plan` …	Kind C. The plan the radio is running differs from the plan the codeplug carries. The radio only accepts channels inside its own plan, so a mismatched write would silently lose channels.	Either move the radio to the codeplug's plan 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. Then reconnect.
`Cannot write: the codeplug needs memory blocks that aren’t in this radio’s backup`	Kind C. The backup you read does not cover everything this codeplug writes — a short read, or a backup from a different model or firmware.	Read a fresh full backup from this radio and prepare again.
`Write failed:` … `— the codeplug may be partial.`	Kind B, during the codeplug phase. The transfer stopped before the codeplug was committed.	Restore from your backup if you read one — the `Restore from backup` button appears for exactly that case — then prepare and write again.
`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 bytes went to the radio, were committed, and read back different. The counts and the first differing addresses are shown.	Treat the radio as suspect. Restore from backup and report it — this is the single most useful failure to 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 in the top bar. The guest allowance is counted per network, and signing in raises it. Plans and limits are on About.
`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, followed by Write Data Failed. It means the band plan in the file does not match the one the radio is running. It has nothing to do with the contents: on the AT-D578UVII the CPS refused a file the radio had produced itself. This is the same mismatch ChannelBuddy checks for before it writes, and the fix is the same — make the two plans agree, then write.

On the AT-D168UV the same string has a second cause. That radio can enter a state where its handshake identity changes and every further USB write is refused with Band Error! — including a rewrite of the codeplug that had just been written successfully. We measured the state; we could not isolate what triggers it. Only a hand power-cycle plus unlocking at the handset cleared it.

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

Get_FileData_Ver_Error is the factory CPS refusing to open a .rdt: its parser rejected the file's structure and it loads nothing. The file never reached the radio, so nothing is at risk. If a file ChannelBuddy built does this, it is a bug on our side — send us the project link rather than editing the file. For the AT-D878UVII the builder runs a simulation of that parser over every file it produces and refuses to emit one that would be rejected.

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 is deliberately not shown to you, because it contains server paths and internal module names; it is written to the log instead.

Quoting the reference is worth doing. It finds exactly one log line, and that line carries what you were doing, the full exception with its stack — including the builder's own output when the failure came from the builder — and, when a project was in scope, that project's identifier.

It carries nothing else. Not your account, not your browser, not the page you were on, not 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 the browser and leave nothing behind, so describe them yourself.
A failed write and a failed verify do reach us, and are kept. Both post their verdict back, and both are archived indefinitely for investigation, together with the backup and the exact envelope the browser wrote. For those the project link is the key, not a reference. A write that was merely unverifiable is not archived — it is not a failure, and its working files are reclaimed within a day.

The write succeeded and the radio still will not key up

Nothing failed here, so there is no message to read. Work down this list.

Power-cycle the radio. The success message asks you to. 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 ChannelBuddy and you cannot find it on the radio. Channels are assigned to zones from the channel editor's Zones field. ChannelBuddy warns you about a zone with no channels, but not about a channel in no zone, so this one is on you to check.
PTT Prohibit is On. Symptom: the radio ignores the PTT completely, on that channel only, receive is fine. This field is the CPS's receive-only flag. Fix: 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. It is one stored byte read through two vocabularies, chosen by channel type — which is why the factory CPS labels the control two ways, why ChannelBuddy 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; the AT-D878UVII, AT-D578UVII 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 on a whole band while other channels are fine — or those channels never appeared on the radio after the write. The radio enforces its transmit and receive limits from its band-plan mode, and ChannelBuddy does not check individual frequencies against it: the pre-write gate compares the codeplug's plan with the radio's plan, not each channel. 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. Fix: 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 not passed. 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. It looks exactly like a dead transmitter from the other end.

If a channel is missing from the radio entirely and the read-back verify passed, suspect the band plan before you suspect the write. See How ChannelBuddy works for 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, and without them the first reply is only going to ask for them:

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 firmware version, exactly as the write dialog printed them beside the connect button, plus the band plan shown there.
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 verify run?
Whether you read a backup before writing, and whether you still have it.

You do not need to attach the codeplug: the project link is enough, and a failed write already keeps its own artefacts server-side. Do not post encryption keys or screenshots showing them.