Tetra decoding

[sq5bpf]

Hello thanks for the program, i'm enjoying it every day (ubuntu 14 on a dual core, 2.4 ghz )
Good reception, excepted i can only monitor one frequency in my area (bus company)
Only issue : i get a lot of empty recordings less than 3 kb, and filename ending with 0_0
And sometimes i can't find interesting conversations i heard in real time ;
Does the issue come from average reception ?

no. there should be no case where you hear a conversation, but it's not recorded (if you enabled recording and tetrad is running properly)

I ve read the FAQ about encoding issues on Ubuntu , but didn't find any solution ;

there is a simple solution - use debian instead of ubuntu

Also i want to know about SDS messages; they don't seem to have GPS positions in them;
yet the buses operators always discuss about position data, telling the drivers he sees their location

you're probably seeing some proprietary protocol (the stuff you've sent doesn't decode to anything meaningful). maybe it's some proprietary ent-to-end encrytpion?

 

[sq5bpf]

minor update that you might like:

the grc flowgraphs now have files named telive_SOMETHING_gr37_udp.grc

these will send the data not via a pipe, but via udp packets. the corresponding script is receiver1udp (feel free to make receiver2udp etc...).

this is fun because the gnuradio-companion receiver and the receiver1udp script can be stopped/started independently of each other (and can be restarted multiple times).

so for example now you can do this:

start telive_1ch_simple_gr37_udp.grc flowgraph
start ./receiver1udp 1
(you can restart the receiver1udp script and gnuradio many times, without having to restart the other)

previously you would need to do this:
start ./receiver1 1
start telive_1ch_simple_gr37.grc flowgraph


note: you need to have socat installed:
sudo apt-get install socat

if anyone wants to have gnuradio-companion 3.6 flowgraphs, i can provide them as well



any comments are welcome. i haven't really tested the performance, it works with 2 channels, and there is no reason why it shouldn't work wiith more. maybe someone could do a performance comparison of the udp transport vs using pipes on a low-end machine (but please no ubuntu/mint, and no VMs), in theory it should be a bit worse, but not that much.

 

[FR3500]

Ok , Dziękuję

I was thinking of using Debian, i will try soon

As for encrypted SDS, i wonder what kind of data could be encrypted;
Also i noticed these sds transit only between few SSIs, it looks like datas between fixed stations, maybe network tests or trunking data;

As for GPS data , my thought is they transit only in uplink way to the operating centre, that's why they don't display in the data flow;
(also i can't hear the buses when they answer to the dispatch, so i guess their voice goes only uplink, and is not broadcasted through the air ...)

 

[sq5bpf]

As for encrypted SDS, i wonder what kind of data could be encrypted;
Also i noticed these sds transit only between few SSIs, it looks like datas between fixed stations, maybe network tests or trunking data;

i've seen stuff like this from other netowrks. often the "Calling party type identifier" is set to 3, which is a value that is not present in the docs, and the decoder refuses to decode the rest (you can see for yourself using testsds). not really sure if this is encrypted data or something else, i guess we could try to do an entropy check and see if it is random enough

As for GPS data , my thought is they transit only in uplink way to the operating centre, that's why they don't display in the data flow; not broadcasted through the air ...)

that depends. some systems will transmit the traffic from the tetra infrastructure to the management station via IP (this is preferred, and there is no reason to use radio channel capacity for thousands of SDS, unfortunately this means you won't receive any of it), while some others (in France too) wiill broadcast the SDS on the downlink (but i guess this is present only in a particular site that services the management station).

if you don't hear the dispatcher, then maybe it's on another channel. his voice has to be present on the downlink.

 

[FR3500]

No i told you i always hear the dispatchers, i hear also operators using a handeld;
i tried several frequencies, i can't receive buses or trams during an individual call, which is understandable cause they don't need to be heard by everyone on the net i think, so in this case voice may be transmitted by cable link

 

[sq5bpf]

No i told you i always hear the dispatchers, i hear also operators using a handeld;
i tried several frequencies, i can't receive buses or trams during an individual call, which is understandable cause they don't need to be heard by everyone on the net i think, so in this case voice may be transmitted by cable link

it might also be DMO

btw try to disable mutessi (it was enabled by default a few versions back, because it lowers the amount of dumb comments about garbled speech), maybe you will get something

 

[FR3500]

Yes of course, mutessi disabled;

I have to check also if i have more traffic on local tranmitters closer to the dispatch station, cause the ones i monitor seem to be wide area repeaters;

I wonder why they would use DMO, in this case, i would hear nothing at all, plus i guess DMO is used for short range traffic, whereas i listen to a wide network,, vehicles can sometimes be > 5 km from the HQ ...

 

[grahampaull]

Whoa. Running volk_profile makes a hell of a difference. That's unreal.

Sent from my SM-G925F using Tapatalk

 

[skinkie]

Just switched from E4000 to R820T... that was insane as well

 

[sq5bpf]

Just switched from E4000 to R820T... that was insane as well

better or worse? areyou sure the E4000 hasn't been zapped? (in this case it works, but with very reduces sensitivity)

btw. if your E4000 still works good, then save it for times when you need rx > 1GHz. it's better and has more range. you can solder a rf choke parallel to the antenna input (this way it might survive longer)

 

[grahampaull]

When I record a call, it is saved as filename.out, how can I listen to this?

I am hoping to be able to save all recordings here then have a player auto play these.

Sent from my SM-G925F using Tapatalk

 

[skinkie]

better or worse?

Much better.

vs

areyou sure the E4000 hasn't been zapped? (in this case it works, but with very reduces sensitivity)

What does 'zapped' means? It was boxed for years, and the only serious thing I did with it was this project.

btw. if your E4000 still works good, then save it for times when you need rx > 1GHz. it's better and has more range. you can solder a rf choke parallel to the antenna input (this way it might survive longer)

 

[sq5bpf]

What does 'zapped' means? It was boxed for years, and the only serious thing I did with it was this project.

E4000 tuners are very sensitive to electrostatic discharge, even if they have back-to-back diodes on the input (most dongles don't because it saves costs). often touching the antenna with your hand is enough to kill the tuner. this results in very reduced sensitivity.

the E4000 are now hard to get, and they have far better range than a R820T. they go up to 2.2GHz, so this is nice for gsm and other stuff. you can solder a rf choke in parallel with the antenna input, you can also try back-to-back pin diodes (but i've added them and still managed to kill the tuner somehow).

 

[sq5bpf]

When I record a call, it is saved as filename.out, how can I listen to this?

I am hoping to be able to save all recordings here then have a player auto play these.

first of all READ THE DOCUMENTATION BEFORE ASKING QUESTIONS

the tetrad script will recompress them into ogg files, and you can listen to them with your favourite player. it's best to have a player that will support long playlists (i usually use audacious, but others are fine too)

the .out files are ACELP-compressed audio, and if you want to listen to it directly for some reason, then you can do it too (the docs show how to play an acelp file). but normally there should be no need to do it.

 

[grahampaull]

first of all READ THE DOCUMENTATION BEFORE ASKING QUESTIONS

the tetrad script will recompress them into ogg files, and you can listen to them with your favourite player. it's best to have a player that will support long playlists (i usually use audacious, but others are fine too)

the .out files are ACELP-compressed audio, and if you want to listen to it directly for some reason, then you can do it too (the docs show how to play an acelp file). but normally there should be no need to do it.

I have read the docs multiple times, I do like to tinker about before asking questions.

I have set to record, I can see the .out files but no .ogg files, should tetrad do this compression on the fly?

Sent from my SM-G925F using Tapatalk

 

[skinkie]

Buffer overflow with under powered hardware

When trying to receive multiple channels on under powered hardware. This post is to figure out between what components over runs occur.

I am in the situation that the broadcaster has two channels far from each other. The RPi seems not able to deal with 2MHz of bandwidth. The result is a lot of "OOO". My question: is this O pointing out that the receiver1 isn't coping or that the initial filters aren't? Lets say I want to optimise a bit further, which variables next to the samp_rate could really help if I want to cheat a bit?

linux; GNU C++ version 5.3.0; Boost_106000; UHD_003.009.002-0-unknown

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
Exact sample rate is: 1640000.049962 Hz
Using Volk machine: neon_hardfp_orc
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

root      2897 10.4  6.7 221832 67544 pts/1    Sl+  00:10   1:07 python demod/python-3.7/simdemod2.py -o /dev/stdout -i /tmp/fifo1
root      2898 12.0  0.1   2860  1616 pts/1    S+   00:10   1:17 ./tetra-rx -a -i /dev/stdin
root      2900  4.3  0.2   3284  2208 ?        Ss   00:10   0:28 SCREEN -d -m ./receiver1 2
root      2901  0.0  0.2   3336  2188 pts/3    Ss+  00:10   0:00 /bin/bash ./receiver1 2
root      2906 10.4  6.8 221980 68584 pts/3    Sl+  00:10   1:07 python demod/python-3.7/simdemod2.py -o /dev/stdout -i /tmp/fifo2
root      2907 11.9  0.1   2860  1616 pts/3    S+   00:10   1:17 ./tetra-rx -a -i /dev/stdin
root      2908  223  6.6 229944 66320 pts/0    Sl+  00:10  23:59 python2 /root/launch.py
skinkie   2962 11.6  0.4   6972  4924 pts/2    S+   00:12   1:04 /opt/tetra/bin/telive

 

[sq5bpf]

I have read the docs multiple times, I do like to tinker about before asking questions.

have you read this particular sentence (telive_doc.pdf , page 3)?
"Telive records the calls in in ACELP codec format. You can use the script tplay to play them,
or tetrad to automatically encode them into OGG format."

I have set to record, I can see the .out files but no .ogg files, should tetrad do this compression on the fly?

it compresses all files older than 2 minutes, every 60 seconds (not sure if that counts as "on-the-fly"). tetrad is a simple shell script, so it you want to see how it works or modify it, it should be trivial to figure it out

 

[FR3500]

Hello;
about my recording or encoding issues i mentioned (missing recordings inside out folder);
i tried Telive without launching tetrad, so i could make the encoding later;
i found only 1 missing (61 out of 62 .out files)
Not a big ratio; but is there another way to encode files without using tetrad (3rd party software on linux or windows?)
I searched for "amr" or "acelp encoder" but found nothing

thanks

 

[skinkie]

Modify your tplay

#!/bin/bash
#play acelp .out files
NOW=`date +"%s%N"`
cat $* | cdecoder /dev/stdin /dev/stdout | sdecoder /dev/stdin /dev/stdout | tee /tmp/bericht-${NOW}.pcm >(aplay -fS16_LE) | /opt/tetra/bin/opusenc --raw --raw-bits 16 --raw-rate 8000 --raw-chan 1 --framesize 60 - /dev/null

 

[FR3500]

Ok thank you
What would result?
As i said all files are recorded and present,( i'm almost certain)
the issue may come from enconding by tetrad