Radio Firmware and Codeplug Updates

Two different things get called "updating the radios", and the confusion has consequences. One is the manufacturer's software inside the device. The other is your configuration. They are updated by different means, fail in different ways, and the standard fleet disaster is treating them as one operation.

Firmware is the operating software of the radio: the code that runs the display, the protocol stack, the audio processing, the power management. It comes from the manufacturer, it is identical for every device of that model, and it changes when the manufacturer releases a version.

The codeplug is the configuration file: channels, frequencies, talkgroups, radio ID, scan lists, button assignments, emergency behaviour, permissions. It describes your organisation. Nobody else's radio has yours.

Programming is the act of writing a codeplug into a radio.

The distinction matters because some firmware updates reset the configuration. A fleet whose codeplug exists only inside the radios has no backup, and the reset removes it permanently.

Not on a schedule. For a reason:

• A defect the manufacturer has fixed that actually affects you.
• A feature you need and cannot otherwise have.
• Compatibility with new infrastructure — a new repeater, a new dispatch platform, new device management.
• A security fix, which matters more on network-connected devices than on conventional handsets.

The counter-case is real. A stable fleet doing its job gains nothing from a version increment and takes on the risk of a regression. "If it works, leave it" is defensible engineering when there is no reason to change.

Whatever version the fleet runs, it should be the same version.

A fleet at three firmware versions and two codeplug versions produces faults that are intermittent, user-specific and unreproducible — the exact profile that gets misdiagnosed as hardware and consumes engineering time. Two users cannot hear each other; a third can hear both; nothing is broken and nothing works.

Configuration drift is not caused by carelessness. It accumulates one reasonable decision at a time: a radio programmed for a specific need, a replacement rebuilt from whichever device was nearest, a batch of new arrivals given a slightly different template.

Export the codeplug from every radio first. Not one representative radio — every one, because they may differ and you want to know if they do.

Record what exists. Firmware version and codeplug version per device, against the serial number.

Pilot on a small group. Five radios, one working week, in real conditions with real accessories. Firmware regressions typically surface in interactions — an accessory that stops working, a repeater behaviour that changes, an emergency function that behaves differently — and those do not appear on a bench.

Then roll out, in batches, with a route back to the previous version if it exists.

Reprogramme after updating, from the master codeplug, so every device lands on the same configuration rather than on whatever survived.

Test after. Transmit and receive on every channel group, the emergency button end to end, accessories, scan behaviour, and reachability from the control position.

Update the inventory with the new versions.

Above roughly thirty devices, cable-and-laptop stops scaling. Hytera's MDM SE and MDM Pro exist for this — bulk programming, firmware distribution, inventory and device status from one place.

Some systems support over-the-air programming, which changes the economics substantially: a talkgroup revision reaches a fleet without collecting the radios. It requires infrastructure support and it is worth confirming at purchase rather than discovering later that the fleet must come in physically for every change.

For PoC fleets, updates arrive over the network as a matter of course. This is one of PoC's genuine operational advantages and it rarely appears in technology comparisons: no device handling at all.

An update that changes button behaviour, menu layout or channel order without telling anyone generates a wave of fault reports the following morning.

Tell users what changed and what to expect, reissue the channel list if the order moved, and brief supervisors first so the first questions have an answer on the floor.

Update handling is a service scope item, and it is usually missing:

• Who supplies firmware and under what terms.
• Whether firmware updates are included in the maintenance agreement or chargeable.
• Response time when an update is needed for a defect.
• Whether over-the-air programming is supported, and what infrastructure it requires.
• Codeplug ownership — the master file delivered in editable form to the organisation.
• How many reprogramming rounds are included per year.

That last pair matter more than they look. An organisation that does not hold its own master codeplug is dependent on its supplier for every change, including the ones that are urgent.