SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

Both of what? Both encrypted and unencrypted PDUs can exist in network and that is what I am seeing when using old version (hotfix 6) of the plug-in. The latest plug-in (when monitoring same network and same frequency) shows nothing but PDU encrypted: MAC_resource (CCK-id is even) on timeslot .....

I think Ubbe point the thing:
"None of the ISSI or talk groups diaplayed in SDR# are actually used in the system and there's a ton of strange control data being displayed due to the encryption not giving you any real data. "

When I test with IQ samples that have been supplied, which has both clear and encrypted PDUs/speech. I see it working as expected.
Hybrid calls (which have clear and encrypted speech) is not that good when "Listen only clear speech" is used. (see previous post)

 

[hamradionl]

TSSDR have many i/Q files with SDS or other network.
Wish list next release:
Tetra decoder in Network Info window
Extra TAB for open a window to view received SDS Messages or logging in to file TETRA_SDS.txt

 

[thewraith2008]

TSSDR have many i/Q files with SDS or other network.

This only helps him.

Wish list next release:
Tetra decoder in Network Info window
Extra TAB for open a window to view received SDS Messages or logging in to file TETRA_SDS.txt

This logging already occurs in "TETRA_sds_data_xxxx.log". This is mentioned in "TTT_Features_and_Usage.pdf"



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

 

[hamradionl]

When open TETRA_sds_data_xxxx.log" wil this file be live updated using monitoring?
Or only update after closing SDR# - TTT ?

 

[thewraith2008]

When open TETRA_sds_data_xxxx.log" wil this file be live updated using monitoring?
Or only update after closing SDR# - TTT ?

As SDS messages are seen they will be added to "TETRA_sds_data_xxxx.log"
Obviously if you have the file open in notepad you will not see it updating (adding new lines). You will need to re-open "TETRA_sds_data_xxxx.log" to see new lines.



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

 

[hamradionl]

As SDS messages are seen they will be added to "TETRA_sds_data_xxxx.log"
Obviously if you have the file open in notepad you will not see it updating (adding new lines). You will need to re-open "TETRA_sds_data_xxxx.log" to see new lines.

Understand its not realtime Due Network Info screen go to fast, never able to read the SDS messages (cant scroll back when busy)
Therefore wish for realtime live Extra TAB window/screen to view and Scroll Back all the received SDS Messages.
Thank you

 

[polar1]

I don't think this should really be prioritized, You can always use some log software such as CMTrace (part of MS config manager toolkit) to open logs and the software will refresh it realtime. You can even filter relevant lines.

 

[phats]

Hi thewraith2008,

Awesome work on TTT, I recently upgraded to v1.0.14 and it’s awesome, however since doing so I have been experiencing a higher number of encrypted calls bleeding through.

The calls do not come through on the device speakers but activates the “Audio Recorder*” add on I have installed.

The bleeding encrypted audio unmutes the volume on SDR# but the volume slider does not increase. When I am monitoring SDR# through teamviewer on my tablet the bleeding audio can be heard.

I did see this problem mentioned in previous posts but did not see a fix for it.

Hope you can help or guide me on how to rectify my problem.

Thanks and again awesome work.

 

[polar1]

Hi,

I downloaded the new version today, been playing with it a bit.
I'm receiving some SDS text messages on main CC about every minute. This is what each line in log file looks like:

11:04:17 PM -  SSI:20151 D_SDS_Data Party_SSI:1008 Type:UDT-4 Length:72 Protocol:Text_Messaging_TL MessageType:SDS-Transfer TEXT:'.  ? '

What confuses me a bit here is the conflict between length and text output. Length always comes up as 72 (bits or bytes?) and text message always looks the same and has 5 chars. Even if 72 is length in bits, although i doubt it, it would still be 40. Does this mean that length shows not only content length but entire frame length or there is a part of message that's not being shown?

If needed, I can record some IQ data of this network with SDR console v3.

 

[polar1]

Just some more info on the network and intent:

This is a public transportation network without encryption used for various purposes (tram and bus AVL/DPI systems, voice...). I know for the fact that it is used to deliver real time vehicle data to public dynamic passenger info displays (found some publicly available presentations about the system itself). Each display in the city has a tetra receiver, probably some microprocessor and dot matrix panels. I'm trying to reach and interpret these messages to see if I can get decoded real time tram information. Display info is refreshed at least once per minute so these SDS data frames could have something to do with it based on frequency of broadcast.

 

[thewraith2008]

Hi,

I downloaded the new version today, been playing with it a bit.
I'm receiving some SDS text messages on main CC about every minute. This is what each line in log file looks like:

11:04:17 PM -  SSI:20151 D_SDS_Data Party_SSI:1008 Type:UDT-4 Length:72 Protocol:Text_Messaging_TL MessageType:SDS-Transfer TEXT:'.  ? '

What confuses me a bit here is the conflict between length and text output. Length always comes up as 72 (bits or bytes?) and text message always looks the same and has 5 chars. Even if 72 is length in bits, although i doubt it, it would still be 40. Does this mean that length shows not only content length but entire frame length or there is a part of message that's not being shown?

If needed, I can record some IQ data of this network with SDR console v3.

Length is bits.
The data for "Protocol:Text_Messaging_TL" is contained with UDT-4 (User Defined Type 4)
"Protocol:Text_Messaging_TL" has overheads (other elements) that further defines how the data is interpreted. In this case 32 bits.



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

 

[polar1]

Length is bits.
The data for "Protocol:Text_Messaging_TL" is contained with UDT-4 (User Defined Type 4)
"Protocol:Text_Messaging_TL" has overheads (other elements) that further defines how the data is interpreted. In this case 32 bits.



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

Yes, I found this later. I hope You don't mind me picking the assemblies a bit. I modified the plugin a bit to show raw globalname data for frames containing "unknowData" key. There is plenty of these frames. I'm digging around ETSI trying to find specifications for PDU types but it's all over the place...
Here's two of the frames (just the dictionary contents):

2:52:26 AM -RAW DATA:
CurrTimeSlot: 4
MAC_PDU_Type: 0
Fill_bit: 1
Position_of_grant: 0
Encryption_mode: 0
Random_access_flag: 0
Length_indication: 11
Address_type: 1
SSI: 300103
Allocation_type: 0
Timeslot_assigned: 0
Uplink_downlink_assigned: 3
CLCH_permission: 0
Cell_change_flag: 0
Carrier_number: 3880
Monitoring_pattern: 3
LLC_Pdu_Type: 2
MLE_PDU_Type: 4
UnknowData: 1

2:52:26 AM -RAW DATA:
CurrTimeSlot: 1
MAC_PDU_Type: 0
Fill_bit: 0
Position_of_grant: 0
Encryption_mode: 0
Random_access_flag: 1
Length_indication: 6
Address_type: 1
SSI: 20089
LLC_Pdu_Type: 3
MLE_PDU_Type: 0
UnknowData: 1

 

[thewraith2008]

Hi thewraith2008,

Awesome work on TTT, I recently upgraded to v1.0.14 and it’s awesome, however since doing so I have been experiencing a higher number of encrypted calls bleeding through.

What options do you use in the plug-in?
Does the call with this issue have clear and encrypted speech.
Does the call also use encrypted PDUs or is it only the speech encrypted.

See this post for snippet from changelog about encrypted speech scenarios



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

 

[hamradionl]

Just some more info on the network and intent:.

Thanks, for info

 

[phats]

What options do you use in the plug-in?
Does the call with this issue have clear and encrypted speech.
Does the call also use encrypted PDUs or is it only the speech encrypted.


See this post for snippet from changelog about encrypted speech scenarios



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

Thanks for getting back to me, I have checked the boxes “Ignore encrypted data” and “Listen only clear speech”. The network that I am listening to is used my 4 users from various services. One service has all there transmissions encrypted. I can only assume it is this services transmissions bleeding through.

 

[polar1]

@thewraith2008 Hi,

would You share Your source code of the Tetra SDR# plugin with me for further development? I'd like to start implementing AL_DATA LLC PDUs and SNDCP packet network support. I have a lot of SNDCP traffic on the network I'm currently listening to. I started implementing but working with decompiled DLL is not the most optimal solution for me... I'd be grateful if You'd like to cooperate on development. This is all of course if You think it is viable.

 

[digiman1]

@thewraith2008 Hi,

would You share Your source code of the Tetra SDR# plugin with me for further development? I'd like to start implementing AL_DATA LLC PDUs and SNDCP packet network support. I have a lot of SNDCP traffic on the network I'm currently listening to. I started implementing but working with decompiled DLL is not the most optimal solution for me... I'd be grateful if You'd like to cooperate on development. This is all of course if You think it is viable.

o0o, I like the sound of this!

 

[R3Natas]

Maybe it's a good idea to move this project to Github?

 

[polar1]

Maybe it's a good idea to move this project to Github?

Well, I don't know if TSSDR wants to make his code completely public and opensource, that is completely up to him and his plans further down the road. I'm just offering some help because I like this TETRA network concept, have some enthusiasm about it and have already invested too much time in studying air interface documentation

 

[polar1]

Perhaps it is a better idea to keep it at least semi-closed for some more time until TETRA as a standard is more completely implemented into source and then release it for others to fork it as much as they want and improve it. If it would be released in current state, there might be dozens of forks implementing some parts of standard, each in its own way and then it will become a chaos for pull requests and merge conflicts later.