SDR# TETRA Demodulator Trunk Tracking Demonstration

[Ubbe]

My limited guess is that either it's hitting some sort of memory leak after being open that long or there's some conflict with both radios running on the two USBs and at some point they cause issues.

I have a MSI.SDR, a RSP1 clone, connected and cannot remember if I used to have that disconnected and used the same USB connector as the RTL-SDR. Maybe that could be my issue that they collide somehow when having them both connected. I'll try and pull that MSI out and see what happens.

/Ubbe

 

[Skowt]

I have a MSI.SDR, a RSP1 clone, connected and cannot remember if I used to have that disconnected and used the same USB connector as the RTL-SDR. Maybe that could be my issue that they collide somehow when having them both connected. I'll try and pull that MSI out and see what happens.

/Ubbe

Yeah I thought maybe there was some sort of conflict but considering that in certain scenarios it works for 24 hours or longer without issue and gradually gets more delayed, I suspect it's some sort of memory leak or weird build up that's slowing down updates to the SDR.

I'm trying to find a solution that lets me prioritize certain frequencies the way TTT does but that I can use in a more automated set up (e.g. on a Raspberry Pi). Right now I'm running this set up on a Windows machine with two SDR# instances and TTT.

 

[thewraith2008]

If the issue you describe is the one I'm thinking of, this was a problem when a call to change frequency (in the RTL driver) was failing.
The default SDR# RTL frontend is very simple and does not check that the frequency change was successful, the SDR# VFO would show the expected frequency but the spectrum display was not right and did not update or was slow to update.

This became worse if further calls where made before the failed call had returned, which was really slow to return.
This normally resulted in a crash/hang if you tried to do something in SDR# before the call returned.

I'm sure this was the thread that had a better working version of the RTL driver which may have fixed some of the problems people saw. (I never tried this one myself)
NOTE: Not sure if it ever got updated for the newer v4 RTL-SDR.COM dongles.



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

 

[Skowt]

If the issue you describe is the one I'm thinking of, this was a problem when a call to change frequency (in the RTL driver) was failing.
The default SDR# RTL frontend is very simple and does not check that the frequency change was successful, the SDR# VFO would show the expected frequency but the spectrum display was not right and did not update or was slow to update.

This became worse if further calls where made before the failed call had returned, which was really slow to return.
This normally resulted in a crash/hang if you tried to do something in SDR# before the call returned.

I'm sure this was the thread that had a better working version of the RTL driver which may have fixed some of the problems people saw. (I never tried this one myself)
NOTE: Not sure if it ever got updated for the newer v4 RTL-SDR.COM dongles.



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

You are 100% correct. That link helped perfectly and I'm no longer having issues. Damn, that's so good. I've been living with this problem for far too long. Thanks!

 

[Dax50]

@thewraith2008 is it possible to include the following feature:
Output of the raw Control Bits?
Or is it possible to connect to the sdr# Plugin socket to get the raw Bits?

 

[thewraith2008]

No I don't think so.

I think the last Vasili version may have been able to output some data stream but I have no idea what that data was.
Was it symbols, dibits and was it before or after channel coding?



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

 

[Dax50]

No I don't think so.

I think the last Vasili version may have been able to output some data stream but I have no idea what that data was.
Was it symbols, dibits and was it before or after channel coding?



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

Yeah the latest Version Show the burst, but not the Bits.
Unfortunately, the source code is not publicly available

 

[thewraith2008]

Here is an open sourced project Telive.

It's for Linux but I sure the main parts like demod, symbol timing, framing and channel coding could be used to make something work in Windows to achieve whatever your trying to do.

 

[Dax50]

Here is an open sourced project Telive.

It's for Linux but I sure the main parts like demod, symbol timing, framing and channel coding could be used to make something work in Windows to achieve whatever your trying to do.

Do you have the latest SDR# Plugin Sourcecode?
If yes I can add some more function.

 

[thewraith2008]

Yes I do and it's not available as open source.

What are you looking for it to do that it currently doesn't?

 

[Dax50]

Yes I do and it's not available as open source.

What are you looking for it to do that it currently doesn't?

I would like to add a Wireshark Interface for the Type1 bits. So sending them as GSMTap Messages over an socket and receiving them in Wireshark. I have a working class for this. Maybe you can add it
As an alternative I would like to See the Type1 bits in the Burst Section.

 

[MechanicVV]

Good afternoon. I'm asking for help. I want to test the TETRA plugin, please upload any TETRA encoded file here.

 

[MechanicVV]

Thanks to everyone who responded. I configured the plugin as in the manual, but there is no sound output to the speaker. Can you tell me how to fix the problem?

 

[Ubbe]

That's probably my fault, the file doesn't cover the whole frequency spectra necessary to run TTT.
I got a new file for you.

First run only SDR# and turn up the volume slider and you should hear the digital audio.
Then click the Demodulator box in the TETRA Demodulator section and it should mute and only have the voice audio of any call slot you select.
Then the audio setup works.

Run TTT and it should jump to the control channel frequency when you select a carrier in SDR# and jump to other frequencies to track calls.

/Ubbe

 

[CqDx]

I seem to have the same issue.
Did try both recording methods, also switched between MME and Windows Device, but still no joy.

I have it running on several other PC's, made sure all settings are the same, but I still get the #5 error.
Did anyone manage to solve it?

@thewraith2008
Any idea what sample rate TTT is referring to?

Many thanks.

Same issue for me. I am using both V1920 and V1830 of SDRSharp with Virtual Audio Cable and VB-Audio.
TTT works fine when recording mode is not on, but when I switch on Recording, I get the dreaded "#5: The specified parameter is out of range for the specified command. Error (samples/sec)"

 

[VK3YMML]

Hi all
We have the Australian Grand Prix only a few months away in Melbourne, Australia and a number of the teams use Tetra Radio systems. I have read most of the postings but cannot find a link to download the plugin, all of them are showing as being offline. Any assistance would be greatly appreciated.

 

[Ubbe]

The link from NVE are still working.

SDR# - TETRA Demodulator Trunk Tracking Demonstration

1.8.9, in my case it does not crash on startup, just got no sound when using the plugin. Log: 5/8/23 ; 20:52:25.583 ; 260 ; 2101 ; 5 ; 5 ; 3612 ; 3 ; 534 ; -error! 5/8/23 ; 20:52:29.880 ; 260 ; 2101 ; 5 ; 5 ; 3612 ; 3 ; 534 ; -error! 5/8/23 ; 20:52:33.440 ; 260 ; 2101 ; 5 ; 5 ; 3612 ; 3 ; 537 ...

forums.radioreference.com

/Ubbe

 

[MechanicVV]

Tetra
Wayback Machine