David,
Sounds right, but not sure I understand all this.

How is a "short FFT" defined?

Are the bins shaded? The effective "FFT length" would be a bit different if the bins were "shaded" ...


> David Woolley wrote:

[ originally sent to the official contact, Matt, on December 18th, but
  still unacknowledged ]

There is a flaw in the SETI@Home logic that I've long suspected but have
now confirmed by reference to the now published source code.

The intervals between short FFTs are calculated based on the the square
of the FFT length.  The logic is that halving the FFT length both doubles
the frequency range over which chirping has to occur and halves the time
available to cross that frequency range.

However, the time over which chirping can take place is limited by the
the Power Over Time calculations, and therefore the beamwidth, not an
individual FFT.  It might have been possible to partially compensate
for this by doing power over time calculations for multiple chirp rates
within one particular FFT chirp rate, by stepping frequency bins at
various rates, so I originally gave you the benefit of the doubt, but
I can see no evidence of that in the December 18th snapshot of the code.

Although this will increase the run time of the client, at worst it will
increase it will increase the number of passes to approximately twice
the number of full length ones (1 + 0.5 + 0.25....), so the additional
processing time won't be catastrophic.  It does mean that you really need
to back fill with the missing chirp/FFT length combinations, on the original data!

[ Paraphrase and addition follows. ]
It would be nice if it were possible for members of the public to contribute
to the bug database as is possible on normal open source projects.
(The BOINC S@H client uses an open source compliant licence, although BOINC itself cannot, because of the inclusion of code that prevents that.)