I have opened an issue on the gnuradio.org. See the link below http://gnuradio.org/redmine/issues/841
-- Bob On Sat, Sep 12, 2015 at 1:36 PM, bob wole <bnw...@gmail.com> wrote: > 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
