Projet ADS-B: Firmware 2.9

Je n'ai guère eu le temps de faire avancer ce projet ces dernières semaines.

En fait le réaménagement de mon environnement m'a pris bien plus de temps que prévu avec notamment la découverte de problèmes divers sur les équipements, et ceci bien sûr après qu'ils aient été installés en rack. La loi de Murphy dans toute sa grandeur. Les choses s'étant semble-t-il stabilisées, avec la réinstallation du système dédié à la gestion de la carte Wavecom W61PC, des télécommandes et des liaisons VoIP, j'ai replongé dans le projet ADS-B.
Il faut dire que mon ami Guenter, DL4MEA, m'y a un peu poussé en améliorant le comparateur d'entrée de son kit pour obtenir une plus grande dynamique face à des signaux de niveau très variable. La technique retenue, fort astucieuse, ne permet cependant plus de garantir la présence d'un niveau bas en l'absence de signal. Le procédé d'acquisition du préambule de la trame ADS-B consistant à rechercher classiquement un changement d'état indiquant la réception d'une impulsion doit en conséquence être revu.
Le code de recherche et d'acquisition du préambule a donc été réécrit pour tenir compte de cette contrainte. J'ai profité de l'occasion pour réintégrer l'optimisation de l'automate que j'avais mise en oeuvre dans la version 1 - rebouclage des 12 états d'erreurs possibles sur l'état 2 de l'automate - puis rapidement abandonné ne trouvant pas l'astuce de programmation me permettant de faire coexister cette technique avec les contraintes imposées par la mise en place de l'horodatage des trames et la gestion des interruptions.
Quelques (difficiles) heures de réflexion m'ont finalement permis de venir à bout du problème. Comme bien souvent, le code final est tellement simple qu'on ne peut imaginer la complexité de sa construction s'agissant de garantir un temps d'exécution précis au cycle près, ici 83.333ns. Que de temps passé à vérifier la bonne synchronisation de l'échantillonnage du signal pour chacune des branches possibles du code.
C'est d'ailleurs durant l'une de ces vérifications que j'ai découvert un décalage d'un cycle présent dans les versions antérieures. Ce décalage, qui peut conduire à rejeter des trames longues, est impossible à annuler mais il peut être compensé sans impact sur le taux d'erreur en avançant d'un cycle l'échantillonnage suivant.
Je doute qu'il me soit maintenant possible d'aller plus loin que le code inclus dans le firmware 2.9 à paraître dans les jours à venir, du moins avec ce microcontrôleur.