>From what Eric has described (which should work), you have choices. The choices would be to increase sensitivity by adding the results of the fft's which is the same as producing spectra from long term autocorrelation which will increase sensitivity O(n) because it is coherent averaging or if you sist on noncoherent averaging sensitivity will be increase O(sqrt(n)) but only by decreasing the variance of the noise. And/or you can build larger fft's from the intermediate ones via several techniques to increase frequency resolution. The latter requires more careful organization because you do not wish to window the smaller ones if you wish to combine them later. This would require windowing in the frequency domain and necessarily the expense of convolution rather than multiplication.
This is all a fruitful area for experimentation now that we have the new TPB scheduler. Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "And yes I said, yes I will Yes", Molly Bloom -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric Blossom Sent: Wednesday, January 07, 2009 12:39 AM To: Marcus D. Leech Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs On Tue, Jan 06, 2009 at 11:20:48PM -0500, Marcus D. Leech wrote: > Eric Blossom wrote: > > > > > > Is this an SMP machine, or a cluster? > > > > If SMP, it'll "just work". If it's a cluster, you'll need to figure > > out how to partition separate instantiations of GR on each node. > > > > Eric > > SMP. > > Describe how it'll "just work"?? > > Maybe I haven't looked at all the blocks carefully enough, but I can't > immediately see how to do this. > > I basically want a "distributor" block that distributes FFT input frames > to multiple instances of an FFT computation, > across multiple threads, and have the results of the separate FFTs > synchronized. Sounds good. Sorry, I misunderstood your goal. (I'm working on the guts of FFTW now and have FFT on the brain...) I think we have the blocks you need to do the fanout and fanin already. They're disguised as gr.deinterleave(itemsize) gr.interleave(itemsize) I think you could use them like this: fft_size = 512 usrp = ... fanout = gr.deinterleave(fft_size * gr.sizeof_complex) fanin = gr.interleave(fft_size * gr.sizeof_complex) fft0 = ... fft1 = ... fft2 = ... fft3 = ... connect(usrp, fanout) connect((fanout, 0), fft0) connect((fanout, 1), fft1) connect((fanout, 2), fft2) connect((fanout, 3), fft3) connect(fft0, (fanin, 0)) connect(fft1, (fanin, 1)) connect(fft2, (fanin, 2)) connect(fft3, (fanin, 3)) Each block runs in its own thread, so this should run faster on an SMP machine. Please let us know if this works for you! [FYI, there are also two extra copies happening in the gr.fft_* block that I now know how to remove...] Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
