[Tetra] Update on TETRA progress, TODO list

Harald Welte laforge at gnumonks.org
Sat Jan 8 18:16:24 UTC 2011


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 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