[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: USRP LO stabilization time ?
From: |
address@hidden |
Subject: |
Re: USRP LO stabilization time ? |
Date: |
Tue, 14 Apr 2020 14:14:53 +0000 |
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" <address@hidden> 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 address@hidden
> <address@hidden>:
>
>> 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