SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

The TETRA plug-in will work best with SDR# v1716.
I don't think v1918 will work either, maybe v1917.

These later versions of SDR# have seen many changes in SDR# and the plug-in API.
This has made the updating the SDR# plug-ins a real bore.

The two main things recently is the change in the audio stream level and the removal of the 'Slope' property for AGC.
The TETRA plug-in would require a fair amount of work to bring it in-line with SDR# v1919 and beyond with no backwards compatibility.
Since I dislike the newer SDR#, I don't see any updates specifically for it occurring anytime soon.
I do fixes where I can, but there are limits to this.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[hassanila]

Thank you for your response @thewraith2008

It's understandable, thank you for your work, much appreciated.

I have downgraded to SDR# v1910 and everything works perfectly now.

The only reason I have updated to a newer version of SDR# is that I noticed some performance improvements especially when opening and closing SDR#, and probably less random crashes.

For future reference:
I used archive.org to download older versions of SDR#

 

[causeway74]

Hi @thewraith2008 - I see Prog has recently been working on a Telerik-free version of SDR Sharp. How does this potentially impact your plugins - is that a good news move that should make compatibility much easier?

I need to set aside time to test but keen to get your view.

 

[thewraith2008]

The plug-ins will either work or they won't.

I won't chase the development of SDR# again like I did when the Telerik version came about.
SDR# has not seen a real stable version since v1716. Almost everything (UI related) after was just horrible and buggy/clunky.

Now just when it was settling down (v1919), we are back to where we were 4+ years ago (2019).
In a short period, we have seen 'sdrsharp-x86-winforms' and 'sdrsharp-x86-minimal' versions appear.

Who knows where SDR# is going. (Constant UI and .NET changes)
I'm not against new development of SDR#, but when plug-ins are built on top of it, maintaining them becomes harder especially with the number of plugins I've maintained over the years.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[NMT]

Could you please create another version of the plugin that would show the parameters:

Fast Reselect Threshold [FRT]
Slow Reselect Threshold [SRT]
Fast Reselection Hysteresis [FRH]
Slow Reselection Hysteresis [SRH]

These interesting variables are assigned by each BS in addition to the parameters your plugin already presents. I don't think it would be difficult to add this in a new version of the plugin. Kind regards.

 

[thewraith2008]

These interesting variables are assigned by each BS

In what PDU are they transported?

This are probably calculated and based on values that are already shown in the Network Info > Current/Neighbour cell tabs.

• see: MS_TXPwr_Max_Cell, RXLevel_Access_Min, Access_Parameter

I don't think it would be difficult to add this in a new version of the plugin

Funny how people always think that.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[NMT]

Thank you for your response. The mentioned parameters are crucial for smooth roaming between sites and are implemented to each BS. I am more than sure that they are not calculated, but passed directly in the signaling data stream. You misunderstood me a bit. I'm not saying that writing a plugin is easy. My point is that since you've extracted "Access Parameters" data, "exposing" similar data may not be difficult. Professional programs such as Scout, Decodio, or the TTS-2000 drive test machine present data such as Fast/Slow Reselect Threshold and Hysteresis. I don't think they come from calculations, but are passed "straight" to MS terminals. Thank you very much for your work and effort. The plugin does a nice job, and I'm not talking about the ability to listen to clear.

 

[NMT]

Supplement. In Decodio it looks like the attached graphic. This data is part of the D-NWRK-BROADCAST section, which your plugin partially shows. Could you check if you have missed any data? Thank you.

 

[thewraith2008]

OK, I see where the elements in question are now.
These four sub elements come under the 'Cell re-select parameters' in the D_NWRK_BROADCAST PDU.
The plug-in does decode the 'Cell re-select parameters' (and also the 'Cell load CA') but does not break them down and display them in the 'Neighbour cell' tab.

I think the 'Cell load CA' (which is shown here as 'Cell_Service_level') is probably the same meaning as the 'CellServiceLevel' shown in the 'Current Cell' tab.

This is roughly what I got to show:

I had to mess about to pass those elements with the neighbour cell details.
Not 100% but it does show now.
Does need a bit of a clean up and I don't think it updates what is displayed once it's seen but I don't think that would be something that always changes.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[NMT]

Good job! This is what I ment. The values you have now added are constant, i.e. you enter them individually for each BS, but they do not change by themselves. Based on them, the MS makes a decision about roaming between cells of the same network. All I can do is ask you to publish a version of the plugin that will present this data in the same form as in the graphics you attached. I have access to the network settings so I will be able to check if the updated plugin shows the correct values. Thank you again for your good work.

 

[NMT]

Cell service level:
Sets the cell service level information element, i.e. define the level of service a MS may
receive in a cell. It may relate to the traffic loading in a cell.
The following service levels are supported:
● "Cell load unknown"
● "Low cell load"
● "Medium cell load"
● "High cell load"

The above description comes from the manual for the TETRA generator manufactured by R/S. This parameter is taken into account during roaming and affects the "attractiveness" of the base station. It is usually set to "Cell load unknown", which makes it transparent with this setting.

 

[HamZeroAT]

Hello!
the trunk tracker works perfectly BUT if i activate the recording function and it records i can't hear anything out of the .WAV files.
i can hear when someone talks on the group via the Trunk Tracker but the recorded one is like there is nothing recorded.
any ideas?


thank you,
Patrick

 

[thewraith2008]

TTT is simple when it comes to it's recording feature.
It only records from the systems default recording device.
Please see the documentation about setting this record feature up for TTT.

Windows 10/11 may have additional requirements for allowing recording from a device.
I've never used TTT on Windows 10/11 so I can't really help with that but if the documentation doesn't help then someone else can probably help with what else maybe required to get it to work.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[bianco99]

Hi,
I wanna start using TETRA demodulator with SDR shap.
Could someone helping me with the best SDR sharp to install and the plugin?
I have windows11.

Kind regards,

 

[loffa]

Hi,

Thanks for this awesome plugin. I managed to get the basic decoding of my local TETRA to work using the SDR# version 1920 together with the TETRA Demodulator plugin from the "SDR# Community Plugin Package (maintained by Rodrig Pérez)" on the SDR# and Airspy Downloads - AIRSPY page. All this on Windows 11. Voice decoding works great. I have some problems opening the latest TTT version (1.8.9.0), got some error with mswinsck.ocx missing. This seems related to Windows 11 and missing older libraries. But it tracks calls on the four channels in SDR# anyway.

I also have one problem with the Demodulator that I can't find a solution for. The plugin sometimes crashes the SDR# instance and I think this has to do with text encoding in certain frames. The error log looks like this:

'iso-8859-2' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name') at System.Private.CoreLib.dll.EncodingTable.InternalGetCodePageFromName (IL offset: 0x109) at System.Private.CoreLib.dll.EncodingTable.GetCodePageFromName (IL offset: 0x21) at System.Private.CoreLib.dll.Encoding.GetEncoding (IL offset: 0xf) at SDRSharp.Tetra.dll.SdsParser.ParseTextMessage (IL offset: 0xa8) at SDRSharp.Tetra.dll.SdsParser.ParseSDS (IL offset: 0x102) at SDRSharp.Tetra.dll.MleLevel.ParseCMCEPDU (IL offset: 0x13a) at SDRSharp.Tetra.dll.LlcLevel.Parse (IL offset: 0x5a) at SDRSharp.Tetra.dll.MacLevel.MacEndPDU (IL offset: 0xb5) at SDRSharp.Tetra.dll.MacLevel.TmoParseMacPDU (IL offset: 0xa7) at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x82d) at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0x166) at System.Private.CoreLib.dll.Thread.StartCallback (IL offset: 0xe)

As I see the pushes on main for GitHub it seems like this bug might have been fixed in a later build. I tried to build from source but failed (not that good in Windows compiling). Perhaps the community package will be updated as well on a new release of this plugin.

 

[thewraith2008]

What version are you using of the plug-in?
I don't think the one in the "SDR# Community Plugin Package" is the same as what is released here.

The error is from a SDS message PDU.
Try the plug-in that is in the latest TTT package and see if you still get the "'iso-8859-2' is not a supported encoding name" error.

I have some problems opening the latest TTT version (1.8.9.0), got some error with mswinsck.ocx missing.

I've not tried the TETRA demodulator plug-in or TTT in Windows 8,10,11 myself.
The documentation for TTT/Plug-in explains how the mswinsck.ocx file is installed. Whether that works for Windows 11 I'm not sure but you could try.

As I see the pushes on main for GitHub it seems like this bug might have been fixed in a later build. I tried to build from source but failed (not that good in Windows compiling). Perhaps the community package will be updated as well on a new release of this plugin.

I don't know what you are looking at here but it has nothing to do with this TTT/plug-in.

I would not use any of the plug-ins that come in the community package as there are generally stale old versions that have been 'patched' to work only for newer SDR# versions. If they do contain newer versions, they have stripped out the documentation that tells you how to install and use them.



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[loffa]

What version are you using of the plug-in?
I don't think the one in the "SDR# Community Plugin Package" is the same as what is released here.

It was not the same version. After the pointers in here I have now tried to get this setup the correct way. I installed TTT 1.8.9.0, and the Demodulator plugin from the same release. With this release of the tetradec.dll I get no sound output from the SDR# side when listening on calls. I get the beep from TTT but no sound is played on the decoded call. I also see that SDR# unmutes the speaker and jumps to the call on the Voice timeslot. Could this be a player/sound problem related to the version of the tetradec? I see that the community version I tested before had a tetraVoiceDec.dll instead so might be working differently. Just tell me if you need any more info to debug this. I will try some different stuff on my end as well.

With recording on (standard settings without VC) I get no WAV files produced in the output folder either. So might be related to the same thing.

The error is from a SDS message PDU.
Try the plug-in that is in the latest TTT package and see if you still get the "'iso-8859-2' is not a supported encoding name" error.

With this plugin installed it solved the problem with loading of the encoding name. I no longer experience crashes. Yay!

I've not tried the TETRA demodulator plug-in or TTT in Windows 8,10,11 myself.

This is why I wanted to see if it was possible to set up on my side. To have a baseline for working on Windows 11.

The documentation for TTT/Plug-in explains how the mswinsck.ocx file is installed. Whether that works for Windows 11 I'm not sure but you could try.

Thanks, I must have skipped that bit in the docs. Fixed now

I don't know what you are looking at here but it has nothing to do with this TTT/plug-in.

I was looking at this GitHub page. I think this is the plugin that was used in the Community Package. It might be different from the one you are providing. The latest Merge Request on there should fix the encoding crashes for that plugin.

Thanks for taking your time to respond. I will have a secondary RTL-SDR dongle coming shortly to test using the Dual mode as described in the documentation. For now I will use Single mode.

 

[thewraith2008]

The TETRA plug-in was updated to use SDR# v1716 at time of active development.
I would recommend using SDR# v1716 version (which is still available for DL from the Airspy webpage) when using TTT + plug-in.

While it did work with newer versions of SDR#, I have not done much in the way of testing them since SDR# lost it's way from v1716 and I could not stand using those painful versions. I hear v1920 is better but if I try that version it just crashes.
SDR# v1919+ as seen some major changes to the audio chain (among other things) and could be the reason for the no audio condition.

Until I can get time to figure out why SDR# v1920 does not work and then work out why the plug-in does not produce audio with it, things will remain the same for the time been with it.

I don't know if people have used TTT + plug-in with Windows 11 successfully and what SDR# versions they used.
Hopefully someone can chime in to verify success or failure and at least you will know if it has been done or not.

That GitHub is unrelated to what is released here which is considerable more updated than that is.
That version is from some old version of Vasili's that has had the copyright/credits stripped the from the code. (DON'T USE IT)



Latest version (v1.8.9.0) can be found here: MEGA - Download (Currently Off-line) - see post #2200 for alternative DL location
see post 2202 for other information about this.

 

[Fredo68]

I successfully use TTT 1.8.9.0 with Win11 Pro and SDR# 1716. Also had the audio problem in latest versions of SDR# so simply reverted to the known working version. Whether any versions between 1716 and 1920 also work, I can't answer

 

[mrscanner2008]

I successfully use TTT 1.8.9.0 with Win11 entreprise 23H2 with SDR# 1716