L’Automatic dependent surveillance-broadcast (ADS-B) est un système de surveillance coopératif pour le contrôle du trafic aérien.
Un avion équipé de l’ADS-B détermine sa position par un système de positionnement par satellites (GNSS) et envoie périodiquement cette position et d’autres informations aux stations au sol et aux autres appareils équipés de l’ADS-B évoluant dans la zone.
Vous pourrez trouver des informations plus détaillées sur la page Wikipédia dédiée à ce protocole qui est accessible ici : fr.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast
Les données sont transmises sur la fréquence 1.090 GHz et une carte SDRPlay RSP1-A qui monte jusqu’à 2GHz peux donc les capter.
J’avais installé sur un Raspberry Pi4 le logiciel de WebSDR « OpenWebRX+ » téléchargeable ici : luarvique.github.io/ppa/ et qui permet de décoder ce protocole ADS-B. 
Et voici la carte que l’on obtient : Un mini FlightRadar24 personnel. 
Le problème avec cette configuration est que le CPU du Raspberry se retrouve avec une charge de plus de 80%, et une température dépassant les 65°, ce qui a terme, pourrait l’endommager.
J’ai donc décidé d’opter pour un autre logiciel, PiAware (fr.flightaware.com/adsb/piaware), proposé par le site FlightAware, concurent de FlightRadar24.
Ce logiciel utilise le programme dump1090 pour faire l’acquisition et le décodage des données en provenance de la carte SDR, et la société SDRPlay a eu la bonne idée de faire une version de ce programme adaptée pour ses cartes RSP1-A et autres.
J’ai donc pu télécharger les sources de ce programme dump1090 depuis ce Github : github.com/SDRplay/dump1090
et après quelques efforts, j’ai réussi a compiler ce programme sur mon Raspberry Pi4.
Du coup, le logiciel PiAware s’est retrouvé alimenté pas les données captées par ma carte SDR.
Voici la page présenté par le Raspberry une fois que PiAware est installé :
On constate que effectivement, la charge CPU a nettement diminué (21%) et la température aussi (52°).
J’ai rencontré un problème avec le protocole MLAT dont l’indication de bon fonctionnement passait de Vert à Orange en indiquant le message « Local clock is unstable« .
J’ai ajouté au Raspberry le protocole NTP permettant de mettre à jour son heure régulièrement, ce qui n’a pas permis de régler le problème.
J’ai finalement compris que j’avais indiqué une position GPS trop approximative pour ma station.
Je suis donc allé sur la page de paramétrage de cette position GPS dans l’interface d’administration proposée par FlightAware, j’ai corrigé ma position, et ce problème de désynchronisation de l’horloge locale a été solutionné.
Les données ainsi remontées à FlightAware me permettent d’accéder à toute une série de Statistiques concernant les données que je leur remonte.
On a également accès à la carte des avions que l’on a capté : 
J’ai ensuite décidé de remonter ces informations en direction de FlightRadar24 qui offre à tous les fournisseurs de données ADS-B un abonnement « Business » d’une valeur de 400€ / an.
Pour cela j’ai installé sur le Raspberry le logiciel fr24 téléchargeable ici:
www.flightradar24.com/share-your-data
et je dispose maintenant des statistiques de FlightRadar : 
Et également de la carte des avions que j’ai capté :
Pour ceux qui voudraient faire de la réception ADS-B avec une carte SDRPlay RSP1-A, je viens de publier sur mon Github le projet RSP1Adump1090 qui contient les sources du programme dump1090 que j’ai dû modifier pour pouvoir les compiler sur mon Raspberry Pi4 booté avec l’image PiAware. Il est disponible ici :
Bonne réception ADS-B 😊