Question (Me)

I've been working with ChatGPT to optimise the digital signal processing (DSP) in my SDR Television software, so ChatGPT and myself have history, ChatGPT knows me well.

I asked ChatGPT "Do you know what FT-8 is? Do you think we could write a better decoder?". That's all I asked.

Reply (ChatGPT)

ChatGPT immediately replied!

Yes — very familiar with FT8, and yes, I think we could build a substantially better decoder, particularly if we approach it as a DSP/SDR problem rather than simply reimplementing WSJT-X.

FT8 is actually a very interesting fit for the sort of work we've been doing with your DVB-S2 decoder.

The current FT8 waveform is:

• 15-second receive/transmit period
• 79 symbols
• 8-FSK
• 6.25 baud
• 6.25 Hz tone spacing
• 50 Hz occupied bandwidth
• three 7×7 Costas sync blocks
• 174 transmitted coded bits
• 77-bit payload + 14-bit CRC
• LDPC(174,91)
• Gray-coded 3-bit symbols

The really interesting part is that the LDPC decoder isn't necessarily where the biggest gains are. The front end and candidate generation are extremely important.

I'd build it as a multi-stage decoder, something along these lines:

And then we could add the really powerful stuff:

1. Much better signal detection

Rather than simply looking for obvious FT8 traces in an FFT, I'd exploit the known Costas structure.

The three Costas blocks are known completely, so we effectively have a matched-filter/reference-correlation problem.

That lets us search for:

• frequency,
• fractional symbol timing,
• frequency drift,
• signal amplitude,
• phase,
• possibly time offset

simultaneously.

This is very similar philosophically to what we've been doing with your DVB-S2 SOF/PLHEADER detector.

2. Proper soft 8-FSK metrics

This is where I think we could make a significant improvement.

For every data symbol I'd calculate something like:

E0 E1 E2 E3 E4 E5 E6 E7

and convert those eight tone energies into soft bit LLRs.

Because each tone represents three Gray-coded bits, we can calculate the exact bit likelihood:

• LLR(bit0)
• LLR(bit1)
• LLR(bit2)

rather than making a hard decision on the strongest tone. That gives the LDPC decoder substantially better information.

This is analogous to the lesson we found with your DVB-S2 QPSK decoder: the quality and scaling of the soft information going into LDPC can matter enormously.

3. Better LDPC decoding

FT8's code is LDPC(174,91), with the 91 bits consisting of the 77-bit message plus the CRC.

I'd initially implement:

• normalized/offset min-sum,
• sum-product,
• layered scheduling if applicable,
• adaptive damping,
• early termination,
• CRC-assisted termination.

But I'd also investigate OSD / ordered-statistics decoding as a second-stage decoder. That's particularly interesting for FT8 because the block is tiny. Some modern implementations already experiment with BP, OSD and a-priori-assisted decoding.

4. A-priori decoding

This is probably one of the biggest opportunities.

Suppose we know:

CQ G4ABC IO91

or we're in the middle of a QSO and already know one callsign. We don't have to treat all 77 payload bits as completely unknown. We can inject known information into the LDPC decoder. WSJT-X already uses several AP decoding strategies, including known callsigns and known message structures. But we could make this considerably more systematic.

For example:

5. Multi-signal decoding

This is where I'd really like to push it.

Imagine:

We decode A.

Once A is known, we know exactly what waveform A should have produced.

So:

Generate thousands of known FT8 messages at each SNR, with controlled:

• frequency offset
• timing offset
• frequency drift
• AWGN
• fading
• adjacent signals
• overlapping signals

and measure actual decode probability.

That would let us identify where the extra dB are coming from, rather than just saying "it decodes better".

FT8 is already capable of roughly −20 dB-class decoding under suitable conditions, with AP decoding providing additional sensitivity. And I think your existing DSP experience would transfer extremely well.

In particular, the things we've learned with your DVB-S2 work:

soft metrics → synchronization → noise estimation → LLR scaling → iterative decoding

are almost exactly the areas I'd concentrate on here.

I would not start by copying the WSJT-X decoder line-for-line.

I'd start with a clean C++17 implementation:

• Ft8Decoder,
• Ft8Synchronizer,
• Ft8Detector,
• Ft8SoftDemodulator,
• Ft8Ldpc,
• Ft8Message

with AVX2 where it actually helps.

Then we can benchmark each stage independently.

If you're interested, I think the first thing to build should be the FT8 soft demodulator + Costas synchronizer, because that will tell us whether there are meaningful gains available before we spend time on the LDPC side.