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.

 

[enCrypt]

Just wanted to state after upgrading to the new version (v1.1.2.5) my installation is much more stable now. Using alongside SDR#1716 the "Received" on the plugins are no longer flashing / unstable looking and the audio seems a bit less broken, still happens a bit though.
All in all seems like a good upgrade, thanks

 

[pingirona]

For whatever reason, calls on TETRA are just drop with no indication (no PDUs of any kind are used).
Because no D_Release PDU is seen, the call will normally just hangs there.
It will sit there until a D_Release PDU seen probably from another (unrelated) call. (or possibly until a different usage marker seen, I forget)

The addition of detecting when slot becomes unallocated is an attempt to end the call and return to MCCH.
This may not always work and may depend on what the TS is outputting (may still be sending something that indicates it's still been allocated).

Can something be done about it, I don't know as I don't really have any interest in TTT/TMN anymore.
Maybe a sample of this occurring could help.



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

Hello

I just saved an IQ file where the problem is reproduced.
I am aware that you are not interested in Tetra development at the moment, but I think the community would really appreciate it if you fixed this bug, because quite a few calls are lost and the only alternative is to "disable alternative calls" and then the code is horrible. Calls from blocked groups that the system interprets as "private" get in, to give just one example. A chaos.

I am going to send you information with all the data privately, to try to make the job as easy as possible and I hope you grant us the wish to fix it. Thank you very much in advance.

 

[tomekjkp]

Hi, has anyone had a problem that after starting the computer and launching the application, no tuners are displayed and it does not collect data? It is also not possible to control it via remote start. I have already tried Tetra Network Monitor 1.1.2.1 and 1.1.2.5
I have tried SDRSharp from 1666 to 1727 and nothing, not even a twitch, before everything worked normally

 

[FR33MAN]

Hi, has anyone had a problem that after starting the computer and launching the application, no tuners are displayed and it does not collect data? It is also not possible to control it via remote start. I have already tried Tetra Network Monitor 1.1.2.1 and 1.1.2.5
I have tried SDRSharp from 1666 to 1727 and nothing, not even a twitch, before everything worked normally

View attachment 165283

Hello, sorry for the question, apart from running the TNM, do you have the TNM Plugin installed and several magic lines created? I would take it for granted but better confirm it for me.

 

[tomekjkp]

Yes, of course I have

 

[FR33MAN]

Yes, of course I have
View attachment 165284

Ok, I see that you have created the lines, I also tell you that you create more than two, since line 2 is used for tracking, in my case the use is deactivated after a short time. Well, at first glance I don't see the problem, you should show me if you have the dlls inside sharp and see how you activate the TNM puglin and hit set on top of a carrier so that it attaches to it.