tetra

tetra@lists.osmocom.org

162 discussions

platform choices
by Sim IJskes 27 Jan '11

27 Jan '11

Hello, My main activity here would be lurking, but i certainly like to make a contribution in the future. I've programmed in ASM on several platforms, C, C++, and nowadays do all of the work in Java. Most java implementations suffer from non-deterministic timing issues, so i wonder, would there be any application for java as a platform in the (osmocom) radio protocols? I've build a hearing loss simulator in java, which is a streaming audio pipeline, so java is not completely useless in applications with strict timing relations. I believe the latency couldn't exceed 50mS which is huge in TDM radio protocols, but in the upper layers with a lot of complex data shuffling it might be usefull? Any ideas? Gr. Sim

3 2

PATCH: bitwise msb-first table-based 16bit CRC calculation
by Christian Vogel 23 Jan '11

23 Jan '11

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

3 2

Wiki write access
by Harald Welte 22 Jan '11

22 Jan '11

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)

1 0

[Tetra] TETRA / PI/4 DQPSK Modulator
by Christian Daniel -- maintech GmbH 12 Jan '11

12 Jan '11

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

1 0

[Tetra] Before we get into writing wireshark dissectors...
by Harald Welte 11 Jan '11

11 Jan '11

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)

1 1

[Tetra] repository with tetra traces
by Harald Welte 09 Jan '11

09 Jan '11

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)

3 3

[Tetra] Update on TETRA progress, TODO list
by Harald Welte 09 Jan '11

09 Jan '11

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)

2 3

[Tetra] current status / scrambling
by Harald Welte 07 Jan '11

07 Jan '11

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)

2 2

[Tetra] Finally: Viterbi Decoding now working
by Harald Welte 06 Jan '11

06 Jan '11

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)

1 0

[Tetra] Viterbi
by Harald Welte 05 Jan '11

05 Jan '11

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)

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra