Why Forward Error Correction Is Not Optional in Satellite Links

By | Monday, August 24, 2026

Forward error correction, or FEC, is the deliberate addition of structured redundancy to a digital bitstream so a receiver can detect and correct symbol errors without asking the transmitter for a retransmission. On a satellite link, where one-way delays run from roughly 120 ms for LEO to more than 500 ms for GEO, and where retransmission protocols such as TCP can collapse under long round-trip times, FEC is not a performance enhancement. It is the difference between a link that closes and a link that exists only on a spreadsheet. This article is for RF engineers, ground segment integrators, and system architects who work with C-band through Ka-band commercial, government, and deep-space systems. We will look at why FEC belongs in the link budget from the first draft, how coding gain behaves in real modems, and where FEC does and does not solve your problems.

Satellite dish against a clear sky, representing a ground station link
A ground station antenna is only as useful as the coding scheme behind its modem.

FEC in the Link Budget: Coding Gain Is Not Magic

Every link budget starts with the same arithmetic: EIRP minus path loss plus receive antenna gain minus system noise, then compare the result with the required Eb/No or Es/No for the modulation and code rate you have chosen. FEC changes the required Eb/No. A rate 1/2 LDPC code with QPSK might need an Es/No of 1.0 dB where an uncoded QPSK signal needs 9.6 dB for the same bit error rate. That difference, roughly 8.6 dB, is coding gain. It is not free power. It is a trade of bandwidth or symbol rate for resilience.

When I review a link budget from a new integrator, the first thing I check is whether the FEC code rate and modulation are consistent with the occupied bandwidth and the actual modem implementation. A budget that says “DVB-S2X, 32APSK 3/4, 2.5 dB margin” but does not mention the LDPC block length, pilot symbols, or roll-off is a wish, not a budget. The modem matters. A 64k LDPC block will behave differently from a 16k block in the presence of phase noise and short bursts of interference. The arithmetic of coding gain is only the beginning.

Why Retransmission Cannot Replace FEC on a Satellite Link

Terrestrial networks lean on retransmission. If a packet fails a CRC check, the receiver asks for it again. That works when the round-trip time is 20 ms and the packet loss rate is low. On a GEO link, the propagation delay alone is about 250 ms one way. A retransmission costs at least 500 ms, often more when you add scheduling, queuing, and modem processing. TCP throughput over a 500 ms RTT with even 0.1% packet loss can drop to a small fraction of the link rate. FEC reduces the packet loss seen by the upper layers, which keeps TCP from backing off. That is not a protocol tweak; it is physics.

For deep-space links, the argument is even stronger. The one-way light time to Mars varies from about 3 minutes to over 22 minutes. Retransmission is operationally absurd for real-time telemetry or command verification. NASA and ESA deep-space missions have used concatenated coding schemes—Reed-Solomon over convolutional codes, then turbo codes, now LDPC—for decades because the alternative is waiting half an hour to find out that a single bit flipped. The DSN’s standard telemetry coding is not optional; it is part of the mission design.

Large satellite dish at night, symbolizing long-distance space communication
Long one-way delays make retransmission impractical; FEC must do the work.

What FEC Actually Corrects—and What It Does Not

FEC corrects random symbol errors caused by thermal noise, modest phase noise, and low-level interference. It does not correct a 20 dB rain fade, a mispointed antenna, or an interfering carrier that sits on top of your signal. I have seen operators add more FEC to a link that was suffering from a saturated LNB or a bad waveguide run. The result was a lower data rate and the same outage. FEC is not a substitute for linearity, pointing accuracy, or spectral hygiene.

Interleaving changes the picture. A block code without interleaving will fail when a burst of errors hits many symbols in one codeword. Interleaving spreads those errors across multiple codewords so the decoder sees a manageable number of errors per block. That is why DVB-S2 and DVB-S2X include time interleaving options, and why deep-space systems use long interleavers. The cost is latency. A deep interleaver can add hundreds of milliseconds or more. For a broadcast video link, that is fine. For a real-time command link, it may not be.

Code Families You Will Meet in the Field

In commercial C-band and Ku-band, DVB-S2 and DVB-S2X dominate. They use LDPC inner codes with BCH outer codes. The LDPC block length is typically 16,200 or 64,800 bits. The shorter block has lower latency and slightly worse coding gain. The longer block has better gain but more delay and more sensitivity to phase noise. In Ka-band government systems, you will also see turbo product codes and, increasingly, CCSDS LDPC codes. The CCSDS 131.0-B series defines LDPC codes for near-Earth and deep-space applications. The code rate and block size are not interchangeable between vendors, even when the numbers look the same on a datasheet.

Reed-Solomon still appears as an outer code in many legacy systems. A (255,223) RS code can correct up to 16 byte errors per codeword. It is simple, well understood, and easy to implement in hardware. But its coding gain is modest compared with modern LDPC or turbo codes. If you are designing a new link, RS alone is rarely the right choice. If you are maintaining an old one, it may be the only choice the existing modems support.

Modulation, Code Rate, and the Real Meaning of Spectral Efficiency

FEC and modulation are a pair. You cannot choose 16APSK and then bolt on a rate 1/2 code and expect the same occupied bandwidth. The code rate determines how many information bits you get per symbol. A rate 3/4 code with 8PSK gives 2.25 bits per symbol. A rate 1/2 code with QPSK gives 1 bit per symbol. The first is more spectrally efficient; the second is more resilient. The link budget must show both the required Es/No and the resulting data rate. Too many proposals show a data rate and a modulation but leave the code rate as an afterthought.

Adaptive coding and modulation (ACM) is standard in DVB-S2X systems. The modem measures the return channel SNR and switches between MODCODs—modulation and code rate pairs—to keep the link alive during rain fade or interference. ACM works well for IP trunking and broadcast contribution. It works less well for fixed-rate circuits where the user has bought a specific data rate and does not want it to drop by 30% during a storm. In those cases, you design for the worst-case fade and accept the lower clear-sky throughput. FEC is part of that trade, not a way around it.

Rack-mounted satellite modem equipment with indicator lights
Modem choice determines the real FEC performance, not just the datasheet number.

Practical Rules for Ground Segment Engineers

First, put FEC in the link budget from the start. Do not design an uncoded link and then “add coding” later. The required Eb/No, the occupied bandwidth, the modem latency, and the ACM behavior all depend on the code choice. Second, verify the modem’s actual implementation. Ask for the LDPC block length, the number of decoding iterations, and the measured performance curve, not just the theoretical Shannon limit. Third, test with real impairments. A modem that performs well in AWGN may fall apart with phase noise from a cheap BUC or a noisy LNB. Fourth, remember that FEC adds latency. If your link carries voice or real-time control traffic, the interleaver and decoder delay may be unacceptable. Fifth, do not use FEC to mask a bad RF chain. Fix the nonlinearity, the phase noise, and the interference first. Then let FEC do its job on the residual errors.

FAQ

How much coding gain can I expect from modern LDPC codes?

For a rate 1/2 LDPC code with QPSK, a well-implemented decoder can achieve a bit error rate of 10-7 at an Eb/No of roughly 1.0 to 1.5 dB. An uncoded QPSK signal needs about 9.6 dB Eb/No for the same BER. That is about 8 dB of coding gain. Higher code rates give less gain but more throughput. A rate 9/10 LDPC code might give only 1 to 2 dB of gain over uncoded modulation. The exact number depends on block length, decoder iterations, and implementation losses.

Does FEC help against interference or only against noise?

FEC helps against noise-like interference that raises the effective noise floor. It does not help against a strong carrier that saturates the receiver or a bursty interferer that wipes out entire codewords. Interleaving can spread burst errors, but only up to a point. If the interference is 10 dB above your signal, no practical code will recover the data. Interference mitigation—filtering, spatial nulling, or coordination—must happen before FEC can be effective.

What is the latency cost of FEC in a typical DVB-S2X link?

The latency depends on the LDPC block length, the interleaver depth, and the decoder implementation. A 16,200-bit LDPC block at 10 Msymbol/s with QPSK takes about 0.8 ms to transmit. A 64,800-bit block takes about 3.2 ms. Decoder latency can add a few milliseconds. Time interleaving in DVB-S2X can add tens to hundreds of milliseconds. For broadcast video, this is irrelevant. For real-time voice or control, you may need to disable interleaving and use short blocks, accepting a small loss in coding gain.

Next Steps for This Site

This article is part of a series on link budget fundamentals for satellite ground segments. A natural follow-up is a detailed walkthrough of a DVB-S2X link budget with real numbers, including the MODCOD table and the effect of roll-off on occupied bandwidth. I will also add a glossary entry for coding gain and a comparison of LDPC block lengths in commercial modems. If you have a specific modem or code rate you want tested, send a note through the contact page.