The 450 ms are indeed a generous upper boundary for tune duration – however, since the B200 can't sample-time analog tunes, you'd do well not to calculate much less; the B200 is generally much faster at tuning, but when crossing certain frequency span boundaries, there's a single tune that might take that long. You can probably test your tuning sequence once and identify the tune step that takes that long, and wait much shorter on all the other tunes.
Regarding RTL dongles: Same problem as B200, no possibility to know at which sample a tune happened, exactly, so you need some safety margin. Considering the cost, and the low bandwidth, and the low filter fidelity, I'd argue, however, that you'd probably want even number of RTL dongles to receive simultaneously, so that you can tune one half while the other half generates "valid" signal. You might want to do some hacks with the RTL dongles to share an oscillator, so that they don't randomly differ in understanding of frequency and in sample rate. Best regards, Marcus On Thu, 2018-03-29 at 14:00 +1100, Balthasar Indermuehle 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) <muel...@kit.edu> 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 > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
