SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

14th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.0.15.8


This package (version) of TETRA Trunk Tracker and TETRA Demodulator plug-in (with codec libtetradec.dll) are only meant to be used
with each other and with no other previous versions. To do so will most likely cause issues.

TETRA Demodulator plug-in has been updated by me. "Tweaked Edition (Unofficial) v1.0.15.8"
It's is required for some SDS features to work with TETRA Trunk Tracker v1.0.15.8. Please read text files in zip for plug-in.

This plug-in version changes/adds and fixes some items:

v1.0.15.8

FIXED: SDS PDUs that use text encodings('TextCodingScheme'): "ISO/IEC 8859-10 Latin 6" or "ISO/IEC 8859-14 Latin 8"
        caused SDR# to crash.
       - If above two text encodings are used, then "ISO/IEC 8859-1 Latin 1" will be used in there place.
       - The PDUs that use 'TextCodingScheme' element will still show the requested encoding, but
          will use the above stated text encoding.

If SDR# is crashing when 'Demodulator' is enabled, it's because you have not set-up the plug-in correctly.
You MUST do this 1st. This is NOT TETRA Trunk Trackers fault.

You generally need to get these installed:
"Microsoft .NET Framework 4.6.2 (Offline Installer)"
"Microsoft .NET Framework 4.7.2 (Offline Installer)"
"Microsoft Visual C++ 2015 Redistributable" and install both 32/64 bit versions (if you use 64 bit OS)



This TETRA Trunk Tracker version changes/adds and fixes some items:

v1.0.15.8 - Minor update

FIXED: SDS LIP 'Velocity' element handling error
- When non numeric value e.g.: "Velocity:Horizontal speed is not known"
- This will now be used when above is seen: "Velocity:0.0km/h"

CHANGED: If D_TX_Granted PDU seen with 'E2EE' then will report in call event log
- NOTE: If D_Setup is seen with 'E2EE', then call will not start.

Has been tested on Windows 7 - Basic (64 bit)
Has been tested on Windows 7 - Professional SP1 (32 bit), English
Has been tested on Windows 10 - Professional (64 bit)

I have created it to suit my needs. And it currently works for me with the TETRA network I monitor.

I make no claim that it will work for other networks.

Please read the provided files for set-up and usage:

• TTT_set-up_manual.pdf
• TTT_Features_and_Usage.pdf

I have tried to be as thorough as possible with the documentation to explain usage and features.
I believe any questions can be answered by reading these files.
These files most likely are not complete and contain errors and are not laid out as good as they could be.

The TETRA plug-in is now been mainly tested with SDR# 1700 on Windows 7 Professional 32 bit with no issues seen.
The TETRA plug-in with SDR# 1700 on Windows 7-10 64 bit PCs is untested by me and is known.

It only works with the provided TETRA plug-in supplied in zip. (2019-May-10).
This version uses a custom compiled version of 'Net Remote' supplied in zip

It is only meant to be a temporary solution until something better comes along.

Please look at the "changelog.txt" for both plug-in and TTT as these maybe contain instructions/explanations for features that may not be covered in the PDF documentation.


Download

MD5 HASH 178aadb9dda7e8b6878cac8d6351cdfc

 

[ferminSV]

still only the old version(TTT v1.0.14) works for me.(win 10 home 64bit)

 

[thewraith2008]

still only the old version(TTT v1.0.14) works for me.(win 10 home 64bit)

Help me help you.

Please read the following posts and answer questions I've asked of people with this issue:
See this post
and this post
and this post
and this post
and this post
and this post
and this post
and this post

I can not fix something if it does not look broken to me.

You have now reached 5 posts, so you should be able to PM me with the details and desktop recording you mentioned in your post #856



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

 

[thewraith2008]

Just an update about issue R3Natas and ferminSV where having.

To Recap:
They ran SDR#+plug-in and TTT then clicked 'Start' in TTT, it set-up SDR# and then TTT retrieved the MCC/MNC/LA then did not continue processing any calls.
It seemed as though TTT could not read the PDUs output that TETRA Demodulator created (in 'Network Info')

I received IQ samples from them both and tested on my set-up, both on Win7-32bit and Win10-64bit with no problems.
This helped determine that #1, the Tetra signal was not of a different type and #2 that TTT was working with it.

A workaround/solution that seems to work that was put forward by ferminSV was to set the 'system locale' language to English from another language that is not English.
See in "Region and Language" > "Language for non-Unicode programs" > "Change system locale..."

Not sure really what the problem is here and why this fixes the issue.
The PDUs output from 'Network Info' looked fine in images that where supplied.
Assuming this is where the differences in locale was.

Also, please check to you have set-up "Checkbox Detection" in TTT. This is needed so TTT can control SDR#.
The default values are only for Windows 7 Basic theme. If you use any different OS (i.e. Windows 10) or change to a different theme, then you will need to reconfigure it.



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

 

[palq]

Just an update about issue R3Natas and ferminSV where having.

To Recap:
They ran SDR#+plug-in and TTT then clicked 'Start' in TTT, it set-up SDR# and then TTT retrieved the MCC/MNC/LA then did not continue processing any calls.
It seemed as though TTT could not read the PDUs output that TETRA Demodulator created (in 'Network Info')

I received IQ samples from them both and tested on my set-up, both on Win7-32bit and Win10-64bit with no problems.
This helped determine that #1, the Tetra signal was not of a different type and #2 that TTT was working with it.

A workaround/solution that seems to work that was put forward by ferminSV was to set the 'system locale' language to English from another language that is not English.
See in "Region and Language" > "Language for non-Unicode programs" > "Change system locale..."

Not sure really what the problem is here and why this fixes the issue.
The PDUs output from 'Network Info' looked fine in images that where supplied.
Assuming this is where the differences in locale was.

Also, please check to you have set-up "Checkbox Detection" in TTT. This is needed so TTT can control SDR#.
The default values are only for Windows 7 Basic theme. If you use any different OS (i.e. Windows 10) or change to a different theme, then you will need to reconfigure it.



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

After the change "Region and Language" > "Language for non-Unicode programs" everything works right.

Thanks.

 

[slicerwizard]

Not sure really what the problem is here and why this fixes the issue.

I would guess that it's because you're using a programming language / runtime environment that calls Windows functions that are affected by the locale/language settings.

 

[thewraith2008]

I would guess that it's because you're using a programming language / runtime environment that calls Windows functions that are affected by the locale/language settings.

Yes I need to look into this further, I need to add some sort of debugging mode so I can determine where to start focusing my efforts.

I still find it odd that this affects some people and not others. Even when they are using the same (non English) language.



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

 

[DarkAngelT]

thewraith2008

The program is without the option to change the groups without having to press the update button. In the previous version had.

 

[thewraith2008]

thewraith2008

The program is without the option to change the groups without having to press the update button. In the previous version had.

You have always had to click 'Update' after changing the label, priority or lockout state.
Or you can change lockout state only by using right click on a highlighted GSSI.



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

 

[thewraith2008]

Just an update about issue R3Natas and ferminSV where having.

To Recap:
They ran SDR#+plug-in and TTT then clicked 'Start' in TTT, it set-up SDR# and then TTT retrieved the MCC/MNC/LA then did not continue processing any calls.
It seemed as though TTT could not read the PDUs output that TETRA Demodulator created (in 'Network Info')

I received IQ samples from them both and tested on my set-up, both on Win7-32bit and Win10-64bit with no problems.
This helped determine that #1, the Tetra signal was not of a different type and #2 that TTT was working with it.

A workaround/solution that seems to work that was put forward by ferminSV was to set the 'system locale' language to English from another language that is not English.
See in "Region and Language" > "Language for non-Unicode programs" > "Change system locale..."

Not sure really what the problem is here and why this fixes the issue.
The PDUs output from 'Network Info' looked fine in images that where supplied.
Assuming this is where the differences in locale was.

Also, please check to you have set-up "Checkbox Detection" in TTT. This is needed so TTT can control SDR#.
The default values are only for Windows 7 Basic theme. If you use any different OS (i.e. Windows 10) or change to a different theme, then you will need to reconfigure it.

To further this issue, I have found some dodgy string handling code in TTT that was indeed messed up by some different locales.
I provided a fix/test version to ferminSV and R3Natas to try and it is working.

If you are desperate for the fix then PM me and I will send link to it, otherwise the fix will be added to next release.



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

 

[oz1jua]

A very interesting observation is that when listening to Tetra uplink frequencies you can listen to the speech if you put on DMO.
However, one can risk SDRSharp crashing after some time.
But, it does not seem to work if you choose Stronger Burst Detection which would otherwise cause SDRSharp not to crash.

This is interesting if you want to see if there is any activity nearby, even if it is encrypted traffic.

 

[thewraith2008]

A very interesting observation is that when listening to Tetra uplink frequencies you can listen to the speech if you put on DMO.
However, one can risk SDRSharp crashing after some time.
But, it does not seem to work if you choose Stronger Burst Detection which would otherwise cause SDRSharp not to crash.

This is interesting if you want to see if there is any activity nearby, even if it is encrypted traffic.

Yes the TMO uplink normal burst and DMO normal burst are basically the same however the TMO normal burst does not use the preamble/training sequence(3, part of) that exists and that is why it won't work when Stronger Burst Detection is used.

The crash is most likely because it's expecting a DMO MAC with DMO MAC elements which are not there and a crash follows, probably a KeyNotFound exception.

 

[egonc]

The file in the download link of TETRA trunk tracker is no longer available. Is there other download link? Or can somebody send me a program? Thanks in advance.

 

[hassanila]

The file in the download link of TETRA trunk tracker is no longer available. Is there other download link? Or can somebody send me a program? Thanks in advance.

https://forums.radioreference.com/t...nk-tracking-demonstration.370639/post-3125368

 

[thewraith2008]

 

[oz1jua]

Is it possible to somehow disable the volume control.
Why I say this is because I have experienced that many receptions have no sound or the sound is so low that you cannot hear it.
Ex. when the sound on Timeslot 2 comes through fine, and after a short time subsequently spoken on Timeslot 3, but to hear this you
have to manually turn up the sound.
It is OK to cut audio but the program lower Audio to Zerro. !!
And if I do not start TTT then it is working with no problem. So it seems that error is ralted to TTT.

 

[thewraith2008]

At TTT start, it sets volume to lowest which also equal muted.
When a call is active, it increases to the preset volume in "VC Volume" (25-60db SDR# values). (Default=47)
When call ends, it sets volume to lowest which also equal muted.

Not sure why you are getting different levels.
TTT itself does not touch the audio.
Do you use the AGC in the plug-in? Maybe check those values. Or test with OFF.



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

 

[oz1jua]

Right now I am not sure what goes on. But Antivirus says virus in TTT_1.15.8.

Have try to download again. But still same error. I have now go back to use 1.15.6 and it works.
Is this false positive or something. It was fist seen today.....

 

[thewraith2008]

See this post.

In my opinion AV programs are a problem in the world.
They tell (scare) people that a program is: "This program is dangerous and executes commands from an attacker" with no proof of such activity. They just use bad heuristic algorithms that blanket call all programs "dangerous and executes commands".

They should say the a program is 'suspicious' and should be tested further. Not tell the people that the world just ended.



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

 

[thewraith2008]

Anybody using Windows 10 (either 32 or 64 bit versions) having any problems with the recording of calls in TTT. Does it crash?
Please let me know if it is working in this OS for anyone as I'm not sure if the method used is actually support by these versions.



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