8 Jan
2011
8 Jan
'11
7:16 p.m.
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
--
- 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)
8 Jan
8 Jan
7:22 p.m.
* 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
9:36 p.m.
Hi Sylvain,
On Sat, Jan 08, 2011 at 07:22:24PM +0100, Sylvain Munaut wrote:
cool, thanks for taking care of it.
* 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).
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)
9 Jan
9 Jan
5:36 p.m.
Hi,
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.
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 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
5391
days inactive
5392
days old
3 comments
2 participants
participants (2)
-
Harald Welte -
Sylvain Munaut