lundi 14 décembre 2009

Projet ADS-B: Messages TIS-B

L'analyse des messages 'ADS-B' n'est pas simple pour qui n'est pas de la partie, et n'a pas connaissance de l'historique de ce système. Ainsi, les structures de données utilisées pourront sembler avoir été organisées en dépit du bon sens si l'on ne tient pas compte de l'historique et des probables contraintes d'intéropérabilité avec les systèmes existants.

Les standards sont par ailleurs en perpétuelle évolution, le système n'étant pas encore réellement stabilisé, c'est du moins ce qu'il me semble à la lecture des nombreux documents de travail disponibles sur Internet.

Ceci est particulièrement vrai en ce qui concerne la structure des données du message DF=18, message transportant les informations du service TIS-B défini dans le DO286A.

Je dois avouer avoir eu le plus grand mal à intégrer le décodage de ce message dans la dernière révision de la version 2 du code de mon décodeur PicADSB. La validation de mon implémentation est d'autant plus difficile qu'aucun message de ce type n'a pu être collecté à ce jour.

Ce service est-il actuellement implémenté à grande échelle, je n'en ai aucune idée et aucune information précise n'est disponible à ce sujet sur Internet.

dimanche 13 décembre 2009

Antenne: Extension du système

L'arrivée d'un récepteur VLF/LF et la transmission SAQ annoncée pour Noël sont autant de raisons pour faire quelques essais d'antennes VLF. Encore faut-il pouvoir passer les coaxiaux et éventuels câbles de pilotage d'une boîte d'accord en provenance du jardin.

J'ai donc décidé d'ouvrir un nouveau passage dans le shack lequel se prolongera dans le jardin à travers deux tubes de PVC de diamètre 80mm vers le lieu d'installation des antennes.

La température était à peine positive, hier et aujourd'hui. Ce n'est pas l'idéal pour engager des travaux de maçonnerie mais d'un autre coté la pelouse aura du temps pour repousser en fin d'hiver sur les deux tranchées qu'il m'a fallu ouvrir.



Une pente fortement négative à l'arrivée dans le shack devrait éviter une possible remontée d'eau. En effet, l'une des sorties arrivant sur le talus se trouve plus haute que l'arrivée dans le shack. Elle est protégée pour l'instant par un bouchon étanche. En cas d'infiltration, l'eau s'évacuera par la seconde sortie positionnée sur l'un des cotés de la maison, bien plus bas que l'arrivée dans le shack.

Ca devrait le faire ;-)

Un coup de peinture, et le shack se trouve doté d'un deuxième accès. A gauche, l'arrivée des coaxiaux en provenance du toit par l'extérieur.



Coté jardin, j'ai calculé un peu court et il va me falloir intervenir de nouveau le week-end prochain après avoir réapprovisionné du tube PVC.

lundi 7 décembre 2009

Divers: Analyse de code

Les microprocesseurs ont fait leur apparition dans les récepteurs professionnels dans les années 80. S’il est assez aisé de dépanner les matériels faisant appel à de la logique câblée, même en l’absence de documentation, ce n’est plus le cas lorsque l’équipement est piloté par un processeur.
Il n'y a rien de plus désespérant que de se retrouver face à un matériel affichant un simple code d’erreur au démarrage, ou après un autotest, sans disposer de la documentation permettant d’interpréter ce code. Et il est des équipements dont la seule certitude que l’on puisse avoir est qu’il a bien longtemps que cette documentation a disparu de la circulation.

Il faut alors employer une approche qui n’a plus grand-chose à voir avec l’électronique classique mais qui par contre est très couramment utilisée dans le domaine de la sécurité des systèmes d’information et de la lutte contre les codes malveillants: l’étude détaillée du logiciel de contrôle de l’équipement permettra d’identifier les grandes fonctionnalités de celui-ci et, avec un peu de chance et de méthode, de cerner l’origine du dysfonctionnement.

Cette étude suppose d’extraire le contenu des mémoires mortes puis de traiter fichier binaire ainsi obtenu pour remonter au code assembleur. Une opération appelée désassemblage, ou décompilation, assez strictement encadrée par la loi (Article L122-6-1 du Code de la Propriété Intellectuelle).

Dans la plupart des cas, l’équipement n’étant plus commercialisé, encore moins maintenu, l’équipementier ayant parfois même disparu, cette décompilation effectuée à titre personnelle, et sans communication des résultats, ne sera pas répréhensible. Encore faut-il disposer de l’outillage ad hoc, et d’un minimum d’informations sur la structure du microprocesseur et des périphériques associés.

L’outillage est le point le plus délicat. S’il est en effet aisé de trouver de fabuleux outils pour la famille des processeurs Intel x86 utilisés dans nos PC – désassembleur OllyDbg par exemple – peu d’outils, hors ceux proposés par le fondeur, sont disponibles pour les autres processeurs.

Il existe toutefois un fabuleux outil commercial capable de désassembler le code des processeurs les plus courants: l’outil IDA dans sa version professionnelle, hélas bien peu abordable pour l’amateur. Tous les processeurs n'y sont cependant pas traités à l’identique. Si pour les processeurs usuels – Motorola et Intel – l'analyse est irréprochable, il n’en va pas de même avec des processeurs complexes tels les processeurs de signaux et en particulier les processeurs Texas Instruments de la famille TMS320 pour lesquels le désassemblage est incomplet voir erroné. L’utilisateur devra alors s’atteler à la difficile tâche de modifier le code du générateur, code fort heureusement livré avec le logiciel.

Disposant du bon outil, il faudra ensuite configurer celui-ci pour que le code assembleur généré soit le plus exploitable possible.

Deux options s’offrent alors. Les adresses de tous les périphériques – E/S, RAM, PIO, PIA… - sont connues, il suffira alors de les déclarer symboliquement rendant le code généré bien plus lisible. Pour ma part et avec IDA Pro, je déclare chaque périphérique dans un segment dédié.


Dans l’hypothèse où ces adresses ne seraient pas connues – absence de toute schématique – il faudra déterminer celles-ci statiquement en étudiant le câblage, une opération longue et fastidieuse, ou bien dynamiquement ce qui sous-entend toutefois que l’équipement démarre partiellement. A cette fin, le bus d’adresse sera supervisé par un analyseur logique – j’utilise pour cela un vieux mais excellent Tektronix 1241 – et l’acquisition déclenchée par le signal de sélection du périphérique. Avec un peu d‘habitude, l’opération va très vite.

L’outil étant configuré, l’opération de désassemblage peut commencer, et avec elle un processus d’analyse itératif pouvant être très long.

Le dicton ‘cent fois sur le métier tu remettras ton ouvrage’ s’applique ici parfaitement car l’outil ne peut aller au-delà de ses limites et il faudra régulièrement intervenir pour corriger l’analyse, pour nommer les fonctions au fur et à mesure que l’on comprend leur rôle, pour assigner un nouveau nom à une variable…


Peu à peu les choses se dessinent, la logique apparaît, la méthode s’affine et l’on est capable d’identifier la structure du code. S’agissant d’un programme écrit en langage assembleur natif, le style du programmeur transparait permettant d’accélérer le travail d’analyse. Que le programme ait été écrit en langage évolué – langage C en général – et l’on sera rapidement à même d’identifier la transcription des instructions de contrôle complexes telles les switch, for ou do loop.

Et après quelques heures de travail, voire quelques week-ends, l’objectif est enfin atteint : toutes les informations requises pour interpréter le code d’erreur affiché, ou le cas échéant cibler le composant susceptible d’être à l’origine de la panne, sont en notre disposition.
Cette approche m’a ainsi permis de comprendre une fonctionnalité non documentée présente sur l’une des versions du programme équipant mon récepteur RACAL 1792 – processeur Mostek F8 - et de modifier ce code pour éliminer la limitation de la fréquence maximale.

Appliquée à un autre récepteur – processeur 6809 - affichant un comportement erratique, elle m’a permis d’identifier les routines de test puis les combinaisons d’un dip-switch permettant d’activer celles-ci. Le test de la mémoire vive ainsi identifié a permis de mettre en évidence un défaut aléatoire dans la RAM.

dimanche 6 décembre 2009

TRC2xx: Rétro-éclairage

Les lucioles permettant l'éclairage des LCD des récepteurs Thomson TRC-243, TRC-241, et autres, sont bien souvent hors service. Il est possible de les remplacer à l'identique, ou bien de leur substituer une diode LED avec une intensité d'éclairage bien plus faible. Il suffit pour cela de limer une diode 3mm afin de réduire sa hauteur et de la glisser dans le puit prévu pour la luciole.



Selon le modèle du récepteur, on modifiera les deux résistances d'alimentation des lucioles (TRC243 et TRC241). On pourra aussi ajouter une résistance CMS au pied de chaque diode LED lorsque les lucioles sont directement alimentées par le rail 5V de la logique. C'est le cas du récepteur sur lequel je suis aujourd'hui intervenu.



Sans être aussi lumineux qu'à l'origine, l'éclairage permet de lire l'affichage dans des conditions de luminosité externe faible.

samedi 21 novembre 2009

Divers: Dead Bugs

Il y a quelques mois, j'ai pris la décision de conserver les composants hors service - dead bugs - en provenance des matériels que je répare afin de pouvoir me faire une idée sur l'origine des principales pannes rencontrées. Il apparaît que les condensateurs chimiques et les circuits logiques TTL et CMOS font partis des pièces les fréquemment remplacées, du moins sur mes matériels.

Une petite image pour s'en convaincre.


Les spécialistes auront reconnu les 'infames' condensateurs WIMO - condensateurs au boîtier argenté - équipant certaines séries de récepteurs RS560, des tantales en boitiers expoxy - rectangles noirs en haut à gauche - en provenance de matériels Francais et Allemands, et un lot de condensateurs chimiques - pourtant récent mais affectés d'un problème de fuite du diélectrique - installés sur une des cartes d'un récepteur Nardeux.

Les circuits logiques ont tous perdu leurs pattes. Ceci est dû à l'approche que j'utilise désormais quand le coupable est identifié, ou soupçonné: coupure des pattes, sans façon et au plus près du boîtier, pour ensuite extraire une à une celles-ci au fer à souder et avec une brucelle. Ainsi je ne risque plus de détruire les trous métallisés ou d'arracher une piste. Il faut dire que certains circuits imprimés n'ont visiblement jamais été conçus pour être réparés...

vendredi 20 novembre 2009

TRC241: Quelques problèmes

Mes dernières soirées ont été occupées par le dépannage d'un TRC241 affecté de quelques problèmes:
- Initialisation du panneau avant erratique,
- Filtre d'entrée demi-octave ne fonctionnant pas sur l'une des bandes,
- Démodulation AM entâchée d'un sifflement infernal,
- Un fonctionnement erratique du clavier.

L'origine du  problème de l'initialisation erratique du panneau a indirectement été déterminée par le nécessaire contrôle des tensions d'alimentation. Ce contrôle a mis en évidence l'absence de tension sur un rail 5V identifié VH par la sérigraphie. Un coup d'oeil sur la schématique montre que cette tension contrôle le signal HALT du processeur verrouillant celui-ci tant que les tensions ne sont pas établies et l'arrêtant proprement lors de la détection d'une perte de tension. Le module de commande est simple, 3 condensateurs, 2 résistances et un régulateur LowDrop. Premiers mis en cause, les condensateurs sont vérifiés au pont de mesure, et l'un d'entre eux défectueux est remplacé. Les choses s'améliorent mais le fonctionnement reste aléatoire. Le remplacement d'office des deux autres condensateurs règle définitivement le problème. Un test a posteriori de l'un des condensateurs avec un bias d'alimentation proche de sa tension nominale met en évidence un courant de fuite qui n'apparaissait pas au pont de mesure en mode alternatif pur.

Le problème de la démodulation AM a vite été réglé, son origine étant localisée autour d'un circuit Plessey. Un rapide test du transistor 2N2222 chargé de la gestion du gain a montré que celui était HS.

La recherche de l'origine du problème dans le filtre demi-octave a demandé un peu de réflexion, n'ayant aucun prolongateur de test et l'accès à la carte étant peu aisé. Le premier test a consisté à valider les fonctionnements des deux relais de commutation de la bande ne fonctionnant pas, et en priorité la continuïté de la bobine. La lecture de la résistance des deux bobines en parallèle des relais a permis de confirmer que l'une d'entres-elles était coupée: la résistance mesurée était le double de celle mesurée sur les bobines d'une gamme fonctionnelle. Le dessoudage et le test du relai le plus près de l'antenne a confirmé la coupure de sa bobine, un coup de chance car le problème aurait pu se situer sur l'autre relais, nécessitant un second dessoudage.



La récupération d'un relais sur la carte d'un amplificateur de puissance puisée dans mes stocks de pièces de rechange a permis de finaliser le dépannage, ce type de relais étant assez spécifique.

La réfection de certaines soudures qui, à l'oeil apparaissaient ne pas être correctes, semble avoir résolu le problème de fonctionnement du clavier. Le multiplexage de celui-ci avait été vérifié auparavant par l'observation des signaux à l'oscilloscope.

mercredi 11 novembre 2009

Shack: Début du grand rangement d'hiver

L'arrivée de nouveaux matériels, le manque de place et quelques week-ends de libres sont l'occasion d'engager le grand rangement d'hiver. La priorité était la réorganisation de l'atelier de travail, et c'est chose faite. La place n'a jamais été aussi nette mais celà va-t-il durer ?



Il reste maintenant à ranger les composants encore en vrac dans diverses boîtes, mais j'avoue repousser sans cesse ce travail laborieux et pourtant indispensable. Les congés de Noël seront les bienvenus pour finir ce tri.

samedi 7 novembre 2009

HP4192A: Condensateurs HS

J'ai eu la chance de pouvoir récupérer un pont d'impédance HP-4192A promis à la benne. En parfait état extérieur, celui-ci n'a pas démarré lors de sa remise sous tension. Aucun affichage, aucune réaction lors de la manipulation des fonctions, seul le ventilateur tourne. Un démontage du panneau supérieur me donne accès à l'alimentation à découpage, la protection de sécurité enlevée mettant en évidence un fusible grillé. Les condensateurs de filtrage 10µF/350V ont une bien mauvaise allure. Après dessoudage, il s'avère que les quatre condensateurs ont fuit et se comportent comme un résistance de quelques centaines d'ohm provoquant un appel de courant ayant fait griller le fusible.



N'ayant pas de condensateurs de ce type en stock, il m'a fallu me résoudre à faire un aller retour vers la plus proche boutique de composants électroniques sur Paris pour acheter quatre remplacants de bonne qualité (105°C et faible).



L'ensemble est bien vite remonté après nettoyage de la platine et la mise sous tension est un succès. Je dispose désormais d'un pont de mesure automatique emcombrant (format 19" en 8U) mais offrant des performances supérieurs à mon pont MW notamment dans le domaine des fréquences de mesure: 5Hz à 13MHz.


Il me faut maintenant réorganiser ma surface de travail pour y intégrer cet instrument.

jeudi 5 novembre 2009

Projet ADS-B: Quelques réalisations

Plusieurs amateurs ont réalisé leur récepteur ADS-B en s'inspirant de mon projet, et en l'adaptant en fonction des composants qu'ils avaient sous la main.

- Francois, F5ANN, a utilisé un ensemble récupéré d'un décodeur satellite constitué d'un tuner disposant d'une sortie 749.5Mhz et d'un convertisseur fournissant une fréquence intermédiaire à 70Mhz.



- David, G4FEV, a réalisé sa propre tête de réception à partir, ici encore, de composants récupérés sur des équipements de réception satellite. Son site: http://g4fev.atspace.com/adsb.htm

dimanche 1 novembre 2009

TRC180: L'effet 'démo'

J'ai pris l'habitude de mettre régulièrement sous tension pour quelques heures les équipements que je n'utilise pas au quotidien. Il en va ainsi de l'un des mes TRC-180, lequel est assez particulier au regard du format du rack qui accueille ses modules mais aussi de la présence, non pas du classique synthétiseur à pas fixe TRC-2105, mais d'un synthétiseur à adjustement continu PS-491.



Un ensemble assez rare, datant des années 72, parfaitement fonctionnel jusqu'à dernièrement, où suite à une démonstration, le synthétiseur est tombé en panne. Le fameux effet 'démo', un dérivé de la loi de Murphy dite de l'emmerdement maximum.



Et de fait, l'ensemble de synthèse est complexe au regard de ce qui se fait de nos jour en utilisant nombre de composants désormais totalement obsolètes et introuvables. Je me suis donc attaqué à la remise en état avec les plus grandes craintes.

Une procédure rigoureuse de recherche de la panne m'a rapidement amené à soupconner le module 'interpolateur' qui intègre l'oscillateur variable - 200/300kHz - commandé par le potentiomètre de la face avant et le mélange de celui-ci avec un signal à 90MHz auparavant divisé par 10 par une ensemble de diviseurs ECL. La loi de Murphy aidant, ce module est l'un des rares qui ne soit pas monté sur connecteur et nécessite d'être déssoudé.

Après avoir alimenté indépendament celui-ci, le problème est rapidement isolé: l'oscillateur variable n'oscille pas. Un rapide test in-situ des composants posant classiquement problème - condensateurs et diodes - met ceux-ci hors de cause.


Le dessoudage et le test du J-FET 2N3823 de l'oscillateur montre que celui-ci est hors service. N'ayant pas ce modèle en stock, je décide de le remplacer par le 2N3823 monté en résistance variable et chargé de réguler le niveau de sortie de l'oscillateur. Ce dernier sera à son tour remplacé par un bon vieux J310, la fonction n'étant ici pas critique.

La remise sous tension du module montre que l'oscillateur redémarre, et le remontage du tiroir dans le récepteur prouve que tout est rentré dans l'ordre. J'approvisionnerai à l'occasion quelques 2N3823 pour pièces de rechange.

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.

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.