Correction, I should have said entire 4 bit range instead of 128 bit range, but I hope you got the picture.
Regards, Adrian On 12/31/18, Adrian Musceac <kanto...@gmail.com> wrote: > 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 > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
