Hi all,
we're making great progress! Today I've added support for the SCH/F dedicated signalling channel (where blocks 1+2 of each burst are combined). This, plus fixing some other bugs now results in CRC=OK on all of the frames in my captures, i.e. we can assume that the PHY and lower MAC layers are working as expected now.
I've also added code to display MAC-ACCESS_ASSIGN, MAC-RESOURCE and some other PDUs. We can now see that there are unencrypted MM LOCATION UPDATE ACCEPT messages even on the BDBOS network, and in some commercial TETRA networks we have already discovered no encryption being used.
The next step would probably be to use the ACELP reference codec and use that for all TCH frames. Luckily, the 'Downlink usage' field of the ACCH (ACCESS-ASSIGN) even tells us if a frame is SCH/F (assigned control) or TCH (traffic).
However, after more than a week of intense TETRA related hacking, I really have to get to some more serious (paid) work now, and I don't expect to find much time again before the end of the month.
So feel free to improve the code as you see fit. I'll be watching your progress.
Zecke is currently looking into integrating the float_to_bits conversion as a gnuradio functional block, together with improving it, i.e. * dynamically calculate the 'offset' that is currently hardcoded at 0.3f * generate soft-bits as int8_t, i.e. +127 == very likely to be a 1, -127 == very likely to be a 0
Other TODO items: * Make sure the de-scrambling will work with the int8_t soft-bits * Actually check if the RM30,14 code produces a correct checksum for AACH * remove lots of superfluous memcpy's all over the place * introduce logging levels/subsystems, use libosmocore/logging * 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 * dump the TCH/F speech frames and try to play them back using the reference ACELP codec (as indicated above)
If you work on something, simply let the mailing list know so we can avoid duplicate work.
Regards, Harald
- 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.
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).
I already have code for a hard decision viterbi. (input being uint8_t [0 or 1] and outputing the same). I also have some preliminary code for soft input -> hard output (which seems to indeed work better if you have real soft input. Like for punctured input you input 0.5f and it doesn't bias it). Still working on soft output.
Cheers,
Sylvain
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
Hi,
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've put it into a sylvain/viterbi branch, replacing the old code.
The test code still gives 0 CRC error so it seems to work. There is still a wrapper because my code takes the -127 0 127 softbit format as input.
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.
I was using float for the tests, but I hadn't settled yet on a format ...
Your arguments are pretty convincing so I adapted to code for int8_t input.
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.
Sounds good to me. It's quite similar to what the calypso use for soft bit output (except it's on 4 bits only). the negatives are the '1' ... I guess it's so that you can make a hard decision just by doing (c >> 7) (taking the MSB).
Cheers,
Sylvain
-
Harald Welte -
Sylvain Munaut