SDR# TETRA Demodulator Trunk Tracking Demonstration

kayakaan02

Newbie
Joined
Dec 2, 2022
Messages
3
@thewraith2008 first thank you for your hard work and effort on this.

I got a question in my mind. I can use tetra-rx on msys with sdr#, but is sdr# really necessary for this? correct me if I'm wrong but I think it only sends data to tetra-rx, receives the decoded data back and displays it, I can as well see the output on msys window.

I really don't need the speech decoder but only the output from tetra-rx. So how can I send data to tetra-rx from another source? for example from gnuradio using udp sink etc.

Also I see tetra-rx is an executable file. How did it compiled into an exe? is there an open source code of it so I can see and work on it myself?

Thanks in advance.

edit: sorry if this is already asked, I couldn't find it anywhere
 
Last edited:

kayakaan02

Newbie
Joined
Dec 2, 2022
Messages
3
Thanks in advance.

edit: sorry if this is already asked, I couldn't find it anywhere

From gnuradio, I used "float to complex" and "CQPSK Demod" on the wav file of a tetra signal and saved into a file. It worked well with tetra-rx.exe

This means my problem is with socat and receiving data from udp.

Sorry for disturbing.
 
Last edited:

lwvmobile

DSD-FME
Joined
Apr 26, 2020
Messages
1,294
Location
Lafayette County, FL
This means my problem is with socat and receiving data from udp.

For what its worth, I've also had issues in the past with UDP streams in various projects. If you think about it, UDP streams aren't protected on delivery, so its possible for packets to be dropped or timing to be incorrect, etc. If you switch it up to a TCP sink in GNURadio and try to have socat listen and pipe that instead, it may work out better. It might also be worth mentioning I've had some issues with UDP and TCP in Cygwin, which is akin to MSys2, so its also possible that there is some delay or lag involved, or some quirk of that environment that makes UDP delivery not very reliable.
 

kayakaan02

Newbie
Joined
Dec 2, 2022
Messages
3
For what its worth, I've also had issues in the past with UDP streams in various projects. If you think about it, UDP streams aren't protected on delivery, so its possible for packets to be dropped or timing to be incorrect, etc. If you switch it up to a TCP sink in GNURadio and try to have socat listen and pipe that instead, it may work out better. It might also be worth mentioning I've had some issues with UDP and TCP in Cygwin, which is akin to MSys2, so its also possible that there is some delay or lag involved, or some quirk of that environment that makes UDP delivery not very reliable.

Thanks for the advice,

Right now I don't want to use any enviroment such as msys2 or cygwin. Because tetra-rx actually doesn't need to be executed on an env.

I will record the signals to a file from gnuradio and read the data from there, as osmo-tetra in linux does. I just want it to be less complex and easy to use/reach for just decoding and not for the listening(I'm also trying to figure out libtetradec for that seperately) so I have to figure out about handling the file size tomorrow.

I will try to update if I figure it out with a gnuradio grc file and a python file.
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,857
@thewraith2008 first thank you for your hard work and effort on this.

I got a question in my mind. I can use tetra-rx on msys with sdr#, but is sdr# really necessary for this? correct me if I'm wrong but I think it only sends data to tetra-rx, receives the decoded data back and displays it, I can as well see the output on msys window.

I really don't need the speech decoder but only the output from tetra-rx. So how can I send data to tetra-rx from another source? for example from gnuradio using udp sink etc.

Also I see tetra-rx is an executable file. How did it compiled into an exe? is there an open source code of it so I can see and work on it myself?

Thanks in advance.

edit: sorry if this is already asked, I couldn't find it anywhere
This should be discussed in it's own thread as it does not relate to this TETRA Demodulator Plug-in or TETRA Trunk Tracker (TTT) project at all.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here
 

hamradionl

Member
Joined
Mar 23, 2014
Messages
730
SDR#1700 use TTT standalone
6 or 7 tetra freq with strong/high SNR, show MCC-1, MNC-1, LA-1, COLOR-1, MAIN-0
No voice
Anyone else seeing this kind channels?
 

Hunno

Member
Joined
Sep 26, 2019
Messages
13
Hey,

didn't know where I need to report bugs, maybe here?

Screenshot_1.png

CurrTimeSlot, 1
MAC_PDU_Type, 0
Fill_bit, 0
Position_of_grant, 0
Encryption_mode, 0
Random_access_flag, 0
Length_indication, 14
Address_type, 1
SSI, 800583
Capacity_Allocation, 0
Granting_delay, 1
MacPduRealSize, 112
PduStartOffset, 0
LLC_Pdu_Type, 1
MLE_Protocol_Discriminator, 2
CMCE_PDU_Type, 15
Calling_party_type_identifier, 1
Calling_party_address_SSI, 16777213
Short_data_type_identifier, 3
User_Defined_Data4_Length_Indicator, 8
User_Defined_Data4, 0
Protocol_identifier, 2
Text_coding_scheme, 0
CRC_check: 0

BURST[64]: 0000001000000000000010000001100010000110000110111001010000000011
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,857
I had a little look at this and I can see some issues.

The User_Defined_Data4_Length_Indicator length is only reporting 8 bits.
This should be greater than 16 bits (and more if message is present) - It should have enough for at least:
  • Protocol_identifier = 8 bits
  • Reserved = 1 bit
  • Text_coding_scheme = 7 bits
  • message_bits = > 8-16 bits at a minimum one would expect

There is actually not enough bits to decode anything further.
It could be possible that there is a parsing error after the CMCE: SDS PDU is processed.
I think an IQ sample of this SDS event occurring is required to properly investigate this further.

The other issue is BURST[64] binary dump is to long
  • It should be only 8 binary bits shown (BURST[8]: xxxxxxxx)
  • The 8 should be the value from User_Defined_Data4_Length_Indicator
  • This [64] is an bug in the plug-in in which that value was hard coded and the value from User_Defined_Data4_Length_Indicator was not used.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here
 

Hunno

Member
Joined
Sep 26, 2019
Messages
13
Hello,

Thank you for your reply, but I'm not a programmer and I didn't understand very much. I can say that I had another error like this before, but it is not critical. In a couple of years of use, these are the first errors.

I am writing on a different subject, on reflection.
Is it possible to expect something like SDS forwarding/reporting of messages to the Telegram bot, or something like that?
As I said, I am not a programmer, but I have some knowledge. I have enlisted the help of ChatGPT AI to help me write a bot code that checks the SDS log file (created by TTT) and sends the new lines that appear to the correspondence. The code has been generated, even several, but I can't quite get it to run. :)
Perhaps this would be a thought for the author? Or for someone else who knows how to code?
If you're interested, I can send you the generated code, maybe with the help of the people here we could manage to get it to run. :)

73
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,857
How often do you see error?

The only way I can fix is by having a recording (IQ sample) of it occurring.
The recording can usually be done with a second SDR setup in parallel using the IF recorder plug-in in SDR#.

See post here on instructions on how to do it.
NOTE: You can get the updated IF Recorder SDR# plug-in can be found here: MEGA - Download
 

Radiotech73

Member
Joined
Jul 26, 2019
Messages
9
Hello,

I seem to have a problem using TTT (v.1.8.6.0). I attached the screenshot for a better explanation. TTT just doesn't show the call while it's visible on the plugin's window. I also tried to use LRRP (DSD+) but shows nothing, even though they do use LRRP. Maybe because it's encrypted? But I heard that it still works...

tetra.PNG
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,857
None of the encrypted PDUs are past to TTT as it can't track this kind of activity.
If you wish to listen to the encrypted voice, you will have to do it with the plug-in as a standalone. (TTT mode disabled)

The display of the encrypted TS usage is at best a guess of what is going on.
There are limits as to what can be expected of the information shown. (partly described in the documentation)

If the system is encrypted, you will not be able to see LRRP data if those related PDUs are encrypted.
Even if they are not encrypted, you may only see (BS) request to send LRRP, not the response which doesn't always return to the downlink.


Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here
 

oe5kbo

Member
Joined
Oct 22, 2013
Messages
45
Location
Wels Austira
Hallo Ich bin Karl und mich interessiert, wie stark das Uplink-Signal ist. Das Tetra-Uplink-Signal ist sehr schnell nur 14 Millisekunden groß, aber mit einem guten Empfänger und einem Booster muss es


funktioned. Ich möchte im Amplidude sehen und überprüfen, wie stark es ist. Haben Sie eine Idee, dies zu tun?????





Danke
 

nimhm

Newbie
Joined
Jan 25, 2023
Messages
3
Hey guys.

I would be very gratefull if someone could help me with showing GPS locations in LRPP.

The thing is that coordinates are sent in DMO mode. I can get coordinates manually when DMO is checked (in TETRA demodulator network info) it says latitude and longitude, speed, heading so I coppy manually in Google maps.

But how can make that info show in LRPP. I have all configured, demodulator connected to TTT all is working, path to LRPP is also specified. Does this feature maybe not work in DMO?
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,857
Hey guys.

I would be very gratefull if someone could help me with showing GPS locations in LRPP.

The thing is that coordinates are sent in DMO mode. I can get coordinates manually when DMO is checked (in TETRA demodulator network info) it says latitude and longitude, speed, heading so I coppy manually in Google maps.

But how can make that info show in LRPP. I have all configured, demodulator connected to TTT all is working, path to LRPP is also specified. Does this feature maybe not work in DMO?
TTT does not handle any of the DMO activity.
In retrospect, it probably would have be better to have the plug-in handle the LRRP traffic file.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here
 

Ivalpe

Member
Joined
Feb 9, 2023
Messages
6
Please i need help. I have installed TTT following all the steps. I get this error over and over again. I have installed windows 10 and 11. Same mistake. Can someone help me please? thank you so much
 

Attachments

  • error.jpg
    error.jpg
    68.9 KB · Views: 32

tomekjkp

Member
Joined
Jan 10, 2019
Messages
36
Please i need help. I have installed TTT following all the steps. I get this error over and over again. I have installed windows 10 and 11. Same mistake. Can someone help me please? thank you so much
You don't have sdrsharp enabled with the plugin
 

Ivalpe

Member
Joined
Feb 9, 2023
Messages
6
Could you please tell me if you are so kind, what do you mean? I have installed the tetra plugin but still the same. thanks for answering. I leave a sample of my screen.

you are very kind to help
 

Attachments

  • ejemplo.jpg
    ejemplo.jpg
    87.5 KB · Views: 49

tomekjkp

Member
Joined
Jan 10, 2019
Messages
36
Could you please tell me if you are so kind, what do you mean? I have installed the tetra plugin but still the same. thanks for answering. I leave a sample of my screen.

you are very kind to help

you need to use the plugin which is in the plug-ins folder and then set it according to the instructions in the docs folder
 
Top