TetraNetMonitor UI Experimentation

[N6ML]

I've been playing with TNM a bit, along with a couple of others in my region. We're all experiencing intermittent (unusable) choppy audio. I'm not convinced that it has to do with selecting a weak voice channel, as I'm experiencing it even when a strong channel is selected. In my experience, it seems less severe with less control channels enabled simultaneously, and it has the feeling of some sort of contention leading to a buffer underflow (or something along those lines). It sounds a bit like Skype on a really bad internet connection.

Something else has me a bit perplexed... I'm using an Airspy Mini. I have calibrated it against a DAB signal. Once I did this, the TETRA signals seem "perfectly" aligned on the waterfall. The TTT Demodulator shows a low FER - around 20Hz. The confusing thing is that the TNM plugin's "remote" window shows high MER and BER rates if AFC is disabled. If I undisable AFC, after a second or two, it shows FER around 1500Hz, and the MER and BER drop to 0. It appears that the TNM demodulator is somehow ~1500Hz off frequency. I'm not sure that this is the cause of the audio choppiness, but I'd like to understand what's going on. Ideas? Note; I don't normally run both plugins in the same SDR# instance - this is just to demonstrate the problem, and rule out any config discrepancies between instances

 

[thewraith2008]

It may have something to do with newer versions of SDR#. (i.e. smaller audio buffers)
TNM+plug-in where built around SDR# v1716, try that version and see if you still see the issue.

I don't use SDR# versions greater than v1716 and I no longer have TETRA to monitor so I don't really have any interest in figuring out why there is an issue with it.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[N6ML]

It may have something to do with newer versions of SDR#. (i.e. smaller audio buffers)
TNM+plug-in where built around SDR# v1716, try that version and see if you still see the issue.

I don't use SDR# versions greater than v1716 and I no longer have TETRA to monitor so I don't really have any interest in figuring out why there is an issue with it.

Totally understand on the motivation being gone. It's a shame, as we see so much potential in TNM! Thanks for sharing it with us anyway!

I still see the FER anomaly with v1716. I'll run it for a while and see how it sounds (limited non-encrypted traffic, so it can take some time to evaluate). My concern with the frequency offset is that (I think) the floating decoder will have to apply AFC every time it gets used, which seems to take 1-2 seconds, so the start of messages (except those on the MCCH carrier) can be a bit broken.

 

[thewraith2008]

The demodulator used in TNM is a little bit different to the one in TTT.
I remember TNM would strangely and randomly lose sync or something like that on strong signals.
Switching it on/off would fix it until it decided to play up again.
It's why I never updated TTT to use it as I thought it was flakey.

You could also try changing the SDR# audio latency (lower I think) and see if that helps (default is 100?)
Again, that may only work with SDR# v1716.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[N6ML]

The default audio latency is 50ms. I don't understand what that setting actually does. The SDR# manual is not helping me - "The latency value (expressed in milliseconds) is the time that elapses between the analog-to-digital conversion of the input signal, its processing and the digital-to-analog reconversion at the output.". That doesn't make sense to me - I can't just specify how long those conversions will take(?).

In general, I don't have a clear understanding of the data flow here. It appears that audio is actually output by the TetraNetMonitor.exe process, and not by SDR#, so I assume it must be transferred from the plugins to TNM over IP? If multiple MCCH carriers are receiving simultaneously, does all of that data from all carries get sent to TNM, and TNM decides which one to output? Maybe there's some contention there.

I'll continue experimenting and trying to look for patterns...

 

[thewraith2008]

Latency is just the time between receiving and hearing the audio.
A higher SDR# latency value uses larger buffer which takes more time to fill and process hence the delay.

Yes, TNM does not use SDR# audio path so changing the latency value is not going to have any affect here. (it would for TTT).

Have you tried TTT for comparison?



Latest version (v1.1.2.1) can be found in this post here: Download

 

[N6ML]

TTT works quite well ... but TNM also works quite well if it's limited to just one control channel. I'm still looking for patterns in circumstances when the problem occurs - e.g. does it only occur when multiple calls (on different carriers) are seen simultaneously? Or does it still occur when there are multiple control channels, but only one of them has an active call at the time? This is a bit tricky, as I have to "catch it in the act" to find out. One thing that would be really really helpful, should you ever find yourself back in the code, would be to log every call seen (at least the non-encrypted ones) in the event log - currently it only logs the one that gets chosen to be played. That way, I could review past recordings and try to correlate audio quality to circumstances. It'd also be super-useful in building knowledge about which talkgroups are often seen on which control channels.

 

[Abyzz42]

@thewraith2008 , Just to add my interest to seeing TNM given a little update when you have the time to do so.
I'd love to see the addition of a volume control ( similar to TTT ) to increase the volume of the outputted decoded audio, or even a way to choose within the TNM itself where the audio gets routed to ( like a virtual cable for example )

Is there a reason why the demodulator in TTT is different from TNM?

Thanks again for some wonderful plugins 👌

 

[N6ML]

I'd love to see the addition of a volume control ( similar to TTT ) to increase the volume of the outputted decoded audio, or even a way to choose within the TNM itself where the audio gets routed to ( like a virtual cable for example )

A bit of audio level boost would be nice. FWIW, you can tell Windows where to send the audio from individual apps. Right-click on the speaker icon on your task bar, select "Open volume mixer", find the "Tetra Network Monitor" app, expand it, and select your virtual cable as the "Output device". You'll need to relaunch TNM for it to take effect. Credit to @digiman1 for pointing out (to me) that this is possible.

 

[thewraith2008]

@thewraith2008
I'd love to see the addition of a volume control ( similar to TTT ) to increase the volume of the outputted decoded audio, or even a way to choose within the TNM itself where the audio gets routed to ( like a virtual cable for example )

It's been awhile since I've used TNM and programmed it.
I know that the audio level is low but strangely NAudio does not seem to have a way to apply any gain to the voice buffer that I can see.
I guess gain could be applied to the buffer manually, it's just I've not really got around to trying it out.

Is there a reason why the demodulator in TTT is different from TNM?

It was a different development path.
I forget where all the differences where with it, but I know burst synchronization was a main one. (for TMN)

• As stated before, sometimes the plug-in would lose SYNC (or be choppy) on a otherwise good signal.
• Also, there is a problem where TMO is sometimes seen as DMO and because DMO is not really implemented/supported by TNM, it would crash in a horrible way.

I have removed the DMO auto detection in a test version of TNM for a user that was repeatedly seeing this problem.
It was strange this issue as no one else ever reported having this issue before.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[pingirona]

"I have removed the DMO auto detection in a test version of TNM for a user that was repeatedly seeing this problem.
It was strange this issue as no one else ever reported having this issue before."

Hello, I would like to be able to try this version of TNM, since I think the same thing is happening to me. Would it be possible to receive a download link?

Thank you

 

[thewraith2008]

You will find that change available in the latest download.



Latest version (v1.1.2.5) can be found in this post here: Download

 

[pingirona]

You will find that change available in the latest download.



Latest version (v1.1.2.5) can be found in this post here: Download

Thank you very much for your help and quick response. I'm going to install it right now.

 

[duzjak]

Hello, have you ever thought about changing the project to open-source and releasing the code? I think TetraNetMonitor is a great program, competing with other Linux programs, and it's a shame that it's no longer being enriched with new features. Perhaps there would be someone interested in adding features such as saving audio recordings, or maybe even recording multiple concurrent calls at once Anyway, thank you very much for this program, it's perhaps the only usable one on Windows that can scan multiple channels simultaneously.