SoapySDRDevice_getSampleRateRange weird behaviour

[ruilvo]

I'm using the SoapySDR C API. Since SoapySDRDevice_listSampleRates is market as deprecated, and the HackRF has a continuously tunable sample rate, I went and used SoapySDRDevice_getSampleRateRange. However, the return value is weird. This is a formatted output:

Frequency ranges detected:
range  0 ; min:  1e+06 ; max:  1e+06 ; step:  0
range  1 ; min:  2e+06 ; max:  2e+06 ; step:  0
range  2 ; min:  3e+06 ; max:  3e+06 ; step:  0
range  3 ; min:  4e+06 ; max:  4e+06 ; step:  0
range  4 ; min:  5e+06 ; max:  5e+06 ; step:  0
range  5 ; min:  6e+06 ; max:  6e+06 ; step:  0
range  6 ; min:  7e+06 ; max:  7e+06 ; step:  0
range  7 ; min:  8e+06 ; max:  8e+06 ; step:  0
range  8 ; min:  9e+06 ; max:  9e+06 ; step:  0
range  9 ; min:  1e+07 ; max:  1e+07 ; step:  0
range  10 ; min:  1.1e+07 ; max:  1.1e+07 ; step:  0
range  11 ; min:  1.2e+07 ; max:  1.2e+07 ; step:  0
range  12 ; min:  1.3e+07 ; max:  1.3e+07 ; step:  0
range  13 ; min:  1.4e+07 ; max:  1.4e+07 ; step:  0
range  14 ; min:  1.5e+07 ; max:  1.5e+07 ; step:  0
range  15 ; min:  1.6e+07 ; max:  1.6e+07 ; step:  0
range  16 ; min:  1.7e+07 ; max:  1.7e+07 ; step:  0
range  17 ; min:  1.8e+07 ; max:  1.8e+07 ; step:  0
range  18 ; min:  1.9e+07 ; max:  1.9e+07 ; step:  0
range  19 ; min:  2e+07 ; max:  2e+07 ; step:  0

I was expecting a single range, or only the recommended sample rates. This behaviour is very weird...

I'm using PhotosSDR latest, on Windows.

[guruofquality]

Thats just each discrete point being turned into a range of 0. This is basically intentional, or its not a bug, its just the current state of the sample rate reporting.

What should it be? This is an easy fix. Would a simple single range of 1 MHz to 10 MHz make sense?

Current API comments on libhackrf.h

/* 2-20Mhz - either as a fraction, i.e. freq 20000000hz divider 2 -> 10Mhz or as plain old 10000000hz (double) */
extern ADDAPI int ADDCALL hackrf_set_sample_rate_manual(hackrf_device* device, const uint32_t freq_hz, const uint32_t divider);
extern ADDAPI int ADDCALL hackrf_set_sample_rate(hackrf_device* device, const double freq_hz);

[ruilvo]

The HackRF wiki recommends some values:

Currently 8-20MHz - either as a fraction, i.e. freq 20000000hz divider 2 -> 10MHz or as plain old 10000000Hz (double) Preferred rates are 8, 10, 12.5, 16, 20MHz due to less jitter

I would suggest that the SoapyAPI suggested the preferred sample rates in zero-range elements, plus the whole range. [Same thing on the SDRPlay could be done for example].

My suggestion would be to return like (in pseudocode):

[
// Recommended values
[min: 8000000, max: 8000000, step:0],
[min: 10000000, max: 1000000, step:0],
[min: 12500000, max: 12500000, step:0],
[min: 16000000, max: 16000000, step:0],
[min: 20000000, max: 20000000, step:0],
// Supported range
[min: 8000000, max:20000000, step:0]
]

This way users would be presented with both the recommended sample rates (which is not what the Soapy API currently does, since it returns all integer values, and the continuous range, for the sake of completeness and user control.

Again, I noticed other devices do this, should I ask the same on the respective repos?

[mossmann]

We no longer prefer any particular sample rates for HackRF. Any rate from 2 Msps to 20 Msps is supported.