Add bandwidth filter

[charlie-foxtrot]

Added a configurable bandwidth filter for NFM signals. Can be set either for single channel or scan mode.

Filter is implemented as a low-pass after de-rotating then checking the average power vs squelch.

The calculation of the filter coefficients is based entirely on a simplification of what is posted here: https://www-users.cs.york.ac.uk/~fisher/mkfilter/

NOTE: Also change the default FFT size to 1024 when NFM is enabled.

[szpajder]

Just testing it on some rail frequencies and I get quite significant sound distortion, even when lowpassing is disabled. Here is an example: https://drive.google.com/drive/folders/1FZQkPvt5agmqZT6eAytmrknrrmfMSOk0?usp=sharing - the same I/Q file demodulated with the current unstable (old.mp3) and the new code (new_no_lowpass.mp3 and new_lowpass3k.mp3).

[charlie-foxtrot]

@szpajder I think the bandwidth in your case should be 8 KHz, or maybe 12.5 KHz? The bandwidth parameter is the channel bandwidth, not the filter frequency (the LowpassFilter is created with a frequency of bandwidth/2).

Looking at your signal, it seems to be at least 8 KHz, but that isn't one of the "standard" bandwidths listed here so maybe its 12.5 KHz 🤷

Running with bandwidth = 8000 on your signal works well, but running with bandwidth not set results in the distortion, will look at it.

[szpajder]

It's a lot better now, however during strong transmissions distortion is still present. It seems that FFT 1024 is too narrow - I reverted it to 512 and then it sounds fine. See the above link, I've put a new example there (the channel frequency is now 150.1 MHz).

[charlie-foxtrot]

@szpajder there seems to be something odd going on in your two recordings and FFTs of 512 and 1024 are behaving differently.

Here are the two recordings:

Both seem to have periods of multiple seconds worth of signals across multiple frequencies coordinated in time.

Using the unstable branch without this PR and comparing FFT of 512 vs 1024 with continuous = true the 512 recording (top) is missing some audio during this period that the 1024 recording (bottom) is picking up. Here is the first iq file:

And the second:

Is this the period of distortion you were talking about? If so, it seems that (although the audio quality isn't good) the 1024 is doing "better". Any idea what these periods of strong multi-channel transmissions are?

[szpajder]

These are spurs caused by some strong digital transmission just outside of the receiver bandwidth. I have plenty of them here, but they are irrelevant to the issue, as the spur occurred in the second half of the recording, while the distorted audio is in the first half (between 4.5 and 9th second on your screenshots).

That initial piece of audio is absent in all three recordings I've shared, which means the squelch didn't open in neither of these cases.

I'd keep the default fft_size at 512 to keep the program behavior unchanged for users that do not wish to enable lowpassing.

[charlie-foxtrot]

Gotcha, ok, I misunderstood what you meant by "distortion". There is a scratchiness to the audio when using 1024 that isn't there with 512.

For me 1024 is better but that obviously isn't true for everyone, so I shouldn't be changing the default

[szpajder]

Merged, thanks.

[szpajder]

I have enabled this for AM also and I see no adverse effects (so far).

It works incely on HF AM broadcast bands, where channels are densely spaced.