Inside the
Contest Decoder

The shape of the problem

An FT8 transmission is 79 symbols of 8-tone FSK at 6.25 baud — 12.64 seconds. Twenty-one of those symbols are sync: three Costas arrays of 7, at the start, middle and end. The other 58 carry a 174-bit LDPC codeword, which unpacks to 77 message bits plus a 14-bit CRC.

The decoder's job is to turn that waveform into 174 log-likelihood ratios — one soft value per bit, signed by which way the bit leans and scaled by how sure the evidence is — and hand them to an LDPC belief-propagation decoder. If BP fails, an ordered-statistics decoder (osd174) gets a turn. The CRC is the referee: a codeword either checks out or it doesn't, so the decoder can afford to guess repeatedly and cheaply verify.

That last point is what makes an ensemble worth building. There is no penalty for a wrong attempt beyond the CPU it burns, and there is no way to know in advance which reading of a given signal is the right one. So the decoder computes several and tries them all.

Perturb the candidate's arrival time and frequency, rescore the Costas sync, keep the best.

The coarse candidate search hands ft8b a rough time and frequency (xdt0, f10). Both are wrong — the time by up to a fraction of a symbol, the frequency by a couple of hertz from drift, Doppler and dial error. Every downstream metric is computed on symbol boundaries, so an alignment error smears energy from each symbol into its neighbours and quietly destroys the bit metrics before the LDPC decoder ever sees them.

So before demodulating, the decoder walks a small grid around the candidate and rescores the sync at each point — a two-stage search, coarse then fine:

Demodulate one symbol at a time, then two at a time, then three (FT8) or four (FT4) — and keep all three answers.

With the signal aligned, the decoder builds bit metrics. The obvious way is symbol by symbol: for each of the 8 tones take the magnitude of that tone's bin, and for each bit take the best hypothesis where the bit is 1 minus the best where it is 0. That is nsym=1, and it is non-coherent — it throws away phase.

But FT8's tones sit at exact multiples of the baud rate, so the phase advance across a symbol is a whole number of cycles. Consecutive symbols are therefore not just continuous but phase-aligned, and you may legally add their complex bins before taking a magnitude. Doing so over two or three symbols at once buys coherent processing gain:

Overwrite part of the codeword with saturated likelihoods taken from the QSO state, and let the decoder solve for the rest.

The first two mechanisms extract more from the signal. This one adds information that was never in the signal at all.

Mid-QSO, you know a great deal about what the other station is about to send. If you called CE3TSK and they answered, their next transmission almost certainly begins with your callsign and theirs. Those bits are not a guess to be recovered from a noisy waveform — they are known. So the decoder writes them in directly, as log-likelihoods at apmag = maxval(abs(llra))*1.01: fractionally louder than the loudest genuine evidence, which pins them without letting them overflow the arithmetic.

How the three compose classic

Stacked, these produce a lot of attempts per candidate. The structure in ft8_decode.f90 and ft8b.f90 is three nested tiers:

Each attempt runs bpdecode174, falling back to osd174. The CRC decides. The first attempt that passes wins, and everything else is discarded — which is why the decoder can be this profligate without being wrong: it is not combining opinions, it is running a search whose answers are individually verifiable.

That is the sense in which it is an ensemble. Not a vote, and not a committee — a set of deliberately different readings of the same twelve seconds of audio, generated because the channel will not tell you which reading is correct, and cheap to test because the code carries its own proof.

Decode the same audio several times through fixed, reproducible perturbations — a delay, a dither, a tone shift — and keep the union.

The observation that started it: the old decoder's non-deterministic runs reached "over 100" messages on a test capture not because any single run was better, but because every run was a different sample of a decoder whose result flips on threshold decisions. The union of many samples climbs toward the real content of the band.

The FT8 chain is a sequence of hard decisions taken on soft data, and every one of them is a place where an input change smaller than the noise flips the outcome:

• sync8 normalises the sync surface by its 40th percentile and keeps only bins above syncmin (1.1–1.5). A candidate a hair under the line is not a weak decode — it does not exist.
• Candidates are sorted by sync and decoded strongest-first with subtraction, so the order decides what every weaker signal underneath them gets to see.
• ft8b rejects candidates on dozens of nsyncscore / scoreratio rules before LDPC or OSD ever runs.
• The LDPC and OSD searches stop at the first codeword that passes CRC.

Measured on one capture: a dither at 1 % of RMS moves a single run between 77 and 86 messages; a delay of one sample gives 83; a 0.2 Hz shift gives 79. Each is a fair sample, and different samples fail on different signals.

The three perturbations

All three live in ft8ensemble.f90 (ens_perturb), and all three are exactly reproducible on any machine:

• Delay — dd8(1+n:)=dd8p(1:np-n), zeros in front. 128 samples is 10.7 ms, below the 40 ms DT step. The member's reported DT is corrected by -n/12000 so the shift never leaks into avexdt.
• Dither — Gaussian noise at k × RMS of the pristine band, from a private xorshift64* generator with a fixed seed and a fixed Box–Muller step. Deliberately not Fortran's random_number, whose sequence is compiler-defined and would break cross-machine determinism. The sweet spot is 3–5 % of RMS (−30 to −26 dB); 30 % destroys the weak tier.
• Frequency shift — analytic signal through the already-linked FFTW (r2c over 180,000 samples, zero the negative half, c2r), multiplied by exp(i2πΔf t), real part. About 10 ms. Reported frequencies are corrected by -Δf.

Members run as extra passes inside one period's decode, starting from the pristine band rather than the merged one — a different subtraction history is the entire point. They deliberately never become "the previous period": feeding perturbed copies into ft8sd averaging produced 95 messages in testing but manufactured one that was not on the air, because averaging near-identical copies is coherent gain that does not exist in reality. That path was closed on purpose.

Once the normal passes have subtracted what they can, re-decode the residual with the opposite recipe.

JTDX's two decoding families are good at different things. The SWL-cycle family works on averaged data with a wide DT window; the plain-cycles + OSD family works on raw data and searches deeper. Classic JTDX makes you pick one and run it everywhere.

The alternate pass runs the other one afterwards. It is a third kind of pass in decoder.f90's pass list — SWL off, 7 plain cycles, OSD order 2, on the main grid, operating on the band with every earlier pass's subtractions merged in and the duplicate arrays carried over. Parameter lft8altpass, file mode -X, GUI Decode → FT8 decoding → alternate-approach pass.

Two results came out of the sweep that settled its shape. The pass wants 7 or 9 cycles — at 5 it gains nothing. And the older half-slice offset pass actively hurts once the alternate pass exists: its extra subtractions and duplicates take away exactly what the alternate pass would otherwise have found. Adding a good idea meant removing one that had been earning its place until then.

Keep four same-parity message lists instead of one, so a single missed period no longer breaks a station's chain.

This one extends the mechanism from section 03 across time. AP decoding pins bits you know from the QSO you are in; the ^ hint decoder pins bits you know because you already decoded that station, at that frequency and DT, in an earlier period. It is the same 77-bit a-priori machinery, sourced from memory rather than from the sequencer.

Classic JTDX keeps exactly one list per parity — evencopy and oddcopy — and will try a stored message only if it was decoded in the immediately previous same-parity period, 30 seconds back. That is a brittle chain. One missed period from a stronger neighbour's residue, from QSB, or from a subtraction artefact — all routine at −24 dB — and the station drops out of memory entirely, then stays lost until some blind pass happens to catch it cold again.

v3.0.0 keeps four lists per parity, reaching two minutes back. The older lists are searched only when the newer ones hold nothing for a candidate, and a hint decode retires its entry in the list it came from, so a station cannot be re-hinted from stale memory once it has been heard. The lastrxmsg fallback looks back the same way. Default is NHINTDEFAULT in ft8_mod1.f90; JTDX_HINT_DEPTH=1..8 overrides it, and 1 is exactly JTDX's behaviour. No params-block change — jtdxjt9 carries it alone.

FT4 gets the same treatment new

The ensemble was transplanted whole into FT4, where ens_perturb runs on the aligned candidate rather than the whole band: member 1 is dither, members 2–3 shift ±0.6 Hz, 4–5 delay by ±1 sample, 6 draws different noise. FT4 is threaded on the same anchored 417 Hz grid as FT8 — each slice subtracting into its own copy of the audio, four inherited data races fixed on the way — so the same audio gives the same message set at any thread count of two or more, and the whole ensemble fits inside FT4’s 1.36 s reply deadline where it used to overrun it. Measured over a 240-period on-air hour at 12 threads on an idle machine:

What came after the ensemble is FT4’s own: a TX background switched on exactly as FT8’s, which re-works the retained period while you transmit — the members the reply phase did not run, deep OSD, the alternate pass, a residual pass, lower thresholds — with its own effort, sensitivity and clock, until 0.5 s before the window ends; six presets in FT8’s tiers, each label carrying its measured cost; budget auto for the max effort tier, which learns what a member costs on this band and admits as many as fit inside 1.3 s; and the virtual candidate at the QSO frequency, worth about +1 dB on the one reply a QSO is waiting for. On the night hour the default recipe decodes 1 737 messages, recommended 1 881 with a 0.10 s reply time, max effort 1 888 at 0.59 s — against 1 525 for JTDX’s own FT4 decoder with its ALLCALL7.TXT lookup off on the same audio, +24 % (1 356 and +39 % as shipped).

Three fixed choices that mapped to 3, 6 or 9 internal passes become a direct setting of 3 to 9.

Everything in Parts I and II is spent inside a pass, and the number of passes was the one dial the operator could not really turn. Classic JTDX offers actionDecFT8cycles1..3 — three menu entries — and ft8_decode.f90 translates them:

if(nft8cycles.eq.1) then; npass=3
else if(nft8cycles.eq.2) then; npass=6
else if(nft8cycles.eq.3) then; npass=9

In the fork the indirection is gone — the setting is the pass count, and the menu carries actionDecFT8cycles3 through 9:

if(nft8cycles.ge.3 .and. nft8cycles.le.9) then; npass=nft8cycles

The same change applies to the SWL cycle count (nft8swlcycles), and file mode exposes it as -C. Why the old steps were multiples of three is visible in the pass loop: when low-threshold or SWL mode is on, the sync threshold walks a three-pass cycle — 1.225, then 1.5, then 1.1 — and repeats. Classic JTDX only let you buy whole sweeps of that cycle.

Fifteen data races fixed — nine inherited in FT8, four in FT4, two of the fork’s own — the hot loops rewritten, and the same answer on every thread count.

The determinism work is not housekeeping here — it is what makes the ensemble a coherent idea at all. "Decode it several times and take the union" is only an instrument if the decoder returns the same answer when you do not change the input. On a racing decoder it is just re-rolling dice, which is precisely what the old non-deterministic runs were doing when they reached "over 100" by accident.

Nine races were found and fixed in the stock FT8 decoder (four more in FT4, and two the fork introduced in its own pipeline and fixed). The worst was the shared audio buffer dd8: threads were subtracting decoded signals out of each other's audio, so what any one thread saw depended on who got there first. It is now threadprivate with copyin. The others were the ft8_downsample C++ cache, the osd174_91 first_osd initialisation, the four2a FFTW plan-cache publish, the gen_ft8wave tables, and the decoded-message store's counter.

On top of that the fixed 12-slice band grid was decoupled from the thread count, with threads picking slices up dynamically and per-slice state indexed by slice. The result is the property the rest of the release is built on: the same message set at every thread count of 2 or more. A 2-core and a 16-core machine decode identically; -j changes only the time.

Then the speed work, which bought the seconds Part II spends:

• sync8 window-sum tabulation. The 17-bin window sum was being recomputed for every DT lag although it depends only on the bin and the symbol. Tabulated once, using the identical expression — bit for bit exact — and the lag loops halved.
• OSD bit-packing rewrite. GF(2) rows packed into 3 × int64 words: word-wise elimination, incremental codewords by row XOR, soft distances by masked sums with the floating-point order preserved, and the 2 MB per-call hash memset replaced by a direct-keyed table. Proven identical to the byte reference on 39,000+ randomised cases — a rewrite of the most numerically delicate part of the decoder that changes no output at all.
• Candidate cap raised 450 → 2000 in sync8; the old cap was silently dropping real signals on a crowded band.

Split the decoder in two: a fast phase that makes the reply deadline, and a background phase that uses the time the process used to spend idle.

Two facts set the shape of this. The decoder process idled about 12 of every 15 seconds — in TX and RX periods alike. And the timing is tight at exactly the wrong moment: the decode does not start until 14.1 s into the period (m_hsymStop=49), because that is when the audio it needs has finally arrived, and the auto-sequencer wants its reply decision roughly one second later — just as the next period, the one you transmit in, begins. Anything slower than that was already too late to change what you send, however good it was.

So the decode is now two phases. The RX phase is deliberately cheap — SWL-5, 78 messages in 1.2 s — and prints <DecodeFinished> exactly as before, so the sequencer sees what it needs on time. The TX background then keeps working on the retained band while you transmit, running units the RX phase could never have afforded:

• the deferred alternate pass,
• the ensemble members,
• a residual pass — every known decode subtracted, then the threshold lowered,
• the classic unit, a plain non-SWL 6-cycle decode on the pristine band, 0.3–0.5 s,
• and extra members if the budget allows.

Each unit is preceded by a check of the GUI's .lock file — removed means the next decode is wanted, and the unit stops within a pass rather than finishing — and, in auto mode, of the remaining time budget. Only new messages print, carrying the period's UTC, and a <BackgroundFinished> line closes with the count. Background decodes are marked | in the output, and a hint made in the background ┼.

The loop that closes new

The three parts of Part II and the pipeline are not independent. They compound, and the thing that couples them is the hint memory from section 06.

The headline FT8 comparison is 240 consecutive on-air 15-second periods (2026-08-27, 20 m, 100–3100 Hz, 12 threads of a Ryzen 7 5800H), the same recorded audio put through every engine at its own best settings:

The recorded hour, the FT4 hour and the wideband benchmark capture are published as 16-bit WAV, with a script that replays them through the standalone decoder and reprints this table on any machine: ce3tsk.com/download/wav.

And every approach separated out, each against the classic JTDX behaviour it replaces or adds to, per mode: