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