At my former employer we were using the HackRF in sweep mode to do I think 100 MHz to 6 GHz sweeps at 1 Hz (i.e. almost 6 GHz scanned each second). For contiguous sweeps I think it used a non-configurable 7.5 MHz (RF tuned) step or something like that, but gave you much better frequency resolution as the waterfall was the output of a some FFT which was somewhat configurable (so you could sort of set the resolution BW). We did make use of QSpectrumAnalyzer mentioned in a previous post and in combination with the hackrf sweep-mode worked quite well. I think the HackRF uses the same driver as rtl-sdrs but a typical rtl does not support the sweep-mode of operation.
On Wed, Mar 28, 2018 at 8:00 PM, Balthasar Indermuehle <[email protected]> wrote: > Thanks Marcus, indeed I'm using B200's for this project. X300's are > slightly over my budget unfortunately... but I'm also interested in doing > the same with RTL dongles. > You mention 450ms for tuning a B200 - that seems rather longish? > > Cheers > > - Balt > > On 29 March 2018 at 06:04, Müller, Marcus (CEL) <[email protected]> wrote: > >> so, 60 steps in 3 Minutes… sounds absolutely doable with the Ettus B200 >> (you asked about UHD drivers, so I presume you mean USRPs – the RTL >> dongle has nothing to do with UHD) and the usrp_spectrum_sense.py >> script that comes with GNU Radio. Even if I do not endorse the >> architecture of that script, and would recommend you reserve up to >> 450ms for tuning, as the B200 can take a bit of time to tune over some >> larger steps. >> With the other USRPs, you'd be faster. With a X300+TwinRX, you'd be >> able to do 80 MHz on each channel at once, and can tune the channels >> independently, so that you can actually even interleave tuning and >> receiving operation; realistically, that'd imply an effective >> observable bandwidth of always at least 120 MHz; 3000 / 120, meaning >> you only need 24 steps to cover all that bandwidth. With tuning delays >> in single milliseconds (too lazy to look this up right now, so let's >> say 1ms), that'd be 25ms tuning, roughly 2.999583 minutes of spectrum >> observation for 3 minutes of operation. >> >> Stitching that together to a full spectrum is more of a challenge here, >> but assuming you control the frequency hopping with commands to the >> USRP Source block, and hence are in control of when which band appears >> on the sample streams: >> You could do something like have a fixed 13-frequency sequence that >> each of the two receive channels hop along in fixed time intervals. >> Convert to vectors of interval length, FFT+magnitude-square these, and >> reassemble to a full spectrum vector (if your frequency sequence is >> strictly ascending, and non-overlapping, then just leave them in the >> order they are – all frequency bins should now be equidistantly >> spaced). >> >> Best regards, >> Marcus >> >> On Wed, 2018-03-28 at 12:19 +1100, Balthasar Indermuehle wrote: >> > At my work we're using R&S EB500s for continuous spectrum monitoring at >> our sites of interest. These machines step through the frequencies 70 - >> 3000 MHz in about 3 minutes in chunks of 50 MHz (from memory), and then >> assemble the fragments into a contiguous waterfall display. >> > >> > Is anyone aware of a wide band scanner software (that may or may not be >> GNUradio based) that works with RTL-SDR dongles and with UHD drivers and >> would allow to create a wide band spectrum sweep? >> > >> > I've built a raw IQ recorder that does just that, but it needs to be >> wrapped into a decent GUI, showing some nice waterfall displays and needs >> to be made pretty. Before I'm investing the time to build this I thought >> I'd check if that's not effort already done and shared by someone else. >> Google thinks no... anyone know differently? >> > >> > - Balt >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
