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)