SDR# TETRA Demodulator Trunk Tracking Demonstration

[DarkAngelT]

Very nice to see there is a cooperation between the two "gods" of tetra.
Thank you both for there efforts
thewraith2008, wish you be stay around and fallow.

Dude, you said everything! I also call them Tetra God! Tetra gods, thank you for listening to our prayers !!!

 

[thewraith2008]

Hi,
Testing your plugin right now, works better that before:
For DMO it works OK, but previous release was better, because now when transmitting it jumps between Slots, not very much, but it happens, reported to TSSDR as well (I haven't seen this "jumping" in the previous release).
For TMO it's awesome, AFC and other features have improved the plugin and I think my problem with "false ISSI" has gone, so it's a progress.
Thanks!

Is this for DMO MS-MS or DMO Repeater?
Is it jumping though out call, or just at start.

"Auto" should be OFF for DMO

On the IQ samples I have tested with, all calls appear on TS1 with exception of one of the repeater IQ samples which TS1 and TS2 are shown. This is the master and slave and same content is heard.

The only reason I can think of for why it would jump around is the timebase synchronization has not taken hold. This occurs on one of the samples I tested with. Once it has sync'ed the correct timeslot is maintained.

By "false ISSI" if you mean the pseudo_SSI as described a few post back (in the plug-in changelog). Nothing has changed here.
The real ISSI is just not visible to second (or other) user as far as I can see. I've been told that "pseudo_SSI" changes on each transmission.
So unless there is a manufacture specific algorithm to reverse this and reveal the real ISSI we will just have to put up with the pseudo_SSI for now.
If there is a "manufacturer specific algorithm" then it probably only works to and from that manufacturer's radios and not other manufacturer's radios. Just a guess though.

 

[RicardoRJ]

thewraith2008

Congratulations on this update.
Testing is latest version some ISSIs are being detected as if they were Groups (GSSI), I do not know if anyone else detected this, but here in my network is occurring!
In most everything ok!

 

[gustavobm]

thewraith2008

Congratulations on this update.
Testing is latest version some ISSIs are being detected as if they were Groups (GSSI), I do not know if anyone else detected this, but here in my network is occurring!
In most everything ok!

I also noticed that!

 

[DarkAngelT]

thewraith2008

Congratulations on this update.
Testing is latest version some ISSIs are being detected as if they were Groups (GSSI), I do not know if anyone else detected this, but here in my network is occurring!
In most everything ok!

After testing for a few hours I realized that too!

 

[thewraith2008]

I have mainly been testing using TTT in single mode, I've noticed in dual mode that the CC SDR# goes into high CPU (approx 30%) and memory condition.
I have located the cause (cleanup code in wrong place that was getting hammered).

This is resulting in erratic behavior in both TTT and SDR#.
Not sure if any impact on TTT in single mode.
Perhaps if you have a single cell network where you don't move of main carrier you will see problem. If it does move around then the plug-in is clear out data as it changes frequency.

Hot-fix to follow shortly.

Not sure if has anything to do with "some ISSIs are being detected as if they were Groups (GSSI)" issue. Will keep an eye out for it.

 

[thewraith2008]

Hot-fix #5 for TTT v1.0.8 Public Release - Updates TETRA Demodulator plug-in to v1.0.10.1



This hot-fix #5 is only for the full release version of TTT v1.0.8 and no other version.

TTT v1.0.8 (and the previous hot-fix #3) must be installed first. Then copy new file to setup.
EDIT: The above line and also hot-fix 4 is considered bad (link removed) don't use it.

Only this one file have been updated:

• SDRSharp.Tetra.dll

Copy it to the usual place.


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

v1.0.10.1

FIXED: High CPU usage (approx. 30%) and memory (approx 200 Mb) condition.
       'Network Info' window tabs (mainly 'Calls' PDU log panel) cleanup code in wrong place that was getting hammered.

CHANGED: Disabled Unallocated timeslot code as it was playing up. Not sure why yet. Need to investigate.

MD5 HASH: 8a533e7632b9d969e66a4b2495c851f4 for "SDRSharp.Tetra.dll"

Download link

MD5 HASH 9f45b7c818e3ff1e70661d531c3bc1a6

Lets see how this goes.

 

[hamradionl]

goodmorning,
thewraith2008
Last late night send you PM about some funny thinks happening with SDR#. I will test this new HotFix version see if this is oke.
Please, take your time we not going anyware.

Trunktracker.exe file size from 1.08 is smaller as 1.09. Is this correct?

 

[hamradionl]

DUAL MODE After some time running,
1x SDR# version / window crashes Other is still open, i had this before in hotfix 4

type System.OutOfMemoryException.
at mscorlib.dll.Dictionary`2.Resize (IL offset: 0x19)
at mscorlib.dll.Dictionary`2.Insert (IL offset: 0x10e)
at SDRSharp.Tetra.dll.GlobalFunction.ParseParams (IL offset: 0x8f)
at SDRSharp.Tetra.dll.PduParser.MacEndPDU (IL offset: 0x4)
at SDRSharp.Tetra.dll.PduParser.ParsePDU (IL offset: 0xca)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x19f7)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0x98)
at mscorlib.dll.ThreadHelper.ThreadStart_Context (IL offset: 0x14)
at mscorlib.dll.ExecutionContext.RunInternal (IL offset: 0x79)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x0)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x2b)
at mscorlib.dll.ThreadHelper.ThreadStart (IL offset: 0x8)

 

[DarkAngelT]

DUAL MODE After some time running,
1x SDR# version / window crashes Other is still open, i had this before in hotfix 4

type System.OutOfMemoryException.
at mscorlib.dll.Dictionary`2.Resize (IL offset: 0x19)
at mscorlib.dll.Dictionary`2.Insert (IL offset: 0x10e)
at SDRSharp.Tetra.dll.GlobalFunction.ParseParams (IL offset: 0x8f)
at SDRSharp.Tetra.dll.PduParser.MacEndPDU (IL offset: 0x4)
at SDRSharp.Tetra.dll.PduParser.ParsePDU (IL offset: 0xca)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x19f7)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0x98)
at mscorlib.dll.ThreadHelper.ThreadStart_Context (IL offset: 0x14)
at mscorlib.dll.ExecutionContext.RunInternal (IL offset: 0x79)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x0)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x2b)
at mscorlib.dll.ThreadHelper.ThreadStart (IL offset: 0x8)

Here before my second SDR burn, I used the TTT in dual mode. I noticed that in double mode it worked much better than in single mode! But after a couple of hours in use, it always gave a blue screen.
I do not know if the burning of the second SDR board is due to the constant stops by blue screen. The fact is that after it burns, I'm being forced to use single mode until I can import another SDR card. After that he never gave a blue screen. I leave for hours on and the system does not stop!

 

[hamradionl]

i always use DUAL mode 2x RTL-SDR-V3 build 2018 with a powered 4 Amps USB hub connect to USB 3.0 on Intel i5 PC run WIN-10 64bit.
When runnig SDR# i using different tasks, like browser is open and other programs
This never before in the other versions, it started from 1.09. Sometimes after 15 - 30 minutes or after some several hours or so.
Lets wait if these ERROR messages is causing by TTT or something else.
5 minutes ago i did fresh restart all SDR#, see how its go but this new start i switch
Callist altergeneration = OFF
Increase PDU element verb = OFF

 

[DarkAngelT]

Hot-fix #5 for TTT v1.0.8 Public Release - Updates TETRA Demodulator plug-in to v1.0.10.1



This hot-fix #5 is only for the full release version of TTT v1.0.8 and no other version.

TTT v1.0.8 (and the previous hot-fix #3) must be installed first. Then copy new file to setup.
EDIT: The above line and also hot-fix 4 is considered bad (link removed) don't use it.

Only this one file have been updated:

• SDRSharp.Tetra.dll

Copy it to the usual place.


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

v1.0.10.1

FIXED: High CPU usage (approx. 30%) and memory (approx 200 Mb) condition.
       'Network Info' window tabs (mainly 'Calls' PDU log panel) cleanup code in wrong place that was getting hammered.

CHANGED: Disabled Unallocated timeslot code as it was playing up. Not sure why yet. Need to investigate.

MD5 HASH: 8a533e7632b9d969e66a4b2495c851f4 for "SDRSharp.Tetra.dll"

Download link

MD5 HASH 9f45b7c818e3ff1e70661d531c3bc1a6

Lets see how this goes.

Testing here. I'll tell you later how it worked.

 

[DarkAngelT]

Thewraith, would there be a possibility in a next fix or release to have an option in the G / SSI Editor so that all changes made at once can be saved? I ask this question because currently each change must be made and applied to ^ UPDATE.

If we could make all the changes and apply only once would be better.

 

[thewraith2008]

DUAL MODE After some time running,
1x SDR# version / window crashes Other is still open, i had this before in hotfix 4

type System.OutOfMemoryException.
at mscorlib.dll.Dictionary`2.Resize (IL offset: 0x19)
at mscorlib.dll.Dictionary`2.Insert (IL offset: 0x10e)
at SDRSharp.Tetra.dll.GlobalFunction.ParseParams (IL offset: 0x8f)
at SDRSharp.Tetra.dll.PduParser.MacEndPDU (IL offset: 0x4)
at SDRSharp.Tetra.dll.PduParser.ParsePDU (IL offset: 0xca)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x19f7)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0x98)
at mscorlib.dll.ThreadHelper.ThreadStart_Context (IL offset: 0x14)
at mscorlib.dll.ExecutionContext.RunInternal (IL offset: 0x79)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x0)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x2b)
at mscorlib.dll.ThreadHelper.ThreadStart (IL offset: 0x8)

This is yet another crash (#4) you have with SDR# with "type System.OutOfMemoryException." but all with different cause.
This one looks like it's related to a fragmented PDUs. But I think this is some other problem.

I use SDR# 1671 and have not tested with newer versions. Try 1671 and see if problem still exists.

I have been running TTT + SDR# since I released hot-fix #5 ealier today and it's running like a champ.

 

[hamradionl]

Yes, from 1.08 i change from SDR# 1666 to SDR# 1700.
Yes in 1666 TTT run for days
I turn OFF things i mention and SDR# 1700 +TTT DUAL running after 2e restart for 1 hour without Crash
I try SDR# 1666 later
EDIT:
DUALMODE
Memory use SDR# 1 = 43 Mb
Memory use SDR# 2 = 35 Mb
Ttrunker = 3mb
Total memory uses = 47 % all programms

 

[RicardoRJ]

Testing the new version (Hot-fix # 5 for TTT v1.0.8 Public Release), the problem of recognizing some ISSIs as if they were GSSI groups remains!
thanks

 

[gustavobm]

My TTT also display the ISSI (from the user who calls first) as the GSSI sometimes.

 

[thewraith2008]

thewraith2008

Congratulations on this update.
Testing is latest version some ISSIs are being detected as if they were Groups (GSSI), I do not know if anyone else detected this, but here in my network is occurring!
In most everything ok!

Testing the new version (Hot-fix # 5 for TTT v1.0.8 Public Release), the problem of recognizing some ISSIs as if they were GSSI groups remains!
thanks

My TTT also display the ISSI (from the user who calls first) as the GSSI sometimes.

Scoured my log files to see if I could find this and eventually found some. This is a bug, I think with the plug-in.
It does not seem to be outputting a GSSI value on the first D-SETUP PDU it sees. Most PDUs are sent about 4 times and the following PDUs for D-SETUP seem to have the GSSI element.
This does not occur all the time which will make it a pain to trouble shoot.
Investigating now what to do. I'll try and capture a IQ sample of it occurring so I can test with the plug-in but in the mean time I can probably make a fix for TTT to deal with the problem.

 

[hamradionl]

@thewraith2008
I using SDR# 1700 for test TTT and TSDDR , because for new users 1700 is the most recent version who is available for download from airspy website.
No idea about the memory crash.txt problem, this morning after 30 minutes, again only 1 SDR# screen crashed.
Did a new startup SDR# see what that bring.

 

[hamradionl]

After some hours play:
Dual mode
SDR# VC = working
SDR# CC = crasht

System.OutOfMemoryException.
at mscorlib.dll.Dictionary`2.Resize (IL offset: 0x19)
at mscorlib.dll.Dictionary`2.Insert (IL offset: 0x10e)
at SDRSharp.Tetra.dll.SduParser.Parse (IL offset: 0x23)
at SDRSharp.Tetra.dll.PduParser.MacEndPDU (IL offset: 0x6f)
at SDRSharp.Tetra.dll.PduParser.ParsePDU (IL offset: 0xca)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x19f7)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0x98)
at mscorlib.dll.ThreadHelper.ThreadStart_Context (IL offset: 0x14)
at mscorlib.dll.ExecutionContext.RunInternal (IL offset: 0x79)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x0)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x2b)
at mscorlib.dll.ThreadHelper.ThreadStart (IL offset: 0x8)