(EFIS-EMS ESP32 : Dernière mise à jour par Benjamin le 7 juillet 2025)
Il s’agit d’une version entièrement nouvelle, qui rassemble sur un même écran tactile de 7 pouces, un EFIS et un EMS. La version présentée sur cette page est préliminaire, destinée à valider un certain nombre d’options et d’innovations. Elle va faire l’objets d’évolutions architecturales notables dans les mois à venir. Cependant, l’aspect visuel de l’écran (voir les photos et vidéo plus bas) est identique à ce qu’il sera à terme, il ne devrait évoluer qu’à la marge.
Cet EFIS-EMS est destiné à devenir autonome, mais pour l’instant, il coexiste dans l’avion qui sert aux tests avec l’EFIS et l’EMS déjà présentés sur le site AvionicsDuino. Il se base sur les mêmes données, transmises par le bus CAN, sauf en ce qui concerne les capteurs de pression de la partie EFIS. Cette page va donc également évoluer dans un avenir proche.
Le but principal du développement de ce nouvel ensemble était d’améliorer la qualité des affichages, pour leur donner un aspect proche de celui des instruments professionnels. En effet, les affichages de l’EFIS et de l’EMS précédents, gérés chacun par une carte Teensy 4.1 et un contrôleur graphique RA8875, étaient très simples, voire simplistes, et parfois peu lisibles en raison de la petite taille des caractères, surtout pour l’EFIS.
On a choisi pour ce nouveau système d’utiliser un écran dont le contrôleur est un « système sur une puce » (SoC) ESP32-S3 intégré à l’écran. Cet écran a par ailleurs des capacités tactiles qui permettent, pour les menus, de se passer de bouton ou d’encodeur rotatif. Les capacités de communication sans fil de l’ESP32 ouvrent par ailleurs de nouvelles possibilités très intéressantes.
Présentation générale de l’EFIS-EMS ESP32
Dans cette version préliminaire, l’EFIS-EMS comporte deux modules. Le premier module est l’écran lui-même, dont la seule connexion électrique est constituée d’un fil de masse et d’un fil pour son alimentation positive. Le second module est également animé par une carte basée sur une puce ESP32-S3. Il pilote des capteurs de pression barométrique et différentiel (les mêmes capteurs AMS5915 que l’EFIS précédent) et un transceiver CAN Bus. Les deux modules communiquent entre eux en Wi-Fi, via le protocole Espressif ESP-NOW. Le module des capteurs de pression communique via le CAN bus avec l’AHRS, le magnétomètre distant, l’EMS, et le micro-EMS.
Architecture générale de l’EFIS-EMS ESP32
Dans cette version préliminaire, la partie EMS de l’EFIS-EMS utilise l’EMS et le micro-EMS existants comme source de données. La partie EFIS utilise quant à elle ses propres capteurs de pression, ainsi que l’AHRS et le magnétomètre. Le lecteur pourra si nécessaire se reporter aux pages consacrées à ces systèmes qui ne sont donc pas détaillés ci-dessous. La figure 1 détaille cette architecture temporaire.
Le module écran utilise une dalle TFT-LCD de 7 pouces, de qualité IPS pour permettre une bonne visibilité sous des angles très larges. La définition est de 800 x 480 pixels. Cette dalle comporte une couche tactile capacitive qui permet de naviguer dans les menus. La luminosité est de 400 cd/m². La surface est brillante comme celle de quasiment tous les écrans tactiles capacitifs.
Ce module écran communique avec le module des capteurs de pression grâce au protocole ESP-NOW d’Espressif qui utilise la technologie Wi-Fi.
Le module des capteurs de pression est connecté par ses deux ports pneumatiques aux circuits de pressions statique et totale de l’avion. Il est également connecté au bus CAN par l’intermédiaire duquel il reçoit les informations en provenance de l’EMS, du Micro-EMS, de l’AHRS et du magnétomètre.
Cette architecture modulaire correspond à la philosophie générale IMA (Integrated Modular Avionics) du projet AvionicsDuino. Les différents modules traitent chacun une fonction particulière et communiquent les uns avec les autres grâce au CAN bus.
Dans la version finale et autonome de l’EFIS-EMS ESP32, un module EMS sans écran viendra remplacer l’EMS actuel. L’architecture générale deviendra alors celle de la figure 2 où les flèches vertes symbolisent le bus CAN.
Dans cette version future, le logiciel du module EMS sera une version allégée du logiciel de l’actuel EMS, toutes les fonctions d’affichage devenant inutiles. Le circuit imprimé de ce module sera lui aussi une version simplifiée, sans fonction d’affichage, du circuit imprimé de l’EMS actuel. Les logiciels et circuits imprimés des autres modules resteront inchangés. On a ici un bel exemple de l’intérêt de cette architecture modulaire intégrée. L’ensemble est ainsi très facile à entretenir et à faire évoluer.
Essais en vol
Un premier essai en vol a validé ce nouveau design d’instrument, combinant un EFIS et un EMS sur un même écran de 7 pouces. La photo de la figure 3 et la vidéo 1 ci-dessous ont été prises durant ce vol. On y voit à droite l’EFIS-EMS ESP32 sur son écran unique, et à gauche les écrans de l’EFIS et de l’EMS Teensy. Tout en bas et à droite, sous le tableau de bord, on aperçoit le module des capteurs de pression, de couleur verte, et les connexions bleues de ce module aux circuits des pressions statique et totale. Il s’agit bien sûr d’un montage provisoire.
Les données affichées par les deux systèmes sont strictement identiques, y compris les données issues des deux jeux de capteurs de pression des EFIS. Ces données EFIS avaient fait l’objet d’une validation extensive, d’une part par comparaison avec l’EFIS Dynon D10 de référence équipant cet avion (voir la page EFIS), et d’autre part grâce à une étude expérimentale des capteurs de pression utilisés.
Ce premier vol a été réalisé dans des conditions idéales, au coucher du soleil, la photo et la vidéo ont été faites avec une lumière rasante, de faible intensité, venant de l’avant, sans aucun reflet sur les écrans mats de l’EFIS et de l’EMS Teensy, et avec de faibles reflets tout à fait tolérables sur l’écran brillant de l’EFIS-EMS ESP32.
Lors de vols ultérieurs en milieu de journée, avec la lumière du soleil directement sur l’écran, les 400 cd/m² se sont avérés insuffisants. De plus, cet écran tactile brillant est sujet à de forts reflets, contrairement aux écrans mats non tactiles. Les filtres anti-reflets faisant perdre de la luminosité, ce n’est sans doute pas une solution idéale. De plus, ces filtres contribuent à faire perdre un peu de netteté à l’image.
Il va donc probablement falloir envisager un autre écran, avec une luminosité d’au moins 1000 cd/m², comme les écran Riverdi de l’EFIS et de l’EMS qui restent parfaitement lisibles même sous la lumière directe du soleil. Un écran mat anti-reflet (donc non tactile) serait sans doute également préférable. Dans ce cas, une rangée de six boutons poussoirs sous ou sur le côté de l’écran pourrait très simplement remplacer le tactile, sans augmenter sensiblement la place occupée sur le tableau de bord. D’autant que le tactile (vidéo 2), s’il semble au premier abord très séduisant, peut parfois s’avérer peu commode à utiliser en conditions turbulentes.
Les fichiers Kicad et Gerber du circuit imprimé du module des capteurs de pression, ainsi que les logiciels de ce module et du module écran seront très prochainement publiés ici. Il faudra attendre un peu plus longtemps pour la publication du circuit imprimé et du logiciel du module EMS.
Pour ce dernier, après avoir envisagé de le construire autour d’une carte ESP32, on va en fait utiliser une carte Teensy 4.0. En effet, les cartes ESP32 sont malheureusement connues pour la médiocrité de leurs ADC (Analog to Digital Converter, ou convertisseur analogique numérique), ce qui imposerait l’utilisation d’au moins deux ADC externes multicanaux. Ce qui compliquerait beaucoup les circuits et annulerait totalement l’économie réalisée en utilisant une carte ESP32 par rapport à une carte Teensy 4.0 comportant 13 entrées analogiques, voire même par rapport à une Teensy 4.1, un peu plus chère, qui en comporte 17.
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….