SDR# TETRA Demodulator Trunk Tracking Demonstration

[ayuhsu84727]

@thewraith2008
After running tetra demodulator about 3-5 minutes, the plug-in crash with the following mssage.

CurrTimeSlot, 1
MAC_PDU_Type, 0
Fill_bit, 0
Position_of_grant, 0
Encryption_mode, 0
Random_access_flag, 0
Length_indication, 29
Address_type, 1
SSI, 51141
Capacity_Allocation, 0
Granting_delay, 0
MacPduRealSize, 232
PduStartOffset, 0
LLC_Pdu_Type, 1
MLE_Protocol_Discriminator, 2
CMCE_PDU_Type, 15
Calling_party_type_identifier, 1
Calling_party_address_SSI, 10001
Short_data_type_identifier, 3
User_Defined_Data4_Length_Indicator, 128
User_Defined_Data4, 0
Protocol_identifier, 130
Message_type, 0
Delivery_report_request, 0
Service_selection, 0
Storage_forward_control, 0
Message_reference, 1
Time_stamp_used, 1
Text_coding_scheme, 26
Timeframe_type, 0
Month, 2
Day, 7
Hour, 13
Minute, 1
CRC_check: 0

BURST[128]: 10000010000000000000000110011010000000100011101101000001000001110101000101110101000001000000100100001010000000001110011111000101

This crash only occur when i was tune to specific tetra system with MNC 10.
if I tune the frequency to another tetra system, the tetra demodulator work without any problem.

 

[thewraith2008]

Ok thanks, like I said above I only find activity on 3 of the frequencies and they are 3 LA which I can switch back and forth to so I expect it is a single carrier system with just timeslot activity and I am probably doing it right. I will use TTT in single mode I love the extra features.

If your 3x LAs are close together, you could use TNM to monitor to all 3 at same time with one dongle.
If not close together you can still use with multiple dongles.
Development has stalled on it, but it still should work OK.
Just an alternative to try if you like.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[DRL-XM43]

If your 3x LAs are close together, you could use TNM to monitor to all 3 at same time with one dongle.
If not close together you can still use with multiple dongles.
Development has stalled on it, but it still should work OK.
Just an alternative to try if you like.

Since I receive 2 LA on 2 Frequencies I monitored them side by each last night as a test. It appears the LA are identical to each other for transmissions so I am guessing each active LA is a locational coverage strategy and I only need monitor one of them. One of them is a tad stroger signal for me but I am still 60 km away so conditions need to be right - it is a bit of a stretch

Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[thewraith2008]

@thewraith2008
After running tetra demodulator about 3-5 minutes, the plug-in crash with the following mssage.

This crash only occur when i was tune to specific tetra system with MNC 10.
if I tune the frequency to another tetra system, the tetra demodulator work without any problem.

This crash is caused by the text coding scheme: "UCS-2 with the UTF-16BE extension" used in a SDS message.
The code to handle this was never properly implemented and should have been removed.

Another problem I'm seeing with that error is there is not enough bits available in message to accommodate the encoding (16 bits)
The SDS UDT-4 length is given as 128 bits with a PDU overhead of 56 bits, this leaves 72 bits for the actual message.
(72 / 16) = 4.5 characters. There is either 8 bits too many or 8 bits not enough.
I cannot see any obvious reason why this bit count is not multiples of 16 bits.

This is what I see when converted: (sorry for small image)

Does this mean anything?

I may need an IQ sample of these types of messages so I can test it better.
The error report has only returned the UDT-4 part of the total burst and it is making it difficult to test with.
Instructions to create IQ sample are given in this post. NOTE: You will need to get your post count above 5 before you can PM with link.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[ayuhsu84727]

This is what I see when converted: (sorry for small image)

Does this mean anything?

The character in the image is like garbled text, maybe the error cause by the language package in the windows.

May i have the method to convert the character from the burst data by myself ?

The IF file will sent via PM after my post count is more then 5.
Thank you for returning my problem.

 

[thewraith2008]

The character in the image is like garbled text, maybe the error cause by the language package in the windows.

May i have the method to convert the character from the burst data by myself ?

The IF file will sent via PM after my post count is more then 5.
Thank you for returning my problem.

Text coding scheme used is "UCS-2 with the UTF-16BE extension" so should be read as 16 bits per character.

Here is the message in binary:

000001110101000101110101000001000000100100001010000000001110011111000101

Here are the 72 bits seen in that message arranged as 16 bits:

0000011101010001 = 0x0751
0111010100000100 = 0x7504
0000100100001010 = 0x090A
0000000011100111 = 0x00E7
11000101         = 0xC7

or last 2 lines could be:

00000000         = 0x00 (is this supposed to be a NULL? It should still be 16 bits if is.)
1110011111000101 = 0xE7C7

If the suspected (8 bit) NULL character is true, that would explain the 8 extra bits, but then does not explain why 8 bits used in the middle of an expected 16 bit encoding.

EDIT: Another thing to remember is that SDS messages don't have to be human readable.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[hamradionl]

No longer use SDR#, idea for new standalone TetraUi full control TTT - 2.0?

 

[thewraith2008]

No longer use SDR#, idea for new standalone TetraUi full control TTT - 2.0?

Why, whats wrong with using SDR#?

It provides interface to hardware and good visual display of the spectrum. This is far better than I could ever do.
Doesn't use much CPU to do what it does. (3-4% excluding plug-in load for me).
OK the new SDR# UI is a bit of a memory eater. I Just stick to v1716 and lower.
The API is pretty full featured and saves time figuring out how to do the hard things myself.

It's not the SDR way to have just one program that does it all.
And none exist the do.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[hamradionl]

@thewraith2008,
Sorry, think mix up TSSDR and / or you both?
Some 8 - 10 month ago, one of you both mention, in SDR# need to do tricks to get it running and when author SDR# change his software, the tricks no longer work. One of you both had the idea make TT or TTT as standalone frontend but not want to develop your own receiver frontend from scratch . So one of you mention use SDRangel and SDRuno. Both SDRangel + SDRuno written in diff programm language, and one of you not have intention to learn a new program language, to start al over.
Was this talk with TSSDR or do you remember this conversation?

 

[thewraith2008]

@thewraith2008,
Sorry, think mix up TSSDR and / or you both?
Some 8 - 10 month ago, one of you both mention, in SDR# need to do tricks to get it running and when author SDR# change his software, the tricks no longer work. One of you both had the idea make TT or TTT as standalone frontend but not want to develop your own receiver frontend from scratch . So one of you mention use SDRangel and SDRuno. Both SDRangel + SDRuno written in diff programm language, and one of you not have intention to learn a new program language, to start al over.
Was this talk with TSSDR or do you remember this conversation?

We both spoke about it. We both have no time to invest in it.
For TSSDR he has no local TETRA, so no motivation. For me, TETRA dead soon so no motivation.

While SDR# has changed, the changes have not broken to much (of the plug-in). The biggest change was when it changed from 3.5 to 4.5 .NET and that didn't affect this plug-in because it came after change. Not sure what 'tricks' are involved you mention all code is pretty standard.

SDRangel needs a super computer to run and SDRuno only works with one SDR hardware and I'm not sure if either have a plug-in interface as advanced as SDR#. It would only be replacing one 3rd party program with another anyway.



Latest version (v1.6.3.4) can be found here: Release post
- Please download 'TTT_1.6.3.4_release.7z' and install.
- Also download 'TTT_hotfix_v1.6.3.8.7z' and copy and replace the two files into the above install.

 

[DRL-XM43]

However - the thought did cross my mind, but it would need you to be real bored LOL

I was impressed how your TETRA plug could manage a CC and VC control of SDR#, this reminded me of how SDRConsole V3 has a built in feature that allows launching DSD+ and then assigns 1 dongle to sit on control while it utilizes 1 to several dongles to trunk follow, you see where I am going LOL.

So if chronic boredom sets in...... LOL

 

[hamradionl]

@DRL-XM43
Good, lots ideas when bored (humor)
I started use SDRconsole it seem better handling low level signal (inmarsat) and the author is open for feetback, support all the Hardware goodies perfectly without any "work around" or permission for "white listed drivers".

 

[thewraith2008]

However - the thought did cross my mind, but it would need you to be real bored LOL

I was impressed how your TETRA plug could manage a CC and VC control of SDR#, this reminded me of how SDRConsole V3 has a built in feature that allows launching DSD+ and then assigns 1 dongle to sit on control while it utilizes 1 to several dongles to trunk follow, you see where I am going LOL.

So if chronic boredom sets in...... LOL

TNM already works with multiple dongles to monitor different LAs and to follow calls.

 

[DRL-XM43]

TNM already works with multiple dongles to monitor different LAs and to follow calls.

That is what I was talking about and how great it was it managed CC and VC with multiple dongles.

 

[DarkAngelT]

TNM already works with multiple dongles to monitor different LAs and to follow calls.

Looking forward to the merger of TNM and TTT.

 

[hamradionl]

TNM already works with multiple dongles to monitor different LAs and to follow calls.

those nice labels to fallow traffic

 

[Erik40]

@thewraith2008.

When is the new update off TTT

 

[AOD999]

@thewraith2008.

When is the new update off TTT

When it is ready.

 

[thewraith2008]

24th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.7.0.0

Please note that TTT and TETRA Demodulator plug-in has some new experimental changes and requires all components to be updated.
I suggest creating a new SDR# and TTT folder for this version.
Please read the changelog for usage procedures for any new and experimental stuff.


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 cause issues.

TETRA Demodulator plug-in has been updated by me. "Tweaked Edition (Unofficial) v1.7.0.0"
This is required to be used with TETRA Trunk Tracker v1.7.0.0. Please read the documentation files in zip for plug-in.

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

Summary of changes:

v1.7.0.0

 Rolled up all hot-fixes and updates (from v1.6.3.4 up) for release


Various fixes

ADDED: When plug-in is used in stand alone mode (TTT mode not enabled), the active call will highlight in the calls list

Updated libtetradec.dll

=====================================================================================================
v1.6.3.10 - Hotfix - Experimental version, not released

Various fixes and changes

FIXED(part): CMCE - SDS when text coding scheme was 'UCS-2 with the UTF-16BE extension' error seen

FIXED: Bad crash of SDR# (no crash reports)
- This was caused by incorrect offset calculation that resulted in a negative value.

FIXED: SNDCP - IPv4 TCP

CHANGED: SNDCP UI
- IP/Port fields removed
  When a transfer occurred, I noticed that IP/Ports change between some SDUs.
- SDU panel larger and now each entry contains IP/Port

CHANGED: SYNCINFO element renamed from 'Security_Class_3_supported_on_cell' to Security_Class_2_or_3_supported_on_cell
- This better indicates the dual nature of element.

ADDED/CHANGED: Very experimental show encrypted "call" details
- This may NOT be 100%.
  If it does not work then disable it.
- The purpose of this is to try and show encrypted activity on the current carrier and other carriers (not possible to know which one).
  This does NOT decrypt anything, it just tries to associate voice activity with the encrypted PDU activity on assigned timeslots.
  Don't be that guy that asks for decrypting PDUs and audio to be added. It not going to happen.
  The encrypted PDUs can be more than just call control PDUs (CMCE) so seeing them does not indicated only D_TX_Grant, D_TX_Ceased.
  The call shown in 'Network Info' 'Calls' is only going to partly showing real information:
   - Call ID is NOT real. It's 20000 + usage marker value. (So any Call ID above 20000 is not real)
   - Group will be either 'Unknown' or 'Encrypted' (Will be determined on encrypted PDU activity)
   - TXer will be the SSI the encrypted PDU was targeted too. This could possibly show that the MS is in call but this does not mean the MS is actually talking.
   - Users same as TXer, will populate as encrypted PDUs are seen on assigned channel.
   - Carrier is real, except when '9999', this is a possible call on another carrier.
   - Timeslot is real, except when ' '. This is a possible call on another carrier.
   - Mode Op (Simplex/Duplex). There is no way to determine this so will always be simplex.
   - Encrypted/Unknown calls that are active on a timeslot of the current carrier will be highlighted light yellow.
  The SDR# side-panel will show 'Unknown' or 'Encrypted' for GSSI and ISSI will be the SSI the encrypted PDU was targeted too. This will show that the MS is in call but this does not mean the MS is actually talking.
   'X' will show when 'Unknown' or 'Encrypted'
   'Unknown' will most likely show when on a carrier that is not the main carrier and call is not encrypted.
   Encrypted "calls" will not be selected for listening if 'Listen only clear speech' enabled.

=====================================================================================================
v1.6.3.9 - Hotfix - Experimental version, not released

FIXED: Detection of an unassigned carrier for a call.
- On some occasions, a carrier is not assigned (by AACH) as 'assigned' or 'traffic' (by network) when
   a call is set-up. When this occurs, there is no call traffic and the call will wait until the 'Call timeout' triggers.
  This change should see the unallocated code detect this and exit call immediately.

CHANGED: When D_SDS text messages (of various known protocol IDs) are seen with unsupported 'TextCodingScheme',
 a binary string will also be output.
 This can be used with TTT 'TETRA_sds_unknown_protocol' processing feature.

CHANGED: D_SDS: Duplicate 'External subscriber number' would cause error.


see 'changelog.txt' for full list and details.

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:

Summary of changes:

v1.7.0.0 - Release

 Rolled up all hot-fixes and updates (from v1.6.3.4 up) for release


FIXED: D_Call_Restore PDU
- This PDU does not always have 'New call ID' element and was ignored when the PDU didn't have it.

CHANGED: Include processing of 'Usage' element
- This will help only playing of call related audio and filter out other audio or encrypted audio.

FIX: D_Setup PDU
- With the inclusion of 'Usage' element, it was noticed that occasionally some 'D_Setup' PDUs did not have the 'Usage' element
   present which would cause a no audio play condition in the plug-in.

=====================================================================================================
v1.6.3.9 - Hotfix - Debug version, not released

FIXED: On incomplete call set-ups (private only?), '-1' was incorrectly stored to G/ISSI records.

ADDED: Processing of known 'Protocal IDs' (text messages) but with unknown 'TextCodingScheme'.
- TTT will pass the binary string though the 'Unknown Protocol' section to process a binary string.

ADDED: Store Call ID + Party ISSI [Experimental]
- Used for calls where the Party ISSI is just missed because it is only sent once. see v1.6.3.1


see 'changelog.txt' for full list and details.

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
• TETRA_Demodulator.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 partly tested with no issues seen.
The TETRA plug-in with SDR# 1727+ on Windows 7-10 32/64 bit PCs is partly tested with no issues seen.

It only works with the provided TETRA plug-in supplied in zip. (2020-February-27).
This version no longer uses a custom compiled version of 'Net Remote'

It is only meant to be a temporary solution until something better comes along.


I'm sure all these changes are going to create addition bugs.
I have tested to the best of my ability.
Putting it in the wild should be a better test of things. Please report any issues.


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 b077a3e86827339f5e7d72fd1c0be0f7

 

[hamradionl]

Thank you !
Wishlist: labels ON / OFF like TNM to fallow traffic ?