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.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
