brmlab

User Tools

Site Tools

You are here: Hackerspace Prague » Projects » Software Defined Radio » tetra-listener
project:sdr:tetra

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
project:sdr:tetra [2016/06/04 15:37] – [What is broken] jendaproject:sdr:tetra [2016/12/26 05:27] – [How To] jenda
Line 9: Line 9:
 status=active}} status=active}}
  
-tetra-listener allows decoding of speech on unencrypted Tetra network. Thanks to miracles of wideband SDRs, a small cluster of standard PCs can decode the entire network in a big city in real time.+tetra-listener allows decoding of speech and SDSs on unencrypted Tetra network. Thanks to miracles of wideband SDRs, a small cluster of standard PCs can decode the entire network in a big city in real time.
  
 tetra-listener consists of GnuRadio Tetra demodulator, [[http://tetra.osmocom.org/trac/|Osmocom TETRA]] patches extracting speech data and some helper scripts. tetra-listener consists of GnuRadio Tetra demodulator, [[http://tetra.osmocom.org/trac/|Osmocom TETRA]] patches extracting speech data and some helper scripts.
Line 19: Line 19:
 ===== Architecture ===== ===== Architecture =====
  
-tetra-rx utility from osmo-tetra is patched to dump traffic data to file.+tetra-rx utility from osmo-tetra is patched to dump traffic data to a file.
  
-tetra.sh spawns one tetra-rx process for each channel we want to listen to (usually 36, 72 or 108 channels), reading raw bits from FIFO, dumping decoded traffic to traffic.out and logs to log.txt (redirect to /dev/null if you don't need them anymore as this can generate 10 GB of logs per hour!) +tetra.sh spawns one tetra-rx process for each channel we want to listen to. Then, tetra.sh spawns one tetra_rx_multi.py (using GnuRadio channelizer) or tetra.py from [[:project:sdr:fcl]] examples (using FCL channelizer), reading data from SDR, demodulating and writing demodulated data to tetra-rx.
- +
-Then, tetra.sh spawns one tetra_rx_multi.py, reading data from SDR, demodulating and writing demodulated data to FIFOs.+
  
 Then, tetra.sh periodically checks for recorded traffic files and runs ETSI reference codec on them. Then, tetra.sh periodically checks for recorded traffic files and runs ETSI reference codec on them.
  
-===== Hardware =====+Additionally, tetra-rx can generate PCAP output to a pipe. This is read by tetra-multiframe-sds and SDSs are reconstructed from it.
  
-For receiving, rtl-sdr works. Of course anything better is… better. +{{ :project:sdr:tetra:tetra.png?direct&300 |}}
- +
-Unfortunately, the thing is a bit CPU hungry. Some examples of hardware tested: Intel Core i3-2350M can barely keep up, losing some samples. i7-3770K and AMD FX-8150 are fine.+
  
 ===== How To ===== ===== How To =====
  
-Get yourself https://brmlab.cz/gitweb/?p=tetra-listener.git;a=summary and do what README says.+[[:project:sdr:tetra:howto]]
  
-On amd64 Debian, a non-obvious dependency is lib32gcc-5-dev. The codec can also run on 32bit ARM and probably other 32b systems too, but it assumes that sizeof(void*) == sizeof(int), so it won't compile in 64bit. Someone should dive into that 20 years old C and fix it...+[[:project:sdr:tetra:sniffutils|What other nice tools we have in the repository]]
  
-Then you need libc6-dev:i386 and realpath. +You can uncomment /dev/null redirect in tetra.sh and check logs for BTSs you have found:
- +
-And libtalloc-dev libpcsclite-dev for libosmocore. +
- +
-Calibrate your SDR, like with kalibrate-rtl. You can use [[:user:jenda:kalibrate-everything]] if there is no specific calibrator for your device. +
- +
-Open your favorite SDR tool and look for Tetra channels in the 420-430 MHz range. It's 25 kHz wide [[http://www.sigidwiki.com/images/e/e1/TETRA_Sound.mp3|buzzing]] when demodulated as FM. +
- +
-Edit config.sh. +
- +
-Recommended: +
-<code>ip6tables -A INPUT -p UDP --dport 4729 -j DROP +
-iptables -A INPUT -p UDP --dport 4729 -j DROP +
-</code> +
- +
-Run radio-tetra/tetra.sh, you should see some GSMTAP traffic on localhost:udp/4729. +
- +
-Check what you have found:+
  
 <code bash> <code bash>
Line 72: Line 51:
 </code> </code>
  
-If you see "Air encryption: 0", you are fine. If encryption is on, you will have to get us Tetra encryption specification and wait if we try to do some cryptanalysis on it :).+===== What is broken =====
  
-===== Jenda's out-of-tree patches =====+The dumper just appends all the audio data from a timeslot to one file. This mixes conversations together, but strict splicing would not be good either as there can be pauses in speech. Maybe we should lower the pause threshold from current one minute to something like 20 seconds.
  
-Not mainlined because of poor code quality, but adds some features.+Recognizing SSI/group ID could be very useful if one network is shared by multiple organizations. Currently we try to guess the SSI; proper implementation of TETRA equivalent of GSM immediate assignment may work better.
  
-You need [[:user:jenda:blobutils]].+Protocol decoding beyond traffic frames needs some love. SDSs are now implemented by a [[https://github.com/itds-consulting/tetra-multiframe-sds|decoder from ITDS]] and seem to work at least to some extent. Another approach are [[https://github.com/sq5bpf/osmo-tetra-sq5bpf|SQ5BPF's osmo-tetra patches]] which gave me some results that unfortunately seem to be garbage.
  
-Apply [[http://jenda.hrach.eu/brm/rad/tetra-patch/|the patch]].+Uplink support would be nice.
  
-  * tetra.patch - enables our favorite stuff - frequency correction, manual channel selection, recording in ACELP format +Error correction is not implemented.
-  * bitstream.patch - dump raw packed bitstream (unpack with gr-unpack and feed to tetra-rx later) +
-  * resample.py - receive Tetra even on SDRs that do not have sample rate that is an integer multiply of 900 kHz +
-  * tetra.grc - one-channel graphic receiver+
  
-Work around broken squelch: run it for several hours with all "brmchannels" (or half of it and then another half if you don't have computational power for this), then `ls -1 | cut -d "o" -f 2 | cut -d "." -f 1 | sort -n | uniq -c` and remove channels that don't work. +Duplicates occur when one sniffs multiple BTSs at once. Detect and remove them.
- +
-There is also some autotune feature, pick some strong from tetra_cli_pwr.py and then put it to self.afc_channel. +
- +
-cdp is now your ACELP player if you set REC_FORMAT=cdata.bz2, which we recommend. +
- +
-===== What is broken ===== +
- +
-The dumper just appends all the audio data from a channel to one file. This mixes conversations together. And also probably interleaves data if they are on both timeslots in parallel. +
- +
-SSI/group ID of the conversation is not recognized. This could be very useful if one network is shared by multiple organizations. +
- +
-Protocol decoding beyond traffic frames needs some love. There are two efforts to decode SDSs: +
-  * [[https://github.com/itds-consulting/tetra-multiframe-sds|Decoder from ITDS]], which seem to work well on local network. It can decode SDSs down to readable ASCII or raw binary payloads. +
-  * [[https://github.com/sq5bpf/osmo-tetra-sq5bpf|SQ5BPF's osmo-tetra patches]] which gave me some results that unfortunately seem to be garbage. +
- +
-Uplink support would be nice.+
  
 The project lives as a combination of patches that occasionally break with new commits. We really need to mainline all of them into one thing. The project lives as a combination of patches that occasionally break with new commits. We really need to mainline all of them into one thing.
  
 Script that automatically selects channels not only based on signal strength, but on amount of traffic, would be nice. Script that automatically selects channels not only based on signal strength, but on amount of traffic, would be nice.
project/sdr/tetra.txt · Last modified: 2017/01/02 11:35 by jenda