USRP LO stabilization time ?

[address@hidden]

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