Replying to myself since I've actually taken the time to read the code instead of asking stupid questions. There is no need for the rail block since the clipping is done in the float to uchar conversion. The range is 7 bits per symbol since one of the bits of the uchar is acting like a sign bit, and the real question I have is how was the number by which to multiply the symbol value derived, since this looks like it depends on the signal scaling (AGC)?
Thanks, 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
