SDR# TETRA Demodulator Trunk Tracking Demonstration

[polar1]

Slow but safe progress. IP packet headers are read correctly and seems like SNDCP reassembly might be working fine. In the attachment is a dump for single destination address (10.8.10.66) in the network. UDP datagrams seem a bit off with length always being 0 in UDP headers...

 

[molay]

Great work polar1!

I'm glad to see someone working at SNDCP Data. Are you going to share your version? Have you thought about an output feature in pcap format to load/analyze IP data in wireshark, tcpdump, etc?

 

[thewraith2008]

Slow but safe progress. IP packet headers are read correctly and seems like SNDCP reassembly might be working fine. In the attachment is a dump for single destination address (10.8.10.66) in the network. UDP datagrams seem a bit off with length always being 0 in UDP headers...

Might be a good idea it start a different thread about it as this is not related to TETRA Trunk Tracker.

 

[polar1]

Sure, I'll create a new thread with next update. For now, here's the first PCAP with some data.

 

[tomekjkp]

Hello my friend, would you be able to make the plugin the ability to set your own configuration of the message with the message sds?

 

[polar1]

There is now a separate thread for TETRA IPv4 traffic decoding. Please post all topics related to that subject over there.
https://forums.radioreference.com/threads/tetra-ipv4-network-decoding-and-capturing.385766/

Thank you! And sorry for hijacking this thread for a bit, @thewraith2008

 

[DarkAngelT]

I'm looking forward to the release of the upcoming TTT!

 

[Nightman_SDR]

Hi,

first i want to thank all the People involved in this Project for their effort and Time they put into it.
I was using TTT newest version with SDR# 1700 in Single Mode without any issues, now i got a second RTL stick but i cant get dual mode working.
Seems like the 2nd SDR# window is not getting the correct Network Remote Port assigned, it starts and TTT shows in log that there is 2 SDR# but it just sets up one with the port 3383, and the other one ist just open but not configured. The Positions in TTT (Auto,Demodultaor) are set up correctly for CC SDR#, what am im missing here

 

[thewraith2008]

Hi,

first i want to thank all the People involved in this Project for their effort and Time they put into it.
I was using TTT newest version with SDR# 1700 in Single Mode without any issues, now i got a second RTL stick but i cant get dual mode working.
Seems like the 2nd SDR# window is not getting the correct Network Remote Port assigned, it starts and TTT shows in log that there is 2 SDR# but it just sets up one with the port 3383, and the other one ist just open but not configured. The Positions in TTT (Auto,Demodultaor) are set up correctly for CC SDR#, what am im missing here

Did you put TTT into 'Dual Mode'. From Menu > Tools "Dual Mode" and restart?
Is the 2nd SDR running from same folder as first?
Is 'Net Remote' side panel expanded and visible? Both SDR# CC and VC windows need to be visible at same time when TTT "Start" is clicked.
Is 'Checkbox detection' setup?

I recommend looking through "TTT_Set-up_manual.pdf" to see if any step was missed. See sections:

• SDR# Configuration
• TETRA Trunk Tracker – Initial (Dual mode)
• TETRA Trunk Tracker – Running (Dual mode)​

 

[Nightman_SDR]

Did you put TTT into 'Dual Mode'. From Menu > Tools "Dual Mode" and restart?
Is the 2nd SDR running from same folder as first?
Is 'Net Remote' side panel expanded and visible? Both SDR# CC and VC windows need to be visible at same time when TTT "Start" is clicked.
Is 'Checkbox detection' setup?

I recommend looking through "TTT_Set-up_manual.pdf" to see if any step was missed. See sections:

• SDR# Configuration
• TETRA Trunk Tracker – Initial (Dual mode)
• TETRA Trunk Tracker – Running (Dual mode)​

I wasnt aware of that option in Tools Menu, it works now. Thank you.

 

[thewraith2008]

I wasnt aware of that option in Tools Menu, it works now. Thank you.

[RANT ON]
People complain when documentation doesn't exists. The documentation here I provide is more than most SDR programs offer.
Honestly, I go to the effort of creating documentation and changelogs to explain things about the program and it's setup for people and they don't bother to even open it or read it.

I'm beginning to understand why sq5bpf added this to his documentation:

TL;DR: Anyone saying “too long; didn't read” will be considered a lazy idiot. I've spent a lot of
time writing this documentation, and telive users are expected to read all of it (multiple times if
needed). Questions resulting from failure to do so will be ignored at best. I'm not a big fan of the
“TL;DR” abbreviation.

[RANT OFF]



Latest version (v1.0.14) can be found here: Release post

 

[enCrypt]

Can anyone tell me if a Tetra control channel always stays on the same frequency, or do they move?
Thanks...

 

[hamradionl]

Can anyone tell me if a Tetra control channel always stays on the same frequency, or do they move?
Thanks...

most use the same frequency but i notice 1x local network use 2x CC channels and TTT jumping between those 2x CC.

 

[enCrypt]

Thanks for that, so will the CC SDR# move on its own under the control of TTT if the control channel changes?
For further clarification, I'm not sure what the control channel is on my local network of around 6 different freqs...

 

[thewraith2008]

...so will the CC SDR# move on its own under the control of TTT if the control channel changes?

Yes. TTT uses the 'Main carrier' element in the SYSINFO PDU to determine what the main carrier (and where MCCH) is for a network (MNC)
If that value changes, then TTT will switch to that newly defined (main) carrier.
So long as the new (main) carrier that has been switched to 'Main carrier' element in the SYSINFO PDU reflects this new change then it should stay, otherwise it will switch to whatever it says the main carrier is.

'D-Release' PDUs also point to the control channel (MCCH) carrier when a call is ended so MS's end up back at the MCCH on the right carrier.
So if MCCH changes carrier while a MS is on a call (on a different carrier), it will switch back to correct carrier for MCCH.
Currently I don't use 'D-Release' for that purpose.

I have never seen MCCH change carrier myself, only heard from one other person about it and they never got back to me about it. Maybe TTT does the job. It should work OK in theory.

For further clarification, I'm not sure what the control channel is on my local network of around 6 different freqs...

As stated above, TTT will determine the main carrier of any carrier selected and switch (CC SDR#) to it.
TETRA Demodulator also shows the main carrier of the selected TETRA carrier.
In SDR# side panel, It is shown (as 'Main: zzzz xxx.xxxx MHz') with a blue link. The current selected carrier is shown as 'Current: zzzz xxx.xxxx MHz'. 'zzzz' = carrier #.

 

[enCrypt]

Great stuff, thanks for that. I had another look at this last night and I can actually find 7 frequencies that report a valid Main carrier number in the Network Info / Current cell window. I looked through all the Neighbour cells to find them all and have made a list of freqs, aligned to main carrier number, aligned to LA. However every one of these that I set my CC SDR# to reports Main and Current are the same in the SDR# side panel. Nothing ever seems to change the CC SDR# (unless I do it myself). The VC SDR# does move to additional non main carrier freqs but I'm wondering if I'm missing out on any calls...

 

[thewraith2008]

TTT with the TETRA Demodulator plug-in only monitors 1 LA at a time and it plays calls on a 1st seen first served basis.

but I'm wondering if I'm missing out on any calls...

Most likely, that's trunking. You just have to accept that you can't hear it all and move pass it.
That's why you use GSSI lockouts and priorities to try and focus in on the calls that interest you the most.

 

[enCrypt]

Ok thankyou. I'll put the 7 freqs into the SDR# scanner plugin and let it hang on each for 5 seconds or similar. With that and GSSI lockouts, I'll need to read up on how the priorities work I should not miss too much... Please keep up the good work on this, it is very much appreciated.

 

[hg69956]

Hi,

I've been using TTT 1.0.7 for some while now and is all working fine. I'm trying out TTT 1.0.14 on my mobile setup to see if it's safe to upgrade my setup at home. When trying 1.0.14 it crashes as soon somebody is talking on the Tetra network.

TTT freezes but SDR# keeps running. I'm using SDR# v1700 and used the files from the latest release (plugins etc.). I also tried running TTT as admin but no difference.

Does anyone experienced this problem before?

 

[hamradionl]

use WIN 7 or WIN 10 ?
try upgrade to the latest .NET (DOT NET) after your upgrade SDR# 1700 + TTT 1.0.14 run ok.