Tetra decoding

[sq5bpf]

On top of my wishlist is to correct the bug causing the decoding to sometimes get out of sync and never get back on track unless the application is restarted. I gave that an attempt some months ago, but didn't have time to really understand what happens.

unfortunately it takes too long to reproduce it. i've ran the receiver for a month and couldn't break it, but i've had it fail twice after a short period.

 

[skinkie]

First: thanks sq5bpf for this work. I like the fact that you wanted to release often and don't keep it for yourself in an open source spirit. I have started to play with telive yesterday, and it pulled me for the first time into an SDR usbstick which was lying in my room for some years. Documented my newbie effort on this Dutch forum. An eyeopener for me was figuring out that the local oscillator isn't your friend in cheap SDR hardware, also it takes some time to tune to the right frequency. I wonder if there is a way to have more visual finetuning.

My goal is labeling the audio output with affected SSI's. I find it difficult to realize this at this point via the telive sourcecode. Some magic happens with the filenames what I don't understand yet. At this point I have prototyped my work by extending telive with some ZeroMQ hooks, and the tplay script now encodes the output into opus frames which are broadcasted to a zeromq pubsub. I maybe should have started with tetra-over-ip which would have sound cooler

I can related to the difficulties with broadcasting a stream to icecast and friends. My goal was near realtime publication (in push-to-talk style) but virtually all streaming solutions require continuous feeds, thus some form of mixing would be required. Must be doable using existing infrastructure for example with empty frames, but not that easy to do it right. The alternatives are obviously VoIP related solutions.

 

[sq5bpf]

First: thanks sq5bpf for this work. I like the fact that you wanted to release often and don't keep it for yourself in an open source spirit.

thanks

I wonder if there is a way to have more visual finetuning.

what can be more visual then a spectrum graph?

btw i will probably implement some AFC in the next major version.

I can related to the difficulties with broadcasting a stream to icecast and friends. My goal was near realtime publication (in push-to-talk style) but virtually all streaming solutions require continuous feeds, thus some form of mixing would be required. Must be doable using existing infrastructure for example with empty frames, but not that easy to do it right. The alternatives are obviously VoIP related solutions.

i don't understand. redirect the output into a streaming program with pulseaudio. if there is a transmission, then the tplay audio is streamed, if there is no transmission then silence is streamed. i haven't tried this myself but others have described how to do it.

you can probably do the same with voip, set up asterisk so that it picks up some number and streams the sound card audio to it. check out descriptions on how to use the sound card as a music-on-hold source for asterisk (and instead of the sound card, redirect the tplay output with pulseaudio). and for additional fun, try to set this up as "early media" (if the voip provider allows this option) so that the person calling doesn't have to pay for the call

 

[skinkie]

what can be more visual then a spectrum graph?

btw i will probably implement some AFC in the next major version.

Maybe something 'digital' that shows what subcarriers have information and in what direction it should be shifted?

i don't understand. redirect the output into a streaming program with pulseaudio. if there is a transmission, then the tplay audio is streamed, if there is no transmission then silence is streamed. i haven't tried this myself but others have described how to do it.

Yes, that would be the easy way to sacrifice the soundcard. Maybe Jack or Pulseaudio could do this indeed, if the setup cost of a connection isn't too big.

Started to write something 'custom' last night: https://github.com/skinkie/softgate

 

[passie101]

unfortunately it takes too long to reproduce it. i've ran the receiver for a month and couldn't break it, but i've had it fail twice after a short period.

If you run only one receiver it runs oké for mouths but when you run more then one receiver than the problems starts

 

[jlxsolutions]

If you run only one receiver it runs oké for mouths but when you run more then one receiver than the problems starts

I actually only observed this happening when one or more signals are on the limit of being decoded
(low signal)
After getting a preamp i have not observed this happening more then once.
you can reproduce it with a 1ch setup find a weak signal that decodes fine wait tills sync errors appear then it will fail to decode any signals that are not absolutely perfect it -20 to -25 dbi
If this happens to me when doing single channel i have to tune into the local tower which is 500meters from my house to get it working again none of the other 9 towers around will Fix it even their signals will normally decode just fine.

 

[sq5bpf]

New versions of osmo-tetra-sq5bpf and telive are out. Hope you will like it, please report any bugs or other interesting info.

Changes to osmo-tetra-sq5bpf:

- put float_to_bits functionality inside tetra-rx (turn on with the -i argument to tetra-rx)
- add a crude pseudo-AFC (turn on with the -a argument, this function works only with -i)
- send the crude pseudo-AFC data to telive (needs -i)
- receiver1 uses both -i and -a options.


Changes to telive:
- set version to 1.6
- receive the crude pseudo-afc data and show a tuning indicator for each receiver in the frequency window
- show a star in the frequency line if any signal is being received
- various small fixes
- enable mutessi by default



The frequency data for AFC is really data from the QPSK demodulator, smoothed with a simple filter. The AFC should improve reception a little bit, but please test with and without the -a options and see how much difference it makes (and report back to me please).

To see the data, turn on the frequency window in telive (press t), and see the nice tuning indicator. If all is tuned correctly, then the marker should be in the center. This is especially useful for ppm correction.

BTW i have plans to add proper AFC in the future.


There hasn't been much info about new features lately, but development has not stopped.


EDIT: quick update on how the pseudo-afc works. Without the -a option the receiver works when the signal is offset -1.6 to 1.3kHz. With the -a option the receiver works when the signal offset is -2.8 to 2kHz. So that's 65% more capture range (useful when your dongle oscillator drifts a lot).

 

[skinkie]

Is there a wishlist we can collaborate on with respect to telive.c?

 

[sq5bpf]

Is there a wishlist we can collaborate on with respect to telive.c?

not really. currently i'm trying to merge code from various experimental versions i have laying around, and fix reported bugs.

i've published a feature list for the next major version, but this is currently at early prototype stage.

 

[grosminet]

1.6 not working with previous batches

Due to float to bit integration , funcube or funcube pro plus aren't working anymore, rtl sdr yes


This batch isn't working (was working with 1.5)

first QTHID 4.0 on the right frequency then :

#!/bin/sh
export TETRA_HACK_PORT=7379
export TETRA_HACK_RXID=$1
ulimit -c unlimited
./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft.py -D hw:1 -o /dev/stdout | ./osmo-tetra-sq5bpf/src/float_to_bits /dev/stdin /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx /dev/stdin


With RTL -sdr , sdrplay bath is working

here is the content :

#!/bin/sh
export TETRA_HACK_PORT=7379
export TETRA_HACK_RXID=$1
ulimit -c unlimited
./osmo-tetra-sq5bpf/src/demod/python/osmosdr-tetra_demod_fft.py -a rtl=0 -f427M -o /dev/stdout | ./osmo-tetra-sq5bpf/src/float_to_bits /dev/stdin /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx /dev/stdin

in one we use fcdp-tetra_demod_fft.py , in other osmosdr-tetra_demod_fft.py

The avantage of the batch with fcdp-tetra_demod_fft.py is that it can be run with no display graph , that is better for CPU and memory usage of slow PCs

Any idea ?

 

[sq5bpf]

Due to float to bit integration , funcube or funcube pro plus aren't working anymore, rtl sdr yes

strange, because without arguments it should use exactly the same code path as before.
how does it not work? does it show some errors, or just no decode? could you paste a few messages from tetra-rx? (especially the AFC ones, maybe some BURST messages etc)

./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft.py -D hw:1 -o /dev/stdout | ./osmo-tetra-sq5bpf/src/float_to_bits /dev/stdin /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx /dev/stdin

you could also try:
./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft.py -D hw:1 -o /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx -i -a /dev/stdin

but if it doesn't work with the previous line, then it won't work with this.

The avantage of the batch with fcdp-tetra_demod_fft.py is that it can be run with no display graph , that is better for CPU and memory usage of slow PCs

funcube will always be faster, because the PC has much less data to process. you can disable the display graph (just disable the graphical elements in the flowgraph and turn off the wxgui option). you can also use 256k sample rate with the rtl, this works even on a very old laptops.

Any idea ?

none. could you revert to the old version and see if it starts working? maybe it's some other problem (didn't tune properly etc)

btw you can take float_to_bits from the new osmo-tetra-sq5bpf and use it with the version which works, it also has the -a option.


unfortunately i don't have a funcube to test with.

 

[skinkie]

EDIT: quick update on how the pseudo-afc works. Without the -a option the receiver works when the signal is offset -1.6 to 1.3kHz. With the -a option the receiver works when the signal offset is -2.8 to 2kHz. So that's 65% more capture range (useful when your dongle oscillator drifts a lot).

Works awesome. I was able to reduce my ppm to 0 and really focus on tuning.

RX:     AFC:                            FREQUENCY
1       +000 [..........|..........]

Above it is 'Known Frequencies' if I would be able to receive them, how would one set up up to 8 channels?

 

[sq5bpf]

Works awesome. I was able to reduce my ppm to 0 and really focus on tuning.

thanks for trying it out!

you probably meant that it let you set the ppm to some value (not 0), and not have to tweak it every time the dongle changes temperature (this comment is for the benefit of other users reading this)

Above it is 'Known Frequencies' if I would be able to receive them, how would one set up up to 8 channels?

look at the docs, there is an example how to monitor 2 (from the same LA) and 4 channels (from different networks). in telive/gnuradio-companion/ you have flowgraphs for listening up to 6 channels with one dongle , but you can easily modify them to support 8 channels (or wait a few days, and i will provide 7 and 8 channel versions). you need to run one receiver process per channel, and then have a telive instance for each LA that you're monitoring.

btw the 'known frequencies' window will have information from various sources: SYSINFO messages (shows the current LA's control channel and capabilities), D-NWRK-BROADCAST (shows neighbouring control channels), and ChanAlloc (shows frequencies used for other channels from this LA). if you want to monitor multiple channels, then it is best to start with a few channels from one LA (so use only the frequencies from ChanAlloc - these are marked with A) since this will require only one telive instance

 

[skinkie]

you probably meant that it let you set the ppm to some value (not 0), and not have to tweak it every time the dongle changes temperature (this comment is for the benefit of other users reading this)

I don't know if it works as it is suppose to. If I try to tune the relative frequency to the Downlink that is on screen I have to go to -102ppm which sounds a bit too much. But since the 2 channel script also has something like -56 I might be wrong, and it may be so extreme.

look at the docs, there is an example how to monitor 2 (from the same LA) and 4 channels (from different networks). in telive/gnuradio-companion/ you have flowgraphs for listening up to 6 channels with one dongle , but you can easily modify them to support 8 channels (or wait a few days, and i will provide 7 and 8 channel versions). you need to run one receiver process per channel, and then have a telive instance for each LA that you're monitoring.

PDF indeed contains it and I got it to work as well:

RX:     AFC:                            FREQUENCY
1       +002 [..........|..........]
2       +003 [..........|..........]

It would have been nice if the screens contained the 2M fourier transform so tuning to the frequencies would be visually possible.

btw the 'known frequencies' window will have information from various sources: SYSINFO messages (shows the current LA's control channel and capabilities), D-NWRK-BROADCAST (shows neighbouring control channels), and ChanAlloc (shows frequencies used for other channels from this LA). if you want to monitor multiple channels, then it is best to start with a few channels from one LA (so use only the frequencies from ChanAlloc - these are marked with A) since this will require only one telive instance

Downlink:425.3562MHz    Uplink:415.3562MHz      MCC:  204       MNC:  707       LA:  110        reason:[SA]     RX:2
Downlink:425.9062MHz                                                            LA:  109        reason:[N]      RX:1
Downlink:425.7312MHz                                                            LA:  108        reason:[N]      RX:1
Downlink:425.4812MHz                                                            LA:  104        reason:[N]      RX:1
Downlink:425.6812MHz                                                            LA:  106        reason:[N]      RX:1
Downlink:425.5562MHz                                                            LA:  102        reason:[N]      RX:1
Downlink:425.2563MHz                                                            LA:  105        reason:[N]      RX:1
Downlink:427.0813MHz                                                                            reason:[A]      RX:1

Sometimes 427 disappears, it does label [A] does it mean I can use it in the same instance?

 

[sq5bpf]

new version of telive is out. this version shows the country and network names in the frequency window

before compiling please install libxml2-dev:

sudo apt-get install libxml2-dev


the names are in tetra.xml, i got the list from a site that hosts mainly GSM operators, so if you know of a better list for your country, or an url from your local telecoms authority that has this data, then please send me updates

 

[skinkie]

Tetra receiving & decoding on a Rpi2

Is there someone here who had tried to install GNU Radio 3.6 on a raspberry Pi 2 ?
If i use the script from sbrac.org it fails on the RaspPi 2 with no specified error.

I had modified the sbrac.org scrip to get it work with the latest Debian release for the RaspPi 2.

Proud to announce that I have just got the following working:

0. gnuradio-3.7.9
1. receiving data from an osmosdr source directly on the RPi2 (rtl-tcp)
2. getting it to work with Gnuradio-Companion on the host system
3. compiling the grc script modify it to run headless on the RPi2
4. running grc headless on the pi with direct hardware access (hence not using rtl-tcp)
5. running telive on the Rasberry Pi
6. encoding sound with opus
7. broadcasting metadata & voice to zeromq

Load average: 1.71, 1.79, 1.65 [verbose messages off in telive]

Indication of the cpu usage across the different components;

root     16485 71.0  7.0 204992 66796 pts/3    Sl+  23:33  16:34 python2 top_block.py
root     16491 12.8  7.2 221248 68912 pts/1    Sl+  23:33   3:00 python demod/python-3.7/simdemod2.py -o /dev/stdout -i /tmp/fifo1
root     16492 17.2  0.1   2856  1624 pts/1    R+   23:33   4:01 ./tetra-rx -a -i /dev/stdin
root     16581 11.2  0.6  25520  6080 pts/5    Sl+  23:41   1:47 ./telive

If people are interested I am happy to write up an in depth tutorial on this specific project. But I want to focus on the bigger picture

For now a small picture

 

[sq5bpf]

If people are interested I am happy to write up an in depth tutorial on this specific project. But I want to focus on the bigger picture

i'm sure many will be interested even if they won't say so

btw could you try how many channels can you decode at once?

i've tried to use the first version of raspberry pi, but that lacked the cpu power, and could barely do 1 channel even with very reduced sample rate

 

[sq5bpf]

Downlink:425.3562MHz    Uplink:415.3562MHz      MCC:  204       MNC:  707       LA:  110        reason:[SA]     RX:2
Downlink:425.9062MHz                                                            LA:  109        reason:[N]      RX:1
Downlink:425.7312MHz                                                            LA:  108        reason:[N]      RX:1
Downlink:425.4812MHz                                                            LA:  104        reason:[N]      RX:1
Downlink:425.6812MHz                                                            LA:  106        reason:[N]      RX:1
Downlink:425.5562MHz                                                            LA:  102        reason:[N]      RX:1
Downlink:425.2563MHz                                                            LA:  105        reason:[N]      RX:1
Downlink:427.0813MHz                                                                            reason:[A]      RX:1

Sometimes 427 disappears, it does label [A] does it mean I can use it in the same instance?

yes.

this sometimes disappears because it's unused (some stations will even turn off the carrier)

 

[sq5bpf]

the MNC lists for Sweden and Finland have been updated. Thanks the people who have sent me the lists!


the present list is based upon a list of GSM operators, the TETRA MNCs should not overlap with them (but they do) and if a company does both GSM and TETRA they should use the same MNC (which is not always the case), so the list is not very good at the moment (only the lists for Sweden, Finland and Poland should be ok).

if you want to update the list for your country, then send me:

- which country (obviously )

- an url for a web page from your local telecoms authority with a list of MNCs, if there is such a thing (usually there is)

- a list of MNCs in a text file (whatever format). this can include things which are not on the official list (sometimes companies make up their own MNCs) . for now please don't use national characters, only ascii

- additional information that might be useful for people if they want to update the list in the future

- info if you want any credit for sending the list to me (some people want it, while others want to stay anonymous)

 

[sq5bpf]

i've been asked via PM how to upgrade, and thought others may like this info too:

#first make sure you have internet access
sudo apt-get update
sudo apt-get upgrade #do this if you want to upgrade your system, which is a good idea anyway
sudo apt-get install libxml2-dev #the newest version of telive needs this library


cd ~/tetra #or wherever you downloaded the sources
cd osmo-tetra-sq5bpf/src
#if you modified any files (like receiver1) then rename them
git pull
make


cd ~/tetra #or wherever you downloaded the sources
cd telive
#if you modified any files (like rxx) then rename them
git pull
make

if you want just the file with the MCC/MNC list, then it is at:

https://github.com/sq5bpf/telive/raw/master/tetra.xml