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 jean-michel.fri...@femto-st.fr < jean-michel.fri...@femto-st.fr>: > 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 > >
