Hey Jan, Thanks for your reply, you are correct about the bit shift being LSB. So, I reversed the bit order of polynomials 1101101 to 1011011 and 1001111 to 1111001 in MATLAB, Now the output of gnuradio and MATLAB and my dry run matches. I am wondering why they did implementation like this? Any advantages?
Yeah, I too was hoping for a reply from Tom and Nick on this. -- Bob On Tue, Sep 8, 2015 at 12:37 PM, Jan Krämer <kraemer...@gmail.com> wrote: > Also I think Tom and Nick Foster for sure know more about it than I do. > > Cheers, > Jan > > 2015-09-08 8:44 GMT+02:00 Jan Krämer <kraemer...@gmail.com>: > >> Hey Bob, >> >> I have the same issues with my SSE Viterbi, works with gr-trellis but not >> with cc_encoder in gr-fec. The output of the cc_encoder is legit though. >> I talked to a couple of guys about this at last year's GRCON. It seems >> that in most implementations, the bit order of the polynomials is reversed >> when compared to the textbook approach. >> Therefor also the bit shifting in the encoding process (and the viterbi >> chainback) is also reversed. I think textbook is MSB while cc_encoder is >> LSB but I always mix them up xD. >> But you can check >> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc >> beginning from line 166. >> >> Hope that helps, >> Jan >> >> 2015-09-08 8:12 GMT+02:00 bob wole <bnw...@gmail.com>: >> >>> >>> >>> On Tue, Sep 1, 2015 at 2:55 PM, bob wole <bnw...@gmail.com> wrote: >>> >>>> I am trying channel coding in gnuradio. I am using convolutional >>>> encoder with K=7 and R=1/2 with polynomials [109, 79] (default). However I >>>> am not getting the expected result. I input a known bit sequence, single >>>> frame using head block, and observe the output of the encoder using file >>>> sink. The output I think is not correct according to the given polynomials. >>>> Input bit stream is >>>> >>>> http://pastebin.com/thsYtLFG >>>> >>>> I am getting this output >>>> >>>> http://pastebin.com/P42QNjiE >>>> >>>> However, I am expecting (in hex) >>>> >>>> 00 00 E3 32 63 D7 4B FA D3 ...... >>>> >>>> >>>> I have attached the flowgraph I am using for this purpose. I did a dry >>>> run by drawing a diagram of the encoder and inputing initial two bytes. >>>> Diagram of the encoder is also attached. I also used MATLAB script to test >>>> and found that my dry run output matches with MATLAB but not with Gnuradio >>>> output. I also played with the endianness but could not get the desired >>>> result. Maybe I am doing something wrong in configuring the encoder? >>>> >>>> >>>> Also another thing I noticed is that in QA codes of gr-fec I found >>>> >>>> import fec_swig as fec >>>> import blocks_swig as blocks >>>> >>>> I think this should be >>>> >>>> from gnuradio import fec, blocks >>>> >>>> Am I right? I am using gnuradio 3.7.8. >>>> >>>> -- >>>> Bob >>>> >>> >>> >>> I am still waiting to get a reply on this. Anyone else verified the >>> output of the convolutional encoder? >>> >>> >>> -- >>> Bob >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
