Projet ADS-B: Amélioration du firmware

Le fonctionnement de la chaîne étant validé, je peux désormais me consacrer à améliorer le logiciel embarqué dans le PIC18F2550. Après réflexion, j'ai décidé d'intégrer, outre la fonction de décodage, quelques fonctions de traitement qui permettront de décharger l'application externe.

La version 0.6 offre ainsi deux modes de fonctionnement activables par une simple commande sur la liaison série:
- Un mode normal (commande 'n') qui transmet les données reçues selon un formatage simple, charge à l'application de tout décoder.
- Un mode étendu (commande 'x') qui transmet en plus les informations suivantes: niveau de réception du signal, type de la trame, identifiant ICAO, et si disponibles: call-sign, CPR, latitude et longitude.

La command 'o' permet d'obtenir l'état courant des options.

La prochaine version intègrera une fonctionnalité permettant de valider la bonne réception des trames autres que les trames DF11 et DF17 quand l'otion de vérification des CRC est activée. Les identifiants calculés à partir du champ PA des autres trames sont corrélés aux identifiants acquis dans les trames DF11 et DF17 considérées comme intègres à la suite de la vérification du champ PI. Si l'identifiant est dans la table, la trame est marquée valide (préfixe '+' dans le format de sortie).
L'exemple de capture précédent permet d'illustrer ce mode de fonctionnement: le code ICAO 391EOF est transmis via le champ PA par deux trames DF00 mais est aussi présent dans une trame DF17 dont l'intégrité a été vérifiée. Toutes les autres trames annoncant ce code dans le champ PA seront considérées intègres.
La commande 'c' permettra d'obtenir le contenu de la table des codes acquis.

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.

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 Errors	Received	CRC KO	DF17
17728	8811	0	1023
33846	17575	1	2150
40735	21447	2	2666
50335	27969	3	3394
51599	29069	3	3524

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

Indicateur	Message	Terminateur	Commentaires
=	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.