Policy on setting bandwidth and sample rate

[vsergeev]

I just wanted to clarify my understanding on whether the application or module is responsible for setting a bandwidth that makes sense for its sample rate. Several SoapySDR code examples (C, Python) demonstrate a setSampleRate() and setFrequency() without explicitly setting the bandwidth, but this only makes sense for some SDRs where the setSampleRate() and setBandwidth() operations are inherently coupled by the hardware (e.g. the RTL-SDR).

In other modules, e.g. the SoapyLMS7, the device is initialized to 30 MHz bandwidth at construction and unchanged in the call to setSampleRate(). Applications using this module should also call setBandwidth() with a choice of bandwidth for good results.

SoapyHackRF occupies an interesting middle ground with an internal _auto_bandwidth variable that tracks whether or not the user has explicitly set a bandwidth. The bandwidth is then left as is in calls to setSampleRate(), or otherwise set to a reasonable bandwidth (in HackRF's case, a rounded down discrete option based on the sample rate) if the user never specified it. I actually like this policy this best, because things will "just work" with minimal library calls and no surprises across different SoapySDR modules, but the downside is that it's more difficult to enforce (up to the module code) and in cases where the allowable bandwidth is continuous, may require a somewhat arbitrary choice of bandwidth (equal, 0.5 MHz less, or even 1 MHz less than sample rate? etc.)

If the latter is the preferred policy, the driver API could be annotated with a note about it and SoapyLMS7 can be updated accordingly.

:two: cents :smiley:

[guruofquality]

Ultimately, its up to the application to set the filter bandwidth (if present in the HW) because it can potentially do a better job depending upon the desired use case. Just as a data point, a lot of the gr-osmosdr wrappers, including the one for soapysdr set an automatic bandwidth which is 75% of the sample rate: https://github.com/osmocom/gr-osmosdr/blob/master/lib/soapy/soapy_sink_c.cc#L274 So even with the modules picking a good automatic value, the application may just immediately overwrite it.

That said, I think that each module should try and do a good job with automatic selection when the hardware is present and the user did not specify a desired bandwidth. In the case of the LimeSDR, I think that the setBandwidth() could set a combination of the analog baseband filter based on the actual ADC/DAC rate, and a narrower digital filter (FIR) to match the actual requested bandwidth. Currently setting the analog bandwidth is a slow operation (if you noticed) so I would be worried to make it automatic. But these are all things that can be fixed in due time.

[vsergeev]

Thanks for the follow-up. The reason I bring it up is that I'm trying to decide a good default bandwidth policy for the SoapySDR source/sink blocks in LuaRadio, for cases that a bandwidth is not explicitly specified. Going with a heuristic like 75% might be a good option, but there is some ambiguity as to whether or not the module will do something better automatically (e.g. HackRF module will, but the LimeSDR module won't), and to a lesser extent I was worried about SDRs with discrete bandwidths (but most module code I've seen seem to handle this gracefully without raising an error). I agree that automatic selection by the module would be nice for these cases (for things to "just work").