discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Repeatability of FEC Decoder Decisions


From: Greg Rendon
Subject: [Discuss-gnuradio] Repeatability of FEC Decoder Decisions
Date: Mon, 26 Mar 2018 16:02:36 +0000

I'm working on a satellite radio downlink implementation that uses the CCSDS recommended error correction, i.e. 7, 1/2, (109,79) inner convolution code and Reed-Solomon (255,223) outer code.  I'm using the suggested FECAPI set (FEC Extended Decoder, CC Decoder definition) for my inner decoder.  To generate some metric on the symbol decisions from the receiver I'm re-encoding the extended decoder output using the FEC Extended Encoder and CC Encoder definition.  I'm acquiring a BER by providing packed bits to the BER block. However, I can't seem to get my bit error rate lower than log10(-1.2).  Running individual block checks I found that supplying the same input to two identical decoders results in a minimum BER around log10(-1.24), i.e. the decoder results do not seem to be very consistent.

To isolate the decoder I generated a test flowgraph (attached) with a (Gaussian) random input to a constellation soft decoder, into a pair of identical decoders and found that the BER is inversely related to the frame size as defined in the CC Decoder definition.  Additionally, observing the output bitstreams of the two decoders it can be seen that decision disagreements are concentrated near, though not exclusively at frame edges.  I've tried using all four available streaming behavior options, with and without byte padding, and all options have roughly the same BER for a given frame size.

I'm still educating myself on Viterbi decoding, particular for streaming implementations, but it seems that these results are (hopefully) anomalous.  At the very least, they are problematic.  I'll keep chugging away at this, but if anyone could provide insight/clarification I would be most appreciative.  In particular,
-  Is there some resource already available in GNURadio literature that I've missed that addresses this?
-  Is there something I'm doing wrong or misunderstanding about the Viterbi algorithm or how FEC should be implemented in GNURadio that would explain this behavior?
-  If not, perhaps this an issue with how the blocks handle data between calls to work() and/or something in the butterfly setup?  If so, suggestions on debugging?
-  Something else blatantly obvious that I've overlooked?

Thanks,
Greg

Attachment: greg_fec_decoder_test.grc
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]