mardi 20 octobre 2009

Projet ADS-B: le prochain firmware

Ce projet semble intéresser un grand nombre de personnes au regard de la quantité de mails que j'ai déjà reçus. Le prochain firmware (V1.5) est en cours de test depuis maintenant deux jours. J'ai quelques doutes sur le décodage d'une trame spécifique bien que la simulation du code en environnement Windows ne m'ait pas permis de mettre en évidence le problème constaté. Il ne me reste donc plus qu'à laisser tourner l'ensemble avec un code instrumenté plusieurs jours d'affilé jusqu'à ce que le problème réapparaisse, ou pas.
A suivre.

Cette version intègre le décodage des informations de vélocité, ainsi que celui de la position en surface, un cas de figure qui sera probablement rarement rencontré à être situé en bordure d'un aéroport.

dimanche 18 octobre 2009

Projet ADS-B: Premier interfaçage avec PlanePlotter

Les premiers tests de l'interface intégrée dans une nouvelle version préliminaire de PlanePlotter sont très encourageants. Ci-dessous, une vue du trafic au alentour d'ORLY à une heure 'creuse'.



La visibilité est ici assez faible car le récepteur est raccordé sans aucun préamplificateur sur une antenne discone. La sensibilité d'entrée du tuner étant de 200µV, seuls les avions proches seront décodés. Le trafic est suffisamment important aux environs des aéroports de la région parisienne pour déjà bien charger le µprocesseur.

samedi 17 octobre 2009

Projet ADS-B: In the box

Avec la version 1.4 du firmware, mon projet a atteint les objectifs que je m'étais fixé avec un bon compromis entre performance, stabilité et fiabilité. Le format de sortie est désormais bien défini, et ne devrait plus évoluer que pour intégrer les informations de déplacement, vitesse, et direction. Celles-ci ne sont toutefois pas indispensables pour obtenir une cartographie du trafic aérien suffisante pour un amateur.

Les données fournies par ce récepteur peuvent être visualisées à l'aide de deux programmes:

- Mon programme de visualisation WinADSB permettant l'affichage tabulaire des données dans sa version actuelle,


- L'application PlanePlotter qui, dans une très prochaine version, devrait autoriser le traitement direct des données transmises sur le port série par mon récepteur. Merci, Bev d'avoir travaillé d'arrache-pied pour intégrer cette interface.

Avant de mettre en coffret le système, j'ai effectué quelques modifications sur le câblage pour préparer l'intégration du processeur PIB18F26K20, compatible broche à broche mais requérant une tension d'alimentation de 3.6V, et un firmware modifié. Avec 16MIPS au lieu des 12 du 18F2550, ce dernier permettra de gagner un peu en performance (25%), et de traiter plus de trames, ou pour être plus proche de la vérité, d'en perdre un peu moins !

L'adaptation de niveau est à faire sur l'alimentation même du µprocesseur mais aussi sur le signal d'entrée et sur le gestionnaire RS232. Ce dernier peut être remplacé par un modèle travaillant en 3.3V mais il s'avère que le modèle 5V que j'utilise - LT1081 - fonctionne encore très correctement lorsqu'il est alimenté en 3.6V. Les tensions générées par les pompes de charge sont plus faibles mais sont encore suffisantes sur une faible distance de liaison.

Un problème résolu qui me permet d'envisager une modification réversible ne nécessitant pas de changement de composant. J'ai opté pour une solution certes non industrielle mais diablement simple pour adapter l'alimentation du µprocesseur: deux diodes en série sur la ligne d'alimentation qui assurent une chute de tension de l'ordre de 1,34V mesurée. La tension d'alimentation est ainsi ramenée à 3.62V pour 3.6V max selon les spécifications de Microchip. La même astuce est employée sur le signal d'entrée, une résistance entre la sortie du signal ainsi adapté et la masse étant cependant ici nécessaire en l'absence de consommation sur cette ligne. La désactivation de cette adaptation est simple: deux cavaliers permettent de court-circuiter ces diodes.

J'ai ainsi pu tester le fonctionnement du 18F2550 avec les deux tensions d'alimentation sans détecter aucun problème de décodage, une perception qui reste cependant subjective en l'absence de générateur de test permettant de comparer fiablement les deux options.

J'attends maintenant de recevoir un 18F26K20 pour modifier les séquences d'initialisation et tester son fonctionnement. En attendant, le récepteur a été mis en boîte dans un boîtier de récupération qui était hélas vide (pour ceux qui reconnaîtrait celui-ci).



lundi 12 octobre 2009

Projet ADS-B: Décodage de la position

Après avoir étudié plus en détail le mécanisme d'encodage de la position, et apprécié l'impact réel des calculs sur l'acquisition, j'ai décidé d'intégrer ce calcul dans le µcontroleur mais de le rendre désactivable (Firmware V1.2).

La fiabilité des calculs a été vérifiée à partir de deux autres implémentations, l'une que j'ai faite sous Excel, et l'autre que j'ai embarqué dans le programme de contrôle qui tourne sous Windows. Il est cependant nécessaire d'utiliser une librairie de calcul en flottant sur 32 bits, l'utilisation d'une librairie en précision réduite 16 ou 24 bits ne permettant pas d'obtenir la fiabilité ici requise.
Le programme de contrôle génère actuellement un fichier de journalisation compatible avec celui du système AirNav, permettant d'injecter les données dans l'application Plane Plotter.



Le prochain Firmware intégrera le décodage du message 19 de la trame DF17, et des messages 1 et 2 de la trame DF18 permettant ainsi d'obtenir les informations sur le déplacement.

mardi 6 octobre 2009

Projet ADS-B: Encodage de l'altitude et de la position

L'altitude et la position sont encodées dans trois champs de 12, 17 et 17 bits respectivement.
Les coordonnées de position sont encodées par un procédé astucieux (Compressed Position Reporting ou CPR) mais imposant l'utilisation de fonctions mathématiques, la mémorisation des données précédentes et la connaissance de la position locale du récepteur.  La transformation de ces informations en coordonnées directement exploitables par une application externe mobilise trop de ressources pour être embarquée dans le µControlleur. Ces coordonnées sont en conséquence transmises telles quelles.
L'encodage de l'altitude fait appel à deux procédés selon la précision de l'information (pas de 25 ou de 100 pieds). Le premier procédé est aisément implémenté en calcul pur. Il n'en va hélas pas de même avec le second qui fait appel à un codage binaire que je n'ai pas réussi à traduire (Cf Note 1) sous la forme d'une fonction mathématique simple, un changement de base par exemple.


L'utilisation d'une table de lookup est alors requise. Celle-ci contiendra les 1280 codes possibles, l'index de la position du code recherché donnant l'altitude (moyennant une soustraction si l'on souhaite gérer les altitudes négatives). Une solution peu performante, en O(N), mais qui a le mérite de pouvoir être très facilement être mise en oeuvre sur un PIC, les données constantes étant stockées dans la mémoire programme sur des mots de 16 bits. Le PIC18F2550 contient suffisamment de mémoire programme pour embarquer cette table.

Cette solution a l'inconvénient de réduire le cycle d'acquisition des trames, et donc d'en perdre un grand nombre. Fort heureusement, le principe même du système ADS-B/Mode-S conduit à transmettre de nombreuses trames redondantes. En conséquence, on constatera tout au plus un léger délai dans l'acquisition de toutes les informations requises pour déterminer la position d'un aéronef.

Dans l'hypothèse où cette perte de trame serait inacceptable, le travail de contrôle d'intégrité et décodage peut parfaitement être intégralement reporté sur l'applicatif externe en désactivant les options de vérification de l'intégrité (switch 'CRC') et de transmission des données étendues (option 'XTD'). Les traitements annexes sont désactivé, et la boucle d'acquisition et de retransmission tourne à sa vitesse maximale, une centaine de cycles étant tout au plus consommé hors de la boucle d'acquisition.

La prochaine version du firmware, version 1.0, intégrera le décodage de l'altitude et sa transmission en données directement interprétables, en 'feet'. La version suivante offrira probablement la transmission des informations de navigation présentes dans la trame DF17 Type 19 dont la vélocité et le cap.

Note 1: En fait, l'encodage par pas de 500 pieds (positions A, B et D) utilise un code de Gray. L'encodage des pas de 25 pieds (position C) utilise un code cyclique spécifique. Il existe donc bien une procédure algorithmique simple pour passer d'un code de Gray à un code binaire qui permettrait de réduire la table de lookup au seul décodage des pas de 25 pieds. J'implémenterai donc cette approche pour test quand mon projet sera finalisé.

samedi 3 octobre 2009

Projet ADS-B: Firmware V0.8

Dans cette version les commandes reçues sur la liaison série sont gérées sous interruption. Le routage du signal d'entrée a été modifié sur RC0 pour libérer les ports I2C en vue d'une extension future permettant de piloter un tuner I2C. Une impulsion est par ailleurs délivrée sur RA4 lors de la réception d'un code ICAO correspondant à celui ayant été mémorisé.



Il me reste encore à faire une dernière modification avant de basculer l'ensemble dans une première version de production: l'extraction en mode étendu, des champs altitude, vitesse et vitesse verticale. Ce sera chose faite d'ici le prochain week-end.

Le code binaire de la version 0.8 est disponible ici.

jeudi 1 octobre 2009

Projet ADS-B: Firmware V0.7

Le mécanisme de vérification de l'intégrité des trames - option CRC activée - est désormais totalement fonctionnel.


Quelques minutes de trafic suffisent pour renseigner la table avec les codes ICAO extraits des trames DF17 (code certain) et DF11 (code probablement bon), et ainsi vérifier l'extraction du code du champ AP des autres trames.



Cette table contient 50 entrées, chaque entrée étant purgée après 5mn d'inactivité constatée sur le code ICAO associé.



Une nouvelle option permet de surveiller l'apparition d'un code ICAO préalablement enregistré en mémoire. Un message spécifique est émis lors de l'apparition de ce code sous réserve que l'option ait été activée.

Les commandes gérées par cette version sont les suivantes:
- 'CTRL-Q': XON
- 'CTRL-S': XOFF
- '?': Identification de la version
- 'o': Etat des options
- 'R': Reset à chaud
- 'S': Remise à 0 des compteurs
- 's': Envoi des compteurs
- 'C': Effacement de la table des codes ICAO
- 'c': Envoi du contenu de la table
- 'E': Effacement du code ICAO à surveiller
- 'e': Entrée du code ICAO à surveiller
- 'i': Envoi du code ICAO surveillé
- 'A': Activation de l'option surveillance
- 'a': Désactivation de l'option surveillance
- 'F': Activation de l'option surveillance
- 'f': Désactivation de l'option surveillance
- 'X': Activation de l'option 'Données étendues'
- 'x': Désactivation de l'option 'Données étendues'

Il me reste un problème à résoudre, la gestion des commandes est réalisée dans la même boucle que la boucle d'acquisition des trames. Cette boucle étant actuellement bloquante en l'absence de trames, aucune commande ne peut être transmise. Je vais donc devoir passer la gestion des commandes sous interruption en priorité basse, la priorité haute étant réservée à la gestion du cycle de vie de la table de codes, ceci uniquement lorsque l'option de contrôle des CRC est activée.

Les meilleures performances seront obtenues en désactivant les modes 'CRC' et 'Données étendues', le microcontrôleur n'ayant aucun autre traitement à effectuer que d'attendre une trame et de la retransmettre codée sus la forme d'un chaîne hexadécimale sur la liaison série à 115200 Bauds.