SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

16th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.0.15.10


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.

No changes to TETRA Demodulator plug-in in this release.


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.10 - Minor update

FIX: On some conditions, a error may be see on (private?) call timeout.
- An expected value returned NULL.

CHANGED: TEST - Added error trapping to try and stop crash on record in TTT for some setups.
- A beep will be heard on error and the error is displayed in status panel and output to 'errors.txt'
- Users have reported that using a device with [Windows Directsound] instead of [MME] in SDR# 'audio'
   output fixes the crash and recording issue.

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.

It would be helpful if the users who where having the crashing issue with TTT could test this version to see if TTT still crashes when you use the old sound device (in SDR#) that was causing crash.
If this fix works, it should stop TTT crashing and notify of you of error with a beep plus a report in the status panel and 'error.txt'.
This won't make recording work as you still need to change the sound device for that.
If someone can report back there finds that what be helpful.

Note: This link now is to a folder that stores the download, which means the link to the location of the files will stay the same but the files in it can vary.
Download

MD5 HASH 457d2d952065043f6fb8e1cd5f4a7cfb

 

[thewraith2008]

Hi Wraith,

First, thanks a lot for your efforts on TTT! Really appreciate the effort.

Second, I experienced the same issue with the audio recording. Upon the first call TTT receives, it locked up and I got the spinning wheel. The workaround as mentioned in post #943 did the trick, all is working fine now. Running Win 10 Pro, 64bit, version 1809, build 17763.503. I'm using audio recording method #1, the PC is dedicated for TTT anyway.

When TTT crashes, SDR# is working just fine as it should. It is responsive.

Thanks for reporting back.

@thewraith2008, I hope you dont mind me posting this on your post, I think this is my best opprtunity to get a fix for an issue I am having.

Hey all, any advice for me regarding stuttering audio? I cannot pin-point if this is a TTT issue or an SDR# issue, I am leaning towards an SDR# or Computer issue but thought I would ask here in case someone else has had it and maybe has a fix.

When I run SDR# and TTT, 90% of the time my audio comes through really choppy, the only way for me to remedy this is to click on Stop SDR then Start SDR a few times, this might take 5 or 6 tries before the audio starts to come through clear without audio stuttering but then slowly starts stuttering again.

My setup:

Windows 10 Pro 64Bit
16GB RAM
Intel Core i7 3.2Ghz
256GB SSD

SDR# v1.0.0.1700

TTT 1.0.15.9

Within the TETRA Demod Plugin Config I have the following:
Ignore Encrypter Data (Checked)
Listen Only Clear Speech (Checked)
Audio Bandpass Filter (Unchecked)
Audio AGC (Checked)
Increase PDU Element Verbosity (Unchecked)
SDS Show Binary String (Checked)
Stronger Burst Detection (Unchecked)
Beep on BFI (Unchecked)
Call List - Alternative Generation (Checked)
Enable AFC (Checked)

Single Mode with Recieved showing as 100%, this is a very strong signal.

When I run TTT on my work computer while connected to my SpyServer at home it works perfect, no stuttering.

Any ideas?

It won't be TTT as it has nothing to do with the audio chain.
Sounds like the issue is more related to type of set-up than the plug-in itself. If it was plug-in, it would affect everyone all the time.

In SDR# > 'Audio' > 'Latency (ms)' does adjusting value from 100 to 500 make any difference?



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

 

[tsapers]

I know there is a tool called RTLTool for RTL devices to test USB throughput (of IQ samples) to see if iq samples are dropped a a given samplerate.

Anyone know where I can find this RTLTool and if available for windows?

 

[hassanila]

Anyone know where I can find this RTLTool and if available for windows?

Here you go, for Windows.

Requirements:
Microsoft Visual C++ 2010 Redistributable Package x86/x64

 

[tsapers]

Here you go, for Windows.

Requirements:
Microsoft Visual C++ 2010 Redistributable Package x86/x64

Thanks!

 

[digiman1]

It won't be TTT as it has nothing to do with the audio chain.
Sounds like the issue is more related to type of set-up than the plug-in itself. If it was plug-in, it would affect everyone all the time.

In SDR# > 'Audio' > 'Latency (ms)' does adjusting value from 100 to 500 make any difference?

Yeah, just as I thought!, I didn't even think to look at Latency, I checked everything else.

I changed it from 100 to 50 which seems to have done the trick! Cheers.

 

[wkrgr]

Hi Wraith,

I started using version 1.0.15.10 a few days ago and tested it in various configurations (method 1 / method 2, MME and Windows Direct Sound).

All of the combinations froze TTT up at some point, even the Windows Direct Sound output setting stopped working after a few days. After the crashes it took rebooting the PC to get it working again, even switched back to the MME output b/c Windows Direct Sound wouldn’t work anymore.

I’d send you the error log, but with all the freezes there was no beep, error message in TTT or error log file :-(.

Then played around a bit more, I always experienced the crashes right after starting TTT with the record option already ON. After that it would freeze. Now it seems, that when I start TTT with the record option OFF, receive a few voice calls and only then turn the record option ON, it just runs and records smoothly.

So I’ll just keep testing that scenario. Any other use cases you’d like me to run through?

 

[ale462013]

Hi. After update to the last version i have this error. Thanks.

 

[thewraith2008]

Hi Wraith,

I started using version 1.0.15.10 a few days ago and tested it in various configurations (method 1 / method 2, MME and Windows Direct Sound).

All of the combinations froze TTT up at some point, even the Windows Direct Sound output setting stopped working after a few days. After the crashes it took rebooting the PC to get it working again, even switched back to the MME output b/c Windows Direct Sound wouldn’t work anymore.

I’d send you the error log, but with all the freezes there was no beep, error message in TTT or error log file :-(.

Then played around a bit more, I always experienced the crashes right after starting TTT with the record option already ON. After that it would freeze. Now it seems, that when I start TTT with the record option OFF, receive a few voice calls and only then turn the record option ON, it just runs and records smoothly.

So I’ll just keep testing that scenario. Any other use cases you’d like me to run through?

At the moment I have no idea why this occurs, I've tried to catch this error before it crashes TTT but it's not working.
Until I can reproduce the error here, I really can't do much about it.

The only thing I know is, it seems to only be with Windows 10 64 bit.

I remember people having issues after a Windows Update awhile back. Something about setting a privacy setting for a microphone.
DSD+ popped this message out:

More in this post here.

Not sure if could be related. My Windows 10 VM has it off and recording works for me OK.



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

 

[thewraith2008]

Hi. After update to the last version i have this error. Thanks.

Did you look at the TETRA_GSSI.txt file to see if anything looks bad/corrupted?



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

 

[DarkAngelT]

I would like to know why TTT tries to read the svchost process. I blocked this attempt and the program works normally without this process reading

 

[ale462013]

Hi @thewraith2008 thanks for helping me. I have renamed my TETRA_GSSI.txt in TETRA_GSSI2.txt and created a new blank file named TETRA_GSSI.txt but nothing, same error. When I delete the file TTT work but when i go to edit the GSSI (tool-G/SSI editor) I see this error:

Thanks again.
Alessandro

 

[wkrgr]

Hi. After update to the last version i have this error. Thanks.

Hi, I encountered the same error today, I already saw a negative ISSI (-1) in the editor in TTT. After restarting TTT, I got the error you mentioned upon TTT sorting the GSSI.txt file. Removed the string with the negative ISSI and problem solved.

 

[thewraith2008]

Hi @thewraith2008 thanks for helping me. I have renamed my TETRA_GSSI.txt in TETRA_GSSI2.txt and created a new blank file named TETRA_GSSI.txt but nothing, same error. When I delete the file TTT work but when i go to edit the GSSI (tool-G/SSI editor) I see this error:

Thanks again.
Alessandro

The first error you posted seems to occur when the file 'TETRA_GSSI.txt' is created and there is nothing in it at TTT start.
TTT creates this file when there is something to save in it.
There is not need for the user to create it (as empty).

The error occurred in the sorting section which expected data, there was none.
I've added code to now for test this.

The second error you posted is related to the 1st.
Because no GSSIs exist when the G/SSI editor is opened, the existing ISSIs list tries to load in but fails because the MCC/MNC dropdown box is empty as it's contents are loaded from the GSSI list.

I've added code to now for test this.

I don't know why after updating you got this error, your 'TETRA_GSSI2.txt' must have something wrong inside it.
You need to identify what this is and report it or sent the unmodified file ('TETRA_GSSI2.txt') to me. Also send the 'TETRA_GSSI.txt' you where using before update to if you still have it.
Also let me know the TTT version you where using before update to v1.0.15.10.

Thanks Alessandro.
I will try and upload the fix soon. But I'll wait until you reply to see if more needs to be changed to TTT to further this fix.



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

 

[thewraith2008]

Hi, I encountered the same error today, I already saw a negative ISSI (-1) in the editor in TTT. After restarting TTT, I got the error you mentioned upon TTT sorting the GSSI.txt file. Removed the string with the negative ISSI and problem solved.

Thanks, this is most likely the cause.
Are you able to look at you logs and tell me if this -1 ISSI was from a Private[Simplex/Duplex] or Group call.



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

 

[hamradionl]

thewraith2008
Your greatest fan put out this question

I would like to know why TTT tries to read the svchost process. I blocked this attempt and the program works normally without this process reading

 

[wkrgr]

Thanks, this is most likely the cause.
Are you able to look at you logs and tell me if this -1 ISSI was from a Private[Simplex/Duplex] or Group call.



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

Hi, I went through the logs, and I can't find the -1 ISSI anywhere in the individual call logs, so I'm assuming it came from a group call (does TTT log the group calls somewhere? Can't seem to find it...).

 

[tsapers]

Anyone running TTT and SDR# on any "mobile" devices. Other than a laptop?

 

[oz1jua]

I was wondering if BS send GPS position on where the mast is placed.
This is becouse I have seen some has show the LA on a MAP.
But maybe this was MAPs that was made that way by knowing there position.
And if BS send GPS position can TTT show this with LRRP.EXE.
I know that every BS in my country has GPS antenna installed on every BS.
But I have been told that this GPS is used to set exact Timeslot timing.

 

[thewraith2008]

Hi, I went through the logs, and I can't find the -1 ISSI anywhere in the individual call logs, so I'm assuming it came from a group call (does TTT log the group calls somewhere? Can't seem to find it...).

All logs if enabled are in the Daily folder (in TTT working folder), under the day folder.
"TETRA_event_xxxx.log"
TETRA_cc_xxxx.log
TETRA_vc_xxxx.log

Probably the best way to track it down if it is related to ISSI, would be when the "-1" is seen in G/SSI editor or when TTT crashes (on start), look at the (-1) ISSI date/time stamp (in G/SSI Editor or TETRA_SSI.txt) then goto the "TETRA_event_xxxx.log" and find the call at same time. This will then indicate where to look in the TETRA_Xc_xxxx.log. Then collect all PDUs related to call (call id).

If the '-1' issue is with the GSSI, then it's a bit harder to locate when the PDUs that caused the issue where seen. Looking at whole log would probably be required. I would still expect the call with '-1' to be shown in "TETRA_event_xxxx.log"

One of these PDUs must be slightly different than the expected format and the SSI value is not seen causing the returned '-1' value to be seen.

While I can fix the code to ignore these issues, it would be helpful to track down the cause of this issue.

I was wondering if BS send GPS position on where the mast is placed.
This is becouse I have seen some has show the LA on a MAP.
But maybe this was MAPs that was made that way by knowing there position.
And if BS send GPS position can TTT show this with LRRP.EXE.
I know that every BS in my country has GPS antenna installed on every BS.
But I have been told that this GPS is used to set exact Timeslot timing.

If a SDS location PDU is sent, Plug-in/TTT with decode and display them and output to LRRP (if enabled).



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