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.