SDR# TETRA Demodulator Trunk Tracking Demonstration

[hamradionl]

@thewraith2008
SDR# 1700 + TTT -1.08 -1e release, is running the whole day

 

[thewraith2008]

Call dropout example with the TETRA Demodulater plug-in (not using TTT) for those who care.

Dropouts of audio can be caused probably by numerous things.
For whatever the reason, the audio is just gone but it usually does not cause the call (traffic channel) to become unassigned (unallocated).

In this example, a call is on timeslot 2 and abruptly ends and immediately becomes unallocated.

 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:15 - TN:1) - Unallocated
 13:34:31 PM   TCH/F                                             [VOICE] (FN:15 - TN:2) - Traffic   *** This is the speech occurring in timeslot 2
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:15 - TN:3) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:15 - TN:4) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:16 - TN:1) - Unallocated
 13:34:31 PM   TCH/F                                             [VOICE] (FN:16 - TN:2) - Traffic
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:16 - TN:3) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:16 - TN:4) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:17 - TN:1) - Unallocated
 13:34:31 PM   TCH/F                                             [VOICE] (FN:17 - TN:2) - Traffic
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:17 - TN:3) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:17 - TN:4) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:18 - TN:1) - Assigned   
 13:34:31 PM   SCH/HD [SYSINFO]                                          (FN:18 - TN:2) - Assigned   
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:18 - TN:3) - Assigned   
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:18 - TN:4) - Assigned   
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:01 - TN:1) - Unallocated
 13:34:31 PM   TCH/F                                             [VOICE] (FN:01 - TN:2) - Traffic
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:01 - TN:3) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:01 - TN:4) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:02 - TN:1) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:02 - TN:2) - Unallocated    *** This indicates that call is no longer here
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:02 - TN:3) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:02 - TN:4) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:03 - TN:1) - Unallocated
 13:34:31 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:03 - TN:2) - Unallocated   *** This should be either 'Assigned' or 'Traffic'
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:03 - TN:3) - Unallocated
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:03 - TN:4) - Unallocated
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:04 - TN:1) - Unallocated
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:04 - TN:2) - Unallocated   ***
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:04 - TN:3) - Unallocated
 13:34:32 PM   SYNCINFO + SCH/HD [SYSINFO]                               (FN:04 - TN:4) - Unallocated

No matter where I look, I don't see any indication in the preceding PDUs (last was D_TX_Granted) about carrier/timeslot or LA change.
Talking just stops mid sentence with no 'D_Release' PDU.
Waiting around on timeslot does not see call return. If anything a different call can take it's place. (This is what the call timeout is for).

I have no idea why this occurs and I don't think anything can be done about it other than end the call and return to MCCH.
On some occasions a call with the same GSSI will be re-started with either:

• Same Call ID, Mostly likely using late entry PDUs or
• New call with new Call ID.

This may occur so long as a different (GSSI) 'D-Setup' has not been seen first.

 

[Ubbe]

If the system recognise that there are no radios on a tower that are affiliated to a talk group that are currently being sent out, it will be switched off as no one are officially listening. It will happen when the last radio with that TG roams over to another site. If a radio later roams back, that TG suddenly springs to life again in mid sentence.

/Ubbe

 

[tsapers]

I now have constant crashes of SDR# with the following error:

Ran for +-2hours for the last 2 crashes. This is in SINGLE mode.

An item with the same key has already been added.
at mscorlib.dll.ThrowHelper.ThrowArgumentException (IL offset: 0x10)
at mscorlib.dll.Dictionary`2.Insert (IL offset: 0x81)
at SDRSharp.Tetra.dll.MM_protocol.ParseMMPDU (IL offset: 0x219)
at SDRSharp.Tetra.dll.SduParser.Parse (IL offset: 0x70)
at SDRSharp.Tetra.dll.PduParser.ResourcePDU (IL offset: 0x7c)
at SDRSharp.Tetra.dll.PduParser.ParsePDU (IL offset: 0x31)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x6cd)
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)

I did a clean install of SDR# 1700 and then ran TTT 1.0.8 and had the above, then moved to TTT 1.0.9 and still the same.
Any ideas?

 

[R3Natas]

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

This happens for MS to MS communication and goes through out the call, it's not critical, but in the previous release I haven't seen this problem, maybe something changed after TSSDR code adoption.

By "false ISSI" if you mean the pseudo_SSI as described a few post back (in the plug-in changelog). Nothing has changed here.

I'm not sure if it's pseudo_SSI or something else, because in the log it appears as "D_Setup Transmission Granted_to_another_user Party_SSI" and unfortunately in previous releases (1.0.5 - 1.0.7 if I'm not mistaken) everything was OK and now both your and TSSDR's releases have this issue.

Now about some other reports:
"ISSI is being displayed as GSSI", yes I've seen this problem too, but when you adopted TSSDR code, this problem appears only on private calls (before group calls were affected too), in the Group section it displays ISSI's, but should show 0, because it's a private call.

About MS Registrations tab, I don't if you know and made it that way, but MS Registrations provide information only when you sit on this tab, like if you watch Calls tab, MS Registrations tab won't update, so it would be great if MS Registrations could update itself without being opened.

This is information from my side, thanks for the updates!

 

[hamradionl]

Notice
DUAL mode SDR# 1700 + TTT 1.08 runs more stable whole day

DUAL mode SDR# 1700 + TTT-1.10 hotfix -5 After 2 - 3 hours
VC screen = crash
CC screen = alive

type System.OutOfMemoryException.
at SDRSharp.Tetra.dll.PduParser.GetDeFragmentedBuffer (IL offset: 0x9)
at SDRSharp.Tetra.dll.PduParser.MacEndPDU (IL offset: 0x64)
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: 0x0)
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)

 

[tsapers]

Notice the TTT 1.08 runs more stable whole day

DUAL mode SDR# 1700 + TTT-1.10 After 2 - 3 hours
VC screen = crash
CC screen = alive

This I have also seen before but on previous versions of SDR# and TTT as well. But not a physical crash. One of the SDR# instances just froze or stopped processing. No entry in logs. Just noted TTT no audo (if VC froze) or no processing (if CC froze). Only option was End Task via Task Manager.

 

[hamradionl]

Is this a typical problem using SDR#1700 anyone else?

The funny part, its happening after 5 minutes or just after 2 hours.
Wrait need some work to do

TSSDR have new version

 

[thewraith2008]

If the system recognise that there are no radios on a tower that are affiliated to a talk group that are currently being sent out, it will be switched off as no one are officially listening. It will happen when the last radio with that TG roams over to another site. If a radio later roams back, that TG suddenly springs to life again in mid sentence.

/Ubbe

Yes I would tend to agreed as that is what's occurring.
One would expect there are PDUs (which there are) that would be sent to indicate that a MS is seeking a new LA and a response (from BS ) to accept or reject request. We'll just have to live with it.

This happens for MS to MS communication and goes through out the call, it's not critical, but in the previous release I haven't seen this problem, maybe something changed after TSSDR code adoption.


I'm not sure if it's pseudo_SSI or something else, because in the log it appears as "D_Setup Transmission Granted_to_another_user Party_SSI" and unfortunately in previous releases (1.0.5 - 1.0.7 if I'm not mistaken) everything was OK and now both your and TSSDR's releases have this issue.

Now about some other reports:
"ISSI is being displayed as GSSI", yes I've seen this problem too, but when you adopted TSSDR code, this problem appears only on private calls (before group calls were affected too), in the Group section it displays ISSI's, but should show 0, because it's a private call.

DMO code was not adopted from TSSDR. I put that in myself. Any bugs are mine too.
I'm just not seeing that problem when I'm playing back the samples I have. Not to say there is not an issue, I just can't see it to fix it.

May bad about the psuedo_ssi. I though we where still talking DMO.
The fake ISSI issue I think is now fixed. So long as it's the ISSI in place of GSSI issue. I posted about it here. I should have a release for it soon.

About MS Registrations tab, I don't if you know and made it that way, but MS Registrations provide information only when you sit on this tab, like if you watch Calls tab, MS Registrations tab won't update, so it would be great if MS Registrations could update itself without being opened.

This is information from my side, thanks for the updates!

That is by design. These new tabs can eat CPU cycles. Especially 'Burst type' tab. I figure, don't update what's not used, save CPU cycles.

 

[hamradionl]

This morning again Second crash
DUAL mode SDR# 1700 + TTT-1.10 hotfix -5
SDR# VC = crash full screen Network Info
SDR# CC = alive full screen Network Info

type System.OutOfMemoryException.
at SDRSharp.Radio.dll.ComplexFifoStream.AllocBlock (IL offset: 0xe)
at SDRSharp.Radio.dll.ComplexFifoStream.GetWBlock (IL offset: 0x0)
at SDRSharp.Radio.dll.ComplexFifoStream.Write (IL offset: 0x44)
at SDRSharp.exe.MainForm.ProcessBuffer (IL offset: 0x4a)
at SDRSharp.Radio.dll.StreamControl.ProcessIQ (IL offset: 0x18)
at SDRSharp.Radio.dll.StreamControl.DSPProc (IL offset: 0x5b)
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)

1430 hours local GMT Europe
i do full restart SDR# + TTT i see how long version will run

 

[R3Natas]

DMO code was not adopted from TSSDR. I put that in myself. Any bugs are mine too.
I'm just not seeing that problem when I'm playing back the samples I have. Not to say there is not an issue, I just can't see it to fix it.

Oh ok, then it might be because talking too close to receiver or talking too loud, idk, but as mentioned TSSDR released an update where this issue is fixed and problems with DMO are resolved, so hope that yours will be OK as well. I will do some additional testings just to make sure..

May bad about the psuedo_ssi. I though we where still talking DMO.
The fake ISSI issue I think is now fixed. So long as it's the ISSI in place of GSSI issue. I posted about it here. I should have a release for it soon.

Perfect, hope next update fixes this issue

That is by design. These new tabs can eat CPU cycles. Especially 'Burst type' tab. I figure, don't update what's not used, save CPU cycles.

Alright, not a problem, I don't think this tab eats a lot, but if it does then just leave it as it is (will stick on it, to get the info I need)

 

[thewraith2008]

For the last 24+ hours I ran SDR# 1700 with TETRA Demodulator plug-in (with no TTT) and no crashes where seen.

I was testing TTT on another seesion so I couldn't use it to test. I'll try later with and see how it goes.

All these SDR# logs show "System.OutOfMemoryException" but the location of the exception is always in a different location in code.

Simple answer is stop using SDR# 1700 and go back to old known stable version.

I simply don't have the time at the moment to trouble shoot this out.

 

[hamradionl]

SDR# 1700 + TSSDR decoder seem work fine, no crash.

What SDR# version + TTT you are using so we use the same configuration ?

 

[thewraith2008]

I mentioned here

 

[hamradionl]

1430 hours local GMT Europe i did full restart SDR# 1700 + TTT 1.10-hotfix-5 i see how long version will run
1450 hours local GMT Europe
SDR# VC = crasht
SDR# CC = alive full screen Network Info

1500 hours local GMT Europe i do full restart SDR# 1671 + TTT 1.10-hotfix-5 i see how long version will run

 

[thewraith2008]

Hot-fix #6 for TTT v1.0.8 Public Release - Updates TETRA Trunk Tracker and TETRA Demodulator plug-in to v1.0.11.0



This hot-fix #6 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,5) must be installed first. Then copy the 2 new files to setup.


Only these files have been updated:

• SDRSharp.Tetra.dll
• tetra_trunk_tracker.exe

Copy them to the usual place.


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

v1.0.11.0

FIXED: Some (D-SETUP and maybe others) PDUs where losing a (G)SSI value.
       This was causing TETRA Trunk Tracker to incorrectly show ISSI as GSSI.

FIXED: Got the Unallocated timeslot detection working again

General code cleanup. Hopefully I didn't stuff something else up.

MD5 HASH: 9614cf9166e81a9957ab87a371483141 for "SDRSharp.Tetra.dll"

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

v1.0.11.0

FIXED: On TTT dual mode start, Both SDR# (CC and VC) 'Net Remote' plug-in may have same port# when
        enabled. This caused a pop-up warning from 'Net Remote' about port # clash.
       This fix tests if 'Net Remote' is enabled (then disables if is) and then sets port # as defined
        then enables 'Net Remote' again.

FIXED: ISSI displaying as GSSI. This was a plug-in issue and no code change in TTT was needed.
       NOTE: This bug will have resulted in bad GSSI entries in TETRA_SSI.txt and TETRA_GSSI.txt
              you should be able to manual remove them if your are careful.

MD5 HASH: f5d03db97bafc86e869fd0d6a88bb1e8 for "tetra_trunk_tracker.exe"

Download link

MD5 HASH b6dcb16c813b05192af6ae923c4e6b68

Lets see if this is better. Fingers crossed.

If all goes well with this version, I'll package up a full release.

 

[thewraith2008]

1430 hours local GMT Europe i do full restart SDR# + TTT i see how long version will run
1450 hours local GMT Europe
SDR# VC = crasht
SDR# CC = alive full screen Network Info

What does task manager say about SDR#'s Memory/CPU usage after crash.
What tabs did you have open in the TETRA Demodulator plug-in. For both CC and VC.

Knowing these things maybe help build a picture. Until it can be reproduced, I just can't do anything about it.

 

[thewraith2008]

Call dropout example (Continued)

To further what was said Here.

In this example you can see how a call was detected as unallocated and was immediately ended (returned to MCCH)
then immediately (in 3 seconds) started in new call (with new Call ID)

So it shows that while a call abrupt ends, in this case the conversation continues in a new call.

26/01/2019 10:06:51 PM - Call ID: 10007 - On carrier: 1041 TS:2 - Group: 500006
26/01/2019 10:06:51 PM - Call ID: 10007 - Calling SSI: 16002
26/01/2019 10:06:54 PM - Call ID: 10007 - VC D-TX-Ceased SSI: 16002
26/01/2019 10:06:55 PM - Call ID: 10007 - VC D-TX-Granted SSI: 16003
26/01/2019 10:06:57 PM - Call ID: 10007 - VC D-TX-Ceased SSI: 16003
26/01/2019 10:06:57 PM - Call ID: 10007 - Did not see D-Release but detected timeslot 2 been unallocated

26/01/2019 10:07:00 PM - Call ID: 10008 - On carrier: 2081 TS:2 - Group: 500006
26/01/2019 10:07:00 PM - Call ID: 10008 - Calling SSI: 16002
26/01/2019 10:07:01 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16002
26/01/2019 10:07:02 PM - Call ID: 10008 - VC D-TX-Granted SSI: 16003
26/01/2019 10:07:04 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16003
26/01/2019 10:07:04 PM - Call ID: 10008 - VC D-TX-Granted SSI: 16002
26/01/2019 10:07:06 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16002
26/01/2019 10:07:07 PM - Call ID: 10008 - VC D-TX-Granted SSI: 16003
26/01/2019 10:07:09 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16003
26/01/2019 10:07:11 PM - Call ID: 10008 - VC D-TX-Granted SSI: 16002
26/01/2019 10:07:13 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16002
26/01/2019 10:07:13 PM - Call ID: 10008 - VC D-TX-Granted SSI: 16003
26/01/2019 10:07:15 PM - Call ID: 10008 - VC D-TX-Ceased SSI: 16003
26/01/2019 10:07:17 PM - Call ID: 10008 - VC D-Released

I've been thinking of adding a GSSI hold delay after one of these unallocated events to try and stay with a conversation.

 

[hamradionl]

What does task manager say about SDR#'s Memory/CPU usage after crash.

When SDR# + TTT running
DUALMODE
CPU = InTel - i5 uses = 45%
Memory use SDR# 1 = 43 Mb
Memory use SDR# 2 = 35 Mb
Ttrunker = 3mb
Total memory uses = 47 % for running all the programs (browser etc etc)

What tabs did you have open in the TETRA Demodulator plug-in. For both CC and VC.

The standard startup tabs only
VC Network Info Call
CC Network Info Call


1530 hours local GMT Europe i do full restart SDR# 1671+TTT 1.08 + hotfix - 3 + 5 + 6 i see how long version will run

 

[thewraith2008]

When SDR# + TTT running
DUALMODE
CPU = InTel - i5 uses = 45%
Memory use SDR# 1 = 43 Mb
Memory use SDR# 2 = 35 Mb
Ttrunker = 3mb
Total memory uses = 47 % for running all the programs (browser etc etc)

Nothing unusual there. But what is the CPU usage for the SDR# that has crashed?

The standard startup tabs only
VC Network Info Call
CC Network Info Call


1530 hours local GMT Europe i do full restart SDR# 1671+TTT 1.08 + hotfix - 3 + 5 + 6 i see how long version will run

OK

I now have a set-up running with SDR# 1700(x2) + plug-in and TTT in dual mode. Been running for approx 50 minutes. All good so far.