SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

Hello,

here is a bug. I can't say if it's generated by the network itself, the tetrademodulator plugin, or TTT.

Sometimes, the txer's SSI is not displayed in the calls window of TTT.
I don't know if it's not forwarded to by the tetrademodulator plugin, or if a wrong SSI structure generates a kind of parsing error, or...?

It results of this missing that the "SSI" is replaced by a "-1" in the "TETRA_SSI.txt" file, like this (third line) :


TTT continues to work without a problem, until you decide to close it and start it again.
It then aborts, generating a type mismatch error :

View attachment 78759

Deleting the file or only the line containing the "-1" solves the problem.

Hope it helps !

Gwargl

This was a problem back in v1.0.16.0

v1.0.16.0
CHANGED: G/SSI of '-1' was sometimes saved in records which caused a "Error in: SortGssi" or "Error in: SortIssi" on start
- Added a message in status panel to indicated bad G/SSI and time seen.
- The '-1' is seen when retrieving G/SSI value from a PDU and it was not seen (but is expected).
Cause PDU unknown at this stage.
- This does not fix this issue as we need to determine what PDU is causing it to happen.

You will need to look in the status panel (above 'Call Details' panel) to see if a message about the bad ISSI/GSSI is there with timestamp.
If it is, you will then need to look in the logs 'TETRA_cc_xxxx.log' or 'TETRA_vc_xxxx.log' for the entry then send it to me unmodified so I can see whats going on with it. Check to see if you have more than one.
You will need to do this before TTT is shutdown or that timestamp info will be lost.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[Gwargl]

Ok,

I'll do this next time it occurs.

Thank you !

Gwargl

 

[thewraith2008]

oops

 

[TheButcher]

Mr. thewraith2008 showed link to downloads here...

SDR# - TETRA Demodulator Trunk Tracking Demonstration

Notice 5 positions the first 224;223 :) Ahh yes, I forgot to put in LA Country Code : Network : LA : Frequency : Label.

forums.radioreference.com

 

[vselic]

I have a problem:
CC TCP: ERROR - 9.1.2020....
IS SDR# OPEN FOR CC?

WHAT TO DO

 

[DRL-XM43]

I have a problem:
CC TCP: ERROR - 9.1.2020....
IS SDR# OPEN FOR CC?

WHAT TO DO

In the plug config have you selected to use TTT

 

[vselic]

Thank you,

i'll try to solve the problem later today. Plug config is in SDR# or TTT?

I've tried in SDR# to listen to tetra with tetra demodulator... positive, strong signal, but the voice is encrypted:
network info: Security_Class_1_supported_on_cell: 0, no clear speech will be on cell
Security_Class_3_supported_on_cell: 1: only security class 3 supported

is there any possibilty to crack this voice encryption? As far as i know, they do not work on TEA1 encryption.

 

[Erik40]

is there any possibilty to crack this voice encryption? As far as i know, they do not work on TEA1 encryption.



short answer :NO

 

[vselic]

Im sorry that it is in Slovenian language but you can translate or i can do it for you: Varnostna analiza slovenskega digitalnega radijskega omrežja TETRA

i believe its possible

 

[vselic]

In the plug config have you selected to use TTT

I cant find plug config

 

[vselic]

Ok, found plugin config works now. But the question is, when i center the frequency, when recieved the signal, it changes automatically the freq to the left. What for?

 

[Erik40]

that is AFC =Automatic Frequency Control

 

[Ubbe]

The radiosignal are transmitting data that tells what frequency it using and TTT reads that frequency and sends to SDR#. If it doesn't match with the signal on the spectrum it means that your SDR dongle needs to be frequency calibrated.

The better quality SDR dongles like SDR-RTL are almost spot on in frequency but other cheaper dongles can be many KHz off in frequency and needs to be calibrated in the configuration settings in SDR#

/Ubbe

 

[Ubbe]

Maybe it is as simple as you are trying to monitor a voice channel and not a control channel?

The datastream from the site are sending out what is the control channels slot and frequency of that site and if you are monitoring a voice channel, the TTT will send the control channel frequency to SDR# to tune to the control channel frequency where all the data are sent that TTT needs to use to be able to function.

/Ubbe

 

[vselic]

i think the problem is, that all traffic is encrypted... i went to a hill today, got 3-4 bursts, but all encrypted...:S

 

[Ubbe]

Radios needs to properly received the encryption key information after they have affiliated to the system so MNC and LA and frequencies and those kind of traffic information are never encrypted.

Your screen says that you are monitoring channel 3693 frequency 392.3375Mhz which is correct with a +12,5KHz offset but SDR# seems to tune to 392.330566MHz. It's probably due to that the dongle is off in frequency calibration.

You probably have to go into the cogwheel configuration in SDR# and try to use a ppm +2 value, or increase the current value by 2.
95% decode quality might not be enough to properly decode the signal.
Be carefull not to overload the dongle, setting the gain too high.

/Ubbe

 

[vselic]

Thanks, ill give a shot in the afternoon. But still... if i dont use Trunk Demonstration, just sdr# and tetra demodulator, it works, the signal is decoded, but all i can hear is scrambled voice... if you look at the photo, you can see security class 3 positive (tea encryption) and air encryption positive... im still worried all the tetra traffic here is encrypted.
As i said, ill try again in the afternoon...

 

[lynzoid]

tea is transport enc only. and scrambled voice sounds like e2ee on top.

 

[vselic]

Everything works, but as i said, voice is scrambled and now i'm at dead end

 

[lynzoid]

You mean you can't eavesdrop on encrypted comms? You are not supposed to, fake state dweller.