I played with fast hopping a while ago and it works very well and you
get lock times of less than 1 msec easily.
This is a B210 just quickly switching between 100M (FM), 816M (LTE),
940M (GSM), 1817M (LTE), 2115M (3G), 2450M (Wifi/Bluetooth)
http://i.imgur.com/FwzVgMx.jpg
You can get an idea
Hi,
a while a ago I looked into fast-hopping using a (possibly modified)
B210.
Basically UHD is issuing a reconfiguration of the AD9361 for each tune
which will not only
wait for the LO to settle, but also will due DC-offset and IQ balance
calibration in the AD9361.
For fast hopping there is
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
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,
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
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
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
