[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-reso
From: |
Bob McGwier |
Subject: |
RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs |
Date: |
Wed, 7 Jan 2009 14:19:23 -0500 |
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:address@hidden
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] Thread scheduling for high-sensitivity, high-resolution FFTs, Marcus D. Leech, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolution FFTs, Eric Blossom, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Marcus D. Leech, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Eric Blossom, 2009/01/07
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Marcus D. Leech, 2009/01/07
- RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Bob McGwier, 2009/01/07
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Marcus D. Leech, 2009/01/07
- RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs,
Bob McGwier <=
- [Discuss-gnuradio] Object model for stdgui2, Paul Mathews, 2009/01/14
Message not available