(EFIS-EMS ESP32 : Dernière mise à jour par Benjamin le 25 mars 2026)
L’ESP32 EFIS-EMS est un système entièrement repensé qui combine un EFIS et un EMS sur un seul écran de 7 pouces. Le système précédent comportait deux écrans, l’un pour l’EFIS et l’autre pour l’EMS, tous deux basés sur des cartes Teensy 4.1. Ce nouveau système se distingue en introduisant des microcontrôleurs ESP32. Ces microcontrôleurs, d’une part, permettent d’importantes améliorations de l’interface graphique, et d’autre part, permettent une communication sans fil entre certains composants.
Les lecteurs sont encouragés à consulter les pages « Écrans TFT et avionique DIY » et « Les cartes microcontrôleur Arduino, Teensy et ESP32 », qui ont été révisées en conséquence. L’un des principaux objectifs de ce nouveau système était de repenser entièrement l’interface utilisateur pour lui donner un aspect plus proche de celui des instruments professionnels. Deux autres objectifs étaient de réduire la taille globale du système et d’améliorer la qualité des connexions avec les nombreux capteurs.
Un pré-prototype de ce système a d’abord subi avec succès des essais en vol, comme illustré ci-dessous. Ces tests visaient à valider plusieurs options et innovations, permettant une évolution vers l’architecture finale actuelle.
Architecture de l’EFIS-EMS ESP32
L’ESP32 EFIS-EMS intègre plusieurs éléments existants qui restent inchangés, à savoir l’AHRS , le micro-EMS, et le RCM (pour Remote Compass Module, un module magnétomètre distant associé à un capteur externe de température et d’humidité).
Deux nouveaux modules sont introduits : un module d’affichage et un module d’acquisition de données distantes, ou RDAM (Remote Data Acquisition Module). Le RDAM doit être considéré comme le module central d’acquisition de données. L’AHRS, le micro-EMS et le RCM sont des modules spécialisés d’acquisition de données.
Tous ces modules communiquent entre eux via le bus CAN. De plus, le RDAM et le module d’affichage échangent entre eux des données via Wi-Fi. Cette architecture est illustrée à la figure 1.
Cette architecture modulaire est conforme à la philosophie globale IMA (Integrated Modular Avionics, ou Avionique Modulaire Intégrée) du projet AvionicsDuino. Chaque module gère une fonction spécifique et communique avec tous les autres via le bus CAN. L’avantage de cette architecture modulaire réside dans la facilité d’entretien et d’évolution de l’ensemble du système.
Prototype provisoire de l’EFIS-EMS ESP32
Pour valider ce nouveau système et poursuivre le développement, un prototype temporaire a d’abord été testé en vol, comme mentionné dans l’introduction.
Le prototype du module d’affichage
Ce prototype comprenait un module d’affichage du commerce de 7 pouces, de qualité IPS, avec une résolution de 800 x 480. Le contrôleur graphique de cet écran est un microcontrôleur ESP32-S3 intégré à un PCB collé à l’arrière du panneau TFT. L’ensemble de l’interface graphique est donc programmé sur cet ESP32.
Ce dispositif présente une couche tactile capacitive, ce qui a permis de tester un système de menu sans boutons ni encodeurs rotatifs, dans des conditions de vol réelles. Il était en effet nécessaire de tester sous la lumière directe du soleil un écran tactile, donc brillant, de luminosité moyenne (400 cd/m²), représentatif des écrans tactiles similaires directement disponibles dans le commerce. Et aussi de tester les capacités de communication sans fil de l’ESP32 via le protocole ESP-NOW d’Espressif, qui repose sur le Wi-Fi. Pour ces premiers tests, la seule connexion électrique de ce module d’affichage à l’aéronef était son alimentation électrique. Il n’était pas connecté au bus CAN.
Aucun changement des circuits électriques de l’aéronef, ni des instruments existants du tableau de bord, n’était nécessaire pour ces tests préliminaires. Le module d’affichage, monté dans un boîtier en ABS imprimé en 3D, était placé sur un support provisoire devant la boîte à gants. Il était alimenté via son port USB, connecté à un chargeur de téléphone branché sur la prise allume-cigare de l’aéronef.
Le module temporaire des capteurs de pression.
Par conséquent, un petit module supplémentaire a été spécialement conçu pour ces tests, également basé sur une puce ESP32-S3, préfigurant le futur RDAM. Ce module était connecté au bus CAN et communiquait avec le module d’affichage via ESP-NOW, servant ainsi d’intermédiaire entre le module d’affichage et l’avionique existante.
Ce module comprenait, outre un transceiver CAN, un capteur de pression barométrique (AMS5915-1500A) connecté au circuit de pression statique, et un capteur de pression différentiel (AMS5915-0050D) connecté au port statique et à la sonde Pitot (les mêmes capteurs de pression que ceux de l’EFIS Teensy en place). Le module recevait toutes les données moteur de l’EMS et du micro-EMS existants, via le bus CAN, ainsi que les données provenant de l’AHRS et du RCM.
Aucune modification logicielle n’a été nécessaire sur l’EFIS et l’EMS Teensy toujours en place pour ces tests, ni sur le micro-EMS, l’AHRS et le RCM, car toutes les données traitées par ces modules étaient déjà transmises au bus CAN. Le module provisoire a été placé dans un boîtier temporaire imprimé en 3D, fixé avec du Velcro sous le tableau de bord (Fig. 2).
Pour ces tests, l’architecture provisoire du système était donc celle illustrée à la Figure 3.
Ainsi, ce prototype fonctionnait en parallèle avec les systèmes Teensy existants, EFIS et EMS.
Résultats des essais en vol du prototype provisoire
Ils ont validé les principes fondamentaux de ce nouveau système et ont permis d’identifier des axes d’amélioration. La photo de la figure 4 et la vidéo ci-dessous (Vidéo 1) ont été prises lors du premier vol d’essai. Sur l’image, l’EFIS-EMS ESP32 se trouve à droite, avec son écran unique, et l’EFIS et l’EMS Teensy à gauche. En dessous et à droite du tableau de bord, on aperçoit le module temporaire vert.
Comparaison des données
Les données affichées par les deux systèmes étaient identiques, y compris celles provenant des deux ensembles de capteurs de pression dans les deux EFIS. Ces données de pression EFIS avaient fait l’objet d’une validation approfondie, en partie en les comparant avec le Dynon D10 EFIS de référence installé sur cet aéronef (voir la page EFIS Teensy), et en partie par une étude expérimentale des capteurs de pression utilisés (voir la page capteurs de pression EFIS).
Compatibilité électromagnétique et ESP-NOW
La communication ESP-NOW entre modules s’est déroulée sans faille. Aucune interférence électromagnétique n’a été observée entre ce prototype, logé dans des boîtiers temporaires non blindés, et le système radioélectrique de l’aéronef, malgré la conception suboptimale de la carte PCB du module provisoire des capteurs de pression.
Qualité d’affichage et ergonomie de l’écran tactile
Ce premier vol a été réalisé dans des conditions idéales, au coucher du soleil. La photo et la vidéo ont été prises avec une lumière rasante, de faible intensité et venant de l’avant. Bien sûr aucun reflet n’a été noté sur les écrans mats de l’EFIS et de l’EMS Teensy. Et dans ces conditions optimales, les faibles reflets sur l’écran brillant de l’EFIS-EMS ESP32, et sa luminosité modeste, étaient tout à fait acceptables.
Mais lors de vols ultérieurs en journée, avec le soleil beaucoup plus haut dans le ciel, éclairant directement l’écran, une luminosité de 400 cd/m² s’est avérée nettement insuffisante. De plus, cet écran tactile brillant est sujet à de forts reflets, ce qui le rend parfois presque illisible, contrairement aux écrans mats des EFIS et EMS Teensy.
Enfin, bien que satisfaisante au banc d’essai, l’utilisation des menus tactiles s’est révélée peu ergonomique en vol, et même assez fastidieuse en cas de turbulences, même modérées. Malgré la grande taille des boutons tactiles comme l’illustre la vidéo 2.
La nouvelle version du module d’affichage
Concernant les reflets sur les écrans tactiles, il aurait sans doute été possible d’envisager des filtres antireflet, mais ceux-ci réduisent la luminosité et la netteté. Par conséquent, ils ne constituent pas une solution idéale, surtout sur des écrans déjà peu lumineux.
Étant donné qu’aucun écran non tactile, mat, IPS, lisible en plein soleil et de 7 pouces n’était directement disponible dans le commerce, il a été nécessaire d’en fabriquer un. Il repose sur une carte électronique personnalisée utilisant un SoC ESP32-S3-WROOM 1 N16R8 et un panneau TFT Newhaven NHD-7.0-800480AF-ASXP. Ce panneau est mat, IPS, non tactile, et possède une luminosité de 1000 cd/m².
Pour l’interaction avec les menus et l’interface graphique, l’écran tactile a donc été définitivement abandonné au profit d’une rangée de six boutons poussoirs situés sous l’écran.
Résultats
L’aspect général est présenté sur la figure 5, qui montre le module d’affichage dans son boîtier en ABS imprimé en 3D.
Les tests au banc ont été très satisfaisants. L’écran mat de 1000 cd/m² reste parfaitement lisible en plein soleil, sans reflets, et le clavier fonctionne parfaitement (vidéo 3).
La conception de ce module d’affichage est désormais stable ; aucune modification supplémentaire n’est prévue. Sans apporter de changement au PCB, on peut utiliser soit un module ESP32-S3-WROOM 1, soit un ESP32-S3-WROOM 1u ; ce dernier dispose d’un connecteur U.FL pour une antenne Wi-Fi distante plutôt que l’antenne intégrée sur la carte du SoC. Cela pourrait être utile pour améliorer la qualité de la communication ESP-NOW avec le RDAM. Par exemple, si les deux modules sont placés de part et d’autre d’un tableau de bord en aluminium, celui-ci pourrait agir comme un écran RF.
Le module d’affichage est également équipé d’un transceiver CAN, au cas où le bus CAN serait préféré à l’ESP-NOW. Avec quelques adaptations logicielles, l’utilisateur peut donc faire son propre choix.
Module d’affichage : téléchargements.
AvionicsDuino ESP32 EFIS-EMS: Code source sur GitHub
Pour installer le logiciel du module d’affichage avec l’IDE Arduino, sélectionnez la carte « ESP32S3 Dev Module ». Ensuite, la taille de la mémoire flash : « 16MB (128 Mb) », le schéma de partition : « Huge APP (3MB No OTA/1MB SPIFFS) », la PSRAM : « OPI PSRAM ».
Le module d’acquisition des données distantes (RDAM)
Plusieurs choix s’offraient : fallait-il utiliser des circuits imprimés séparés pour l’EFIS et l’EMS, comme dans le système actuel Teensy, ou combiner l’ensemble sur un seul PCB? Et d’autre part, quel microcontrôleur utiliser : Teensy 4.x ou ESP32 ?
Le PCB
Pour optimiser l’utilisation de la place, un seul PCB à 4 couches a été choisi, afin d’augmenter la densité des composants. De plus, un PCB à 4 couches permet d’améliorer beaucoup la compatibilité et l’immunité aux interférences électromagnétiques.
Le microcontrôleur
L’ESP32-S3 a été sélectionné pour exploiter la connectivité Wi-Fi ESP-NOW avec le module d’affichage. La carte Seeed Studio XIAO ESP32-S3 est idéale en raison de sa taille particulièrement compacte. Cependant, en raison de ce choix, le problème bien connu de la faible performance de l’ADC (convertisseur analogique-numérique) de l’ESP32 a dû être réglé.
Les problèmes de l’ADC sur les ESP32
Comme de nombreux utilisateurs, nous avons observé une importante non-linéarité sur l’unique ADC disponible (le second étant réservé au système). En suivant la procédure de calibration d’Espressif, la linéarité peut être améliorée. Mais il existe un second problème avec cet ADC : il est très sensible aux parasites (surtout par rapport aux ADC des cartes Teensy 4.x), notamment lorsque le Wi-Fi est actif.
Par conséquent, il a été décidé d’utiliser deux ADC externes (ADS7828) connectés au bus I2C, l’un pour les capteurs ratiométriques et l’autre pour les capteurs non ratiométriques.
Un premier prototype, puis le RDAM définitif, ont été assemblés et testés. De nombreux tests préliminaires au banc, sur de petits sous-ensembles, ont permis d’être assez optimiste quant au résultat final. Néanmoins, il fallait démontrer qu’un seul ESP32-S3 pouvait gérer simultanément le Wi-Fi, le bus CAN et six périphériques esclaves sur le bus I2C (deux ADC externes et quatre capteurs de pression) tout en maintenant un taux d’échantillonnage suffisant, et en tenant compte d’autres limitations de l’ESP32.
Autres problèmes potentiels de l’ESP32
Le bus I2C
Une inquiétude pouvait provenir spécifiquement du bus I2C. Même en suivant strictement les procédures d’Espressif pour l’initialisation du bus I2C et des périphériques esclaves, les mesures à l’oscilloscope et à l’analyseur logique montrent des latences non compressibles de 50 à 70 µs entre toutes les transactions I2C, ce qui réduit la bande passante du bus. Cela impacte le taux d’échantillonnage et, potentiellement, la qualité du filtrage des données numériques. De telles latences ne sont pas observées avec les cartes Teensy 4.x.
Le problème du bruit
Une autre source d’inquiétude concernait le bruit. Les tests avec des ADC externes, sur des breadboards, en utilisant des fils volants et des connecteurs Dupont, sans plan de masse, ont suscité quelques préoccupations quant à ce qui pourrait advenir par la suite. Dans des conditions expérimentales similaires, les cartes Teensy, avec leur propre ADC, se sont révélées beaucoup moins bruyantes.
Le premier prototype de la carte PCB à 4 couches, avec deux plans de masse, a heureusement démontré que la conception était solide. Malgré les latences mentionnées, le taux d’échantillonnage des 6 périphériques esclaves sur le bus I2C est suffisant (300 Hz), tout en assurant la communication nécessaire sur le bus CAN et le Wi-Fi pour ESP-NOW.
Les plans de masse et la séparation stricte entre analogique et numérique sur le PCB ont considérablement réduit le bruit électronique par rapport aux tests initiaux sur breadboard. Le filtrage numérique élimine presque complètement le bruit résiduel.
Le RDAM définitif
Quelques modifications mineures du premier prototype ont été nécessaires, en raison de quelques petites erreurs de conception (empreintes incorrectes pour certains composants et oubli de points de masse parmi les points de test du PCB). Le PCB définitif du RDAM est désormais prêt.
En réalité, il s’agit de deux PCB empilés (Fig. 6). Le PCB supérieur, à quatre couches, accueille tous les composants et les deux connecteurs SUB-D sur sa face supérieure. Tous les capteurs de pression sont placés sur sa face inférieure. Le PCB inférieur, à deux couches, constitue le module d’alimentation électrique, fournissant 5 V à partir du système électrique de l’avion de 14 V (Fig. 7). Les deux PCB sont reliés par des connecteurs mezzanine. En raison de contraintes d’espace, le module d’alimentation développé pour l’EFIS et l’EMS Teensy n’a pas été réutilisé pour l’EFIS-EMS ESP32, au profit d’un module d’alimentation du commerce (fig. 8).
Les raccords pneumatiques
Chaque capteur de pression est relié, à l’intérieur du boîtier, par un tube souple en silicone, à un raccord pneumatique en laiton, fixé au boîtier (fig. 9, 10 et 11). Il s’agit de raccords destinés à des réservoirs de carburant de modèles réduits, très faciles à trouver grâce à quelques mots-clés dans un moteur de recherche (Brass Fuel Nipple Inlet Outlet Filler RC Model Tank DIY). Ces raccords s’adaptent parfaitement aux tubes en Rilsan des circuits pneumatiques d’un avion.
La nature modulaire du RDAM
C’est une caractéristique importante du RDAM. Les composants nécessaires à chaque fonction sont regroupés. Ainsi, si toutes les fonctions ne sont pas utiles dans une installation particulière, il suffit de ne pas souder les composants concernés sur le PCB.
Les entrées disponibles du RDAM AvionicsDuino
- 2 pour les températures des culasses
- 4 pour la température des gaz d’échappement
- 1 pour la température de l’huile
- 1 pour la température du liquide de refroidissement
- 2 pour la pression d’huile (1 pour capteur résistif, 1 pour capteur Keller)
- 2 pour la mesure du courant basée sur un shunt (1 unidirectionnel, 1 bidirectionnel)
- 1 pour un contrôleur de sonde lambda (mesure du ratio air/carburant, AFR)
- 4 capteurs de pression (statique, Pitot, angle d’attaque, pression d’admission)
Les entrées utilisées dans le RDAM testé en vol
- 2 pour les températures culasses, CHT2 et CHT3
- 2 pour la température des gaz d’échappement, EGT3 et EGT4
- 1 pour la température de l’huile
- 1 pour le capteur de pression d’huile résistif VDO
- 2 pour la mesure du courant, basée sur un shunt
- 1 pour l’AFR
- 3 capteurs de pression (statique, Pitot, pression d’admission)
Le moteur est un Rotax 912 UL de 80 CV à carburateurs, équipé d’une hélice à pas variable et d’un système DIY de contrôle du mélange par dépression.
De nombreux pads de composants du PCB restent donc libres, comme on le voit sur la figure 6. Une méthode simple pour garder ces pads inutilisés exempts de soudure, en vue d’une éventuelle utilisation future, consiste à masquer le stencil avec du ruban adhésif en aluminium avant d’appliquer la pâte à souder (Fig. 13).
Les lecteurs souhaitant obtenir des informations techniques détaillées sur le RDAM sont invités à consulter le document « Le PCB du RDAM Pourquoi et Comment », disponible en téléchargement ci-dessous.
RDAM : téléchargements.
Fichiers KiCAD V8 du PCB principal
Fichiers Gerber et perçage du PCB principal
Fichiers KiCAD V8 du PCB d’alimentation
Fichiers Gerber et perçage du PCB d’alimentation
Nomenclature du PCB d’alimentation
AvionicsDuino ESP32 EFIS-EMS: Code source sur GitHub
Le PCB du RDAM Pourquoi et Comment
Fichiers STEP du boîtier du RDAM
Les fichiers STEP du boîtier RDAM sont fournis ici principalement à titre illustratif. L’installation dans l’avion utilisé pour tester l’EFIS-EMS ESP32 est unique, spécifiquement adaptée à cet avion, notamment en ce qui concerne la plaque de fixation RDAM sur le tableau de bord. Cette plaque est fixée sur la face avant du tableau de bord, en utilisant les trous de vis laissés par d’anciens instruments analogiques, tandis que le module d’affichage est fixé à l’arrière du tableau, face au pilote, en utilisant d’autres trous de vis déjà existants. L’agencement de ces éléments pourrait être très différent dans un autre avion.
Pour installer le logiciel du RDAM, dans l’IDE Arduino, sélectionnez la carte XIAO_ESP32S3. Ensuite, la taille de la mémoire Flash : « 8MB (64 Mb) », le schéma de partition : « Maximum APP (7,9MB APP, sans OTA, sans FS) », la PSRAM : « OPI PSRAM ».
Tests en vol
La suite très prochainement
Bonjour Cédric,
Merci pour cet aimable commentaire.
L’idée d’intégrer la vision du relief dans l’EFIS est très tentante, mais elle dépasse largement nos compétences en tant que constructeurs amateurs d’avions et hobbyists passionnés d’électronique et d’informatique.
Si tu souhaites participer au projet AvionicsDuino et implémenter cette fonctionnalité, ce sera avec un très grand plaisir !
Benjamin
C’est super tout ça !
Je faisais des recherches pour voir ce que je pourrais installer sur mon prochain avion expérimental.
Je travaille au niveau industriel sur de l’AHRS / INS et puisque l’on travaille aussi avec de la visualisation 3D, je me demandais si on pouvait intégrer une visu des reliefs dans ton EFIS.
Normalement le Teensy ou l’ESP32 sont capables de gérer ça !
Je vais regarder ça un peu plus en détail 🙂
Bonjour Daniel,
J’ai déjà tous les composants, je pourrai les souder dès que je recevrai les PCB. Puis les essais au banc pourront débuter. Espérons qu’ils seront satisfaisants. Si c’est le cas, je pourrai alors monter le prototype dans l’avion pour des essais au sol, puis en vol. Tout cela va prendre encore un peu de temps. Avant d’envisager des commandes de groupe, il faut s’assurer que cela fonctionne. S’il n’y a que des points de détails à régler ou à améliorer, je partagerai alors bien volontiers un jeu de PCB avec vous. Je suis prudent, je préfère qu’on parte sur une base saine qui pourra alors certainement être améliorée avec votre aide. Je suis d’autant plus prudent que je n’ai bien sûr pas encore pu tester le logiciel… avec un PCB que je n’ai pas encore ! Dans l’article ci-dessus, la vidéo 1 (avec le beau coucher du soleil) est très encourageante, mais elle a été réalisée avec un pré-prototype beaucoup plus simple.
Benjamin
Ah, d’accord, je ne savais pas que vous utilisiez le convertisseur MeanWell. Dans ce cas, je ne pense pas que vous aurez de problèmes, car même les feux de balisage ou stroboscopiques produisent des pics de tension supérieurs à ceux de l’alimentation elle-même…
Si nous procédons à un achat groupé, comptez sur moi pour tester un exemplaire ; sinon, j’en commanderai un moi-même avec les fichiers et je vous ferai part de mes commentaires.
En attendant confirmation, je le fixerai sur les instruments. Une fois testé, je l’intégrerai au panneau imprimé en 3D.
Cordialement
Bonjour Daniel,
Merci pour vos encouragements. Après quelques ultimes modifications, les deux PCB sont partis hier pour la fabrication.
Concernant le module d’alimentation, bien sûr, il doit être blindé. Pour des raisons de facilité et d’encombrement, un convertisseur DC-DC Meanwell SKE15A-05 a été choisi pour le RDAM. Ces modules sont encapsulés dans un « six-sided shield metal case » et sont en conformité EMI avec le standard EN 55022/32 Class A qui est utilisé pour les équipements de communication. J’espère que cela suffira à éviter l’émission d’interférences. Les PCB du RDAM sont eux-mêmes conçus pour leur conférer la meilleure immunité EMI possible. Si malheureusement ce module Mean Well ne donnait pas satisfaction, le RDAM est prévu pour pouvoir être alimenté directement par une source de 5 volts externe. Par exemple, la source décrite ici. Cette alimentation donne actuellement toute satisfaction, mais elle est sensiblement plus volumineuse que le module Mean Well.
Avec les éléments AvionicsDuino actuellement en vol, nous n’avons jamais eu de problèmes d’interférences. Le câblage de l’avion est lui-même conçu avec le plus grand soin pour éviter les parasites et autres « ground loops ».
Je vais recevoir dans quelques jours les cinq ensembles de deux PCB que j’ai commandés hier. Si après les essais au banc et en vol, ce nouvel EFIS EMS donne satisfaction, je pourrai publier sur le site AvionicsDuino les schémas, les fichiers Gerber, la BOM et les résultats des essais en vol. Il me restera deux ensembles de PCB disponibles, car j’en garderai un pour moi et j’en ai réservé un pour un ami. S’il y a des volontaires pour se lancer dans cette aventure, on pourrait effectivement regrouper les commandes. Mais avant toute chose, il faut prouver que ça fonctionne bien en vol !
Benjamin
Bonjour, ça fait plaisir de voir à quel point le projet a l’air bon…
Si vous avez besoin d’aide pour faire avancer la partie électronique qui reste, écrivez-moi sans problème et je serai ravie.
Concernant le module d’alimentation, il est conseillé de le mettre dans un boitier métallique relié à la masse générale pour éviter les interférences et les antennes, avec lesquelles je ne sais pas si vous avez eu des problèmes dans les versions précédentes.
Envisagez-vous de passer une commande commune de matériel ou de plaques une fois celle-ci terminée ? Ce ne serait pas une mauvaise option et vous pourriez obtenir des avantages pour compenser vos efforts.
Sans plus tarder, merci beaucoup pour vos efforts et nous continuerons à prêter attention à l’évolution…
Bonjour Stéphane,
Le projet EFIS EMS ESP32 avance bien. Comme je l’avais écrit en réponse à Daniel le 8 novembre dernier, l’écran 7″ est au point.
Après avoir (longuement…) testé au banc les différents composants et sous-circuits, je viens de terminer la conception du module de gestion des capteurs (ou RDAM, pour Remote Data Acquisition Module). Ci-dessous les deux PCB en 3D dans Kicad. Pour le PCB principal tous les composants et les connecteurs sont sur une face, et les capteurs de pression (pour l’EFIS et la pression d’admission) sur l’autre. La petite carte Seeed Studio XIAO ESP32 S3 qui anime l’ensemble va avoir beaucoup de travail… Le deuxième PCB est juste le module d’alimentation qui fournit les 5 volts nécessaires à partir de la tension de bord de l’avion (14 volts).
Ce RDAM reçoit sur son connecteur Sub-D 25 les infos de tous les capteurs du moteur : CHT x 2, EGT x 4, température liquide refroidissement, pression d’huile (capteur résistif VDO ou Keller), AFR, intensités x 2. L’entrée AFR ou une des entrées EGT peut aussi être utilisée pour y connecter un capteur de pression d’essence de type UMA.
Le connecteur Sub-D 9 est dédié au CAN Bus, on peut aussi y connecter en option une sonde de température intérieure. On a prévu une communication par ESP-NOW entre le RDAM et l’écran, mais la connexion au CAN bus pourrait facilement remplacer la solution sans fil. Cette connexion au CAN bus est de toute façon nécessaire pour transmettre tous les paramètres de vol et moteur en temps réel à l’enregistreur de vol.
Il y a quatre capteurs de pression sur le PCB principal : deux capteurs de pression absolue (l’un pour la pression d’admission, l’autre pour la pression statique), et deux capteurs de pression différentielle (l’un pour la sonde de Pitot, l’autre pour une sonde AOA).
Le micro-EMS Teensy décrit sur une autre page du site reste tout à fait d’actualité, il s’occupe de la gestion du carburant (jauge et débit), du compte tours, de la tension de la batterie et de « l’idiot lamp ». Il est lui aussi relié au CAN bus.
Les deux PCB vont partir en fabrication la semaine prochaine, et lorsque je les aurai reçus, il y aura encore du travail pour y souder les composants et tester l’ensemble. L’écriture du programme sera l’étape la plus simple.
J’espérais pouvoir présenter ce nouveau système avant la fin de cette année, mais comme toujours dans le monde exigeant de la construction amateur (d’avions ou autres), on arrive rarement à tenir les délais qu’on aurait souhaités ! Ce sera donc pour le début de l’année 2026.
Benjamin
Bonjour Benjamin.
J’espère que ce message te trouveras en forme. Je venais voir si le projet ESP32 avait avancé avant les fêtes de fin d’année. Le temps va être précieux avec la fin d’année qui arrive.
A tous qui me lisez, je vous souhaite le meilleur.
Je suis ravi que cela vous ait été utile.
Si vous avez besoin de quoi que ce soit d’autre, n’hésitez pas à me le faire savoir ici. Je continuerai à suivre l’évolution du projet, même si cela devient difficile pour moi. Si je peux vous aider, ce sera avec plaisir. Cordialement.
Bonjour Daniel,
J’ai refait plusieurs essais avec mon code originel, y compris en y ajoutant #include « esp_wifi.h » puis esp_wifi_stop() dans le setup, sans que cela ne change quoi que ce soit. J’observe toujours un délai d’environ 60µs entre deux transactions. En diminuant la fréquence du bus I2C, ce même délai persiste et s’allonge. En diminuant la fréquence du MCU de 240 à 160 MHz, c’est pareil, le délai persiste et s’allonge. Je n’en connais pas la raison, je n’ai pas trouvé de cas similaire dans aucun forum.
Le programme en mode Bit Bang de votre ami fonctionne bien, il permet de faire disparaître les délais entre transactions, comme on peut le voir sur les copies d’écran d’analyseur logique ici et là. J’ai apporté quelques modifications mineures à ce programme, voir le fichier ZIP ci-joint. J’ai supprimé les lignes d’inclusion du début, car au moins avec l’IDE Arduino, elles n’étaient pas nécessaires. J’ai amélioré certains temps de commutation des GPIO, et modifié la fonction delay_half_cycle() pour obtenir une fréquence de bus d’environ 1MHz, à peu près stable.
Je n’avais pas pensé à cette solution élégante de piloter des périphériques I2C en contrôlant directement les GPIO, et en s’affranchissant complètement du hardware I2C. Il reste à tester la fiabilité du bit banging avec plusieurs esclaves I2C sur le même bus, la compatibilité avec le protocole WiFi ESP-NOW, et à s’assurer qu’il restera assez de temps de processeur pour les autres calculs, tout en assurant une fréquence d’échantillonnage adaptée aux différents capteurs et aux filtres numériques.
Un grand merci pour votre précieuse aide.
Benjamin
Merci Daniel pour la fin du programme. Cela semble très intéressant.
Je regarderai tout cela dès mon retour.
Pour envoyer un programme entier, le plus simple consiste à en faire une archive ZIP qui peut être envoyée en pièce jointe avec un commentaire.
Benjamin
// Lit un octet sur le bus I2C et envoie un ACK/NACK selon le paramètre
IRAM_ATTR uint8_t i2c_read_byte(bool ack) {
uint8_t data = 0;
gpio_set_direction(SDA_PIN, GPIO_MODE_INPUT);
for (int i = 0; i < 8; i++) {
delay_half_cycle();
gpio_set_level(SCL_PIN, 1);
data = (data << 1) | gpio_get_level(SDA_PIN);
delay_half_cycle();
gpio_set_level(SCL_PIN, 0);
}
// Envoi du bit d’ACK ou de NACK
gpio_set_direction(SDA_PIN, GPIO_MODE_OUTPUT);
gpio_set_level(SDA_PIN, ack ? 0 : 1);
delay_half_cycle();
gpio_set_level(SCL_PIN, 1);
delay_half_cycle();
gpio_set_level(SCL_PIN, 0);
gpio_set_level(SDA_PIN, 1);
return data;
}
// Lecture d’un canal du convertisseur ADS7828
IRAM_ATTR uint16_t ads7828_read(uint8_t channel) {
uint8_t cmd = 0b10000000 | ((channel & 0x07) << 4) | 0b1100;
uint8_t msb, lsb;
i2c_start();
i2c_write_byte((ADS7828_ADDR << 1) | 0); // Adresse + écriture
i2c_write_byte(cmd); // Commande du canal
i2c_start();
i2c_write_byte((ADS7828_ADDR << 1) | 1); // Adresse + lecture
msb = i2c_read_byte(true); // Lecture du MSB avec ACK
lsb = i2c_read_byte(false); // Lecture du LSB avec NACK
i2c_stop();
return ((uint16_t)msb << 8) | lsb;
}
void setup() {
Serial.begin(115200);
esp_wifi_stop(); // Désactive le Wi-Fi pour éviter toute interruption parasite
// Configuration des broches I2C en sortie
gpio_set_direction(SDA_PIN, GPIO_MODE_OUTPUT);
gpio_set_direction(SCL_PIN, GPIO_MODE_OUTPUT);
gpio_set_level(SDA_PIN, 1);
gpio_set_level(SCL_PIN, 1);
// Broches de diagnostic pour oscilloscope
pinMode(7, OUTPUT);
pinMode(8, OUTPUT);
Serial.println("Test I2C bit-bang ADS7828 (IRAM)");
}
void loop() {
// Clignotement de la broche 7 à chaque itération
digitalWrite(7, !digitalRead(7));
// Lecture des 8 canaux de l’ADS7828
for (uint8_t i = 0; i < 8; i++) {
digitalWrite(8, HIGH); // Indique la lecture en cours
uint16_t val = ads7828_read(i); // Lecture du canal i
digitalWrite(8, LOW); // Fin de la lecture
(void)val; // Valeur ignorée, juste pour test }
}
Merci Daniel pour ces suggestions qui me donnent des idées.
Il va falloir que je fasse quelques essais, mais je ne serai pas chez moi avant quelques jours.
Votre message a malheureusement été tronqué, il manque à la fin la fonction de lecture d’un octet sur le bus et d’envoi d’un ACK/NACK
Benjamin
D’accord, désolé. Je pense que lorsque j’ai utilisé Google Traduction du français vers l’espagnol, la traduction n’était pas tout à fait exacte, et c’est pourquoi j’ai été confus ou mal compris. Toutes mes excuses.
Maintenant que j’ai vu votre explication, je comprends ce que vous voulez dire, et il semble très étrange que la suppression de l’option que j’ai mentionnée dans vos tests provoque ces pauses.
Je viens d’en parler à un ami qui s’y connaît en la matière, et il regardait attentivement jusqu’à ce que je lui dise que c’était pour monter dans l’avion, et il m’a regardé d’un air de dire » tu es fou 😉 »
Je lui ai montré ta réponse et il m’a donné des explications très techniques, mais je suis complètement perdue à ce niveau-là, haha…
Nous avons examiné la fonction « i2c master transmit receive() », et elle provoque un blocage car elle interroge d’abord le CAN via la ligne de commande (cmd), attend l’accusé de réception (ACK), puis lit les octets de réponse dans le tampon. Pendant cette attente, le pilote cède le contrôle au système d’exploitation temps réel (RTOS), qui peut alors effectuer des tâches telles que l’accès à la mémoire flash, à la PSRAM ou à d’autres ressources. On m’a conseillé d’essayer d’exécuter le même code avec le format suivant : `esp_wifi_stop();`
/ ADS7828 read
`esp_wifi_start();`
afin de déterminer si le problème vient de là, ou d’essayer d’exécuter les fonctions séparément : `i2c_master_transmit` + `i2c_master_receive` avec le délai le plus court possible entre elles pour déterminer si le problème se situe au niveau du CAN ou de la couche HAL. On m’a indiqué que pour réduire le temps d’attente, il faudrait utiliser du code bas niveau, mais je ne sais pas comment faire sans utiliser de bibliothèques. Il me dit aussi que si vous l’avez déjà utilisé auparavant, pourquoi ne pas conserver le flux de lecture des données sur Teensy, qui est plus stable et ne possède pas de convertisseurs analogique-numérique externes, et utiliser uniquement l’ESP pour la partie graphique ?
Vous pouvez essayer ceci pour voir si l’accès direct via I2C sans HAL ni RTOS réduit le problème.
#include « soc/i2c_reg.h »
#include « soc/i2c_struct.h »
#include « rom/ets_sys.h »
#include « esp_rom_gpio.h »
#include « driver/gpio.h »
#include « esp_wifi.h »
#define SDA_PIN 5
#define SCL_PIN 6
#define I2C_FREQ_HZ 400000
#define ADS7828_ADDR 0x48
// Petite temporisation pour ajuster la période du signal I2C
static inline void delay_half_cycle() {
// Ajuster ce nombre de boucles selon la fréquence désirée (ici pour ~400 kHz)
for (volatile int i = 0; i < 40; i++) {}
}
// Génère une condition START sur le bus I2C (mode bit-bang)
IRAM_ATTR void i2c_start() {
gpio_set_level(SDA_PIN, 1);
gpio_set_level(SCL_PIN, 1);
delay_half_cycle();
gpio_set_level(SDA_PIN, 0);
delay_half_cycle();
gpio_set_level(SCL_PIN, 0);
}
// Génère une condition STOP sur le bus I2C
IRAM_ATTR void i2c_stop() {
gpio_set_level(SDA_PIN, 0);
gpio_set_level(SCL_PIN, 1);
delay_half_cycle();
gpio_set_level(SDA_PIN, 1);
delay_half_cycle();
}
// Envoie un octet sur le bus I2C et lit l’accusé de réception (ACK)
IRAM_ATTR bool i2c_write_byte(uint8_t data) {
for (int i = 0; i < 8; i++) {
gpio_set_level(SDA_PIN, (data & 0x80) != 0);
delay_half_cycle();
gpio_set_level(SCL_PIN, 1);
delay_half_cycle();
gpio_set_level(SCL_PIN, 0);
data <<= 1;
}
// Lecture du bit d’ACK
gpio_set_direction(SDA_PIN, GPIO_MODE_INPUT);
delay_half_cycle();
gpio_set_level(SCL_PIN, 1);
bool ack = (gpio_get_level(SDA_PIN) == 0);
delay_half_cycle();
gpio_set_level(SCL_PIN, 0);
gpio_set_direction(SDA_PIN, GPIO_MODE_OUTPUT);
return ack;
}
// Lit un octet sur le bus I2C et envoie un ACK/NACK selon le paramètre
IRAM_ATT_
Bonjour Daniel,
Je me suis mal exprimé. Les latences entre deux transactions sont observées en toutes circonstances, y compris lorsque l’ESP32-S3 ne fait rien d’autre qu’interroger l’ADS7828. C’est à dire avec un sketch minimaliste n’utilisant que la bibliothèque I2C Espressif (#include « driver/i2c_master.h »), sans Wi-Fi, sans CAN Bus, sans aucune tâche autre que celle qui exécute la fonction loop() de l’IDE Arduino sur le core_1. Laquelle loop() « tourne » en continu, sans delay() ni autre vTaskDelayUntil() qui pourrait limiter la fréquence d’itération de loop().
Il ne s’agit donc pas d’un problème de préemption par une autre tâche de priorité supérieure, Wi-Fi, CAN (twai) ou autre. Ces latences ne sont pas une conséquence de la vitesse du bus I2C. On observe la même chose, que cette fréquence soit de 100kHz, 400kHz ou 1000kHz, elles sont juste proportionnellement plus longues quand on diminue la fréquence du bus. Des latences inter-transactionnelles de 58µs (voir la copie d’écran de l’analyseur logique de mon précédent message) sont donc observées pour une fréquence de bus de 1000kHz. Cette fréquence est possible grâce à des résistances pull up de 1k, car avec des résistances de valeur plus élevée, et à cette fréquence, le temps de montée du signal SCL se dégrade.
J’utilise la bibliothèque I2C d’Espressif, car avec la bibliothèque Wire, ce problème de latences est encore pire : non seulement les latences inter-transactionnelles sont plus longues, mais il apparait également une latence à peu près identique entre les séquences write et read, et la bande passante du bus I2C s’effondre.
Avec une carte Teensy 4.0, avec le même convertisseur analogique-numérique ADS7828, et avec le même sketch, et bien sûr l’utilisation de la bibliothèque Wire, il n’y a aucune latence (ce qui prouve que le problème ne vient pas de l’ADS7828), et cela permet une fréquence d’échantillonnage environ 4 fois plus élevée qu’avec une carte ESP32-S3. J’utilise souvent une XIAO ESP32-S3, mais c’est la même chose avec n’importe quelle carte ESP32-S3.
Cela ne sera a priori pas rédhibitoire, mais on aurait préféré disposer de toute la bande passante du bus I2C, sans ces temps morts.
Pourrait-il s’agir d’un problème de configuration du bus I2C ? Si vous souhaitez vérifier cette configuration et faire des essais, mon sketch minimaliste de test est téléchargeable ici. Je n’ai pas fait d’essai avec un autre « esclave » que l’ADS7828.
J’utilise l’IDE Arduino 2.3.6, avec le gestionnaire de cartes Espressif 3.2.1 (la version la plus récente est 3.3.3, je n’ai pas encore fait la mise à jour).
Benjamin
Salut Benjamin, je n’ai jamais travaillé avec toutes ces technologies simultanément sur un seul ESP32, mais je pense que le problème vient de la façon dont l’ESP32 gère le Wi-Fi. Il utilise ESPNow comme couche supplémentaire par-dessus le Wi-Fi standard et gère tout au niveau du cœur 1. Lorsqu’ESPNow doit gérer les communications pour d’autres fonctions, comme les interruptions, il lui faut entre 40 et 80 microsecondes pour les résoudre, et je pense que c’est ce qui provoque ces interruptions dans le flux de données. Je crois que c’est là que le problème se situe.
La solution pour conserver espNow consiste à déplacer toutes les données CanBus vers le cœur 1, en veillant à ce que l’ISR CanBus s’exécute sur le cœur 1 et en conservant wifi-espNow sur le cœur 0. Vous pouvez également conserver le CanBus sur un Teensy, ce qui n’est pas un problème majeur si vous investissez un peu plus pour cette qualité et économisez sur les CAN.
Bonjour Daniel,
Merci pour votre intérêt pour le site AvionicsDuino.
Le projet EFIS-EMS-ESP32 avance. Lentement, mais surement.
Le nouveau module écran est au point. La dalle Newhaven Newhaven NHD-7.0-800480AF-ASXP est parfaite, le PCB qui la contrôle fonctionne comme attendu, animé par un SoC ESP32-S3 Wroom1 N16R80, le mini clavier à 6 touches remplace très avantageusement la dalle tactile des premiers essais. Voir ci-dessous la photo de ce nouveau module écran, dans son boîtier ABS.
Le développement du module de gestion des capteurs EMS et EFIS est en bonne voie. Après avoir hésité à revenir au monde Teensy pour l’animer, on continue finalement quand même le développement avec l’ESP32, pour bénéficier d’une connexion ESP-NOW avec le module écran. Comme le convertisseur analogique numérique des ESP32 est de (très) médiocre qualité, on a choisi des ADC externes ADS7828 qu’il a fallu tester de façon extensive. On a repensé tous les étages d’entrée par rapport à la version précédente de l’EMS, pour encore plus de précision et de fiabilité. On a rajouté des entrées, pour pouvoir connecter 4 EGT, et pour le capteur de pression d’huile Keller des moteurs Rotax récents. Le PCB de ce module EMS-EFIS est désormais au point sur le papier, les simulations LTspice sont OK, il reste la fabrication du PCB lui-même et bien sûr les essais à faire.
Il persiste à ce stade quelques interrogations. La première concerne la lenteur du bus I2C des ESP32. Il y a des latences importantes entre les transactions, qui diminuent beaucoup la bande passante, par rapport aux cartes Teensy 4.x, à fréquence de bus égale. Et les deux ADC ADS7828 sont sur bus I2C, tout comme les trois capteurs de pression (pression statique, pression Pitot et pression d’admission). La seconde interrogation concerne l’échauffement assez important des ESP32 constaté lorsque l’ESP-NOW est sollicité en continu. Pour cette dernière raison, le module écran et celui des capteurs EMS et EFIS sont équipés d’un transceiver CAN qui permettra, si l’ESP-NOW ne tient pas ses promesses, de recourir au CAN bus.
Donc encore un peu de travail de mise au point en perspective.
Un point encourageant : lors des essais en vol de ces derniers mois, tous réalisés avec des boîtiers imprimés 3D en ABS, donc sans aucun blindage, aucune interférence n’a été constatée avec l’installation radioélectrique de bord. Y compris lors de l’utilisation de la Wi-Fi pour le protocole ESP-NOW.
Merci pour votre proposition d’aide. Elle pourra certainement être très utile pour des tests au banc ou en vol. Ou par exemple pour trouver une solution à ces latences bien gênantes entre transactions I2C, voir ci-dessous : pourquoi ces 58µs incompressibles entre deux transactions, alors même que l’ESP32 n’a strictement rien d’autre à faire que d’interroger un ADS7828 en permanence ? Lorsque le même programme tourne sur une carte Teensy 4.x, les transactions s’enchaînent sans aucune latence
Benjamin
Bonjour, comment avance le développement ?
J’ai hâte de mettre en service cette nouvelle version d’EFIS-EMS. Si vous avez besoin d’aide pour le développement, la configuration ou les tests, n’hésitez pas à me le faire savoir et nous pourrons commencer. Je suis en Espagne, mais je peux vous aider pour tout ce dont vous avez besoin. Cordialement, et bravo pour votre travail.
Bonjour Stéphane,
L’architecture actuelle est en fait très largement conservée dans ce nouvel EFIS-EMS.
Les mêmes infos qu’actuellement circuleront toujours sur le CAN bus.
A terme, il y aura un nouveau PCB EMS, et un nouveau PCB EFIS, beaucoup plus compacts qu’actuellement, tous deux connectés au CAN bus. Le PCB EFIS sera en outre chargé de la communication via ESP-NOW avec l’écran 7″ unique. Ce nouvel ensemble sera donc animé par trois SoC ESP32S3 (PCB-EMS, PCB-EFIS, et écran). J’avais envisagé de conserver une carte Teensy sur le PCB-EMS, mais finalement, après des essais concluants avec des ADC externes ADS7828, ce sera donc une carte ESP32, nettement plus économique. Cela ne complique pas beaucoup le circuit, et ces ADC performant ne coûtent pas grand-chose.
Benjamin
Bonsoir Benjamin.
J’espère que ce message te trouvera en bonne santé.
Je pense que le boîtier avec les boutons sera bien plus pratique. Ne peut-on conserver l’architecture que l’on a aujourd’hui EMS, EFIS etc…. Et procéder à un affichage grâce à une carte ESP 32 qui reçoit les infos par Can bus ?
Bonjour Stéphane,
Comme l’écran tactile Elecrow Crowpanel du prototype actuellement en vol ne donne pas entière satisfaction (trop de reflets, luminosité insuffisante), je pense le remplacer par un Newhaven NHD-7.0-800480AF-ASXP, avec une dalle mate IPS non tactile et une luminosité de 1000 cd/m². Un prototype fonctionne déjà au banc avec cet écran, dont la qualité est effectivement nettement meilleure. L’étude du PCB est faite, il est basé sur un SoC Espressif ESP32-S3, il est équipé de 6 boutons poussoirs qui, je l’espère, remplaceront avantageusement le tactile. Voici un aperçu de l’aspect du boîtier qui sera imprimé en 3D en ABS, avec son mini clavier de 6 boutons. Le PCB est en commande chez Aisler. Il y a donc encore du travail et des essais en vol avant de pouvoir publier une version plus aboutie, et bien sûr testée en vol.
Benjamin
Bonsoir Benjamin.
Nous avions abordés le sujet du tactile en vol qui a mon gout reste compliqué en condition un peu turbulentes et tu as expérimenté en vol…il existe des écrans avec l’option de rangé de touches déportées (me semble t il)
Bonsoir Stéphane,
Merci pour cet aimable commentaire.
Il y a encore un peu de travail à faire sur l’EFIS-EMS lui-même, et sur le tableau de bord de l’avion, puis d’autres essais en vol à réaliser, avant de pouvoir publier une version plus « finie » de ce projet.
Benjamin
Bonsoir Benjamin. Tout d’abord j’espere que la santé est au rendez vous. Félicitations !!! beau, très beau travail…. hâte de voir le reste de la publication….