Okay. I registered my self at gnuradio.org. Do I have to open a new Issue on the website?
-- Bob > Jan, Bob, > > might be worth opening a ticket for this. > > M > On 10.09.2015 00:22, bob wole wrote: > > 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 > > <mailto: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 > > <mailto: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 > > <mailto:bnw...@gmail.com>>: > > > > > > > > On Tue, Sep 1, 2015 at 2:55 PM, bob wole <bnw...@gmail.com > > <mailto: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
