Here, "pulse" refers to the detection type, though I should add that SETI@home itself still has a pulse in spite of the low rate of progress over the last couple of months. I've become involved in another SETI project, PanoSETI. And there are other factors.

Anyway, the good news is that I think we're done with narrow-band signals (spikes and Gaussians). We're happy with RFI removal, and with multiplet finding and scoring.

So we've turned our attention to pulsed signals (pulses and triplets). Until recently we've ignored these to some extent, because the birdie mechanism doesn't extend to pulsed signals so we don't have it to guide us.

Recently, when Eric examined the top-scoring pulse/triplet multiplets, he found that they consisted of detection that were zone RFI: in particular, their periods were multiples of 12s, which is the period of some kind of radar that pollutes our data.

Now, we have a "zone" RFI filter that is supposed to find stuff like this. We wrote this filter for narrow-band signals, where the zones are in frequency space: TV station sidebands and the like. We used the same algorithm for pulses and triplets, but using zones in period (i.e. the period of the pulse, or the spacing of the triplet) rather than frequency. (Actually, the zones are in log(period)).

But it turned out - once Eric looked that the aforementioned top-scoring multiplets - that this didn't work. The reason is that the periods of pulses and triplets are (unlike spike/gaussian frequency) not smoothly distributed. They're contentrated at particular values that arise from our FFT lengths and the algorithms we use to find pulses and triplets. Our zone-finding algorithm wasn't finding RFI - it was just finding groups of detections at these periods.

So Eric put on his thinking cap, looked at a lot of histograms in log(period) space, and came up with new zone-finding algorithms for pulses and triplets. I don't know exactly what these algorithms are - Eric did the work in IDL and just sent me a list of zones.

Anyway, we're still working out some kinks, but this looks like the right way to go. We'll know when we re-run the pipeline and look at the new pulse/triplet multiplets.

In other news: our application for time at FAST to re-observe candidates was approved - I may have mentioned this in an earlier post - and we're scrambling to make a data recorder to use at FAST. We can't - for various reasons - use the same approach we used at Arecibo. After we record this data, BTW, we'll analyze it with the SETI@home client program. But we'll do this on cluster nodes, not home PCs. There won't be very much data, and it will be easier to handle that way. But who knows - maybe this collaboration will lead to an eventual un-hibernation.