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é.
Aucun commentaire:
Enregistrer un commentaire