FM Noise Squelch

[sblandford]

Feature description
FM transceivers often use the audio noise level rather than the RSSI level as a squelch trigger. This is able to let through weak signals with fluctuating signal levels (e.g. mobile or portable users) more consistently than a traditional RSSI squelch.

https://en.wikipedia.org/wiki/Squelch#:~:text=The%20squelch%20control%20adjusts%20the,turns%20the%20receiver%20audio%20off.

Target audience
Anyone using OpenWebRx to listen to NBFM communications on CB, 10m, VHF/UHF, PMR446 etc

[jketterl]

Do you have an implementation of such a squelch?

This will require special cases for the FM demodulator chain, given that this type of squelch only works after the actual demodulator, it means that the current position of the squelch would not work for FM any more. I'm not very keen on making such exceptions since they mean additional complexity for the base chains.

Also, how would this integrate with the existing squelch control?

Also, fluctuating signal level should not be a problem for our current squelch implementation. The squelch should be set in reference to the noise level. That means that the squelch will only activate when the fluctuation cause the signal to drop below the threshold, which should generally also be the point where it becomes unreadable. As such, I don't expect a significant improvement for the given use case.

[sblandford]

I have built noise squelches in hardware many years ago but haven't found an open-source code implementation as of yet. It seems to be the very common hardware feature that software forgot! I will keep searching.

Usually, the demodulated audio is passed through a high pass filter above about 4KHz and the high-passed audio is used as a trigger for a gate.

Fluctuating signals are definitely a problem for the current RSSI squelch. I am finding that weak signals, which are otherwise audible, get lost in the hysteresis gap, which is why I raised this enhancement request. I am guessing that reducing the hysteresis gap would probably cause the squelch to start chattering.

FM mode is probably the most likely time a squelch would be used because the empty channel noise is so harsh. It is less likely to be used on any other mode except AM, which can also be triggered by the FM noise squelch, as it is on some CB/10m transceivers, since an AM carrier also has a quieting effect on an FM detector. On SSB and other modes the squelch is rarely used so the slider could recall a different position for RSSI mode.

A noise squelch works well enough not to even need a slider, if that helps. Most walkie-talkies I've seen recently have a setting somewhere in the menus but once set it is usually forgotten. So a simple on/off switch in the UI is probably all that is needed. In that case the RSSI squelch can be left intact as an additional squelch.

I found some discussion on various WebSDR squelch options here...

https://www.pa3fwm.nl/technotes/tn16e.html, although I don't think he released the source code.

[jketterl]

There's a big problem with that suggested implementation... The WFM demodulator runs at a sample rate of 8-12kHz, depending on the client audio sample rate. That means that if you apply a high-pass at 4kHz, you'll end up with basically nothing left in the worst case. There should also not be a lot of audio in that frequency range to trigger anything (typical transmissions range from 0-3kHz).

Not using the squelch slider in the frontend requires even more special handling for this implemenation.

websdr does not share any sources, no.

In general, I'd say this is a lot of effort, with little added value.

[sblandford]

I usually switch off the RSSI squelch because I know I will be missing a lot of readable signals. I think most people using NBFM receivers with only and RSSI squelch end up doing this. So to me it is definitely worth having a better squelch that I can use.

I appreciate that the UI changes and code changes are not trivial and this feature would need a lot more support to be worth anyone else investing time in. As far as I can tell, I am the first one to have raised this request.

I will have a look at the csdr project and see what would be involved. It would be a good learning experience for me :)

The HPF doesn't have to be 4KHz since most NBFM audio is with a 2.5KHz baseband. It should still be possible to get a useful level difference between an open channel and voice if the HPF cuts at something less than 4KHz.