SDR# TETRA Demodulator Trunk Tracking Demonstration

[hamradionl]

in my local area start using tetra 18 years ago
1x LA there are many, many users from different companys who not use trunk function and stay on the MAIN and only switch between the 4 slots and they not switch nor going elsewhere
example
there are in total 15 different private network and all network using 23 different LA within a 15 - 30 km range, so in total there are 15 x 23 LA and 15 x 23 x 4 slots to swith to and there also 4x network use more than one MAIN and TSSDR and TTT doing nice job sofar.
The AUTO mode is monitor all the 4 slots on 1x MAIN and fallowing a particular GSSI or SSI and go to one of the 23 other LA slot
Some users are simplex + trunk all together and even using more as 1 MAIN sometimes use 4x or 6x MAIN data channels. When TTT auto mode is no longer working, that moment TTT become a program for a network with only 1 user and 1 operator and only work for that user. If that the case, new TTT is no longer useful and role back to the previous version when able to deside if use only the AUTO or Both AUTO + trunk function.
I try in my best possible english and wish my message is clear.

 

[hamradionl]

I did a count, 42x MAIN data channels use 6 to 23 neighbour cells. The smaller ones only simplex or semi-duplex and larger do trunk + simplex + semi-duplex in de mix.

 

[DarkAngelT]

I noticed that in dual mode the main carrier is not going automatically when changing the tetra carrier!
This happens in CC
In VC works normal
In previous versions this worked automatically.

Congratulations for the work!

Truth! I realized that today! When the network changes frequency MCCH, TTT detects where the MCCH is, but does not automatically change frequency as it did in previous versions.

 

[hamradionl]

I noticed that in dual mode the main carrier is not going automatically when changing the tetra carrier!
This happens in CC
In VC works normal
In previous versions this worked automatically.

Correct, TTT is no longer fallowing MCCH

 

[badyunior]

23th Public Release - TETRA Trunk Tracker and TETRA Demodulator plug-in - v1.6.3.4

Hi Wraith,

I saw that call timout time is 150seconds. Is it possible to change this option somewhere in TTT? Sometimes call ends without signal of end call, then TTT still record and decode but only mishmash sound. And this create record files of 100MB, to the timeout or another "end call" signal.

Regards.
Darek

 

[DarkAngelT]

Correct, TTT is no longer fallowing MCCH

Exactly! If The MCCH changed. The VC change normally to the new frequency, but The CC does not! It remained as often as before. It has not changed to the new frequency. The CC only changes if you manually in SDR place or manually click on CC PARK in TTT

 

[thewraith2008]

Hi Wraith,

I saw that call timout time is 150seconds. Is it possible to change this option somewhere in TTT? Sometimes call ends without signal of end call, then TTT still record and decode but only mishmash sound. And this create record files of 100MB, to the timeout or another "end call" signal.

Regards.
Darek

The 150 is not seconds but the number of 300mS segments in timeout value (e.g. 45 seconds)
The 300mS is the internal timer interval. e.g. 45 / 0.3 = 150

I never got around to making the UI just show the seconds.
I have now changed this for next release.

Changing the 'Call Timeout' value is covered in the documentation.



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

 

[thewraith2008]

I have created a hotfix for those that are seeing the issue with the MCCH following in dual mode.
Thanks to DarkAngelT and RicardoRJ who have tested this hotfix and confirmed that it is working again.

The hotfix is only to be applied to the 'TTT_1.6.3.4_release.7z' release.

The hotfix only has one file: 'tetra_trunk_tracker.exe'.
- Please download 'TTT_1.6.3.4_release.7z' and install if you have not already done so.
- Also download 'TTT_hotfix_v1.6.3.6.7z' and copy and replace the 'tetra_trunk_tracker.exe' file.

The following as been changed:

v1.6.3.6 - hotfix

CHANGED: Call Timeout UI displayed value.
- The 150 is not seconds but the number of 300mS segments in timeout value (e.g. 45 seconds)
    The 300mS is the internal timer interval. e.g. 45 / 0.3 = 150


FIX: Internal IQ sample carrier range usage debug code.

=====================================================================================================
v1.6.3.5 - hotfix

FIX: Was not auto switching to MCCH in TTT dual mode.
- MCCH following code was not updated with the recent major changes and was addressing wrong SDR#.

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

If there are no other issues seen, I will package up a release version in next couple of days.
Jingle bells everybody.



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.6.7z' and copy and replace the two files into the above install.

 

[hamradionl]

not working

 

[hamradionl]

big area wide network use 23x MAIN MCCH cells with 4x slots and calls are switch between those 23x MCCH in 4x slots in full duplex mode
voice one is using MAIN MCCH-1 slot 1 and cell is located in west part of area
voice two is using MAIN MCCH-6 slot 3 and cell is located in south part of area
VOICE AUTO not working and TTT not able to fallow any voice traffic in this network

 

[iw2dtt]

Hello
non there is the possibility to decode the following messages
thank you

SSI:6xxxxxxx D_SDS_Data Party_SSI:xxxxxxxx Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'ãäá'

 

[iw2dtt]

SSI: D_SDS_Data Party_SSI:Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$ã6'
SSI: D_SDS_Data Party_SS Type:UDT-4 Length:64 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'& @A'
SSI: D_SDS_Data Party_SSI: Type:UDT-4 Length:64 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'& z'
SSI: D_SDS_Data Party_SSI: Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$/ãÌ'
SSI_SDS_Data Party_SSI: Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$5ã1'

 

[DarkAngelT]

I have created a hotfix for those that are seeing the issue with the MCCH following in dual mode.
Thanks to DarkAngelT and RicardoRJ who have tested this hotfix and confirmed that it is working again.

The hotfix is only to be applied to the 'TTT_1.6.3.4_release.7z' release.

The hotfix only has one file: 'tetra_trunk_tracker.exe'.
- Please download 'TTT_1.6.3.4_release.7z' and install if you have not already done so.
- Also download 'TTT_hotfix_v1.6.3.6.7z' and copy and replace the 'tetra_trunk_tracker.exe' file.

The following as been changed:

v1.6.3.6 - hotfix

CHANGED: Call Timeout UI displayed value.
- The 150 is not seconds but the number of 300mS segments in timeout value (e.g. 45 seconds)
    The 300mS is the internal timer interval. e.g. 45 / 0.3 = 150


FIX: Internal IQ sample carrier range usage debug code.

=====================================================================================================
v1.6.3.5 - hotfix

FIX: Was not auto switching to MCCH in TTT dual mode.
- MCCH following code was not updated with the recent major changes and was addressing wrong SDR#.

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

If there are no other issues seen, I will package up a release version in next couple of days.
Jingle bells everybody.



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.6.7z' and copy and replace the two files into the above install.

Thanks for the correction!

I would like to comment that there is a bug in the Network Info window when TTT is running

 

[DarkAngelT]

Two more things to add.

1 - In this update is impossible to use the auto function of the plugin Tetra Demodulator if I want to use without TTT.

Now speaking of TTT:

2 - I noticed that TTT is not following the communication as in previous versions.

MCCH issue has been resolved.

However, VC is not pursuing communication over different frequencies.

Both CC and VC are constantly at the frequency where there is MCCH.

If MCCH changes both SDRs go to the frequency where they are. Ok,
but I realized that TTT is not following the communication by different frequencies as before!

 

[DarkAngelT]

Create another folder and reconfigure again in version 1.0.20
Because this new version is still very unstable!

I will continue testing with each new patch or release.
But to hear without missing anything you're on the network, I prefer version 1.0.20

For me so far proved to be the most stable version!

 

[DRL-XM43]

Two more things to add.

1 - In this update is impossible to use the auto function of the plugin Tetra Demodulator if I want to use without TTT.

I think you need to uncheck use TTT in the plug config

 

[hamradionl]

I think you need to uncheck use TTT in the plug config

Yes you right, missing the VOICE AUTO
I also role back to a previous released version.

 

[thewraith2008]

big area wide network use 23x MAIN MCCH cells with 4x slots and calls are switch between those 23x MCCH in 4x slots in full duplex mode
voice one is using MAIN MCCH-1 slot 1 and cell is located in west part of area
voice two is using MAIN MCCH-6 slot 3 and cell is located in south part of area
VOICE AUTO not working and TTT not able to fallow any voice traffic in this network

TTT only follows traffic on a single LA not multiple LAs.
Why do you keep going on about the 'Auto'. It is not supposed to be used with TTT. See response to DarkAngelIT further down for reason.

Hello
non there is the possibility to decode the following messages
thank you

SSI:6xxxxxxx D_SDS_Data Party_SSI:xxxxxxxx Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'ãäá'

SSI: D_SDS_Data Party_SSI:Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$ã6'
SSI: D_SDS_Data Party_SS Type:UDT-4 Length:64 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'& @A'
SSI: D_SDS_Data Party_SSI: Type:UDT-4 Length:64 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'& z'
SSI: D_SDS_Data Party_SSI: Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$/ãÌ'
SSI_SDS_Data Party_SSI: Type:UDT-4 Length:96 Protocol:Simple_text_msg TextCodingScheme:Latin_1 TEXT:'$5ã1'

Text messages don't have to be human readable.
How the contents of message that is not human readable is used is not described in standards.

Two more things to add.

1 - In this update is impossible to use the auto function of the plugin Tetra Demodulator if I want to use without TTT.

I have already addressed this here.
And when the 'TTT Mode Enable' is disabled and 'Auto' is enabled, then 'Auto' works as it should.

Just to be clear about the plug-in 'Auto' function.
When the plug-in is used with TTT, the 'Auto' is disabled because TTT is supposed to control the timeslot as per 'D_Setup'.
To allow 'Auto' to be ON while TTT is supposed to be in control is not right.
If a call is started by TTT then the 'Auto' changes the timeslot, then you are no longer listening to the call that TTT just set-up and any voice traffic or call information will be wrong. Why on earth would anyone want this as a desirable behavior.

Now speaking of TTT:

2 - I noticed that TTT is not following the communication as in previous versions.

MCCH issue has been resolved.

However, VC is not pursuing communication over different frequencies.

Both CC and VC are constantly at the frequency where there is MCCH.

If MCCH changes both SDRs go to the frequency where they are. Ok,
but I realized that TTT is not following the communication by different frequencies as before!

I'm seeing calls follow to other carriers for both single and dual modes.
Not sure why it's not working for you.



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.6.7z' and copy and replace the two files into the above install.

 

[hamradionl]

thewraith2008
There is some misunderstand, not the SLOT and not the LA are switching but the whole MCCH is switching or moving or how do i explain this?
Anyone else know how to make this clear to thewraith2008 ?
Some network in other countrys are using total different network setup.
Sorry my good friend, i think the best is to turn on the functionality s in the program again, and let user itself manage the functions in the program, the user know what is working best for his own local situation.
But if not possible for the newer version, switch back to previous version

 

[Ubbe]

Is there an explanation on the web how this system are supposed to be configured?
TTT are designed to help with trunk tracking, that the tetra plugin for SDR# couldn't do.

All tetra systems are trunked systems. There are always 4 slots on a frequency and if only one frequency are at use at one LA site then there are one control channel where all mobile radios needs to be connected to. Then the control channel sends out data to direct mobiles to which other 3 slots they should go to for the voice communication. That's the definition of a trunked system.

Semiduplex or duplex are just the way the communication are performed, if they have to wait on each other and say "over" or if they can talk at the same time as they listen, full duplex.

Simplex are when two mobiles talk to each other outside of the trunked system and no basestation or LA can be involved in that.
There are mobile gateways available that monitor simplex communications and patch them to a talkgroup in the tetra system.

In some extremly busy systems, with a lot of frequencies on one LA site, a single control channel will be overloaded by too many mobiles and then you can create several control channel slots on other frequencies to spread out the load on different basestation controllers in the same site LA.

TTT can only decode data from one control channel at a time. It has the same problem as choosing which LA to monitor in a system. Some LA have some talkgroups at a particular moment and other LA sites carry different TG's but they could change constantly and it is usually difficult to monitor all TG's from one LA site, or from one control channel of several available in the same LA. You'll need to run several dongles and several instances of SDR# and TTT to try and monitor more calls.

If mobiles are involved in sending large amount of data, that takes a long time to do for each mobile, it will block a slot from others to use and then mobiles must be spread out on different control channels but can be on the same frequency as it isn't overloading that basestations controller too much. In that case one frequency in one LA could have several control channels. I guess that this is how your system are setup, that groups of mobiles use different slots on the same frequency as control channels and if auto in SDR# are enabled it will decode the data from whatever control channel slot are setting up a voice call. But TTT in later releases are coded to only decode data from one slot in SDR#.

I know that there have been some bugs, or more like bad software designs, in some tetra systems basestations that the sub control channels didn't get the same information as the main control channel where sending and it gave all sorts of huge problems. But a good working system should have the exact same data being sent on all control channels in one LA, but perhaps that's still not the case in your system, it's an old system and perhaps no one are paying to get upgrades, and you have to monitor several different control channels in one LA to be able to follow as much conversations as possible.

/Ubbe

in my local area start using tetra 18 years ago
1x LA there are many, many users from different companys who not use trunk function and stay on the MAIN and only switch between the 4 slots and they not switch nor going elsewhere
example
there are in total 15 different private network and all network using 23 different LA within a 15 - 30 km range, so in total there are 15 x 23 LA and 15 x 23 x 4 slots to swith to and there also 4x network use more than one MAIN and TSSDR and TTT doing nice job sofar.
The AUTO mode is monitor all the 4 slots on 1x MAIN and fallowing a particular GSSI or SSI and go to one of the 23 other LA slot
Some users are simplex + trunk all together and even using more as 1 MAIN sometimes use 4x or 6x MAIN data channels. When TTT auto mode is no longer working, that moment TTT become a program for a network with only 1 user and 1 operator and only work for that user. If that the case, new TTT is no longer useful and role back to the previous version when able to deside if use only the AUTO or Both AUTO + trunk function.
I try in my best possible english and wish my message is clear.