[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


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.


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
"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,

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
> which is the same as producing spectra from long term autocorrelation
> 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
> 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
> 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
> scheduler.
> Bob

Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium

reply via email to

[Prev in Thread] Current Thread [Next in Thread]