For the record ... thanks to the excellent reference provided in this answer, I became convinced that the timing issue does not lie with the B210/libuhd but with the PlutoSDR. After reading https://ez.analog.com/adieducation/university-program/f/q-a/91477/adalm-pluto-how-to-change-settings-with-quick-settling/199287#199287 and porting the single_param function updated by Travis Collins to the GNU Radio 3.8 port of gr-iio, I get sub-millisecond stabilization time by changing *only* the out_altvoltage1_TX_LO_frequency parameter and not the full set of settings as done with the defaut Pluto Sink function set_params. Now my sweep time is limited by data transfer and no longer by LO settling time, but that is another issue for me to solve.
Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France April 14, 2020 2:22 PM, "Sebastian Sahlin" <seb.sah...@gmail.com> wrote: > 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
