Transcript Power Point format

Proposal for a
FEC-Coded AO-40 Telemetry Link
2002 AMSAT Annual Meeting
Phil Karn, KA9Q
[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/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
–
●
Differential encoding
–
●
no benefit or penalty
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
–
●
Keep frame transmission time reasonably short
–
●
no need to preserve hardware BPSK demods
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
65-bit
sync
vector
tail
6 bits
pad
3 bits
256 data bytes
(160,128)
Reed-Solomon
Encoder
2:1 byte
Interleaver
Scrambler
Convolutional
encoder
r=1/2 k=7
65x80 bit
block interleaver
5200 channel symbols
(2560+6)*2 = 5132 bits
8x2x160 = 2560 bits
CCSDS standard
my
addition
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
–
●
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
–
●
Decoder should be easily ported
–
●
to AO40RCV, etc
Encoder in IPS needed
–
●
all software open source GPL
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
–
●
Noncoherent demod for fading links
–
●
QPSK for high rate links (rate >> freq uncertainty)
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