Traduction de la lettre d'information Radar Blanking de Jeff Cobb.
Nous voudrions tenir tout le monde au courant au sujet des interférences qu'Eric a décrites sur son blog. Alors qu'il travaillait sur l'application multi-faisceaux du projet seti bêta, Eric a noté qu'un grand nombre de résultats débordaient. Trop de signaux étaient détectés, un signe que les données contenaient un grand nombre d'interférences en radio-fréquence (IFR). L'interférence se présentait sous forme de signaux pulsés.
La tâche ardue était alors de dénicher la source des IFR et de "la faire disparaitre " en éliminant la source ou, si cela échouait, de la retirer de nos données. À ce moment là, nous n'étions pas encore sûrs que ce soit de vraies IFR (un signal entrant dans le récepteur) ou un type d'interférences à l'intérieur de l'appareil d'enregistrement ou dans son électronique qui finirait par ressembler à des IFR. Nous avons testé nos données (rassemblées sur plusieurs mois et pour un nombre important de zones du ciel) et constaté que les interférences pulsées étaient constamment présentes. Ainsi la source était très locale. En commençant par la fin de la chaîne d'acquisition des données puis en remontant le processus, nous nous sommes déjà demandé si le logiciel d'enregistrement ne présentait pas un bug qui lui faisait introduire ces signaux pulsés. Non, des logiciels autonomes les ont également vus. Était-ce un problème de disque dur ou d'alimentation électrique ? Était-ce un problème dans l'électronique au début du processus ? Nous avons éliminé ces possibilités une par une. Il était temps de demander de l'aide au personnel de l'observatoire d'Arecibo.
Après avoir reçu l'appui d'un technicien radio et de l'expert IFR de l'observatoire d'Arecibo, nous avons rapidement résolu le problème. C'était de vraies IFR, provenant du radar de défense aérienne à l'autre bout de l'île (Porto Rico). Nous n'avions pas vu ces IFR dans nos données jusqu'à ce que nous ayons commencé des observations multi-faisceaux. Avant l'acquisition multi-faisceaux nous prenions en considération les données d'une antenne qui était moins élevée que le récepteur d'ALFA et étions ainsi dans l'ombre du radar caché par les collines environnantes.
Nous n'allons pas pouvoir retirer la source des IFR, donc il nous reste que la possibilité de la retirer de nos données. Eric a déjà commencé à développer un algorithme pour ça. Nos données, si elles sont bien exemptes d'IFR, ressemblent à du bruit. C'est à dire qu'en l'absence d'ExtraTerrestres ou d'autres phénomènes radio, nos données sont aléatoires. Donc l'algorithme de "débroussaillage" (scrub algorithm) doit détecter quand les IFR du radar sont présentes, et rendre aléatoire cette petite portion de donnée. Nous pouvons détecter le radar en examinant les données dans un logiciel de post-acquisition (la place logique serait dans le découpeur (splitter) mais nous devrons rester prudent pour éviter des débordements de résultats dans l'application Seti. En conséquence, le programme rendra aléatoire plus de données qu'il ne serait strictement nécessaire. Une meilleure solution serait de savoir d'une quelconque manière quand le radar nous frappe et ainsi de marquer les données en temps réel lors de l'acquisition. C'est ce que nous avons décidé de faire.
Il s'avère que ce radar est bien connu du personnel de l'observatoire. Il existe une antenne sur la plateforme qui supporte les récepteurs qui est conçue pour détecter le signal radar (l'antenne est pointée droit sur le radar et l'antenne alimente un récepteur développé pour détecter quand le radar est actif). L'électronique existe pour fournir cette détection à l'enregistreur de données. Le fait de détecter l'activité du radar (allumé ou éteint) s'appelle le "découpage radar" (radar blancking). Nous avons décidé que la façon la plus précise (et la plus aisée) d'encoder ce signal de découpage radar est d'indiquer l'état du radar directement dans le flux de données. L'enregistreur de données est conçu pour recevoir 16 entrées. Nous n'en utilisons que 14 (7 récepteurs ALFA, chacun étant sur 2 polarisations linéaires). Le signal de découpage radar ira ainsi dans un des canaux d'entrée inutilisés. Cela permettra au signal de découpage radar d'être exactement corrélé dans le temps avec nos données d'observation puisque les deux apparaitront ensemble dans notre flux de données. Avec les données comportant l'ajout du signal de découpage radar, le découpeur (le splitter) n'aura pas à déterminer si le radar est actif ou non. Il n'aura qu'à surveiller le canal du découpage radar et rendre aléatoire les données d'observation lorsque ce canal sera en position "ON". Bien entendu, nous allons devoir nettoyer toutes les données enregistrées lorsque l'acquisition du signal de découpage radar n'était pas implémenté. Pour ces données, le découpeur (splitter) devra déterminer si le radar était actif ou non et (de manière un peu plus aggressive) rendre ces données aléatoires.
Une petite interface électronique doit être mise au point. Dan et un ingénieur de l'équipe de l'observatoire, Dana Whitlow, le feront lorsque Dan sera à Porto Rico vers la mi-juillet pour une conférence sur l'astrobiologie. Lorsque le radiotélescope d'Arecibo sera de nouveau en ligne, lorsque la peinture sera terminée, nous devrions être tous prêts.