Is there some estimate of the tuning time measured in SPI register operations for standard tuning with all calibrations and tuning from a fastlock profile?
We would also like an estimate on the updating a profile from the BBP, again, in SPI register operations.
Please see post:
Re: AD9361 frequency switching time
There is no specified tuning time in SPI register operations for standard or fastlock tuning.
Note that if frequency change is greater than 100MHz additional calibrations will have to be performed which will extend the tuning time.
For fastlock tuning, in most applications, profiles are setup during initialization so timing is not critical.
The documentation outlines the steps required to use fastlock feature.
Can you give me a metric on the expected tuner lock time based upon some clock fed to the device? The number of profiles available in hardware (8) is very limiting, so these profiles will have to be pre-calibrated, stored, then subsequently loaded from the BPP. I am assuming that the SPI register operation times are the limiting factor in tuning time in this mode. It is difficult to evaluation the "timing is not critical" if the SPI register count loading up a new SPI profile.
Unless the tuner lock time (also looks to be "[un]specified") is substantially larger than expected best-case the SPI programming times.
Can a profile be loaded while the tuning for a previously loaded and commanded profile is settling toward tuner lock? That is, can tuning be overlapped? This may wash out most of the SPI programming overhead.
I see the documentation on the Linux device file-system interface to the fastlock feature (http://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361) but looking through the source tree (analogdevicesinc/ad9361 · GitHub) I don't see how these "fastlock" routines are jacked into the IIO file-system. I'm guessing that this "FMCOMMS" environment fabricates these entries from some top-level description somehow, but I'm not finding the specifics. All of the "fastlock" routines are "static" and not exposed in the symbol tables...
Moved to Linux Software Drivers.
The fastlock sysfs control attribute files should appear in your sysfs.
If they don’t, then your driver is too old.
More or less all driver functions are declared static. There isn’t a in-kernel API, other than the clock framework.
And the ways the capture driver binds to the ad9361-phy driver.
The user API is all handled via IIO sysfs files.