Limit viewable frequency range per profile

[weux]

Feature description
When using an RSPdx with the sample rate set to a relatively low value (<2MS/s) a large portion of the band at the edges are attenuated. I understand this is how the hardware works, but it causes some issues when creating profiles.

For example, if you want to create a profile that covers just the 20m ham band you would need to set the sample rate to at least 1MS/s in order to have all of the 20m band included in the unattenuated center portion. This ends up including parts of the SW broadcast band and ideally I'd like to limit the profile to just the 20m ham band and nothing else. Another issue is that the attenuation at the edges is so large that it falls inside the center 80% of the waterfall which throws off the auto waterfall adjustment. I was able to find a workaround for this by increasing the waterfall ignored value in openwebrx.js, but I think there could be a better way.

Proposed change: Would it be possible to limit the viewable frequency range per profile? This would allow us to set the sample rate high enough that the frequencies we are interested in are not attenuated and then limit the viewable frequency range to the exact value desired.

Here are some screenshots showing the edge attenuation at various sample rate settings using an RSPdx.

0.5MS/S

1.0MS/s

2.0MS/s

5.0MS/s

10MS/s

Target audience
Users with SDRplay devices

[jketterl]

I see the problem, but I personally don't think that cutting off the flanks is the best solution. After all, they are not completely unusable.

The problem itself is a lack of linearity, and it should be possible to counter that with proper calibration.

[weux]

I agree that would be a better solution, my initial idea would be kind of hacky.

So, I’ve done a bit more digging and I think I’ve narrowed down the issue. The RSPDx can be used at any arbitrary sample rate up to 10MS/s, but it also has 8 fixed bandwidth filters. Since there is currently no way to configure the bandwidth filter in OpenWebRX, it looks like the bandwidth filter is defaulting to a value one step lower than the sample rate.

The filter values can be found by running SoapySDRUtil --probe="driver=sdrplay", and you get this in the output.
Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

So right now the 0.5MS/s sample rate is using the 0.3Mhz filter, 1.0MS/s is using the 0.6Mhz filter, 2.0MS/s is using the 1.536Mhz filter, etc. This is causing the drop off at the edge of the band and also explains why it’s worse at the lower sample rates.

I’m not sure how much work it would take, but I think adding an option to configure the filter bandwidth would fix this issue. Then we could select a filter larger than the sample rate and the entire sampled area would be usable.

[jketterl]

The filter selection is actually reasonable, so I did not see the need to implement a manual selection (at least, not yet). If you set the filter wider than the sampling rate permits, you will see aliasing of out-of-band signals, so it's generally not advisable to do that.