Yeah, I was as surprised as you that Matlab got the order wrong!
No, all jokes aside, I think both orders are as valid. But I also agree that this must be documented! So, http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__encoder.html says > A common convolutional encoder uses K=7, Rate=1/2, Polynomials=[109, > 79]. This is the Voyager code from NASA: > > * 109: b(1101101) –> 1 + x + x^3 + x^4 + x^6 > * 79: b(1001111) –> 1 + x^3 + x^4 + x^5 + x^6 > I'll happily include the sentence "This bit order might not be what is used in other softwares". Do you have any better way off putting it? The reason it's in this order is that this order is relatively handy in the general_work, i.e. the actual encoding process, but that's basically but an opinion. We could change that, but it'd be a serious API breakage, and thus, I personally don't think we should. Best regards, Marcus On 23.11.2016 00:07, Eugene Grayver wrote: > > Hello, > > > I just found out that the polynomial definition convention used by the > GR cc_encoder and decoder is bit *reverse * of the 'standard' > convention. The standard convention (e.g. Matlab, Xilinx) pushes data > bits from MSB to LSB, while the GR pushes LSB to MSB. At the very > least this should be called out LOUDLY in the documentation. > > > Eugene > > > ________________________ > > Eugene Grayver, Ph.D. > Aerospace Corp., Sr. Eng. Spec. > Tel: 310.336.1274 > ________________________ > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
