SDR# TETRA Demodulator Trunk Tracking Demonstration

[lunakk]

@lunakk,
Is this SDS on open or encr network?

Its on open network. With Clear Voice

 

[lunakk]

123;4;User_Defined_195;e0,r0

I already did that, that's the output format from TTT
When i divided string to 8 bits and converted to decimal, it looks like some kind of counter? maybe...

 

[thewraith2008]

I already did that, that's the output format from TTT
When i divided string to 8 bits and converted to decimal, it looks like some kind of counter? maybe...

You should be seeing something like this:

9:28:57 PM - SSI:12345678 D_SDS_Data Party_SSI:543210 Type:UDT-4 Length:136 Protocol:User_Defined_195
9:28:57 PM -   DATA:'00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
9:28:57 PM -   Converted unknown protocol: This is whatever is converted

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

 

[lunakk]

Stupid me, i commented out with # settings in:

TETRA_sds_unknown_protocol

Now i get:

12:47:07 - SSI:1533285 D_SDS_Data Party_SSI:1533212 Type:UDT-4 Length:72 Protocol:User_Defined_195 DATA:'000000100111000100000001000100001010101010101010000001000000000000000000'
12:47:07 -   Converted unknown protocol: qªª
12:47:41 - SSI:1533258 D_SDS_Data Party_SSI:1533212 Type:UDT-4 Length:72 Protocol:User_Defined_195 DATA:'000000100111001100000001000100000111111111011001000011110000000000000000'
12:47:41 -   Converted unknown protocol: sÙ
12:47:52 - SSI:1533267 D_SDS_Data Party_SSI:1533212 Type:UDT-4 Length:72 Protocol:User_Defined_195 DATA:'000000100111010000000001000100000010101111000111000101000000000000000000'
12:47:52 -   Converted unknown protocol: t+Ç

Is it worth to investigate further in your opinion?

 

[thewraith2008]

Most important are TX user and group and more. By statistics method is possible to analyze that data to see something valuable. The same like MS Registrations.

Darek

There is no group (GSSI) that can be determined with encrypted PDUs, only ISSI.



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

 

[thewraith2008]

Is it worth to investigate further in your opinion?

Probably not.
Your not going to get text messages there most likely.
It's probably some bit of hardware sending status back to whoever.
Structure is unknown so you really don't known how to interpret what the data is.



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

 

[hamradionl]

@thewraith2008,
Do you know if tetra able to compress data before transmit a SDS
Is SDS handle some limited line of characters txt ?
So the actual message is longer and long message first be compresses before transmitted as short SDS?

 

[thewraith2008]

@thewraith2008,
Do you know if tetra able to compress data before transmit a SDS
Is SDS handle some limited line of characters txt ?
So the actual message is longer and long message first be compresses before transmitted as short SDS?

No compression available from TETRA for D_SDS_Data PDU.
But when a 'User Defined' protocol ID is used, then I guess the user can prepare the data how ever they like and provide custom structure and or compressed/encrypted data for the UDT-4 element of a D_SDS_Data PDU.

This is why there is no standard way of understanding/reading/decoding this data.



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

 

[hamradionl]

This is why there is no standard way of understanding/reading/decoding this data.

One way to investigate, when there be knowledge what is transmitted end go test to get that particular txt is shown in TTT

 

[wkrgr]

Yep, same PC and the old version still works. The output device is the same as well, both using DirectSound and switching to MME makes no difference.
Thanks for confirming there are no changes to the recording functions. I'll try a clean "install" to another folder and will report back if that changes anything.

I did a clean install with v1700 and 1.7.0.0 and it didn't record either. Also getting error "#5:The specified parameter is out of range for the specified command. - Error (samples/sec).

Then downgraded to 1.6.3.4 and the corresponding plugin, same SDR#. Still no recording.

Tweaked all possible audio settings, no effect.

Did you find any way to mitigate this?

 

[wkrgr]

I did a clean install with v1700 and 1.7.0.0 and it didn't record either. Also getting error "#5:The specified parameter is out of range for the specified command. - Error (samples/sec).

Then downgraded to 1.6.3.4 and the corresponding plugin, same SDR#. Still no recording.

Tweaked all possible audio settings, no effect.

Did you find any way to mitigate this?

Nevermind, switched to vitual cable setup, working fine now.

 

[LA6FRA]

Link to MEGA does not work today

 

[thewraith2008]

Link to MEGA does not work today

Just tried, works fine for me.



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

 

[morfis]

Link to MEGA does not work today

Checked using UK, German and US proxies and no problem from any

 

[ET-NL]

Yesterday tested the latest version of TTT on SDR#1700 no crashes.
So it looks like I have a problem with the combination SDR#1732 / TTT1.7 / Win10 NL 1909 x64

 

[thewraith2008]

Yesterday tested the latest version of TTT on SDR#1700 no crashes.
So it looks like I have a problem with the combination SDR#1732 / TTT1.7 / Win10 NL 1909 x64

Do you see any entries in Event viewer in windows when crash occurs?
Does crash seem to occur during a call or only while idle?
Are you using RTL dongle?

If TTT or plug-in was at fault, you would expect the crash to occur across different SDR# versions.
If TTT or plug-in is at fault, not sure if crash is triggered by some PDUs only you are seeing every so often. As you said, it can crash in minutes or hours randomly.

Only way to test this would be to setup:
- Normal TTT+plug-in setup on PC where crash occurs (SDR#1732 / TTT1.7 / Win10 NL 1909 x64)
- Other PC setup with SDR# 1700 and a IF Recorder plug-in (NOTE: WAV has 2GB limit, not sure record time for that size, couple hours?)

Record until crash occurs.
Note crash time
Playback IQ sample (from a time just before crash time) on SDR#1732 / TTT1.7 / Win10 NL 1909 x64 setup.
Does crash re-occur?
If yes, you will need to send IQ sample (I can provide a way to trim file to a small size)
If no, then error could somewhere else, Windows, SDR#, RTL driver etc...

I have setup a SDR#1732 + TTT+plug-in v1.7.0.0 on a Windows 10 64 bit to see if anything happens.
I use a custom RTL frontend for SDR# so I don't know if test will be any good.



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

 

[ET-NL]

I will try to help to debug this problem.
The Windows logfiles doesn't show any problems but maybe Windows is not able to write the log anymore. Recording and playing back looks like a good way to troubleshoot. I will start doing some tests.

 

[tsapers]

As always thanks for your efforts @thewraith2008!
Just a RFE for when\if you do another update.
Would it be possible to please add a Temp Lockout option? Like with the Uniden's.
Basically temp lock out the specific GSSI/s for that session only. So in this case temp lock out for this listening session via a shortcut or button, but it will be back to normal and enabled for listening again once TTT is closed and re-opened.
The lockout isn't permanent like when you go into the GSSI editor and uncheck it.
Basically looking for something between clicking on the CALL button (end call for 15s) and the perm lockout.

 

[hamradionl]

@thewraith2008,
last 4 days and 24/7 very intensive testing the new MS registration on Class 3 only
When users in Europe will understand how the network and this MS reg is working, carry very interesting functions to fallow what going on in your area.
I shared some ideas to use the MSreg information for use extra logging.
Thank you for this !

Any other users in EU use the MSreg function for there own region?
You have ideas to share for extend this function?

LOGGING requesting
MS reg log go to c:\SDR\TETRA_MM-Registrations_2020-03-16.txt
Possible to change root to save in a other map/dir ?
Please,
Possible a extra setup menu what lines/info be saved to file TETRA_MM-Registrations_2020-03-16.txt

 

[thewraith2008]

I found the follow quote in the standards in relation to the encryption of the SSI (element of the Layer 2 MAC) for encrypted PDUs.
The following would seem to indicate that the SSI is always encrypted for encrypted PDUs.

4.2.6 Encrypted Short Identity (ESI) mechanism

The ESI mechanism shall provide a means of protection of identities transmitted over the air interface. It operates in
addition to, or as a replacement for, the Alias Short Subscriber Identity (ASSI) mechanism described in ETSI
EN 300 392-1 [1], clause 7.

NOTE 1: In standard TETRA addressing no alias addresses are associated with a group address in the home system.
The ESI mechanism provides such an alias within a location area for all address types.

NOTE 2: The broadcast address as defined in ETSI EN 300 392-1 [1] is a reserved value of the group address so
ESI applies to it.

This clause describes a mechanism that allows the encryption of the SSI segment of addresses used by layer 2. The
event label and usage marker shall not be encrypted by this mechanism. USSI and SMI shall not be encrypted by this
mechanism. The mechanism is valid only for networks with air interface encryption applied. The mechanism shall be
integrated with the use of CCK within a location area in cells of security class 3, or with SCK for cells of security
class 2. Whenever encrypted signalling is used, the ESI shall be sent instead of the true identity. The mechanism uses
algorithm TA61 as shown in Figure 4.15.

xSSI are all short addresses valid for the MS (ISSI, GSSI, ASSI, V-ASSI, V-GSSI). The output xESI (IESI, GESI,
AESI, V-AESI, V-GESI) shall be a cryptographic address. Only MSs in a location area with the correct values of CCK
or SCK shall be able to identify messages addressed for their attention.
If the PDU is encrypted ESI shall be used in that PDU The use of signalling for AI encryption management is more
fully described in clause 6.5

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