We (mostly Eric) examined lots of top-ranking multiplets from the recent all-pixels scoring run. Many of the multiplets were clearly RFI, and we'll be tweaking the filters a bit to reduce the number of such cases.

In addition, we found a multiplet whose time factor seemed way too high. We figured out why.
Here's what happened: when looking for multiplets in a pixel P, we assemble the detections from a "disk" that includes all of P and parts of the 8 adjacent pixels. For each pixel, we know the time intervals during which we observed it (more precisely: the intervals during which a beam was within a half beam-width of the pixel center). The time factor compares the time we observed P (the central pixel) with the time covered by detections. For example, if we observed for 26 seconds and the multiplet has two 13-second spikes, that would get a high score. If we observed for 1000 seconds, it would get a lower score.

The problem is that the observation times of adjacent pixels can be wildly different. In the problem case, the central pixel was observed for 0.3 seconds and one of the adjacent pixels was observed for 1000s of seconds. The multiplet included spikes from the adjacent pixel (in fact, it only had spikes from that pixel). Their duration was way more than 0.3 seconds, so the multiplet (incorrectly) got a high time factor.

How to address this? One approach is to include, in the calculation of time factor, the observation intervals of the adjacent pixels as well as those of P (or perhaps, for a given multiplet, just the pixels for which the multiplet has detections). But this is flawed: the detection disk includes only a part of each adjacent pixel; we shouldn't include times when the beam didn't overlap this part.

Another approach is to include, in the calculation of time factor, only the multiplet's detections that are in the central pixel. I think this is the way to go; it's certainly the simplest option. It would (correctly) give a low time factor score in the above example.

If a multiplet consists primarily of detections from an adjacent pixel, this approach would tend to give it a low time factor score. But that's OK - when we score the adjacent pixel we'll see a (probably better) version of this multiplet, and it would get a higher time factor in that pixel.

A related issue: during multiplet finding we do something called "observation consistency pruning", which means e.g. ignoring a 13-second spike that occurs during a 1 sec observation. We do this only for detections that lie in the central pixel, because that's the only pixel for which we've read the observation intervals. In theory we could do this for adjacent pixels too, but I don't think it's worth it.