We wanted to bring everyone up to date on the interference issue that Eric described in this blog entry. Eric, while working on the multibeam client in the beta project had noticed that a large number of results were overflowing. Too many signals were being detected, a sign that the data contained a large amount of radio frequency interference (RFI). The interference was in the form of pulses.
The task at hand was to track down the source of the RFI and then make it "go away" by either removing the source or, failing that, scrub it from our data. At this point we were not sure if this was real RFI (a signal entering the receiver) or some sort of interference within the data recorder or intervening electronics that ended up looking like RFI. We sampled our data (collected over many months and many different pointings) and found that the RFI pulses were always present. So the source was very local. Starting at the end of the data acquisition chain and working backwards we first asked if the recorder software had a bug that caused it to introduce these pulses. No, independent software also saw them. Was it a hard drive or power supply issue? Was it a problem in the front end electronics? One by one we eliminated these possibilities. Time to ask the Arecibo Observatory (AO) staff for help.
Once we engaged the efforts of an AO radio engineer and the AO RFI expert, we quickly found the problem. It was real RFI, coming from the air defense radar system across the island. We had not seen this RFI in our data until we started multibeam observations. Prior to multibeam acquisition we were taking data from an antenna that was lower than the ALFA feed and was thus in a radar shadow provided by the surrounding hills.
We were not going to be able to remove the RFI source, so we were left with scrubbing it from our data. Eric had already begun to develop the algorithm for this. Our data, if very clean of RFI, looks like noise. That is, in the the absence of ET or some other radio phenomena, our data are random. So the scrub algorithm is to detect when the radar is present and randomize that tiny portion of data. We could detect the radar by examining the data in software post acquisition (the logical place would be in the splitter) but we would have to be conservative to prevent result overflows in the client. Thus we would be randomizing more data than we strictly need to. A better way would be to somehow know that the radar was hitting us and so tag the data in real time during acquisition. This is what we decided to do.
It turns out that this radar is well known at AO. There is an antenna on the platform that holds the receivers that is designed to detect the radar signal (the antenna is pointed right at the radar and the antenna feeds a custom receiver developed to detect when the radar signal is on). The electronics exist to deliver this detection to the data recorder. Delivering and dealing with this radar on / radar off signal is called radar blanking. We decided that the most precise (and easy) way to encode the radar blanking signal is to have the radar state indicated right in the data stream. The data recorder is built to receive 16 inputs. We are only using 14 (7 ALFA receivers each at 2 linear polarizations). The radar blanking signal will go into one of the unused input channels. This will allow the blanking signal to be exactly time correlated with our observational data as the two will appear side by side in our data stream. With data taken after we implement radar blanking the splitter does not have to decide whether or not the radar is present. It will just watch the blanking channel and randomize the observational data when the blanking channel is "on". Of course we will have to scrub all of the data taken to date - data that does not have the blanking signal. For this data, the splitter will have to decide if the radar is present and (a bit more aggressively) randomize it.
A small bit of interfacing electronics needs to be built. Dan and an AO engineer Dana Whitlow will do that when Dan is in Puerto Rico in the middle of this month for a bioastronomy conference. When AO comes back on line after the painting is completed we should be all set.
©2019 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.