Proposal for aFEC-Coded AO-40 Telemetry Link

2002 AMSAT Annual MeetingPhil Karn, KA9Qkarn@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– 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):– 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/N

0 : energy per bit / noise spectral density

– Ebin joules; N

0 in watts/Hz = joules

– dimensionless, usually expressed in dB– aka "digital S/N ratio" or "per bit SNR"

● Es/N

0 : Energy per symbol / noise spectral density

– Without FEC, Eb/N

0 = E

s/N

0

– With FEC, Es/N

0 = E

b/N

0 + 10log

10(code rate)

– Es/N

0 <= E

b/N

0

● 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/N

0 ~= 2.5 dB

– vs ~10 dB for uncoded BPSK on AWGN

FEC Performance

Encoder Block Diagram

2:1 byteInterleaver

(160,128)Reed-SolomonEncoder

Convolutionalencoderr=1/2 k=7

65x80 bitblock interleaver

65-bitsyncvector

8x2x160 = 2560 bits

tail6 bits

(2560+6)*2 = 5132 bits

5200 channel symbols

pad3 bits

Scrambler

256 data bytes

CCSDS standard myaddition

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/N

0 = 10 dB

– So why are most Phase 3 demods coherent??

Prototype

● Encoder: ~1kB code + ~2kB RAM– 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– E

b/N

0 = E

s/N

0 = 10 dB

● FEC, differential PSK demod, measured– E

b/N

0 = 6dB; E

s/N

0 = 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– E

b/N

0 = 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/N

0 ratios of strong, low rate FEC codes