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