Scientific Newsletter - May 4, 2010

How to Mitigate Radar Contamination
Matt Lebofsky

For some background, read this scientific newsletter which described the radar noise problem when we first detected it in 2007.

There's strong federal aviation adminstration (FAA) radar near Arecibo that affects our data. Luckily the observatory set up an antenna to detect and "lock on" to this radar. By "locking on" at regular periods we can identify when we are susceptible to radar noise even when the radar is normally too quiet to easily detect, yet still contaminates our data.

The output signal from the radar blanker receiver is merged into our data stream and recorded along with the signals from the ALFA (Arecibo L-band Feed Array) multibeam receiver. We call this the "hardware blanking signal." Basically, it's a stream of bits - if the number is 0, the data are clean. If the number is 1, insert random noise otherwise you'll get obliterated by radar noise. Roughly speaking, we are randomizing about 15% of our bits. This may seem like a lot, but really only results in a slight loss of sensitivity.

While this method ended up solving the immediate data integrity crisis, we still had to solve another problem: what about all the raw ALFA data we collected for almost two years which had no embedded hardware blanking signal? While figuring this out we stumbled upon a second problem: there's actually a second radar from an Aerostat balloon which, while not as frequently, seems to hit us as well but the hardware blanking system doesn't know about it and therefore lets it all through.

Luckily both problems had one solution: the software blanking system. It is possible to do a simple statistical analysis of the bits across all the beams to retroactively find radar in our raw data, even without confirmation from a hardware blanking signal. Simply put, if all the bits in all beams over several samples are suddenly all 1's, we're being jammed by radar. When this happens frequently and in succession, we can lock onto it and form our own "software blanking signal." There is very little fear of "false positives" - we check 28 possible beam bits over 10 samples - that's 280 bits that have to all be 1's, which is always the case when radar hits us, and rarely otherwise. That occurs by random chance 1 in every 2*1084 times, or, given our sample rate, once every 2,500,000,000,000,000,000,000,000,000,000,000 years.

Using analysis and algorithms by Dan and Eric, summer student Luke Kelley worked on the first version of the radar blanker, which generated useful results, but this was before we fully understood the kinds of radar hitting us and when. I took over the code and ultimately revised it to use a folding algorithm which was far more accurate. In fact, this was also far more accurate than the hardware blanking signal which sometimes fails us because (a) it might slip out of phase or (b) doesn't see the Aerostat radar.

Here's a recent test example. First, a waterfall plot when the raw data was analyzed using the hardware blanking signal:

waterfall: hardware blanked file

Note the garbage that started happening around 2400 seconds into the analysis. Turns out this is that secondary Aerostat radar, which the software blanking analysis picked up. Check out the same raw data using the software blanking signal:

waterfall: software blanked file

Much better! At this point we're running all data, new and old, through the software blanking analysis suite, while sometimes using the hardware blanking signal (if it exists) for confirmation.

Return to Science Newsletter main menu

©2016 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.