Hi Sylvain,
On Sat, Jan 08, 2011 at 07:22:24PM +0100, Sylvain Munaut wrote:
- optimize the viterbi decoder (and its primitives)
- modify the viterbi to directly use arrays of uint8_t so we can seave
the copying from 8->16 and back from 16->8
I'm working right now on viterbi.
cool, thanks for taking care of it.
It's not specifically for TETRA but the generator will be able to generate code for any convolutional coder polynoms of rate 1/n (or derived from a 1/n code via puncturing).
even more cool :)
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 also have some preliminary code for soft input -> hard output (which seems to indeed work better if you have real soft input.
This is also great.
Like for punctured input you input 0.5f and it doesn't bias it).
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.
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. Using those values will make sure you don't need any special treatment for a "don't care" symbol. I also like that range as it means you can use a single octet for each input bit, as opposed to a 16bit int or even a float number.
Still working on soft output.
I think that's more like a nice future option, but nothing I would consider doing at the moment...
Regards, Harald