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/tetra@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comHi,
>> I already have code for a hard decision viterbi. (input being uint8_t
>> [0 or 1] and outputing the same).
>
> this is great, and it would already work as a drop-in replacement for
> the current viterbi.c implementation we use
I've put it into a sylvain/viterbi branch, replacing the old code.
The test code still gives 0 CRC error so it seems to work.
There is still a wrapper because my code takes the -127 0 127 softbit
format as input.
> So in your code you want to input float values? I would suggest to re-evaluate
> that... if you ever want to cross-compile it to an ARM or other
> RISC target, it's going to hurt a lot performance-wise. According to some
> of the literature I've read, having more than 8 levels (3 bits) of soft input
> resolution will not show any noticable improvement in the decoder.
I was using float for the tests, but I hadn't settled yet on a format ...
Your arguments are pretty convincing so I adapted to code for int8_t input.
> The viterbi from the ACELP code has input values 127...1 for 0 and -1...-127
> for 1 (IIRC) and uses the 0 as the logical 'do not care' in case of punctured
> codes.
Sounds good to me. It's quite similar to what the calypso use for soft
bit output
(except it's on 4 bits only). the negatives are the '1' ... I guess
it's so that you can make a hard decision just by doing (c >> 7)
(taking the MSB).
Cheers,
Sylvain