mardi 29 septembre 2009

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.

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.

jeudi 17 septembre 2009

Projet ADS-B: Problème de performance sur PIC18

Cela fait maintenant plusieurs soirées que je me bats pour tenter de faire tenir le code d'acquisition des trames dans un microcontrôleur.

Le problème est simple:
- L'acquisition du préambule nécessite d'échantillonner le signal au moins toutes les 500ns et ceci sur une durée de 8µs. La 'signature' de l'entête en hexadécimal est alors C100.
- L'acquisition du reste de la trame impose aussi d'échantillonner le signal à la même cadence bien que la durée d'un état soit de 1µs. Le codage utilisé impose en effet, si l'on veut travailler proprement, d'échantillonner une première fois puis de contrôler que l'état du signal a bien changé 500ns après. Et c'est ici que le bât blesse, du moins si l'on veut obtenir un code proprement structuré.

La lecture des données, hors le préambule , peut se faire par bloc de 8 bits, 7 dans le cas d'une trame courte, et 14 dans le cas d'une trame longue. Le tout premier bit de la trame indiquera si l'on est en présence d'une trame longue (112µs) ou courte (56µs). De ce bit dépendra donc le nombre d'itérations de la boucle d'acquisition.
Qui dit boucle, dit instructions de contrôle et instructions de stockage dans un tampon, et donc perte de quelques précieux cycles.

Avec un cycle d'échantillonnage à 500ns, il est hors de question de travailler sous interruption même avec les dernières générations de microprocesseurs. Si l'on prend un PIC18 cadencé à 48MHz facile à approvisionner, le cycle d'une instruction est de 83.33ns autorisant au plus 6 instructions pour acquérir et traiter un échantillon. Il me faut donc trouver une optimisation du code permettant:
- à t+000: d'acquérir le signal et de stocker son état dans un registre indexé ceci en tout au plus 6 cycles.
- à t+500: d'acquérir de nouveau de le signal, de vérifier qu'il s'est inversé, si ce n'est pas le cas, de repartir au debut du code, et si l'on est en fin de boucle, d'incrémenter l'index du registre de stockage, de tester le compteur et de repartir en début de boucle, ici encore en moins de 6 cycles.

Avec les instructions du PIC, cela 'passe' dans le cas du préambule mais pas pour le reste de la trame, les instructions de contrôle et de gestion du stockage venant tout perturber.

Sauf à considérer que je n'ai pas encore vu l'assemblage d'instructions qui me fera gagner les 3 cycles manquants sur les 2*6 cycles (acquisition et vérification), je n'ai plus guère d'options:
1- je fais sauter le contrôle de la transition d'état, ou je le reporte en fin de réception d'une trame complête,
2- je travaille de manière linéaire, sans boucle, mettant bout à bout 14 fois 8 blocs élémentaires de code, chaque bloc utilisant 12 instructions (1µs). Soit 1344 instructions, 14 fois plus qu'une programmation structurée,
3- je passe à la vitesse supérieure avec les dernières générations PIC18 à 16MIPS, soit un temps de 50ns par instruction au lieu des 83.33ns, m'offrant ainsi les 3 instructions manquantes,
4- je passe à l'ennemi en utilisant un micro-controlleur ATMEL autorisant un temps de cycle de 50ns et bien plus facile à approvisionner que les PIC18F1xK22,
5- Je passe encore à vitesse supérieure avec un FPGA, mais là il me faut tout apprendre ou presque, étant resté au PAL22V10...

L'option 3 me satisferait pleinement si MicroChip n'avait complexifié à l'extrême la procédure de commande d'échantillons, et même d'achat en direct, les références qui m'intéressent (PIC18F13K22 et PIC18F14K22 en PDIP), pourtant annoncées disponibles sur le site principal, n'étant pas livrables sur commande avant décembre.

Une bonne nouvelle toutefois, les AD8310 commandés chez Analog Devices sont arrivés. Le temps de faire un adaptateur SOIC vers DIP8, et je pourrais vérifier ce week end que ce modèle me permet d'obtenir de bien meilleurs fronts sur le signal.

samedi 12 septembre 2009

Projet ADS-B: Incompatibilité de l'AD8307 - Révision

En attendant de recevoir un AD8310, je me suis de nouveau penché sur la maquette utilisant l'AD8307 pour découvrir que j'ai commis une erreur dans ma conception. La tête ailleurs, j'ai câblé un condensateur de 1.5nF sur la sortie du détecteur, lequel participait à l'intégration du signal. Celui-ci enlevé, l'AD8307 se comporte comme je le pensais à la lecture des courbes de réponse en fournissant un signal démodulé 'potable'. L'utilisation d'un AD8310 devrait cependant me permettre d'obtenir des signaux plus abrupts.


Signal en sortie du comparateur LM311

Je dois ici avouer qu'un oscilloscope digital me serait ici probablement d'une trés grande utilité au regard du nombre de trames détectées en réglant le seuil du comparateur assez bas. Je dispose fort heureusement d'un analyseur logique qui m'a permis de vérifier que le signal démodulé est exploitable.



Celà est le cas.



Il va donc falloir maintenant engager la seconde partie du projet, la programmation du code de décodage sur microprocesseur PIC, modèle non encore sélectionné mais très certainement un PIC-18.

jeudi 10 septembre 2009

Projet ADS-B: Incompatibilité de l'AD8307

Celà se confirme, les temps de réponse de l'AD8307 sont incompatibles avec la détection des pulses comme je le craignais. Celles-ci sont pourtant parfaites en sortie de l'amplificateur NE592, le tuner étant simplement raccordé sur une antenne discone sans aucune préamplification.

La vitesse fixe de rotation du radar permet de recevoir à période fixe les trames d'un même avion qui s'est relativement peu déplacé et donc de synchroniser assez correctement l'oscilloscope. En pratique, les pulses de plusieurs trames différentes peuvent se recouvrir, en particulier le soir quand le trafic est important.




Ces pulses sont hélas intégrées par l'AD8307:



Il me reste donc à passer au plan B, utiliser un AD8310. Quand à l'AD8307 que j'hésite à décâbler au risque de le détruire, l'intégration qu'il effectue sera peut être exploitable à d'autres fins, asservissement du comparateur de tension en sortie de l'AD8310 ou encore mesure directe du niveau reçu par l'un des convertisseur analogique d'un microcontroleur par exemple. Un PIC16F676 peut effectuer une conversion en 18µs, ce qui permet effectivement d'acquérir le niveau avec un déclenchement à la fin de la réception du préambule. Une idée à creuser.

mercredi 9 septembre 2009

Projet ADS-B: Réalisation d'un chopper

Avant d'aller plus en avant dans le projet, j'aurais souhaité pouvoir disposer d'une source me permettant de simuler une trame ADS-B, ou a minima, de générer une modulation d'impulsion. Une solution possible serait de réaliser un chopper à 500Khz assurant la découpe du signal à 990Mhz produit par le générateur.

Ayant sous la main une diode PIN Hyper (MA4P326) mais sans les spécifications techniques pour déterminer la fréquence maximale de fonctionnement dans ce mode, je me suis attaqué à la réalisation d'une maquette qui, de toute façon et au pire, trouvera rapidement une utilisation comme atténuateur variable.



Les résultats ne sont hélas pas à la hauteur des attentes, le découpage étant parfait jusqu'à une fréquence d'environ 50kHZ puis se transformant en un superbe modulateur au-delà.


Chopper à 10KHz, porteuse à 10MHz et 100MHz

Chopper à 1MHz, porteuse à 10MHz et 100MHz
En résumé: une fausse bonne idée qu'un spécialiste de ces composants aurait probablement immédiatement rejetée. Mais n'est-ce pas en forgeant que l'on devient forgeron ?

mardi 8 septembre 2009

Projet ADS-B: Justifications des choix techniques

Une trame de réponse longue MODE-S ressemble à cela:

Extrait du remarquable site 'www.radartutorial.eu'

Les données sont encodées par la position respective d'impulsions d'une durée élémentaire de 1µS. Ces impulsions correspondent à la présence de la porteuse à 1.090GHz sur cette même durée.

J'ai fait le choix d'utiliser une chaîne à changement de fréquence, la porteuse sera donc transposée à 480Mhz (valeur de la 1ere FI) puis à 37Mhz (valeur de la 2ième FI). La durée d'une impulsion ne change pas mais sa représentation passera de 1090 périodes de 0.912ns à 37 périodes de 27ns soit trente fois moins d'échantillons que n'en aurait une chaîne de mesure directe telle que celle utilisée par les récepteurs du commerce.

La détection de ces impulsions est assurée par un amplificateur logarithmique AD8307 suivi d'un comparateur de tension, l'ensemble formant un détecteur de porteuse très simple. Encore faut-il que celui-ci offre un temps de réponse permettant de détecter des impulsions aussi courtes, sa bande passante - 500MHz - étant elle largement suffisante.

Les spécifications techniques de ce composant annoncent un temps de réponse - passage de 10% à 90% du signal de sortie - de 400ns pour des signaux de faible amplitude (<100mV) et de 500ns au delà. En fait, ce composant courant est hélas le plus lent de toute la gamme, l'AD8313 annonçant 40ns, l'AD8317 seulement 20ns et l'AD8310 quelques 10ns. La lecture des courbes de réponse laisse entendre que je devrais cependant pouvoir l'utiliser n'ayant aucune des contraintes fortes qui s'appliqueraient à un système commercial embarqué.
Extrait de la documentation technique AD8307

Si la maquette devait démontrer que le temps de réponse de l'AD8307 est insuffisant, je le remplacerais par un AD8310, hélas moins adapté au maquettage car utilisant un boîtier SOIC.

lundi 7 septembre 2009

Projet ADS-B: Tuner SAT Mitsumi TSU2-E01P - 5

Le câblage sur une platine de test est suffisamment avancé pour permettre quelques mesures sur la chaîne de réception actuellement constituée du tuner, d'un filtre SAW suivi d'un NE592 et d'un AD8307.


Pour plus de 200µV en entrée du tuner, le NE592 délivre presque 2Vcc, le filtre SAW apportant une atténuation de près de 18dB dans la chaîne. Le détecteur constitué du circuit AD8307 travaillera donc dans la plage haute de sa dynamique de mesure.

Les tests effectués à 990MHz - je n'ai pas de générateur montant à 1.090GHz - donnent les mesures suivantes en sortie du détecteur:
- 1.34V -> Pas de signal
- 1.88V -> 20µV
- 2.14V -> 66µV
- 2.39V -> 200µV et plus

Cette configuration permet donc de détecter un signal au-dessous du niveau de sensibilité du tuner (200µV). Il me reste à câbler un comparateur type LM311 en sortie de l'AD8307. Il sera alimenté en 5V et sera réglé pour basculer juste au dessus de 2V, avec peut être un hystérésis. A voir ...

Je ne sais pas encore comment je vais pouvoir tester la réponse impulsionnelle de l'ensemble, n'ayant pas la possibilité de piloter le synthétiseur en tout ou rien. Je crains de devoir valider le fonctionnement 'in situ' en raccordant une antenne et en visualisant les séquences reçues sur la sortie logique via mon analyseur logique.

dimanche 6 septembre 2009

Projet ADS-B: Tuner SAT Mitsumi TSU2-E01P - 4

S'ils sont fort pratiques s'agissant de circuits logiques, les régulateurs à découpage ne font décidément pas bon ménage avec les circuits linéaires. J'ai longuement hésité s'agissant de l'alimentation 12V et 5V du tuner et de la glue associée pour me décider à finalement employer une alimentation à découpage à base de LM2575.

Le résultat fût à la hauteur, non de mes attentes, mais de mes craintes. Certes le bilan énergétique est là mais les perturbations aussi, et ce malgré avoir scrupuleusement suivi les recommandations du fabricant, notamment sur la disposition du circuit de masse, et la diode de récupération. Après une après-midi passée à tenter de réduire la pollution générée sur les rails d'alimentation - 15mV de bruit de découpage à 52kHz - j'ai abandonné ce choix pour repasser sur une alimentation traditionnelle.

Mon erreur provient probablement de la sélection d'une inductance ne correspondant pas aux références fournies dans le datasheet, et d'une valeur sélectionnée pour un courant plus élevé que celui actuellement consommé par la maquette. Quoiqu'il en soit, l'utilisation de ces alimentations nécessite des précautions incompatibles avec le maquettage et les circuits que j'utilise.