[USRP-users] B200-mini does not respond to fast frequency changes

Marcus D. Leech mleech at ripnet.com
Tue Nov 14 19:15:14 EST 2017


On 11/14/2017 06:35 PM, David Rose via USRP-users wrote:
>
> All,
>
> I’m trying to implement a spectrum analyzer that spans the 2.4 GHz ISM 
> band.  The band I want is about 90 MHz wide, which is too wide to 
> handle at one frequency setting.  So my design is to step the receive 
> frequency across the band, pausing at each step to collect enough 
> samples for an FFT.  I’m sampling at 10 Msps, and only need 1024 
> complex samples at each frequency step.
>
> My flowgraph has the following components:
>
>   * _Source block_: (Controls the B200-mini)
>   * _Stream-to-vector block_: (Groups the samples in to 1024-sample
>     vectors)
>   * _Signal processing block_: Custom block, written in Python, that
>     does the FFT, computes the magnitude, and writes the results to
>     file.  Also tells the source when to change frequency.
>
> The problem is, if the dwell time at each frequency is less than about 
> 3 mS or so, the B200mini doesn’t respond to the “set frequency” 
> command.  It adds a tag to the stream that _says_ it changed to the 
> new frequency.  And if I interrogate it using the command “new_f = 
> self.uhd_usrp_source_0.get_center_freq()”, it returns the new 
> frequency.  But based on looking at known emitters in the resulting 
> spectrum, the frequency does not in fact change—it just continues 
> generating samples at the original center freq.  If the dwell at each 
> frequency step is more than 3 mS or so, it all works as it should.
>
> The 3 mS limit doesn’t seem to be related to the settling time of the 
> PLL in the receiver.  After a successful frequency change, I see valid 
> samples (and valid spectrum) within about 0.1 mS.
>
> Bottom line is, I only need one vector of 1024 samples at each 
> frequency, but this issue is forcing me to wait for around 30 vectors 
> at each freq.  That’s too slow for the intended app.  Has anyone run 
> into this before (I assume they must have), and is there a solution?
>
> Misc info:
>
>   * GNURadio version 3.7.9
>   * GNU Radio Companion 3.7.12
>   * UHD version: 3.11.0.git-191-g1cd96dde
>   * Python 2.7.12
>   * Ubuntu 16.04.3 LTS - Desktop version
>   * Running on Oracle VM VirtualBox Manager (version 5.1.28) under Windows
>
> Thanks,
>
> Dave Rose
>
> Valkyrie Systems Corp.
>
>
I'm not sure why things are being apparently *ignored* at 3ms intervals, 
but the AD9361 is not known to be terribly zippy in changing 
frequencies.  There
   is an optimization in UHD where if the frequency change is less than 
(AFAIR) 100MHz, it doesn't both doing laborious recals on some of the 
internal
   compensation machinery in the AD9361.  But even absent *that*, it's 
not a fast-hopping synthesizer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171114/c74e895f/attachment-0002.html>


More information about the USRP-users mailing list