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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to