Hi JM,

What is the definition for settled for your application? The LO should
be on frequency within a few milliseconds. Possibly you should look at
disabling the IQ and DC tracking loops in the AD936x frontends. The USRP
has arguments exposed in GRC for that.

Derek

On 14/04/2020 12:39, jean-michel.fri...@femto-st.fr wrote:
> 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
>

Reply via email to