vendredi 25 septembre 2009

Projet ADS-B: Premiers décodages

L'objectif que je m'étais fixé est atteint: décoder les trames ADS-B avec un minimum de matériel, et au plus faible coût. La chaîne de réception et de transcodage fonctionne mieux que je ne l'aurais pensé, d'autant que le composant Analog Device utilisé n'est pas optimum. J'attends avec impatience de recevoir les échantillon de l'autre modèle.



Mon programme de test me permettant de visualiser l'essentiel des informations prend forme, et arrive à suivre la cadence sans trop souvent activer le contrôle de flux.


Une video du programme en action

Il me reste à valider le bon de fonctionnement de l'acquisition du niveau d'entrée du tuner, à activer le chien de garde, à ajouter une signalisation lumineuse de l'activité reçu, et à réaliser la liaison USB. J'envisage aussi d'ajouter un afficheur LCD pour visualiser les principaux paramètres, et quelques informations extraites des trames. Pour éviter de surcharger le microprocesseur, je pense faire gérer cet affichage par un second PIC, un 16F628A probablement connecté sur la liaison série.

Le code binaire du programme du PIC18F2550 sera disponible sur mon d'ici une quinzaine de jours, ce programme pouvant être utilisé avec n'importe quelle tête de réception.

jeudi 24 septembre 2009

Projet ADS-B: Vérification des CRC - 2

Le taux d'erreur constaté lors de mes essais d'hier avait pour origine une erreur dans le calcul, lequel ne tenait pas compte de la possibilité que les champs CL et IC puissent ne pas être nuls. Ajoutons à cela une erreur dans le calcul du contrôle d'une trame DF17. Après correction le taux d'erreur tombe presque à zéro !

Framing ErrorsReceivedCRC KODF17
17728881101023
338461757512150
407352144722666
503352796933394
515992906933524

Le compteur 'CRC OK' a été modifié pour désormais compter les valeurs de contrôle probablement erronées, c'est-à-dire, celles ne passant pas le crible d'une distance inférieure à 128. Les trames ne comportant pas de champ de contrôle sont considérées toujours bonnes.

Je n'ai toujours pas finalisé le format de sortie. Pour l'instant, les trames sont transmises comme suit:

 [Indicateur][Message][Terminateur]CRLF

    avec

IndicateurMessageTerminateurCommentaires
=Version du logiciel;Transmis en réponse à la commande?CRLF
#Compteurs internes;Transmis en réponse à la commande sCRLF
+Trame CRC valide;Transmis en hexadécimal. La somme de contrôle est a priori valide.
-Trame CRC invalide;Transmis en hexadécimal. La somme de contrôle est a priori invalide.
*CRC non calculé(able);Transmis en hexadécimal. La somme de contrôle n'est pas calculée(able)

Les compteurs sont transmis séparés par une virgule, avec dans l'ordre:
1- le nombre de trames erronées,
2- le nombre de trames reçus en entier,
3- le nombre d'erreurs de CRC,
4- le nombre de trames de 112µs
5- le nombre de trames non transmises durant les pauses de transmission dues au contrôle de flux.
Ces compteurs (32bits) sont  remis à zéro lorsque le nombre de trames erronées repasse à 0. Le contrôle de flux n'influence pas les réponses aux commandes.

Projet ADS-B: Vérification des CRC

J'ai implémenté le calcul des codes de contrôle transmis dans les champs AP ou PI des trames DF11 et DF17 pour lesquelles les polynômes générateurs sont disponibles dans la littérature, en particulier dans les documents publiés par Eurocontrol.

Après quelques minutes d'acquisition, les compteurs embarqués dans le code permettent d'avoir une bonne idée de la qualité de la réception:
HeureFraming errorReceivedCRC OKDF17
19:06TU890983328124
19:10TU366438021371515
19:12TU599461322318823
19:14TU9219956336551286
19:20TU163501747467792428
On en retiendra que:
- 50% des trames ne passent pas le test du décodage Manchester,
- 66% des trames ont un code contrôle erroné (Cf  Note de fin de page).

Et ceci de manière assez constante, le réglage du seuil de détection ne semblant pas influencer outre-mesure le taux d'erreur sur les CRC. Sur les trames courtes, l'erreur apparaît être dans les derniers bits du champ du contrôle comme on peut le voir ci-dessous sur la copie d'écran de mon application de validation:


Il s'agit probablement d'un nouveau problème d'échantillonnage - le code a été modifié depuis la première optimisation - problème qu'il va falloir confirmer en déclenchant au bon moment l'analyseur logique. Cela demande du temps et l'instrumentation du code. J'attaquerai donc cette validation après finalisé les développements.
La version 0.3 du code assure:
- l'acquisition de toutes les trames ADS-B
- la vérification des CRC des trames DF11 et DF17
- la retransmission sur une liaison série à 115200bds
   - de toutes les trames, ou uniquement des trames DF17
   - de toutes les trames, ou uniquement de celles ayant un CRC correct
- la gestion du contrôle de flux de la liaison série en XON/XOFF
- le maintien de 5 compteurs d'état:
   - Nombre d'erreurs de framing
   - Nombre de trames reçues
   - Nombre de trames CRC OK
   - Nombre de trames DF17
   - Nombre de trames perdues durant un XOFF
- la retransmission sur demande de ces compteurs.

Nota: La relecture d'une spécification de l'ICAO me laisse à penser que j'ai mal interprété le paragraphe consacré à la génération des champs AP ou PI. J'ai ainsi considéré à tort que les informations CL et IC étaient systématiquement positionnées à 0 dans toutes les réponses. Il apparait que cela n'est vrai que dans le cas d'une réponse à certaines requêtes spécifiques. Dans tous les autres cas, les informations CL et IC sont acquises dans la requête et réintégrées dans le calcul de la valeur de contrôle.
N'ayant pas la connaissance de ces valeurs, il apparaît impossible de vérifier l'intégrité des trames reçues. Cependant, la faible taille de ces deux champs (3bits et 4bits) au regard de celle de la somme de contrôle (24bits) doit permettre d'effectuer malgré un filtrage intéressant en rejetant des trames à coup sûr erronées. Il suffit pour cela de calculer la somme exclusive de la valeur reçue avec celle calculée, et de rejeter toutes les trames pour lesquelles le résultat sera supérieur à la valeur maximale pouvant être encodée par ces deux champs, soit 7F (ou 127 en décimal) et non pas simplement égal à 0 comme je l'ai implémenté. Cette erreur explique le constat précédent portant sur le fait que les bits erronés se situent en fin du champs de contrôle le reste de la trame étant cohérent.

mardi 22 septembre 2009

Projet ADS-B: Quelques statistiques

J'ai fini de modifier le code du PIC18F2550 pour intégrer une gestion de flux de type XON/XOFF et trois compteurs: le nombre de trames reçues complètes, le nombre de trames dont le codage manchester est invalide mais avec un préambule correct et le nombre de trame perdues durant un XOFF.

Après quelques dizaines de minutes de réception en soirée (20H30GMT), les deux premiers compteurs s'établissent comme suit: 6238/20483 (trames reçues/trames erronées). Quelques 5 minutes plus tard, le ratio n'a pas énormement changé: 8157/27399 puis 8669/29185. A confirmer sur des plages horaires plus chargées en trafic.

La prochaine étape va être de lire attentivement les spécifications pour déterminer si le code correcteur d'erreur peut être vérifié ou non, les avis dans certains groupes de discussion semblant diverger sur ce point. Si tel est le cas, j'embarquerai probablement la routine de contrôle dans le PIC, la perte de quelques trames durant le temps de calcul ne devant pas impacter le fonctionnement au regard des statistiques déjà collectées.

lundi 21 septembre 2009

Projet ADS-B: Premiers messages

J'ai enfin confirmation de la viabilité du projet avec la réception des premiers messages démodulés et transmis à 115200 Bauds sur la liaison série du PIC18.



La quantité de messages reçus est d'autant plus impressionnante que j'utilise une antenne discone sans aucun préamplificateur, et que ni le réglage du tuner, ni celui du comparateur, n'a réellement été affiné. La proximité d'un grand aéroport doit cependant bien aider.



Le travail ne fait cependant que commencer car le décodage des messages n'est pas encore programmé, et bien des options doivent être étudiées: utilisation du bus USB en lieu et place de la liaison série, acquisition en temps réel du niveau de réception des trames et pilotage d'un indicateur de niveau, un afficheur LCD pourquoi pas...

Ma priorité va aller à l'écriture d'un programme Windows simple décodant textuellement les trames, et vérifiant leur intégrité. Je suis curieux de connaitre le taux d'erreur au niveau de la réception (trames incomplètes) et du décodage (trames erronées). Il va donc me falloir encore ajouter quelques compteurs dans le code du PIC.

dimanche 20 septembre 2009

Projet ADS-B: Acquisition fonctionnelle

N'ayant pas (encore) réussi à approvisionner un PIC18F13K22, j'ai continué à chercher à optimiser le code du PIC18F2550 pour finir par retenir l'option d'un code linéaire dans lequel les séquences de décodage élémentaires sont mises bout à bout quand bien même celles-ci sont presque toutes identiques. Ce n'est pas élégant mais je n'ai vraiment pas trouvé d'optimisation me permettant d'éviter cela.



La bonne configuration du PIC, et les timings des séquences, ont été vérifiés à l'aide de l'analyseur logique - échantillonnage à 20ns - et de l'insertion dans le code d'une instruction inversant l'état d'une sortie. Première erreur: j'ai oublié que le codage de l'activation du diviseur d'horloge de la CPU différait selon que l'on est en mode HS (High Speed) ou HSPLL (HighSpeed avec horloge dérivée du PLL intégré). Ce problème corrigé, il m'a fallu partir à la chasse à une erreur d'un cycle dans l'échantillonnage. La lecture du listing résultant de l'assemblage m'a permis de découvrir l'origine du problème. La taille du code non structuré conduit à encoder la plupart des branchements sur deux mots, consommant alors 2 cycles, et non un seul. Une fois le code revu, les premières trames reçues et décodées sans aucune erreur - 56µs et 112µs - s'affichent sur l'écran de l'analyseur logique.



Mon code gère deux signaux d'information que j'utilise pour déclencher l'analyseur: un signal devenant vrai lorsqu'un préambule complet est reçu et un signal devenant vrai quand une trame complète a été reçue, sans erreur. Cette approche s'avère être indispensable pour mettre rapidement au point un programme aussi pointu en terme de précision dans l'échantillonnage.

La suite: transmettre les trames - 7 ou 14 octets - sur la liaison série de test avant de s'attaquer à configurer et utiliser la sortie USB.