• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

SDR# TETRA Demodulator Trunk Tracking Demonstration

lemano

Newbie
Joined
Dec 13, 2018
Messages
2
SDR#1700 with SDRPlay RSP1a ==> if you know a driver, iam able to test it for you.
SDR# + RTLSDR-V3 using a special driver better selectivity
SDR# + Airspy-mini give improvements better selectivity.
SDR# + PlutoSDR its works but driver little bit unstable
SDR#1700 with RSP1a
You can use
TCP SERVER V1.0 (15TH FEB 2019)
available here: Downloads – SDRplay ...
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
17th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.0.16.0


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.16.0"
It's is required for some SDS features to work with TETRA Trunk Tracker v1.0.16.0. Please read text files in zip for plug-in.


This plug-in version changes/adds and fixes some items:
Code:
v1.0.16.0

ADDED: SSI element to 'PDU encrypted:' output message.
- This SSI value may also be encrypted. If it is, it means it's wrong.
   I don't know how to determine if SSI is encrypted or not (or if I can at all, standards seem vague on this).

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:
Code:
v1.0.16.0

Various minor changes and bug fixes.

see Changelog.txt
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-June-19).
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 c29605f1fcef57601db209e52ec7442f
 

point2point

Member
Joined
Oct 30, 2015
Messages
13
Thanks, for the new release.

16.0 can't write to the DSDPlus.LRRP file i get a DSDPLUS io Error (75)

15.0 is working fine with SDS on and fastlane DSD
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
Thanks, for the new release.

16.0 can't write to the DSDPlus.LRRP file i get a DSDPLUS io Error (75)

15.0 is working fine with SDS on and fastlane DSD
Error 75 is a path/file access error. (for the DSDPlus.LRRP file)
I don't think it's a file path issue as checks are done for this.

This path is tested on TTT start. e.g. it looks to see if LRRP.exe is in the path defined. If path is blank, this is not tested and the DSDPlus.LRRP file is saved to TTT working folder.
If the test returns it is not valid, it resets path to use TTT working folder. TTT shows pop-up to indicate this.
When you enter a path, TTT also tests this path like above.
If path is valid the "DSDPlus.LRRP save path" above textbox on right will turn green.
If path is not valid then it's the same as not defining a path and will save DSDPlus.LRRP to the TTT folder. On saving of settings the path will be cleared. (The textbox may still show the invalid path for that session)

Does the path where DSDPlus.LRRP is saved, have read/write access? Probably not this a you would see a different error message anyway.
Check to see if the attribute for DSDPlus.LRRP is NOT set to 'Read-only'

Setting the attribute to 'Read-only' was only way I could see this error.



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

yugps

Member
Joined
Oct 2, 2018
Messages
13
Error 75 is a path/file access error. (for the DSDPlus.LRRP file)
I don't think it's a file path issue as checks are done for this.

This path is tested on TTT start. e.g. it looks to see if LRRP.exe is in the path defined. If path is blank, this is not tested and the DSDPlus.LRRP file is saved to TTT working folder.
If the test returns it is not valid, it resets path to use TTT working folder. TTT shows pop-up to indicate this.
When you enter a path, TTT also tests this path like above.
If path is valid the "DSDPlus.LRRP save path" above textbox on right will turn green.
If path is not valid then it's the same as not defining a path and will save DSDPlus.LRRP to the TTT folder. On saving of settings the path will be cleared. (The textbox may still show the invalid path for that session)

Does the path where DSDPlus.LRRP is saved, have read/write access? Probably not this a you would see a different error message anyway.
Check to see if the attribute for DSDPlus.LRRP is NOT set to 'Read-only'

Setting the attribute to 'Read-only' was only way I could see this error.

not support SDR#(SDRSharp)x86 rev 1702



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

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
not support SDR#(SDRSharp)x86 rev 1702
Just a note about your post first. If you are writing something inside the quoted message, you need to break in to it with the tags:
Code:
[/QUOTE]  <-- at position in quoted message just before you start your message.
[QUOTE]   <-- after your message and before the remainder of quoted message.
Use the preview button before you post your message to test what it looks like first.
If you don't do this then I may not see you message and I'll just think someone has just quote message without saying anything.


Not sure why you quote my post.
Are you saying you have same issue and it's related to using SDR# 1702?
It won't be as the issue is with TTT. (or with file been read only?)

If you are saying TTT+plug-in is not working in SDR# 1702.
In my initial test, it works fine.



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

point2point

Member
Joined
Oct 30, 2015
Messages
13
Error 75 is a path/file access error. (for the DSDPlus.LRRP file)
I don't think it's a file path issue as checks are done for this.

This path is tested on TTT start. e.g. it looks to see if LRRP.exe is in the path defined. If path is blank, this is not tested and the DSDPlus.LRRP file is saved to TTT working folder.
If the test returns it is not valid, it resets path to use TTT working folder. TTT shows pop-up to indicate this.
When you enter a path, TTT also tests this path like above.
If path is valid the "DSDPlus.LRRP save path" above textbox on right will turn green.
If path is not valid then it's the same as not defining a path and will save DSDPlus.LRRP to the TTT folder. On saving of settings the path will be cleared. (The textbox may still show the invalid path for that session)

Does the path where DSDPlus.LRRP is saved, have read/write access? Probably not this a you would see a different error message anyway.
Check to see if the attribute for DSDPlus.LRRP is NOT set to 'Read-only'

Setting the attribute to 'Read-only' was only way I could see this error.



Latest version (v1.0.16.0) can be found here: Release post
Hi,

I tried everything you mentioned here.
File is not read only, path is empty (using the TTT directory) and it is green.
Also specifiying a path does not help, what ever i do keep having IO error (75)
v 1.0.15.0 does not have this problem, can i try anything else ?
I will go back to v 1.0.15.0 for now.
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
Hi,

I tried everything you mentioned here.
File is not read only, path is empty (using the TTT directory) and it is green.
Also specifiying a path does not help, what ever i do keep having IO error (75)
v 1.0.15.0 does not have this problem, can i try anything else ?
I will go back to v 1.0.15.0 for now.
Strange, I'm sure from 1.0.15 to 1.0.16 nothing changed in relation to 'DSDPlus.LRRP' creation/appending.
If the file was already opened from either TTT, DSDPlus or something else then a different error would show.

What is the full path to your TTT folder?
How big is the file 'DSDPlus.LRRP'
If you delete 'DSDPlus.LRRP' (or just rename original to something else) then re-run TTT, does it still give the same error?



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

point2point

Member
Joined
Oct 30, 2015
Messages
13
Hi,

I found out that when i run TTT folder for example in Downloads (Windows 2012 Server) and specify the LRRP path it will work.
Leaving it blank gives me that error, but no problem i just specified the path now , maybe it is windows server related i run TTT as admin so it can write anywhere.
Anyway it looks like it is windows server 2012 related then , everything up and running again on .16
Thank you for the support.
 

hamradionl

Member
Joined
Mar 23, 2014
Messages
337
Anyway it looks like it is windows server 2012 related then , everything up and running again on .16
Because i think logic and just being be curious You use diff windows for version 15?
Because when use the same PC for 15 is works, so it must be also work in 16
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
Hi,

I found out that when i run TTT folder for example in Downloads (Windows 2012 Server) and specify the LRRP path it will work.
Leaving it blank gives me that error, but no problem i just specified the path now , maybe it is windows server related i run TTT as admin so it can write anywhere.
Anyway it looks like it is windows server 2012 related then , everything up and running again on .16
Thank you for the support.
OK, I did a bit of digging on this and found that there is a problem with TTT here. Simply solution but a pain to find.:sick:
The problem starts from a new install.
The path save string variable was not initialized on new installs and if the 'DSDPlus.LRRP save path' field is never changed then it remains that way.
If you do change it then it will be OK from then on.

Will be fixed in next release.(y)



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

ScanHen

Member
Joined
Mar 18, 2018
Messages
9
Running TTT v1.0.16 and SDR# v1.0.0.1700 on W10

Unexpected Error has occurred - Please report this
Error in: Section 0
Error #:[52]
Error:[Bad file name or number]

lastPDUerror.txt:
17-7-2019 - 09:28:56 - CC -
17-7-2019 - 09:28:56 - VC -
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
Running TTT v1.0.16 and SDR# v1.0.0.1700 on W10

Unexpected Error has occurred - Please report this
Error in: Section 0
Error #:[52]
Error:[Bad file name or number]

lastPDUerror.txt:
17-7-2019 - 09:28:56 - CC -
17-7-2019 - 09:28:56 - VC -
That's odd, that section does not even have anything to do with opening a file.

How often does this it occur and when (at TTT start, running for a while, on close)?
Do you have 'Create Call Activity CVS' enabled?
What's your path to TTT. Having a long path to TTT and it's sub folders can cause issues with TTT. Keep it short like 'C:\SDR\TTT'



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

ScanHen

Member
Joined
Mar 18, 2018
Messages
9
That's odd, that section does not even have anything to do with opening a file.

How often does this it occur and when (at TTT start, running for a while, on close)?
Do you have 'Create Call Activity CVS' enabled?
What's your path to TTT. Having a long path to TTT and it's sub folders can cause issues with TTT. Keep it short like 'C:\SDR\TTT'



Latest version (v1.0.16.0) can be found here: Release post
It happened after running for a while and it was the first time. I am running v1.0.16.0 since 2 days after its release.
I do not have 'Create Call Activity CVS' enabled.
The path is: D:\Gebruikers\xxxxxxxx\Downloads\TTT_1.0.16.0_release but I will move it to a shorter path.
 

CqDx

Member
Premium Subscriber
Joined
May 15, 2003
Messages
918
Location
US
Hi all,

While looking into the Neighbour Cell tab, when a Neighbour LA is advertised, does it always mean it is within the same network?
For example:
MNC 111 is advertising Neighbour LA 2222 - Does it mean LA 2222 must be part of MNC 111 or can it be MNC 333?

Thanks
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
688
Hi all,

While looking into the Neighbour Cell tab, when a Neighbour LA is advertised, does it always mean it is within the same network?
For example:
MNC 111 is advertising Neighbour LA 2222 - Does it mean LA 2222 must be part of MNC 111 or can it be MNC 333?

Thanks
Neighbor LAs seen are related to current MNC only.
There would be no point to advertise unrelated (MNC) cells as MSs from different providers (MNC) can't use them anyway.



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

tsapers

Member
Joined
Aug 25, 2011
Messages
65
Howdy all

Have you seen this before?
I seem to not get it on the v1.0.14 release with its related plugins, once I go to v1.0.15+ it starts doing this.
Best I can describe is that SDR# "pauses" for a second. As can be seen from the screen grab at that point CPU spikes and then returns to the normal sub 10% for SDR#. Look at the Diagram and the SDRSharp.exe
This of course has an effect on the decode and voice output.
Disabling the plugin (Demodulator) in SDR# has no effect, even stopping the SDR dongle in SDR# has no effect. The processing remains the same.
Only option is to close SDR# and rerun. On the specific signal I have a SNR of around 34 and 100% Receive in the Demodulator, except when it jumps to a new frequency where I see a slight drop to high 80%\low 90%.

I have been running v1.0.14 now for a few days without this issue. Previously when testing with v1.0.15 versions it would happen, within minutes\hours\max within a day.

I have tried a clean install of SDR# and then upgrading directly to the latest TTT release with the same results. Have also tried SDR# version 1660 and 1700.
View attachment 72595
Just some more info on this and the posts that followed it....
I upgraded from Win 7 64bit to Win 10 64bit. Issue persisted. I then did a clean install of Win 10 64bit, but the issue still persisted.
I have in the meantime started running TTT in dual mode and WOW what a difference it makes. The Mem\CPU issue is still there, but doesn't affect the audio and trunking as much as it did in single mode as now the audio us done by the VC instance.
However I am now seeing exactly the same symptoms hamradionl saw at the beginning of the year, where his system would increase in CPU and Mem usage for the CC SDR# instance and would eventually crash with SystemOutofMemoryException as per this post and the following ones. SDR# - TETRA Demodulator Trunk Tracking Demonstration

I will wait for this condition to occur again and then post the exact error here.
 

tsapers

Member
Joined
Aug 25, 2011
Messages
65
Just some more info on this and the posts that followed it....
I upgraded from Win 7 64bit to Win 10 64bit. Issue persisted. I then did a clean install of Win 10 64bit, but the issue still persisted.
I have in the meantime started running TTT in dual mode and WOW what a difference it makes. The Mem\CPU issue is still there, but doesn't affect the audio and trunking as much as it did in single mode as now the audio us done by the VC instance.
However I am now seeing exactly the same symptoms hamradionl saw at the beginning of the year, where his system would increase in CPU and Mem usage for the CC SDR# instance and would eventually crash with SystemOutofMemoryException as per this post and the following ones. SDR# - TETRA Demodulator Trunk Tracking Demonstration

I will wait for this condition to occur again and then post the exact error here.
Was eventually able to capture the error.

************** Exception Text **************
System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
at System.Runtime.InteropServices.Marshal.AllocCoTaskMem(Int32 cb)
at System.Windows.Forms.UnsafeNativeMethods.GetWindowText(HandleRef hWnd, StringBuilder lpString, Int32 nMaxCount)
at System.Windows.Forms.Control.get_WindowText()
at System.Windows.Forms.TextBoxBase.get_WindowText()
at System.Windows.Forms.Control.get_Text()
at System.Windows.Forms.TextBox.get_Text()
at System.Windows.Forms.TextBoxBase.get_Lines()
at SDRSharp.Tetra.NetInfoWindow.‌‫‌‫‬‬‎‏‏‌‭‭‪‌‫‎‏‏‌‎‮‌‮(Object , EventArgs )
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This time pointing to the VC instance. Clicking "Continue" on the exception,it just continued as normal.
 
Top