ADS-B: Clef RadarBox et Mise à jour Radarcape

Ce week-end a été l'occasion de mettre à jour ma configuration ADS-B constituée d'un Radarcape et d'un Raspberry PI doté d'une clef SDR, les récepteurs étant raccordés sur une antenne colinéaire placée à 3m au-dessus du toit, soit à plus de 170m d'altitude au sud de Paris. Autant dire un dégagement parfait sur 360°. Un splitter 'maison' est ici utilisé.

Ayant eu l'occasion d'acheter un lot de SDR, j'ai eu la bonne surprise de trouver dans le colis une clef RadarBox. Il s'agit d'une clef SDR incorporant un filtre 1090Mhz en entrée. J'ai donc remplacé la bonne vieille clef à base RTL-2832 par celle-ci avec une très légère amélioration. Le Raspberry Pi devrait se voir doter sous peu  d'un boitier moins fragile que le boitier actuel en plexiglas.

Pour ce qui concerne le Radarcape, la version Debian 8 installée n'étant plus supportée, j'ai effectué non sans difficulté la mise à jour sur une Debian 10. J'ai rapidement abandonné l'idée d'une  reconfiguration complète, une image pré-configurée étant proposé par 'JetVision', le fournisseur de ce récepteur.

Cette image est parfaite pour préparer une configuration spécifique, à savoir: installation d'une clef Wifi et configuration du réseau associé avec une adresse IP statique, configuration du réseau Ethernet avec une seconde adresse IP statique, désactivation du réseau IP V6, modification des comptes d'accès par défaut, installation de quelques utilitaires pratiques.

Une première configuration s'effectue en SSH sur l'adresse 192.168.73.1 affectée sur la connexion USB. Elle permet de configurer le réseau Ethernet sur son adresse statique via la commande 'connmanctl ethernet.... --ipv4 manual 192.168.1.X 255.255.255.0 192.168.1.1'. On en profite pour changer aussi le serveur DNS via un 'connmanctl ethernet.... --nameserver 192.168.1.1 8.8.8.8' et pour désactiver IP V6 via un 'connmanctl ethernet.... --ipv6 off'. Et enfin pour changer le mot de passe du compte 'jetvision' ('jetvision' par défaut), créer un compte dédié autorisé en sudo et modifier le mot de passe du compte  'root' ('radarcape' par défaut)

La configuration définitive s'effectue après redémarrage et la connexion du Radarcape sur le réseau Ethernet. On peut alors installer les paquetages requis dont le firmware du dongle wifi via un 'apt install firmware-realtek'. Le dongle peut ensuite être connecté en vérifiant qu'il est bien activé par un 'dmesg'. La configuration du Wifi peut commencer via les commandes 'connmanctl' ad'hoc en n'oubliant pas de lancer un 'connmanctl scan wifi' pour créer les tables de configuration. Il s'agira ensuite de reconfigurer Radarcape en activant les feeds si besoin. Dans mon cas, l'identifiant de connexion FlighAware (feeder-id) est récupéré sur le site FlighAware puis copié dans le fichier '/etc/piaware.conf' afin d'alimenter le compte attaché au Radarcape.

On vérifiera que tout fonctionne bien en se connectant sur le Radarcape puis sur le site de feed pour contrôler que les données sont bien transmises. Les fonctions d'affichage de l'état du système sont bien pratiques pour cela.

 

Ici, la charge système est très élevée (1.29) ce qui est indiqué par l'affichage en rouge de l'état (Load). Un point qu'il va me falloir investiguer.

ADS-B: Nouveau changement du mât ADS-B

Le mat supportant l'antenne colinéaire de réception ADS-B avait été modifié en août dernier. Les résultats étant excellents mais la hauteur du mat un peu trop élevée sans haubanage, l'antenne vient d'être de nouveau déplacée pour être installée sur l'une cheminée avec une antenne discone.

Les deux fixations libres sur le chien assis accueilleront sous peu une antenne pour la réception satellite méteo ainsi qu'une seconde discone.

ADS-B: Changement du mât

Le mat PVC installé en octobre 2016 donnait des signes de faiblesse depuis les tempêtes d'hiver et la chaleur de ces derniers mois. Ce mât a donc était remplacé par un tube d'aluminium de 30x2, certes plus lourd, mais aussi plus rigide. Le mât étant en aluminium il ne m'a pas été possible de réinstaller l'antenne active PA0RDT à mi-hauteur.

 

Je croise les doigts que cette installation plus lourde tienne les grands vents. Ce nouveau mât a donc été installé sur l'autre ensemble de potences, plus robuste. Les antennes précédemment installées - discone VHF et Dressler ARA-30 - ont été déposées pour réfection. Cette maintenance s'avère nécessaire car après plus 8 ans l'effet combiné du vent, des vibrations et des changements de température aura eu raison du frein-filet déposé sur les filetages des brins de la discone. Ceux-ci étaient bien dévissés et menaçaient de tomber à la prochaine tempête.

Je réfléchis maintenant à la configuration que je vais remonter n'ayant jamais réellement été satisfait de l'ARA-30 et souhaitant disposer d'une discone de meilleure qualité que la précédente. A suivre.

ADS-B: Radarcape - 6

La mise à jour dite 'Major 2' du firmware du radarcape est assez remarquable. Elle corrige de nombreux problèmes de performances et s'appuie sur le client PiAware pour transmettre les données sur le site FligthAware. Il est donc maintenant possible d'utiliser le MLAT. Un serveur NTP de strate 1 couplé au récepteur GPS peut aussi être utilisé pour synchroniser d'autres équipements.

L'installation s'est effectuée sans aucun problème. Il faut simplement penser à redémarrer le système pour que le feed soit correctement activé.  J'utilise actuellement le kernel  '4.12.3-bone2'.

Le radarcape est désormais identifié comme un fournisseur de type PiAware ce qui conduit à devoir réenregistrer l'équipement sous une autre identification, et du coup, perdre l'historique précédent.

Les performances restent toujours aussi bonnes et l'activation du MLAT permet d'améliorer encore celles-ci.

ADS-B: Radarcape - 5

La version 'rt' du kernel ne semble décidément pas améliorer la performance des traitements sur le radarcape. Le test effectué sur la version '4.8.6-bone2-rt-r2' montre que la CPU est utilisée à plus de 70% de son temps sur la gestion d'une interruption, probablement celle de la liaison série à 3mpbs connectant le FPGA au processeur. Je n'ai pas cherché plus en avant d'autant qu'un problème de stabilité reste présent dans la gestion de l'interface Wifi. 

Environ toutes les 30mn la connectivité est interrompue pour une durée pouvant aller jusqu'à 10mn sans que rien ne soit journalisé qui permette d'identifier le problème. Celui-ci a, temporairement et rapidement, été résolu par la mise en place d'un script. Ce script 'bash', lancé toutes les minutes via le 'cron', teste la connectivité de l'accès Internet (un simple 'ping' sur le routeur) et, en cas de problème, désactive puis réactive l'interface Wifi.

L'alimentation du site FligthAware n'a pas non plus été poser quelques soucis. Autant le 'RaspberryPi' avec son 'Dump1090' version 'fa' tourne comme une horloge, autant le 'Beaglebone' et son 'radarcape' n'est plus détecté actif par le site au bout d'environ 5mn.

 

Feed 'RadarCape'

Le transfert des données via une connexion HTTP s'effectue pourtant normalement mais le site FligthAware ne semble plus prendre en compte celles-ci. L'ajout d'une clause 'WatchdogSec=600' dans le fichier de configuration 'radarcape.service' conduit à réinitialiser celui-ci toutes les 6mn, sans grand problème de perte de données, et ainsi à maintenir le feed actif.

Feed 'Dump1090-fa'

Pour ceux que cela intéresse, les statistiques sont accessibles sous la référence utilisateur 'rxc'.

ADS-B: Radarcape - 4

Depuis quelques temps, la réception s’avère être très mauvaise, très peu d'avions étant reçus. Avant d'accuser l'antenne extérieure, quelques tests sont réalisés avec une antenne intérieure et la tête de réception du radarcape est vérifiée. 

Celle-ci s'avère être parfaitement fonctionnelle avec des niveaux d'amplification corrects:

- Signal injecté sur l'antenne:	-60dB
- Sortie du premier MMIC:	-42dB
- Sortie du premier filtre:	-52dB
- Sortie du second MMIC:	-33dB

Soit un bilan de 27dB avant le second filtre, 17dB donc de gain total.

Le mat est donc descendu et l'antenne inspectée. Le problème est rapidement identifié: de l'eau s'est infiltrée dans le tube et provoque un désaccord de l'antenne. Celle-ci est donc remontée en assurant l'étanchéité de chaque élément avec du joint silicone. 

Une seconde antenne - colinéaire - est intégrée directement dans le mat en PVC et sous l'antenne principale. Le coaxial de la première est enroulée autour afin de ne pas créer d'ombre sur un secteur fixe. Le mat est rallongé de 40cm afin de gagner en hauteur et de mieux recevoir les pistes d'Orly actuellement masquées.

L'antenne active HF retrouve sa place  aux deux tiers de la hauteur, l'antenne GPS étant placée en prolongation du montant de fixation le plus élevé. Le décodeur Radarcape est doublé d'un RaspberryPi 2 connecté sur la seconde antenne et faisant tourner le logiciel Dump1090.

La réception est de nouveau excellente avec quelques 150 avions suivis en fin de journée sur le RadarCape (sur une distribution Debian avec un kernel 4.8.5-bone2)). Il reste à espérer que le problème de passage d'eau dans l'antenne haute ne reviendra pas avec les mauvais jours.

Le logiciel Dump1090 (une distribution Raspbian avec un Kernel 4.4.26-v7) s'avère être un peu moins performant mais permet lui aussi une bonne couverture comme le montre la copie d'écran ci-dessous prise quelques secondes après la précédente.

Je dois avouer avoir été impressionné par  la fluidité de l'accès au Raspberry avec notamment des connexions immédiates ce qui n'est pas le cas du BeagleBone. J'envisage d'acquérir un SDR AirSpy pour tester le logiciel de décodage ad'hoc lequel devrait donner des résultats largement supérieur au Radarcape. Ce dernier utilise en effet une démodulation d'amplitude qui ne permet de séparer deux trames qui ne seraient pas tout à fait sur la même fréquence. Le logiciel livré avec AirSpy semble pouvoir séparer de telles trames et les décoder indépendamment.

ADS-B: Radarcape - 3

Le noyau Linux TI (4.4.23-ti-r51) s'avère être instable notamment lors d'un trafic intense. Cette instabilité peut conduire le système à ne plus répondre voire à rebooter.

Les événements enregistrés dans le journal système (fichier '/var/log/messages') mettent en évidence deux problèmes: un overrun  régulier sur la liaison série ttyS2 (message 'ttyS2: 3 input overrun(s)') ainsi qu'un blocage de la CPU (message 'NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!'). Plusieurs tests de versions alternatives de ce noyau TI dont la version RT mettent en évidence la même instabilité. 

J'ai donc installé le noyau bone (4.8.3-bone-rt-r1) lequel s'avère être plus stable même en conditions de charge élevée. Loi de Murphy oblige, au moment même de l'écriture de ce billet, la connexion SSH avec l'équipement vient de tomber, sans que l'équipement n'ait rebooté après plus de 14h de bon fonctionnement. Aucun événement particulier n'a été journalisé. Je considère toutefois que cette branche de noyau est la bonne.

 

La procédure de mise à jour est simple à condition de disposer d'assez de place libre sur la carte. 

1- Il s'agira tout d'abord de mettre à jour le catalogue local:

  sudo apt-get update

2- Puis de trouver le noyau à mettre à jour:

  sudo apt-cache search linux-image | grep bone

3- De charger celui-ci:

  sudo apt-get install linux-image-xxxxx

     avec xxxxx valant pour la version précédemment identifiée (ici '4.8.3-bone-rt-r1')
4- Et surtout de recopier le fichier de configuration faute de quoi le système ne redémarrera pas:

  cd /boot /dtsb

  sudo cp zzzzzz/bbb-4.1-radarcape.dtb xxxxx/

     avec zzzzzz valant pour la version active (ici '4.4.24-ti-rt-r57')

     avec xxxxx valant pour la version installée (ici '4.8.3-bone-rt-r1')

5- Et enfin de rebooter (et de croiser les doigts):

  sudo reboot

Il va de soi qu'il vaut mieux disposer d'une copie de l'environnement fonctionnel sur une seconde carte microSD ou sur la mémoire eMMC du beaglebone.

ADS-B: Radarcape - 2

L'antenne installée sous le toit vient de rejoindre sa place définitive à l'extérieur en haut d'un mat en PVC d'une hauteur permettant d'avoir une visibilité à 360° car dépassant du faîtage du toit. L'antenne GPS est installée sur un déport permettant d'avoir un bon dégagement.

Les résultats sont bons, voire trop bons puisqu'il m'a fallu installer un atténuateur de 18dB pour éviter la saturation du récepteur par les avions en approche ou décollage d'Orly. La couverture est plutôt correcte malgré l'atténuation.

Le décodeur Radarcape semble être très sensible à l'approche de la saturation, au point de voir le système hôte Debian ne plus répondre correctement.

ADS-B: Radarcape

En 2009, je finalisais un décodeur ADS-B embarqué sur un microcontrôleur PIC. La tête de réception était constituée d'un tuner pour la télévision numérique modifié pour les besoins, suivi d'une chaîne d'amplification et de filtrage et d'un détecteur log. Peu de temps après, ce développement donnait lieu à la réalisation par Günter, DL4MEA, d'une platine industrialisée dite 'PIBADSB8'. En parallèle Günter menait un développement visant à embarquer un décodeur dans un FPGA permettant ainsi de traiter un bien plus grand nombre de trames que ne le permettait un PIC. Ont ainsi été conçus les produits Beast et Radarcape que je n'avais jamais eu l'occasion de tester.

C'est désormais chose faite avec le Radarcape de SK François, F5ANN. Après un test rapide, je me suis lancé dans la mise à jour de la distribution Debian embarquée sur la carte Beaglebone Black utilisée par ce décodeur. Première surprise, la présence d'un code malveillant - Aiken - laissant entendre que ce dispositif avait fait l'objet d'une compromission visant à l’enrôler dans un réseau de Bot. Après nettoyage, et finalement réinstallation complète d'une distribution récente, le travail le plus compliqué a été engagé, à savoir disposer d'une configuration 'hot-plug' autorisant une connectivité Wifi par défaut et d'un secours LAN. Cela m'a permis de découvrir la complexité de la distribution Debian laquelle conserve des pans entiers du mécanisme 'init' tout en intégrant de manière encore incomplète le mécanisme 'systemd'. Ajoutons à cela des interactions parfois difficiles à maîtriser entre les applications 'networking', 'ifplugd', 'wpa_supplicant' et 'connman' et l'on comprendra qu'il m'aura fallu un week-end entier et plusieurs réinstallations pour arriver à la configuration souhaitée.

Le jeu en valait la chandelle puisque le décodeur tourne actuellement sur l'une des dernières versions du noyau - v4.4.23-ti-r51- avec une distribution Debian 8.6 et la dernière version du firmware radarcape disponible. L'ensemble est bootable sur carte microSD (la mémoire eMMC embarquée est chargée avec une version de récupération au cas où). Il s'avère être remarquablement stable.

L'objectif que je m'étais donné est désormais atteint: la connexion sur le réseau LAN entraîne immédiatement la déconnexion du réseau Wifi, lequel est automatiquement remonté lors de la déconnexion du réseau LAN. La carte Wifi peut être déconnectée puis reconnectée sans aucun problème. Les adresses sont configurées statiquement sur le même réseau.

Le dispositif est actuellement installé dans le grenier tête en bas pour lire à distance les indicateurs LED autrement masqués par la clef USB. Il est raccordé sur une antenne colinéaire conçue par François et sur une antenne GPS amplifiée. La synchronisation GPS est effective même sous un toit de tuiles mécaniques lourdes!

La portée est correcte pour cette configuration sans toutefois permettre de suivre les mouvements sur LFPO situé bien trop en contre-bas de ma position actuelle.