SDR# TETRA Demodulator Trunk Tracking Demonstration

[tomekjkp]

Why don't you just turn it OFF?

I tried to disable it, but it continues to binary after that. I restarted TTT after a change and no change

 

[thewraith2008]

I tried to disable it, but it continues to binary after that. I restarted TTT after a change and no change

Turning it OFF in the plug-in works here.



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

 

[hamradionl]

Binary output seem only show in the logfile
Obther i notice in the last versions in Settings using Binary output ON / OFF
When Binary output set ON i see SDS messages.
These type SDS messages are gone when set Binary output to OFF
And instead while Binary is set OFF, i see other SDS type message who not show when binary output is ON

I read the manual ...... but did i miss some information?

Anyone else notice this?

 

[digiman1]

Hello, does anyone have an archived version of the TTT plugin? Because the new one throws out binary digits in SDS, which is tedious when reading the file. My request, as if the author could collect all previous versions and put on his MEGA it would probably be very helpful for some. greetings

Why dont you use the built in feature to read the SDS? On the list of all the calls, right click this and you should see all the SDS messages.

 

[hamradionl]

Why dont you use the built in feature to read the SDS? On the list of all the calls, right click this and you should see all the SDS messages.

The last release work different than the early release in that window or in list
Cant see all messages because when turn ON binary mode you see SDS messages-A. When turn OFF binary mode you see SDS messages-B.

 

[Jo6466]

I have a SDR ELAD FDM-S1 ... is it compatible with your plugins?

 

[thewraith2008]

The last release work different than the early release in that window or in list
Cant see all messages because when turn ON binary mode you see SDS messages-A. When turn OFF binary mode you see SDS messages-B.

I need real world examples, not cryptic 'SDS messages-A' and 'SDS messages-B'. How am I supposed to know what types of messages are been passed and not been passed here.

All tests here of SDS messages output by the plug-in with 'TEXT:......' are shown in TTT SDS event window.

When 'SDS - Show binary string' option is enabled, the binary string for the UDT-4 is appended to output. This binary string is NOT shown in TTT SDS event window. (never has been)

When 'SDS - Show binary string' option is enabled in the plug-in and the 'TETRA_sds_unknown_protocol.txt' is defined for a 'User_Defined_xxx' or Reserved_xxx' protocol ID, then TTT will translate the binary string into 8 bit characters and display it in the SDS event window.

When 'SDS - Show binary string' option is disabled in the plug-in and the 'TETRA_sds_unknown_protocol.txt' is defined for a 'User_Defined_xxx' or Reserved_xxx' protocol ID, then TTT will only show that the message was seen and show that in the SDS event window.
- e.g 10/09/2019 12:25:00 PM - ISSI: 12345678 - Protocol: User_defined_123

When 'SDS - Show binary string' option is disabled in the plug-in and the 'TETRA_sds_unknown_protocol.txt' is NOT defined for a 'User_Defined_xxx' or Reserved_xxx' protocol ID, then TTT will NOT show anything in the SDS event window.

I have a SDR ELAD FDM-S1 ... is it compatible with your plugins?

Is that SDR fully supported by SDR#. If not then no.



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

 

[jlxsolutions]

Well Said

 

[hamradionl]

I need real world examples, not cryptic 'SDS messages-A' and 'SDS messages-B'. How am I supposed to know what types of messages are been passed and not been passed here.

5 days ago send logfile as PM in the LOG file you notice when ON show behind the line "YES" but not show the actual SDS TXT message.
When turned OFF the "YES" is gone and you see the actual SDS txt message.
And in the event window (right mouse click) you will notice the 2 different type of SDS TXT message when switch binary ON / OFF
Just try you notice it.

This binary string is NOT shown in TTT SDS event window. (never has been)

Yes it did show in SDS event window!
The first version we both tested that function show binary as that the way we both to get that UserDefine up and running.
Are you forgot this?

I give up feetback coming months because it need do other things like betatest a new digital hardware receiver.
Good luck all.

 

[thewraith2008]

5 days ago send logfile as PM in the LOG file you notice when ON show behind the line "YES" but not show the actual SDS TXT message.
When turned OFF the "YES" is gone and you see the actual SDS txt message.
And in the event window (right mouse click) you will notice the 2 different type of SDS TXT message when switch binary ON / OFF
Just try you notice it.

Yes you did dump a logfile in a PM, but you failed to explain anything about it.
Even with what you said above, it still makes no sense.

Yes it did show in SDS event window!

No release version ever showed the binary string anywhere in TTT. TTT only passed it to a log file.

from TTT changelog for v1.0.14.3
ADDED: SDS event window panel for location and text messages.
- To access right click the event log panel and again to switch back.
- Not all "text" messages are human readable. Without documentation as to it's structure, then it is considered a unknown format.
- Does not show the 'Binary' strings as these can get quite long. see them in the 'TETRA_sds_data_xxxx.log' file.

The first version we both tested that function show binary as that the way we both to get that UserDefine up and running.
Are you forgot this?

Stop referring to a test/development versions. If the binary strings where shown in these versions they are not in the release version.
No-one wants to see binary data spamming the event window and if they do then look at the output window in 'Network Info' or look at one of the two logfiles. ('TETRA_cx_xxxx.log' or 'TETRA_sds_data_xxxx.log')
If the 'TETRA_sds_unknown_protocol.txt' file is used properly, then TTT will translate the binary string in to a character string and that will be shown in TTT SDS event window.

If SDS messages are been missed (using the latest release version) you need to more clearly demonstrate this occurring. Make a video or animated GIF.
What is the protocol of the SDS been missed, is it always the same type?



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

 

[DarkAngelT]

@thewraith2008 I would suggest a new function if it is possible!
priority by activity! GSSI among those selected with the highest activity would have priority.

 

[senavick2]

Set up today using two Mini Airspy dongles. After configuring (little bit of hit and miss I admit) I just want to thank Ian once again for a great program (I still have his original modem for MPT trunking) Regards and again thank you.. Shane Vickers

 

[thewraith2008]

Set up today using two Mini Airspy dongles. After configuring (little bit of hit and miss I admit) I just want to thank Ian once again for a great program (I still have his original modem for MPT trunking) Regards and again thank you.. Shane Vickers

I'm not "Ian"

But thanks for the thanks anyway.



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

 

[senavick2]

Please accept my apologies on that mistake..
Sitting here this morning listening to our CBD rail system drivers permission to end blocks etc is fantastic..
So once again thank you...

 

[asgard]

@ the wraith and others ham radio fellows enjoying tetra hobby we will be glad to have you in our telegram tech talk group regarding a tetra radio hotspot building. All help regarding hw and sw cont. Don't wanna stress people with private messages so if someone is interested please inbox me . thanks

 

[webexcel82]

Hi all! I'm monitoring the same tetra network with 2 pc. On pc 1 have installed two sdr dongles and TTT, on pc 2 have installed one sdr dongle and tetra network monitor (TNM). In both pc have the exactly the same filter lockouts and the same priorities.
It seems that TTT loose some data reading the control channel
I had seen that in TNM I have a greater number of communications than in TTT when it should be just the opposite, why??

 

[thewraith2008]

Hi all! I'm monitoring the same tetra network with 2 pc. On pc 1 have installed two sdr dongles and TTT, on pc 2 have installed one sdr dongle and tetra network monitor (TNM). In both pc have the exactly the same filter lockouts and the same priorities.
It seems that TTT loose some data reading the control channel
I had seen that in TNM I have a greater number of communications than in TTT when it should be just the opposite, why??

What mode are you running TNM in?

It seems that TTT loose some data reading the control channel

What data is it missing? If you can see it on one and not the other then what is it?



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

 

[oz1jua]

I have seen something similar. But in my case it is becouse the system using more Control Channel with different LA.
TNM is just received all data on the channel that is setup and do not trunck track from Control Channel I think.
TTT has to trunk track from the MCCH. And if no data is there and MCCH is on another channel TTT does not se it I think.

This is similar to the Whistler vs. Uniden. Where Uniden Trunk Track correct on DMR and Whistler just receive
data from the freqency that is setup. Se this threads TRX-1 or Uniden 325P2

 

[thewraith2008]

I have seen something similar. But in my case it is becouse the system using more Control Channel with different LA.
TNM is just received all data on the channel that is setup and do not trunck track from Control Channel I think.
TTT has to trunk track from the MCCH. And if no data is there and MCCH is on another channel TTT does not se it I think.

This is similar to the Whistler vs. Uniden. Where Uniden Trunk Track correct on DMR and Whistler just receive
data from the freqency that is setup. Se this threads TRX-1 or Uniden 325P2

TNM and TTT both monitor the MCCH (and SCCH if exists).
Calls are only set-up from here. No call set-ups are sent on (assigned) traffic channels/carriers.
If TTT/TNM are in single mode, then when they leave the main carrier (which has MCCH/SCCH) to follow a call, it is no longer possible to monitor control data any more. Call set-ups will be missed.

If TTT is dual mode then it will always monitor MCCH (except when a duplex call is set-up off the main carrier - this can be disabled).
- If on a duplux call off the main carrier, then call set-ups will be missed.
If TNM is Master/Slave, and if set-up correctly (where only MCCH are set on each turner - except #2 tuner) then it will always monitor all the set and enabled MCCH and display all the call set-ups from any MCCH that is sending them.

That is of course the theory of operation, if it's missing some thing (assumed calls) then I need to know what type or some other details of it.
Maybe a screenshot,video,animated GIF of what your are seeing.

TNM is a working in progress and far from complete, I have kind of lost interest with it for now.

Some of the missed calls in TTT maybe because of what I explained here.



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

 

[polar1]

@thewraith2008 can you please take a look at PM regarding some questions on TNM? I'd appreciate it