Alors que nous pensions avoir terminé notre première station ADS-B sous Raspberry Pi, une nouvelle étape s’impose. Ce sixième article prolonge le précédent avec view1090, la multilatération, l’équipement fourni par RadarVirtuel et le partage simultané des données vers plusieurs réseaux collaboratifs.
Introduction
Dans le cinquième article, nous avons utilisé la Raspberry Pi pour recevoir les signaux Mode-S et ADS-B émis par les avions sur 1090 MHz. Nous avons installé plusieurs versions de dump1090, testé leurs limites, affiché les appareils détectés sur une carte locale et commencé à transmettre nos données vers des sites collaboratifs.
Ce sixième volet prolonge directement cette exploration. Alors que nous pouvions penser avoir fait le tour du sujet, il restait en réalité plusieurs points importants à aborder. Le suivi du trafic aérien ne se limite pas à l’affichage d’avions sur une carte. Il suppose aussi de comprendre comment les données circulent, comment elles peuvent être visualisées localement, comment elles sont partagées, et comment certains appareils peuvent être suivis même lorsqu’ils ne transmettent pas directement leur position.
Nous commencerons donc par revenir sur l’environnement dump1090, déjà installé pour fonctionner en continu. Dans cette configuration, l’affichage interactif que nous avions utilisé lors des premiers essais n’est plus toujours disponible. C’est ici qu’intervient view1090-mutability, un petit outil très pratique pour retrouver, dans une fenêtre de terminal, les avions reçus en direct et leurs principales informations.
Nous aborderons ensuite la multilatération, ou MLAT. Cette technique permet d’estimer la position d’un avion à partir de l’heure d’arrivée de ses signaux sur plusieurs récepteurs au sol. Elle devient particulièrement intéressante pour suivre certains appareils qui émettent des messages Mode-S, mais sans fournir de latitude ni de longitude. Pour y parvenir, notre station doit être correctement localisée, synchronisée et reliée à un serveur capable de réaliser les calculs nécessaires.
Ce travail nous conduira naturellement vers l’équipement fourni par RadarVirtuel. Nous verrons comment mettre en route une station préconfigurée, comment y accéder à distance, comment vérifier les services actifs et comment intégrer cet ensemble dans notre propre installation. Nous évoquerons aussi le partage simultané vers ADSBExchange, puis comparerons, sans prétention, les couvertures obtenues selon les solutions testées.
Ce sixième article est donc moins une rupture qu’un approfondissement. Après la découverte du suivi ADS-B, nous cherchons maintenant à rendre notre station plus complète, plus utile et mieux intégrée aux réseaux existants. La Raspberry Pi confirme ainsi son intérêt : elle peut fonctionner longtemps, discrètement, et devenir une véritable station de contribution au suivi aérien collaboratif.
Nous pouvons maintenant reprendre le fil du précédent article avec la suite consacrée à la bande UHF et aux signaux GPS ADS-B.
Rappel du principe de fonctionnement ADS-B (Source illustration : FlightRadar24)
- L’avion récupère sa localisation à partir d’un récepteur GPS,
- Le transpondeur ADS-B installé sur l’avion transmet un signal à 1090 MHz contenant cette information de position ainsi que d’autres données (N° du vol et indicatif, altitude, vitesse, vitesse ascensionnelle…),
- Le signal du transpondeur ADS-B est capté par les récepteurs au sol, équipés des logiciels de la famille dump1090,
- Ces récepteurs envoient les données reçues à Flightradar24 et/ou RadarVirtuel,
- Les données s’affichent sur leur site respectif et en local.
Bande UHF (signaux GPS ADS-B) (suite)
Dump1090 / Raspberry Pi OS (suite)
View1090-mutability
Le programme dump1090 étant installé pour travailler en continu avec envoi de données vers tel ou tel serveur distant, il n’est plus possible de visualiser « en direct » les écoutes comme nous aimions (peut-être) le faire par le biais de l’option –interactive.
Pour remédier à cela, un second programme existe. Il s’agit de view1090-mutability (ou view1090, ou view1090-fa selon le logiciel installé préalablement). En y ajoutant l’option –metric, nous pouvons même obtenir les données dans le système métrique et non plus anglosaxon :
- view1090-mutability –metric
Commande view1090-mutability –help
Commande view1090-mutability –metric
Multilatération / Raspberry Pi OS
Certains avions, tel que ce QID51, voient leur trajet affiché sur les sites collaboratifs avec l’indication MLAT (Multi-LATération) ou Mode-S. Comme ils n’annoncent pas leur position (latitude et longitude), l’affichage de leur trajectoire nécessite la mise en œuvre d’un calcul mathématique prenant en compte l’heure d’arrivée exacte du signal de transmission reçues par plusieurs récepteurs situés au sol à des emplacements connus. Même s’il est différent, ce calcul s’apparente à un calcul de triangulation dénommé multi-latération. C’est ce que font, parmi d’autres les sites coopératifs RadarVirtuel ou Adsbexchange. Pour cela les récepteurs doivent être équipées d’un client MLAT. Ceux-ci ne recevant pas les signaux exactement au même moment, le calcul nécessite, pour leurs récepteurs, l’utilisation d’une référence de temps identique telle que celle obtenue par synchronisation NTP avec Chrony. Contrairement à la triangulation, il ne s’agit pas ici de mesurer des angles, mais des distances. (Capture : Suivi d’un avion militaire par multilatération)
Pour installer ce client, j’ai à nouveau fait appel à l’équipe de RadarVirtuel. Ils m’ont alors guidé dans la procédure suivante :
Récupération et installation du client MLAT :
- wget https://github.com/abcd567a/mlat-client-package/releases/download/v1/mlat-client_0.2.11_BUSTER_armhf.deb
- sudo dpkg -i mlat-client_0.2.11_BUSTER_armhf.deb
Edition et modification du fichier de configuration /etc/default/mlat-client. Voici ci-dessous une reprise de ce fichier, avec en rouge, les données modifiées :
pi@raspberrypi:~ $ cat /etc/default/mlat-client
# mlat-client configuration file
# This is a POSIX shell fragment.
# You can edit this file directly, or us
# « dpkg-reconfigure mlat-client »
# Start the client?
START_CLIENT= »yes »
# System user to run as.
RUN_AS_USER= »mlat »
# User to log into the server as
SERVER_USER= »lfcz » [Le code de votre station tel que radarvirtuel vous l’a fourni.]
# Logfile to log to
LOGFILE= »/var/log/mlat-client.log »
# Input receiver type (dump1090, beast, radarcape_12mhz, radarcape_gps, sbs)
INPUT_TYPE= »dump1090″
# Input host:port to connect to for Beast-format messages
INPUT_HOSTPORT= »localhost:30005″
# Multilateration server host:port to provide data to
SERVER_HOSTPORT= »[IP server]:yyyyy [L’IP du serveur et son port d’écoute fournis par radarvirtuel.]
# Latitude of the receiver, in decimal degrees
LAT= »44.xxxxxx »
# Longitude of the receiver, in decimal degrees
LON= »-1.xxxxxx »
# Altitude of the receiver, in metres
ALT= »10″
# List of result connections/listeners to establish.
# This should be a space-separated list of values suitable for passing to
# the –results option (see mlat-client –help for syntax)
RESULTS= »beast,connect,localhost:30004″
# Other arguments to pass to mlat-client
EXTRA_ARGS= » »
Cette configuration entrainera le lancement du programme avec les options suivantes (commande systemctl status) :
/usr/bin/mlat-client –user [CODE STATION] –lat 44.07930 –lon -1.25850 –alt 25 –input-type dump1090 –input-connect localhost:30005 –server [IP SERVER:PORT] –results beast,connect,localhost:30004
Commande mlat-client — help
Pour vérifier le bon fonctionnement du système, il ne vous reste plus qu’à vous déplacer dans le répertoire /var/log pour vérifier le contenu du (des) fichier(s) mlat-client.log.
Extrait du répertoire /var/log
Cinq fichiers sont disponibles : l’un relatif au jour présent, les quatre autres aux quatre précédents. On y retrouve une indication des données Mode-S envoyées au serveur.
Extrait du fichier mlat-client.log
La capture d’écran suivante montre le trajet d’un tel avion au-dessus des Landes. Il s’agit sans doute d’un avion de l’Armée de l’air française, en manœuvre, ayant décollé de la base aérienne 118 « Colonel Rozanoff » située à Mont-de-Marsan.
Trajet d’un avion militaire repéré grâce à ses signaux Mode-S
Équipement envoyé par RadarVirtuel
Envoi radarvirtuel
Ayant souhaité tester l’équipement standard radarvirtuel, je le reçois quelques jours plus tard, par la poste. Mon colis comprend :
- Une antenne verticale 1090MHz,
- Une base d’antenne réalisée à l’aide d’un tube PVC Tubifor de 25mm de diamètre,
- Un câble d’antenne de 5m, avec prises SMA,
- Une carte Raspberry Pi 4b avec boitier radiateurs de refroidissement,
- Un récepteur USB SDR ADS-B Flightaware Pro Stick Plus,
- 2 cartes MicroSD préconfigurées. L’une insérée dans la Pi, l’autre en secours,
- Une alimentation 220Volts AC vers 5,1Volt DC / 3 ampères,
- Prolongateur USB et rallonge secteur.
Pour sa première mise sous tension, la carte doit être reliée à votre box Internet à l’aide d’un câble RJ45. Vous devrez ensuite, au travers du panneau d’administration de cette box, noter l’adresse IP qui lui aura été attribuée.
L’adresse IP de la carte Raspberry Pi et son accès au travers de Putty
Cette carte n’a pas d’interface graphique (telle que Pixel desktop). VNC n’est donc pas en place. Elle est néanmoins accessible sous SSH, au travers des logiciels Putty et WinSCP . Le nom d’utilisateur est root, le mot de passe vous sera fourni avec l’envoi.
Premier accès sur la carte avec Putty
Avant de mettre en place le Wi-Fi, il y a lieu de modifier le pays à associer à notre future connexion sans fil. Après lancement de raspi-config (et approbation pour l’utilisateur pi inexistant) il faut faire les choix suivants :
5 Localisation Options
L4 WLAN Country
Choisir la France et confirmer votre choix lorsqu’apparait une nouvelle fenêtre (le curseur étant sur OK, tapez ENTER). On ajustera ensuite le fuseau horaire :
5 Localisation Options
L2 Timezone
Après avoir confirmé par OK le choix Europe, sélectionnez Paris, confirmez par OK et rebootez la machine.
L’étape suivante consiste – comme nous l’avons montré précédemment. – à modifier les fichiers /etc/wpa_supplicant/wpa_supplicant.conf et /etc/dhcpcd.conf afin d’activer la connexion Wi-Fi.
Si nous possédez un LNA, il faudra aussi mettre en place le logiciel rtl_biast pour son alimentation :
- cd /home/py
- sudo apt-get update
- sudo apt-get install git cmake build-essential libusb-1.0-0-dev
- git clone https://github.com/rtlsdrblog/rtl_biast
- cd rtl_biast
- mkdir build
- cd build
- cmake .. -DDETACH_KERNEL_DRIVER=ON
- make
La commande suivante permet ensuite de vérifier si l’installation s’est bien déroulée (donc l’absence de message d’erreur) :
- sudo service dump1090-mutability stop && cd /home/py/rtl_biast/build/src && ./rtl_biast -d 001090 -b 1 && sudo service dump1090-mutability start
NOTA : Au tout premier lancement du visionneur (http://[IP FIXE DE LA PI]/dump1090/gmap.html), il faut réinitialiser l’aperçu afin de repositionner correctement notre station sur la carte. Sans cela – dans mon cas – elle se retrouvait à Rennes, lieu de configuration de la Pi reçue.
Ceci fait, il ne reste plus qu’à modifier le fichier /etc/init.d/dump1090-mutability en y ajoutant les lignes de commande déjà citées dans le précédent paragraphe.
Lancé depuis un PC connecté au réseau local, un accès sur le visionneur, suivi d’une réinitialisation (choix Réinitialiser), nous confirme le bon fonctionnement de l’ensemble. Au fil des minutes, la carte montrant la couverture d’écoute de notre antenne se dessine à l’écran.
Mais, curieusement, je ne constate aucune amélioration de couverture d’écoute avec ou sans LNA alimenté. Après vérification au multimètre numérique, il s’avère que les clés FlightAware ne laissent pas passer le +5 Volt DC. Un simple échange standard avec ma clé RTL-SDR V3 me confirme que le problème vient bien de la clé.
Interface locale radarvirtuel avec clé FlightAware et LNA (non) alimenté. Peu d’avions sont visibles
Interface locale radarvirtuel avec clé RTL-SDR V3 et LNA (bien) alimenté. De nombreux avions sont visibles
Notons pour finir le contenu du fichier /etc/rc.local qui lance :
- le feeder (sh),
- la synchronisation de l’horloge système avec un serveur NTP.
Comme ces programmes effectuent une boucle infinie sans rendre la main au script, ils doivent être lancés en tâche de fond. C’est à ce titre qu’est ajouté un & après chaque commande.
Quant à l’opérateur &&, il permet l’enchainement de 2 commandes ; la seconde ne s’exécutant qu’après réussite de la première.
Fichier rc.local d’une station radarvirtuel
Le système étant maintenant fonctionnel il ne reste plus qu’à le mettre en boite et à le fixer sur un mur extérieur, non loin de l’antenne et à portée du Wi-Fi. Le module 220Volts AC vers 5,1Volt DC est à l’intérieur de la maison, Un câble de quelques mètres amène le courant continu au boitier. Pour cette installation, j’ai remis la clé d’origine Flightaware Pro Stick Plus car la longueur de câble entre celle-ci et l’antenne ne nécessite plus l’utilisation du LNA.
Installation en fixe du matériel radarvirtuel
Partage simultané sur adsbexchange.com
Malgré un fonctionnement parfait en lien avec radarvirtuel, je me retrouve déçu par l’affichage des trajets aériens repérés en mode S (MLAT). Plusieurs avions de tourisme survolant mon QRA restent souvent invisibles sur la carte https://alpha.radarvirtuel.com/, alors qu’ils apparaissent clairement sur celle proposée par le site https://globe.adsbexchange.com/ (j’ai constaté plus tard que l’inverse était également vrai !!). De plus, un système de filtres étendu permet d’aisément de les isoler.
Carte adsbexchange.com après filtrage sur le mode MLAT
Ayant contacté à ce sujet les administrateurs du site radarvirtuel, ceux-ci m’indiquent que cette partielle invisibilité s’explique par le manque de stations d’écoute dans ma région. AVIS AUX AMATEURS : il en faudrait 2 ou 3 de plus, autour de mon QRA, dans un rayon de 30Km.
Après avoir fait une sauvegarde de ma carte SD, je tente donc d’installer (sous root) un second feeder me permettant d’envoyer, en simultané, mes informations sur les 2 sites, et selon la procédure décrite ici : https://www.adsbexchange.com/how-to-feed/ :
- wget -O /home/py/axfeed.sh https://adsbexchange.com/feed.sh
- sudo bash /home/py/axfeed.sh
Après lancement du script, une fenêtre de configuration s’ouvre avec une suite de questions permettant la configuration du feeder :
- Un intitulé pour votre station,
- Sa latitude,
- Sa longitude,
- Son altitude.
Configuration du feeder adsbexchange.com
L’installation se poursuit ensuite avec toute une série d’instructions, et par étape selon une chronologie numérotées de 1 à 100. Il ne faut pas s’inquiéter si l’écran se fige quelques minutes. Lorsque l’installation se termine n’omettez pas de noter les liens http ainsi que la commande permettant l’installation de l’interface web.
Fin de processus d’installation
Et comme indiqué, il faut ensuite bien attendre 5 minutes avant de recevoir confirmation du bon fonctionnement de l’ensemble sur https://www.adsbexchange.com/myip/
Confirmation d’une bonne installation
La commande systemctl status permet de visualiser les nouveaux services créés, avec l’ensemble des options nécessaires :
- /bin/bash /usr/local/share/adsbexchange/adsbexchange-mlat.sh
- /usr/local/share/adsbexchange/venv/bin/python3 /usr/local/share/adsbexchange/venv/bin/mlat-client –input-type dump1090 –no-udp –input-connect 127.0.0.1:30005 –server feed.adsbexchange.com:31090 –user StJulien –lat 44.0793036 –lon -1.2585172 –alt 10m –results beast,connect,localhost:30104 –results basestati
- /bin/bash /usr/local/share/adsbexchange/adsbexchange-feed.sh
- /usr/local/share/adsbexchange/feed-adsbx –net –net-only –debug=n –quiet –write-json /run/adsbexchange-feed –net-beast-reduce-interval 0.5 –net-connector feed.adsbexchange.com,30004,beast_reduce_out,feed.adsbexchange.com,64004 –net-heartbeat 60 –net-ro-size 1280 –net-ro-interval 0.2 –net-ro-port 0 –net-sbs-port 0 –net-bi-port 30154 –net-bo-port 0 –net-ri-port 0 –write-json-every 1 –net-connector 127.0.0.1,30005,beast_in –lat 44.0793036 –lon -1.2585172 –db-file none
La visite de l’URL : https://map.adsbexchange.com/mlat-map/ confirme le bon fonctionnement en échanges MLAT, avec, en vert les liens de bonne qualité.
Visualisation des liens d’échanges MLAT
Il ne reste plus maintenant qu’à installer l’interface web locale :
- sudo bash /usr/local/share/adsbexchange/git/install-or-update-interface.sh
À l’issue de l’exécution du script, il est possible de visualiser les données récoltées par notre station à l’adresse : http://192.168.1.162/adsbx/. L’avantage de cette page est la mise à disposition des filtres permettant d’isoler les avions selon le mode de transmission des données : ADS-B, MLAT et/ou Mode-S (les modes TIS-B et UAT / ADS-R étant valides aux USA sur la fréquence de 978 MHz) et s’ils sont militaires, ou non (les choix PIA (Privacy ICAO Address) et LADD (Limited Aircraft Data Displayed) concernent des vols « confidentiels » qui sont difficilement identifiables par des récepteurs peu coûteux et disponibles dans le commerce.
Vol MLAT sur l’interface web locale adsbexchange
Vol Mode-S sur l’interface web locale adsbexchange
Sélection des vols militaires avec adsbexchange
Vol militaire AlphaJet RIC61sur l’interface web locale adsbexchange
Vol militaire AlphaJet RIC61sur le serveur adsbexchange
Petit comparatif de couverture aérienne sans prétention
Couverture aérienne mondiale. En haut, à gauche : Radarvirtuel avec environ 3000 avions visibles pour 600 radars dans le monde. En haut, à droite : PlaneFinder. En bas, à gauche Adsbexchange avec environ 9000 avions visibles pour 6000 radars dans le monde. En bas, à droite FlightRadar24 avec environ 12000 avions. Notez la présence de quelques ballons au-dessus des Etats-Unis.
Couverture aérienne sur l’Europe. En haut, à gauche : Radarvirtuel. En haut, à droite : PlaneFinder. En bas, à gauche Adsbexchange. En bas, à droite FlightRadar24.
La couverture MLAT et Mode-S semble plus efficace sur radarvirtuel et adsbexchange. Ces deux sites affichent plus de vols militaires que leurs concurrents. Selon leur couverture, certaines portions de trajets ne sont visibles que sur l’une des deux cartes. Léger avantage à adsbexchange qui, avec tar1090, propose des jeux de filtres pour mieux les visualiser.
Pour conclure, j’ai un petit faible pour adsbexchange. Mais radarvirtuel étant français, je pense que notre rôle est de le faire connaitre et de tout faire pour le nombre de leurs feeders augmente, en France, bien sûr, mais aussi aux 4 coins du monde.
Configuration définitive
Au moment de conclure mes articles sur l’environnement Raspberry Pi, j’étais sur le point de rejoindre la région parisienne pour me retrouver à 700 kilomètres de mon boitier radarvirtuel/adsbexchange maintenant positionné, à demeure, sur le mur extérieur de ma résidence secondaire.
Alors qu’il m’était possible, en local, de l’atteindre depuis mon PC avec Putty, cette solution allait, bien entendue, devenir inapplicable. Et souhaitant garder le contact, il n’était pas envisageable d’utiliser un ensemble VNCServer/VNCViewer puisque ma carte Pi ne possédait pas d’environnement graphique.
Après une brève recherche Internet, j’ai appris que Putty existait aussi dans le monde Raspbian. Je décidais donc de l’installer sur ma (seconde) Raspberry Pi ; celle accueillant Gqrx et l’ensemble des logiciel dédiés à la traque des ballons sondes :
- sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get install putty
Suite à cela, l’appel de putty dans ma fenêtre Terminal faisait apparaitre son interface habituelle.
Putty sous Raspbian OS
Et malgré le message d’erreur répété 3 fois :
(putty:31964): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion ‘size >= 0’ failed in GtkScrollbar
… tout a fonctionné correctement. Je pouvais partir tranquille.
Voici donc ma configuration finale :
Configuration finale pour un accès à distance
Exemple : Depuis la région parisienne, je me connecte à Raspi 1 à l’aide de VNC. Depuis cette carte, je lance l’interface visuelle locale ([MON_IP]/dump1090/gmap.html). Toujours depuis cette carte, je lance PuTTY pour me connecter en SSH à Raspi 2. Sur Raspi 2, je lance view1090-mutability.
François Paget est aujourd’hui retraité. Membre fondateur du McAfee Labs, il y travailla de 1993 à 2016 comme spécialiste de la sécurité informatique et de la cybercriminalité. Il s’est notamment intéressé aux programmes malveillants, aux nouvelles menaces numériques, à la fraude financière et aux cyber-conflits. Longtemps Secrétaire général du CLUSIF, il anima son Panorama de la Cybercriminalité de 2002 à 2017 et publia en 2005, chez Dunod, l’ouvrage Vers & Virus.
Toujours curieux de techniques nouvelles, il s’est également passionné, à partir de 2021, pour la radio logicielle, ou SDR. Il a depuis publié plusieurs articles de vulgarisation consacrés au décodage de signaux numériques, notamment dans la revue Radioamateurs France et sur les sites ON5VL et HamAnalyst. Ses expérimentations récentes portent en particulier sur la réception ADS-B dans la bande des 1090 MHz.
Avec son épouse Yvette, il partage son temps entre la région parisienne et les Landes. Ils ont trois enfants et six petits-enfants.
