Thank you all of you who have answered to my questions. I am sorry for anwering too late.
I'll try as many solutions as you suggested and will let you know how I will have implemented it. Regards, Jeon. 2015-09-22 23:31 GMT+09:00 Jan Krämer <kraemer...@gmail.com>: > Hi all, > > my repo is here https://github.com/SpectreJan. > Though the decoder that I presented last year at GRCON is not in > there...long and shitty story. There is an optimized version of the > gr-trellis decoder in gr-celec. You have to clone gr-celec and volk-fec > from my repo. Then build volk-fec and then gr-celec. I renewed my fork of > GNURadio and am starting implementing a generic version of cc_decoder that > is cc_encoder compatible but to be honest, work is pretty slow. > > cheers and happy hacking, > Jan > > 2015-09-22 15:24 GMT+02:00 Tom Rondeau <t...@trondeau.com>: > >> On Tue, Sep 22, 2015 at 1:52 AM, Jeon <sjeon87+gnura...@gmail.com> 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 >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
