Squelch usability improvements

[tmiw]

This PR contains the following:

1. Adds an additional decimal place to the current SNR to avoid confusion when signals are near squelch level (resolves https://github.com/drowe67/codec2/issues/238).
2. In multi-RX mode, per-mode squelch levels are now relative to the mode that can support the weakest signals (currently 700D). For example, setting the squelch to -2.0dB will result in the application telling Codec2 to set 700E's squelch to 1.0dB instead. This is because the minimum SNR for 700D is -2.0dB while the minimum for 700E is 1.0dB per the specs. As a result, blips and unwanted false decodes are dramatically reduced in multi-RX mode.

[Tyrbiter]

SNR now starts off reading 0.0 at program open, once the modem is started it goes back to reading in whole dB increments, there is no decimal point or 0.1dB shown. SNR sits at -4dB, it jumps typically to 0dB and with squelch set at -0.5dB in 700E mode there is still quite a lot of short audio false decodes appearing in my headphones.

I have multi-rx multi-thread enabled.

Edit: scratch that, the git checkout of the squelch-ux had an error and I built the wrong thing. Now testing with a correctly built version. Sorry for the noise.

[Tyrbiter]

I'm uncertain about the squelch level changes, at least about the labelling aspect. I wonder whether it would be better if a 0dB squelch setting translated into the lowest spec'd SNR for the mode. That way the - and + adjustment is clearer about what is being done, as it stands I find it confusing. More thoughts on this would be sensible, it could just be that I am in a minority of 1.

[tmiw]

I'm uncertain about the squelch level changes, at least about the labelling aspect. I wonder whether it would be better if a 0dB squelch setting translated into the lowest spec'd SNR for the mode. That way the - and + adjustment is clearer about what is being done, as it stands I find it confusing. More thoughts on this would be sensible, it could just be that I am in a minority of 1.

I'm not sure how doing that would impact those with multi-RX off. At least with the current approach, the squelch setting works the same as it always has except when multi-RX is on. @drowe67, any thoughts on this?

[Tyrbiter]

I think changing to a +/- display would help under all circumstances. I don't think most people want to have to change the squelch setting with mode. I don't know if this is currently remembered by mode, I usually have multi-rx enabled. Previously I spent a lot of time fiddling with the squelch setting, the new calculation of SNR/squelch interaction is great for suppressing the false decodes, it's just the labelling I am having difficulty with.

Perhaps displaying the offset to actual squelch SNR when not using multi-rx? It doesn't make sense when multi-rx is on of course. And call the setting squelch offset? Naturally this would need some explanation in the user manual.

[drowe67]

I'm uncertain about the squelch level changes, at least about the labelling aspect. I wonder whether it would be better if a 0dB squelch setting translated into the lowest spec'd SNR for the mode. That way the - and + adjustment is clearer about what is being done, as it stands I find it confusing. More thoughts on this would be sensible, it could just be that I am in a minority of 1.

I'm not sure how doing that would impact those with multi-RX off. At least with the current approach, the squelch setting works the same as it always has except when multi-RX is on. @drowe67, any thoughts on this?

Nope, but maybe let a few people try a test release and see how they go.

[tmiw]

Nope, but maybe let a few people try a test release and see how they go.

Hmm, should #184 and #187 be merged before I do that? Both have fixes for build errors on Windows and macOS.

[tmiw]

Merged this and #189 into v1.6.2-test to make test build generation easier. Should have something out tonight for initial testing hopefully.

[Tyrbiter]

Built this and running it on Fedora 35, seems to be essentially identical to my local hacked build. Certainly ready for wider testing.

[tmiw]

@drowe67, I haven't heard any issues with this change so we can probably review/merge this PR now.

[drowe67]

This table could be a freedv_api.h getter type function, ie a property returned by the FreeDV API. But that would mean a codec2 PR so not really necessary right now 🙂

[drowe67]

Looks good @tmiw and it sounds like it's working for end users. Pls feel to merge when you are ready.

Is there anything about the operation of this feature that end users should know about, e.g. by a comment in the manual? Or do you feel it's operation is transparent?

[tmiw]

Is there anything about the operation of this feature that end users should know about, e.g. by a comment in the manual? Or do you feel it's operation is transparent?

Operation should be transparent but I added some info on how it works to the manual.