Marcus: What is the time constant on your IIR? If the time constant is longer than two FFT's you are probably losing sensitivity doing noncoherent averaging. All I am suggesting is that a computation is in order to determine the "noise figure" of the two approaches.
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: Marcus D. Leech [mailto:[email protected]] Sent: Wednesday, January 07, 2009 12:00 PM To: Bob McGwier Cc: 'Eric Blossom'; 'GNURadio Discussion List' Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs Bob McGwier wrote: > >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. > In the existing FFT sink, many frames are dropped, and the FFT output bins are averaged using a single-pole IIR. It takes long integration times for this to be as sensitive as an FFT in which no input frames are ever dropped. In my application (SETI), having long integration times hurts, because of chirp (although one could also de-chirp the baseband prior to computing spectra). I'll conduct some experiments as Eric has suggested, once I get my quad-core system back in operation. [Don't muck with hardware when you're too sick to cope. That's how LGA775 sockets get bent pins :-( :-( :-( ]. > This is all a fruitful area for experimentation now that we have the new TPB > scheduler. > > Bob > Indeed -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
