[Tetra] Update on TETRA progress, TODO list

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)