[Tetra] Update on TETRA progress, TODO list

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.org
Sat Jan 8 20:36:23 UTC 2011


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




More information about the tetra mailing list