This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comHi,
> 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