Alimenter plusieurs réseaux ADS-B en même temps avec Docker et Ultrafeeder

D’abord PiAware, puis fr24feed, puis encore le script pour adsb.fi et un autre pour adsb.lol – qui laisse son récepteur grandir au fil des années finit par avoir un système plein de services, de fichiers de configuration et de dépendances. La communauté sdr-enthusiasts suit une autre voie : un seul conteneur Docker nommé Ultrafeeder prend en charge le décodage, la carte, les statistiques et tous les flux communautaires, et chaque réseau supplémentaire s’ajoute comme conteneur propre, bien séparé. Ce guide te montre comment alimenter plusieurs réseaux ADS-B en même temps avec Ultrafeeder, de quels fichiers tu as besoin et comment garder une vue d’ensemble.

La réponse courte

Tu alimentes plusieurs réseaux en même temps en installant Docker sur un ordinateur Linux et en créant un docker-compose.yml avec le conteneur Ultrafeeder comme centrale. Ultrafeeder lit ta clé SDR, décode les signaux avec readsb et envoie les données à tous les réseaux communautaires que tu enregistres dans la variable ULTRAFEEDER_CONFIG. Les services commerciaux comme FlightAware ou Flightradar24, tu les raccordes comme conteneurs supplémentaires, qui obtiennent leurs données de la centrale via BEASTHOST=ultrafeeder. Coordonnées, altitude et clés sont rassemblées dans un fichier .env.

Le principe est le même qu’avec les scripts individuels de Alimenter ADS-B Exchange et les réseaux communautaires : un décodeur produit un flux de données, plusieurs feeders le récupèrent. Sauf qu’avec Docker, chaque élément tourne dans sa propre capsule.

Pourquoi Docker pour un récepteur ADS-B ?

Les sdr-enthusiasts justifient leur approche dans leur guide par plusieurs points, directement parlants pour les spotteurs dont le zoo de feeders s’agrandit :

• Isolation : chaque conteneur apporte son propre logiciel. Des versions différentes de bibliothèques ne se gênent pas, et le système hôte reste propre.
• Extension facile : un nouveau réseau signifie un conteneur de plus ou deux lignes de configuration – pas de crainte qu’un script d’installation écrase quelque chose.
• Configuration centralisée : au lieu d’entretenir des fichiers sous /etc/default/ et dans divers dossiers de programmes, tout se trouve dans le fichier Compose et le fichier .env.
• Matériel partagé : l’ordinateur peut héberger d’autres services en plus. Cela économise un appareil supplémentaire et de l’électricité.

Le prix : tu dois connaître quelques notions de base de Docker ou être prêt à les apprendre. Qui ne veut alimenter qu’un réseau et a déjà un Pi qui tourne arrive souvent plus vite au but avec les paquets classiques. Un aperçu de toutes les variantes est donné par Comparatif des programmes de feeder ADS-B.

Ce que contient l’Ultrafeeder

Ultrafeeder n’est pas un nouveau programme, mais un paquet soigneusement ficelé d’outils open source éprouvés :

Composant	Rôle
readsb	Décode les signaux de la clé SDR et distribue les données via des ports réseau
tar1090	Interface cartographique dans le navigateur, avec relecture, traces des dernières 24 heures et carte de chaleur
graphs1090	Diagrammes sur le taux de messages, la portée, la puissance du signal et la charge du système
mlat-client	Une instance par serveur MLAT enregistré
Hub MLAT	Rassemble les positions MLAT calculées de plusieurs sources
Autogain	Régule le gain du RTL-SDR, la variante intégrée de readsb est recommandée

Si tu connais déjà readsb et tar1090, tu t’y retrouves tout de suite – les interfaces sont les mêmes que dans Installer readsb et tar1090. La nouveauté, c’est que tout tourne dans un conteneur et se pilote par des variables d’environnement.

Préparation : matériel et système hôte

Côté matériel, il te faut l’habituel : un ordinateur, une clé SDR et une antenne 1090 MHz. Quelle clé convient, Comparatif des clés SDR pour l’ADS-B le clarifie ; l’antenne, tu la construis d’après Construire soi-même une antenne 1090 MHz. L’ordinateur n’a pas besoin d’être un Raspberry Pi ; le guide de sdr-enthusiasts s’adresse aux systèmes basés sur Debian comme Raspberry Pi OS, Ubuntu ou DietPi. Des alternatives possibles au Pi sont décrites dans Réception ADS-B sans Raspberry Pi.

Pour le système hôte, le projet fournit un script d’installation qui met en place Docker et le plugin Compose, adapte les règles udev pour les clés RTL-SDR et bloque les pilotes de noyau préinstallés pour les clés, afin que les conteneurs puissent accéder à la clé :

bash <(curl -s https://raw.githubusercontent.com/sdr-enthusiasts/docker-install/main/docker-install.sh)

Comme toujours avec les scripts venus du web : lis-le avant. Le projet lui-même recommande exactement cela.

Renommer la clé

Presque toutes les clés RTL-SDR sortent d’usine avec le même numéro de série. Pour que le conteneur trouve la bonne clé – au plus tard quand une deuxième s’ajoute pour la radio aéronautique ou l’UAT –, tu attribues un numéro de série unique. La recommandation est 1090 pour la clé ADS-B. Pour cela, tu ne branches que cette clé et tu écris le numéro avec rtl_eeprom depuis l’image Ultrafeeder :

docker run --rm -it --device /dev/bus/usb --entrypoint rtl_eeprom ghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder -s 1090

Après confirmation, tu retires la clé et tu la rebranches. Un redémarrage de l’ordinateur ne suffit pas, selon le guide.

Dossier du projet et fichier .env

Le guide place tout sous /opt/adsb. S’y trouvent le fichier Compose et un fichier .env caché avec tes données de base :

sudo mkdir -p -m 777 /opt/adsb
cd /opt/adsb
nano .env

Dans le .env vont entre autres ces valeurs :

FEEDER_LAT=48.1234567
FEEDER_LONG=11.1234567
FEEDER_ALT_M=520
FEEDER_TZ=Europe/Berlin
FEEDER_NAME=ma-station
ADSB_SDR_SERIAL=1090
ADSB_SDR_PPM=
ULTRAFEEDER_UUID=

Les chiffres sont des valeurs fictives – saisis tes propres valeurs. FEEDER_NAME est transmis plus tard aux réseaux comme nom MLAT ; choisis-le de façon à pouvoir vivre avec s’il apparaît publiquement. Tu génères une UUID avec :

cat /proc/sys/kernel/random/uuid

Important pour la protection des données : le guide met en garde contre l’utilisation de la même UUID pour tous les réseaux, car ta station serait sinon reconnaissable d’un service à l’autre. Génère donc une UUID propre à chaque réseau et enregistre-la sous des noms parlants comme ADSBFI_UUID ou ADSBLOL_UUID dans le .env.

Le docker-compose.yml avec Ultrafeeder

Voici maintenant le cœur. Un exemple abrégé, inspiré du guide de sdr-enthusiasts, avec deux réseaux communautaires :

services:
  ultrafeeder:
    image: ghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder
    container_name: ultrafeeder
    hostname: ultrafeeder
    restart: unless-stopped
    device_cgroup_rules:
      - "c 189:* rwm"
    ports:
      - 8080:80
    environment:
      - LOGLEVEL=error
      - TZ=${FEEDER_TZ}
      - READSB_DEVICE_TYPE=rtlsdr
      - READSB_RTLSDR_DEVICE=${ADSB_SDR_SERIAL}
      - READSB_RTLSDR_PPM=${ADSB_SDR_PPM}
      - READSB_GAIN=auto
      - READSB_LAT=${FEEDER_LAT}
      - READSB_LON=${FEEDER_LONG}
      - READSB_ALT=${FEEDER_ALT_M}m
      - UUID=${ULTRAFEEDER_UUID}
      - MLAT_USER=${FEEDER_NAME}
      - ULTRAFEEDER_CONFIG=
          adsb,feed.adsb.fi,30004,beast_reduce_plus_out,uuid=${ADSBFI_UUID};
          mlat,feed.adsb.fi,31090,uuid=${ADSBFI_UUID};
          adsb,in.adsb.lol,30004,beast_reduce_plus_out,uuid=${ADSBLOL_UUID};
          mlat,in.adsb.lol,31090,uuid=${ADSBLOL_UUID}
    volumes:
      - /opt/adsb/ultrafeeder/globe_history:/var/globe_history
      - /opt/adsb/ultrafeeder/graphs1090:/var/lib/collectd
      - /proc/diskstats:/proc/diskstats:ro
      - /dev/bus/usb:/dev/bus/usb:rw
    tmpfs:
      - /run:exec,size=256M

Les valeurs entre ${...} sont lues automatiquement par Docker Compose depuis le .env du même dossier. L’entrée tmpfs place les données volatiles en mémoire vive et ménage ainsi la carte SD. Les chemins sous volumes font en sorte que l’historique de la carte et les statistiques survivent à un redémarrage du conteneur. Le modèle complet et à jour avec toutes les variables optionnelles se trouve dans le guide et dans le dépôt GitHub du projet – en cas de doute, reprends leur version.

Comment lire ULTRAFEEDER_CONFIG

Chaque entrée commence par un type :

• adsb,<hôte>,<port>,<protocole> envoie tes données ADS-B à un serveur ou va chercher des données auprès d’une source. Pour la plupart des réseaux récents, le projet recommande le protocole beast_reduce_plus_out, un format Beast allégé.
• mlat,<hôte>,<port> lance une instance mlat-client propre pour ce serveur.
• mlathub,<hôte>,<port>,<protocole> reçoit les résultats MLAT d’autres feeders et les rassemble.

En option, tu ajoutes uuid=.... Si elle manque, le conteneur utilise la variable générale UUID. Les entrées sont séparées par un point-virgule, et à l’intérieur d’une entrée, ni point-virgule supplémentaire ni virgule ne doivent figurer dans les valeurs.

Réseau	Données (hôte, port)	MLAT (hôte, port)
adsb.fi	feed.adsb.fi, 30004	feed.adsb.fi, 31090
adsb.lol	in.adsb.lol, 30004	in.adsb.lol, 31090
airplanes.live	feed.airplanes.live, 30004	feed.airplanes.live, 31090
Planespotters	feed.planespotters.net, 30004	mlat.planespotters.net, 31090
ADS-B Exchange	feed1.adsbexchange.com, 30004	feed.adsbexchange.com, 31090

Les adresses proviennent du README du projet Ultrafeeder, données d’octobre 2026. D’autres réseaux, parfois régionaux, y figurent encore. Comme les noms d’hôtes peuvent changer, compare-les avec la liste actuelle avant de les saisir. Quelle carte montre quoi, Sites de suivi communautaires sans filtre en comparaison le compare ; des informations de fond sur ADS-B Exchange sont fournies par ADS-B Exchange expliqué.

Démarrer et vérifier

On démarre dans le dossier du projet avec :

docker compose up -d

Au bout d’une ou deux minutes, tu ouvres dans le navigateur http://<ip-de-ton-ordinateur>:8080/. La carte tar1090 y apparaît avec tes réceptions. Des ajouts utiles sont /graphs1090/ pour les statistiques ainsi que les paramètres ?pTracks pour les traces des dernières 24 heures, ?heatmap pour une carte de chaleur et ?replay pour la relecture. Ce que les diagrammes révèlent de ton antenne, Mesurer les performances de réception avec graphs1090 l’explique.

Réseaux commerciaux comme conteneurs propres

FlightAware, Flightradar24 et d’autres services commerciaux exigent leurs propres programmes de feeder avec des clés. Là aussi, sdr-enthusiasts propose des images toutes faites. Le schéma est toujours le même : le conteneur reçoit BEASTHOST=ultrafeeder, y récupère le flux de données de la centrale et s’annonce auprès du service avec ta clé du .env.

Service	Image	Variable de clé	Interface locale dans l’exemple
FlightAware	ghcr.io/sdr-enthusiasts/docker-piaware	FEEDER_ID	Port 8081 (SkyAware)
Flightradar24	ghcr.io/sdr-enthusiasts/docker-flightradar24	FR24KEY	Port 8754
AirNav Radar	ghcr.io/sdr-enthusiasts/docker-airnavradar	SHARING_KEY	–
Plane Finder	ghcr.io/sdr-enthusiasts/docker-planefinder	SHARECODE	Port 30053

Le guide propose en outre des instructions pour le réseau OpenSky, ADSBHub, Plane.watch, RadarVirtuel et d’autres réseaux. Un exemple pour FlightAware ressemble à ceci :

  piaware:
    image: ghcr.io/sdr-enthusiasts/docker-piaware:latest
    container_name: piaware
    restart: unless-stopped
    ports:
      - 8081:8080
    environment:
      - BEASTHOST=ultrafeeder
      - MLAT_RESULTS_BEASTHOST=ultrafeeder
      - MLAT_RESULTS_BEASTPORT=31004
      - TZ=${FEEDER_TZ}
      - FEEDER_ID=${PIAWARE_FEEDER_ID}
    tmpfs:
      - /run:exec,size=64M
      - /var/log

Les deux lignes MLAT_RESULTS renvoient les positions MLAT calculées par FlightAware dans le hub MLAT de l’Ultrafeeder, de sorte qu’elles apparaissent aussi sur ta carte locale.

Reprendre les clés ou en générer de nouvelles

Voici le principal piège lors du changement : qui alimente déjà reprend ses clés actuelles. Sinon, le service crée une nouvelle station, et les statistiques ainsi que les contreparties de feeder restent attachées à l’ancienne. Les guides donnent les commandes pour les installations existantes :

• FlightAware : piaware-config -show feeder-id sur l’ancien système. Les nouveaux feeders peuvent être enregistrés une seule fois via un conteneur temporaire puis associés à un compte sur flightaware.com. Veille à ce que la position et l’altitude chez FlightAware correspondent à ton .env, sinon le MLAT ne fonctionne pas. Plus d’informations sur FlightAware lui-même figurent dans Installer et configurer PiAware.
• Flightradar24 : la Sharing Key se trouve dans l’ancien /etc/fr24feed.ini. Les nouveaux feeders exécutent le dialogue d’inscription dans un conteneur temporaire. Des informations de fond sont données par Configurer fr24feed.
• AirNav Radar : rbfeeder --showkey --no-start ou un coup d’œil dans /etc/rbfeeder.ini montre l’ancienne clé. Sans clé, le conteneur en génère une nouvelle au premier démarrage et l’affiche dans le journal. Plus d’informations sur le service lui-même figurent dans Utiliser AirNav RadarBox.
• Plane Finder : le Share Code se trouve dans le compte sur planefinder.net, sous tes récepteurs. Un aperçu du service est donné par Plane Finder en un coup d’œil.

Les anciens feeders sur le système hôte, tu les arrêtes avant que les conteneurs prennent le relais – sinon deux programmes s’annoncent avec la même clé. Quels abonnements et avantages les services t’accordent pour l’alimentation, Ce que les feeders obtiennent en échange le compare.

Le MLAT avec plusieurs réseaux

Chaque ligne mlat dans ULTRAFEEDER_CONFIG lance son propre mlat-client. Ta station participe ainsi à la multilatération de chaque réseau enregistré – et chaque réseau calcule avec les stations qui y participent. Plus tu alimentes de réseaux, plus la chance est grande que, dans l’un d’eux, assez de voisines se trouvent à portée. Justement, les appareils militaires sans compte rendu de position propre n’apparaissent qu’alors ; comment le procédé fonctionne, c’est dans MLAT/multilatération.

Les conditions sont les mêmes que pour toute autre installation : coordonnées exactes, hauteur d’antenne correcte et réception stable. L’avantage de Docker : ces valeurs ne figurent qu’une fois dans le .env et valent automatiquement pour tous les réseaux. Les fautes de frappe dans des fichiers de configuration individuels, qui paralysent le MLAT chez un réseau mais pas chez un autre, n’existent plus ainsi.

Exploitation : journaux, mises à jour, santé

Au quotidien, tu t’en sors avec peu de commandes, que tu exécutes dans le dossier /opt/adsb :

Tâche	Commande
Suivre tous les journaux en direct	docker compose logs -f
Journal d’un conteneur	docker logs -f ultrafeeder
État et santé	docker ps
Prendre en compte les modifications de .env ou de Compose	docker compose up -d
Mettre à jour toutes les images	docker compose pull, puis docker compose up -d

Les conteneurs de sdr-enthusiasts embarquent des contrôles d’état. Dans la colonne STATUS de docker ps, on lit alors healthy, unhealthy ou health: starting. Si un conteneur affiche durablement unhealthy, son journal donne le plus souvent la raison – souvent une mauvaise clé d’accès, une clé SDR introuvable ou une faute de frappe dans ULTRAFEEDER_CONFIG.

Symptôme	Cause probable	Solution
Carte vide, le journal signale aucun appareil	Mauvais numéro de série ou clé occupée par un autre programme	Vérifier le numéro de série, arrêter l’ancien décodeur sur l’hôte
Un réseau ne reçoit pas de données	Faute de frappe ou point-virgule manquant dans ULTRAFEEDER_CONFIG	Comparer l’entrée avec la liste du projet, docker compose up -d
Conteneur FlightAware unhealthy	Identifiant de feeder manquant ou emplacement différent chez FlightAware	Vérifier l’ID dans .env, aligner la position dans le compte
Station en double chez un service	Nouvelle clé utilisée à la place de l’ancienne	Saisir l’ancienne clé dans .env, recréer le conteneur

Pour les utilisateurs avancés, le guide décrit en outre les mises à jour automatiques, le redémarrage automatique des conteneurs défaillants et des analyses avec Grafana. Pour débuter, tu n’en as pas besoin.

Pour qui le changement vaut la peine

Pour la pratique du spotteur, un récepteur bien alimenté apporte un avantage très concret : ta région est couverte plus densément sur plusieurs cartes, souvent exactement là où tu fais toi-même du spotting – par exemple à la butte d’observation de l’aéroport de Munich avec vue sur l’aéroport de Munich ou au Spotterhügel de Teveren, où est stationnée la flotte AWACS de l’OTAN. S’y ajoutent des outils pour retracer plus tard ce qui est vraiment passé ; comment faire, Recouper ses observations avec des journaux ADS-B le montre. Si la réception et la transmission des données sont autorisées dans ton pays, Recevoir des données ADS-B : le cadre légal le clarifie.

Conclusion

Avec l’Ultrafeeder de sdr-enthusiasts, un bric-à-brac de feeders accumulés devient un système rangé : un conteneur pour le décodeur, la carte, les statistiques et tous les réseaux communautaires, plus un conteneur léger par service commercial. Le plus de soin est dû, comme toujours, aux données de base – coordonnées, altitude, clés et UUID distinctes. Une fois le .env en place, chaque réseau supplémentaire est une affaire de deux lignes et d’un docker compose up -d.