[USRP-users] B200-mini does not respond to fast frequency changes
ianb at ionconcepts.com
Tue Nov 14 22:11:52 EST 2017
Not a direct answer to your question but an idea for you to sidestep it.
Setup your B200-mini to capture a big chuck of spectrum, say 56MHz, with the band center at 2022MHz.
You are going to capture 56MHz of spectrum up front but only pass a 1MHZ sub-band of that at any one time to the host.
You do this by setting master_clock_rate=56e6 and samp_rate=1e6.
Then use a tuning request to the DDC (Digital Down Converter) within the USRP to instantaneously retune the sub-channel digitally without retuning the LO synthesizer.
So you would start with a target frequency of 2400.5MHz and an LO offset of 21.5MHz, then step them both by 1MHz (with opposite signs) to tune each band.
After you grab your first 45MHz, do a retune of the RF LO to 2067MHz and repeat the process.
(The excess bandwidth captured leaves filter rolloff out of band)
> On Nov 14, 2017, at 4:15 PM, Marcus D. Leech via USRP-users <usrp-users at lists.ettus.com> wrote:
> On 11/14/2017 06:35 PM, David Rose via USRP-users wrote:
>> 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
>> 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
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users