Access quick tune API

[KarlL2]

Hi Josh,

I'd like to access bladerf_get_quick_tune and bladerf_schedule_retune . Do you think we could update the SoapySDR API to handle that? Or is there an easier way to access those methods?

I'm currently modifying the SoapySDR and SoapyBladeRF dlls, but I would rather not have to maintain my own version. Also that would impact all types of device and I'd need to rebuild all other dlls.

[guruofquality]

I think the path of least resistance is to use the tune args in the existing set frequency call to invoke bladerf_schedule_retune when a timestamp is passed.

[KarlL2]

Actually there are several ways to use bladerf_schedule_retune:

• you can pass a frequency to do a tune, or the result from bladerf_get_quick_tune to directly reuse a previous configuration
• you can pass a timestamp in the future to really schedule a tune/retune in the future, or pass an old timestamp to tune/retune at once

In my tests I always called bladerf_schedule_retune with a timestamp of 0 to do it at once. Doing a normal tune takes 12-15ms, while a retune takes 0.4ms.

We could indeed pass data in args when calling setFrequency. Here are the possible cases I'm thinking of:

• schedule at once with no existing quick tune: that's a normal tune, no specific args needed
• schedule at once and keep the info on the quick retune saveQuickTune=true
• schedule at once using an existing quick retune reuseQuickTune=true
• schedule in the future with no existing quick retune timestamp=xxx
• schedule in the future and keep the info on the quick retune: probably not possible as we don't know when to call bladerf_get_quick_tune
• schedule in the future using an existing quick retune timestamp=xxx,reuseQuickTune=true

Note that the tune configuration may need to be updated as time passes:

These parameters are sensitive to changes in the operating environment, and should be "refreshed" if planning to use the "quick retune" functionality over a long period of time.

We could pass an additional argument forceTuneAfterSeconds=xxx to force a normal tune if the tune configuration is older than the specified number of seconds. After a forced normal tune, we would store the tune configuration for future reuse. This would again work only when scheduling at once.

We could also (instead?) use quickTune=true to either reuse an existing quick retune if any, or do a normal tune and store the quick tune configuration.

What do you think?

[guruofquality]

Sounds good overall. I don't think the forceTuneAfterSeconds hurts anything, its like a happy extra feature. Since the application could also manage the force tune if needed.

[KarlL2]

Thanks. I'll look into it once I have time.

[KarlL2]

Hi Josh,

I sent https://github.com/pothosware/SoapyBladeRF/pull/52 where you can pass the following arguments:

• no argument for the default behavior
• "saveQuickTune" = "1" to set the frequency and keep track of its quick tune
• "reuseQuickTune" = "1" to reuse a previously computed quick tune (throws a runtime_error if no quick tune exists for that frequency)
• when "reuseQuickTune" = "1", "timestamp" can be set to the string representation of the timestamp when you want the tune to be done

Note that I haven't done anything concerning forceTuneAfterSeconds as:

• this can be time consuming
• once you exceed NUM_BBP_FASTLOCK_PROFILES quick tunes in RX or TX, you cannot get any new ones, without resetting the state of the RFIC (which is currently done when the FPGA is loaded or reloaded). To have the ability to live reset the quick tunes, the ADI AXI core might have to be modified.

For now if you reach the max number of quick tunes, you can SoapySDRDevice_unmake then SoapySDRDevice_make your device again, which will reset things.

[KarlL2]

@guruofquality I've fixed my PR (I had renamed but somehow missed to commit the updated definition). The PR now compiles fine and works well.