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 >