Re: [Discuss-gnuradio] FEC: Convolutional Encoder Gnuradio and Matlab: different results

[Dan CaJacob]

Hi Emanuel,

Try bit-reversing the polynomials.  By the way, even though the block definitions can take any python representation of the numbers.  For instance 91 decimal is 0x5B (hex) and 091 (octal) in python.  I often use the leading zero octal notation for stuff like this since the weirdos who came up with conv encoding like to use octal to specify their polynomials.

- Dan

On Wed, Mar 22, 2017 at 10:16 AM Usman Haider <address@hidden> wrote:

Hi Emanuel,

Maybe you find following thread useful.

http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00404.html

--

Usman

On Wed, Mar 22, 2017 at 1:07 PM, <address@hidden> wrote:

Hi together,

 

I’m using the FEC Async Encoder with the CC Encoder Definition. Input/Output are unpacked and I use the terminated behavior. In Gnuradio the polynomials for the CC Encoder Definition are defined on a base of 10, and not as octals like in MATLAB, right?

 

I tried the following: 1 bit with ‘1’ as input to the FEC Async Encoder and the same in MATLAB to check the response of the encoder. The results don’t match. No matter if I use different constraint lengths, rates or polynomials.

e.g. in Matlab: K = 7, 1/R=2, Polynomials (octal) [171,133] and Gnuradio Polynomials (10-base) [121,91] give completely different outputs.

 

No matter what I do, e.g., using octal representation in Gnuradio, or changing the polynomials’ positions in the specified vector, gives me a result which matches.

 

Did anyone compare results before? Any clues?

Regards,

Emanuel

 

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--

Very Respectfully,

Dan CaJacob