ADS-B: 14 juillet 2025 - Défilé aérien

Comme à chaque 14 juillet, mon radar virtuel me permet d'observer la préparation du défilé aérien avec ici encore une couverture permettant de bien identifier quelques zones d'attente.

Et puis le départ du défilé aérien jusqu'au final.

ADS-B: 14 juillet 2023 - Défilé aérien

Comme à chaque 14 juillet, mon radar virtuel me permet d'observer la préparation du défilé aérien avec cette année l'identification d'un drone 'aerobot' non identifié l'année dernière.

Les avions sont positionnés sur au moins cinq zones jusqu'à 10h30 environ avec le drone tournant du coté de Magny-en-Vexin.

Quelques 27 avions étaient visibles avec un code transpondeur et identification.

A 10h42, les premiers blocs quittent l’hippodrome de Magny.

Et quelques minutes plus tard, tout le monde converge au-dessus de Nanterre en alignement sur les Champs-Elysées. Les identifications MUS12x correspondent aux magnifiques Pilatus PC-21.

Encore un magnifique défilé avec en plus le plaisir d'avoir pu observer le déplacement des blocs d'hélicoptères sur l'horizon du coté des Ulis.

ADS-B: 14 juillet 2022 - Défilé aérien

Tout comme l'année dernière, mes récepteurs ADS-B m'ont permis de suivre la finale du passage des gros porteurs sur les Champs-Elysées. Je m'y suis pris un peu tard sans pouvoir suivre les préparatifs et les décollages mais la finale est propre. 

Deux hippodromes sont constitués à l'Ouest de Paris avec plusieurs avions en attente avec déjà des avions dans l'axe des Champs.

Une minute plus tard, l'alignement dans l'axe des Champs Elysées est parfait.

ADS-B: 14 juillet 2021- Défilé aérien

En ce jour de défilé sur les Champs-Élysées, mes récepteurs ADS-B se sont révélés bien utiles pour observer la préparation du survol de Paris, du moins pour les avions disposants d'un balise ce qui n'est pas le cas des chasseurs.

1- Hippodrome à l'ouest de Paris

2- Poursuite de l'hippodrome

3- Top départ

4- Retour

On notera un C135 en hippodrome au nord-ouest de Paris, l’atterrissage sur Vélizy et sur Villaroche d'une partie des avions.

ADS-B: Clef RadarBox vs Clef RTL-SDR

La mise à jour de la configuration de l'un des récepteurs ADS-B avec une clef RadarBox intégrant un filtre 1090Mhz en entrée sans aucune modification permet d'attendre les performances du récepteur RadarCape, du moins en terme de positions signalées sur FlightAware.

On voit très nettement que l'écart entre la courbe bleue (RadarCape) et orange (Dump1090) présent avant l'arrêt de ce dernier se réduit à 0 après le seul changement de la tête de réception.

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.

Divers: Ciel ... bien vide

Les effets du nouveau confinement commencent à être visibles avec moins d'une centaine d'avions suivis sur mon RadarCape. L'impact reste cependant moindre que lors du tout premier confinement mais le nombre de vols décroit très régulièrement depuis un mois.

Chiffres à comparer à ceux du mois de mai.

Divers: Ciel ... déconfinement

Des trainées de condensation  - Contrail - sont de nouveau régulièrement visibles depuis quelques jours. Le calme observé il y a un peu moins de deux mois avec moins d'une trentaine d'avions est bien terminé.

La courbe représentative des vols suivis et signalés sur le site FlightAware par mes deux récepteurs confirme bien cette tendance à la hausse avec un doublement du nombre d'avions signalés en une semaine.

Divers: Ciel ... vide

Les effets du confinement sont de plus en plus visibles: plus aucune trainée de condensation dans le ciel au sud de Paris et seulement 22 avions suivis sur mon RadarCape...

La diminution des vols est encore plus impressionnante sur la courbe représentative des vols suivis et signalés sur le site FlightAware par mes deux récepteurs: diminution d'un facteur de 6 entre le 16 mars et ce jour, 30 mars.

DDay 75: Espace aérien

Quelques aéronefs intéressants vus sur sur l'un de mes récepteurs ADS-B le 6 juin dernier. Le premier est un transporteur de la Royal Air Force effectuant sur une trajectoire d'attente plusieurs heures durant. Ici à 10h47.

Le second est un Hercule C-130J, toujours de la Royal Air Force, se dirigeant vers les plages du débarquement et vu à 11h08.

 Le second est un aussi Hercule C-130J mais de l'USCG (US Coast Guard) vu à 10h39.

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.

Projet ADS-B: Firmware 3.0

Le firmware PicADSB 3.0, et l'application WinADSB 0.9.0, sont disponibles.  Ces deux nouvelles versions corrigent un boggue se traduisant par l'impossibilité d'envoyer une commande sur le décodeur lorsque celui-ci est configuré pour transmettre ses données à 1Mbs et qu'aucune trame ADS-B est reçue dans le même temps. Un 'bête' problème dans la gestion des événements qui n'apparaît pas à basse vitesse de transmission, et qui m'a tout de même pris quelques heures à corriger.

La mise à jour est fortement recommandée.

Projet ADS-B: Firmware 2.9

Je n'ai guère eu le temps de faire avancer ce projet ces dernières semaines.

En fait le réaménagement de mon environnement m'a pris bien plus de temps que prévu avec notamment la découverte de problèmes divers sur les équipements, et ceci bien sûr après qu'ils aient été installés en rack. La loi de Murphy dans toute sa grandeur. Les choses s'étant semble-t-il stabilisées, avec la réinstallation du système dédié à la gestion de la carte Wavecom W61PC, des télécommandes et des liaisons VoIP, j'ai replongé dans le projet ADS-B.
Il faut dire que mon ami Guenter, DL4MEA, m'y a un peu poussé en améliorant le comparateur d'entrée de son kit pour obtenir une plus grande dynamique face à des signaux de niveau très variable. La technique retenue, fort astucieuse, ne permet cependant plus de garantir la présence d'un niveau bas en l'absence de signal. Le procédé d'acquisition du préambule de la trame ADS-B consistant à rechercher classiquement un changement d'état indiquant la réception d'une impulsion doit en conséquence être revu.
Le code de recherche et d'acquisition du préambule a donc été réécrit pour tenir compte de cette contrainte. J'ai profité de l'occasion pour réintégrer l'optimisation de l'automate que j'avais mise en oeuvre dans la version 1 - rebouclage des 12 états d'erreurs possibles sur l'état 2 de l'automate - puis rapidement abandonné ne trouvant pas l'astuce de programmation me permettant de faire coexister cette technique avec les contraintes imposées par la mise en place de l'horodatage des trames et la gestion des interruptions.
Quelques (difficiles) heures de réflexion m'ont finalement permis de venir à bout du problème. Comme bien souvent, le code final est tellement simple qu'on ne peut imaginer la complexité de sa construction s'agissant de garantir un temps d'exécution précis au cycle près, ici 83.333ns. Que de temps passé à vérifier la bonne synchronisation de l'échantillonnage du signal pour chacune des branches possibles du code.
C'est d'ailleurs durant l'une de ces vérifications que j'ai découvert un décalage d'un cycle présent dans les versions antérieures. Ce décalage, qui peut conduire à rejeter des trames longues, est impossible à annuler mais il peut être compensé sans impact sur le taux d'erreur en avançant d'un cycle l'échantillonnage suivant.
Je doute qu'il me soit maintenant possible d'aller plus loin que le code inclus dans le firmware 2.9 à paraître dans les jours à venir, du moins avec ce microcontrôleur.

Projet ADSB: MLAT sous Plane Plotter

Le firmware 2.8, actuellement en beta test, délivre les informations requises pour la fonctionnalité MLAT de l'application Plane Plotter. Il suffira pour celà de sélectionner le mode '4' (mode par défaut à partir de la version 2.8) et de configurer Plane Plotter pour le format dit 'AVR', l'application étant à même de détecter automatiquement la présence des informations dans la trame de données transmise.

La validation de ce mode de fonctionnement est en cours d'étude par Bev, l'auteur de Plane Plotter. Cette validation n'est pas évidente, et nécessiterait pour bien faire de disposer d'un récepteur SBS1, et d'un récepteur utilisant mon logiciel, pour vérifier la concordance des données calculées.