• A new L3Harris radio needed far more output dynamic range than the fielded RF front end it had to work with was designed to give.
• The front end’s transmit chain had two gain stages: a coarse driver with three setpoints (low, medium, high) and a downstream fine stage adjustable in dB. The radio commanded a single power level. I designed and implemented the control software that turns that level into a safe setpoint pair for both stages.
• Reaching the required range meant disabling the equipment’s built-in protection interlocks, so the software became the only thing standing between a command and hardware damage. Both stages maxed, or either past its limit, could destroy the amplifier and drop a pilot’s radio link.
• Acted as de-facto software lead: direction for a small team, and project status reporting to organization management.

L3Harris Communication Systems West builds secure radio systems, and the software I wrote there is safety-critical C++ around hardware control. I have to stay away from specifics, but the shape of this project is worth telling.

The constraint

A new radio was being brought up against RF equipment that was already deployed in numbers, and could not be redesigned. The radio needed a large amount of dynamic range in its transmit output to function properly. The front end offered power control in two stages: a coarse amplifier with exactly three setpoints, and a finer amplifier downstream whose gain is set in dB. Neither stage alone covered the range, and the equipment’s original control plane did not expose them as a single continuous knob.

The control problem

Our side commanded one number, the desired output power. My job was the mapping from that number to a pair of setpoints, coarse and fine, that produces it. That is a search over a small, discontinuous space with hardware-specific constraints: the coarse setpoints are not evenly spaced, the fine stage’s usable range depends on which coarse setpoint sits in front of it, and transitions between coarse setpoints have to be sequenced so the chain never passes through a combination that overdrives the next stage. The control scheme that came out of that is the “unorthodox” part, and it added a substantial amount of complexity to what would otherwise be a lookup.

Why correctness was the whole job

The equipment had interlocks to stop the two stages from being driven into a damaging combination. To reach the range the radio needed, we had to disable them. From that point on, the software was the safeguard. Both stages at maximum, or either pushed past its limit, could damage the amplifier, and the consequence of a damaged amplifier in this equipment is a pilot losing their radio link.

That reframed the project. The value was less in the mapping than in the confidence that the mapping could never emit an unsafe pair, under any command sequence, including transitions, faults and out-of-range requests. Design, implementation and verification were weighted accordingly, and the verification effort was a first-class deliverable rather than a phase at the end.

Leading it

This was also where I first acted as a software lead. I set direction for a small team, owned the overall status, and reported project health to organization management. Learning to give an honest schedule for safety-critical work, where the verification tail is the schedule, was as much a part of the project as the control logic.