SDR# TETRA Demodulator Trunk Tracking Demonstration

[jlmarc33]

@Motik @jlmarc33 and maybe @Sinager

I think I may have an answer to your problem.

In the newer SDR# (around v1733+) a feature was added for the lazy loading of plug-ins.
This will stop the plug-in from running the UI if the side panel for plug-in is minimized.
This results in an internal error when TTT tries to set 'netinfowindowopen' (because UI is not there) and the plug-in returns the error response to TTT which just keeps retrying it and will not proceed until it gets a OK response from the plug-in.

So if the plug-in side panel is minimized when you start TTT, then the following error is seen:

==============
14/11/2020 9:35:46 AM
Unknown ERROR[RAW]:
Last DATA: Result:Error,Type:Syntax error,Message:{\command\: \set\, \method\: \netinfowindowopen\, \value\: true}
==============
Syntax error in \method\: \netinfowindowopen\ invalid \value\: true}
==============
Call active: False
tmrSaveTimed: True
==============

So make sure it's not minimized and it should be OK.
Let me know if this works for you.

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

@thewraith2008, thank you too for your investigation about this strange behaviour.
Same as Motik, my TETRA demodulator side panel has always been open.
I gave a try to last SDR# (v1779 release) with my W10 Pro PC. I have to manually open netinfo window,... and the new plugin View/Activation does not seem simplified.

 

[iw2kpl]

ho visto che gli algoritmi sono stati rotti

But the decrypt

 

[DarkAngelT]

@thewraith2008 I have noticed that TTT is not playing private calls.
In the timeslot the name private call is displayed and in TTT the private call is detected, however it is not played
Is there a way for private calls to be heard?

 

[thewraith2008]

I'm not seeing that problem when I testing here.

Check setting in 'Options 2' > 'Play only when both ISSIs seen on private call'
If this is enabled, a private call where all the PDUs where not sent (should be indicated by [half] ) will not be played.
This could be because one ISSI is on the LA you are listen to and the other on a different LA.
See post here to see diagram. While it's for a group call, it can be applied to private call to show where PDUs flow (and don't)

If this is not the case, then a IQ sample capturing both main carrier and traffic carrier (if different) will be require to investigate further.



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

 

[tomekjkp]

Hello @thewraith2008 is it normal for something like this to appear all the time?

 

[thewraith2008]

If you are using TTT in single mode then yes, this was a bug where 'callinfo' command was sent to the VC SDR# which of course is not used so an error 'SET: No SDR# NET connection' is seen every time call is setup.



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

 

[DarkAngelT]

Thanks for your answer.
In option 2 this option is not checked.
About being in another LA ... I don't think so, because I noticed a few times that the calls were in the same listening LA.
About sending the sample, I will try when I am watching. Because there are almost no private calls in LA and when they do, it doesn't last for many minutes.

 

[thewraith2008]

Investigating your logs would also show what PDUs are sent for private call.

Using TTT in single mode makes it harder to capture all PDUs for private call.
Private call PDUs are sent about 30 seconds before call actually starts. If a group is seen before this it can affect receiving all required PDUs (if sent).



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

 

[DarkAngelT]

Investigating your logs would also show what PDUs are sent for private call.

Using TTT in single mode makes it harder to capture all PDUs for private call.
Private call PDUs are sent about 30 seconds before call actually starts. If a group is seen before this it can affect receiving all required PDUs (if sent).



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

I use it in dual mode. I'll take a look

 

[Kazzaw]

Just tried to reinstall on a new laptop. I am struggling with stability issues, mainly the VC instance crashing, sometimes both crashing. SDR# Version 1.0.0.1784. Using supplied fresh files from download.

Errors.txt giving me the following

==============
22/12/2020 10:22:14 AM
Unknown ERROR[RAW]:
Last DATA: Result:Error,Type:Syntax error,Message:{\command\: \set\, \method\: \netinfowindowopen\, \value\: true}
==============
Syntax error in \method\: \netinfowindowopen\ invalid \value\: true}
==============
Call active: False
tmrSaveTimed: True
==============

 

[thewraith2008]

This has been mentioned here.
The other cause of this issue (French language) should not be affect you.

At this stage I have no plans to spend time on this plug-in further adapting it to SDR# themes.
The handling of these themes (for all plug-ins) is becoming a waste of my (and other plug-in developers) time.

I would recommend sticking will an earlier version of SDR# (before 1717 is best (pre-Telerik) or before 1777 - pre-Telerik docking)


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

 

[Kazzaw]

Thanks, greatly appreciated. Found an older version (1700) and is working perfectly recording and tracking a busy network. Thanks for all the time you put into this program

 

[Kazzaw]

Spoke too soon - It was working fine, crashed on an invalid pdu or something (missed the error message). When restarting TTT, it just crashes as soon as voice traffic is detected... Might need to spend a little more time looking into it.

 

[WireDelphin]

@thewraith2008
From manual of Tetra Demodulator Plugin:

TXer will be the SSI of the encrypted PDU.
The SSI will most likely be 'Encrypted Short Identity' (ESI). Which means the SSI is encrypted.
This could possibly show that the MS is in call but this does not mean the MS is actually talking.

What exactly does encrypted ESI mean? So how long stays it the same? Suppose a new call from the same mobile station a few minutes later: Has it the same SSI or another one? If it is the same after a few minutes: how long does ist stay the same for this particular mobile station?
If SSI is not the same: Is there any unencrypted metadata in an encrypted network you could use to identify individual mobile stations?

 

[thewraith2008]

What exactly does encrypted ESI mean?

From what you quoted from the documentation:

...'Encrypted Short Identity' (ESI). Which means the SSI is encrypted.

So how long stays it the same? Suppose a new call from the same mobile station a few minutes later: Has it the same SSI or another one? If it is the same after a few minutes: how long does ist stay the same for this particular mobile station?
If SSI is not the same: Is there any unencrypted metadata in an encrypted network you could use to identify individual mobile stations?

No idea to all above.
I never had an encrypted network to monitor/analyze.
Others here who see this type of activity maybe able to answer.



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

 

[hamradionl]

I notice, a network that normaly use TA1
This day TTT Network screen tell the PDU is enc on the MAIN show GSSI + ISSI and other LA show no GSSI no ISSI is clear voice (sometime enc).

 

[Ubbe]

So how long stays it the same? Suppose a new call from the same mobile station a few minutes later: Has it the same SSI or another one?

The TEA3 system I monitor that carries the national police and rescue services among many other services are said to change the key once a year or similar for critical users and the non critical users, that not really need encryption, always use the same key.

Tetra demodulator shows the encrypted value and it will be different depending of the site. I can see the same user id that are affiliating to the same site day after day and conversation after conversation.

Security Analysis of Tetra from a university in Norway.

"The Cipher Key will be modifed by the Carrier Number (CN), LA-id, and Colour Code (CC) using the algorithm TB5"

/Ubbe

 

[WireDelphin]

Hi Ubbe. Thanks for that really worthful information.

"The Cipher Key will be modifed by the Carrier Number (CN), LA-id, and Colour Code (CC) using the algorithm TB5"

So that means if devices do a handover to another tetra basestation they get another SSI and can't be tracked over multiple base stations, right?

Is there any software to decode frames / get any data out of the transmissions the mobile stations send to the Base stations? I know there are devices which detect these signals called Python Detectors or Target Blue eye. But don't know if they actually decode anything or just detect signals in the Tetra uplink band and warn based upon the received signalstrength. Didn't provide links to these devices, because I don't know if this is allowed or perhaps not welcomed here.

 

[Ubbe]

They are just RF detectors that sweep the frequency band and trigger on the exact pulse lenght that a mobile transmits. They do not do any kind of decoding of the actual data.

If you set a scanner to WFM for broadcast that are some 200KHz wide and preferable use AM mode you will hear any nearby mobiles in that frequency span. The trick is to monitor the whole frequency range that they use, and a SDR dongle and a RaspberryPi can cover some 5MHz and then need some software code to trigger on the correct pulse lenght.

/Ubbe

 

[WireDelphin]

These companies claim that their scanners can detect Tetra mobile stations long before you see them. But these mobile stations won't trasmit voice or data all the time. Most time its just that their tetra MS is turned on.
I think they send some kind of ping to the base stations like GSM mobile phones do every few minutes which you could here when placing them near to a cheap radio receiver. Do you know how often these impulses are sent in Tetra networks when the user of a mobile station doesn't actively trasmit any data?