Re: USRP LO stabilization time ?
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 of the switch time by looking at the duration of the GSM FCCH signal ( which is ~ 4.6 ms long ) The hardware can only store 8 profiles internally but you can upload / download profiles via SPI while another profile is running and so my plan was to use the FPGA to upload next profile and switch to it at times interval. The client for that project disappeared and so I never continued to actually implement it ... Cheers, Sylvain
Re: USRP LO stabilization time ?
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 a special mode in the AD9361 manual where you can basically save the settings after calibration either in a special set of registers (limited space) or supply them on the fly so no calibration is carried out. Using this it would be possible to possibly to sub-ms tuning. (I don't recall the details) In the end I did not implement this but it would be definitely feasible (would require a bit of work). Maybe someone else has some more details on this (I think there is something in the archives on this). Cheers Andrej -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: USRP LO stabilization time ?
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" 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 > : > >> 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
Re: USRP LO stabilization time ?
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, 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 > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, > 25000 Besancon, France >
Re: USRP LO stabilization time ?
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.
Re: USRP LO stabilization time ?
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 > >
USRP LO stabilization time ?
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
