On 04/14/2020 07:39 AM, 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
The AD936x series is simply NOT optimized for fast-sweeping
applications. When you chance frequency, a number of internal
re-calibration operations have to happen within the chip. UHD tries
its best to make those as speedy as it can, without
compromising quality parameters of the chip.
