SDR# TETRA Demodulator Trunk Tracking Demonstration

[RMW1010]

If you have "Turn off the display" turned on, try turning it off and see if that makes a difference.

Thanks for the suggestion, but that doesn't make a difference.
I also switched off the option in the device manager "Allow the computer to turn off this device to save power", but also no difference.

I didn't seem to have an issue in one of the previous versions IRC.

I will try with a second laptop to see if I also have the issue there.

Thanks!

 

[iw2dtt]

Hello
after the last version no more messages of this type appear, you can help me thanks?


SYSINFO - Main_carrier: 2518 Offset: 0 Frequency_Band: 4
SSI: 11******7 D_SDS_Data Party_SSI: 1 ---------- Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0
SYSINFO - Main_carrier: 2518 Offset: 0 Frequency_Band: 4
SSI: 11*******7 D_SDS_Data Party_SSI: 11 ------ Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0
SYSINFO - Main_carrier: 2518 Offset : 0 Frequency_Band: 4




SSI: 1*******5 D_SDS_Data Party_SSI: 1 ---------- Tipo: UDT-4 Lunghezza: 32 Protocollo: Text_Messaging MessageType: SDS-Report Delivery_status: SDS_receipt_acknowledged_by_destin ation_Destination_Success TextCodingScheme: _7_bit_alphabet TimeStampUsed: No
SSI: 1******7 D_SDS_Data Party_SSI: 11 -------- Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0

 

[thewraith2008]

Hello
after the last version no more messages of this type appear, you can help me thanks?


SYSINFO - Main_carrier: 2518 Offset: 0 Frequency_Band: 4
SSI: 11******7 D_SDS_Data Party_SSI: 1 ---------- Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0
SYSINFO - Main_carrier: 2518 Offset: 0 Frequency_Band: 4
SSI: 11*******7 D_SDS_Data Party_SSI: 11 ------ Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0
SYSINFO - Main_carrier: 2518 Offset : 0 Frequency_Band: 4




SSI: 1*******5 D_SDS_Data Party_SSI: 1 ---------- Tipo: UDT-4 Lunghezza: 32 Protocollo: Text_Messaging MessageType: SDS-Report Delivery_status: SDS_receipt_acknowledged_by_destin ation_Destination_Success TextCodingScheme: _7_bit_alphabet TimeStampUsed: No
SSI: 1******7 D_SDS_Data Party_SSI: 11 -------- Tipo: UDT-4 Lunghezza: 96 Protocollo: Simple_location_system DATI: '00000011000000000010010001010000010100110100 00110100111101000011010011010010110000110010001100 00' LocationSystemCodingScheme: 0

The "Simple_location_system" has never been fully decoded by the plug-in, and not at all by TTT.

As I posted and here. "The "$P" indicates Extended messages/Proprietary Sentences. These extended messages are not standardized." There for it's unknown how to interpret them.

 

[hamradionl]

Just curious, notice some questions about this particular subject
Did anyone see "real messages" in early versions of Telive or the early Tetra Plugin?
Last time so see "real message" what version Plugin you using?
What messages are shown in your area or country?

 

[iw2dtt]

first I saw those messages now no - I'm using last version thanks

 

[thewraith2008]

first I saw those messages now no - I'm using last version thanks

Most likely they are not currently been sent on you network.

I just looked in my "TETRA_sds_data_xxxx.log" file and I saw a "Simple_location_system" PDU listed in it. So it still must be working.

You can test with an old version to verify. If it works on old version again then I would need an IQ sample so I can see what the issue could be with the new version.

 

[tsapers]

Has anyone looked at utilizing TTT and specifically the Remote window text with something like RadioFeed for private audio streaming across the internet and displaying the Groups and Users from the Remote Window. Maybe even running something similar on a Pi?

 

[iw2dtt]

Hello

this is the registration

 

[digiman1]

Minimise

If I minimize SDR#, will TTT continue to work as it should or does this need to be open for all to work normal?

 

[DarkAngelT]

I would like to leave a suggestion here. If it were possible, it would be nice if the program had a night mode. Where the main window and background were dark and the text of other colors.

 

[lemano]

messages... ?

Hello

Congratulation for the plus-in.

Voice dedoder is not perfect but it is ok, but all massages are bad.

Do you have an idea ?

 

[thewraith2008]

Hello

Congratulation for the plus-in.

Voice dedoder is not perfect but it is ok, but all massages are bad.

Do you have an idea ?

Can you elaborate on the Voice decoder issue?

The contents of the "Text Messaging" I don't think have to be readable (by human and in English/Other). They can user defined and translated by application on the radio.

Note about the audio:
I have found just recently that the plug-in (not TTT) is actually missing some of the voice frames (TCH) that are been sent in a (shared) normal burst (Training sequence 2). Each of these voice frames are only 30mS in duration but because these are been missed, the plug-in is muting SDR# when no voice frames are seen and results in a larger portion of the audio to be cut off. A lot larger than the missing audio duration.
This makes it sound like dropouts in the audio.
These mainly seem to occur near end of transmissions.
I have added code to the plug-in to fix this.

 

[DarkAngelT]

I'm really looking forward to the next release!

 

[thewraith2008]

I'm really looking forward to the next release!

I'm currently chasing a few rabbits down their holes with the plug-in at the moment, which is delaying further releases.

In addition to the missing audio frames there is also an issue with the way the plug-in extracts control data from the bursts (with the MAC protocol).

Most of the time this data is contained in one MAC-Resource PDU, but it can also span multiple PDUs (MAC-FRAG / MAC-END). I am only seeing the MAC-Resource and MAC-END PDUs over the air here at the moment.

The plug-in is not processing MAC-FRAG / MAC-END PDUs at all, which is resulting in missing Downlink PDUs (CMCE).
Most notably the "D_Release", which causes a call timeout and can result in a missed call if another call is set-up while still in the timeout period. Also if the same timeslot becomes active again, this will further delay the call timeout (Release).

I have made some changes to allow processing of part of these PDUs to retrieve more of the missing Downlink PDUs (CMCE). But more needs to be done.

I have also been playing with the (MM) protocol that deals with MS de/registrations to see if there is anything interesting there.

Anyway, that's where I'm at.

 

[DarkAngelT]

I'm currently chasing a few rabbits down their holes with the plug-in at the moment, which is delaying further releases.

In addition to the missing audio frames there is also an issue with the way the plug-in extracts control data from the bursts (with the MAC protocol).

Most of the time this data is contained in one MAC-Resource PDU, but it can also span multiple PDUs (MAC-FRAG / MAC-END). I am only seeing the MAC-Resource and MAC-END PDUs over the air here at the moment.

The plug-in is not processing MAC-FRAG / MAC-END PDUs at all, which is resulting in missing Downlink PDUs (CMCE).
Most notably the "D_Release", which causes a call timeout and can result in a missed call if another call is set-up while still in the timeout period. Also if the same timeslot becomes active again, this will further delay the call timeout (Release).

I have made some changes to allow processing of part of these PDUs to retrieve more of the missing Downlink PDUs (CMCE). But more needs to be done.

I have also been playing with the (MM) protocol that deals with MS de/registrations to see if there is anything interesting there.

Anyway, that's where I'm at.

The issue of timeout I solved by changing from 5 to 6 seconds.
One bug that bothers me a bit is the demodulator plugin information being slower than it was.

I hope we have a new update soon! Good luck buddy!

 

[thewraith2008]

The issue of timeout I solved by changing from 5 to 6 seconds.

The IQ sample you provided a week or so ago where a following call was missed because of the missing D_Release PDU. This PDU does exist in the IQ sample and now shows up with the change I made. Still not 100% but it's a step closer.

One bug that bothers me a bit is the demodulator plugin information being slower than it was.
I hope we have a new update soon! Good luck buddy!

Not sure why it would be any different. It should show them as it sees them.
I reduced the update interval awhile back. I think it was 500mS and I change it to 50mS. So it would be faster than what it original was.

 

[DarkAngelT]

The IQ sample you provided a week or so ago where a following call was missed because of the missing D_Release PDU. This PDU does exist in the IQ sample and now shows up with the change I made. Still not 100% but it's a step closer.



Not sure why it would be any different. It should show them as it sees them.
I reduced the update interval awhile back. I think it was 500mS and I change it to 50mS. So it would be faster than what it original was.

In the TTT_1.05.0_release version the tetra demodulator displays the information exactly at the time it occurs

 

[DarkAngelT]

thewraith2008 A Some days I discovered a bug. I use a link from SDR SHARP with the Zello program, so I can listen when I'm in other places outside the home. However, when the program runs for more than 2 hours on the computer, the Sharp SDR hangs. The VC SDR or the SDR VD. Always one of them stops working. In the previous version this bug did not happen. It was possible for the program to stay connected and running perfectly on the computer for several days.

 

[digiman1]

thewraith2008 A Some days I discovered a bug. I use a link from SDR SHARP with the Zello program, so I can listen when I'm in other places outside the home. However, when the program runs for more than 2 hours on the computer, the Sharp SDR hangs. The VC SDR or the SDR VD. Always one of them stops working. In the previous version this bug did not happen. It was possible for the program to stay connected and running perfectly on the computer for several days.

Hey, I have been running TTT over Zello for around 2 weeks constant without any issues. Could be an issue with VB Cable crashing maybe?

 

[thewraith2008]

Does SDR# + TTT crash after same time with out using Zello?
If no crash, I can't really help with the Zello program as I don't know what it is or what does and how it's setup.

When SDR# crashes it writes to a file in the folder called "crash.txt" this may point to where the problem is occurring in SDR#
Crash reports can also be found in the Windows "Event viewer" > "Windows Logs" > "Application" with similar information.