SDR# TETRA Demodulator Trunk Tracking Demonstration

[reckless76]

You will just have to try different combinations of things to see if anything else works. What the "different combinations" are is the trick.
There is no reason why v1.0.15.9 would make any different to this crash issue as the update does not address this.
I don't know what's causing crash so I can't fix it, and it sounds more like OS specific set-up issue and/or possibly a limitation of the implemented recording function on the Windows 10 64 bit OS with some sound devices.



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

Thank you for your reaction, but it is solved. But my post is waiting for approval.

 

[thewraith2008]

To people having issue with recording and TTT crashing.

When TTT crashes, is SDR# also locked up, frozen, crashed at same time? So before you close the crashed TTT, is SDR# responsive?



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

 

[DarkAngelT]

I don't know if bigger companies that produce windows software somehow reports to different AntiVirus and AntiMalware companies what programs they create and their hash sums to put them on a white list, but any program that writes to an already existing file on the harddrive are suspicious of adding damaging code to it and are flagged as dangerous and if the code bytes sequence match an already known malware or virus it flags it with that name. Using code that handles ip numbers and/or network ports are treated as code that tries to spread the detected virus or malware over the network.

If TTT didn't had code that writes to an already existing log file that builds up in size with each recording, it probably wouldn't give false detects with some antivirus/antimalware programs.

/Ubbe

I understand. But the only version of TTT that the anti virus warns me about WORM is version 1.0.15.8

 

[DarkAngelT]

15th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.0.15.9


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 should fix the issue as reported here

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

v1.0.15.9 - Minor update

FIXED: String handling issue that affected some causing TTT not to start in non-English locales

FIXED: On 2nd start (after initial set-up) a pop-up error "LRRP path is not valid" would show when path
 field was left blank. Blank is valid (saves LRRP to TTT folder). The error should only show if set 
 path no longer exists.

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.


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 c13abed7e6362a69e2a8d6ea9d5a72fd

interestingly, version 1.0.15.9 is not showing any viruses. Just as the others did not.
Here for me only version 1.0.15.8 presented the problem quoted.

 

[thewraith2008]

interestingly, version 1.0.15.9 is not showing any viruses. Just as the others did not.
Here for me only version 1.0.15.8 presented the problem quoted.

Since V1.0.15 some have told me of AV detection.
Some see it, some don't. It's a mystery, but at the end of the day it,s a false positive.

Thank you for your reaction, but it is solved. But my post is waiting for approval.

Happy to hear you got it sorted out.



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

 

[hassanila]

@thewraith2008 Is there any way to lockout an ISSI instead of a GSSI?
I have someone in the network that sends over random talkgroups but with the same ISSI so I was wondering if I can block it out?

 

[thewraith2008]

@thewraith2008 Is there any way to lockout an ISSI instead of a GSSI?
I have someone in the network that sends over random talkgroups but with the same ISSI so I was wondering if I can block it out?

No. Way to many variables to deal with blocking a ISSI.
What do you do:
Group call started by ISSI (the one which to block), If stop/block call setup, then call is missed, nothing from that call will be heard.
Group call started by other ISSI (not one you want to block), call setup, then maybe ISSI (one which to block) speaks. Then what? End call? Mute that ISSI?
Do you want to block that ISSI on all GSSI seen on, or only 1 or some?.



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

 

[hassanila]

No. Way to many variables to deal with blocking a ISSI.
What do you do:
Group call started by ISSI (the one which to block), If stop/block call setup, then call is missed, nothing from that call will be heard.
Group call started by other ISSI (not one you want to block), call setup, then maybe ISSI (one which to block) speaks. Then what? End call? Mute that ISSI?
Do you want to block that ISSI on all GSSI seen on, or only 1 or some?.



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

Alright, what I wanted to do is to block that specific ISSI everywhere on all GSSI.

 

[thewraith2008]

Alright, what I wanted to do is to block that specific ISSI everywhere on all GSSI.

What if that ISSI didn't start the call?



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

 

[hassanila]

What if that ISSI didn't start the call?



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

The call is started by that ISSI but it is more like an information broadcast, so no one answers.

 

[thewraith2008]

The call is started by that ISSI but it is more like an information broadcast, so no one answers.

OK, understand.

 

[DarkAngelT]

Sometimes the user name does not appear in the drop-down window (F12)

 

[Ubbe]

Check if SDR# show the issi number in the gssi/issi info for each timeslot.
TTT only use the info that the tetra plugin supplies from SDR# and that plugin isn't working 100% perfect.

/Ubbe

 

[thewraith2008]

Sometimes the user name does not appear in the drop-down window (F12)

ISSI/Labels will only show while a ISSI is talking (between D_TX_Grant and D_TX_Ceased)
It's possible short 'over' may not show.
Is this for a group or private call?
Does the ISSI have a label?

Check if SDR# show the issi number in the gssi/issi info for each timeslot.
TTT only use the info that the tetra plugin supplies from SDR# and that plugin isn't working 100% perfect.

/Ubbe

Well don't keep it to yourself, what is it not doing?



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

 

[R3Natas]

Hi thewraith2008,

Tested your latest release, everything works fine from my side and recording of calls started to work without crashing, thanks for new release.

 

[Ubbe]

Well don't keep it to yourself, what is it not doing?

The four timeslots info in SDR# sometimes also show the issi number in the gssi field and sometimes there's no issi number shown. I have 100% receive and I can see an 8 as the highest number in the buffer. It's always been like that since the tetra plugin where available. I'm not using the latest version and it might be the system I'm monitoring or my computer to blame if no one else sees it.

/Ubbe

 

[thewraith2008]

The four timeslots info in SDR# sometimes also show the issi number in the gssi field and sometimes there's no issi number shown. I have 100% receive and I can see an 8 as the highest number in the buffer. It's always been like that since the tetra plugin where available. I'm not using the latest version and it might be the system I'm monitoring or my computer to blame if no one else sees it.

/Ubbe

Any reason why you don't use the latest version? The ISSI <> GSSI has been fixed for sometime now.
I know there where some issues that arose in some later versions but I think these have been sorted out now with the help of user feedback.

If you use the TETRA Demodulator plug-in by itself, then the best results in the SDR# side panel values (ISSI/GSSI) and the call list (Network Info - Calls tab) is achieved by using the plug-in option "Call list - Alternative generation" enabled.

Based on using "Call list - Alternative generation":
If you use TETRA Demodulator and TTT, then the SDR# side panel values (ISSI/GSSI) and call list will not always show the correct values.
I actually recommend ignoring the SDR# side panel values altogether.
Different results in the side panel and call list can also be seen depending on TTT mode.
Not much more than what I've tried can be done about this.

• Single mode - SDR# CC and VC side panel probably will not be correct. Call list will OK, but only when on CC (MCCH).
• Dual mode - CC SDR# side panel will probably show the most accurate values, VC can not really know what's going on, so VC side panel and VC call list should be ignored. The CC call list (as shown in SDR# CC Network Info Calls tab) will be OK.

I recommend people using the latest version and if they have an issue, then post it here so the project can move forward and benefit everyone.



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

 

[wkrgr]

To people having issue with recording and TTT crashing.

When TTT crashes, is SDR# also locked up, frozen, crashed at same time? So before you close the crashed TTT, is SDR# responsive?



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

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.

 

[digiman1]

@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?

 

[hamradionl]

Any ideas?

You run SDR# 1700 TTT the 1.0.15.9
Most common for stutter
SDR#. Exe. Config sampleRate set this to 48000
SDR# AUDIO = set Audio filter OFF
SDR# RADIO = set 25000/26000 Bandwith
and
when a women / young lady speak in there radio, the audio always stutter ........