Radios
Figures ▾
Tables ▾

Programming Software Landscape (Radios) · Volume 1

Programming Software Landscape (Radios)

AnyTone CPS, wfView, CHIRP, and codeplug backup discipline

Figure 1 — Programming via software — laptops and code on screen during a coding session, evoking programming radios with CPS/CHIRP over a cable (representative). Photo: "Spring 2012 Student Hackathon Coding"…
Figure 1 — Programming via software — laptops and code on screen during a coding session, evoking programming radios with CPS/CHIRP over a cable (representative). Photo: "Spring 2012 Student Hackathon Coding" by hackNY, CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0/), via Openverse.

1.1 About this volume

The programming-software landscape for the bench’s radios is fragmented by design, by accident, and by vendor incentive. Every Uniden scanner family has its own CPS — and Uniden ships THREE different CPS tools to cover the lineup, none of which fully overlap with the other two. Every DMR vendor (AnyTone, Connect Systems, TYT, Anytone-clone variants) ships their own Windows-only CPS, and the codeplug formats are mutually incompatible. CHIRP, the open-source cross-vendor unifier, gets close to “one tool to program them all” on the budget HT side — but stops dead at DMR, at Uniden scanners, and at Icom HF. The full picture is six discrete software ecosystems for the twenty-one programmable radios on the bench, plus the browser-based dashboards on the two hotspots.

This volume catalogs the six ecosystems — what each does, what radios it touches, what platform it runs on, what version is archived in programs/, and which cross-link in the per-radio volumes connects back here. Cross-links into this volume come from every per-radio volume’s §4 (Programming workflow); cross-links out point back to each radio’s volume for the radio-specific operating procedures, codeplug structure, and field workflows.

The persistent friction in this landscape is Windows-only-ness. Five of the six tools (ProScan, Sentinel, FreeScan, AnyTone CPS, all the vendor-specific Uniden tooling) are Windows-only — by deliberate vendor choice, not technical necessity, because the install base of Windows in the licensed-radio market dominates and there’s no commercial pressure to port. Only CHIRP and wfView are cross-platform — both of those are free open-source community projects, which is not a coincidence. Practical posture: the shack-room T480 dual-boot includes Windows 11 Pro specifically to host the vendor CPS tools; cross-link to Parrot OS Vol 3 (Dual-boot architecture) for the dual-boot rationale. The Parrot Linux side runs CHIRP and wfView (or stays out of the way and lets the Windows partition do the CPS work).

The naming + ownership matters: ProScan is a paid third-party product (Bill Davis, W6BD; not Uniden); Sentinel is Uniden’s free first-party tool (bundled with the radio); FreeScan is a free third-party community tool (no affiliation with Uniden) that supports the older Uniden lineup that Sentinel never covered. The three are NOT successors to each other — they’re parallel offerings for different (overlapping) parts of the Uniden product line, each with different strengths and different blind spots. Picking which CPS to use for a given Uniden scanner is the first programming decision and it’s not always obvious. §2-4 disambiguate the three.

The cross-cutting discipline in §8 — versioning and backup hygiene — applies to every CPS in the landscape and is the single most important habit. A bricked codeplug after a firmware update is the single most common failure mode in the entire bench; the cure is always “restore the last known good codeplug from programs/” and that cure only works if the discipline has been kept.

The full landscape cross-link grid:

Table 1 — The full landscape cross-link grid

SoftwareOSCostVendorRadios covered
ProScanWindows~$50 lifetimeBill Davis (W6BD) — third-party paidSDS100, SDS200, BCD536HP, BCD436HP, BCD396XT, BCD325P2, others (broad Uniden coverage)
SentinelWindowsFreeUniden — first-partyBCD436HP, BCD536HP, SDS100, SDS200, Homepatrol family
FreeScanWindows (Wine works)FreeARC/Butel — third-partyBC246T, BC346XT, BCD396XT, BC125AT, BC75XLT, others (older Uniden)
AnyTone CPSWindowsFreeAnyTone — first-partyAT-D878UVII PLUS (and family)
wfViewWin/Mac/LinuxFree (GPL)Open-source communityIcom HF transceivers via CI-V — IC-7300, IC-9700, IC-705, IC-7610, others
CHIRPWin/Mac/LinuxFree (GPL)Open-source communityHundreds of models — Baofeng UV-5R/F8HP/UV-B5, Yaesu VX-8/FT-60, TYT, Wouxun, dozens more (NOT AnyTone DMR, NOT Uniden scanners)

Cross-links to the synthesis siblings: Vol 1 (Overview) §7 has the preview of this table; Vol 2 (DMR Network) covers the talkgroup-and-contact data that AnyTone CPS imports (RadioID CSVs, BrandMeister rosters); Vol 4 (Frequency Planning) covers the per-band frequency assignments that get poured into codeplugs across CHIRP and ProScan.

1.2 AnyTone CPS (D878UVII)

AnyTone CPS is the vendor’s first-party Windows programming utility for the AT-D878UVII PLUS (and the broader D868/D878 family). It’s free, Windows-only, and required for any meaningful programming on the radio — DMR codeplug structure on the D878 is genuinely too complex for a generic tool like CHIRP to handle, which is why no cross-vendor option exists.

1.2.1 The codeplug schema — why DMR is hard

A DMR codeplug isn’t just a list of frequencies. It’s a layered set of data structures with cross-references:

  • Channels — the lowest layer. Each channel has a frequency, mode (analog/DMR), CTCSS/DCS (analog) or color code + time slot (DMR), TX power, and a reference into a Contact OR a Receive Group.
  • Contacts — DMR talkgroups, by name and ID. Tens of thousands of these exist (every BrandMeister talkgroup, every TGIF talkgroup, every local club’s private group). A typical codeplug has 50-300 of them loaded.
  • Receive Groups — sets of contacts (e.g., “all Michigan talkgroups”, “all worldwide-English”) that listen on a single channel; for monitoring multiple talkgroups in time-slotted DMR.
  • Scan Lists — sets of channels for the radio to scan. Each scan list has priority channels, dwell time, look-back behavior.
  • Zones — sets of channels for one-touch selection on the front panel. A “Home Repeaters” zone, a “Travel — Detroit” zone, a “VHF Simplex” zone.
  • Roaming Zones — sets of channels for automatic site selection in multi-site DMR systems; the radio listens to all channels in a roaming zone for the strongest control signal and automatically registers there.
  • DMR Contacts Database (DCDB) — the per-user DMR ID directory imported from https://radioid.net. When a DMR transmission decodes a user ID, the radio looks it up in the DCDB and displays “John KD8XYZ” instead of “2347001”. This database has ~250,000+ entries as of mid-2026 and consumes a chunk of the radio’s flash.

All of these interlink. A channel references a contact; a scan list references channels; a zone references channels; the DCDB is independent but loaded into the same codeplug. Edit any one and the cross-references must remain valid. The AnyTone CPS UI presents these as separate spreadsheet-like grids with click-through navigation between them.

CHIRP cannot handle this. CHIRP’s data model is fundamentally “list of channels with frequency + CTCSS”; the DMR scaffold doesn’t fit. This is why every DMR vendor maintains their own CPS and why CHIRP-for-DMR has never materialized despite occasional community attempts.

1.2.2 The proprietary programming cable

The D878UVII uses a USB-C-to-K2-pin programming cable that’s specific to AnyTone (and the broader Hytera/QYT K2-pin family). The “K2” refers to the dual-pin connector on the radio side — a proprietary AnyTone connector that looks vaguely like a Kenwood K-plug but is electrically different.

Use the AnyTone-supplied or AnyTone-clone cable. The CH340/CP2102 serial chip in the cable is identified by the CPS during connect; some third-party “compatible” cables don’t enumerate correctly and the CPS won’t see the radio. The Bridgecom-sold cable (~$25-30) is the safe option; the eBay $8 clones are 50/50 at best.

USB driver discipline: the cable presents as a USB-to-serial bridge (typically Silicon Labs CP2102 or WCH CH340G). Windows finds drivers automatically in current versions; in some Win 11 cases the CP2102 driver needs to be installed manually from Silicon Labs’s site. The COM port number assigned at first connect should be remembered — the AnyTone CPS auto-detects but if multiple USB-serial devices are plugged in, the auto-detect can pick the wrong one.

1.2.3 Codeplug import and export — the data dance

The data that goes INTO a D878 codeplug rarely originates in the AnyTone CPS UI. The realistic workflow:

  1. Pull a DMR ID CSV from https://radioid.net. This is the 250k-entry per-user directory.
  2. Pull a BrandMeister talkgroup list (CSV) from a community-curated source — N1RCN’s lists, BrandMeister’s own exports, or a local-club roster. These become the Contacts list.
  3. Pull repeater/hotspot frequencies from RepeaterBook (https://repeaterbook.com) for the geographic area of interest. These become the analog/DMR channel entries.
  4. Build the Zones by hand in the CPS — group channels into the front-panel zones that match your operating posture.
  5. Build the Scan Lists by hand — pick channels per scan list, set priority channels, set dwell times.
  6. Build the Roaming Zones if using multi-site DMR — set the channels in each roaming zone, set the threshold for auto-switch.
  7. Write to the radio.

Steps 1-3 are CSV imports through the CPS’s Import functions; step 4-6 are interactive UI work. A first codeplug from scratch is ~4-6 hours of work; updates to an established codeplug are minutes.

1.2.4 Third-party alternatives

The AnyTone CPS UI has rough edges (Windows-only, Chinese-translated, occasional crashes on large codeplugs). Several third-party tools improve the experience:

  • CPSProgrammer — open-source codeplug editor that reads/writes AnyTone codeplug files, with a cleaner UI and scriptable batch operations. Cross-platform via Qt.
  • AnyTone-Sync — Python tool that pulls fresh RadioID and BrandMeister data on a schedule and rebuilds the codeplug; useful for keeping the DCDB current without manual re-imports.
  • DCS-CodePlugMaster — Windows tool that focuses on bulk talkgroup management and zone organization; integrates with multiple DMR vendors’ codeplug formats.

None of these REPLACE the AnyTone CPS for the final write-to-radio step — only AnyTone CPS has the official write protocol implementation that won’t brick the radio. They generate codeplug files that AnyTone CPS then loads and writes. The workflow becomes: edit in the third-party tool, save codeplug file, open in AnyTone CPS, write to radio.

1.3 wfView (Icom radio control)

wfView is the free, open-source, cross-platform PC client for Icom HF/VHF/UHF transceivers — IC-7300, IC-9700, IC-705, IC-7610, and the IC-7100. It’s the modern open-source alternative to Icom’s own RS-BA1 commercial software, runs on Windows, Mac, and Linux, and is licensed GPL. It’s archived in programs/wfview/ despite the fact that no Icom radios are currently owned — the archive is forward-looking for the eventual addition of an IC-7300 or IC-705 to the lineup.

1.3.1 What it is

wfView is a CAT-control + spectrum-scope + audio-routing front end for Icom radios. It connects to an Icom radio over:

  • USB (Icom radios with built-in USB sound + CAT — IC-7300, IC-705, IC-9700) — single cable carries both CAT control and audio.
  • CI-V serial (Icom’s CI-V bus, the historical Icom remote-control protocol) — for older Icom radios with a 3.5mm CI-V jack plus a separate audio path.
  • TCP/UDP network (using wfView’s own server running on a Pi/PC connected to the radio) — for remote operation over LAN or internet.

Once connected, wfView presents the radio’s full operator interface on screen: VFO knob (mouse scroll), band-stacking memory, all the menus accessible via clickable controls, the radio’s panadapter display rendered as a configurable spectrum + waterfall (the IC-7300/IC-9700/IC-705/IC-7610 all have built-in spectrum scopes that wfView reads at higher resolution than the radio’s own screen), audio I/O routed to/from the PC’s sound system for digital-mode integration (FT8, WSJT-X, JS8, FLDIGI).

1.3.2 Why it’s archived “no current radio uses this”

The bench has the Xiegu X6100 as the current HF radio. wfView does NOT support the X6100 — Xiegu has its own CAT protocol that’s Icom-CI-V-compatible-ish but with quirks that wfView’s Icom-specific implementation doesn’t handle cleanly. (The X6100’s CAT control is best handled via Xiegu’s own utility or via FLrig configured for X6100; cross-link to Vol 9 (Xiegu X6100) §4.)

The Icom IC-705 is on the long-term acquisition wishlist — same QRP HF/VHF/UHF posture as the X6100 but with Icom’s more refined CAT control, better spectrum scope, and the entire Icom-software-ecosystem maturity. If/when the IC-705 lands on the bench, wfView is the front-end of choice and the archived install will save a download. The cross-link is Vol 1 §11 (Aspirational/Future radios) ↗.

The IC-7300 is the other long-term aspirational acquisition — the desktop HF that would complement the X6100 portable. Same wfView story: archived now, deployed if/when the radio arrives.

1.3.3 Why archive software you don’t have a radio for

The discipline: archive the version of the software that was the most-recommended-stable release at the time of decision, not whatever’s current when you eventually buy the radio. wfView’s development moves fast — major releases yearly, with occasional protocol-breaking changes when Icom updates a radio’s firmware. The version you’d install today (mid-2026: wfView 2.0x — TBD verify exact version against the wfView release page) is known-good with current IC-7300/IC-705/IC-9700 firmware. The version that exists when the IC-705 eventually arrives in 2027 or 2028 might or might not be compatible with the radio’s then-current firmware.

Having the archived “known-good” installer means a clean rollback path if the future wfView version has issues. Same discipline as the ProScan v24.0/v24.4 dual archive (§2.5) and as the firmware-version archiving discipline in general — keep one or two versions back from current.

1.3.4 Cross-platform notes

wfView builds natively on Linux (Qt-based), and the Linux build is in some respects more polished than the Windows build (smoother audio routing via PipeWire/PulseAudio; native ALSA support for radios that present USB-audio directly). On Mac (Intel and Apple Silicon), wfView runs cleanly via the official .dmg.

For the eventual workflow: the Parrot Linux partition can host wfView for Icom radio control, leaving the Windows partition free for the Uniden+AnyTone CPS tools. The cross-link is to Parrot OS Vol 11 §6 (Integration with owned hardware) for the udev-rules pattern that gives non-root user access to USB-CAT devices.

1.3.5 Resources

1.4 CHIRP (universal — Baofeng, Yaesu, others)

CHIRP is the universal cross-vendor open-source CPS — the closest the radio world has to a “one tool to program them all” for the budget HT segment. It supports hundreds of radio models from Baofeng, Yaesu, Kenwood, Wouxun, BTECH, Anytone (the analog-only Anytones, not the DMR D868/D878), Quansheng, TYT, and dozens more. Free, cross-platform (Python/wxWidgets — runs on Windows, Mac, and Linux), GPL-licensed, maintained by the CHIRP project at https://chirpmyradio.com.

For the bench’s purposes, CHIRP is the CPS for the Yaesu VX-8DR, the Baofeng F8HP, and the Baofeng UV-B5. Three radios, one tool, one shared codeplug paradigm — this is the productivity multiplier CHIRP delivers.

1.4.1 The CHIRP model

CHIRP’s central abstraction is the memory channel. Each memory has a frequency, an alpha tag (display name), a tone (CTCSS encode/decode, DCS), an offset (simplex/duplex), a TX power, a width (narrow/wide FM), and a few minor attributes (skip in scan, mode if non-FM). The same memory structure represents a channel on a Baofeng, a Yaesu, or a Wouxun — CHIRP normalizes the differences.

This means: you can build a codeplug ONCE in CHIRP and write it to any supported radio. Build a “local repeaters” channel set, save to a .img or .csv file, write to the Baofeng F8HP, write to the Yaesu VX-8DR, write to a friend’s UV-5R. Same channels, same alpha tags, three different radios, ten minutes of work for the second and third radios after the first.

The per-radio differences (some radios have more memories, some have different attribute support — FM broadcast band, VFO B independence, scan groups, banks) are handled by per-radio driver modules. The same channel data writes to each radio with appropriate truncation/expansion of optional fields.

1.4.2 The driver-per-radio architecture

CHIRP supports a radio when someone in the community has written a driver for it. Driver maturity varies wildly:

  • Mature, gold-standard drivers: Baofeng UV-5R, F8HP, BF-F8HP, BF-888, GT-3, GT-5R; Wouxun KG-UVD1P; Yaesu VX-8DR, FT-60R, FT-7800/8800/8900. These have years of community refinement, reliably read/write codeplugs, handle the radio’s edge cases.
  • Solid but slightly newer: Baofeng UV-B5, UV-B6; BTECH UV-25X4, UV-50X3; many Quansheng UV-K5 variants (relevant cross-link to Hack Tools/Quansheng UV-K5).
  • Beta/experimental: New radios that landed in CHIRP within the last 6-12 months; usually work but may have rough edges (specific tone modes missing, attribute fields untested).
  • Not supported: Anything DMR (AnyTone D878, all the TYT MD-series, Connect Systems CS800), Uniden scanners (any model), Icom HF (any model — that’s wfView’s territory), the M17 digital radios.

For the bench: the Yaesu VX-8DR has a fully mature driver (CHIRP has had VX-8 support for over a decade); the Baofeng F8HP uses the same driver family as the UV-5R (the F8HP is electrically a UV-5R with an 8W PA), and the UV-5R driver is the most-used CHIRP driver in existence; the UV-B5 has a separate driver that’s been stable for years.

1.4.3 The build cadence

CHIRP releases on a rolling basis — there’s a “stable” release roughly twice a year (e.g., CHIRP next-20240725, CHIRP-next-20251215; TBD verify current release date) and a “next” build that updates weekly with new drivers and bug fixes. The recommended practice is the next build for any new install — it has the most current drivers and is generally as stable as the stable release.

Install via:

  • Windows: download the installer from chirpmyradio.com and run; .NET prerequisites bundled.
  • Mac: download the .dmg.
  • Linux: package available via pip (pip install chirp), via Flatpak, or distro packages.

The Parrot OS partition runs CHIRP cleanly via Flatpak (or pip-installed into a venv); the cross-link is Parrot OS Vol 11 §6 for the udev rules that give the user access to the USB programming cable without root.

1.4.4 The programming cable problem

Each radio has its own programming cable. CHIRP doesn’t ship cables; you supply them. The relevant cables for the bench:

  • Baofeng UV-5R/F8HP — Kenwood K1-style 2-pin (2.5mm + 3.5mm coaxial plugs). Several variants: original Baofeng “BF-9700” cable ($5, sometimes works, often doesn’t due to fake FTDI chips bricking themselves under Windows driver updates); the Valley Enterprises FTDI Genuine cable ($25, the safe choice); the BTECH Baofeng cable (FTDI-based, $20-25).
  • Yaesu VX-8DR — CT-167 cable (manufacturer Yaesu) or aftermarket equivalents. The CT-167 is overpriced ($60+); aftermarket versions are ~$20.
  • Baofeng UV-B5 — same K1-style 2-pin as the UV-5R; same cable works.

The single most painful CHIRP failure mode is fake FTDI cables that work until Windows updates the FTDI driver, then the cable bricks itself. The legitimate FTDI driver since ~2014 has shipped with a “kill counterfeit” feature that detects fake FTDI silicon and reprograms the USB-VID to 0x0000, rendering the cable unusable. The Valley Enterprises Genuine FTDI cable is the safe purchase; the no-brand $5 cables are a coin flip.

On Linux, the FTDI kill behavior doesn’t happen — the driver is open-source and doesn’t include the counterfeit-detection. A Baofeng programming cable that doesn’t work on Windows often works fine on Linux; this is a use case for the Parrot partition.

1.4.5 The limitations

What CHIRP can’t do:

  • AnyTone D878 (or any DMR radio). The DMR codeplug structure (§5.1) is too complex; no DMR driver has been written and the project has effectively decided not to pursue it. Use the AnyTone CPS.
  • Uniden scanners. No support, by design — Uniden’s DMA architecture is unrelated to CHIRP’s memory model. Use Sentinel, ProScan, or FreeScan.
  • Icom HF transceivers. Use wfView.
  • Most modern digital-mode radios (Yaesu System Fusion C4FM HTs like the FT-1DR/FT-2DR/FT-3DR/FT-5DR — those have D-STAR-and-Fusion codeplug structures that CHIRP partially supports but not as cleanly as Yaesu’s RT Systems software).

1.4.6 RT Systems as a paid alternative

For Yaesu radios specifically, RT Systems sells a per-radio paid CPS (~$25-40 per radio) that some operators prefer over CHIRP — cleaner Yaesu-specific UI, support for some attributes that CHIRP doesn’t expose (DSP filter presets, GPS waypoint memory on the VX-8 series). RT Systems is Windows-only.

The trade-off: CHIRP is free and covers many radios with one install; RT Systems costs per-radio but has more polished per-radio UX. For most operators, CHIRP is sufficient. For the operator who programs the VX-8DR weekly and uses every Yaesu-specific feature, RT Systems might be worth it. The posture here: CHIRP is enough for the current bench; no RT Systems license held.

1.5 Codeplug versioning and backup discipline

This is the cross-cutting practical guidance that applies to every CPS in the landscape. It’s the single most important habit in the entire programming workflow — the discipline that distinguishes “I lost three hours of work because the firmware update bricked the codeplug” from “the firmware update was a non-event; I restored the previous codeplug and was on the air in 60 seconds.”

1.5.1 Always back up BEFORE you edit

The rule with no exceptions: before opening a codeplug for editing, save a copy of the current state with today’s date in the filename. Then edit.

This costs ~10 seconds and zero cognitive load. Skipping it costs hours-to-days when an edit goes wrong and you discover that the radio’s codeplug had a state you can’t reconstruct from memory.

The failure modes that demand this:

  • CPS crashes mid-edit, corrupting the file in memory. Saving overwrites the previous file with corruption.
  • You mis-edit something subtle (wrong tone on one channel, wrong offset, deleted a zone) and don’t notice until days later. Without a backup from before the edit, you can’t recover.
  • The radio firmware updates and invalidates the codeplug schema. The post-update CPS reads the codeplug, “migrates” it (sometimes losing data), and writes it back. The original is gone.
  • You hand the radio to someone else to program a feature, they accidentally erase a zone, you discover it next week. Without a backup, you reconstruct from scratch.

The mechanics are trivial:

  • ProScan: File → Save Codeplug As → date-stamped name. Or just copy the active Profile.dat from the radio’s microSD to the project’s programs/ folder before connecting in ProScan.
  • Sentinel: same — copy Profile.dat directly from the radio’s microSD when connected; that’s the backup.
  • FreeScan: File → Save As with a new date-stamped name.
  • AnyTone CPS: File → Save → name the file with the date.
  • CHIRP: File → Save As → name the file with the date. CHIRP saves to .img (binary, exact radio image) or .csv (human-readable, can be re-imported); save both formats for important codeplugs.
  • wfView: codeplug-style data isn’t typically saved here (wfView is more of a control surface than a CPS), but VFO memory snapshots can be exported and should follow the same naming convention.

1.5.2 The filename convention

The project-wide convention for codeplug backups:

{slug}-codeplug-YYYY-MM-DD-{descriptor}.{ext}

Where:

  • {slug} is the radio’s project slug (sds200, d878uvii, vx8dr, bcd536hp, etc. — match the slug used in MY_GEAR/inventory.yaml).
  • YYYY-MM-DD is the ISO date the backup was taken.
  • {descriptor} is a short hint about WHY this backup exists (pre-firmware-update, pre-rr-import, pre-zone-rebuild, last-known-good, field-day-prep, etc.).
  • {ext} is the CPS’s native format (dat for Uniden DMA, rdt for AnyTone, img or csv for CHIRP).

Examples:

  • sds200-codeplug-2026-05-24-pre-firmware-update.dat
  • d878uvii-codeplug-2026-05-20-after-bm-tg-import.rdt
  • vx8dr-codeplug-2026-05-15-last-known-good.img
  • f8hp-codeplug-2026-04-30-field-day-prep.csv

The descriptor matters more than you’d expect — six months later when you’re looking through the programs/ folder for “the codeplug from before I rebuilt the zones,” the descriptor tells you which one to restore.

1.5.3 Test new codeplugs in a sandbox zone before promoting

When making a substantive codeplug change (new zone, new scan list, mass talkgroup import):

  1. Build the new content in a sandbox zone named something like _SANDBOX or _TEST (the underscore prefix sorts it to the top or bottom of the zone list on the radio).
  2. Write to the radio, navigate to the sandbox zone, test it — keyup, scan, verify the talkgroups decode, verify the alpha tags display correctly.
  3. If it works, promote to a permanent zone with its real name and remove the sandbox.
  4. If it doesn’t work, edit further or restore the previous codeplug.

This pattern matters most for DMR codeplugs where a misbuilt zone can be subtle (wrong color code, wrong time slot, wrong contact reference) and only manifests when you actually key up. Testing in a sandbox zone first means a failed test costs you 15 minutes; testing in a permanent zone that you’ve already merged into your main rotation costs you an hour-plus to unwind.

1.5.4 Maintain a “last known good” alongside the working copy

Every radio should have one specific backup file labeled last-known-good — the most recent codeplug that’s been confirmed working in actual field use (not just confirmed-writes-cleanly-to-the-radio, but confirmed-keyup-and-traffic-and-scan-and-alpha-tags-all-correct).

When something breaks, restore last-known-good. When last-known-good is verified after a substantial codeplug update, rename the previous last-known-good to last-known-good-PREVIOUS-{date} (keep two generations back) and promote the new one.

This is a single labeled file per radio in the programs/{slug}/ folder. It’s the recovery anchor.

1.5.5 Re-test after firmware updates

Every CPS in the landscape (except wfView, which doesn’t do firmware) ships firmware updates periodically. Always assume a firmware update can invalidate an older codeplug schema.

The discipline around firmware updates:

  1. Backup the codeplug first — {slug}-codeplug-YYYY-MM-DD-pre-firmware-update.{ext}.
  2. Note the current firmware version before updating, in case rollback is needed.
  3. Run the firmware update through Sentinel (Uniden) or AnyTone CPS or the radio’s native firmware-update method.
  4. Re-test the codeplug after the update — open in the CPS, verify all zones still exist, verify a representative channel keys up correctly, verify scan still scans.
  5. If something’s broken, restore the pre-firmware codeplug and consider whether to roll back the firmware.
  6. If everything works, promote the restored codeplug to the new last-known-good.

The single highest-risk operation in the entire programming workflow is a firmware update on a radio with a complex codeplug (the AnyTone D878 specifically). The pre-firmware backup is the only insurance.

1.5.6 Store backups in programs/{slug}/

The project convention: each radio’s CPS files and codeplug backups live in programs/{slug}/. The slug matches the radio’s slug in MY_GEAR/inventory.yaml and matches the per-radio volume’s slug:

programs/
├── proscan/
│   ├── ProScan-24.0-installer.exe
│   ├── ProScan-24.4-installer.exe
│   └── license.txt
├── uniden-misc/
│   └── Sentinel.zip
├── sds100/
│   ├── sds100-codeplug-2026-05-24-pre-firmware-update.dat
│   ├── sds100-codeplug-2026-05-15-last-known-good.dat
│   └── sds100-codeplug-2026-04-12-after-county-update.dat
├── sds200/
│   └── (same pattern)
├── d878uvii/
│   ├── d878uvii-codeplug-2026-05-20-after-bm-import.rdt
│   ├── d878uvii-codeplug-2026-05-15-last-known-good.rdt
│   └── radioid-database-2026-05-20.csv
├── vx8dr/
│   └── (same pattern)
├── f8hp/
│   └── (same pattern)
└── (etc.)

This puts every radio’s programming history in one predictable place, surfaced under programs/, alphabetized for navigability, and discoverable by any contributor (or the operator six months later) without explanation.

The CPS installers themselves (ProScan, FreeScan, AnyTone CPS, wfView, CHIRP) also live in programs/ — under their own slug folders (proscan/, freescan/, anytone-cps/, wfview/, chirp/). When a new CPS version is released, archive it alongside the previous version with the version number in the filename, the same way ProScan 24.0 and 24.4 are kept side-by-side.

1.5.7 Versioning across multiple radios

When the same codeplug data (a list of frequencies, a set of CTCSS tones) feeds multiple radios via CHIRP, the source-of-truth is the CHIRP .csv export — the human-readable spreadsheet version of the channel list. Edit the CSV (in Excel, LibreOffice, or any spreadsheet), re-import into CHIRP, write to each radio in turn.

The CSV becomes the canonical “channels I care about” file, with each radio’s .img file being a derived artifact. The discipline: edit the CSV, not the .img. The CSV is human-readable, diffable, mergeable; the .img is binary and opaque.

For the bench, the CSV that feeds the Baofeng F8HP, the UV-B5, and the VX-8DR (for the channels each one supports) is the load-bearing artifact. The per-radio .img files are recreated from the CSV via CHIRP whenever the channel set changes.

1.5.8 The “I bricked my radio” recovery path

The worst case: a CPS write went wrong, the radio is unresponsive, or the firmware update failed mid-flash.

  • Uniden DMA scanners (SDS100/SDS200/BCD536HP): there’s a hardware recovery mode (the radio’s bootloader will accept a firmware re-write even if the application firmware is corrupt). Cross-link to the per-radio volumes’ §7 (Tips & tricks) for the model-specific recovery key combo. The codeplug recovery is separate — even if the firmware is fine, a corrupt Profile.dat can be restored by mounting the microSD in a PC and copying a backup over.
  • AnyTone D878: hardware recovery mode (hold PTT + side key + power-on, plug in CPS cable, write a fresh firmware). The CPS will then ask for a codeplug write; restore the last last-known-good.
  • Baofeng UV-5R/F8HP/UV-B5: no real bricking risk — even a corrupted codeplug doesn’t disable the radio, just blanks the channels. Re-write via CHIRP with a backup.
  • Yaesu VX-8DR: factory reset (hold MON+POWER on power-up) returns the radio to defaults; re-write the codeplug via CHIRP.

For every radio, the recovery anchor is the last-known-good codeplug backup. If you don’t have it, recovery is “reconstruct from RadioReference + memory + frustration.”

1.6 Resources

1.6.1 Programming software — official sites

1.6.2 Third-party AnyTone tooling

  • CPSProgrammer (open source): community-maintained; search GitHub for current canonical repo
  • AnyTone-Sync (Python): community tooling for periodic RadioID + BrandMeister refresh
  • DCS-CodePlugMaster (Windows): bulk talkgroup management

1.6.3 Yaesu paid alternative

1.6.4 Data sources — what goes IN to the codeplugs

1.6.6 Sibling synthesis vols

1.6.7 Cross-deep-dive references