Proposal for aFEC-Coded AO-40 Telemetry Link
2002 AMSAT Annual MeetingPhil Karn, [email protected]
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