SDR# TETRA Demodulator Trunk Tracking Demonstration

[hamradionl]

VLC player works fine for me.

I just try that, the WAV file have no audio.
Do you use Virtual Cable?

 

[causeway74]

I just try that, the WAV file have no audio.
Do you use Virtual Cable?

I had the same issue which was due to file path being too long. I moved TTT to C:\tools and things started working.

 

[hamradionl]

causeway74,
Okeee thank you for advice and you found out,
i dont like these programs in the main root map/directory, but i will try your advice to put the recording log in to root.
I also dont understand what a long install path have to do with fact the audio is not working. For last 25 years iam using PC, never have this issue before (btw i do lots of MiDi music with Terra bytes music files using long path )

thewraith2008
Did you know this?
Why the audio record log file need to be in root?
Why is this not in the manual?

.

 

[causeway74]

causeway74,
Okeee thank you for advice and you found out,
i dont like these programs in the main root map/directory, but i will try your advice to put the recording log in to root.
I also dont understand what a long install path have to do with fact the audio is not working. For last 25 years iam using PC, never have this issue before (btw i do lots of MiDi music with Terra bytes music files using long path )

This isn't a tool issue, it was where I was storing the tools. The path to the recording directory in my case was too long (windows limit). Because of path length it seems to block the saving of the file. It may be something completely different for you though, I'm just sharing my experience.

 

[hamradionl]

causeway74,
Fully understand, thank you.
i try pointing the log files saving go to root map C:\record\,
but seem not possible TTT keep using the map "C:\\.......\\daily" in his own TTT map/directory
Seem i need to copy the whole TTT program to root map/directory, what i not going to do.

 

[slicerwizard]

I also dont understand what a long install path have to do with fact the audio is not working. For last 25 years iam using PC, never have this issue before (btw i do lots of MiDi music with Terra bytes music files using long path )

thewraith2008
Did you know this?
Why the audio record log file need to be in root?
Why is this not in the manual?

.

Are you positive that it's a path length issue? How do you know it's not something else, like spaces in the path name?

 

[hamradionl]

slicerwizard
- Read the post from causeway74 he mention this matter
- because i have no spaces in the path name
And otherhand, if there are spaces that should not be a reason using win10

 

[thewraith2008]

Whitespace should not be a problem in the path.
Filenames (for logs and WAVs) are not created with whitespace.

There is a max WIN32 path length (260) limitation (mentioned a few months back) for the creation of files.
The max path length for the WAV files is further restricted to a path length of 117. This is a limitation in the old MCI API.

e.g. "C:\sdr\.......\TTT\Daily\Record\"
This path (including all characters) between quotes must not be longer than 117.

Errors from MCI should be shown in the status panel (above 'Call details')



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

 

[tsapers]

Howdy all

Have you seen this before?
I seem to not get it on the v1.0.14 release with its related plugins, once I go to v1.0.15+ it starts doing this.
Best I can describe is that SDR# "pauses" for a second. As can be seen from the screen grab at that point CPU spikes and then returns to the normal sub 10% for SDR#. Look at the Diagram and the SDRSharp.exe
This of course has an effect on the decode and voice output.
Disabling the plugin (Demodulator) in SDR# has no effect, even stopping the SDR dongle in SDR# has no effect. The processing remains the same.
Only option is to close SDR# and rerun. On the specific signal I have a SNR of around 34 and 100% Receive in the Demodulator, except when it jumps to a new frequency where I see a slight drop to high 80%\low 90%.

I have been running v1.0.14 now for a few days without this issue. Previously when testing with v1.0.15 versions it would happen, within minutes\hours\max within a day.

I have tried a clean install of SDR# and then upgrading directly to the latest TTT release with the same results. Have also tried SDR# version 1660 and 1700.

 

[thewraith2008]

Howdy all

Have you seen this before?
I seem to not get it on the v1.0.14 release with its related plugins, once I go to v1.0.15+ it starts doing this.
Best I can describe is that SDR# "pauses" for a second. As can be seen from the screen grab at that point CPU spikes and then returns to the normal sub 10% for SDR#. Look at the Diagram and the SDRSharp.exe
This of course has an effect on the decode and voice output.
Disabling the plugin (Demodulator) in SDR# has no effect, even stopping the SDR dongle in SDR# has no effect. The processing remains the same.
Only option is to close SDR# and rerun. On the specific signal I have a SNR of around 34 and 100% Receive in the Demodulator, except when it jumps to a new frequency where I see a slight drop to high 80%\low 90%.

I have been running v1.0.14 now for a few days without this issue. Previously when testing with v1.0.15 versions it would happen, within minutes\hours\max within a day.

I have tried a clean install of SDR# and then upgrading directly to the latest TTT release with the same results. Have also tried SDR# version 1660 and 1700.

For me, CPU is 5-13% and Memory is at 71000K

Does this occur straight away after starting (press play) SDR#. No plugin started.
Does this occur straight away after starting (press play) SDR# then starting plug-in.
Does this occur anytime after starting plug-in or when call starts, during call?
Does this occur without TTT started.
When this occurs with SDR#+plugin and TTT started. Does closing TTT make any difference to CPU/RAM of SDR#?
You say stopping plugin and SDR# makes not difference CPU/RAM usage. This seems odd.

What SDR dongle you use?



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

 

[tsapers]

When running normal then CPU <10% with mostly <5%. Memory seems to be between 100 000K and 140 000K

Does this occur straight away after starting (press play) SDR#. No plugin started. NO
Does this occur straight away after starting (press play) SDR# then starting plug-in. NO
Does this occur anytime after starting plug-in or when call starts, during call? Occurs at random times. And then remains. Difficult to say that it starts with a call or during a call.
Does this occur without TTT started. I have not checked, will have to test.
When this occurs with SDR#+plugin and TTT started. Does closing TTT make any difference to CPU/RAM of SDR#? No difference
You say stopping plugin and SDR# makes not difference CPU/RAM usage. This seems odd. Stopping the plugin and stopping the SDR dongle (press STOP) makes no difference in SDR# CPU/mem usage.

What SDR dongle you use? Original RTL SDR V3

Very strange indeed. Was wondering if it might be due to some of the background components. VC Redist? .NET? maybe?

 

[thewraith2008]

@tsapers

... Was wondering if it might be due to some of the background components. VC Redist? .NET? maybe?

Not sure.

There could be some type of runaway condition with the plug-in that is triggered by a combination of things. Configuration of settings, visible tab in 'Network Info' or type of PDUs seen. Since it doesn't happen straight away it will be difficult to pin point.

What is the visible tab in 'Network Info'?
What options you using in the plug-in?
Do you have checked in SDR# > Radio > 'Correct IQ'. If yes, try with it disabled. On occasions I see high CPU usage with this on.



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

 

[tsapers]

What is the visible tab in 'Network Info'?
What options you using in the plug-in?
Do you have checked in SDR# > Radio > 'Correct IQ'. If yes, try with it disabled. On occasions I see high CPU usage with this on.

Visible tab is default and always on "Calls" if I'm understanding the question correctly.
Yes I do run Correct IQ checked. I will test this with it unchecked and will have to let it run and confirm.

Here are my settings:

 

[thewraith2008]

FYI/Clarification:

In TETRA, a group call is set-up via a PDU called 'D-Setup'.
TTT (and TNM) only uses this PDU to setup calls.

There may be occasions where voice traffic can still occur on any of the available timeslots (on any carriers in the currently monitored LA)
TTT/TNM does not play this traffic because there is no 'D-Setup' for it.

This traffic belongs to a call that spans two LAs. see the image.

You can see that there is only one MS on LA:1 that you are monitoring and it starts the call by sending a 'U-Setup' PDU on the uplink.
If the call is granted, the BS sends a 'D-Connect' back to the calling MS on the downlink. There is no 'D-setup' PDU sent on the LA:1
downlink as there are no other MSs on LA:1 at the present time.

The call set-up is sent via the infrastructure received from LA:1 uplink to LA:5 downlink to any MSs that are there (at least one).

On LA:5, The 'D-Setup' is sent on the downlink and all related MSs are set-up on the call on one of the carriers/timeslots on LA:5.

Speech from LA:5 is played on downlink of LA:1 and speech from LA:1 is played on downlink of LA:5.
Speech from LA:1 uplink is not replayed on the downlink of LA:1 because there is no other MSs there.
If there is more than one MS on LA:5 then speech from LA:5 uplink is replayed on the downlink of LA:5.

With this traffic, it will only be one sided. You will not hear the MS on LA:1.

While the PDUs used are slightly different, the same can be seen with private calls.

While TNM can monitor multiple LAs, it does this individually and can not determine if calls on different LAs are connected to each other.
To do so is a case of diminishing returns and the code only supports listening to one tuner at a time anyway.



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

 

[tsapers]

Anyone running SDRPlay RSP1a on TTT/TNM and see a big improvement compared to the RTL SDR v3?

 

[hamradionl]

Anyone running SDRPlay RSP1a on TTT/TNM and see a big improvement compared to the RTL SDR v3?

SDR#1700 with SDRPlay RSP1a ==> if you know a driver, iam able to test it for you.
SDR# + RTLSDR-V3 using a special driver better selectivity
SDR# + Airspy-mini give improvements better selectivity.
SDR# + PlutoSDR its works but driver little bit unstable

 

[DarkAngelT]

@thewraith2008



Could it be that in the not too distant future we could have a DUAL LISTENING TTT?
Example:
Speaker L: GSSI A
Speaker R: GSSI B
And a volume control for L and other control for R?


Both groups playing at the same time in different speakers!

 

[thewraith2008]

@thewraith2008



Could it be that in the not too distant future we could have a DUAL LISTENING TTT?
Example:
Speaker L: GSSI A
Speaker R: GSSI B
And a volume control for L and other control for R?


Both groups playing at the same time in different speakers!

Probably not, TTT+plug-in is not structured to do this.

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

 

[tsapers]

SDR#1700 with SDRPlay RSP1a ==> if you know a driver, iam able to test it for you.

Thanks, yes I read that RSP's were only supported up to a specific older version of SDR# and then no longer.
Was just wondering if there is much improvement using a RSP or Airspy Mini VS the RTL SDR v3. Is it really worth the extra $ when looking at digital decoding, etc.

 

[hamradionl]

Thanks, yes I read that RSP's were only supported up to a specific older version of SDR# and then no longer.

Yep, and in older SDR# 14xx serie the TTT plugin not working.

Was just wondering if there is much improvement using a RSP or Airspy Mini VS the RTL SDR v3. Is it really worth the extra $ when looking at digital decoding, etc.

In my response number #1,056 i answered your question
Airspy-mini = My opinion is more selective with strong signals nearby
RTLSDR-V3 = you able try the special driver.