Correctly implement SoapySDR::Device::getSampleRateRange()

[jketterl]

In preparation for a better integration with SoapySDR, I introduced a very basic validation for sample rates in the OpenWebRX web config. I based the list of options on what is implemented in the listSampleRates() function found in the code here because that would ultimately be the base for said validation when SoapySDR devices are natively integrated (the default implementation of getSampleRateRanges() falls back to the data available from listSampleRates()).

I am now receiving complaints from users that various sample rates that they used before cannot be entered any more. The following rates seem to be in use, but are invalid according to the code here:

• 5.7MS/s
• 2.56MS/s
• 2.4MS/s
• probably more, this is just the ones i know of right now.

It is my understanding that SDRPlay devices have (multiple?) ranges of sample rates they can operate on. The existing listSampleRates() API cannot really properly model these ranges, so it is understandable that it cannot really present all valid options. There is however getSampleRateRanges(), which, according to my understanding, follows a different data model that allows both discrete entries as well as ranges. It would be really helpful if this method was implemented in a way that covers all valid user input in the future.

[fventuri]

Thanks for the suggestion, Jakob.
I just implemented the method getSampleRateRange() in the new branch add-getSampleRateRange (https://github.com/pothosware/SoapySDRPlay3/tree/add-getSampleRateRange).

The SoapySDR Device API lists that method here: https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.hpp#L909

The command SoapySDRUtil shows the sample rates correctly:

    Sample rates: 0.0625, 0.125, 0.25, 0.5, 1, [2, 10.66] MSps

I also ran a quick test with CubicSDR tonight to make sure it still behaved as expected, but CubicsDR uses the the old listSampleRates() API, so it was mostly to make sure I didn't introduce any regression bug.

Give it a try and let me know what you think.

Franco

[jketterl]

Hello Franco,

thanks for the prompt response. I've had a quick look at your changes, and they look perfectly fine for my purpose.

I'm no expert in SDRPlay hardware, but the value of 10660000 did surprise me a bit, I always thought that 10MS/s was the limit, flat out. Is is really possible to push that far?

I'll port these ranges over to the OpenWebRX codebase for now, the actual integration is still down the line somewhere, but given that the sample rate is the one input that cause the most input errors, it made sense to start introducing validation here.

As far as I'm concerned, this is good (pending maybe a double check for that maximum value from above).

Thank you :)

[fventuri]

Jakob,
glad I could help.

All the datasheets for the SDR RSPs list 10.66MHz as the maximum sample rate (see here for instance for the RSP1A: https://www.sdrplay.com/docs/RSP1Adatasheetv1.9.pdf; look on page 2 where under the header 'ADC Characteristics'), so I think it should be OK to run them at 10.66MHz.

I am going to go ahead and merge this change into the 'master' branch tonight or tomorrow morning.

Franco

[jketterl]

Yeah that's alright, I don't have any better information, i was just trying to avoid a minor oversight. I have adopted the values here:
jketterl/openwebrx@3a79ff3

[fventuri]

Looks good to me Jakob.

The thing is with a maximum IF bandwidth of 8MHz (see that datasheet) there's little reason IMHO to go above 9Msps (let alone 10Msps) since the internal IF filter will cut off anything above that, and they are going to lose 2 bits of ADC resolution (from 10-bit to 8-bit), but perhaps I am missing something.

Franco

[fventuri]

I just merged those code changes to implement getSampleRateRange() to the master branch, and I also pushed the new tag soapy-sdrplay3-0.5.1.

Franco

[luarvique]

@fventuri you missed the following valid sample rates: 96000, 192000, 384000, 768000.

[fventuri]

Good point; actually if you are running in Zero IF (IF=0) mode you can use any sample rate >= 62.5kHz (while in Low-IF/LIF mode only 2MHz and power-of-two fractions of 2MHz).

Franco

[fventuri]

It's fixed now: 2c8169d

Thanks for letting me know about that error.

Franco