Forward Error Correction (FEC)
Adding structured redundancy at the transmitter so the receiver can repair damage alone, with nothing to ask again. The reason a deep-space downlink, a broadcast, or a capture you recorded yesterday can survive a channel that corrupts bits.
Forward error correction (FEC) adds structured redundancy to a message before it is sent, so that a receiver can repair a corrupted copy on its own, without asking for a retransmission. It is the answer to a channel that damages bits and a link that has nobody to ask: a deep-space probe, a broadcast, a beacon, or a capture you recorded yesterday and cannot re-request.
What it is
Two strategies exist for bits that arrive wrong. Detection (parity, checksum, CRC) tells you something is broken and stops there, which is only useful when you can ask again. Correction adds enough structure that the receiver can work out what was sent. A single parity bit detects every odd number of flips and no even number at all, and it can never say where the error is, so it can never repair anything.
What decides repair is Hamming distance, the number of single-bit flips between the two closest legal codewords. A code with distance d detects d - 1 errors or corrects (d - 1) / 2 of them. The (7,4) Hamming code has d = 3, so it fixes one bit per block, and on two errors it confidently produces the wrong answer.
Why it matters
Anything you capture off the air is coded. A downlink you cannot decode is very often a correctly received but still-coded bitstream, and the layers have to be peeled in the right order before any of it makes sense. Understanding FEC also explains why a link stays up in conditions that look impossible, why a protocol pays 14 percent or 200 percent more airtime for the same payload, and why past a certain error rate a code stops helping and just costs you.
Code rate and the cliff
A code takes k data symbols and emits n coded symbols; the ratio k/n is the code rate. Rate 0.87 means 14.3 percent more airtime, rate 1/3 means three times the airtime. Systematic codes leave the original data readable in the first k symbols, which is why you can often spot ASCII inside a coded capture. Every code also has a cliff: below its design error rate it is nearly magic, past it the decoder starts producing confident, wrong output.
The two repairing families
- Block codes work on fixed chunks. Reed-Solomon works on symbols rather than bits, which is why it eats bursts:
RS(255,223)repairs any 16 damaged bytes in a block, so 128 consecutive wrecked bits (16 symbols) are fixed while 17 scattered single-bit errors touching 17 symbols are not. - Convolutional codes have no blocks. The encoder slides a window over the stream, so each output depends on the current bit and the last few, and the message is smeared across the channel. Decoding is a search: the Viterbi algorithm walks a trellis of encoder states and keeps only the best path into each one. The result survives scattered errors and dies on consecutive ones.
Real downlinks concatenate the two, an inner convolutional code and an outer Reed-Solomon code, with interleaving in between that spreads any single fade across several codewords.
Pitfalls
- A CRC never repairs. It is detection, and its parameters (polynomial, init value, input and output reflection, final XOR) change the answer completely, so "CRC-16" names nothing on its own.
- Reed-Solomon parameters are not guessable. The field polynomial, the first consecutive root, and the symbol order all have to match the sender. This is exactly where CCSDS downlink decoding usually fails.
- Peel the layers in order. Randomiser, then Reed-Solomon, then interleaver, then Viterbi, in the reverse order of the transmitter. Out of order, every stage produces noise.
- Past the cliff, a decoder lies. It does not report "too many errors", it emits a plausible wrong message, which is far more dangerous than a clean failure.