Arbitrary sample rates

[willcode]

Feature request: PLUTO does not require fixed set of sample rates. Allow arbitrary rates within valid range.

[zuckschwerdt]

Yes, we should add getSampleRateRange(). I think I can do that in the next few days.

[willcode]

I just gave it a quick try, arbitrarily using Range(65105, 10e6) and I think it works. You know the driver better, so if you've got time, I'll wait for you to do it the right way :-)

[zuckschwerdt]

Thanks. Yes we need to account for x8 decimation/interpolation and x4 FIR to get the minimum 25e6/384, or x8 decimation/interpolation or x4 FIR for sample rates below 25e6/12 to 25e6/48, and that only if libad9361 is available to load an approporiate FIR. I.e. it will be 3 or 4 ranges with different step size.

[zuckschwerdt]

Something like #44 -- but I need to check the exact bound values still.

[willcode]

Seems to work. So, there's no totally arbitrary rate? Not that those small steps should be a problem for anyone, just curious.

I see the higher rates are totally arbitrary.

[zuckschwerdt]

Well, I was thinking wrong about that. Lower rates are arbitrary as we should be able to find an internal sample rate that divides nicely by 4(FIR), 8(decimation/interpolation), or 4x8 to that sample rate. For higher rates it might not be possible to get an exact desired rate. And it's complicated by the fact that reading and writing IIO values is truncated to int. E.g. 25e6/12 = 2083333.333 is read as 2083333 but written as 2083334. Also the divider can't get e.g. 2048M exactly. We might want to use the decimation/interpolation even for higher rates. E.g. 16384000 is possible and then decimates exactly to 2048M. If FIR is available it's not so much an issue and even more complicated. And then libad9361, if available, alleviates some of that, I guess.

Good enough, I'd say, caveat: surprisingly you might not get the exact frequency even for seemingly harmless values like 2048M, and the value read back is likely off by the truncated fraction also.

I use an LimeNET micro with GNSS synchronisation when a stable and exact frequency matters ;)

[willcode]

Have you thought of requiring libad9361? Or are there platforms that do not support it?

[zuckschwerdt]

It's an optional dependecy, not much of a problem if it's not available. But I'd recommend it and packagers seem to always include it, afaik.

[willcode]

Since setSampleRate() calls iio_channel_attr_write_longlong(..., long long samplerate) do you still get truncation?

Oh, rounding, then truncation after multiplication.

As you say, cheap hardware, no GPSDO, unlikely that it will make a difference.

[zuckschwerdt]

Yes ;) The Pluto is fun because of the capable processor. Deploying apps onto the SDR is the interesting part. I have a USB-hub with power bank, memory stick, GNSS, and wifi on my Pluto. I runs a hotspot with web server for easy control from a mobile phone. One-stop wardriving gimmick.

[zuckschwerdt]

For quick reference, you can inspect and modify the rate with:

• get internal rate: iio_attr --auto -c ad9361-phy voltage0 sampling_frequency
• set internal rate: iio_attr --auto -c ad9361-phy voltage0 sampling_frequency 4096000
• get internal rate range (includes FIR if set): iio_attr --auto -c ad9361-phy voltage0 sampling_frequency_available
• use "cf-ad9361-lpc" for effective RX rate
• use "cf-ad9361-dds-core-lpc" for effective TX rate
• note that sampling_frequency_available on ad9361-phy is a range, otherwise it's just two values (with/without decimation/interpolation)
• if you want the FIR, use e.g. something Soapy to (auto)load one.
• check FIR state with iio_attr --auto -c ad9361-phy voltage0 filter_fir_en, disable add 0

[willcode]

Nice, thanks.