SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

@thewraith2008

I would like to inform you of a bug in this version that didn't happen in other versions.
I use TTT on Windows 10 x64 in dual mode.
I open both SDRs and when I start TTT it starts only one of the SDRs.
I always need to close TTT and open it again so that it recognizes the two SDR windows.
Other than that, the program is working perfectly for me!

What version of SDR# are you using? Newer versions maybe a problem, stick with v1716.

The code for this has not change in a long time.
If you have experienced this problem for awhile then you should have said something sooner, the ship has sailed me thinks.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[DarkAngelT]

What version of SDR# are you using? Newer versions maybe a problem, stick with v1716.

The code for this has not change in a long time.
If you have experienced this problem for awhile then you should have said something sooner, the ship has sailed me thinks.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

I'm using the SDR version you mentioned.
About the bug, it only appeared to me in this version of TTT.
Until a version before this this bug did not occur.

 

[DarkAngelT]

Hi DarkAngelT,

A workaround that I found regarding that is to have the following options on TTT like this:
1- TTT Options (O) --> "Start Network Info Minimized" Enabled
2- TTT Options (O) --> "Position SDR#" Disabled

That should allow SDR and TTT to start normally at 1st attempt without having to close and open it again.

@thewraith2008

I did the test that the colleague mentioned above and in fact TTT was able to trigger both windows simultaneously.
There seems to be a problem with the "Position SDR#" option
I should also mention that although the "Start Network Info Minimized" option is enabled, the Network Info window does not start minimized.

 

[FR33MAN]

Hello, after using TTT for a long time I was surprised that the port can be changed, I would like to do it to have two TTT on the same PC, I have read that it is changed with the command line, adding -sp XXXX in the path, but no I get them to fit, I'm doing something wrong. can you help me please.


Thank you very much.

 

[thewraith2008]

You change the port number directly in TTT. (and then in the plug-in)
See general options third panel. (click the 'O' button three times)

I've not really tried use more than one instance of TTT (and SDR# + Plug-in).
There are caveats to running more the one TTT at a time if it does work.
One of them is not running multiple TTT from same folder. (that pobably goes for SDR# too)



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[radionordic]

Does anyone have problems getting the ISSI and GSSI displayed on DMO? Seems to generate some random numbers everytime on DMO.
This is all clear, can hear voice fine.

 

[radionordic]

Does anyone have problems getting the ISSI and GSSI displayed on DMO? Seems to generate some random numbers everytime on DMO.
This is all clear, can hear voice fine.

Correction, GSSI shows up, its only ISSI that seems to generate a random number each time the demodulator is activated.

 

[thewraith2008]

DMO can use pseudo addressing.

• This is indicated by the PDU element 'Destination address type' or 'Source address type' (when 1=Pseudo SSI)

This number is random and the true address cannot be derived from it.

8.4.7.7 Selection of pseudo address
In those cases where the DM-MS does not wish to use its true ISSI as a layer 2 address the DM-MAC shall randomly
select a pseudo SSI address, using the procedures detailed in clause 8.5.2. The use of a pseudo address by the DM-MS
shall be indicated in the signalling message

The pseudo SSI has a limited lifetime.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[oscar6]

In DMO i got this info:

DMAC-DATA : ISSI:1235 to ISSI:6789 Type:UDT-4 Length:104 Protocol:Location_information SubType:Location_protocol_with_extension SubTypeExt:Long_location_report TimeDataType:2 LongShapeType:Location_point LongVelocityType:No_velocity_information Lat:xxxxx° Long:xxxxx° 1 frames remaining SDS sent as stand-alone transaction  DM_SDS_UDATA

Is it possible to programm my radio as ISSI:6789 and receive ISSI:12345's location via SDS?

 

[apcofan]

Hi! Thanks for great piece of software! Got problem with recording... TTT records RAW audio instead of TETRA demodulator audio. Calls are heard okay, but not recorded properly. What can be wrong?

Regards, Kamil

 

[thewraith2008]

Sounds like you need to check how the record device is setup.
Please check instructions in the documentation to see if you missed a step.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[apcofan]

Sounds like you need to check how the record device is setup.
Please check instructions in the documentation to see if you missed a step.

Thanks Ian! I noticed that VBcable isn`t set as a default audio input, now it works perfectly!

 

[Skowt]

Has anyone had an issue with SDR# where the frequency changes but the spectrum analyzer doesn't actually pickup the change until you manually drag the frequency back and forth?

I've tried the latest version of SDR#, and then v1.0.0.1716 and so on and no joy. Anything I should be trying?

 

[FERRAINAELENA]

did development STOP HERE?

 

[Ubbe]

Has anyone had an issue with SDR# where the frequency changes but the spectrum analyzer doesn't actually pickup the change until you manually drag the frequency back and forth?

Something similar that the spectrum doesn't follow the frequency change if I have SDR# running for a full day or so and it has to be restarted to get the spectrum working again. This is with an old 1642 version.

/Ubbe

 

[thewraith2008]

Has anyone had an issue with SDR# where the frequency changes but the spectrum analyzer doesn't actually pickup the change until you manually drag the frequency back and forth?

I've tried the latest version of SDR#, and then v1.0.0.1716 and so on and no joy.

If you are using a RTL dongle, this type of issue is sometimes related to the driver and SDR# standard RTL frontend.

Specifically the communication with the RTL2832U via libusb hangs on the 'rtlsdr_set_center_freq' function and will eventually throw a -9 (LIBUSB_ERROR_PIPE) error. Because the driver and SDR# RTL frontend does not validate the frequency change, you see this effect of VFO change but the actually spectrum does not. If you try and stop or close SDR# before the function has returned, SDR# will crash.

Anything I should be trying?

Not really much you can do via the standard driver and SDR# frontend. (this problem has been around for years)
Resetting the RTL2832U is the cure here when first seen. Why this -9 (LIBUSB_ERROR_PIPE) error starts to randomly occur is a mystery.
Unfortunately, the only way to do this with the standard frontend is restart SDR# or wait for the 'rtlsdr_set_center_freq' function to return (usually the spectrum will update a few seconds later) and stop/start the radio in SDR#. (this issue may still repeat again after sometime)

Sadly creators of SDR# blocked the ability to fix this by not allowing external SDR frontends to be used anymore.
Another reason why I stick to using the older version (v1716) of SDR#.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[thewraith2008]

did development STOP HERE?

For the most part, yes.

I don't have TETRA here anymore and no longer use the TTT program/plug-in.
I'm not against applying fixes when needed but this would not be a priority for me.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[Cretu]

For the most part, yes.

I don't have TETRA here anymore and no longer use the TTT program/plug-in.
I'm not against applying fixes when needed but this would not be a priority for me.

Hello and first of all, let me thank your for your hard work.

I understand your priorities are others now, but perhaps you could take a look at this: with the latest TETRA Demodulator Plugin (11/09/2021 1.8.6.0) running the latest SDR#, when you open a slicer, it throws the following error. No need to do anything, even if the plugin is not loaded. Just open the slicer and here it comes. This doesn't happen with the original old TETRA Demodulator plugin. To my limited understanding, it seems to be a .NET thing.

Best regards.

 

[thewraith2008]

Hello and first of all, let me thank your for your hard work.

I understand your priorities are others now, but perhaps you could take a look at this: with the latest TETRA Demodulator Plugin (11/09/2021 1.8.6.0) running the latest SDR#, when you open a slicer, it throws the following error. No need to do anything, even if the plugin is not loaded. Just open the slicer and here it comes. This doesn't happen with the original old TETRA Demodulator plugin. To my limited understanding, it seems to be a .NET thing.

Best regards.

TETRA Demodulator Plug-in was not designed with running it as multiple instances (like in SDR# slicer).
SDR# slicer wasn't a thing when the plug-in was been developed originally.

It would take to much to fix this as there are many different issues that need to be addressed.

• Use of static variables and methods that change them.
• One instance may remove something (from a static variable) that another instance still thinks is there.
• Or trying to add something (to a static variable) that all ready exists (This is what you are seeing).
• The saved settings from different instances would cause a conflict because they are the same and some values need to be unique.
• The saved settings from different instances would overwrite each other.
• Other ?

What I should do is patch the plug-in so it can't be used in a slicer instance.

The only way to have multiple instances of the TETRA Demodulator Plug-in running is to also have multiple instances of SDR# running (from different folders). I would recommend using and older version of SDR# (v1716) and not any of the newer SDR# versions for this purpose.

Another suggestion is to try the TETRA Network Monitor (TNM - program/plug-in)
This will avoid the ugliness of multiple windows (depending on how you set it up)
This is an off shoot of the TETRA Demodulator Plug-in which allows multiple VFO to be use.
TNM is not as developed as TETRA Demodulator Plug-in but may meet your needs.
Again, I would recommend using an older version of SDR# (v1716) and not any of the newer SDR# versions.
NOTE: This can't be used with slicer either.



Latest version (v1.8.6.0) can be found here: MEGA - Download
Release post here

 

[kayakaan02]

@thewraith2008 first thank you for your hard work and effort on this.

I got a question in my mind. I can use tetra-rx on msys with sdr#, but is sdr# really necessary for this? correct me if I'm wrong but I think it only sends data to tetra-rx, receives the decoded data back and displays it, I can as well see the output on msys window.

I really don't need the speech decoder but only the output from tetra-rx. So how can I send data to tetra-rx from another source? for example from gnuradio using udp sink etc.

Also I see tetra-rx is an executable file. How did it compiled into an exe? is there an open source code of it so I can see and work on it myself?

Thanks in advance.

edit: sorry if this is already asked, I couldn't find it anywhere