In the last month we've made progress in several areas.

Birdie generation

On property of birdies (simulated ET signals) is bandwidth. Before, we were generating almost entirely narrow-band birdies; We weren't generating enough with wider bandwidths to give us sensitivity stats. I changed things so that we generate 100 birdies in the bandwidth range corresponding to each of SETI@home's 15 FFT lengths. This uses a configuration file so we can, for example, specify different power ranges for each bandwidth range.

I did a Nebula run with this, and the results can be seen in the sensitivity summary page. In most cases, we're finding almost all birdies, regardless of their bandwidth and power. This isn't what we expected; it suggests that there are some remaining problems, probably in how we generate birdie detections.

Birdie detection generation

Eric made several changes to how we generate detections (spikes) for birdies:

• Limit of 8 spikes per WU (since this is what the SETI@home client does).
  
• For planetary birdies (i.e. where the transmitter is on the surface of a rotating planet), assume that ET has put two transmitters at antipodal positions, so that one of them is always visible. Before we were assuming a single transmitter and that the planet is transparent to radio waves (not realistic); Before that we were assuming a single transmitter and that the planet is opaque, so that the transmitter is visible only about half the time.
  
• Make sure detections start an integer number of FFT lengths from the start of the WU (since that's what the SETI@home client does).
  
• The "time" of a detection is the midpoint of the FFT bin, not the start.
  

Drifting RFI removal

The drifting RFI algorithm looks at the upper and lower "fans" of triangles in freq/time space centered at a given signal. If two nearly-opposed triangles both have a statistical excess of detections, their contents are flagged as drifting RFI.

A while back we added a requirement that the detections in each triangle be spread out in time by a certain factor; this avoided getting rid of everything between parallel RFI bands. However, it also prevented us from flagging a certain type of RFI, namely repeated clumps of detections at about the same frequency (the "8 spikes per WU" rule can produce such clumps).

I fixed this by removing the time-spread requirement for the middle 3 triangles, i.e. the ones with little drift. Ad hoc, but it did the job in the cases we looked at.

Second, I fixed a subtle bug. Originally the drifting algorithm had only an "upper" fan of triangles. As we flagged drift triangles, they were always in increasing time order. The logic for maintaining windows of triangles assumed this order. When we added a lower fan of triangles, we no longer flag triangles in time order.

For the triangles flagged for the current detection type, I don't think this actually caused any problems, other than making things slightly less efficient (we didn't flush some triangles as early was we could).

But for spike triangles - which are used to flag gaussians - it did result in a bug. The triangles were being written to a file out of order. So there were cases where a triangle wasn't being read when it was needed, and a gaussian wasn't being flagged that should have been.

The fix for this was slightly involved. We now maintain two double-ended queues, one for upper triangles and one for lower. (Upper triangles are generated in time order, and so are lower triangles, but the combination is not). When we flush triangles from the window - and, in the case of spikes, write them to a file - we alternate between the deques in a way that writes them in time order.