Joined: 13 Feb 99
In the last month we've made progress in several areas.
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:
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.
©2022 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.