Proposal for a FEC-Coded AO-40 Telemetry Link 2002 AMSAT Annual Meeting Phil Karn, KA9Q karn@ka9q.net http://www.ka9q.net

The AO-40 Telemetry Format Same as Phase 3-A (1980) 400bps BPSK, suppressed carrier Manchester coding no FEC 4 byte sync + 512 byte data + 2 byte CRC + idle Requires strong, steady signals Highly susceptible to fading One bad bit destroys whole frame

Uncoded BPSK Performance

Why FEC? Substantially improved link margins Allows one or more of: especially dramatic against fading Allows one or more of: Reduced spacecraft power ($$) Reduced ground G/T (smaller receive antennas) Improved link margin during off-axis operation Higher data rates but not on AO-40 (limited by hardware) Now well within capability of average PC

Terminology Forward Error Correction (FEC): Bit: data bit from user Adding redundant info to enable receiver correction of transmission errors without retransmission Bit: data bit from user Symbol: data bit from encoder output modems handle symbols, not bits Code Rate: bit rate / symbol rate e.g., rate ½ = 2 channel symbols per user data bit

Eb/N0 : energy per bit / noise spectral density Ebin joules; N0 in watts/Hz = joules dimensionless, usually expressed in dB aka "digital S/N ratio" or "per bit SNR" Es/N0 : Energy per symbol / noise spectral density Without FEC, Eb/N0 = Es/N0 With FEC, Es/N0 = Eb/N0 + 10log10(code rate) Es/N0 <= Eb/N0

AWGN: Additive White Gaussian Noise Classic model for satellite or deep-space channel NO fading!

AO-40 Hardware Constraints 400 bps BPSK, suppressed carrier Manchester encoding no benefit or penalty Differential encoding turns out to be useful IHU limitations on memory, CPU not a problem with chosen scheme

FEC Design Requirements Obey AO-40 hardware constraints Assume Pentium-class PC with soundcard for demodulation and decoding no need to preserve hardware BPSK demods Keep frame transmission time reasonably short reduce payload instead to accommodate overhead Design primarily for fade resistance Good AWGN performance desirable, but secondary

My Design Choices 256 data bytes/frame vs present 512 bytes/frame Frame transmission time: 13.00 sec Concatenated RS-convolutional code Overall code rate: 0.4; reasonably optimal user data rate = 0.4 * 400 = 160 bps Scrambling for reliable symbol timing recovery Extra layer of interleaving also interleaves sync vector

Concatenated Coding Two layered FEC codes Reed-Solomon code + convolutional code byte interleaver between codes First flown on Voyager (1977); standard practice ever since Now being slowly replaced with Turbo coding but turbo codes are still patented

Proposed Codes (160,128) Reed-Solomon code (rate 0.8) Shortened from CCSDS standard (255,223) code 128 8-bit data symbols + 32 8-bit parity per block Corrects up to 32/2 = 16 symbol errors/block Rate ½ constraint length 7 convolutional code CCSDS standard, very widely used Viterbi decoded Steep threshold at Eb/N0 ~= 2.5 dB vs ~10 dB for uncoded BPSK on AWGN

FEC Performance

Encoder Block Diagram my CCSDS standard addition 256 data bytes 65-bit sync vector pad 3 bits tail 6 bits 256 data bytes 2:1 byte Interleaver Scrambler Convolutional encoder r=1/2 k=7 (160,128) Reed-Solomon Encoder 65x80 bit block interleaver 5200 channel symbols (2560+6)*2 = 5132 bits 8x2x160 = 2560 bits my addition CCSDS standard

Coherent BPSK Demodulation Costas or Squaring loop required on suppressed carrier signal traditionally used on Phase 3 Optimum performance on AWGN Bad choice on fading channel may spread outside loop bandwidth sudden carrier phase jumps lose lock

Noncoherent BPSK Demodulation Use each symbol as phase reference for next Requires differential encoding at transmitter Phase 3 already does this in hardware Easy to implement in both SW and HW "Instant" lockup Excellent fade performance Theshold effect, much like FM small (~0.5 dB) penalty at Es/N0 = 10 dB So why are most Phase 3 demods coherent??

Prototype Encoder: ~1kB code + ~2kB RAM Decoder libraries: fits easily into IHU Decoder libraries: Viterbi decoder in C/MMX/SSE/SSE2 ~14 Mb/s on 1.8 GHz P4 Reed-Solomon codec in C General purpose DSP (filtering, etc) Prototype demod/decoder in C < 1% of 1GHz PIII when locked

AWGN Performance Uncoded BPSK demod, ideal Eb/N0 = Es/N0 = 10 dB FEC, differential PSK demod, measured Eb/N0 = 6dB; Es/N0 = 2 dB 3 dB worse than coherent PSK Link margin still 8dB better

Fading Performance Tested configuration: 3.3 Hz sinusoidal envelope, 2 nulls/cycle Eb/N0 = 8 dB (2 dB worse than AWGN) Actual performance depends on fade envelope slow fading worse than fast fading short fades more tolerable than long fades fade depth irrelevant

Status Linux prototype developed and working all software open source GPL Decoder should be easily ported to AO40RCV, etc Encoder in IPS needed IPS-like code in C written Restructure IPS pseudo-DMA subsystem eliminate inter-frame padding desirable, not absolutely necessary

Planned Improvements Equalizer for AO-40 transmit filter ~1 dB ISI loss with current matched filter Implement coherent demodulator Use noncoherent first, switch to coherent if necessary Improve performance on weak nonfading signals

Thoughts on Future Links Not constrained by existing AO-40 hardware FEC is now a no-brainer should be mandatory on all future AMSAT links! Adapt design to specific requirements uplinks and downlinks may use different modulation & coding encoding easier than decoding

Future Modulation Choices BPSK still ideal for low speed links QPSK for high rate links (rate >> freq uncertainty) Noncoherent demod for fading links but threshold effect limits coding gain Add residual carrier on low speed links find with FFT, track with simple PLL Manchester keeps data away from carrier avoid squaring losses of Costas and squaring loops essential for low Es/N0 ratios of strong, low rate FEC codes