tetra-rx
founder:
depends on:
interested:	mrkva Jenda
software license:
hardware license:

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 consists of GnuRadio Tetra demodulator, Osmocom TETRA patches extracting speech data and some helper scripts.

https://brmlab.cz/gitweb/?p=tetra-listener.git;a=summary

A proprietary extension to TETRA standard enables psychological control of nearby people. The publicly available version of brmlab tetra-listener does not support this feature.

tetra-rx utility from osmo-tetra is patched to dump traffic data to 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!)

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.

For receiving, rtl-sdr works. Of course anything better is… better.

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.

Get yourself https://brmlab.cz/gitweb/?p=tetra-listener.git;a=summary and do what README says.

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…

Then you need libc6-dev:i386 and realpath.

And libtalloc-dev libpcsclite-dev for libosmocore.

Calibrate your SDR, like with kalibrate-rtl. You can use 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 buzzing when demodulated as FM.

Edit config.sh.

Recommended:

ip6tables -A INPUT -p UDP --dport 4729 -j DROP
iptables -A INPUT -p UDP --dport 4729 -j DROP

Run radio-tetra/tetra.sh, you should see some GSMTAP traffic on localhost:udp/4729.

Check what you have found:

cd ~/tetra-tmp/fifo
 
for f in log*txt; do
  echo "** $f"
  cat $f | grep -A 14 -B 8 "BNCH SYSINFO" | while read line; do
    echo "$line"
    if [ "$line" = "--" ]; then
      break
    fi
  done
done

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 :).

Not mainlined because of poor code quality, but adds some features.

You need blobutils.

Apply the patch.

• tetra.patch - enables our favorite stuff - frequency correction, manual channel selection, recording in ACELP format
• 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.

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.

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:

• Decoder from ITDS, which seem to work well on local network. It can decode SDSs down to readable ASCII or raw binary payloads.
• 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.

Script that automatically selects channels not only based on signal strength, but on amount of traffic, would be nice.