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
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)