David, 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. http://files.ettus.com/manual/structuhd_1_1tune__request__t.html <http://files.ettus.com/manual/structuhd_1_1tune__request__t.html> 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) -Ian
> On Nov 14, 2017, at 4:15 PM, Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com> wrote: > > 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 > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
