-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly implement SoapySDR::Device::getSampleRateRange() #81
Comments
Thanks for the suggestion, Jakob. The SoapySDR Device API lists that method here: https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.hpp#L909 The command
I also ran a quick test with CubicSDR tonight to make sure it still behaved as expected, but CubicsDR uses the the old Give it a try and let me know what you think. Franco |
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 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 :) |
Jakob, 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 |
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: |
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 |
I just merged those code changes to implement Franco |
@fventuri you missed the following valid sample rates: 96000, 192000, 384000, 768000. |
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 |
It's fixed now: 2c8169d Thanks for letting me know about that error. Franco |
Hi,I found that when using OpenWebRX, the sampling rate can be set to 10.66 MSPS. I tried it, but it didn't work. There was an error reported in the log, and no spectrum data appeared. However, when set to 10 MSPS it worked fine. When troubleshooting the problem, I stumbled upon this issue. I have doubts about the maximum sample rate mentioned above. This sampling frequency doesn't work with my device (it should be noted that I have an SDRPLAY RSP1 clone). I don't have the original SDRPLAY device on hand (besides, I also have an original RTL-SDR blog V4). It's also possible that the hardware differences of the clone are causing this. I'm not sure. I'm just leaving my feedback. Maybe mine is a special case, and the original device can work properly. |
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 ofgetSampleRateRanges()
falls back to the data available fromlistSampleRates()
).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:
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 howevergetSampleRateRanges()
, 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.The text was updated successfully, but these errors were encountered: