DEV Community: P.R.Decker

Acquisition: finding the burst

P.R.Decker — Fri, 16 Oct 2026 14:44:09 +0000

Part 4 of "Building a MIL-STD-188-110 HF Modem in Modern C++." Start with the overview, Part 1, the rules I build by, Part 2, the transmit chain, or Part 3, the audio front end. The code for this article is on GitHub: kg7hf/modem-core.

Part 3 ended with symbols: the front end turns 48,000 audio samples a second into 2400 complex values a second, each read at a symbol's peak. It does not say what they are. A receiver listens to a channel that is mostly noise; somewhere in it a burst starts, in one of the standard's modes, with its carrier some hertz away from where the receiver expects it. Acquisition answers four questions from the symbols alone: is a burst there, where does it start, which mode is it, and where does its data begin. It also measures how far off the carrier is, so the stages after it start close.

The standard makes that possible: every burst begins with a preamble whose symbols it fixes in advance. This article reads the preamble the way the standard defines it, then builds the search for it.

Part 3 had front_end_demo; this article has acquisition_demo. Build it, run it, and keep its output open beside this article:

./build/acquisition_demo

It runs fourteen steps in the order this article takes them, and every output block below comes out of one of them. Each step is a function in tests/walkthrough/acquisition_steps.cpp that main() calls by name, and each section names its step. In VS Code, press F5 and choose acquisition_demo (gdb); it stops at the top of main(), so step into each step in turn, or set a breakpoint in the function for the section you are reading and continue to it.

Step	Function	Section
1	`preamble_segments()`	The preamble, as the standard defines it
2	`prefix_reference()`	The reference
3	`fading_prefix()`	Correlating so a fade does not hide it
4	`correlation_comb()`	A match at every segment
5	`carrier_range()`	The carrier offset
6	`read_segment()`	Reading the mode and the countdown
7	`wake_mid_preamble()`	Waking up mid-preamble
8	`unsupported_mode()`	A mode this modem does not implement
9	`segment_vote()`	One segment, or all of them
10	`noise_only()`	No burst at all
11	`phase_search()`	Part 3's hang-up, fixed while acquiring
12	`clock_offset()`	The clock offset, or a second loop
13	`learning_time()`	When to learn, and when to stop
14	`long_burst_rule()`	When to learn, and when to stop

As in Part 3, the unit tests call the same functions: tests/acquisition_tests.cpp runs each step and checks what it returned, so the walkthrough is under automated regression too.

Steps 4, 6 and 7 work on one recording: the "Hi" burst from Parts 2 and 3 (600 bps, long interleave), half a second into a noisy line, with white noise 10 dB below the signal in a 3 kHz band and the whole signal moved 37 Hz off frequency. Step 9 uses the same burst with the noise turned up. Part 3's front end turns it into symbols, and acquisition gets nothing else.

The preamble, as the standard defines it

MIL-STD-188-110B describes the preamble in 5.3.2.3.7.2. It is three 200 ms segments for the zero and short interleave settings, and twenty-four for the long. Each segment is 15 three-bit channel symbols:

0, 1, 3, 0, 1, 3, 1, 2, 0, D1, D2, C1, C2, C3, 0

The first nine are fixed. D1 and D2 name the bit rate and the interleave setting (Table XV); 600 bps with the long interleave is D1 4, D2 6. C1, C2 and C3 are a count of the segments still to come, from 2 (zero and short) or 23 (long) down to 0 in the last segment. The count is a six-bit word, C1 holding the most significant two bits, and each two-bit piece is sent as a three-bit symbol with a 1 in front of it, so 23, binary 010111, goes out as 5, 5, 7 (Table XVI).

Each channel symbol goes out as 32 transmitted symbols (Table XVII): one of eight patterns of tribits 0 and 4, phases 0 and 180 degrees, eight long and repeated four times. The sync randomizer (5.3.2.3.8.2) then adds its own 32-tribit sequence, mod 8, the way Part 2's data randomizer does in the body. Fifteen channel symbols of 32 make 480 symbols, exactly 200 ms at 2400 symbols a second.

Step 1, preamble_segments(), reads the transmitter's own preamble back: for each 32-symbol block it finds the channel symbol whose pattern, plus the randomizer, made those tribits:

segment   0 1 3 0 1 3 1 2 0 | D1 D2 | C1 C2 C3 | 0   countdown
      0   0 1 3 0 1 3 1 2 0 |  4  6 |  5  5  7 | 0          23
      1   0 1 3 0 1 3 1 2 0 |  4  6 |  5  5  6 | 0          22
  ...
     22   0 1 3 0 1 3 1 2 0 |  4  6 |  4  4  5 | 0           1
     23   0 1 3 0 1 3 1 2 0 |  4  6 |  4  4  4 | 0           0
24 segments; prefix on every one: yes; countdown runs down to 0: yes
D1 4, D2 6 on a long preamble: 600 bps, long interleave

Acquisition follows that table. The nine fixed symbols are the same in every segment of every burst, so the receiver can search for them without knowing anything else. Once it has found them, D1 and D2 in the same segment name the mode, and the countdown says how many segments remain before the data, so where the body starts.

The reference

The receiver searches for the first nine channel symbols, 288 transmitted symbols (I call them chips here, the usual name for the symbols of a spreading code), built exactly as the transmitter builds them. Step 2, prefix_reference(), prints the first eight:

chip  code  randomizer  tribit       I       Q
   0     0           7       7  +0.707  -0.707
   1     0           4       4  -1.000  -0.000
   2     0           3       3  -0.707  +0.707
   3     0           0       0  +1.000  +0.000
   4     0           5       5  -0.707  -0.707
   5     0           1       1  +0.707  +0.707
   6     0           5       5  -0.707  -0.707
   7     0           0       0  +1.000  +0.000
 ...  288 chips; the same as the first 288 symbols of every transmitted segment: yes

Channel symbol 0's pattern is all zeros, so its 32 chips are the sync randomizer's own sequence. The randomizer's sequence is 32 long and a segment is 15 of its periods, so every segment starts it over: the 288 chips are the same at the start of every segment, and the step checks them bit for bit against all 24 segments the transmitter sent.

The code is make_body_prefix_reference(), in modem/m110a/synchronization.cpp:

void make_body_prefix_reference(std::span<IQSample, prefix_symbols> reference) noexcept
{
    SyncRandomizer randomizer;
    std::size_t index{};

    for (const auto channel_symbol : acquisition_prefix)
    {
        for (std::size_t spread = 0U; spread < channel_symbol_chips; ++spread)
        {
            const auto tribit = tribit_add(body_channel_symbol_tribit(channel_symbol, spread), randomizer.next_tribit());
            reference[index++] = psk8_symbol(tribit);
        }
    }
}

body_channel_symbol_tribit, SyncRandomizer, tribit_add and psk8_symbol are Part 2's transmitter functions, so the reference cannot disagree with what the transmitter sends.

The reference never changes, so the scanner builds it once, on first use, into function-local static storage, the way psk8_symbol keeps its constellation table. That was not the first version. The scanner used to build it on its own stack: 288 complex floats, over 2 KB, in a frame of nearly 5 KB. When I moved the code into this repository, its stack-usage check, which holds every function in the modem library to 4 KB, failed. In static storage the reference costs no stack, and no time after the first call, and the frame is back inside the limit.

Correlating so a fade does not hide it

A correlation multiplies the received symbols by the conjugate of the reference and adds the products. At the start of a segment every product lines up, and the sum is large; anywhere else the products point every which way, and the sum stays small. Divided by the energies of both, the result is 1 for a perfect match and near 0 for none.

One sum over all 288 chips assumes the channel holds still for the 120 ms they take. An HF channel does not. A fading path changes its gain and turns its phase as it goes, and a turn of half a circle partway through the prefix makes the second part of the sum cancel the first. body_prefix_correlation() sums each 32-chip block on its own and adds the nine magnitudes instead. A block lasts 13 ms, short enough for the channel to hold still, and a magnitude is the same whichever way its block points. Step 3, fading_prefix(), shows the difference on the reference itself, clean and then with the last 128 chips turned 180 degrees, as a fade can:

                            one sum   nine blocks
clean prefix                 1.000       1.000
last 128 chips turned 180    0.111       1.000

One sum keeps only the difference between the two parts: 160 chips against 128, 32 out of 288. The nine-block sum is unchanged. On a channel that holds still, the two are the same.

The block sum has a cost. Where nothing matches, the products are random, and a sum of random products grows only like the square root of its length. Nine short sums, their magnitudes added, grow faster than one long one, so away from a match the block correlation sits on a higher floor than the single sum would.

    for (std::size_t index = 0U; index < reference.size(); ++index)
    {
        const auto rotation = std::polar(1.0F, frequency_radians * as_real(index));
        const auto product = input[start + index] * std::conj(reference[index] * rotation);
        coherent += product;
        block_correlation += product;
        input_energy += std::norm(input[start + index]);

        if ((index + 1U) % channel_symbol_chips == 0U)
        {
            noncoherent += std::abs(block_correlation);
            block_correlation = IQSample{};
        }
    }

The rotation takes the carrier offset out of the reference before it is compared; the next section is where the offset comes from. The one long sum, coherent, is still kept: its angle is the carrier phase at the start, which the equalizer starts from.

A match at every segment

Step 4, correlation_comb(), runs the whole test: the noisy recording, through the front end, correlated at every start from 300 symbols before the burst to the end of its third segment. It lists every start inside the 120 Hz carrier gate that reaches a correlation of 0.35, with the carrier offset estimated there; starts are counted from the burst's first symbol:

10 dB SNR, carrier +37 Hz off; every start that reaches the 0.35 floor:
  start  correlation  carrier (Hz)
   -256        0.354         +46.6
   -160        0.362         +29.1
    -96        0.396         +58.1
      0        0.959         +35.2
    480        0.959         +36.2
    960        0.965         +37.6
largest correlation anywhere else, inside the carrier gate: 0.308, at start 938

A match every 480 symbols, one at the start of each segment, at 0.96, each with its own estimate of the 37 Hz offset. Between them, nothing reaches 0.35; the largest is 0.308.

The three weak ones before the burst are the burst too. A start 96 symbols early, three channel symbols, lays the last six blocks of the reference over the burst's first six. The prefix repeats itself (0, 1, 3, then 0, 1, 3 again), so three of those blocks carry the same channel symbol in both, and three out of nine blocks match. At 160 and 256 symbols early, fewer blocks overlap and fewer match. These are real partial matches, about a third of a full one, so a floor high enough to take them out would also lose weak bursts. Reading the mode and the countdown takes them out (Step 6).

The carrier offset

Two single-sideband radios never tune to exactly the same frequency, so the signal arrives some hertz above or below where it left, and every symbol comes out of the front end turned a little further than the one before. The serial-tone section of MIL-STD-188-110B holds the transmitter's own carrier to 1 Hz (5.3.2.3.9b), but says nothing about how large an offset a receiver must accept. Its Appendix C sets a Doppler test for the higher-rate waveforms at 75 Hz (C.6.3), and this modem accepts up to 120 Hz.

estimate_body_prefix_frequency_radians() measures the offset over the prefix:

    for (std::size_t index = 1U; index < reference.size(); ++index)
    {
        differential += input[start + index] * std::conj(input[start + index - 1U]) * std::conj(reference[index]) * reference[index - 1U];
    }

    return std::arg(differential);

Each term is a received symbol times the conjugate of the one before it, with the known modulation of both taken out. What is left in each term is the turn from one symbol to the next: the offset, in radians per symbol. The terms are added before taking the angle, so the noise averages out over 287 of them. The estimate needs neither the carrier phase nor the correlation, so the scan can run it first.

An angle is only known modulo a full turn, so the estimate wraps at half a turn per symbol: 1200 Hz either way at 2400 symbols a second. Step 5, carrier_range(), turns a clean segment by each offset:

  true (Hz)  estimated (Hz)  inside the 120 Hz gate
       +0.0            +0.0  yes
      +37.0           +37.0  yes
      -75.0           -75.0  yes
     +110.0          +110.0  yes
     +150.0          +150.0  no
     +600.0          +600.0  no
    +1300.0         -1100.0  no

The gate, maximum_frequency_offset_hz, is the scan's first test. It is the cheapest of three, and noise turns by random amounts, so most starts in noise fail it before the correlation is computed at all.

In Step 4, one segment's estimate came out between 35.2 and 37.6 Hz at 10 dB. That is close enough to start from; Part 3's carrier tracker takes up the rest.

Reading the mode and the countdown

A start that passes the carrier gate and the correlation floor is a candidate. characterize_body_candidate() reads its D1, D2, C1, C2 and C3: for each, it rebuilds all eight channel symbols' chips, randomizer included, correlates each with the received block, and takes the largest magnitude. The eight patterns are orthogonal, so only the right one correlates fully, and the magnitude makes the decision independent of the carrier phase. (It also adds the strongest copy of the same block up to 15 symbols late, for a two-path channel whose first path has faded; that is next week's subject.)

Then the checks. Every count symbol is sent as 4 plus two bits, so a count symbol below 4 means the candidate is not the start of a segment. D1 and D2 must name a mode this modem implements, and the count must fit the preamble that mode sends. A candidate that passes is valid, and the arithmetic is short:

            const auto elapsed_segments = segments - countdown - 1U;
            const auto elapsed_symbols = elapsed_segments * first_segment_symbols;
            candidate.first_body_symbol = detected_segment + (countdown + 1U) * first_segment_symbols;

The body starts after this segment and the countdown segments still to come; the preamble started elapsed_segments before this one.

Step 6, read_segment(), walks the scan's tests start by start through the recording until a candidate is valid:

start 940: correlation 0.354, carrier +46.6 Hz, but not a valid segment
start 1036: correlation 0.362, carrier +29.1 Hz, but not a valid segment
start 1100: correlation 0.396, carrier +58.1 Hz, but not a valid segment
first start through all three gates: symbol 1196 (the burst starts at 1196)
  correlation 0.959, carrier +35.2 Hz
  D1 4, D2 6: 600 bps, long interleave
  countdown 23: the body starts 24 segments on, at symbol 12716 (really 12716)
  so the preamble began at symbol 1196

The three starts that fail are Step 4's early partial matches: they passed the floor, and their blocks read as nothing the standard sends. The first valid one is the burst's first symbol, and the countdown puts the body exactly where it is.

Waking up mid-preamble

The long preamble lasts 4.8 seconds, so a receiver can easily start listening in the middle of one. Step 7, wake_mid_preamble(), cuts the recording 10 segments and 137 symbols into the burst and runs the whole acquisition on what is left:

the receiver starts 4937 symbols into the burst (segment 10, symbol 137)
  it read the countdown from burst segment 13: 10, so 11 segments to the body
  body starts at symbol 6583 of what it heard (really 6583)
  preamble start in what it heard: no

The countdown does not depend on where the receiver started. Acquisition reports that the preamble began before the recording did, so nothing downstream counts on having all of it.

A mode this modem does not implement

The standard is explicit: "If a demodulator receives any D1, D2 combination that it does not implement, it shall not synchronize but shall continue to search for synchronization" (5.3.2.3.7.2.1). Table XV lists D1 7, D2 7 as 2400 bps secure voice, which this modem does not implement, and a note reserves 5, 6 and 5, 7 for application-specific use. Step 8, unsupported_mode(), builds a 600S preamble, then the same preamble with D1 and D2 changed to 7, 7 in every segment:

D1 6, D2 6 (600S):        supported                     acquired: yes
D1 7, D2 7 (patched in):  recognized, not implemented   acquired: no

recognize_body_designators() distinguishes the two cases: a combination the standard defines but this modem does not implement, and one the standard does not define at all. Either way the candidate is not valid, nothing is acquired, and the scan goes on.

One segment, or all of them

That is everything acquisition needs from one segment. A segment is 200 ms of a weak signal, and one decode at low signal-to-noise can be wrong. The burst sends the same information in every segment, so acquire_body_preamble() reads all of them:

    const auto scan = scan_for_consensus(symbol_rate_input, reference, search_starts, config);

    if (scan.count == 0U)
    {
        return Status{StatusCode::unavailable, "body preamble countdown not acquired"};
    }

    const auto& strongest = scan.groups[strongest_group(scan)].representative;
    return vote_mode_and_boundary(symbol_rate_input, reference, strongest, config);

scan_for_consensus() takes every start through the three gates: the carrier offset, the correlation, and a valid read. Each valid candidate names a mode and a body boundary, and candidates that name the same ones are the same burst, read through different segments, so they join one group. strongest_group() takes the group with the most segments behind it; a tie goes to the larger sum of correlations. The group's representative, which supplies the carrier offset and phase the later stages start from, is its best-correlated member, not its earliest: an early segment that clears the floor during a fade can carry an estimate several hertz off, and starting the equalizer from it can cost a block that a cleaner segment of the same group would have decoded. Then vote_mode_and_boundary() reads every segment from the winner's on and lets the majority correct the mode and boundary, if at least two segments agree on something else. When the scan has covered the whole preamble, the strongest group already is the majority; the vote matters when the scan has seen only the first segment or two, as it has in a streaming receiver that commits early.

Step 9, segment_vote(), turns the noise up to 4 dB above the signal, reads each segment of the recording on its own, and groups the reads:

-4 dB SNR, each segment read on its own; the ones that did not read right:
segment  correlation  countdown  reads as
      0        0.257          -  not a valid segment
      3        0.505          -  not a valid segment
      8        0.485          -  not a valid segment
     10        0.434          -  not a valid segment
     15        0.218          -  not a valid segment
     16        0.243          -  not a valid segment
     18        0.493          -  not a valid segment
     20        0.378         19  600 bps, body at 20396  (wrong)
     21        0.410          -  not a valid segment
right 15, wrong 1, not valid 8
grouped by the burst they describe:
  600 bps, body at 12716: 15 segments
  600 bps, body at 20396: 1 segment
acquisition: right

Segment 20 read its countdown as 19 instead of 3, which would have put the body 3.2 seconds late. Alone it is a group of one; fifteen segments agree on the right answer.

No burst at all

A receiver spends most of its time listening to noise, and every false acquisition costs something: a mode and a boundary the stages after it try to decode, until they give up. Step 10, noise_only(), runs ten seconds of white noise through the front end and the whole acquisition:

10 s of noise: largest correlation 0.264 against the 0.35 floor
  starts through both gates 0, of those reading as a valid segment 0; acquired: no

BodyAcquisitionConfig sets the correlation floor at a cautious 0.75 by default. This walkthrough uses 0.35, the floor the streaming receiver later in the series runs at, because the floor is only the second of three gates. A start in noise has to turn by under 120 Hz, then correlate above 0.35, then read as a segment of a mode this modem implements, with a count that fits; and to win, it has to outnumber the segments of any real burst. In ten seconds of noise nothing passed the first two.

How often acquisition finds a burst at each signal-to-noise ratio, and how often noise alone gets through, are measurements of their own, over many recordings; they come in a later article.

Part 3's hang-up, fixed while acquiring

Part 3 found one start its timing loop handles badly. A loop started half a symbol off the symbol peaks reads early and late samples of equal strength, so its error is close to zero and it barely moves; on the short preamble it can still be off the peaks when the body begins. Part 3 left that as a documented limit, with a [!shouldfail] test. The fix belongs to acquisition, because only while the receiver looks for a burst can the loop be anywhere in the symbol; once it has locked to one, the loop is on the peaks.

The fix is a phase search: the energy comparison a batch receiver makes over a whole recording, made with the three points the loop already reads. Over every 120 symbols the front end adds up the energy of the on-time samples and the energy half a symbol off them. A loop on the peaks reads more energy on time: half a symbol off, where two neighbouring pulses overlap, a stream of raised-cosine pulses at the receive filter's 0.35 rolloff reads about 0.83 of its on-time energy. A loop hung half a symbol off reads more energy off time. When the off-time sum beats the on-time sum by 6 percent in two windows running, the loop is moved half a symbol, onto the peaks, and pulls in from there. It waits for two windows so that noise, whose two sums differ by a few percent, never moves a locked loop. The same comparison speeds the loop up while it is well off the peaks: after a window whose off-time energy reached 92 percent of the on-time energy, the next window runs at three times the tracking gain. In BodyAudioStreamFrontend::process():

        float phase_move = 0.0F;
        if (mPhaseSearch)
        {
            mPhaseOnEnergy += std::norm(on_time);
            mPhaseOffEnergy += (std::norm(early) + std::norm(late)) / off_time_points;

            if (++mPhaseWindowSymbols >= phase_search_window_symbols)
            {
                mPhaseWindowsOff = mPhaseOffEnergy > mPhaseOnEnergy * (1.0F + phase_search_margin) ? mPhaseWindowsOff + 1U : 0U;
                mPhaseFastGain = mPhaseOffEnergy > mPhaseOnEnergy * phase_search_fast_gain_ratio;

                if (mPhaseWindowsOff >= 2U)
                {
                    phase_move = as_real(half_symbol_samples);
                    ++mPhaseSearchMoves;
                    mPhaseWindowsOff = 0U;
                }

                mPhaseOnEnergy = 0.0F;
                mPhaseOffEnergy = 0.0F;
                mPhaseWindowSymbols = 0U;
            }
        }

        const auto loop_gain = mPhaseSearch && mPhaseFastGain ? phase_search_loop_gain : mTimingLoopGain;

The receiver turns the search on while it looks for and acquires a preamble, and off once it commits to a burst, so a locked body is never moved. Off, the loop is Part 3's loop exactly. Step 11, phase_search(), starts a 2400S burst at each of the twenty sample phases of a symbol, at 10 dB, with and without the search:

2400S, 10 dB SNR, the burst started at each of the 20 sample phases of a symbol
pulled in before symbol 1200 of the 1440-symbol preamble: 17 of 20 plain, 20 of 20 with the phase search
the starts the plain loop missed:
lead  plain loop pulled in at   with the search   moves
   0     not in the preamble               245       1
   1                    1328               379       1
  19     not in the preamble               431       1

Without the search, three starts around half a symbol off missed symbol 1200 of the 1440-symbol preamble, and two of them were not on the peaks anywhere in the preamble. With it, all twenty were; the three late ones were moved once each and were on the peaks by symbol 245 to 431. Part 3's [!shouldfail] test runs the front end alone, without the search, so it still fails as expected: the fix lives where the receiver acquires, and this article's tests check it there.

The clock offset, or a second loop

Part 3 ended on what its timing loop cannot do. Two sample clocks never agree exactly, so the received symbols arrive slightly faster or slower than 20 samples apart, and part of the timing error is steady. The loop is proportional: each symbol it moves by its gain times the error. To keep up with a steady drift it needs a steady error, so it settles off the symbol peaks by the drift divided by its gain. At 100 ppm the drift is 0.002 samples a symbol; with the loop's gain of 0.08 and the detector's slope near the peak, that is about 0.74 samples. At 1000 ppm it would need ten times as much, which is past the peak of the detector's output, and the loop cannot hold it.

Three more steps measure that, and what fixes it. The bench now records where the loop reads every symbol and compares it with the grid the transmitter laid down, stretched by the clock offset (grid_offsets() in the test harness), so these numbers are the loop's own position, not a count of symbol decisions. Step 12, clock_offset(), runs 2400 bps bursts carrying 10 s of data each, at 20 dB. The interleaver pads a body to whole blocks, so the long-interleave body lasts 14.4 s and the short one 10.2 s:

20 dB SNR, 10 s of data in each burst; the loop against the symbol grid through the body
clock (ppm)  mode   loop    offset (samples)  wander  symbols slipped  integrator at the end
       +100  2400L  type 1             +0.68    0.22                0                      -
       -100  2400L  type 1             -0.64    0.21                0                      -
      +1000  2400L  type 1             +1.47   11.46               30                      -
       +100  2400L  type 2             +0.02    0.22                0             -3 ppm off
      +1000  2400L  type 2             +0.03    0.24                0             -6 ppm off
      -1000  2400L  type 2             +0.03    0.20                0             +1 ppm off
      +1000  2400S  type 2             +0.07    5.98                0            -11 ppm off

The first three rows are Part 3's loop, type 1. At 100 ppm either way it sits 0.64 to 0.68 samples off the peaks, on the side the clock pushes it. At 1000 ppm it slips 30 symbols through the body. The count starts a segment into the body, and from there the clock drifts by 34 symbols, so the loop barely follows the clock.

The fix is a second loop with an integrator, the same structure as Part 3's carrier tracker. The integrator adds up the error, so it settles at the clock's rate, and the proportional term is left with only the jitter. That makes it a type-2 loop. In BodyAudioStreamFrontend::process():

        if (mTimingIntegralGain > 0.0F && mTimingRateMode != TimingRateMode::held)
        {
            // Type 2: the integrator carries the clock's rate, and the proportional term only
            // the jitter. It integrates while tracking; frozen, the rate stands. Both are
            // limited to the step limit, which is far beyond any real clock offset.
            const auto normalized_error = timing_error / normalization;

            if (mTimingRateMode == TimingRateMode::tracking)
            {
                mTimingRate = std::clamp(mTimingRate + mTimingIntegralGain * normalized_error, -mMaximumTimingStep, mMaximumTimingStep);
            }

            mTimingRateSum += round_to<std::int64_t>(mTimingRate * timing_rate_mean_scale);
            ++mTimingRateSamples;

            correction = std::clamp(loop_gain * normalized_error + mTimingRate, -mMaximumTimingStep, mMaximumTimingStep);
        }
        else
        {
            // Type 1, the default, and the tracker while held: the proportional loop.
            correction = std::clamp(loop_gain * timing_error / normalization, -mMaximumTimingStep, mMaximumTimingStep);
        }

The integrator is off unless configure_timing_tracker() turns it on, and with it off, or held, the loop is Part 3's expression exactly, so every Part 3 number stands. In Step 12's type-2 rows it runs from the first preamble candidate to the end of the burst. On the long preamble it ends within 6 ppm of the clock, at 100 and at 1000 ppm either way, and the loop sits within 0.03 samples of the peaks without a slip. On the short preamble at 1000 ppm the loop is still pulling in when the body begins, so it wanders 6 samples through the body, but it does not slip.

When to learn, and when to stop

An integrator left running is only right while it is fed a signal. On a line with no signal, the timing error is not zero on average, and an integrator running through minutes of noise walks to a rate the next preamble cannot pull in from. So the receiver holds it at zero while it searches, and starts it at the first preamble candidate acquisition finds.

Through a fade it causes trouble too. A fading path changes the shape of the received pulse, so the timing error carries a bias that follows the path gains, and the integrator turns that bias into a rate. A clock offset is a crystal's and does not change during a burst, so the first design I measured learned the rate in the preamble and froze it for the body: track from the first candidate, and once 2880 symbols and the end of the preamble had passed, freeze. On the front end alone, at 20 dB, it worked. In the receiver's qualification it did not. The qualification runs the whole receiver, decoding, on white noise through the test bench's channel at the signal-to-noise ratio where each mode is meant to work, many times per condition, each run with its own seed: the number that starts the random-number generator, so a run's noise and fading can be repeated exactly. At 1000 ppm either way, on the short-interleave modes, the receiver with the freeze lost about two thirds of the bursts that the receiver with the integrator left running decoded. Step 13, learning_time(), shows why. It runs the integrator on 600 bps with the short interleave and the clock 1000 ppm off, at falling signal-to-noise ratios:

600S, the clock +1000 ppm off, the integrator running from the first candidate, three seeds
SNR (dB)  rate error at 2880 symbols (ppm)  within 100 ppm from symbol
      20                    +1   -30   -34          2627   2735   2715
      10                  +391  +207   -37          4127   4102   3859
       7                    -6   -52  +213          4091   4049   6266
       4                  +845  +580  +835          4401   6124   8606

At 20 dB the integrator is within 100 ppm of the clock about 2700 symbols after the first candidate, inside the 2880-symbol window. At 4 dB it takes 4400 to 8600 symbols, and when the window closes it is still 580 to 845 ppm off. The timing error is divided by the energy of the three samples it reads, and at 4 dB much of that energy is noise, so each symbol moves the loop and the integrator less. A fixed window that fits 20 dB freezes a wrong rate near the modes' working SNR.

Leaving the integrator running has a cost of its own on long messages. Through pathsim, on a slow fade (two paths 1 ms apart with a 0.5 Hz fading bandwidth) at the mode's Table 10.1 signal-to-noise ratio, the running integrator lost every one of a set of five-minute 75 bps messages, where the type-1 loop lost at most one; the test bench's own channel gave the same picture. And on white noise at each mode's Table 10.1 signal-to-noise ratio, the type-1 loop alone decoded with the clock up to 250 ppm off, though 75 bps at +250 ppm was marginal, and it lost every long-interleave mode at 500 ppm. MIL-STD-188-110B holds signaling rates to 0.01 percent of nominal (4.2.1), so two modems within the standard are at most 200 ppm apart: the integrator is for clocks worse than the standard allows.

So the receiver judges the integrator rather than freezing it. It tracks from the first candidate; at 20, 30 and 40 seconds it takes the mean of the integrator's rate since 5 seconds, when the pull-in is over, and if that mean is below a threshold rising from 125 to 175 ppm, it retires the integrator: holds it at zero, the type-1 loop, for the rest of the burst. An integrator that passes the last judgement runs to the end, and a burst over before 20 seconds keeps it throughout. The front end keeps the sum in fixed point, the rate times 2^20 per symbol, so 10^5 symbols lose nothing to float rounding. Step 14, long_burst_rule(), shows why the judgement is made on the mean. It runs 25 s of 2400L data, a 28.8 s body, through the same slow fade, with no clock offset and with 350 ppm:

2400L, 25 s of data through Watterson fading, 1 ms and 0.5 Hz, 20 dB SNR; the integrator from 5 s to 20 s
clock (ppm)  seed  largest momentary rate  mean rate  at 20 s (threshold 125 ppm)
         +0     1                 712 ppm     27 ppm  retired
         +0     2                 643 ppm     83 ppm  retired
       +350     1                 837 ppm    323 ppm  kept
       +350     2                 924 ppm    265 ppm  kept

Through the fade the integrator's momentary rate swings to 640 to 920 ppm whether there is a clock or not; the strongest path moves, and the integrator follows it. Over 15 seconds the swings average out: 27 and 83 ppm with no clock, 265 and 323 ppm with one. The mean tells them apart where the momentary rate cannot.

One case none of this fixes. When two fading paths are about as strong as each other, the loop can walk from one to the other, a few samples apart, whatever rate it holds. That is the equalizer's problem, and it comes with the equalizer.

Testing, part one: what the standard asks, and how long it takes

This article starts a testing thread that runs through the rest of the series, a piece in each article, to a full treatment of compliance testing in Part 9.

MIL-STD-188-110B sets the serial-tone performance in 5.3.2.5, Table XX: a coded bit-error rate at a signal-to-noise ratio measured in a 3 kHz band, on Watterson-model channels per ITU-R F.520-2 (for the fading rows, two independent fading paths of equal average power), with the longest interleaver. The JITC conformance test plan (2004) turns that into the test conditions of its Table 10.1 (Subtest 10), and its criteria say how long: at least an hour on the non-fading channel, and at least five hours on each fading one.

The hours come from the statistics. A bit-error rate of 10^-5 is one error in 100,000 bits. With no errors in n bits, the 95 percent upper bound on the rate is about 3/n, so showing 10^-5 takes about 300,000 error-free bits: two minutes at 2400 bps, over an hour at 75 bps. That bound assumes the errors are independent, and a decoder's are not: when it fails, it fails over a run of bits, so for a coded modem the bound is optimistic. A fading channel needs longer still, because the errors come in the deep fades, which are rare; the test has to run long enough to meet a great many of them.

None of that tests acquisition directly. The serial-tone section sets no acquisition requirement, and Appendix C's acquisition test, for the higher-rate waveforms, reads "Not yet standardized" (C.6.2). The acquisition tests in this article are mine: every mode found, the carrier gate, waking mid-preamble, a mode not implemented, and nothing in ten seconds of noise.

A test result is only as good as the channel it ran through, so this work uses three channel simulators, and measures each before trusting its numbers:

The test bench's own model, inside the unit tests: a two-path Watterson model, an engineering model. Its noise and fading come from a random-number generator started from a seed, so two designs run on the same seeds meet exactly the same noise and the same fades, and any difference between them comes from the designs, not from luck. That makes it good for comparing designs, as Steps 12 to 14 do, and not for absolute numbers.
pathsim (github.com/bubnikv/pathsim): Moe Wheatley AE4JY's PathSim, reworked by Vojtech Bubnik OK1IAK, under the GPL-3.0. The seeded campaigns run on it; my build adds a seed, so a run repeats.
The IONOS HF channel simulator (github.com/ARSFI/HFSimulator): a hardware box by Rick Muething KN6KB, Tom Lafleur KA6IQA and Tom Whiteside N5TW, from the Amateur Radio Safety Foundation, under the MIT license. It puts a real audio path between the transmitter and the receiver, so it checks the software simulators independently. Measured the same way as pathsim, it delivered more signal-to-noise ratio than its setting on a non-fading channel, by an amount that varied with the signal level, and its two-path settings stop at 4 ms and 2 Hz, short of the 5 ms, 5 Hz channel Table 10.1 sets for the lowest rates.

A commercial laboratory channel simulator costs many thousands of dollars. Whichever kind is used, MIL-STD-188-110D's Appendix E applies to a simulator used to test a modem's compliance, and says what it should meet: a frequency response within 0.5 dB; a signal-to-noise ratio within 0.25 dB of its setting on a non-fading path, averaged over at least 20 minutes, and within 0.5 dB on fading paths, averaged over at least two hours; and a Doppler spectrum measured from at least three hours of a tone (E.7). I ran the same kinds of measurement, shorter than the appendix asks, with the same probes on every simulator.

Two other software modems decode the same captured audio beside this one: MS-DMT, N2CKH's free, closed-source 110A modem, and ION2G, another 110A software modem. They are a second opinion on the test set-up, not a reference for this receiver: when all three decode a clean burst exactly, the audio path is good, and a disagreement points at the set-up before it points at a decoder.

The test audio comes from my waveform generator and signal lab. They render a recording with CW, noise, impulses, fades and sample slips mixed in, play it from the PC or from a microcontroller board that is also a USB sound card, capture what comes back, and keep a journal to replay any run. They will be public, under the GPL-3.0, soon.

The tests

tests/acquisition_tests.cpp runs every walkthrough step and checks what it returned: the 24 segments and their countdown, the reference against every segment, the block sum through the phase flip, the matches at the segment starts and nowhere else, the estimate to 1200 Hz and the gate at 120 Hz, the mode, the countdown and the body boundary, the wake, the mode not implemented, the vote, and the noise. The phase-search test checks that every start phase pulls in within the short preamble with the search on. The clock steps' tests check the loop against the grid: type 1 off the peaks by about the drift over its gain at 100 ppm and slipping at 1000, type 2 on the peaks with no slip; at 4 dB the integrator still hundreds of ppm off when 2880 symbols have passed; and on the long burst, the mean telling no clock from a real one. Around them are tests beyond the walkthrough: every mode the modem implements, at 10 dB with the carrier 75 Hz off either way, found with the right mode, start and body; the gate, which takes a burst 110 Hz off and not one 150 Hz off; and waking at five places in a long preamble, down to the last whole segment.

The test bench grew with them. The test channel takes a carrier offset, in whole hertz, so the shift is exact over any length of audio, the way the CW tone is. Its clock offset came back too, fixed: the first version kept the resampler's position in one float, which past a fraction of a second could no longer take the offset's tiny step, so a whole burst got the offset only at its start. It now keeps a whole sample plus a fraction, the way the front end keeps time. And the bench has its own answer for where a burst sits in the front end's output, locate_burst(): it lines the burst's last 2000 symbols up with what was sent, eight at a time so a turning carrier cannot cancel the sum. Acquisition is checked against that, and never against itself.

The acquisition code reached this repository rearranged. acquire_body_preamble() had grown into one function of 400 lines with a lambda inside it, a fix at a time; it is now the short sequence above, one named function a step. Before the rearrangement went anywhere, a scratch program ran the old and the new code on the same inputs, every combination of six modes, four carrier offsets, three signal-to-noise ratios, six channels (one path; two paths at three spacings; two with the first path faded) and three acquisition settings, and compared every field of every result bit for bit. They were identical.

Run it on your own

Each demo walks one stage on data I chose. The runner runs every stage published so far, in order, on what you give it: your message through Part 2's transmitter, a channel you set, Part 3's front end, and this article's acquisition. It prints what each stage found. Each article adds its stage, so it grows with the series.

./build/runner "Hi" --snr 10 --carrier 37

== Part 2  transmit: "Hi" in 600L (600 bps, long interleave)
           2 bytes -> 11520 preamble symbols (24 segments) + 11520 body symbols, 9.60 s of audio
== Channel: 10 dB SNR, carrier +37 Hz; 0.5 s of line before the burst, seed 4
== Part 3  front end, Part 3's loop: 10.10 s of audio -> 24232 symbols
           through the body, against the transmitter's grid: 0.04 samples off the symbol peaks, in step with every symbol
== Part 4  acquisition, with the phase search on (it moved the loop 0 times): 600 bps, long interleave
           read at symbol 3116: countdown 19, correlation 0.966, carrier +37.7 Hz
           preamble from symbol 1196, body from symbol 12716 (the bench: 1196 and 12716)
           committed at symbol 1676: the phase search off, the rate integrator tracking
           the clock: the integrator learned 0 ppm through the body
           through the body, against the transmitter's grid: 0.04 samples off the symbol peaks, in step with every symbol
== next: the first path (Part 5)

That is the line from Steps 4 and 6: the same message, noise and seed, so the same burst. Step 6 showed the first segment through the gates, with countdown 23; the runner shows what acquire_body_preamble() returns, the group's best-correlated segment, here the fifth, with countdown 19. Both put the preamble at symbol 1196 and the body at 12716, where the bench's own answer puts them.

The runner runs the front end three times over the audio, once for each way a receiver can run it. The Part 3 line is Part 3's loop and nothing else. Acquisition runs on the front end with the phase search on, the way a receiver runs it while it looks for a preamble. Then the runner commits at the first candidate, a segment into the preamble: from there the search is off and the rate integrator tracks, the way a receiver listening live would have run it from that point. (A live receiver does all of that in one pass; the runner has the whole recording, so it finds the candidate first and then runs the front end again.)

Give the transmitter's clock a 1000 ppm error and the two loops part:

./build/runner "Hi" --snr 20 --clock 1000

== Part 3  front end, Part 3's loop: 10.09 s of audio -> 24210 symbols
           through the body, against the transmitter's grid: the loop slipped 11 symbols, net 11 lost
== Part 4  acquisition, with the phase search on (it moved the loop 0 times): 600 bps, long interleave
           ...
           committed at symbol 1675: the phase search off, the rate integrator tracking
           the clock: the integrator learned +1000 ppm through the body
           through the body, against the transmitter's grid: 0.04 samples off the symbol peaks, in step with every symbol

Part 3's loop slips 11 symbols through the 4.8 s body, every one a symbol stepped over, about what the clock drifts across it, as Step 12's type-1 row does on 2400L. (The runner counts every slip, either way, and gives the net beside it, so a slip one way and one back cannot pass for a loop in step.) With the integrator tracking from the commit, the loop learns the clock and stays on the peaks. Try --fade 2,1 for two-path fading, --mode 2400S, or a message of your own; --help lists the rest.

The runner also reads a WAV file, 48 kHz, 16-bit or float. --save heard.wav writes the audio it hands the receiver, and --wav heard.wav runs the receive stages on it; a recording of a real transmission works the same way, with no bench answer to compare against. tests/runner_tests.cpp checks the chain: the WAV file out and back in, the walkthrough's burst found where the bench put it, a 1000 ppm clock learned, the slip count on a trace that slips one way and back, and a saved recording read back to the same burst.

Go read the code, and the standard

Table XVI lists the two-bit count values in an order that does not match the rule in the text of 5.3.2.3.7.2.1 ("adding a '1' before the two-bit value"). Which reading does characterize_body_candidate() follow, and how does the note's example, 23 sent as 5, 5, 7, decide it?
The prefix is the same at the start of every segment because the sync randomizer's sequence is 32 long. What would a receiver have to do if a segment were not a whole number of its periods?
Work out the block correlation's floor with no match: nine blocks of 32 random unit products, magnitudes added, normalized as body_prefix_correlation() does. Then work it out for one sum of 288.
The carrier estimate wraps at 1200 Hz. Add 2500 Hz to Step 5's list: what does it print, and why?
A receiver hears a long-interleave segment with countdown 10 at symbol 9000 of its recording. Where does the body start, and where did the preamble start?
The channel-symbol decode compares the eight patterns by magnitude. What would comparing the real part need that the decoder does not have?
Why does a consensus group's representative have to be its best-correlated member, and not its first?
vote_mode_and_boundary() needs two segments to agree before it overrules the winner. What could go wrong with one?
Find the D1, D2 combinations recognize_body_designators() treats as recognized but not implemented. Which does the standard reserve, and which is a mode?
Set the walkthrough's floor to 0.25 and run Step 10 again. What gets through the first two gates now, and what stops it?
Run Step 9 at -8 dB. How many segments read right on their own, and does acquisition still find the burst?
Work out the type-1 loop's offset at 100 ppm from the drift and the gain, and compare it with Step 12. What sets the slope that turns the gain into samples?
Step 13: at 4 dB the integrator is still hundreds of ppm off after 2880 symbols, with the same gains as at 20 dB. Look at what the timing error is divided by, and explain why noise slows the loop down.
Why must the integrator be held at zero while the receiver searches? Run the type-2 loop through Step 10's ten seconds of noise and watch timing_rate().
Step 14 takes the mean from 5 s, not from the first candidate. What would the first 5 s add to the mean at 4 dB, and to the judgement?
The phase search moves the loop only after two windows in a row read more energy off time. Change it to one, and run Step 11 at 4 dB: what does a loop already on the peaks do now?
Table 10.1's fading conditions run for at least five hours. Roughly how many fades of a 1 Hz fading bandwidth is that, and why does a fading test need so many more bits than a non-fading one?

Next week: the first path. On a two-path channel, each path delivers its own copy of the preamble, a few symbols apart, and each copy forms its own group. When the two paths are of similar strength, the strongest group is often the later one, the echo, and an equalizer that starts on the echo cannot reach the path in front of it. Earliest-path anchoring finds the first copy, even when it faded through the segments the scan saw first, and moves the anchor to it.

The audio front end: finding the symbols

P.R.Decker — Fri, 09 Oct 2026 19:10:25 +0000

Part 3 of "Building a MIL-STD-188-110 HF Modem in Modern C++." Start with the overview, Part 1, the rules I build by, or Part 2, the transmit chain. The code for this article is on GitHub: kg7hf/modem-core.

Part 2 ended with clean symbols on the air. The transmitter knew everything about its signal: the carrier, the symbol rate, and where every symbol starts. The receiver starts with none of that. It gets 48,000 audio samples a second and has to turn them back into symbols: one complex value per symbol, taken at the right instant. That is the job of the audio front end, the first stage of the receiver.

The standard says what a receiver has to achieve, not how it does it. Everything in this article is an implementation choice, so for each one I show what the code does, why, and the step of the demo that shows it running.

Part 2 had tx_demo to walk its message through the transmitter; this article has front_end_demo. Build it, run it, and keep its output open beside this article, the way Part 2 asked you to keep tx_demo's:

./build/front_end_demo

It runs nine steps in the order this article takes them, and every number below comes out of one of them. Each step is a function in tests/walkthrough/front_end_steps.cpp that main() calls by name, and each section below names its step. So the best way to read a section is in the debugger: in VS Code, press F5 and choose front_end_demo (gdb). It stops at the top of main(); step into each step in turn, or set a breakpoint in the function for the section you are reading and continue to it.

Step	Function	Section
1	`carrier_table()`	Mixing down to baseband
2	`tone_mix()`	Mixing down to baseband
3	`tribit6_mix()`	Mixing down to baseband
4	`receive_filter()`, `pulse_neighbors()`	The matched filter
5	`timing_error()`	Finding the sampling instant
6	`float_position()`	Keeping time for hours
7	`block_sizes()`	Any block size, the same symbols
8	`carrier_tracking()`	Carrier tracking, part one
9	`walk()`	Walk the symbols back out

This article also starts the repository's unit tests, and they call the same nine functions: tests/front_end_tests.cpp runs each step and checks what it returned. So the walkthrough you read is also under automated regression. ctest runs it all, and the Testing panel in VS Code runs or debugs any one test.

Four jobs

The front end does four things, in order:

Mix down. Move the signal from the 1800 Hz carrier to 0 Hz, so each symbol becomes a plain complex number.
Filter. Run a matched filter, the receive-side counterpart of the transmitter's pulse shaping, to get the best signal-to-noise ratio at each symbol instant.
Find the sampling instant. Work out where in the stream of filtered samples each symbol is best read.
Keep it there. Track that instant as it moves, for as long as the signal lasts.

A fifth job, removing what is left of the carrier's phase and frequency, starts here and finishes in the equalizer.

Mixing down to baseband

The audio is real: one number per sample. The symbols are complex: a phase on the 1800 Hz carrier. To get them back, the front end multiplies each sample by a phasor that turns at minus 1800 Hz. The signal lands at 0 Hz, along with a copy at 3600 Hz that the matched filter removes. The product is doubled because a real signal carries half its energy at plus 1800 Hz and half at minus 1800 Hz, and the mix keeps only one half.

The phasor comes from a table. At 48,000 samples a second, 1800 Hz turns 3/80 of a cycle per sample, 13.5 degrees, so after 80 samples it has made exactly three cycles and starts over. Eighty constants hold the whole carrier, and the mixer reads entry n mod 80 for sample n. It keeps that index as a counter that wraps at 80, because a remainder of the 64-bit sample count would be a library call on a part with no 64-bit divider. Nothing about the carrier is computed while the modem runs, so nothing about it can drift, however long the audio lasts.

Step 1, carrier_table(), walks the table. It compares every entry with the exact phasor and prints the first few entries and the quadrants; its test checks that every entry is within half a float step of exact, and that the four quadrant entries are exact:

  n   phase (deg)      cos        sin
  0        0.0   +1.000000  +0.000000
  1       13.5   +0.972370  +0.233445
  2       27.0   +0.891007  +0.453990
  3       40.5   +0.760406  +0.649448
  4       54.0   +0.587785  +0.809017
  5       67.5   +0.382683  +0.923880
  6       81.0   +0.156434  +0.987688
  7       94.5   -0.078459  +0.996917
 20      270.0   +0.000000  -1.000000
 40      180.0   -1.000000  +0.000000
 60       90.0   +0.000000  +1.000000

Step 2, tone_mix(), feeds the front end a pure 1800 Hz tone, and a constant comes out: 2.2505, symbol after symbol. A tone at 1810 Hz comes out turning by 0.026179 radians per symbol, which is 10 Hz at 2400 symbols per second, with a faint ripple from the mix's mirror image near 3600 Hz, far down the filter's stopband.

Then a real symbol. Part 2 ended on the randomizer's sixth value, 6, and its worked symbol was tribit 6, at 270 degrees; in the "Hi" burst they meet at body symbol 5. Step 3, tribit6_mix(), prints the audio around that symbol's peak, the carrier's phase at each sample, and what the mix makes of it:

   sample     audio   carrier (deg)   mixed I   mixed Q
   230496   -0.2831          216.0   +0.4580   -0.3328
   230497   -0.4058          229.5   +0.5270   -0.6171
   230498   -0.5029          243.0   +0.4566   -0.8961
   230499   -0.5652          256.5   +0.2639   -1.0991
   230500   -0.5872          270.0   -0.0000   -1.1744
   230501   -0.5693          283.5   -0.2658   -1.1072
   230502   -0.5165          297.0   -0.4689   -0.9203
   230503   -0.4360          310.5   -0.5664   -0.6631
   230504   -0.3384          324.0   -0.5476   -0.3979
after the matched filter: on-time (-0.016, -2.391), 269.6 degrees, tribit 6

One mixed sample is not the symbol. It is a real number times the mixing phasor, so it can only point along that phasor, one way or the other; put another way, it is the symbol plus a copy of it turning the other way at 3600 Hz, 27 degrees a sample. At the peak, sample 230,500, the two line up and the mixed sample points straight down. On either side the copy swings it left and right. The matched filter averages over many samples, the turning copy cancels, and what comes out is (-0.016, -2.391): 269.6 degrees, tribit 6. Set a breakpoint in tribit6_mix() and step through it; the numbers are the ones above.

The compiler changed the math

At the end of Part 2 I promised to explain why the transmitter's audio can differ in the last bit between two builds of the same source, even though every symbol matches.

The transmitter computed the carrier's cosine and sine for every sample. With optimization on, GCC noticed that the code asked for the cosine and the sine of the same angle and replaced the two calls with one sincos call. On the toolchain I measured, that function rounds a few results differently in the last bit. The symbols are integers, so they never change; the float audio does, by a tiny fraction of the smallest step a 16-bit sample can show.

IEEE 754, the standard for float arithmetic, requires addition, subtraction, multiplication, division and square root to be correctly rounded, so they give the same bits on every machine that follows it. Sine and cosine have no such requirement. Each library computes them its own way, and the compiler can swap one call for another. No build setting controls that across every library, so the fix is to stop calling them where it matters. Two changes do it, and both are in the code now:

The carrier table above, in the transmitter and in the receiver's mixer.
The build forbids the compiler to fuse a multiply and an add into one instruction (-ffp-contract=off), because a fused result is rounded once instead of twice, and whether it fuses depends on the compiler and the target.

Measuring the change turned up a bigger effect than the one I went looking for. The old transmitter kept the carrier's phase in a float and added one step to it for every sample. Each addition rounds, and the rounding piles up: by sample 458,610, near the end of the "Hi" burst, the phase had walked about 1.4 degrees from where it belonged. The symbols still came out right, because the receiver tracks the carrier, but it is the same story as the timing position later in this article: a float that keeps adding walks off. With the table there is no running sum to walk.

What is left is plain arithmetic, and a new library cannot change a result it never computes. On Linux, with GCC and Clang, in Debug and Release, all four builds now produce the same audio, bit for bit, and the same symbols as before. I have not checked Windows yet, and the filter taps are still computed with the library's cosine when the modem starts, so a different library can still move the last bit of a tap. Making the taps constants too is the next step, and then the golden test can check the whole audio instead of five decimal places.

The matched filter

The receiver filters with a root-raised-cosine pulse, the same family the transmitter shaped with: 161 taps, eight symbols long. Each symbol is spread across neighboring symbols on the air, and the filter is shaped so that, at each symbol's own instant, the neighbors add almost nothing.

Why the receive filter is wider than the transmit pulse

The transmitter shapes with a rolloff of 0.25; the receiver filters with 0.35. A matched filter is, strictly, the transmit pulse itself, so this is a mismatch, and nothing in the history records why: the code says only that it copies the filter of an earlier reference receiver. So I measured it both ways on the modem's own signal (a 2400 bps burst through the whole front end, five random seeds per condition, signal-to-noise measured in a 3 kHz band):

Signal-to-noise: almost no cost. The filter's peak response drops from 0.9997 to 0.9973, about 0.02 dB.
Interference between symbols: a real cost on a clean channel. With the matched 0.25 filter, the largest leftover at a neighboring symbol's instant is 50.5 dB below the peak; with 0.35 it is 43 dB below. On a clean burst the symbol error floor is -42.6 dB with 0.25 and -37.7 dB with 0.35. With noise added the gap shrinks to about a tenth of a dB at 20 dB signal-to-noise, and to nothing at 10 dB.
Timing: no measurable difference. The wider filter gives the timing detector a slightly stronger error signal, which shows as a slightly smaller standing offset under a 100 ppm clock error (0.74 against 0.79 samples), but the loop's jitter is the same within the noise.
Behind an equalizer: none. With noise or fading and an ideal equalizer after the front end, both filters leave the same symbol error, within 0.2 dB.

Step 4, receive_filter() and pulse_neighbors(), prints the filter and the first two of those numbers for both rolloffs: the transmit pulse through the receive filter, its peak, and the largest leftover at any other symbol's instant.

receive filter: 161 taps, energy 1.000000, peak 0.2450 at tap 80
transmit 0.25, receive 0.25: peak 0.9997, largest neighbor 0.00298 (50.5 dB below)
transmit 0.25, receive 0.35: peak 0.9973, largest neighbor 0.00706 (43.0 dB below)

On this evidence the wider filter buys nothing the rest of the receiver needs, and the matched one is cleaner. The modem keeps 0.35 for now: the receiver's conformance results were measured with it, and changing a filter the receiver was qualified with means qualifying it again first.

Computing only what is needed

The timing loop reads three points per symbol, and each point is interpolated between two filtered samples. So the front end runs the filter only at those six positions, not at all 20 samples of every symbol: 966 tap products per symbol instead of 3220.

The raw samples wait in a ring buffer of 1024 entries. The deepest read reaches 661 samples back, and a static_assert beside the ring checks that the buffer is at least that deep, so a change that outgrows it fails the build.

Finding the sampling instant

Each symbol has one best instant to read it: the peak of the filtered pulse. Between peaks the signal passes through transitions, where it carries little information about the symbol. At 20 samples per symbol, the peak can fall anywhere between two samples, so the loop keeps a fractional position and reads the filtered signal there by linear interpolation between the two nearest samples.

The loop decides where to read next with an early-late timing detector. At each symbol it reads three points: half a symbol early, on time, and half a symbol late. Then:

const auto timing_error = std::real((late - early) * std::conj(on_time));

If the late sample is stronger than the early one, the peak is ahead, and the loop moves later; if the early one is stronger, it moves earlier. Multiplying by the conjugate of the on-time sample makes the result independent of the carrier's phase, so the loop works before the carrier is tracked. The error is divided by the energy of the three samples, so a loud signal and a quiet one move the loop by the same amount, and the step is limited to a fifth of a sample per symbol. So the front end needs no gain control of its own. The stages after it do care about the level, and the receiver scales each burst's symbols to a set level before it hands them on.

Step 5, timing_error(), reads the receive pulse at those three points, with the on-time point on the peak and four samples either side of it:

on the peak +0.000000, 4 samples early +0.031043, 4 samples late -0.031043, early and turned by 1 rad +0.031043

Zero on the peak. Reading early, the error is positive, so the loop moves later; reading late, it is the same size with the other sign. And turning the carrier by a radian changes nothing.

The on-time sample is the symbol. The early sample goes along with it: two samples per symbol, which the equalizer uses in a later article.

Here's a sea story. Back in the day, when I arrived at US Navy boot camp, we learned to form up into a column, and we marched everywhere as a unit. You've probably seen movies where someone in the group, maybe the drill instructor or the company commander, is "calling cadence". Calling cadence was usually assigned each week as a special duty, a reward. The cadence is rhythmic, and it keeps everyone in sync: left, left, left right left. Then you can throw in some colorful rhymes. It keeps all the steps in sync, and when it doesn't, the column stumbles and falls out of formation, so keeping a good rhythm is important for marching. Well, I was awarded the job of calling cadence, and wow, was I excited. Unfortunately, my internal clock has a lot of jitter; one could say I don't have good rhythm. My cadence lasted about one day of lllleft, rrrright, rrright, leeft, all at random times, and everyone's feet were jumbled up trying to get onto the foot I was calling at the time. Needless to say, the formation lost sync and collapsed, and my day of calling cadence ended when I was replaced by a more stable oscillator.

A timing loop has the column's problem. Every symbol, the detector calls the beat, and noise makes some calls early and some late. If the loop jumped to each call, its samples would stumble the way my column did, so it moves only a fraction of what each call asks for, at most a fifth of a sample per symbol, and keeps a steady step through the noise. How steady it stays is its jitter, and jitter is where the two detectors below differ.

Early-late or Gardner

The overview called this Gardner symbol timing. The detector in the code is the early-late form. The two are related; here is how they differ.

Both are textbook detectors, and both multiply a difference by a third sample:

Early-late: the difference of the two samples half a symbol either side of this symbol, weighted by the on-time sample. It looks for the peak.
Gardner (Floyd Gardner, 1986): the difference of this symbol's on-time sample and the previous one, weighted by the sample halfway between them. It looks for the zero crossing between two symbols.

I measured both on the modem's own pulses. On average they behave the same: the same zero point, the same strength. Symbol by symbol they do not. Gardner's output is steadier: on a clean signal its spread is under half of early-late's, the gap narrows as noise rises, and by a 5 dB signal-to-noise ratio they are close. Gardner is also cheaper here, because the previous symbol's on-time sample is already computed: two interpolations per symbol instead of three.

On a dirty channel the difference does not show in the symbols. I ran both loops over the same transmitted bursts (2400 bps, long interleave) with five fixed random seeds per condition: noise at 20, 10 and 6 dB signal-to-noise in a 3 kHz band, a CW tone, impulse noise, a strong signal in the adjacent channel, two-path multipath, Watterson fading, and clock offsets. Wherever both loops held lock, Gardner's timing jitter was a quarter to a half lower, yet the symbol error came out within a few tenths of a dB either way. Interference cost both the same: a CW tone 10 dB below the signal cost nothing extra, and one as strong as the signal ruined both. Multipath and fading hurt through the echoes, which is the equalizer's job, and after an ideal equalizer the two were indistinguishable. (The test kit's fading model is not conformance-qualified, so those rows are engineering evidence, not conformance results.) At a 1000 ppm clock offset both lost lock: the limit there is the loop, not the detector, and that is next week's subject.

Why does the code use early-late, then? There was no decision. The loop arrived labelled "Gardner-style", and the label stayed until I checked the formula for this article. For now the modem keeps early-late. Its conformance results were measured with it, and the front end shows no symbol-quality reason to switch; if I do switch, it will be because the full receiver's conformance runs say so.

Keeping time for hours

The overview and Part 1 both mentioned a sample counter that walks off the grid after about twenty minutes. This is that story.

The timing loop's position is a sample count, and it grows for as long as the audio does. A float holds 24 bits of precision. Past 2^24 samples, about six minutes of audio, it can no longer hold the fraction of a sample the loop needs. Past 2^26 samples, about 23 minutes, it cannot even add the 20 samples of one symbol: 67,108,864 plus 20 comes out as 67,108,880, a step of 16. The loop slides four samples per symbol, and a long capture decoded at chance.

The whole-buffer version of the loop fixed it with a double position, which is exact for longer than anyone will record. The streaming front end, the one built for the microcontroller, splits the position into a whole number of samples (a 64-bit integer) and a fraction (a float between 0 and 1). The fraction keeps its full precision forever, and there is no double on the M33, where it would be emulated in software.

Step 6, float_position(), shows both:

float: 2^26 + 20 = 67108880.0; 2^24 + 20.5 = 16777236.0
whole + fraction: 67108885 + 0.0

And it holds over a long run. One test in the bench, "Thirty minutes of continuous traffic: still exact past 2^26 samples", sends 188 bursts through one front end, 86,630,400 samples, well past 2^26, and every decision in every burst comes out right. It takes a few seconds, so it runs only when asked for: ctest -L long.

Any block size, the same symbols

On a microcontroller the audio arrives in whatever blocks the DMA or the interrupt hands over. The streaming front end keeps all of its state between calls: the ring, the carrier table's index, the timing position. So the symbols do not depend on how the audio is cut up: feed it one sample at a time or 480 at a time, and the output is identical, bit for bit. The carrier index is part of that state for the same reason: it counts samples, not blocks.

Step 7, block_sizes(), checks it: the "Hi" burst goes through one front end 480 samples at a time and through another in blocks of 1, 7, 33, 160 and 480 samples in turn, and all 23,032 symbols come out identical, bit for bit.

Carrier tracking, part one

Two radios never agree exactly on 1800 Hz, and the path between them can shift it further. After the mix, that difference shows up as a slow rotation of every symbol. The carrier tracker removes it with a second-order loop:

It turns each incoming symbol back by its current phase estimate.
It measures the remaining angle against a decision, the constellation point the symbol should be.
It adds a fraction of that angle to its frequency estimate (the integral part), and steps its phase by the frequency plus another fraction of the angle (the proportional part).

The frequency estimate is limited to 0.1 pi radians per symbol, 120 Hz at 2400 symbols per second. The decisions it learns from come from the equalizer, in a later article.

Step 8, carrier_tracking(), uses the receiver's gains. Given symbols turned by a fixed 0.5 radians, it learns 0.5000; given symbols turning at 5 Hz, it learns 5.000 Hz, and each corrected symbol lands on its decision. It also calls a sine and cosine for every symbol (std::polar), the same kind of call the float section is about.

Walk the symbols back out

Part 2 walked the message "Hi" into the transmitter and ended with the body randomizer's first values: 0 2 4 3 3 6. The first symbols of the burst's body carry exactly those, so here they are coming back out of the front end. Step 9, walk(), prints them from the real code:

body  on-time I, Q       angle  tribit  sent  randomizer  tribit - randomizer  coded bit
   0   +2.369  +0.001     0.0       0     0           0                    0          0
   1   +0.014  +2.403    89.7       2     2           2                    0          0
   2   -2.409  -0.009   180.2       4     4           4                    0          0
   3   -1.731  +1.690   135.7       3     3           3                    0          0
   4   -1.661  +1.682   134.6       3     3           3                    0          0
   5   -0.016  -2.391   269.6       6     6           6                    0          0
 ...
  80   +1.687  -1.685   315.0       7     7           3                    4          1

Each on-time sample sits within a degree of one of the eight phases, at the same magnitude, about 2.4: the loop is on the symbol peaks. The nearest phase gives the tribit, and every one matches what the transmitter sent. Subtract the randomizer, the same sequence Part 2 added, and what is left is the BPSK data: tribit 0 for a coded 0, tribit 4 for a coded 1. The first six body symbols happen to carry coded zeros, so on the air they are the randomizer itself. The first coded 1 arrives at body symbol 80: it comes in as tribit 7, and taking away the randomizer's 3 leaves 4.

These coded bits are still in the interleaver's order, so they are not yet the bits of "H". Undoing the interleaver and the code is the work of later articles.

The test bench

This article is where the repository starts testing: at the receiver's first stage, so that each stage after it arrives with its own tests.

The framework is Catch2. It is an external test tool, kept as a git submodule in external/catch2 and fixed to one release by its commit, and it builds only for the tests, never into the modem. Like the modem, it builds without exceptions: a failed REQUIRE ends that test's process instead of throwing. CMake registers every test case as its own CTest test, so ctest runs them all, and VS Code's Testing panel lists each one to run or debug on its own. Clone the repository with --recurse-submodules, or run git submodule update --init once.

A test is built from three pieces in tests/support/:

A signal from the real transmitter (test_waveform). The Part 2 transmitter is the reference every receive stage is measured against, so it makes the test signals: a mode, a payload (given, or random from a seed so every run repeats) and any number of bursts, with what was sent kept beside the audio.
A channel (test_channel): white noise, a CW tone and two-path Watterson fading, all from fixed seeds. Signal-to-noise is set the way the standard measures it, signal power over the noise power in a 3 kHz band. White noise spreads evenly from 0 to 24 kHz, so a 3 kHz band holds one eighth of its power. The fading model is an engineering model, not a qualified simulator, so a result through it is engineering evidence, not a conformance result.
A scorer (front_end_harness). It runs audio through a front end in any block sizes, lines the symbols up with what was sent, finds where the loop locked, and counts the decisions that match after that.

The walkthrough steps are tests too: front_end_tests calls the functions front_end_demo calls and checks what they return. Around them are tests of whole bursts: "Hi" from start to finish, a train of random messages with gaps between them, white noise at 10 dB signal-to-noise, and a CW tone on the carrier 10 dB below the signal at 20 dB signal-to-noise. Two more run only when asked for. One is the thirty-minute run from "Keeping time for hours" (ctest -L long). The other only reports: through Watterson fading (2 ms, 1 Hz, 20 dB signal-to-noise) the front end alone gets most decisions wrong, because removing the echoes is the equalizer's job (ctest -L report).

What the short preamble showed

When I added a test for the short interleaver, it showed that a comment in the front end was wrong. The comment said the loop pulls in from any starting phase during the preamble. The 600S preamble is 1440 symbols, 0.6 seconds, and the test slides the "Hi" burst through every sample of one symbol period, so the loop starts at every phase it can meet. From 19 of the 20 starting phases it locks inside the preamble, by symbol 1000 at the latest, and every decision after that is right. Started exactly half a symbol off the symbol peaks, it locks only by symbol 2200, after the body has begun, on a clean signal and with white noise from 40 down to 10 dB signal-to-noise alike.

That start is the early-late detector's unstable zero. The early and late samples are equally strong there, the error is close to zero, and the loop barely moves until the data pushes it off; the textbook name is a hang-up. Gardner's detector has the same point, and so does every timing detector, because its error repeats every symbol and has to cross zero twice. Started there, Gardner locked by symbol 1900: sooner, and still too late. The limit is how fast the loop pulls in: nine samples off the peak, either detector takes 1000 symbols to lock.

The fix belongs with the receiver's conformance testing, later in the series, so for now the limit is documented, and I corrected the comment. The half-symbol start has its own test, tagged [!shouldfail]. Catch2 counts its failure as expected, so the suite stays green; when the limit is fixed, that test's pass is reported as a failure, and the tag comes off. Until then the limit sits in the test list, where anyone who runs the tests sees it.

Part 2, retrofitted

Part 2's transmitter had tx_demo and two golden tests, which check every transmitted symbol against a saved snapshot and the first samples of the waveform. It now has unit tests as well, in tests/transmit_chain_tests.cpp, following that article's sections: the plan, the FEC, each rate's block plan, the interleaver, the Gray map, the randomizer, the carrier and the walk. Every number Part 2 quotes came out of them unchanged.

One sentence needed correcting. Part 2 said each input bit "influences seven coded pairs, fourteen coded bits". The bit stays in the encoder for seven pairs, but each generator, 133 and 171 octal, has five taps, so ten of those fourteen coded bits depend on it; in the fifth pair, neither coded bit does. Part 2 now says so.

Go read the code, and the standard

The mix doubles each product. Why? (A real cosine is the sum of two phasors.)
The ring buffer holds 1024 samples. Find the static_assert beside it and work out how many the code actually needs, and why.
Feed the matched filter a single impulse. What comes out, and why?
The timing detector multiplies by the conjugate of the on-time sample. What would happen without the conjugate while the carrier phase rotates?
In float, add 20 to 67,108,864. What do you get, and what does that do to a timing loop 23 minutes into a recording?
The mixer's carrier index wraps at 80 instead of taking the sample count mod 80. Why not just use % on the 64-bit count? (Look up what a 64-bit division costs on a Cortex-M33.)
Work out the filter's cost per symbol if it ran at every sample, against running it only where the loop reads.
Step 5, timing_error(), reads the early-late detector on the receive pulse. Write Gardner's detector next to it and run both on the same pulse. Where do they agree, and how many interpolated samples does each need per symbol? Then put it in the loop in place of the early-late error and run the 600S tests. Does Gardner escape the half-symbol start? Why does every timing detector have a point like that?
Step 4, pulse_neighbors(), prints the leftover at the neighboring symbols for a receive rolloff of 0.25 and of 0.35. Why is the 0.25 leftover smaller, and what would you have to check before switching a qualified receiver to it?
MIL-STD-188-110B holds the 1800 Hz carrier to within 1 Hz (paragraph 5.3.2.3.9) and every signaling rate to within 0.01 percent of nominal (paragraph 4.2.1). Put two modems at opposite ends of those limits: how far apart can their carriers be, and their symbol clocks, in parts per million? Compare that with the carrier tracker's limit of 0.1 pi radians per symbol, and with the timing loop's standing offset at 100 ppm. Then find what else in a real link moves the frequency further than the modems do.
Run front_end_tests and find the [!shouldfail] case. What does Catch2 print for it, and why does ctest still pass? What has to happen before the tag can come off?

Next week: acquisition. This week's loop tracks a symbol instant it has been handed; acquisition finds a burst in noise, reads the mode from its countdown, and tells the receiver where the body starts.

There is also one thing this week's loop cannot do. Two sample clocks never agree exactly, so part of the timing error is steady. At a 100 ppm clock offset the loop sits 0.74 samples off the eye, and at 1000 ppm it loses lock altogether (20 dB signal-to-noise). A proportional loop can only make a steady correction from a steady error, so it sits off the eye by the drift divided by its gain, and at 1000 ppm the offset it would need is past the peak of the detector's output. The fix is a second loop with an integrator, the same structure as the carrier tracker's, and next week I measure what it fixes and what it costs.

The transmit chain: the easy half, done right

P.R.Decker — Sun, 04 Oct 2026 00:49:40 +0000

Part 2 of "Building a MIL-STD-188-110 HF Modem in Modern C++." Start with the overview, or Part 1, the rules I build by. The code for this article is on GitHub: kg7hf/modem-core.

At the end of Part 1 I called the transmitter the easy half. Encoding is deterministic, there is no channel to undo, and the standard spells out every step. I still hold it to the same discipline as the receiver.

A transmitter error can pass every test you run. Get one bit order backwards, seed a scrambler one tap wrong, or number the interleaver rows the way that felt natural instead of the way the standard wrote them, and the waveform still looks fine on a scope and still decodes perfectly... in your own receiver, which makes the same mistake. Only another vendor's modem shows the error, and by then it is on the air.

The best-known case of this kind of error is NASA's Mars Climate Orbiter. The interface specification called for thruster impulse in newton-seconds, but the contractor's ground software wrote it in pound-force seconds, and NASA's navigation software read those numbers as newton-seconds. Each program was consistent with itself; the mismatch showed only where the two met, and in 1999 the spacecraft was lost as it arrived at Mars. Part 1's unit types catch that kind of mismatch inside one program. Between two programs built by different teams, the specification is the only shared reference, so on the transmit side I follow it exactly, not my instincts.

The transmitter is also the reference for everything that follows. The whole receiver, all nine stages, is tested against output from this side; the golden vectors that gate every build are transmit output, decoded and compared. A subtle transmitter error would carry into every receiver result measured against it.

Here's a story from my childhood. When I was very young, my dad had a professional furniture repair shop. One day I was at his shop causing kid trouble, and he had had enough, so he wanted me to cut some wire to a specific length. He cut the first one, then showed me how to measure the next one with it; I was likely so young I couldn't even read a measuring tool. So piece by piece I cut, measured with the last one I cut, cut again, measured with the last one I cut... The astute reader can see where this is going. After some time, the wires I was cutting were getting longer and longer each time; little by little they were drifting, because of cumulative measurement errors, until I had pieces that were extraordinarily long.

Each piece was measured against the one before it, so each small error carried into the next and added up. That is why the transmitter has golden tests: every build is checked against the same saved snapshot of its output, so errors cannot add up from one build to the next.

The chain takes a few user bytes to an 1800 Hz waveform. It is linear, each stage feeding the next with no feedback, which is the other reason it is the easy half.

The waveform is a family of modes, from 75 bps to 4800 bps. They share this chain and differ mainly in how much redundancy they add. I follow one mode the whole way down: 600 bps with the long interleaver, "600L." It is the mode I use most: slow enough to survive a rough NVIS path, fast enough for real traffic, and coded and interleaved enough to exercise every stage of the chain. Where another rate does something different, the 75 bps Walsh mode above all, I say so. I take it a stage at a time, then walk a two-character message through the whole chain in 600L.

Plan the whole burst before you move a bit

Part 1's first rule was no heap on the hot path: the signal path allocates nothing while it runs. So the transmitter does all of its sizing up front. Before a single bit is encoded, body_transmission_plan sizes the entire transmission: the countdown preamble, the coded body blocks, the end-of-message marker, the coder flush, and the padding that squares off the final interleaver matrix. It returns a plan, not a buffer.

struct BodyTransmissionPlan
{
    BodyBlockPlan block{};
    std::size_t    payload_bits{};
    std::size_t    framed_bits{};
    std::size_t    body_blocks{};
    std::size_t    preamble_symbols{};
    std::size_t    transmitted_symbols{};
    std::size_t    audio_samples{};
};

[[nodiscard]] Result<BodyTransmissionPlan>
body_transmission_plan(BodyMode mode, std::size_t payload_bytes) noexcept;

The render step then takes that plan, the payload, and a BodyTransmissionScratch of caller-owned work buffers, and writes the audio without touching the heap:

[[nodiscard]] Status
generate_body_transmission_audio(const BodyTransmissionPlan& plan,
                                 std::span<const std::uint8_t> payload,
                                 BodyTransmissionScratch scratch,
                                 MutableSampleSpan audio) noexcept;

Every buffer the pipeline needs (the framed bits, the coded bits, the interleaver matrix, the interleaved bits, the transmitted tribits) is a span the caller prepared, sized from the plan. On a microcontroller, that is what lets you prove the transmit path never runs out of memory. Errors are Part 1's error values: a request the plan cannot size comes back as a failed Result, and buffers that do not match the plan come back from the render as a Status, both before any audio is written.

The FEC: spend bits to buy survival

After framing comes forward error correction: the modem adds redundant bits so the receiver can correct errors. The serial-tone body uses a K=7, rate-1/2 convolutional code, the classic NASA-heritage code with generator polynomials 133 and 171 in octal. Rate 1/2 means every input bit produces two coded bits; K=7 means the encoder remembers six previous bits, so each output depends on the last seven inputs. That overlap lets a decoder correct errors that a code without memory could not.

In code the encoder is a tiny state machine. You push one bit and get back the pair of coded bits it produced, T1 then T2, which is the order the standard serializes them and the order the receiver has to expect:

struct EncodedPair { std::uint8_t t1{}; std::uint8_t t2{}; };

class ConvolutionalEncoderK7
{
public:
    explicit constexpr ConvolutionalEncoderK7(std::uint8_t initial_state = 0U) noexcept;
    [[nodiscard]] EncodedPair push(std::uint8_t bit) noexcept;   // generators 133/171 octal
    // ...
};

The T1-before-T2 order has to match on both ends, so it is documented in the encoder's source, and the golden test, which checks every transmitted symbol against a saved snapshot, fails if the order ever flips. The lower rates add more redundancy on top of the code, which is the next stage.

Repetition and Walsh: more redundancy, lower rates

The rate-1/2 code alone carries 600, 1200, or 2400 bits per second of user data over the 2400 symbol-per-second channel, depending on how many bits each symbol carries. The lower rates add repetition. At 300 and 150 bps the coded bits are repeated, so the receiver can combine several noisy copies into one decision; the encoder provides this as encode_repeated_pairs. At 75 bps the modem switches to Walsh orthogonal spreading, giving up almost all of its throughput for a signal that survives conditions the coded rates cannot. At the top, 4800 bps is uncoded: no convolutional code at all, so it has no error protection and depends entirely on the equalizer. (The tail-biting punctured variant you will also find in the encoder belongs to the 110B high-rate waveforms, a different family.) So the mode selects one of four options: the plain code, repetition, Walsh spreading, or no code.

Interleaving: scatter the damage

Fades on HF are bursty. A 200 ms null wipes out a long run of consecutive bits, more than the code can correct. So between coding and modulation a block interleaver scatters the bits in time: a 0.6 second "short" matrix or a 4.8 second "long" one. The coded bits are written into the matrix one way and read out another, so bits that were neighbors in the code end up spread across the interleaver span on the air. A fade then damages a few bits in many places instead of a long run in one place, and the code corrects scattered errors well. The longer the span, the longer the fade it can break up. The cost is latency: 4.8 seconds for the long interleaver.

Bits to symbols: the constellation and a Gray map

Next the coded bits become points on the constellation. Every mode sends 2400 symbols per second on the same 1800 Hz carrier; the data rate changes how many bits each symbol carries. The fast modes use the full 8-PSK circle, three bits per symbol; 1200 bps uses QPSK, two bits; and 600L uses BPSK, one bit per symbol, two points on opposite sides of the circle. Fewer points sit farther apart, so it takes more noise to turn one into another.

The mapping from bits to phase is Gray-coded on purpose: adjacent constellation points differ by exactly one bit, so when noise nudges a symbol into its neighbor, the receiver's most likely error, only one bit flips instead of several. All of it comes from one shared function, modified_gray_decode, read the same way by the transmitter and both demappers, with a small table for each width:

// MIL-STD-188-110B body-waveform modified-Gray mapping.
// width 3 (8-PSK): the full table.  width 1 (BPSK, 600L): bit 0 -> 0, bit 1 -> 4.
constexpr std::array<std::uint8_t, 8> map{0U, 1U, 3U, 2U, 7U, 6U, 4U, 5U};

So in 600L a coded 0 becomes tribit 0, the point at 0 degrees, and a coded 1 becomes tribit 4, the point at 180 degrees. A mistake in this mapping goes out on the air, so the table lives in one place instead of being retyped wherever a symbol is formed, and a static_assert locks its derived cases.

(The 75 bps mode is the exception: instead of mapping coded bits to single symbols, it sends each pair of coded bits as a 32-symbol Walsh sequence. It rejoins the chain at the scrambler.)

Probes and the countdown preamble

A receiver cannot equalize a channel it cannot measure, so the transmitter inserts known symbols into the stream. These probe symbols are values the receiver can predict exactly; it uses them to keep estimating the channel as it changes. The equalizer, in a later article, depends on them.

And the whole burst opens with the countdown preamble. It does two jobs. It announces the mode, so a receiver that had no idea what was coming learns the rate, the interleaver length, everything it needs to configure itself. And it counts down to the data, so a receiver that wakes up in the middle of the preamble, which on a low-power part listening for activity is the normal case, knows exactly how many symbols remain until the payload begins. That countdown is what lets the Cortex-M33 from the overview sleep through dead air and still catch the start of a message. Finding the preamble in noise is the receiver's job, in Part 4.

Scrambling: whiten it, and exactly

The last step before the carrier is the scrambler, and it has to match the standard exactly. Long runs of identical symbols are bad for a receiver's timing and carrier recovery and bad for the transmitter's spectrum, so the modem adds a known pseudo-random sequence to whiten them. By now the data is tribits on an 8-PSK ring, so the scramble is modular addition on the ring, not an exclusive-or:

// (tribit + randomizer) mod 8, on the 8-PSK ring
[[nodiscard]] constexpr std::uint8_t tribit_add(unsigned tribit, unsigned randomizer) noexcept
{
    return low_bits<3>(tribit + randomizer);
}

The randomizer itself is a linear-feedback shift register (BodyDataRandomizer), and it whitens every body symbol, data and probes alike; the preamble gets its own fixed sequence (SyncRandomizer), the one the receiver correlates against. Every part of the system that has to agree on these sequences, the transmit mapper, the probe generator, the receiver's reference, adds the randomizer the same way through this one function. That is DRY, from Part 1's list, applied to the standard: there is exactly one definition of adding the randomizer, so the transmitter and the receiver cannot disagree about it.

Turning symbols into 1800 Hz

Pulse shaping and modulation are the only real signal processing on the transmit side. Each symbol, whichever part of the constellation the rate uses, is a phase on a single 1800 Hz carrier, at 2400 symbols per second. To keep it from splattering into the neighboring spectrum, each symbol is shaped with a square-root raised-cosine pulse; the receiver filters with the same family of pulse. The carrier itself is a phase that advances a fixed step per sample:

// Carrier phase advance per sample: (two_pi * f) / fs, in Real, in the shipped order.
template <HertzSource F> [[nodiscard]] constexpr Real radians_per_sample(F carrier, SampleRate sample_rate) noexcept
{
    return two_pi * static_cast<Real>(carrier.hertz()) / sample_rate.hertz_real();
}

// The carrier-step check: the exact float the shipped code produced for the body carrier.
static_assert(std::bit_cast<std::uint32_t>(radians_per_sample(Frequency{1800.0, Hz}, SampleRate{48000U})) == 0x3E714639U);

Several of Part 1's rules show up in that one return statement. The carrier and the sample rate are unit types, not bare numbers, so passing a sample rate where the carrier belongs does not compile. The arithmetic stays in the single Real type, so nothing promotes to a software-emulated double on the M33. The operation order is fixed, two_pi * f then divide, so the value is bit-for-bit the same on every build, and the static_assert locks that float to its bit pattern at compile time. Every sample the transmitter emits uses this step, so a one-bit change here changes the whole waveform. The modulator renders straight into the caller's audio span without allocating, so the same code can write a WAV file on a PC or feed a DAC on the microcontroller.

Walk a message through it

Here is the two-character message "Hi" pushed through the chain in 600L. Every value below is what the code actually produces, not an illustration; I ran the real encoder and modulator stages and copied the numbers out, and tx_demo in the repository prints the bit-level ones.

The transmitter takes user octets least-significant bit first. The byte for 'H' is 0x48, so it enters the encoder as the bit sequence:

'H' = 0x48 -> 0 0 0 1 0 0 1 0

Those bits feed the K=7 encoder one at a time, and each one comes back as a coded pair, t1 then t2. Starting from the all-zero state, the eight bits of 'H' produce:

input bit:  0    0    0    1    0    0    1    0
coded pair: 00   00   00   11   01   11   00   01

Look at the fourth column. The input bit there is the first 1 in 'H', and both coded bits change. The encoder's memory then affects the pairs after it, even where the inputs are 0 again. Each input bit influences seven coded pairs, fourteen coded bits, which is what lets the receiver recover it after the channel corrupts some of them.

Because 600L is BPSK, each coded bit becomes one symbol on its own; there is no gathering into threes. A coded 0 maps to tribit 0 and a coded 1 maps to tribit 4, the two points at 0 and 180 degrees:

coded bit 0 -> tribit 0  (0 degrees)
coded bit 1 -> tribit 4  (180 degrees)

Interleaving sits between the code and this mapping, and it is the one stage a single-message trace cannot really show on paper: it scatters the coded bits across the whole 4.8 s long-interleaver span, so two bits that were neighbors above end up hundreds of milliseconds apart on the air, and a fade that would have wiped out a run of them instead leaves isolated errors scattered across the codeword.

Last, the scrambler adds its known sequence on the ring before the symbol reaches the carrier. The body randomizer's first tribits are:

0  2  4  3  3  6 ...

Take a coded 1: it maps to tribit 4, and with a randomizer value of 2 it becomes (4 + 2) mod 8 = 6. That is the tribit that goes out on the air, at 6 x 45 = 270 degrees. BPSK only produces tribit 0 or 4, two phases, but after the randomizer is added the transmitted symbols land on all eight, so the spectrum looks full and random even though the data is two-level. The receiver runs the same randomizer, subtracts the same 2, recovers tribit 4, and reads it as a 1. The sequence is known to both ends; it only looks random on the air.

The transmitted tribit is a phase. The modulator turns tribit 6 into a point on the 8-PSK circle, psk8_symbol(6), the unit vector at 6 x 45 = 270 degrees:

tribit 6 -> I = cos(270) = 0.000,  Q = sin(270) = -1.000   (magnitude 1)

Then the point modulates the carrier. Each output sample advances the carrier phase by the fixed step the static_assert locks, 2*pi*1800/48000 = 0.2356194 radians, which is 13.5 degrees per sample; at 48 kHz one full cycle of the 1800 Hz tone is about 26.7 samples, and each symbol occupies 20 of them. The audio sample is the real part of the symbol rotated by that phase, scaled for headroom:

audio[n] = scale * Re{ symbol * exp(j * carrier_phase[n]) }

To see it, hold tribit 6 steady and the modulator emits a clean 1800 Hz sinusoid sitting at that 270-degree offset. These are eight consecutive samples the modem actually produces, climbing to a crest and turning over:

n=241  n=242  n=243  n=244  n=245  n=246  n=247  n=248
0.126  0.244  0.349  0.435  0.497  0.531  0.536  0.511

That is the 1800 Hz carrier, one sample every 13.5 degrees, with its amplitude kept under the 0.98 no-clip limit the modulator derives from its own pulse. In live traffic the phase changes every 20 samples as the tribits change (for 600L the data only ever picks tribit 0 or tribit 4, and the randomizer spreads those picks across all eight phases), and the square-root raised-cosine pulse smooths each change so the burst stays inside its band.

Every value here is deterministic, reproducible, and defined in exactly one place, so a receiver that does each step in reverse, mine or an independent one, gets back the bytes "Hi".

Why the easy half gets the same rigor

The transmit chain is short: plan, encode, repeat, interleave, map or spread, probe, scramble, shape. None of it is hard the way undoing a fading channel is hard. But at every stage a detail the standard fixes can be subtly wrong in a way that testing against your own receiver never reveals, because your receiver shares the mistake. So I treat the transmitter as ground truth. Its output is the reference the whole receiver is measured against, and it is what an independent implementation has to decode. It has to be exactly right for anyone else to talk to you, which means building it once, carefully, from the specification, and keeping it from drifting.

Go read the code, and the standard

The core skill in this work is reading a specification and confirming that the code does what it says. The code is on GitHub at kg7hf/modem-core, and its start-here page maps it stage by stage. MIL-STD-188-110 is public (pull it from EverySpec or the DoD's ASSIST site). It is written in "shall" statements, with the exact numbers in its tables and figures. Several of the questions below have you open the standard and the source side by side, find a requirement, and check that the code meets it. That is most of the daily work in mission-critical engineering.

What carrier frequency and symbol rate does this waveform use, and where are they set? One search; they are named constants, not magic numbers.
The standard gives the K=7 code's generator polynomials in octal: 133 and 171. The code stores them as 0x6D and 0x4F. Convert 133 and 171 to hex yourself; you will get 0x5B and 0x79, which do not match. Work out what the code did, and why. (Which end of the shift register feeds the taps?)
The end-of-message marker is a specific 32-bit word. Find it in the code (a single hex literal), then find where the standard specifies it, and check it bit for bit. Why would a wrong EOM word pass every one of your own tests and only surface when another vendor's modem reads your signal?
The body data randomizer is a 12-bit shift register. MIL-STD-188-110B Figure 6 draws it, including the value it is loaded with at the start of every burst; the code even cites the page. Find the initial load in the code and confirm it against the figure. (Write 0xBAD in binary and compare it with the figure.)
The 8-PSK modified-Gray mapping is a table in the standard (MIL-STD-188-110B section 5.3.2.3.6, Tables XII and XIII). The code carries it as an eight-entry array. Rebuild the table from the standard, check every entry against the array, then confirm the one-bit-between-neighbors property the Gray code is there to provide.
600L uses BPSK, one bit per symbol; 2400 bps uses full 8-PSK, three. Find the single place that decides how many bits each symbol carries, and tie 600, 1200, and 2400 bps each back to the modulation the standard calls for at that rate.
The interleaver is a rows-by-columns matrix: you load it one way and read it another. Find the matrix geometry in the code, match it against the dimensions the standard gives for the 4.8 second interleaver, and work out how far apart on the air two bits that were neighbors going in end up.
A receiver cannot equalize a channel it cannot measure. Find where the transmitter builds the countdown preamble and inserts probe symbols into the data. What is the countdown counting down to, and why does a battery-powered receiver need it?
The article claims the signal path allocates nothing. Do not take my word for it: start at generate_body_transmission_audio and prove it. Show every buffer came from the caller, find the one place all the sizing is decided, and find the Result that rejects an impossible request before any work starts.
The transmitter is the reference the whole receiver is measured against, so its output has to be reproducible. The carrier step is (two_pi * f) / fs. Predict, in float, whether rewriting it as two_pi * (f / fs) changes a single output sample, before you test it. Then find one more place where the order of a floating-point operation is fixed on purpose, and say what a re-order would cost.
Build tx_demo in Debug and in Release, with GCC and with Clang, and compare the step 7 hash and the WAV files. The symbols match on every build. Do the samples? If they do not, find out why.

For those excited to see what the receiver looks like, the headers in the repository already declare a body decoder, a Viterbi decoder, a soft demapper, and a carrier tracker that it does not yet implement. Read their design notes and ask: from the transmitter alone, what is the first thing the receiver has to undo?

Next week I move to the receiver and start undoing the channel: the audio front end, matched filtering and symbol timing recovery, where the receiver first has to find where each symbol is. I'll also explain why this week's audio can differ in the last bit between two builds of the same source, even though every symbol matches.

The rules I build by

P.R.Decker — Sun, 27 Sep 2026 00:14:19 +0000

New here? Start with the overview.

Before the rules, a debt. These are not mine alone; they are the labor of a whole career, and every one of them was shaped by the engineers I have had the honor to work beside. Most of what I hold to here was taught to me, one code review and one hard-won bug and one patient explanation at a time. That is really the method, more than any single rule below: let your thinking evolve with every project and every review, keep what survives contact with the work, and let the rest go. They have changed as the standards and the tools changed, and they will keep changing. I set them down not as a decree but as what I have learned so far; if they are any good the credit is shared, and if they are still improving, that is rather the point. Special thanks to Brian, Jim, Erik, Patty, Dan, Glenn, Ken, and the many others I have worked beside over the years, who formulated and crafted these ideas with me.

In the overview I said the whole modem has to run on a microcontroller, not just a workstation, and that one constraint shaped every line of it. This installment is that constraint, spelled out: the rules I hold myself to, and why I think they make the code both safer and faster than the C it is so often assumed to be slower than.

These aren't modem rules, or even embedded rules; I hold every project to them, and that consistency is the point. Apply the same discipline everywhere and two things compound. You get better at writing it right the first time, so the gap between "it works" and "it's right" keeps shrinking. And the reach-back gets cheap: that genuinely useful function you wrote eight months ago drops into the new project with far less rework, because it already speaks the same types, returns errors the same way, and owns nothing it shouldn't. Discipline you practice everywhere is discipline that pays you back.

Here is the shape of it before the detail, so you know where we are headed. One distinction sits under everything: style, which only ever costs you a confused maintainer, versus functional discipline, which is what actually keeps the program from failing. The embedded target then forces exactly three carve-outs from the language, and everything that remains organizes into four habits:

Memory and mutation, locked down. No heap on the hot path, a bounded and knowable stack, const by default.
One type, top to bottom. A single numeric scalar, almost no casts, and physical quantities that carry their units in their types.
Checked, not hoped. Errors are values you cannot ignore, one way to fail everywhere, and as much proof as possible moved to compile time.
Less you have to trust. No macros computing values, no shared mutable state in the core, the algorithms portable and the platform kept at the edges.

The claim underneath all of it, the one I want to earn over the rest of this piece, is that this is not the slow, careful C++ people brace for. Done this way it is both safer and faster than the C it is so often assumed to trail.

Embedded-first, or nothing

Here's the constraint that shaped everything: this core must cross-compile to embedded microcontrollers, Cortex-M33 and M7-class parts, not just run on a workstation. If you've ever watched a single stray heap allocation blow a real-time audio deadline on a small ARM part, you already know why there is no new anywhere in my signal path. That one mandate rules out a mountain of the bloat that quietly accretes in DSP code, and it turns "good style" from a preference into a spec.

The rules

Before any specific rule, one distinction that matters more than any single one of them: there are two kinds of "coding standard," and they fail in completely different ways.

The first is style, which is about human readability and nothing else: what you name a variable, a class, a function, a member; tabs or spaces; where a line wraps. A formatter like astyle enforces most of it, and a short style guide covers the rest. Get style wrong and nothing breaks; you've just left visual noise for whoever maintains the code next, which in mission-critical work is far more often than you write it. It matters, but it matters to people, not to the compiler.

The second is functional, and it's where the C++ Core Guidelines earn their keep: disciplined casting, strict types, honest error handling, DRY, const used liberally (const data, const pointers, or better still a reference), buffers that carry their length with their type (std::array, not a bare pointer and a separate size you hope still matches), scopes kept small, every object initialized before it's used, one name declared per line and only once you have a value for it. Get one of these wrong and the program can actually fail: a silent narrowing, an uninitialized read, a dangling reference, a buffer that lost track of its length. I follow almost all of them.

Almost, because the embedded target forces exactly three carve-outs, and all three are functional: no exceptions, no RTTI, and no dynamic memory allocation on the signal path. Everything else in the guidelines stands. So the build runs under -fno-exceptions -fno-rtti, warnings-as-errors, and in practice the functional rules look like this:

Memory and mutation, locked down.

No heap on the hot path. Every buffer is a fixed std::array sized by a compile-time constant, its type and its length traveling together. The receiver allocates nothing while running; pools are prepared before the stream starts, and real-time callbacks never allocate, never block, never touch I/O.
Bounded, known stack; no unbounded recursion. With the heap gone, the stack is the last place memory can surprise you, so recursion on the signal path is out and the depth stays bounded and knowable instead of a runtime unknown. I build with -fstack-usage, and every function in the core reports a fixed, compile-time frame; there are no variable-length arrays and no alloca, so nothing can grow the stack while the program runs. On a part with no MMU, a stack that can grow without limit is just a slower way to corrupt memory; I would rather know the worst case before the part ships than discover it in the field.
const by default, references over pointers. Data is const unless it has a reason to change, and where a raw pointer would do I reach for a reference instead. Fewer things can move, so fewer things can go wrong.

static constexpr std::size_t maximum_taps = 32U;
std::array<IQSample, maximum_taps> mCoefficients{};   // fixed size, zero-init, never allocates

One type, top to bottom.

One numeric type, chosen at build time. The whole modem is parameterized on a single Real scalar: float by default, which already carries far more precision than the data ever has (the datasheet note below), with a seam already cut for a future fixed-point Q15/Q31 backed by the M33's CORDIC. Verification is by bit-exact golden vectors and an independent reference decoder, not by a higher-precision build; the point of one type is that nothing silently promotes or narrows between the layers.
One type all the way up and down, almost no casts. Unify a call stack on one type and functions stop converting a size to call a helper that converts it back. Casts are where bugs hide (a silent narrowing, a signed/unsigned flip) and where the compiler stops being able to help you, and they are rarely free: an int-to-float conversion is a VCVT, a stray promotion to double is a software-emulated call on a part with no hardware double, and a few of those per sample, multiplied across a real-time block, is how a DSP loop quietly eats its cycle budget and misses its deadline. The only sanctioned cast is at the boundary of an API you don't own: the codec's int16 buffer, a published C/DMA interface.
Strong types, not bare numbers. A physical quantity carries its unit in its type: a Frequency, an Angle, a Decibel, a SampleRate, a Baud, a BitRate. You cannot build one or read it back without naming a unit, so a hertz cannot be mistaken for a kilohertz and a symbol rate cannot be passed where a bit rate belongs. The decibel types go a step further and know their own algebra: a gain adds to a power level, the difference of two power levels is a ratio, and adding two absolute power levels does not compile at all. It is the same instinct as the single Real type, taken up a level; make the wrong thing impossible to say, and let the compiler enforce the physics. And it is free at runtime: the wrappers fold away, so on the microcontroller a Frequency costs exactly what the bare number underneath it would.

using Real = float;                  // the one scalar the whole modem is built on
Frequency carrier{1800, Hz};         // the unit lives in the type
Power     eirp = transmit + antenna; // dBW + dBi -> Power; but Power + Power will not compile

Checked, not hoped.

Errors are values, not surprises. With exceptions off, a fallible operation returns a [[nodiscard]] std::expected<T, Status>, C++23's standard "a value, or the reason there isn't one," and exactly the shape the Core Guidelines' no-exceptions guidance describes (E.25 through E.28): you must handle it; you can't forget it, and you can't be ambushed by a throw three layers down. I mark the error type itself [[nodiscard]], too, so even a bare status returned by value fails the build when it is dropped; forgetting to check an error is not a mistake you can make by accident, it is a mistake the compiler refuses to let you commit.

One wrinkle earns its own sentence, because it is exactly where the no-exceptions rule and std::expected meet. With exceptions off, calling .value() on an error does not throw; it aborts, with no diagnostic and no Status left to inspect. So the fallible type is a thin Result<T> wrapped over std::expected<T, Status>: the storage is the standard type, but value() routes a missing value through an installable handler that can record the failure before it traps. It is one seam kept on purpose, for the one diagnostic the bare abort would have swallowed; everything else is just std::expected.

In code the wrapper is small, and the whole design lives in one method:

// A fallible T: std::expected<T, Status> underneath (standard, constexpr, trivially
// copyable when T is), wrapped for one reason. With exceptions off, std::expected's
// own value() on an error aborts, with no diagnostic and no Status to inspect.
template <typename T>
class [[nodiscard]] Result
{
public:
    constexpr Result(T value)  noexcept : mResult{std::move(value)} {}
    constexpr Result(Status e) noexcept : mResult{std::unexpected(std::move(e))} {}  // `return Status{...}` just works

    [[nodiscard]] constexpr explicit operator bool() const noexcept { return mResult.has_value(); }

    // Safe on success too, unlike std::expected::error(): a good result reports an ok Status.
    [[nodiscard]] constexpr Status error() const noexcept
    {
        return mResult.has_value() ? Status::success() : mResult.error();
    }

    // The one seam: a missing value routes through an installable handler that can record the
    // failure before it traps, instead of the blind abort. (The const& and && overloads mirror this.)
    [[nodiscard]] constexpr T& value() & noexcept
    {
        if (!mResult)
        {
            critical_error(mResult.error());
        }
        return *mResult;
    }

private:
    std::expected<T, Status> mResult;
};

So where a signature above hands back std::expected<T, Status>, the shipped type is this Result<T>: the same value-or-error contract, drop-in with the standard type, plus the one trap the bare abort would have swallowed. The implicit Result(Status) constructor is what lets a function just return Status{...} on failure and return value; on success, with no ceremony at either end.

One way to fail, everywhere. The single-type rule has an error-handling twin. If a function can fail it returns the one fallible type, a Result<T> (or a Status when there is no value to hand back), and nothing else; never a bare bool that secretly means "did it work," never a sentinel -1 or SIZE_MAX, never a naked error code whose meaning the caller has to memorize. A bool gets exactly one job, a question the caller asks (is_locked(), empty()), never an answer about whether the last call survived. One channel means nobody learns a new failure convention per function: the way you check the channel estimate is the way you check the demodulator is the way you check the file open, a failure three layers down propagates up in the same shape, and the test is always if (!result) with the reason riding along. It is also a library's proper manners; the core originates failures and passes them up, it almost never inspects them, because deciding what an error means is the caller's job. That is why the error-code checks in this project cluster in the application that consumes the modem, not in the modem itself.
Compute at compile time, check at compile time. Anything knowable before the program runs, a table, a size, a bit of geometry, is constexpr; the invariants that must hold, a buffer sized for the worst case, a type that must stay trivially copyable, a rate that divides evenly, are static_asserted, so a wrong assumption fails the build instead of the mission. There are well over a hundred of these compile-time checks across the core, and every one of them costs nothing at runtime.

[[nodiscard]] std::expected<ChannelEstimate, Status> estimate_flat_channel(...) noexcept;
static_assert(sizeof(Instance) <= 4096U);   // a wrong assumption fails the build, not the mission

Less you have to trust.

No macros for values or logic. A constant is a constexpr, a set of states is an enum class, a small helper is an inline function or a template. A #define is text substitution with no type and no scope, and it bites where the debugger cannot follow it: the double evaluation, the silent narrowing, the name that collides with something three headers away. In the whole core the only macros are a platform export shim and a couple of build-time feature gates; nothing computes with them.
No shared mutable state in the core. The portable algorithms are single-threaded on purpose. On a small part a mutex is expensive and there is no reason to be multi-threaded, so the core owns no interrupts, no timers, no DMA, and nothing two contexts can touch at once. The real-time handoff lives at the platform edge, and it stays simple: on the desktop side the audio is a plain producer-consumer relationship, one writer and one reader, not a web of shared locks. Concurrency bugs live in that seam, so I keep the seam thin and out of the algorithms.
Portable core, platform at the edges. The algorithms know nothing of UI, OS, or drivers. The same source that runs a desktop diagnostic tool compiles into firmware.

constexpr std::size_t maximum_taps = 32U;   // typed, scoped, and the debugger can see it
// not:  #define MAXIMUM_TAPS 32            // text substitution, no type, no scope

And none of it runs on the honor system. A formatter (clang-format or astyle) enforces the style half, so no one argues about names or indentation in review. clang-tidy's cppcoreguidelines, bugprone, performance, and modernize checks enforce most of the functional half, run against the C++23 standard the project targets and wired into the build as an opt-in pass the CI and audit builds turn on; on Windows, Microsoft's C++ Core Guidelines Checker does the same job. A complexity checker (I use lizard, though clang-tidy's cognitive-complexity check can do it in-build) guards against functions quietly growing unmaintainable: across the core the average function's cyclomatic complexity is under six, and the handful that run high are the genuinely hard DSP kernels, not accidents. No linter catches every guideline, and some rules are human judgment, but when I say I follow them it's a claim a machine re-checks, not something I'm asking you to take on faith.

The short version: get a name wrong and you've annoyed a maintainer; get one of these wrong and you've shipped a defect. Both are worth fixing, but only one of them fails at three in the morning, when a device is trying to read a life-saving sensor, or a radio is trying to get an emergency message out.

A note on precision: read the datasheet

Developers reach for double by reflex, "double beats float beats int32," but almost none of them open the datasheet of the part feeding them the numbers. Your samples arrive from a codec or ADC with a hard precision ceiling, and the HF signal itself is buried near the channel noise floor. float32 already carries far more precision than the data ever had, so double spends cycles and memory refining bits that are pure noise.

The one place double does earn its keep isn't per-sample math; it's a long-running accumulator, like the sample counter from the overview that walks off the grid after about twenty minutes of continuous audio. Match the precision to where the math actually needs it; the datasheet, not habit, tells you where that is.

That rule cuts the other way, too, and it caught me while I was writing this. My Frequency type stores its value in double, not the float the signal path runs on, and this time that is the right call: a frequency is not per-sample math, it is a setting, and it can be an on-air RF value. float holds integers exactly only to about 16.7 million, so a 29 MHz dial plus a one hertz nudge quietly rounds straight back to 29 MHz; the single hertz just vanishes. So the quantity that might live at RF gets double, while the sample stream that never needs it stays float, and each pays for exactly the precision it uses and no more. The wrapper also carries its own unit, so I can build one frequency in megahertz and another in kilohertz and add them without thinking; inside, both are only ever hertz. Same rule as the codec datasheet, pointed at my own types: match the precision to the quantity, not to a habit.

Right and wrong, in the code

None of this is abstract. Here are four of the rules in real code, three of them straight from the modem's equalizer, next to the version I will not write, and the failure each one removes.

Errors are values, and a buffer carries its own size. The flat-channel estimate takes two spans, checks that they agree, and returns a checked result:

[[nodiscard]] std::expected<ChannelEstimate, Status>
estimate_flat_channel(IQSampleSpan received_probes, IQSampleSpan known_probes) noexcept
{
    if (received_probes.empty() || received_probes.size() != known_probes.size())
    {
        return std::unexpected(Status{StatusCode::invalid_argument, "probe buffers are invalid"});
    }
    // ...
}

The version I refuse to write:

// pointer + length: the caller can lie about either, and a bad input has nowhere to be reported
ChannelEstimate estimate_flat_channel(const IQSample* received, std::size_t n_recv,
                                      const IQSample* known,    std::size_t n_known);

Failure removed: the buffer overrun from a length that doesn't match its pointer; the caller who swaps n_recv and n_known; and the error with nowhere to go. A span carries its data and its length together, so they cannot disagree; the [[nodiscard]] std::expected makes the caller handle failure instead of dropping it; noexcept means the audio thread never unwinds. And if std::span looks like it copies the array on every call, it doesn't: it is just a pointer and a length passed by value, a view into memory the caller still owns, with member functions that keep every access inside the buffer. You get the safety of a bounds-checked container at the cost of passing two registers. And the pointer underneath is not a loophole: because the size rides along, a copy is written against received_probes.size(), so a size-aware copy (std::ranges::copy over the span, or std::copy_n bounded by size()) physically cannot walk off the end. Compare memcpy(received, src, n), where n is a naked count that will cheerfully run past the buffer the moment it's wrong.

Storage is fixed and initialized. The filter taps are a compile-time-sized array, zero-initialized at the declaration:

static constexpr std::size_t maximum_taps = 32U;
std::array<IQSample, maximum_taps> mCoefficients{};

The version I refuse to write:

IQSample* coefficients = new IQSample[taps];   // heap on the hot path, uninitialized, and now someone must delete it

Failure removed: allocation failure, heap fragmentation, and the nondeterministic latency that blows a real-time deadline; the leak; and the uninitialized read. The {} starts every tap at a known value, and a fixed std::array never allocates and can't be freed out from under the receiver.

One type, no casts. The arithmetic stays in IQSample from end to end:

// A conjugated correlation is an inner product. Use inner_product (a strict left-to-right
// fold), not std::reduce: reduce may reorder the sum, and float addition isn't associative,
// so its result is unspecified and not reproducible build-to-build; at a threshold it can
// even flip a decision. inner_product is deterministic.
const IQSample cross = std::inner_product(
    received_probes.begin(), received_probes.end(), known_probes.begin(),
    IQSample{}, std::plus<>{},
    [](IQSample r, IQSample k) { return r * std::conj(k); });

No raw index, so nothing to overrun and nothing for the bounds checker to flag; the intent ("correlate these two") is on the page instead of buried in a loop.

The version I refuse to write:

double cross_re = 0.0, cross_im = 0.0;                              // accumulate in double...
for (std::size_t i = 0; i < n; ++i)
{
    cross_re += (double)received[i].real() * (double)known[i].real()
              + (double)received[i].imag() * (double)known[i].imag();
    cross_im += (double)received[i].imag() * (double)known[i].real()
              - (double)received[i].real() * (double)known[i].imag();
}
IQSample cross{ (float)cross_re, (float)cross_im };                 // ...then narrow it all back

Failure removed: the silent promotion to double, the narrow back to float on the last line, and every hand-rolled complex-arithmetic slip the standard library already gets right. And watch the cost. On a part with no hardware double, every (double) conversion and every double multiply and add is a software-emulated call, not a single FPU instruction. Drop that multiply-accumulate into a tight FFT butterfly and the per-iteration cost stops being one VMLA and becomes a fistful of emulated-double calls; across an N-point transform that is the difference between making your block deadline and an audio underrun. The one-type version compiles to single-precision VMUL and VMLA with nothing in between. When the whole stack speaks one type, there is nothing to cast, and nothing to pay for the cast.

Units live in the type. A quantity carries its unit, so the compiler speaks radio with you:

using namespace modem::common;
using namespace modem::common::literals;

constexpr Frequency carrier     = 1800_Hz;     // not a naked 1800.0f
constexpr Baud      symbol_rate = 2400_baud;   // and not the same type as a bit rate

const Power tx   {10, dBW};     // an absolute power level
const Gain  amp  {13, dBi};     // a relative gain
const Power eirp = tx + amp;    // Power + Gain -> Power (amplification): 23 dBW

const Db snr = eirp - Power{-120, dBW};   // Power - Power -> a ratio in dB

const Power oops = tx + eirp;   // Power + Power: this line does not compile

Look at tx + amp. tx is in dBW, an absolute power level; amp is in dBi, an antenna gain. Those are different units, and adding them by hand is the sort of thing that should make you nervous. But a power level plus a gain is a new power level; that is what amplification is. So the result comes back a Power, in dBW, and I never carried the units in my head; the compiler did the dimensional bookkeeping. It is the difference between adding a temperature to a temperature change, which is fine, and adding two temperatures, which is not.

That last line is two absolute levels, and there is no meaningful sum of two power levels, the same way "nine o'clock plus noon" is not a time. So I made it impossible to write. The decibel type's operator+ carries a constraint, requires(!std::same_as<Tag, PowerTag>), so for an absolute Power it is not even a candidate; and I never wrote a free Power + Power. (I did write Power - Power, because the difference of two levels is a meaningful ratio, the snr line above.) Ask for the sum and the compiler looks for an operator+ that takes two power levels, finds none, and stops. It is not an assert and not a runtime check; the program that does the wrong thing cannot be built. That is what C++20's requires clauses buy you: "this operation is not defined for this type" becomes something the compiler enforces.

Failure removed: the transposed unit, the hertz read as a kilohertz, the gain quietly added to a level as if they were the same thing, and the dimensionally meaningless operation that a comment would have let slide.

A note on `void*`

There is one more cast worth calling out by name, because it hides so well: the void*. It almost never belongs in C++. A void* is not really a way to pass "anything"; it is a cast you have agreed to make later, at the far end, out of the compiler's sight. It throws the type away at exactly the point you most needed it, and the receiver buys it back with a static_cast the compiler cannot check. Hand that callback the wrong object and it still compiles, then does something undefined at runtime, far from the mistake. It also splits one idea into two things that must travel together and can silently disagree: a function pointer and its context. An interface binds the behavior and the object into a single typed thing that cannot be mismatched.

I caught myself on this while writing modem-core. One receiver's callback had grown up as a function pointer plus a void* context, the C way; most of the families still did it that way, and the easy move was to make the odd one out match the majority. I started to, then stopped and asked the question that mattered: do these C++ interfaces actually need void*? They did not. The C module contract is a separate, pure-C header with its own structs; the application links the C++ code directly, and no C caller could touch these interfaces anyway. So the alignment ran the other way. Every family moved up to a small typed interface, an abstract class with a couple of noexcept virtual calls, and the void* stayed only where real C lives. The casts disappeared because the type never got lost.

The "almost" is real, and it is narrow. void* earns its place at a genuine C boundary: the STM32 HAL, an RTOS like FreeRTOS, a Win32 or POSIX callback, or a frozen C ABI of your own. C has no templates and no virtual functions, so an opaque user-data pointer is simply the idiom there, and you make your peace with it. Even then you wrap it once, in one small adapter that does the single documented cast and hands typed references to everything behind it; exactly one place in the codebase ever sees the void*.

One caveat that is easy to miss on a microcontroller, because it is where I have watched good intentions backfire. Removing a void* only helps if what replaces it costs nothing. On a host you would reach for std::function; on a -fno-exceptions, no-heap signal path you cannot, because it allocates. The type-safe replacement has to be the zero-overhead kind: a template resolved at compile time, or a non-owning virtual interface, whose virtual call is a single indirect call, the very same instruction the function pointer was already costing you. Trade a void* for std::function and you have swapped a type hole for a heap allocation, which on the audio thread is the worse of the two. Avoid the void*, but reach for the tool that keeps the deadline, not the one that quietly breaks it.

Turn it upside down

That decision about void* is worth one more look, not for the answer but for how it got there. The first instinct was to make the odd interface match the majority; the better answer only showed up when I stopped and asked the opposite question: what if I go the other way? What if the majority is the thing that's wrong? Aligning up instead of down was sitting right there the whole time, but I could not see it until I turned the problem over.

I learned that trick somewhere unexpected. I once took an art class, and I am genuinely terrible at drawing (most AI agents are no better, for what it's worth). The instructor, a real master, watched me struggle and gave me one piece of advice that has outlasted everything else from that room: turn the thing you are drawing upside down, and draw it upside down. Your brain stops insisting it already knows what a hand or a chair is supposed to look like, and you finally draw the lines that are actually there. Turn it sideways. Take the negative and draw the empty space instead of the object. What do you see now that you could not a moment ago?

Code review is the same discipline. The assumption you cannot see is the one doing the damage, and you do not dislodge it by staring harder from the same angle. So I keep asking "what if?" What if the data flowed the other direction? What if this owner should be the caller instead of the callee? What if the thing everyone treats as fixed is the one thing to change? Most of the time the answer comes back "no, the first way was right," and that is fine; you have paid a few minutes to be sure. But often enough the upside-down view shows you the line that was there all along, the one you would never have drawn facing the page the usual way.

Determinism, or the same answer twice

Here is the hard one, the rule underneath the rules. For a system you have to verify, certify, and someday debug from a field failure, the same input must produce the same output: on this build, on the next run, and on a colleague's machine a year from now. Determinism is the precondition for proof. You cannot verify, trust, or certify a result you cannot reproduce.

That is why the std::reduce question earlier is not pedantry. Its result is unspecified: the standard lets it group the sum any way it likes, and because floating-point addition isn't associative, "any way it likes" can mean a different answer on a different day. The same trap hides in -ffast-math, which quietly reassociates your arithmetic; in relying on argument evaluation order; in reading uninitialized memory; in undefined behavior of any kind, a signed overflow, a shift off the end of a type, a strict-aliasing violation, each of which licenses the compiler to do literally anything, and "anything" is rarely the same thing twice; and in anything that depends on timing or thread scheduling. None of these are wrong the way a crash is wrong. They are worse: they pass every quick test and then diverge later, under a different compiler, a higher optimization level, or the one machine you can't get your hands on.

And it isn't only about ordering. The float32 sample counter from earlier, the one that walks off the grid after twenty minutes, is the same disease in another form: same code, same input, correct and then incorrect, determinism lost across time rather than across runs. A two-minute test never sees it; a five-hour soak always does.

So determinism gets designed in, then proven. Designed in: one Real type so a build can't silently promote and shift the answer, a fixed left-to-right fold instead of a reordering reduce, no -ffast-math, every object initialized. Proven: bit-exact golden vectors and an independent reference decoder that has to produce the same bytes, checked on every build. The goldens aren't there because I doubt the math; they are there because "the same answer twice" is a property you can only keep by testing for it. Correctness you can often eyeball. Determinism you cannot, which is exactly why it's the one that bites in the field.

"C++ is too slow": a myth worth retiring

There's a reflex in embedded circles that "C++ is too slow for a microcontroller." I'd put the opposite on the table: C++ written this way (templates resolved at compile time, no dynamic memory, no RTTI, no exceptions) is almost certainly safer than the equivalent hand-rolled C, and arguably just as fast, in a comparable memory footprint. The abstractions cost nothing at runtime because they're gone by the time the linker runs; what's left is the same machine code a careful C programmer would have written, but with the compiler enforcing the invariants instead of a code review hoping to catch them. Code that reads like a specification, runs in a few kilobytes of workspace, and doesn't make you choose between safety and speed. "Tight and fast" isn't a slogan; it's what the target demands.

Honesty cuts both ways

Not every algorithm fits every part. The model-based CIR equalizer compiles out entirely on embedded targets to reclaim ~14 KiB, and the whole-burst turbo decoder that earns the standard's conformance corners at zero errors is a host-side path; on the microcontroller, the leaner adaptive decision-feedback equalizer is the sole receiver, a decision expressed in one build flag rather than a forked codebase. That's a real tradeoff, not a free lunch: the embedded receiver gives up some of the turbo path's fading margin to fit the part's memory and clock budget. But the ceiling there is this particular part's budget, not embedded computing itself; every processor has a ceiling, and a bigger part or a co-processor moves it. I'll quantify what the tradeoff costs, and whether more capable hardware (a larger part, or the FPGA co-processor I've prototyped alongside the M33) buys the turbo path back into budget, when I reach the equalizer.

A word on "safety"

There have been press conferences and position statements arguing that one language is inherently safer than another. The fact is quieter: safety is far more about using the tool correctly than about which tool you picked. That framing confuses the tool with the hand holding it. A language isn't unsafe on its own; code becomes unsafe through undisciplined practice: the raw pointer no one bounds-checked, the buffer no one sized, the exception no one expected. The guardrails are right there in the language; unsafe code comes from engineers who don't use them, or who deliberately switch them off. A power saw hurts you when the operator won't lower the guard into place; the saw isn't the defect, the choice is. The disciplines I hold to in this project (no heap in the signal path, checked [[nodiscard]] results instead of surprises, one unified type, casts only at the door) are those guardrails, used on purpose. And modern C++ hands you the rest directly: std::span and std::ranges for bounds-safe access instead of raw pointer arithmetic, std::array for fixed storage, and RAII with std::unique_ptr for ownership you cannot leak. C++23 is a perfectly capable language for safety- and mission-critical work; you just have to pick up the tools it already gives you. The safe choice isn't a rewrite; it's the practice.

On the rulebooks: MISRA, AUTOSAR, JSF

Someone in a regulated shop is already asking the obvious question: where is MISRA? This is medical and military work, and MISRA C++ (now MISRA C++:2023), AUTOSAR C++14, and JSF are the coding standards certification bodies ask for by name. I have been pointing at the C++ Core Guidelines instead.

Here is my honest position. Write code the way I am describing, and use the Core Guidelines the way they are meant to be used, as a way of thinking and not a checklist, and you are not falling short of those rulebooks; you are past them. The rules in this article are stricter than most of what those standards enforce, and having clang-tidy and lizard check them on every build is a stronger guarantee than a signature attesting that someone read the standard once. A result a machine re-derives on every commit beats a box a human ticked at the end.

I will go further, because I have watched it happen. A great deal of "MISRA-compliant" code is not compliant in spirit at all; it is a pile of suppressed warnings and blanket deviations. The rule fires, the deadline is close, and the fastest way to green is a justification comment and a suppression, not a fix. The standard is satisfied on paper while the very thing it warned about stays in the code. That is the failure mode of any rulebook used as a checklist: it rewards making the warning disappear, not making the defect disappear.

My rules push the other way. When the analyzer flags something, the move is to change the code until the reason for the warning is gone, not to annotate it into silence. Address the root cause and the deviation log stays short and honest. The goal was never to satisfy a document; it was to make a class of failure impossible. Do that in earnest and the certificate takes care of itself.

A note on getting it wrong

I should be honest about all of this: I don't always get it right the first time. I slip back into old habits, I race to get something working, and then I look up and find a raw index where a span belongs, or a function that quietly grew three jobs while I wasn't watching. The rules above are not how my first draft comes out. They are what I hold myself to on the way from "it works" to "it's right."

Code is iterative, like anything worth doing. You can absolutely write software this way, anyone can, but not in one pass and not on good intentions alone. It takes real work, real time, and honest iteration: write it, measure it, run the linter over your own code, and fix what it finds. That last part is the whole point of the tools; they catch me when I've slipped, they are not a trophy for never slipping. The discipline isn't being perfect. It's going back.

Why this is what "safety-critical" means

Step back from the individual rules and the argument is simple. "Mission-critical" and "safety-critical" are not adjectives you earn by trying hard; they are a standard of evidence. The question is never "is the code good," it's "can you show that a whole class of failure cannot happen." Everything above exists to answer that question, one failure mode at a time.

Read the rules in that light and they stop being style. No heap on the signal path removes allocation failure, fragmentation, and the nondeterministic latency that blows a real-time deadline. No exceptions removes an invisible control path through code that must never unwind on the audio thread. Checked results, in an error type you cannot silently drop, remove the error a caller forgot to handle. One type, with casts only at the door, removes the silent narrowing and the signed/unsigned slip; a quantity that carries its unit removes the unit mismatch and the transposed argument. A std::array that carries its length removes the buffer overrun; a bounded, recursion-free stack removes the silent overflow on a part with no memory protection; initializing every object removes the uninitialized read; a static_assert removes the wrong assumption that would otherwise wait until runtime to matter; small, low-complexity functions remove the path no test ever covered. Each rule turns a possible defect into an impossible one, at compile time or by construction. That is the whole game: you don't hope the bug isn't there, you arrange for it to be unrepresentable.

And then you prove it, which is where the tooling stops being a convenience and becomes the point. A safety process does not accept "we were careful"; it wants a demonstration it can repeat. The compiler's warnings-as-errors gate every build, and clang-format, clang-tidy, and lizard run as a build-integrated pass, so the discipline isn't a story I tell in a design review, it's a result a machine reproduces. Careful is a feeling; a failing build is a fact.

That is why disciplined modern C++ belongs in mission-critical systems, and why I keep the rules boring and the tools honest. The exciting part is the DSP. The rules are what let me sleep while the modem runs for five hours straight.

With the rules on the table, next week I start at the top of the signal chain: the transmit side, the easy half done right.

Building a MIL-STD-188-110 HF Modem in Modern C++: An Introduction

P.R.Decker — Sat, 26 Sep 2026 16:06:02 +0000

A weekly deep dive into a fixed-frequency serial-tone waveform, one block at a time.

High-frequency (HF) radio is the communications system that refuses to die, and for good reason. It bounces signals off the ionosphere to reach thousands of miles with no satellites, no cell towers, and no infrastructure an adversary can switch off. That resilience is exactly why defense communications still standardize on it, and why MIL-STD-188-110, the interoperability standard for HF data modems, is still very much alive, from its 1991 "A" revision through the current "D."

Picture trying to pick out one friend's voice across a crowded room. Now make the room an echo chamber, so every word reaches you two or three times, each arriving a beat apart, and let the crowd swell and hush at random, so your friend fades to a whisper and back mid-sentence. That is the HF channel. And here's the part the textbooks written in the 1980s didn't have to reckon with: the room is louder now than it has ever been. The early radio pioneers listened into a quiet spectrum. We've filled ours with switch-mode power supplies, LED drivers, and phone chargers, each one humming broadband electrical hash across the very bands the ionosphere hands us for free. A modem that still works over that is a small master class in digital signal processing. Over the next several weeks I'm going to take mine apart, the serial-tone (single-tone) waveform of MIL-STD-188-110A/B (110B §5.3.2), and walk through every block of it.

And there's a second reason it matters, the one that turns a clever demo into something you can actually field: the whole modem runs on a microcontroller, not a rack of specialized radio hardware. For the modern warfighter that's less about cost than about weight and battery life. A Cortex-M33 is a part you can put to sleep, so ours sits in deep sleep and only wakes when there's activity on the channel; the radio you carry gets lighter, lasts longer between charges, and still never misses a call. Resilient, low-power, and small enough to disappear into a handheld is a rare combination, and it's the one I care about most; I've spent my career in safety- and mission-critical codebases, the kind where a defect isn't a bug ticket, and this modem is that same rigor aimed at HF.

The waveform in one breath

If the acronyms in this section aren't your world, don't sweat them; the single idea to carry out of it is that every one of them is a deliberate trade of raw speed for survivability.

The serial-tone body is deceptively simple on paper. Everything rides on a single 1800 Hz carrier at 2400 symbols per second, using 8-PSK modulation, at data rates from 75 to 4800 bps. Lower rates buy robustness by spending bits on redundancy: a K=7 rate-1/2 convolutional code protects the data, with symbol repetition at 300 and 150 bps and Walsh spreading at 75 bps. A block interleaver (0.6 s "short" or 4.8 s "long") scatters the bits so a fade burst damages many codewords a little instead of one codeword fatally. Known probe symbols are stitched into the data stream so the receiver can keep measuring the channel, and the whole burst opens with a countdown preamble that announces the mode and marks where the data begins.

That's the transmitter, and honestly it's the easy half. Encoding is deterministic. The hard half is undoing what the channel did.

What a real receiver actually looks like

If you've seen the classic block diagram of this waveform, a clean left-to-right chain of equalizer to symbol extraction to deinterleave to Viterbi, you've seen an honest simplification. The standard even ships its own version (Figure 2, the serial-tone functional block diagram), and like every textbook rendering it assumes the receiver already knows where the burst starts and what mode it is. A real receiver has to earn all of that from raw audio and noise.

And that gap is the whole game. I've seen plenty of implementations that decode a clean, textbook waveform beautifully... and then fall over the moment the channel does anything real: a little noise, a fade, an echo, a few hertz of drift. The clean case is the easy ten percent. The hard ninety is the error correction, the equalization, and the timing and carrier tracking that keep a link alive when the ionosphere is working against you. Meeting the standard under those conditions is genuinely hard; exceeding it is harder still, and that's exactly what this series spends its time on.

The receive chain I built has nine stages, and the interesting ones are the three the textbook version glosses over:

Acquisition doesn't assume sync; it finds the burst. It correlates against the known preamble in a way that survives fast fading, and decodes the mode and a countdown that tells a receiver waking up mid-preamble exactly how far ahead the data is.
Earliest-path anchoring solves a subtle multipath trap: on a two-path channel you can lock onto the echo instead of the direct signal, which puts the real energy somewhere the equalizer can't reach. So I lock onto the direct path and treat the echo as energy the equalizer can use, not interference it can't.
The equalizer is where my design diverges most from a reference model. Instead of one fixed adaptive filter, I pick the equalizer's geometry from the measured delay spread, and solve the channel one of three ways: an adaptive decision-feedback equalizer for the streaming/embedded path, a model-based CIR-MMSE equalizer that measures the channel and solves the optimal filter in one shot, and a whole-burst turbo decoder for the strongest possible decode. The insight behind it: a 20-symbol probe can't train a 46-tap adaptive filter on a fast-fading channel, but it easily over-determines a 13-tap channel model, so measuring the channel and solving the filter is the stronger move.

Everything after that carries soft information end to end: soft demapping to log-likelihood ratios, deinterleaving, repetition combining, and a continuous Viterbi (or a soft-in/soft-out decoder for the turbo loop). The decoder gets probabilities, not just hard guesses.

Does the extra machinery earn its keep? Here's the number. Across every conformance corner the test plan defines for this waveform (Table 10.1 of the JITC conformance test plan, which verifies the 110B serial-tone performance requirements), my whole-burst turbo receiver decodes at zero bit errors, comfortably clearing a bar that only asks for fewer than one error in 100,000. That includes the punishing low-rate case of a 5-millisecond multipath echo under a 5 Hz fade, the condition the plan sets for 75, 150, and 300 bps. That worst-case corner is the one where two equal-strength copies of the signal arrive a beat apart and the channel breathes in and out five times a second; it's the corner that separates a demo from a modem. As one example of why it holds up: simply deciding to lock onto the direct signal instead of its louder echo cut the error rate roughly tenfold on a 300 bps two-path fading channel. Every figure in this series comes with its channel and SNR attached, because on HF a bit-error rate without a channel is a number without a meaning.

Conformance is the floor, not the ceiling

Passing MIL-STD-188-110 is the price of admission; the interesting engineering lives in the margin above it. So I built a battery of my own tests that push well past what the standard asks: faster fading than the spec's worst corner, carrier offsets wider than it tolerates, and in-band interference it never contemplates at all. The modem holds zero errors across conditions the standard doesn't even test. That margin isn't a trophy; it's what keeps a link up when the real world is worse than the spec promised: more range on a bad night, messages that still get through under jamming and the electrical junk no test plan models. I'm not going to dump those numbers here; each one belongs with the block of the receiver that earns it, so I'll bring them out as we go and assemble the whole picture in the finale. But the headline is worth stating plainly up front: meeting the standard was never the goal; beating it was. That's a theme I'll keep coming back to.

Why this is hard to fake: hours, not minutes

Here's what separates a real modem from a weekend project: endurance. Anyone can write something that decodes a clean 30-second test tone. The MIL-STD / JITC conformance regime doesn't ask for 30 seconds; it asks for hours of continuous, unbroken bitstream at a target error rate, over a channel that is actively fighting you the entire time. The plan isn't coy about the duration, either: it calls for each fading condition to be measured for at least five hours, and even the clean AWGN case for at least an hour. Just to measure a bit-error rate of 1 in 100,000 with statistical confidence you need on the order of ten million bits, and at these data rates that's a stream running for tens of minutes to hours without a single stumble.

A toy modem sails through the first few minutes and then quietly comes apart: a timing loop drifts, an accumulator overflows, a fade it can't ride knocks it off the channel. Passing means actually implementing the advanced DSP (adaptive equalization, carrier and symbol-timing tracking, interleaving deep enough to outlast a fade) that keeps the stream locked for the full duration. I found this out the hard way: a sample-index counter I'd kept in float32 walks off the symbol grid after about twenty minutes of continuous audio (once it passes 2^26 samples, where the gap between representable integers grows past the step size). A two-minute test can never surface that. The hours-long soak isn't an inconvenience in the test plan; it is the test.

On top of duration, the channel itself escalates:

Test channel	What it simulates	Why it's punishing
AWGN (Gaussian)	Thermal noise only, no fading	The baseline, yet the low rates must still decode at just a few dB of SNR
Doppler shift / offset	Radio tuning error, oscillator drift, ionospheric motion	Must hold sync with the carrier offset +/-75 Hz, and in the sweep test, ramping +/-75 Hz at 3.5 Hz/s
Watterson 2 ms / 1 Hz	Moderate two-path multipath, slow fade	Two signal copies ~5 symbols apart; the equalizer must exploit the echo, not fight it
Watterson 5 ms / 5 Hz	Severe multipath, fast fade (low-rate corner)	Echo 12 symbols deep and the channel changing 5x a second; the low rates (75-300 bps) must survive exactly this
Continuous duration (>=1 hr AWGN, >=5 hr fading)	A real operational link held open for hours	Every drift, overflow, and timing walk compounds over millions of symbols; only sustained DSP survives it

But it has to run on a microcontroller

There's one more constraint that shaped every decision you'll read about in this series, and it's worth naming up front: none of this was written just to run on a workstation. The whole modem cross-compiles to embedded microcontrollers, Cortex-M33 and M7-class parts, and that single rule, more than any other, is why the code looks the way it does. No heap in the signal path. No exceptions. One numeric type, chosen to match the hardware rather than habit.

That's an entire engineering philosophy of its own: the coding guidelines I hold myself to, why modern C++ is a genuinely capable choice for this kind of work, and how you get memory-safety-grade discipline without throwing away thirty years of tooling. It's too big to bury in an introduction, so it's where the series actually starts. Next week: the rules I build by.

The series ahead

Each week I'll take one piece and go deep, looking at the DSP, the standard's intent, the failure modes on a bad channel, and the choices that keep it small enough to embed:

The rules I build by. The coding guidelines, no heap and no exceptions in the signal path, one numeric type, disciplined error handling, and what makes modern C++ the right tool for the job.
The transmit chain. Framing, the countdown preamble, and turning bits into an 1800 Hz waveform.
The audio front end. Matched filtering and Gardner symbol timing.
Acquisition. Finding a burst in noise, and reading the mode from a countdown.
Earliest-path anchoring. Why you lock onto the direct path, not the loudest one.
The equalizer. Adaptive vs. model-based, why measuring the channel beats chasing it, and what actually fits a microcontroller.
Soft demapping and the FEC. LLRs, continuous Viterbi, and the turbo loop.
Orchestration. The streaming state machine that makes it a live receiver.
Testing and channel simulation (a side journey). Standing up the channel simulators (Watterson / PathSim), and how you get repeatable, statistically meaningful BER-vs-SNR results instead of a lucky decode. This one turned out complex enough to earn its own deep dive.
Conclusion: the whole modem, measured. The complete results table in one place: conformance, and everything the receiver does beyond what the standard asks.

If you build HF systems, write real-time C++, or just like watching a hard problem get taken apart cleanly, follow along.

About the author. Paul Decker (amateur radio callsign KG7HF) is a mission-critical, safety-critical embedded developer with thirty years of microcontroller experience, the greenfield kind, where a defect isn't a bug ticket. He served as a radioman aboard Trident ballistic-missile submarines, worked in the DSP division at Analog Devices, and has built safety-critical medical devices and mission-critical military systems. On the amateur side he's a dedicated homebrewer: antennas, amplifiers, and a long line of embedded controllers for ham gear. He works weak-signal VHF/UHF, including EME ("moonbounce"), and operates in the Army MARS (Military Auxiliary Radio System) program. He's an engineer and a builder, not an algorithm researcher: this modem isn't a research project, it's an engineered one, built to run on a microcontroller and proven against the standard.

DEV Community: P.R.Decker

Acquisition: finding the burst

The preamble, as the standard defines it

The reference

Correlating so a fade does not hide it

A match at every segment

The carrier offset

Reading the mode and the countdown

Waking up mid-preamble

A mode this modem does not implement

One segment, or all of them

No burst at all

Part 3's hang-up, fixed while acquiring

The clock offset, or a second loop

When to learn, and when to stop

Testing, part one: what the standard asks, and how long it takes

The tests

Run it on your own

Go read the code, and the standard

Next

The audio front end: finding the symbols

Four jobs

Mixing down to baseband

The compiler changed the math

The matched filter

Why the receive filter is wider than the transmit pulse

Computing only what is needed

Finding the sampling instant

Early-late or Gardner

Keeping time for hours

Any block size, the same symbols

Carrier tracking, part one

Walk the symbols back out

The test bench

What the short preamble showed

Part 2, retrofitted

Go read the code, and the standard

Next

The transmit chain: the easy half, done right

Plan the whole burst before you move a bit

The FEC: spend bits to buy survival

Repetition and Walsh: more redundancy, lower rates

Interleaving: scatter the damage

Bits to symbols: the constellation and a Gray map

Probes and the countdown preamble

Scrambling: whiten it, and exactly

Turning symbols into 1800 Hz

Walk a message through it

Why the easy half gets the same rigor

Go read the code, and the standard

Next

The rules I build by

Embedded-first, or nothing

The rules

A note on precision: read the datasheet

Right and wrong, in the code

A note on void*

Turn it upside down

Determinism, or the same answer twice

"C++ is too slow": a myth worth retiring

Honesty cuts both ways

A word on "safety"

On the rulebooks: MISRA, AUTOSAR, JSF

A note on getting it wrong

Why this is what "safety-critical" means

Next

Building a MIL-STD-188-110 HF Modem in Modern C++: An Introduction

The waveform in one breath

What a real receiver actually looks like

Conformance is the floor, not the ceiling

Why this is hard to fake: hours, not minutes

But it has to run on a microcontroller

The series ahead

A note on `void*`