Hi Sylvain, hi list!
I saw you commiting a generic viterbi de-/encoder in libosmocore core/conv.c. Just when I started to learn how to implement something like that some days ago... :-)
Now I'd like to know if there are also some precomputed tables available for next_output and next_state implementing the convolution codes described in GSM 05.03/3.9.
Regarding the soft input bits to the algo, my guess is when just having hard bits you have to simply convert 1 to 127 and 0 to -127 in sbit_t, right?
And what came to my mind while reading the code is that couldn't you improve its performance on punctured codes by remembering the re-inserted bits and excepting them from next accumulated error calculation (line 291)? If I'm understanding viterbi the right way, as punctured bits doesn't contain any information and introduce some random additional error, only real input bits should be incorporated in state decisions.
Regards, Mad
Hi,
Now I'd like to know if there are also some precomputed tables available for next_output and next_state implementing the convolution codes described in GSM 05.03/3.9.
Yes, they're coming, but there is a _lot_ of tables I have to generate / transcribe the polys for all the AMR modes and such :p
If you just need the XCCH, you can use this : http://pastebin.com/zdZ29GWF (you'll need to fix the osmo_ prefix I added later).
Regarding the soft input bits to the algo, my guess is when just having hard bits you have to simply convert 1 to 127 and 0 to -127 in sbit_t, right?
Actually -127 is 1 and 127 is 0
This is so that the 7th bit is the hard bit. ( 01111111 = 127 - "0" and 10000001 = -127 = "1" )
And what came to my mind while reading the code is that couldn't you improve its performance on punctured codes by remembering the re-inserted bits and excepting them from next accumulated error calculation (line 291)? If I'm understanding viterbi the right way, as punctured bits doesn't contain any information and introduce some random additional error, only real input bits should be incorporated in state decisions.
Yes indeed I'll try that.
I'm not sure it's gonna be a lot faster (due to the added test), but it would avoid having a non-0 accumulated error.
Cheers,
Sylvain
Yes, they're coming, but there is a _lot_ of tables I have to generate / transcribe the polys for all the AMR modes and such :p
If you just need the XCCH, you can use this : http://pastebin.com/zdZ29GWF (you'll need to fix the osmo_ prefix I added later).
Thanks, but for that mode I already use the code from airprobe. Of course I'm more interested in the ones for AMR, but I can wait. Or try it by myself if I find the time to, what ever succeeds first. :)
Regarding the soft input bits to the algo, my guess is when just having
hard bits you have to simply convert 1 to 127 and 0 to -127 in sbit_t, right?
Actually -127 is 1 and 127 is 0
This is so that the 7th bit is the hard bit. ( 01111111 = 127 - "0" and 10000001 = -127 = "1" )
Ah ok, I see!
Regards, Mad
Hi Sylvain, hi list!
Like I said I would try to, here are my computed convolution tables for all eight AFS modes.
Unfortunately I'm not _that_ confident that I didn't made some mistakes in writing the generator and exactly implementing the specs.
First test calculations by hand look good, though I'd rather like to verify the tables but didn't found any test vectors yet.
If you or someone had some known test data at hand, that would be useful. Otherwise feel free to check it by yourself and integrate it in libosmocore.
Yes indeed I'll try that.
I'm not sure it's gonna be a lot faster (due to the added test), but it would avoid having a non-0 accumulated error.
What I meant was performance not in terms of speed but in terms of decoding quality. As you wrote not to have error added where is none. It should improve correct decoding of weak signals by some slight degree.
Regards, Mad
Hi,
Like I said I would try to, here are my computed convolution tables for all eight AFS modes.
I didn't check them all but they don't look good because they're at least missing the proper termination. When the code is systematic it's not terminated the same way as a non-systematic code and so you need some special termination handling.
See in attachement for my version. (and I know it works :p)
I don't want to just include the table in libosmocom, I'd like to include the generator itself and build them as part of the build process and for that I still need to write it to output nicely formatted C code :p
What I meant was performance not in terms of speed but in terms of decoding quality. As you wrote not to have error added where is none. It should improve correct decoding of weak signals by some slight degree.
Well since that error is constant I'm not sure it'll help that much.
But at least the decode will not return a != 0 value if there was no bit errors.
Cheers,
Sylvain
I didn't check them all but they don't look good because they're at least missing the proper termination. When the code is systematic it's not terminated the same way as a non-systematic code and so you need some special termination handling.
See in attachement for my version. (and I know it works :p)
Thanks, helped finding my generators bugs knowing the right output. :) I swapped sth. in the 12k2 output and messed up the feedback in the next state tables. Now with the added termination this should be complete and ready to use with conv.c for those impatient to work with AFS.
I don't want to just include the table in libosmocom, I'd like to include the generator itself and build them as part of the build process and for that I still need to write it to output nicely formatted C code :p
That's a good thing to do, as AFAIK there is none suitable available for now. And it's definitely generating the nicer code! :-)
Regards, Mad
baseband-devel@lists.osmocom.org
-
mad -
Sylvain Munaut