[Discuss-gnuradio] Question regarding convolutional decoder usage in FEC extended decoder API

[Adrian Musceac]

Hi,

I'm sorry I didn't have much time to research the intricacies of the
convolutional decoder implementation, but I have a question coming
more from the user perspective regarding the optimal way of using the
API.

In the default implementation of the extended decoder (
https://github.com/gnuradio/gnuradio/blob/master/gr-fec/python/fec/extended_decoder.py
) the canonical way seems to be to multiply the input (which is
assumed to be symbols scaled close to -1, 1 range) with 48, and then
to add 128 to bring into unsigned char 128 bit per symbol range.
This works fine, except it exhibits what seems like a very abrupt
cliff at about 3 db Eb/N0.

I had the idea that comparatively large momentary noise amplitudes at
this treshhold might cause a char overflow, so I modified this a
little: instead of passing the unaltered symbol into the decoder, I
clipped it to (-1, 1) with a rail_ff block and multiplied with 128 in
an attempt to reserve the full 128 bit range of the decoder to the
most ambiguous symbols while avoiding the char overflow. This seems to
cause a more gentle degradation of the BER instead of the abrupt slope
from before and maybe a little improvement in BER (not verified, could
be bogus).

I thought that either this is a good idea and might benefit more
people, or I'm ignoring some subtleties of the Viterbi algorithm and I
should be corrected because I'm doing something wrong.

Thanks,
Adrian