Technique SDR 6

Sixième Partie : Découverte de la réception SDR sous Raspberry Pi OS

Trafic aérien (suite) – Introduction

Avec ce sixième article, et dans l’environnement Raspberry Pi, nous avons entrepris l’écoute radio des données de vol ADS-B émises directement par les avions, et permettant de connaitre leurs positions exactes.
Alors que je pensais en avoir terminé, pouvant ainsi passer aux autres communications aériennes, force m’a été de constater qu’il n’en était rien. Alors que j’écrivais l’addendum sur view1090, je recevais un paquet de l’équipe radarvirtuel avec l’une de leur station à installer. Voilà donc pourquoi ce sixième article n’est que la suite du précédent.

Quoi décoder ?

Voici, mis à jour, le tableau présentant un aperçu des décodages traités dans cette série d’articles. Les cases vierges dans la dernière colonne signifient que la réception sera traitée dans les mois qui viennent.

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.

par François F-80543 | F-80543