I am considering frequency sweeping a PlutoSDR and a B210, both fitted with
AD936x RF frontends.
As I was writing the application and reading the libuhd documentation, I read
at https://files.ettus.com/manual/page_general.html
"After tuning, the RF front-end will need time to settle into a usable state.
Typically, this means that the local oscillators must be given time to lock
before streaming begins. Lock time is not consistent; it varies depending upon
the device and requested settings. After tuning and before streaming, the user
should wait for the lo_locked sensor to become true or sleep for a conservative
amount of time (perhaps a second)."
... and surely enough, I can see that if I wait less than a second after programming
the LO, I get inconsistent results because my LO has not stabilized. That is also
true with the USRP GNU Radio source block.
Unfortunately I want to sweep a few hundred frequencies (in several 100 MHz range,
so no option of playing with the I/Qs while keeping the same LO setting), meaning
that the current measurement takes forever (up to 5 min) only waiting for the time to
settle since data communication delay is at the moment negligible.
1/ What is the cause of this settling delay ? is it libuhd communication (in my
case over USB with a B210) or the Analog Devices frontend hardware ?
2/ is there some "setting rule" that might lower the settling time (e.g. programming
a multiple of some magic frequency that might take less time to settle) ? Currently
I sweep with 1 MHz steps, ie a fraction of the sampling frequency, for spectra to overlap,
but that frequency step was selected randomly and could be any better value if that
could help LO stabilize "quickly".
Thanks, JM
--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France