[Tetra] Update on TETRA progress, TODO list

Sylvain Munaut 246tnt at gmail.com
Sun Jan 9 16:36:46 UTC 2011


>> 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).



More information about the tetra mailing list