Review: the ALFA receiver used by SETI@home has a cluster of seven small "beams" that sometimes move across the sky and sometimes "stare" for a while at a point on the celestial sphere. Over the 15+ years of recording data, these beams have looked at most of the sky visible from Arecibo. Some places have been observed once for a few seconds; others have been observed hundreds of times, for many hours total.

The question of how long we've observed a given spot of sky comes into play in several parts of Nebula. For example, the score of a multiplet (a candidate ET signal) includes a "time factor" that in essence measures: in the times we could have detected something here, how often did we actually detect something?

The notion of observation time seems straightforward, but it's not. When we examine it carefully, it turns out we've been doing things in a somewhat sloppy way. Eric and I have been figuring out how to clean this up.

There are two inherent approximations in how we do things. First, the idea that a beam "sees" a sky disc is inaccurate. The sensitivity of a beam is a distribution, roughly Gaussian shaped but with "side lobes" that extend far from the beam's center. In fact, for sufficiently powerful signals, a beam "sees" the entire visible sky.

In SETI@home we assume that ET signals will be fairly low power. So we assume - somewhat arbitrarily - that the source of a signal seen by a particular beam at time T is within an angle of H of the center of the beam at time T, where H is the half-power diameter of the beam sensitivity. We call this the "feasible disc" for the beam at time T. Dan pointed out that - if we had infinite time and computing resources - we could do separate back-end analyses for different ranges of ET signal power.

Second, our notion of "spot of sky" is approximate. We account observation time in terms of pixels. The resolution - the size of the pixels - is chosen to be somewhat finer than the half-power beam size. A beam's feasible disc could include only part of a pixel.

OK - back to observation. In fact, let's go back to the beginning: the data. Our data from Arecibo includes pointing information: the sky coordinates (RA and dec) of each beam center as a function of time. The time resolution of this info is fairly coarse: early data has "pointing records" about every 5 seconds, in later data it's every second.

The "workunits" analyzed by the SETI@home client consist of 107 seconds of data from a particular beam, together with the pointing information for the beam during that period. The client does FFTs of various durations and generates "detections". Each detection is assigned a sky position: the estimated position of the beam center at the midpoint of the FFT. This is computed by linearly interpolating between pointing records.

Reminder: if a detection is actually from a celestial signal, its sky position is not the location of that source; it's the location of the beam center at the time of the detection.

We find multiplets on a per-pixel basis. For each pixel, we collect the detections whose angle from the center of the pixel is less than H. This "detection disc" will typically include detections from the 8 adjacent pixels.

With that background, let's get back to our original goal: to calculate, for a given pixel, the set of time intervals during which the SETI@home client could feasibly have generated detections that lie in that pixel - or more accurately, that lie in that pixel's detection disc.

Here's what we were doing until now: for each beam, we stepped through its pointing records. For each pointing, we formed the group of pixels with centers within H of the pointing (usually a block of 9 pixels) and counted the time interval from that pointing to the next as an observation of each of these pixels.

This gave us a set of time intervals for each (pixel, beam) pair. For a given pixel we took the union of these intervals, and considered that as the time we observed that pixel.

A problem became apparent: the detection disc of some pixels contained detections whose times were outside (usually by just a little) the observing time of that pixel.

As a quick fix for this, I increased the radius used in the observing-time calculation from H to 1.5H. Each pointing interval was then being credited to block of up to 25 pixels.

It turned out there were two problems with this. First, detection discs still had detections outside the pixel's observing time. Second, we were granting time too liberally: a pixel's observing time now included intervals during which detections in its disc are not feasible.

The problem - we eventually figured out - is that during periods of telescope movement, consecutive pointing records can skip over pixels. This happens more when the time resolution is 5 seconds, but it can also happen with 1-second resolution when the beam is moving quickly. Because the SETI@home client interpolates between pointings as described above, it can generate detections whose positions are not when the pixel of any pointing, or even in the discs of H or 1.5H around any pointing.

With me so far? Now we come to the solution: be more precise in granting observing time to pixels. Let's say that consecutive pointings are in pixels P1 and P2, and that these pixels are non-adjacent: maybe they're 4 or 5 pixels apart. Instead of crediting the time interval to a block of pixels around P1 (or P2, or both) we should credit it (or rather parts of it) to the line of pixels between P1 and P2. This reflects what the SETI@home client does, in interpolating the position of detections.

How to do this? Prior to doing observation accounting, I added a step in which we "fill in the gaps" in the pointing data. For each beam, we go through its pointings in time order. For each consecutive pair of pointings X1 and X2, we interpolate their midpoint Y: namely, the halfway point assuming that motion in RA and dec is linear (the SETI@home client makes this assumption).

If the position of Y is in the same pixel as either X1 or X2, we move on to the next pair of pointings. Otherwise we add Y to the pointing history, and then recursively look at the midpoints of (X1, Y) and (Y, X2), possibly adding them as well.

After this interpolation process, there are no gaps in the pointing history: consecutive pointings are in adjacent pixels (not obvious but true). I changed the radius back to H, so as to not grant observation time to spurious pixels. And we're doing a more accurate job of accounting: if there's a 5-second gap between pointings, and the beam moves across 5 pixels, we're granting 1 second to each pixel along the line, rather than 5 seconds to the start pixel and its neighbors.

Also, I must say I'm proud of the above interpolation algorithm. As far as I recall it's the only direct use of recursion in Nebula (although, of course, the Healpix and R-Tree libraries do recursion galore).

I'm currently doing a Nebula pipeline run with these changes; it should be done and copied over in a couple of day.