The path from raw baseband samples to a structured telemetry frame that your mission control system can actually read is longer and more fragile than most mission teams realize until something in the middle breaks. A CubeSat ground system that "receives telemetry" is really running a chain of five or six distinct processing stages, each of which can fail independently, and each of which has its own configuration parameters, edge cases, and failure modes.

In our experience, about a third of the "we lost telemetry" reports we see from operators are actually decoder chain misconfiguration problems, not RF link problems. The satellite is transmitting fine. Something in the chain from raw samples to parsed frames is broken. Understanding that chain — how it's structured, where the failure points are, and how to diagnose them — is foundational knowledge for anyone running a CubeSat ground operation.

Stage One: RF Front-End and Baseband Sampling

The decoder chain starts at the antenna output. After the low-noise amplifier (LNA) and any bandpass filtering, the signal reaches a software-defined radio (SDR) or dedicated modem front-end that performs downconversion and analog-to-digital conversion. The output is a complex baseband sample stream — typically at a sample rate of 100 kHz to 10 MHz depending on the signal bandwidth.

At this stage, the primary configuration parameters are the center frequency (which must account for Doppler offset), the sample rate (which must satisfy Nyquist for the signal bandwidth), and the gain settings. Automatic gain control (AGC) is common but has edge cases: if the AGC time constant is too long, the receiver oversaturates on the first strong signal burst and clips the useful signal. For CubeSat TT&C at S-band with a 2 W transmitter and a 3.7 m dish at 500 km range, received power can vary by 15-20 dB across a pass from horizon to zenith — more than most AGC designs handle gracefully without tuning.

Stage Two: Demodulation

The complex baseband sample stream feeds into the demodulator, which recovers the bit stream from the modulated carrier. For most CubeSat missions using standard commercial modems, this means BPSK, QPSK, or GMSK demodulation. The demodulator's job is carrier frequency recovery, symbol timing recovery, and bit decision.

Carrier frequency recovery is where Doppler compensation matters at the demodulation stage. If the open-loop Doppler pre-correction at the front-end has left a residual offset of more than about half the symbol rate, the carrier recovery loop will struggle to acquire. For a 9.6 kbps BPSK signal with a 9.6 kHz symbol rate, a residual Doppler error of more than ±5 kHz will prevent acquisition. A residual error of ±1 kHz typically acquires in 2-4 symbol periods.

Symbol timing recovery establishes the sample clock relationship to the transmitted symbol boundaries. This requires a stable sample clock or a timing recovery loop. Most SDR implementations include a timing error detector (typically a Mueller-Müller or early-late detector) followed by a digital interpolation filter. The loop bandwidth is a key parameter: narrow bandwidths give better noise performance but slower acquisition; wide bandwidths acquire fast but amplify timing jitter.

Stage Three: Forward Error Correction Decoding

After demodulation produces a bit stream, forward error correction (FEC) decoding repairs errors introduced by the RF channel. The FEC scheme is defined by the mission's link layer protocol. For CubeSat missions using CCSDS standards, the most common options are:

  • CCSDS Reed-Solomon (255, 223): Corrects up to 16 byte errors per 255-byte codeword. A classic block code that's been standard in spacecraft communications since the 1980s. Decoder implementation is straightforward; the Berlekamp-Massey algorithm is well-characterized.
  • CCSDS Turbo codes: Substantially better coding gain (approaching Shannon limit) but more complex decoder implementation. Iterative decoding with 8-16 iterations is common; each iteration adds latency. At 10 Mbps downlink throughput, a 16-iteration turbo decoder needs to process roughly 160 Mbps of soft decisions.
  • LDPC (Low-Density Parity Check): Increasingly common in newer CCSDS specifications and many commercial CubeSat modems. Good performance in AWGN channels; decoder complexity is manageable in modern FPGAs.

The FEC decoder configuration must exactly match the spacecraft's encoding configuration. Constellation operators who inherit a satellite design often find that the modem firmware version on the spacecraft doesn't match what the documentation says — and that the FEC parameters differ by one iteration count or one interleaver depth from what the ground decoder expects. The result is a decoded bit stream that looks like valid CCSDS framing but produces a constant stream of uncorrectable frame errors. This is one of the harder failure modes to diagnose because the RF metrics (SNR, BER pre-FEC) look completely normal.

Our standard advice: during integration testing, run the full decoder chain against the actual flight modem firmware before any RF testing begins. A bench test that drives the SDR input with a signal generator at known SNR, runs through the full decoder chain, and parses real telemetry frames is the most reliable way to verify that all FEC parameters are consistent end-to-end.

Stage Four: Frame Synchronization and CCSDS Frame Processing

After FEC decoding, the recovered bit stream is a continuous sequence of bits with no explicit frame boundaries. Frame synchronization identifies the start of each CCSDS Transfer Frame by searching for the Attached Sync Marker (ASM) — a known 32-bit sequence (0x1ACFFC1D for CCSDS standard) that precedes every frame. The frame sync correlator slides a window across the bit stream and compares against the ASM pattern, allowing for a configurable number of bit errors (typically 1-2 bits are allowed to handle channel errors in the ASM itself).

Once frame synchronization is established ("in-lock" state), the decoder moves to "verify" mode — it expects the next ASM at exactly the frame-length offset from the previous one. This reduces false sync detections dramatically. For a 1024-byte frame with a 32-bit ASM, the probability of a random bit sequence matching the ASM with 0 errors is 2^-32, which is negligible. With 2 bits allowed, it's still less than 10^-7 per frame.

The CCSDS Transfer Frame contains a primary header with the spacecraft ID, virtual channel ID, frame counter, and other routing metadata. The frame counter is particularly useful for diagnosing reception gaps — if you receive frame 1247 followed by frame 1251, you know frames 1248-1250 were not received, and you can quantify the actual packet loss rate rather than estimating from BER alone.

Stage Five: Space Packet Processing and Telemetry Parsing

The CCSDS Transfer Frame payload carries Space Packets (CCSDS Space Packet Protocol), which in turn contain application-layer telemetry data. Space Packets have their own header (with APID identifying the telemetry source) and may span multiple Transfer Frames (segmentation/reassembly) or be contained within a single frame.

At this stage, the decoder chain hands off to mission-specific software: a telemetry parser that interprets the binary payload against the spacecraft's database definition (often stored as an XTCE XML schema or a proprietary MIB file). This is the last stage before your mission control system sees recognizable engineering values like "battery voltage: 7.42 V" or "attitude mode: nadir-pointing".

The most common failure at this stage is a mismatch between the ground telemetry database and the actual spacecraft telemetry format — a parameter added to flight software after the database was last updated, or an endianness inconsistency in a specific parameter. Unlike RF-layer failures, this type of failure is completely silent: the decoder chain reports a successful frame reception, but the telemetry value for the affected parameter is garbage.

Monitoring the Chain End-to-End

A well-instrumented decoder chain exposes metrics at each stage: sample rate and ADC saturation count at the front end; carrier frequency offset and symbol timing error at the demodulator; pre-FEC and post-FEC BER from the FEC decoder; sync lock status and frame error rate from the frame sync stage; Space Packet reception count and reassembly errors from the packet layer. Together, these metrics let you locate a failure to a specific stage in under 2 minutes during a contact window.

For operators integrating with the Orbitvein network, we expose these stage-level metrics through the station telemetry API in real time during contacts, not just in post-pass summaries. The ability to see "demodulator acquired at T+3s, FEC BER 1.2e-4, frame sync locked at T+5s, 847 frames received in 480 seconds" gives a complete health picture of the reception chain for every pass, which is the foundation for meaningful contact reliability trending.

The decoder chain isn't glamorous infrastructure. But it's the last thing standing between your satellite's transmitted bits and your mission control system's telemetry display. Understanding each stage, its failure modes, and its diagnostic metrics is the kind of knowledge that pays off quietly — most of the time, everything works and you never think about it. When something fails, having this mental model tells you exactly where to look.