tetra

tetra@lists.osmocom.org

161 discussions

PATCH: bitwise msb-first table-based 16bit CRC calculation

by Christian Vogel

Hi, after a remark by Harald about bitwise CRC calculation and seeing the crc_simple code in lower_mac, I've thought about how to implement "optimized" routines using a table-based approach operating on our pbit_t/ubit_t arrays in libosmocore/master. People on IRC consider it more tetra-specific though, so I'm posting this here for advice on where to put it. The usage is to first create the table via osmo_crc16_table_init(*table,polynomial) and then to encode bits using osmo_crc16() - default, operates on pbit_t[] osmo_crc16_ubits() - operate on ubit_t[] osmo_crc16_ubit() - one single bit, takes polynomial as first arg! osmo_crc16_pbit() - operate on 1-7 bits in a pbit_t It passes the crc_test ported to the new routines. $ ./crc_test # osmo-tetra The CRC is now: 4129/0x1021 The CRC is now: 4129/0x1021 The CRC is now: 61905/0xf1d1 The CRC is now: 65534/0xfffe The CRC is now: 57073/0xdef1 The CRC is now: 7439/0x1d0f Decoded successfully. $ tests/crc/crc_test # this patch, in libosmocore First elements of table for CRC with poly 0x1021: 0000 1021 2042 3063 4084 50a5 60c6 70e7 8108 9129 a14a b16b c18c d1ad e1ce f1ef The CRC is now: 4129/0x1021 The CRC is now: 4129/0x1021 The CRC is now: 61905/0xf1d1 The CRC is now: 65534/0xfffe packed bits: 10 b0 be 00 83 07 d3 3d ef 10 The CRC is now: 57073/0xdef1 ...packed: 57073/0xdef1 packed bits: 10 b0 be 00 83 07 d3 3d ef 10 The CRC is now: 7439/0x1d0f Decoded successfully. Chris

13 years, 2 months

Wiki write access

by Harald Welte

Hi all, OsmocomBB and OsmocomTETRA share the same list of accounts, so if you have an account on OsmocomBB, you can use the same credentials to write to the new http://tetra.osmocom.org/ website. Regards, -- - 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)

13 years, 2 months

[Tetra] TETRA / PI/4 DQPSK Modulator

by Christian Daniel -- maintech GmbH

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, I haven written (and ripped :-) a PI/4 DQPSK modulator, which should be able to transmit TETRA bursts. For compilation have a look into the Makefile. It reads data from stdin and expects one byte for every symbol. The value should be 0, 1, 2 or 3. 0xff results in silence. The symbol rate is 250000/14 on USRP1 which is 17857 symbols/s. A more or less simple demodulator should work without problems (perhaps with more selfnoise), but a MLSE based RX will most probably not work. For more "professional" uses we will need an accurate resampler, but I will throw that one in as time comes :-) Have fun, Christian - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 · D-97204 Höchberg | - --------------------------------------------------- | AG Würzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd(a)maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNLjLHAAoJEHkgzUIsAWriO2UH/ivlinNO6L/Y74pe8Bf3eKhF K9bgUKAbowa/AHlKRzJlUU0AvjmAgkDRZOJ9lDqZUyBW5NnoJkxTvRjfq0Deytad MCwb2jLkN37MLCWju/3io60672G5uMKX4J7N3zDkrLgZKnKesaVJY+NgiLLTkMY1 uh6/ZJ7Fg/snMPXfffMiNo+vG+G9pIMYmzRp3rPaqYL4sSQjyoUWpOoNruDFA+uu wYf/R1rGo5wWbKdTKAbRCHt3FmTyn61BEtngcyrc30XOZppCjH2oboMpAYmUyU88 bI6pnptMHixoi7skGH0lfD5Fqb5PlUqYOqAaq83LUYmbcv5v7NV51BrikBfk1l0= =7aiy -----END PGP SIGNATURE-----

13 years, 3 months

[Tetra] Before we get into writing wireshark dissectors...

by Harald Welte

It seems somebody has already done it: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5355672 I have contacted the authors of the paper and asked them if they have ever released the source code or send me a copy of it. This would definitely speed things up. I really have no intention (or time) to write a full wireshark dissector for the entire protocol stack. Too many other interesting projects :/ So lets hope they will release their code... -- - 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)

13 years, 3 months

[Tetra] repository with tetra traces

by Harald Welte

Hi! I have uploaded a number of tetra data files to a password-protected rsync repository: you can access it using "rsync -azv tetra@osmocom.org::tetra/data ." using the password "Xo4ried5" (please use -z option to compress the transmission, as the files in the repo are uncompressed) *.cfile raw complex samples recordings, need tetra_demod.py *.float output files of demodulator, 1 float per symbol *.bits output of float_to_bits (1 bit-per-byte format) If you want to contribute traces, feel free to upload them, preferrably both the cfile and the bits... there's no need for the .float files. please create one new directory for every trace or class of traces you upload. A small README file is appreciated in order to explain what those traces are. Due to the sensitive nature of the data, pleaes keep access to the repository private. Thanks for your understanding. btw: The entire project is not released yet. While I have made it public that we're working on TETRA, I would not want the current code released - last but not least since we're using a viterbi implementation that is under unclear license terms as it is derived from the ACELP refernence codec. Once somebody has replaced the viterbi with a new implementation and we have cleaned up the code, I don't really see why we would not release it publicly. 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)

13 years, 3 months

[Tetra] Update on TETRA progress, TODO list

by Harald Welte

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)

13 years, 3 months

[Tetra] current status / scrambling

by Harald Welte

Hi all, in TETRA, the only part of the signal that is transmitted with a well-known scrambling code is the BSCH in the SB1 (first half of the downlink SYNC block). We can finally decode that since yesterday and get proper MCC/MNC and TDMA time information. The colour code + MNC + MCC is used as the scrambling sequence for all other messages of the cell, specifically also the BNCH containing the SYSINFO messages. I've recently added code to indicate when a BNCH block is to follow, but the de-scrambled type-2 bits do not look plausible at all. So there's most likely still some problem with the de-scrambling. The de-interleaving, de-puncturing and viterbi decoder are the same code (even with different parameters), so I don't think that there are likely problems caused by them. 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)

13 years, 3 months

[Tetra] Finally: Viterbi Decoding now working

by Harald Welte

Hi! As it turns out, my fibonacci and galois form of the scrambler do not generate the same bit pattern. I originally tested and verified they produce identical results - but apparently they don't. We now have successful decoding of all the SYNC bursts in the sample capture, as you can see from the attachment. Whenever there's a gap in the decoded FN, this is due to a NORMAL burst being transmitted instead. The normal burst does not carry the timeslot/framenumber information and we need to count ourselves in the gaps in between. I am already computing the scrambling sequence init value from the MCC/MNC/CC that we receive in the SYNC burst, and de-scramble the BBK and BLK2 of the SYNC burst. However, the viterbi has not been adapted yet to the encoding of those bursts (it's not much). I'll update you once we can decode more... -- - 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)

13 years, 3 months

[Tetra] Viterbi

by Harald Welte

Hi all, I managed to modify the viterbi code from C-CODE/SUB_DC.C in the ZIP file from the 300 395-2 spec. It implements a different mother code (i.e. the voice code which is a rate 1/3 code, whereas signalling uses a rate 1/4 mother code). So far I am not really getting much out of it. Sometimes some parts of the bursts make sense (like the 0/1/2/3/0/1/2/3/... sequence of frame numbers), but stuff like MCC/MNC gives completely bogus values. I'm too tired now to continue, will look at it again tomorrow. But I think we're close. I will commit the code as soon as something is working at all. My next attempt is to try to run this viterbi against bursts that I generate using my code. If that works, then we must be doing something wrong in the lower steps (de-interleaving, de-puncturing). 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)

13 years, 3 months

Re: [Tetra] TETRA Demodulation

by Harald Welte

(we have a mailinglist and we should use it... and write in english for sylvain's benefit) On Tue, Jan 04, 2011 at 08:16:12PM +0000, Dieter Spaar wrote: > Kleine Korrektur: > > Das Muster im vorherigen Bild ist natuerlich drei Bursts mit > "Frequency Correction Field" und dann einer ohne, das koennte > eventuell etwas mit dem Frame bestehend aus vier Slots zu > tun haben. The tdma multiplex of TETRA is unfortunately much more complicated than in GSM. I only really understood it earlier today while reading a textbook, from the specs it is very difficult to understand. The Frequency Correction Field is only present in the sync bursts (SB), which in turn are only (required to be) sent in Frame number 18 , but not on every multiframe. Interestingly, the SB is also present in _every_ timeslot, but not in every Frame 18 of every TS. The formula for the Timeslot Number is "4-(MN+1)mod4", it is indicated in Table 9.25 in Chapter 9.5.1

13 years, 3 months

[Tetra] code for the tetra MAC layer

by Harald Welte

Hi, I've started to implement the TETRA TMO MAC layer, i.e. the part that takes MAC blocks from higher layers and applies CRC, FEC, interleaving and scrambling before finally handing the bits to the DQPSK-modulator. The code can now generate a (hopefully valid) to-be-modulated bit pattern for a 'continuous downlink synchronization burst', i.e. what corresponds to the 'SCH+FCCH+BCCH' in GSM. You can find the code (including a small README) at: gitosis@git.osmocom.org:tetra-misc.git in the 'src' directory. If you don't yet have git access, feel free to mail me your sshv2 key. What's missing: * CRC16-CCITT to be computed over odd number of bits like 60 or 124 (all common implementations assume you encode integral # of bytes) [zecke] * decoding: * decoder for the RM(30,14) code [zecke] * soft-input/soft-decision viterbi for the RCPC code * synchronizer, able to detect synchro and normal training sequence [laforge] Once those tasks are completed, we can not only generate simulated burst bit patterns, but also decode them - which should be a good start for the time when Hopscotch' demodulator will spit out some real received bitstream. 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)

13 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra