Re: USRP LO stabilization time ?

[Sebastian Sahlin]

Hi,

I believe the following paper may be of interest: https://pubs.gnuradio.org/index.php/grcon/article/view/2

It is indicated that the B210 needs around 3.3 milliseconds minimum to settle and it is, as you say, due to the hardware frontend. What is causing the extra delay I can only guess but perhaps communication overhead is the culprit.      

Regards,

Sebastian 

Den tis 14 apr. 2020 kl 13:40 skrev address@hidden <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