Add high and low pass filter parameters

[clydebarrow]

This PR adds config parameters (in a channel spec) for high and low-pass filtering of the audio. The defaults are 100-2500Hz. This significantly improves the audio quality by suppressing high frequency noise. Setting the low or high pass values to 0 will replicate current behaviour (automatic selection by Lame) and -1 will disable the filter.

Example config:

  channels:
  (
    {
      freq = 118.1;
      lowpass = 2500;
      highpass = 150;
      outputs: (
        {
          type = "icecast";

[szpajder]

Thanks, merged into unstable branch (this is where the new code lands first).

[starvald]

Handy for filtering out CTCSS.
many thanks.

[Strykar]

Woot, just got pinged about this, trying it now!

[vitaliy-sk]

@clydebarrow thanks for PR, I tried unstable branch but looks like squelch is working not so good.
Sometimes it open closes a few times per seconds, possibly it caused by the filter?
I used default settings (lowpass = 2500; highpass = 150;)

[clydebarrow]

@vitaliy-sk I've not seen any issues with the squelch. Is it spuriously opening and closing in the presence or absence of signal?

[vitaliy-sk]

@clydebarrow mostly in presence of the signal.

I'll try to play with gain but looks like on master branch I don't have this issue with same config

[szpajder]

Filtering does not affect squelch operation, as it's done way after squelch is performed. Squelch behavior was slightly modified in unstable to fix issue described in #84 (comment) .

[vitaliy-sk]

@szpajder thanks for the clarification

some examples below

https://we.tl/t-cJh0MwE7Sh

maybe it's possible to cherry-pick commits filters to release?

[szpajder]

@vitaliy-sk your recording has a high amount of background noise, which means the reception is weak. If you browse previous issues here on Github, you may notice that people tend to have contradicting expectations on how the squelch should behave when the signal is just above the noise level. Users who primarily use scanning want the squelch to react quickly, otherwise the scanner gets blocked frequently just by fluctuations of the noise level. Whoever uses multichannel mode, prefers the squelch to act lazily in such cases, because they don't want it to open and close too often. So there is no one-size fits-all solution and I'd rather not revert the abovementioned tweak to the squelch algorithm, because blocking the scanner by a lazy squelch is a major inconvenience, while the effect you are describing can in most cases be fixed by using manual squelch feature and setting it a bit lower than what auto squelch would do.

[vitaliy-sk]

@szpajder thanks for the detailed explanation
make sense, the common solution can be smth like squelch_sensitivy or I should just play with gain level

[szpajder]

First of all, check the textual waterfalls (run the program with -f option to see them) and verify if the noise level in your channels is not near zero (noise level is the number after the '/' character in the waterfall). If it's very low (like 1-3), then increase the RTL gain. I typically run my dongles at the noise level between 8 and 13. This is when automatic squelch works best.

If it won't help, then enable manual squelch (see https://github.com/szpajder/RTLSDR-Airband/wiki/Manual-squelch-setting#how-to-find-the-proper-squelch-value). You can go as low with it as you wish, but at some point it will start opening all the time due to noise level fluctuations, so don't overdo it.

[vitaliy-sk]

@szpajder thanks

I played little bit with unstable branch and I guess that the same condition conditions for open and close could be a root cause

// open
fparms->agcavgslow > sqlevel
// close
fparms->agcavgslow < sqlevel

so in case when agcavgslow is near sqlevel it can cause opening and closing squelch few times per seconds.

I tried to collect some example, but it's not so easy to debug.
Silence:

 13/ 12  128.175
  13/ 13  127.725
  13/ 13  127.725
  12/ 13  124.675
  13/ 13  124.675
  14/ 14  122.775
  16/ 14  122.775
  15/ 16  125.300
  13/ 13  125.300
  23/ 36  123.450
  15/ 18  123.450
  15/ 12  128.175 

Transimition

Apr  4 23:01:33 raspberrypi rtl_airband[26239]: [ ] fparms->agcavgslow: 31.825272 sqlevel: 36.673882 diff: 4.848610
....
Apr  4 23:01:33 raspberrypi rtl_airband[26239]: [ ] fparms->agcavgslow: 36.789024 sqlevel: 36.674179 diff: -0.114845
Apr  4 23:01:33 raspberrypi rtl_airband[26239]: Open 122.775
Apr  4 23:01:33 raspberrypi rtl_airband[26239]: -> fparms->agcavgslow: 36.789024 sqlevel: 36.674179 diff: -0.114845
Apr  4 23:01:33 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 36.970989 sqlevel: 36.674484 diff: -0.296505
...
Apr  4 23:01:33 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 41.113571 sqlevel: 36.674782 diff: -4.438789
...
...
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 37.142056 sqlevel: 37.013901 diff: -0.128155
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 37.066639 sqlevel: 37.013901 diff: -0.052738
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 37.041813 sqlevel: 37.013901 diff: -0.027912
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [*] fparms->agcavgslow: 36.779022 sqlevel: 37.013901 diff: 0.234879
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: Close 122.775
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: <- fparms->agcavgslow: 36.779022 sqlevel: 37.013901 diff: 0.234879
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [ ] fparms->agcavgslow: 36.619549 sqlevel: 37.013901 diff: 0.394352
Apr  4 23:01:35 raspberrypi rtl_airband[26239]: [ ] fparms->agcavgslow: 36.360310 sqlevel: 37.013901 diff: 0.653591

float diff = (sqlevel - fparms->agcavgslow);

[szpajder]

So could you please modify this line in rtl_airband.cpp: ```C if ((channel->agcsq == -1 && fparms->agcavgslow < sqlevel) || fparms->agclow == AGC_EXTRA - 12) { ``` to something like: ```C if ((channel->agcsq == -1 && fparms->agcavgslow < 0.8f * sqlevel) || fparms->agclow == AGC_EXTRA - 12) { ``` and verify if it works any better? Thanks in advance.

[vitaliy-sk]

@szpajder I tried it's working slightly better, but issue still present

then I removed channel->agcsq == -1 && fparms->agcavgslow < sqlevel and it work much more better.
I capture some logs for undestand which real value of agcavgslow when the close logic based only on this condition fparms->agclow == AGC_EXTRA - 12 and I see in some cases the ratio agcavgslow / sqlevel is < 0.6.

Few minutes record with log (without channel->agcsq == -1 && fparms->agcavgslow < sqlevel): https://we.tl/t-Q6HfH4TnCo