Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

[Tom Rondeau]

On Tue, Sep 22, 2015 at 1:52 AM, Jeon <address@hidden> wrote:

Thanks for your answers, Ron and Marcus.

I posted this question since my module is using both Reed Solomon (https://github.com/pjkundert/ezpwd-reed-solomon) and Convolutional Code (IT++).

And I saw that CC is extremely slower than RS. Thus, I posted this question, but I made a question too short and lack some information.

(Of course, this is because mechanism of RS is much much simpler than that of CC.

Or it could be because ezpwd RS which I am using is optimized well, but IT++ CC is not.)

To improve my OOT's performance, thus, I need to replace IT++ with other some heavily optimized library or module.

I remember that...one of gr-fec, gr-dtv, gr-trellis can do this for me.

Now I wonder which gr module supports some arbitrary polynomials and code rate.

Specifically, I want one of three set of polynomials:

- Polynomial 1 (g0 = 133, g1 = 171, g2 = 165)

- Polynomial 2 (g0 = 131, g1 = 145, g2 = 133)

- Polynomial 3 (g0 = 131, g1 = 171, g2 = 133)

(Common: Code rate 1/4, 2/3 and 1/3, where 1/4 = repeat of code rate 1/2)

The reason that I try to implement one of three is,

document describing specification has some wrong points.

Text says polynomial 1, but figure shows polynomial 2.

One thing is hopeful:

I think that polynomial 3 seems a sort of widely used one

and that it has been already implemented by someone in GNU Radio,

which has been heavily optimized... I hope...

(While I am writing this, I've checked that gr-fec can do CC with arbitrary polynomials.

gnuradio/gr-fec/examples/fecapi_cc_decodres.grc

I still don't know optimization.)

I will keep looking into those gr-fec, dtv, trellis modules.

If someone have suggestions, I will appreciate it.

Thanks a lot.

Regards,

Jeon.

Jeon,

No, as the docs say, this block is only designed to handle rate 1/2, K=7 codes:

http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__decoder.html

We had some work done for GSoC last year to improve the speed of the Viterbi algorithm for other cases, but we have not yet merged that into the code. This was Jan Kramer's work, though I'm having trouble finding a link to his repo.

Tom