Presentation on theme: "Proposal for a FEC-Coded AO-40 Telemetry Link"— Presentation transcript:
1 Proposal for a FEC-Coded AO-40 Telemetry Link 2002 AMSAT Annual MeetingPhil Karn, KA9Q
2 The AO-40 Telemetry Format Same as Phase 3-A (1980)400bps BPSK, suppressed carrierManchester codingno FEC4 byte sync byte data + 2 byte CRC + idleRequires strong, steady signalsHighly susceptible to fadingOne bad bit destroys whole frame
4 Why FEC? Substantially improved link margins Allows one or more of: especially dramatic against fadingAllows one or more of:Reduced spacecraft power ($$)Reduced ground G/T (smaller receive antennas)Improved link margin during off-axis operationHigher data ratesbut not on AO-40 (limited by hardware)Now well within capability of average PC
5 Terminology Forward Error Correction (FEC): Bit: data bit from user Adding redundant info to enable receiver correction of transmission errors without retransmissionBit: data bit from userSymbol: data bit from encoder outputmodems handle symbols, not bitsCode Rate: bit rate / symbol ratee.g., rate ½ = 2 channel symbols per user data bit
6 Eb/N0 : energy per bit / noise spectral density Ebin joules; N0 in watts/Hz = joulesdimensionless, usually expressed in dBaka "digital S/N ratio" or "per bit SNR"Es/N0 : Energy per symbol / noise spectral densityWithout FEC, Eb/N0 = Es/N0With FEC, Es/N0 = Eb/N0 + 10log10(code rate)Es/N0 <= Eb/N0
7 AWGN: Additive White Gaussian Noise Classic model for satellite or deep-space channelNO fading!
8 AO-40 Hardware Constraints 400 bps BPSK, suppressed carrierManchester encodingno benefit or penaltyDifferential encodingturns out to be usefulIHU limitations on memory, CPUnot a problem with chosen scheme
9 FEC Design Requirements Obey AO-40 hardware constraintsAssume Pentium-class PC with soundcard for demodulation and decodingno need to preserve hardware BPSK demodsKeep frame transmission time reasonably shortreduce payload instead to accommodate overheadDesign primarily for fade resistanceGood AWGN performance desirable, but secondary
10 My Design Choices 256 data bytes/frame vs present 512 bytes/frameFrame transmission time: secConcatenated RS-convolutional codeOverall code rate: 0.4; reasonably optimaluser data rate = 0.4 * 400 = 160 bpsScrambling for reliable symbol timing recoveryExtra layer of interleavingalso interleaves sync vector
11 Concatenated Coding Two layered FEC codes Reed-Solomon code + convolutional codebyte interleaver between codesFirst flown on Voyager (1977); standard practice ever sinceNow being slowly replaced with Turbo codingbut turbo codes are still patented
12 Proposed Codes (160,128) Reed-Solomon code (rate 0.8) Shortened from CCSDS standard (255,223) code128 8-bit data symbols bit parity per blockCorrects up to 32/2 = 16 symbol errors/blockRate ½ constraint length 7 convolutional codeCCSDS standard, very widely usedViterbi decodedSteep threshold at Eb/N0 ~= 2.5 dBvs ~10 dB for uncoded BPSK on AWGN
14 Encoder Block Diagram my CCSDS standard addition 256 data bytes 65-bit syncvectorpad3 bitstail6 bits256 data bytes2:1 byteInterleaverScramblerConvolutionalencoderr=1/2 k=7(160,128)Reed-SolomonEncoder65x80 bitblock interleaver5200 channel symbols(2560+6)*2 = 5132 bits8x2x160 = 2560 bitsmyadditionCCSDS standard
15 Coherent BPSK Demodulation Costas or Squaring loop required on suppressed carrier signaltraditionally used on Phase 3Optimum performance on AWGNBad choice on fading channelmay spread outside loop bandwidthsudden carrier phase jumps lose lock
16 Noncoherent BPSK Demodulation Use each symbol as phase reference for nextRequires differential encoding at transmitterPhase 3 already does this in hardwareEasy to implement in both SW and HW"Instant" lockupExcellent fade performanceTheshold effect, much like FMsmall (~0.5 dB) penalty at Es/N0 = 10 dBSo why are most Phase 3 demods coherent??
17 Prototype Encoder: ~1kB code + ~2kB RAM Decoder libraries: fits easily into IHUDecoder libraries:Viterbi decoder in C/MMX/SSE/SSE2~14 Mb/s on 1.8 GHz P4Reed-Solomon codec in CGeneral purpose DSP (filtering, etc)Prototype demod/decoder in C< 1% of 1GHz PIII when locked
19 Fading PerformanceTested configuration: 3.3 Hz sinusoidal envelope, 2 nulls/cycleEb/N0 = 8 dB (2 dB worse than AWGN)Actual performance depends on fade envelopeslow fading worse than fast fadingshort fades more tolerable than long fadesfade depth irrelevant
20 Status Linux prototype developed and working all software open source GPLDecoder should be easily portedto AO40RCV, etcEncoder in IPS neededIPS-like code in C writtenRestructure IPS pseudo-DMA subsystemeliminate inter-frame paddingdesirable, not absolutely necessary
21 Planned Improvements Equalizer for AO-40 transmit filter ~1 dB ISI loss with current matched filterImplement coherent demodulatorUse noncoherent first, switch to coherent if necessaryImprove performance on weak nonfading signals
22 Thoughts on Future Links Not constrained by existing AO-40 hardwareFEC is now a no-brainershould be mandatory on all future AMSAT links!Adapt design to specific requirementsuplinks and downlinks may use different modulation & codingencoding easier than decoding
23 Future Modulation Choices BPSK still ideal for low speed linksQPSK for high rate links (rate >> freq uncertainty)Noncoherent demod for fading linksbut threshold effect limits coding gainAdd residual carrier on low speed linksfind with FFT, track with simple PLLManchester keeps data away from carrieravoid squaring losses of Costas and squaring loopsessential for low Es/N0 ratios of strong, low rate FEC codes
Your consent to our cookies if you continue to use this website.