SDR# TETRA Demodulator Trunk Tracking Demonstration

[RicardoRJ]

What setup you using, Dual/Single?
What options do you use?

Is this happening after a call has been recorded? The option in 'R' > 'Hold Delay' can cause this missing other calls, as it waits to see if current GSSI resumes talking.


Is this for same GSSI or 2 different GSSIs? Do you have any lockouts set?
See G/SSI editor for GSSI that are unchecked.

Does your network use more than 1 frequency?

If none of the above helps you may need to send me a IQ sample of this occurring.

This happens in both dual mode and simple mode.
I do not use the recording option!
Let me give you a clear example:
I leave marked in the GSSI editor only the GSSI 111012 the rest left unchecked. When listening begins normal, sometimes this fault occurs between one change and another. In exchange exchange TTT simply does nothing, it's as if there was no one talking at that moment. Only on the radio, I can see there's a conversation!
With regard to frequencies 8 are the frequencies with higher intensity. I always use the one that comes with more clarity, usually the one indicated on the radio!
I noticed that in Telive this "empty interval" also occurs.
I hope I have clarified, otherwise I will be able to record a video or something!

Thank you

 

[RicardoRJ]

Complementing, I noticed that when this happens, in SDR # appears in Timeslot the GSSI and ISSI normally but in the remote panel of the TTT it is as if it was not having transmission at that moment, however in the radio the audio is coming out, and precisely the same GSSI and ISSI that appear in Timeslot.
I think now you can understand!

 

[thewraith2008]

This happens in both dual mode and simple mode.
I do not use the recording option!
Let me give you a clear example:
I leave marked in the GSSI editor only the GSSI 111012 the rest left unchecked. When listening begins normal, sometimes this fault occurs between one change and another. In exchange exchange TTT simply does nothing, it's as if there was no one talking at that moment. Only on the radio, I can see there's a conversation!
With regard to frequencies 8 are the frequencies with higher intensity. I always use the one that comes with more clarity, usually the one indicated on the radio!
I noticed that in Telive this "empty interval" also occurs.
I hope I have clarified, otherwise I will be able to record a video or something!

Thank you

Complementing, I noticed that when this happens, in SDR # appears in Timeslot the GSSI and ISSI normally but in the remote panel of the TTT it is as if it was not having transmission at that moment, however in the radio the audio is coming out, and precisely the same GSSI and ISSI that appear in Timeslot.
I think now you can understand!

Is the call a group or individual call?
A video of this occurring maybe be helpful.
A copy of the CC/VC log may also shed some light on what is occurring. You would need to point to the Call ID around the missed call so I know where to start looking.

 

[RicardoRJ]

Is the call a group or individual call?

In group!

I will provide the logs and a video highlighting the moment the error occurs.

thankful

 

[DarkAngelT]

Here in the log it appears to me:

Type: UDT-4 Length: 112 Protocol: Simple_location_system DATA: '0000001100000000001001000101000001010011010000110100111101000011010011010010110000110010001100000000110100000000' LocationSystemCodingScheme: 0

When I translate this into binary code this is what I have:

? PSCOCM, 20

With that to know location?
I do not think so?

 

[Kenzi]

This could be a bug, not sure. I would need an IQ sample of your CC frequency (Main_carrier)


How much is a "little bit" off frequency.
Is it +/- 0.00625 MHz off or 0.0125 MHz off or something else.

In the meantime you can disable the auto set Base frequency/Main carrier (CC) and Offset by using the command line option. ( -dm )
For more information see "TTT_Features_and_Usage.pdf' > "Command line options"

Hi, i will get details in next week how much it jumps off. In the next weekend i could send the IQ sample if needed.

 

[thewraith2008]

Here in the log it appears to me:

Type: UDT-4 Length: 112 Protocol: Simple_location_system DATA: '0000001100000000001001000101000001010011010000110100111101000011010011010010110000110010001100000000110100000000' LocationSystemCodingScheme: 0

When I translate this into binary code this is what I have:

? PSCOCM, 20

With that to know location?
I do not think so?

The "$P" indicates Extended/Proprietary Sentences. These extended messages are not standardized.
There for it's unknown how to interpret them. It's obviously not long enough to carrier the coordinates for anything.
Information other than GPS can be carried.

 

[RicardoRJ]

Is the call a group or individual call?
A video of this occurring maybe be helpful.
A copy of the CC/VC log may also shed some light on what is occurring. You would need to point to the Call ID around the missed call so I know where to start looking.

thewraith2008

I filmed the moment of error!
In the video the radio works ok and in the TTT there is a message saying "Call timeout occured - Did not see D-Release" and it is at this moment that I miss part of the conversation. This happens in both single and dual mode.
This is a group conversation in which I am listening to GSSI 111007.
After a few moments TTT speaks again!

Follow the video link: https://www.youtube.com/watch?v=Gc5gV5cg0Bo

thankful

 

[thewraith2008]

thewraith2008

I filmed the moment of error!
In the video the radio works ok and in the TTT there is a message saying "Call timeout occured - Did not see D-Release" and it is at this moment that I miss part of the conversation. This happens in both single and dual mode.
This is a group conversation in which I am listening to GSSI 111007.
After a few moments TTT speaks again!

Follow the video link: https://www.youtube.com/watch?v=Gc5gV5cg0Bo

thankful

Pity you didn't show the full TTT window.
Sounds like increasing the value of the "Call Timeout" will fix the problem. Default is 5 seconds, try a little higher. Do not make it to high as this can have a negative affect of call not releasing. (because another call further delays the release.)

It would seem some networks use a longer timer for when there is no SSI activity in a call. For me, a call normally ends before the 5 seconds.

 

[RicardoRJ]

Pity you didn't show the full TTT window.
Sounds like increasing the value of the "Call Timeout" will fix the problem. Default is 5 seconds, try a little higher. Do not make it to high as this can have a negative affect of call not releasing. (because another call further delays the release.)

It would seem some networks use a longer timer for when there is no SSI activity in a call. For me, a call normally ends before the 5 seconds.

Perfect, problem solved. I just increased the value from 5 to 8 seconds and now everything is going well.
Thanks again and congratulations for the beautiful work.

 

[pd3lkn]

help tetra trunk tracker v0.99.6

how can i use tetra trunktracker for listing to specific gssi only

 

[grahampaull]

how can I use tetra trunktracker for listing to specific gssi only

It's in the Readme for the latest version.

 

[EarHoles]

Hey Guys,
Thank you very much for this from a small county called New Zealand.
I have got it up and running no problems.

Only thing i cant work out ( i know its going to simple)
i have 3 Tetra CC's in my area.
i monitoring the first one flawlessly. Ive attempted to moniter the 2nd and 3rd but it auto reverts back to first site.

Once again this is awesome stuff, thanks again

 

[thewraith2008]

i have 3 Tetra CC's in my area.
i monitoring the first one flawlessly. Ive attempted to moniter the 2nd and 3rd but it auto reverts back to first site.

The plug-in outputs e.g. "SYSINFO - Main_carrier:1234 Offset:3 Frequency_Band:8" which TTT uses to configure itself with. If all frequencies report "Main_carrier:1234" then you most likely have one Main carrier (CC) and two carrier (VC) frequencies for that network (MCC/MNC).

 

[EarHoles]

The plug-in outputs e.g. "SYSINFO - Main_carrier:1234 Offset:3 Frequency_Band:8" which TTT uses to configure itself with. If all frequencies report "Main_carrier:1234" then you most likely have one Main carrier (CC) and two carrier (VC) frequencies for that network (MCC/MNC).

Makes sense. Thank you again and god bless.

 

[tsapers]

Various CC

The plug-in outputs e.g. "SYSINFO - Main_carrier:1234 Offset:3 Frequency_Band:8" which TTT uses to configure itself with. If all frequencies report "Main_carrier:1234" then you most likely have one Main carrier (CC) and two carrier (VC) frequencies for that network (MCC/MNC).

So if the Neighbouring Cells have different Main_carrier values than the current cell, then you can expect there to be various CCs? I have however seen that many GSSIs are shared between the various CC's and others mostly appearing on certain CC's only. Possibly 1 system with many CC's based on location?

 

[thewraith2008]

A network (MNC) can have many locations (LA) to improve coverage. Each LA can have many carriers to handle more users (GSSI/SSI).

Each LA has a main carrier (CC) which sets up calls, i.e. Tells the MS where the call is to take place. (Carrier and Timeslot).

Each carrier broadcasts what it's main carrier is.
The plug-in reads this and outputs it as the custom message "SYSINFO" which TTT interprets.
If you select any (TETRA) carrier (that is not a main carrier), then TTT will switch SDR# to the frequency that the main carrier resides on.

CC = Control channel (not color code)

You can see the same GSSI # on any carrier in all LAs for that network (MNC) and it's will be same user.
You can see the same GSSI # on one network (MNC) and another network (MNC) but they will be different users.

[b]MNC(1) - Provider A (different company to Provider B)[/b]

 -LA(1) - City
  -Main_Carrier(1)
   -Carrier(2) - GSSI:123456 (Transport X)
   -Carrier(3)
   -Carrier(4)

 -LA(2) - City border North
  -Main_Carrier(1)
   -Carrier(2)
   -Carrier(3) - GSSI:123456 (Transport X)

 -LA(3) - City border South
  -Main_Carrier(1)
   -Carrier(2) - GSSI:123456 (Transport X)

GSSI:123456 seen on LA(1,2,3) are same user. (User = Transport X)



[b]MNC(2) - Provider B (different company to Provider A)[/b]

 -LA(1) - City
  -Main_Carrier(1)
   -Carrier(2)
   -Carrier(3) - GSSI:123456 (Transport Y)
   -Carrier(4)

GSSI:123456 (Transport X) seen on MNC(1) LA(1,2,3) is different user than GSSI:123456 (Transport Y) seen on MNC(2) LA(2)

Hope that makes sense.

 

[tsapers]

Thanks, that makes a lot of sense. In my case it is a single MNC with multiple LA's

 

[RMW1010]

I seem to have an issue with SDR# not switching back to the CC after a voice call

I am using TTT in single mode.
The LA I'm monitoring has one CC and a VC. On the CC there are also voice calls.

On some occasions, after a voice call on the VC, SDR# doesn't go back to the CC.
At the top of the SDR# screen it shows the correct frequency for the CC, but when I look at the spectrum it is still on the VC.
I have to select a diffent frequency and then select the CC again.
It doesn't happen everytime, but quite regularly.

Any ideas?

Thanks!

 

[thewraith2008]

I seem to have an issue with SDR# not switching back to the CC after a voice call

I am using TTT in single mode.
The LA I'm monitoring has one CC and a VC. On the CC there are also voice calls.

On some occasions, after a voice call on the VC, SDR# doesn't go back to the CC.
At the top of the SDR# screen it shows the correct frequency for the CC, but when I look at the spectrum it is still on the VC.
I have to select a diffent frequency and then select the CC again.
It doesn't happen everytime, but quite regularly.

Any ideas?

Thanks!

I see this when I use the windows option to "Turn off the display" after X amount of time. It also seems to cause a delay in changing frequency in SDR#.

For me, my monitor is connected via HDMI so when windows sends the "Turn off the display" to the monitor, it goes into a no signal mode (which starts a internal screensaver) which then shuts down (turns off) the monitor after a time, which windows sees as a device disconnect.

My guess is the action of the "Turn off the display" is causing the USB to drop data coming from the dongle when it's turning off (or on again). This dropped data seems to cause some sort of sync issue in SDR#. I normally have to stop SDR# then start it again.

This could come down to CPU power and or the type of USB controller. I not really sure.

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