(EFIS : Dernière mise à jour par Benjamin le 24 mars 2024)
Les systèmes d’information électroniques de vol (EFIS, ou Electronic Flight Instrument System) présentent sur un écran unique les données indispensables au vol : l’horizon artificiel, la bille, l’indicateur de virage, l’anémomètre, l’altimètre, le variomètre et le compas. Avant la généralisation des EFIS et du numérique sur les tableaux de bord de nos aéronefs, il existait un instrument dédié à chacune de ces fonctions, généralement analogique ou électromécanique.
Un EFIS étant essentiellement un calculateur associé à de nombreux capteurs et à un écran, la liste des autres fonctions qui peuvent être implémentées n’est pas limitative : affichage de l’altitude densité, de la vitesse propre, de l’angle d’attaque, de la température extérieure, de la direction et de la vitesse du vent, G-mètre, voltmètre, chronomètre, pilote automatique…etc.
Sur cette page, nous allons décrire l’unité principale de l’EFIS AvionicsDuino. Le lecteur pourra se reporter aux pages AHRS et Compas digital pour la description de ces modules qui font partie intégrante de l’EFIS.
Présentation générale de l’EFIS AvionicsDuino
Le rôle essentiel de l’unité principale de l’EFIS est de gérer l’écran (affichage graphique de l’horizon artificiel et de toutes les données textuelles) et de faire les très nombreux calculs indispensables pour afficher les informations nécessaires au pilotage, en partant des données brutes des capteurs.
Par exemple pour calculer la vitesse de l’avion à partir des mesures de la pression statique et de la pression totale à l’extrémité de la sonde de Pitot. Ou calculer la position de la bille en fonction des accélérations latérales. Cette unité comporte en elle-même un nombre très limité de capteurs, à savoir les deux capteurs de pression (absolue pour la pression statique, et différentielle pour le tube de Pitot), et le capteur de température intérieure.
Les autres capteurs sont situés dans les deux modules (AHRS et Compas digital) cités dans l’introduction : GNSS, gyromètres, accéléromètres, magnétomètres, capteurs de température extérieure et d’humidité. Beaucoup de calculs sont également confiés à ces modules.
Architecture de l’EFIS
Elle est schématisée sur la figure 1. L’unité principale dont il est question ici est représentée dans le rectangle jaune, l’AHRS dans le rose, et le module magnétomètre, capteur de température extérieure et humidimètre dans le vert pâle.
L’unité principale comporte une alimentation 5 volts (décrite par ailleurs). Elle fournit la tension requise par les deux autres modules (flèches rouges), cette alimentation emprunte une des deux paires torsadées du câble utilisé pour le CAN Bus. Les modules communiquent en effet tous entre eux par le CAN bus (flèches vertes). Dans des versions logicielles antérieures, l’AHRS communiquait avec l’unité principale de l’EFIS par une voie série UART, représentée sur la figure 1 par une flèche bleue pointillée à double sens. Cette communication série est devenue obsolète, mais les versions logicielles qui l’exploitaient restent téléchargeables sur GitHub, cependant elles n’évolueront plus et ne seront plus mises à jour.
Composants principaux
Le cœur de l’unité principale est une carte Teensy 4.1, équipée d’un microcontrôleur NXP i.MX RT1062 (ARM Cortex-M7 – 600 MHz, voir la page Cartes microcontrôleur).
Les autres composants sont listés ci-dessous :
- Capteur de pression différentielle : Analog Microelectronics AMS 5915 0050D, pour mesurer la pression différentielle entre la prise statique et la sonde Pitot, et calculer la vitesse. La plage de mesure de ce capteur va de 0 à 50 hPa, ce qui est adapté à la plage de vitesse du MCR Sportster (0 – 320 km/h).
- Capteur de pression absolue : Analog Microelectronics AMS 5915 1500A, pour la prise de pression statique, et le calcul de l’altitude. La plage de mesure de ce capteur va de 0 à 1500 hPa.
- Capteur de température intérieure oneWire DS18B20.
- Encodeur rotatif optique Grayhill 62SG pour la navigation dans les menus.
- Transceiver CAN Bus MCP2562EP
- Contrôleur graphique Adafruit RA8875
- Ecran LCD TFT IPS 4.3″ 480 x 272 1000 cd/m² Riverdi RVT43HLTFWN00
Le circuit imprimé
Les figures 2 et 3 sont des vues 3D du circuit imprimé dans sa version 2.1 actuelle (vues réalisées à l’aide de KiCad). Par rapport à la version 2.0 précédente, il y a peu de changement. L’ancien connecteur pour un GNSS a disparu. Un GNSS était effectivement incorporé antérieurement dans l’unité centrale de l’EFIS.
En effet, avant la mise au point de notre propre AHRS, nous utilisions un prototype d’AHRS fourni par la société Naveol. Ce prototype comportait bien un GNSS, mais son logiciel fermé ne nous permettait pas d’y accéder. D’où la nécessité à l’époque d’intégrer un GNSS à l’unité centrale. Le GNSS inclus dans l’AHRS AvionicsDuino fournit désormais toutes les données nécessaires à l’EFIS.
Le connecteur AHRS-UART est devenu inutile avec les dernières versions logicielles. En effet, avec ces versions, l’AHRS envoie ses données au bus CAN. Il est donc indispensable de connecter l’AHRS et l’unité centrale de l’EFIS au bus CAN.
Le circuit électrique
La figure 4 ci-dessous montre le schéma électrique de l’unité principale de l’EFIS. Le dossier KiCad correspondant est téléchargeable plus bas sur cette page.
Sur ce schéma figure une résistance de 120 ohms de terminaison du CAN bus (R2). Cette résistance était justifiée avant l’extension du bus vers l’AHRS. Désormais, c’est l’AHRS qui est le nœud le plus proche de l’extrémité du bus. La résistance R2 doit donc être supprimée de l’unité principale de l’EFIS, et il faut par contre mettre une résistance de 120 ohms à l’extrémité AHRS du bus (voir la page CAN bus).
Le connecteur J4, intitulé “TO EMS” avait été prévu pour connecter l’EMS au CAN bus en même temps que l’EFIS, dans l’hypothèse d’une configuration où l’EMS et l’EFIS partageraient le même boîtier. Même si une telle connexion commune fonctionne bien en pratique, en toute rigueur, elle n’est pas souhaitable. Le connecteur J4 n’est donc pas nécessaire.
Le boîtier
Les figures 5 et 6 montrent le boîtier combiné qui contient les unités centrales de l’EFIS et de l’EMS. Aucun plan ni aucune consigne ne sont fournis sur ce site pour la réalisation des boîtiers. En effet, une des caractéristiques de la construction amateur d’aéronefs, c’est la très grande diversité des réalisations. Les tableaux de bords sont hautement personnalisés. Un boîtier adapté à l’un ne conviendra pas à l’autre.
Nous avons choisi de fabriquer nos boîtiers en aluminium pour des raisons de protection contre les interférences électromagnétiques. Des boîtiers en impression 3D peuvent être blindés intérieurement ou extérieurement avec du ruban adhésif en cuivre ou en aluminium. Nos boîtiers sont constitués de tôles et de cornières en aluminium assemblées par des vis ou des rivets. On remarque sur la figure 6, réalisée lors de l’installation sur le tableau de bord, qu’il y a encore un connecteur pour une antenne GPS. Depuis, ce connecteur a été démonté, et son orifice a été obturé… avec du ruban adhésif en cuivre.
Résultats des essais en vol
Pour ces essais, un enregistreur de paramètres de vol a été préalablement développé, afin de pouvoir comparer rigoureusement le comportement de notre EFIS AvionicsDuino avec celui de l’EFIS commercial déjà installé dans l’avion, un Dynon D10A, utilisé comme référence.
Le premier port COM de l’enregistreur recevait le flux série en provenance de l’EFIS AvionicsDuino, le second celui de l’EFIS Dynon, et le troisième le flux NMEA d’un GNSS U-Blox NeoM9N. En vue des analyses, toutes les données bénéficiaient d’un horodatage commun.
Les vidéos ci-dessous ont été faites lors d’un des nombreux vols d’essai réalisés pour tester l’EFIS. Elles sont démonstratives des performances de l’AHRS AvionicsDuino, parfaitement adapté à la mécanique du vol des aéronefs à voilure fixe. L’horizon artificiel suit parfaitement celui de l’EFIS de référence, ainsi que l’horizon naturel, de façon stable et prolongée. La position de la bille est identique sur les deux EFIS. Les capteurs de pression sont parfaitement adaptés à cet usage, la vitesse indiquée, et l’altitude sont identiques à celles du Dynon.
Par rapport à ces deux vidéos, les dernières versions du logiciel de l’EFIS (v2.5 et v3.0) apportent quelques améliorations de la présentation des données à l’écran (fig. 7), ainsi que la prise en charge des différentes unités de vitesse (Km/h, nœuds, MPH), de pression (hPa ou In Hg) ou de température (°C ou °F). L’utilisateur peut choisir les unités qu’il souhaite en naviguant dans les menus à l’aide du codeur rotatif. Ses choix sont sauvegardés dans l’EEPROM, ainsi que de nombreux autres paramètres (déviation magnétique, correction de l’heure UTC, luminosité de l’écran, derniers QNH et QFE, G max et G min)
Comparaisons des données de l’enregistreur de vol
Sur les courbes ci-dessous, établies à partir des enregistrements, l’axe des abscisses est gradué en secondes. Ces courbes démontrent l’excellente corrélation entre les indications des deux EFIS. Elles valident nos différents choix matériels et logiciels. Il faut passer le curseur de la souris sur les courbes pour les agrandir.
Comparaisons de l’inclinaison et du variomètre
Comparaisons de l’altitude, de l’assiette et de la vitesse indiquée
Un coucou de Garéoult. Je devrais bientôt avoir le support pour les écrans.
Bonjour Benjamin. Effectivement il y a un clignotement dans la barre de vitesse. Il y a certainement moyen de supprimer ça puisque ça fonctionne avec les barres pour le vario. Non pas essayé en vol je suis toujours dans la réalisation du projet j’en suis à l’impression 3D pour les écrans, les fixation des cartes exetera…
Je sais que j’ai fait pour l’instant c’est en voiture en fixant un pito sur la calandre. des forces appliquées ne sont pas les mêmes en voiture qu’en aéronautique.
Bonne continuation.
Bonjour Stéphane,
Je pense que le gain de fluidité n’est probablement pas lié à l’implémentation du CAN bus, mais plutôt aux modifications de coefficients de filtrage que j’ai réalisées.
J’ai regardé (trop) rapidement votre version 800×480 du programme. J’ai vu le rajout d’une barre de vitesse. Elle clignote, ce qui est probablement lié à des affichages puis des effacements complets successifs de cette barre, donc beaucoup de pixels à modifier à chaque mise à jour de l’écran, chose qu’il faut essayer d’éviter. Avec ce contrôleur graphique connecté en SPI, il n’y a aucune possibilité de synchronisation verticale, donc il faut beaucoup ruser pour limiter les clignotements.
Il faut vraiment que je prenne le temps de compléter mon travail d’adaptation aux écrans 800×480. J’avais bien avancé cette tâche l’année dernière, mais sans la terminer…
Avez-vous fait des essais en vol ?
Bonne journée,
Benjamin
Bonsoir Benjamin.
Je me suis empressé d’appliquer les modifs faites sur le CanBus. C’est incroyable le gain de fluidité dans l’affichage des mouvements de L’AHRS sur l’écran 7 “. Avec l’ancienne connexion, ça arrivé par paquet ….et la c’est ……trés fluide, réactif.
Je passe dans ton coin le 5/6 mai.
Bonne soirée et merci
EFIS_7P_V3_01
Merci Stéphane pour cette précision sur les capteurs de pression. Je suis sur le point d’en commander deux nouveaux chez AMSYS pour pouvoir refaire quelques tests au banc, je vais leur préciser que certains de leurs capteurs sont entachés d’une erreur significative pour une pression nulle, et leur demander de vérifier mes capteurs avant l’envoi. Dans le cas du capteur différentiel installé dans mon MCR, il y a association d’une “zero-point error” avec une “full scale output” error. Mais en corrigeant de façon logicielle, j’obtiens au final une exactitude parfaite de la vitesse indiquée en comparaison avec l’EFIS Dynon D10A installé à côté de l’EFIS AvionicsDuino.
Et comme tout le monde n’a pas un 2ème EFIS dans son avion/ULM pour vérifier l’exactitude de la vitesse indiquée, il faut que je mette au point une procédure de vérification et d’étalonnage. Pour le capteur, une première estimation de son exactitude sur toute la plage de mesure peut être réalisée avec un simple manomètre à eau. Et ensuite, une fois l’EFIS installé dans l’avion, la meilleure façon de vérifier la chaine anémométrique consiste à utiliser un GPS et la technique des 3 routes. Mais un mauvais positionnement de la prise statique influe beaucoup sur ce dernier test.
Benjamin
Bonjour Stéphane,
Merci pour cette contribution importante.
Je suis en déplacement, je n’ai pas sous la main de quoi tester, mais ce sera fait dans quelques jours, j’y reviendrai dès que possible.
En attendant, je vais lire le sketch avec attention.
Benjamin
Bonjour Nicolas. j’ai eu également ce soucis de capteur fonctionnant mais avec une erreur qui peut etre corrigée. Cependant j’en ai réclamé un autre a Analog electronique qui m’en a renvoyé un qui fonctionne très bien et sans erreur. Très beau boitier…
Voici le fichier EFIS pour écran 7″.
J’y ai adjoint une barre de vitesse à l’image de la barre mobile de vitesse verticale. A terme je pense faire disparaitre le QFE et grossir le QNH ainsi qu’agrandir la barre de vitesse verticale pour gagner en précision avec la barre mobile.
ATTENTION cela n’a pas encore été testé en vol !!!!! Quand quelqu’un aura essayé, merci de valider ou invalider.
EFIS_Gazaile-7
Re bonjour Nicolas,
J’ai retrouvé le sketch qui m’avait servi à vérifier mon capteur différentiel, le voici.
Je n’ai pas de capteur sous la main, je n’ai pas pu vérifier que ce sketch fonctionne correctement, mais au moins il compile bien.
Benjamin
Bonjour Nicolas,
Wouah !!! Magnifique, le boîtier ! Très beau travail de modélisation 3D !
Je ne dispose pas d’une imprimante 3D, je n’ai que quelques rudiments de FreeCAD, et je suis bien habitué à la fabrication de boîtiers en alu (qui demandent aussi pas mal de travail).
Mais je pense que ceux qui ont commencé la fabrication de l’EFIS, ou qui sont tentés de le faire seront très (très) intéressés par les fichiers ! En particulier leur version définitive, après les premiers essais en vol, et une fois la face arrière finalisée.
Dans mon installation, l’AHRS est séparé du boîtier de l’EFIS, ce qui rend l’alignement avec l’avion assez simple, il suffit d’orienter correctement la platine qui le porte avec quelques vis de réglage. Il est en effet primordial que cet AHRS soit bien aligné en roulis et en tangage avec les axes de l’avion. Idem d’ailleurs pour le magnétomètre distant. C’est un impératif commun à tous les EFIS.
Ce boîtier est tellement beau que je me demande si je ne devrais pas miniaturiser un peu et adapter le PCB de l’EFIS pour qu’il rentre plus facilement, que les connecteurs (électriques et pneumatiques) soient bien orientés, et qu’on puisse prévoir un peu plus de place pour l’AHRS afin de pouvoir corriger son alignement sur les 3 axes si le tableau de bord n’est pas lui-même parfaitement aligné. Mais il faut bien sûr préalablement valider en vol le fonctionnement de l’ensemble avec le prototype actuel.
Concernant les prises D-SUB, voici un petit fichier avec quelques liens utiles.
La raison pour laquelle le contrôleur graphique est connecté directement au PCB de l’EFIS dans mon installation, c’est pour réduire le plus possible la longueur des lignes du bus SPI qui ont tendance à générer des parasites. C’est également pour réduire ces parasites qu’une résistance de 33 ohms est insérée en série dans chacune des 4 lignes SPI.
Concernant la vitesse indiquée de 13 kts à l’arrêt, c’est lié à un défaut du capteur différentiel. On peut lire sur la datasheet de ce capteur que pour la pression minimale (donc une différentielle nulle), il doit “sortir” une valeur brute de 1638 counts. Et qu’à la valeur maximale de la gamme de pression (50 mBar/Hpa), la valeur brute est de 14745. Ces deux valeurs sont stockées sous forme de constantes dans les fichiers de la bibliothèque AMS5915_simplified qui fait partie intégrante du programme de l’EFIS. Il s’agit d’une version simplifiée d’une ancienne version d’une bibliothèque écrite par Brian Taylor (Bolder Flight Systems), lequel a depuis complètement réécrit sa bibliothèque.
J’avais également un défaut similaire sur mon capteur différentiel (mais je ne me souviens plus s’il était aussi important, 13 kts pour une différentielle nulle, ça me semble quand même beaucoup). J’avais écrit un petit sketch (que je ne retrouve plus) pour afficher sur le moniteur série de l’IDE Arduino le nombre de “counts”. Pour une différentielle nulle avec mon capteur, je trouvais une valeur de 1569 counts, et j’avais donc modifié en conséquence les fichiers .h et .cpp de la bibliothèque AMS5915_simplified. Vous pouvez lire ces fichiers, j’y ai mis des commentaires qui expliquent mes modifications. Il vous faudra certainement ajuster la valeur de la constante digOutPmin pour lire une vitesse nulle quand la pression différentielle est nulle. Il est hautement probable que la valeur de 1569, adaptée à mon capteur, n’est pas du tout adaptée au vôtre. Et éventuellement, la valeur adaptée à votre capteur sera plus proche de la valeur théorique de 1638 qui figure dans la datasheet.
Il va falloir que je retrouve mon petit sketch d’étalonnage, ou que je le réécrive, et que je précise ce point au sujet des capteurs AMS5915 sur la page de l’EFIS.
Benjamin
Bonjour Benjamin,
J’ai un peu cafouillé avec les balises pour inclure les photos merci d’y avoir remis de l’ordre.
J’ai bien installé L’EFIS et l’AHRS dans le boitier (ça passe juste juste dans le diamètre 80…) mais pas le magnétomètre. Je pense déporter comme conseillé pour éviter les perturbations. En revanche j’ai des strobes en bouts d’ailes alors ce sera peut-être dans la queue du fuselage).
Je suis en train d’approvisionner le matos pour l’ensemble magnétomètre et les EMS…
La seule modification concerne le contrôleur graphique que j’ai déporté dans le dos de l’écran pour que la nape ne soit pas vrillée (et de tout façons elle ne passait pas dans le cylindre de 80mm). Par contre le raccordement avec le PCB de l’EFIS n’est pas hyper propre, je découvre le monde de l’électronique et je galère un peu à trouver les connectiques qui vont bien.
Concernant les connectiques en face arrière, cette version est juste un proto pour tester rapidement l’ensemble sans rien abimer. J’ai juste laissé un trou pour laisser passer un câble USB (connecté à la Teensy de l’EFIS) pour l’alimentation via une batterie portable, l’antenne GPS et la sonde de T°.
Mon idée est de monter des prise D-SUB pour la communication avec les autres modules et l’alimentation de l’ensemble. Mais comme dit plus haut je galère à trouver les pièces qui vont bien pour monter des prise D-Sub (encastrées et sur câbles) propres et qui ne coutent pas un bras. As-tu des conseils sur ce point ?
Je n’ai pas encore pris le temps de bien tester mais sans rien de connecté à l’équipement j’ai systématiquement 13kt de IAS. La vitesse varie bien dans la bonne direction lorsque je titille la prise statique et totale (doucement) mais je reviens toujours à 13kt. Penses tu qu’il y ait juste un calibrage à faire dans le programme ou ma sonde peut-elle être défectueuse ?
Ci joint une vue en coupe de la version actuelle du boitier avec les différentes cartes.
Nicolas
Bonjour Nicolas,
Merci pour votre commentaire, et bravo pour cette superbe réalisation, et pour la persévérance pour y parvenir !
J’imagine que vous avez inclus les deux PCB de l’EFIS et de l’AHRS dans le même boitier. Et peut-être même celui du magnétomètre distant ? Avez-vous été obligé de les modifier ? Je ne vois pas de connecteur sur la face arrière pour l’alimentation, le CAN bus…etc.
On a hâte d’avoir les résultats d’essais en vol. J’espère que vous ne serez pas confronté à un problème de compatibilité ou d’interférences électromagnétiques avec l’installation radio électrique de bord, c’était une de mes craintes au départ.
Vos photos sont particulièrement démonstratives. Elles n’apparaissaient dans votre commentaire que sous forme de liens à cliquer, car je n’avais pas encore pris le temps de configurer le site pour permettre aux internautes d’inclure des pièces jointes dans leurs commentaires. C’est maintenant chose faite. Vos photos apparaissent désormais sous forme de vignettes sur lesquelles il faut cliquer pour les agrandir.
Vous n’êtes pas le premier à signaler des difficultés pour configurer le NEO-M9N, et je n’arrive pas à identifier clairement les raisons de ces difficultés. J’ai encore très récemment mis à jour les pages sur l’AHRS et sur la configuration du GNSS. Il y a peut-être quelque chose que j’ai mal exprimé, mais je n’arrive pas à trouver quoi et où…
Y a-t-il un problème avec les versions de firmware, comme vous le suspectez ? Effectivement, le NEO-M9N que j’utilise chez moi pour les essais a le firmware version 4.00. Je n’ai pas noté la version du firmware de celui (plus récent) qui est à poste dans mon avion. Il est surprenant qu’un fichier de configuration créé avec la version 4.0 ne soit pas utilisable après upgrade du firmware vers une version plus récente. Si c’est le cas, alors à quoi bon créer et sauvegarder un fichier de configuration avant de mettre à jour son GNSS si on ne peut pas l’utiliser ensuite ! Je vais faire des essais, j’ai d’ores et déjà téléchargé dans ce but sur le site u-blox les 3 versions de firmware disponibles pour le NEO-M9N, à savoir 4.00, 4.03 et 4.04. Donc affaire à suivre…
Benjamin
Bonjour, merci d’avoir partagé ce projet! je le suis depuis quelques mois avec grand intérêt.
Le temps de collecter tout le matériel, faire fabriquer les cartes et souder l’ensemble (et galérer avec le sertissage des fiches).
L’ensemble est aujourd’hui fonctionnel (au sol) j’espère pouvoir le tester en vol dans les prochaines semaines.
j’ai un peu galéré à faire communiquer le module GPS avec la Teensy 4.0. J’ai réinstallé proprement l’IDE, les bibliothèques et u-center sur un PC vierge mais rien n’y faisait…
J’ai refait plusieurs fois la config du GNSS en suivant les vidéos mais soit la Teensy renvoyait “Impossible de communiquer avec le GNSS” soit j’avais tout les bons messages mais l’horizon restait cabré. J’ai ajouté un serial print du nbre de satellites juste avant la condition >5 et la valeur restait à zéro…
Finalement j’ai appliqué la méthode du fichier config tout fait pour le GNSS mais au moment du versement j’obtenais un message me précisant que le firmware du GNSS n’était pas le même que dans le fichier de config (4.04 chez moi et 4.0 dans le fichier de config). je cliquais sur ok mais toujours les mêmes symptômes.
J’ai finalement été chercher la version 4.0 sur https://content.u-blox.com/sites/default/files/UBX_M9_400_SPG.809ed6273c701f5d6c1ca2bf97758d23.bin et l’ai installé sur le gnss avec u-center (Tool/firmware update). Après ça j’ai à nouveau versé ton fichier de config et paf ça fonctionne!!!
je ne sais pas si c’est la raison qui à fait que ça fonctionne mais ça à solutionné des heures d’errance…
En parallèle de tout ça j’ai dessiné une boite pour recevoir l’ensemble des cartes et qui peut s’intégrer dans un trou diamètre 80mm. C’est encore un prototype (l’arrière est temporaire et je vais ajouter un port USB sur la tranche de l’écran. Mais si ça intéresse je peux faire passer les fichiers.
La tension du rétroéclairage est fournie par un convertisseur élévateur intégré au breakout, et qui peut aller jusqu’à 24 V indépendamment de la tension d’alimentation sur Vin. Pour obtenir plus de courant à travers les LED (qui contrôlent la luminosité), utilisez les 25 mA et 100 mA. cavaliers à souder.
Bonsoir.
Pas de soucis pour partager. Le côté tactile ne m’intéresse pas forcément. Pas trop pratique en vol.
Pour le côté rétro eclairage il suffit sur la RA8875 de souder les deux jump qui sont entre les résistances. Gain en luminosité. J’ai laissé les deux écrans 3heures d’affilée sans soucis pour le moment.
Laurent,
Si Stephaner (ou quelqu’un d’autre) veut faire un fork GitHub avec l’adaptation 800×480, tout le monde pourra en profiter !
Benjamin
Bonjour Laurent,
Plus l’écran est grand et lumineux, plus il faut d’intensité pour le rétroéclairage.
Attention à bien vérifier que le driver de LED de la carte Adafruit RA8875 pourra assurer…
Voir ce lien.
Benjamin
Benjamin,
Serait il possible de publier un fork sous github avec le travail de Stephaner sur l’ecran 800×480 si il est ok pour le partager ?
Bonjour à tous,
Merci Stephaner pour la piste de l’écran ADAFRUIT. Il est effectivement interessant.
Est il suffisamment lumineux ? Il est donné pour 300 400 CD/M2 ce qui est theoriquement 2 fois moins lumineux que l’ecran d’origine du montage.
J’avais trouvé celui là un peu plus lumineux mais plus cher :
https://www.digikey.fr/en/products/detail/az-displays/ATM0700H1/18796390
Ou celui là ;
2x plus cher mais >1000CD optimisé pour la lecture en plein soleil.
https://www.digikey.fr/en/products/detail/focus-lcds/E70RB-FS1100-N/14553206
Bonjour Stephaner,
L’écran Adafruit 2354 est un tactile résistif. Pensez-vous pouvoir exploiter cette caractéristique ?
D’autres constructeurs de l’EFIS seront peut-être intéressés par un retour sur cet écran, en particulier sur sa luminosité. Sera-t-elle suffisante pour exploiter l’écran en plein soleil ? La carte contrôleur RA8875 sera-t-elle en mesure de délivrer un courant suffisant pour le rétroéclairage de ce grand écran ?
Benjamin
bonjour bon vœux à tous .
j’ai mis des écrans 7″ Adafruit 2354 et adapté pour l’affichage en 800×480.
j’ai des cartes PCB d’avance pour les efis, ems, micro ems, Ahrs
Bonjour Laurent,
Effectivement, les écrans 7″ 800×480 haute luminosité ne sont pas courants.
Attention, le logiciel de l’EFIS est prévu pour une définition de 480 x 272. Il faudrait donc faire des modifications des graphismes, des tailles des polices et des emplacements des affichages textuels et numériques pour l’adapter à une définition de 800×480. Ce n’est pas compliqué à faire, juste un peu fastidieux. Je n’ai pas pris le temps de faire ce travail jusqu’au bout, seulement partiellement. Ce n’est pas très haut dans ma liste de priorités, d’autant plus que d’autres constructeurs de l’EFIS sont intéressés et vont peut-être entreprendre ce job, et j’espère le partager.
Benjamin
Après l’AHRS je me lance sur l’EFIS.
J’ai la plaque et les commandes composants sont en cours, petite réflexion du jour, j’ai relu les commentaires je tenterai bien de trouver un écran en 7′ 480×800 histoire de me faciliter la lecture des valeurs, mais ca ne semble pas simple à trouver.
Bonjour Stephaner,
Comme indiqué plus bas dans ma réponse du 18 mars 2023 à Florent, il faut commander les capteurs de pression AMS5915 par mail chez AMSYS. Ils sont plus réactifs que chez Analog Microelectronics.
Pour l’instant, je pense que tout le monde a réussi à se procurer ces capteurs AMS, ce qui est quand même plus simple que de modifier le PCB et le logiciel pour adapter les autres capteurs, que j’ai suggérés surtout pour le cas où, à l’avenir, les capteurs AMS deviendraient effectivement indisponibles. Ce qui n’est donc pas actuellement le cas.
Ceci étant dit, le capteur MPRLS est employé par l’EMS pour la mesure de pression d’admission, vous pouvez donc vous reporter au programme de l’EMS pour y trouver un exemple d’utilisation. Quant au capteur différentiel 4515D0 de TE Connectivity, la bibliothèque MS4525DO de Bolderflight fournit un exemple d’utilisation très clair.
Benjamin
Bonjour Stephaner,
Le LMP8601QMAX/NOPB n’est pas un composant de l’EFIS, mais de l’EMS…
Ce composant est effectivement actuellement indisponible. Chez Digikey comme chez Mouser, ils indiquent un délai de livraison assez rapide en mars prochain. Je vous conseille d’attendre cette disponibilité, sauf à recalculer vous même le circuit. Je ne connais pas le INA240A1QDRQ1.
Benjamin
Bonjour Benjamin.
l’approvisionnement du LMP8601QMAX/NOPB est juste très compliqué. Sur le site de Texas instrument j’ai trouve ce capteur en équivalence INA240A1QDRQ1 peux tu me confirmer a l’occasion si cela peut faire l’affaire. Merci d’avance
Bonjour Benjamin.
j’ai plutôt bien avancé pour adapter l’affichage sur l’écran 7″. Je bloque sur l’adaptation de la création d’objet pour remplacer les capteurs AMS5915 quasi introuvables par ceux préconisés MS4525 et MPRLS
.
Je te souhaite de très bonne fêtes de fin d’année
Bonjour Stephane,
Le message d’erreur est explicite, il vous manque la bibliothèque Adafruit_GFX.h, ou bien elle n’est pas placée au bon endroit.
L’emplacement de votre sketch est lui-même mal choisi.
Vous pouvez vous reporter à la page de ce site consacrée à l’IDE Arduino, dans la rubrique “Programmation”.
Vous pouvez aussi vous familiariser avec cet IDE sur Internet, en lisant divers tutoriels ou en regardant des vidéos consacrées à ce sujet.
Benjamin
Bonsoir Benjamin.
Tout d’abord merci de consacrer de ton précieux temps à m’expliquer et solutionner les problèmes que je rencontre, dus à mon ignorance!
j’ai recu les PCB et assemblé l’EFIS . Quand je fais vérifier , ce message s’affiche en orange:
C:\Users\steph\Desktop\EFIS_AvionicsDuino_V2_2\EFIS-AvionicsDuino-main\src\EFIS_AvionicsDuino_V2_2\EFIS_AvionicsDuino_V2_2.ino:111:10: fatal error: Adafruit_GFX.h: No such file or directory
111 | #include // Pour les fontes, il faut télécharger cette library https://github.com/mjs513/ILI9341_fonts et l’installer dans le dossier des libraries Teensy.
| ^~~~~~~~~~~~~~~~
compilation terminated.
Bonne soirée et encore merci
Bonjour Stephaner,
Même adresse mail que “rojouan” : une seule et même personne avec 2 pseudos ?
Sinon, pour l’EFIS, tous les fichiers de l’archive ZIP que vous avez téléchargée sur GitHub sont à extraire dans le même dossier que le fichier .ino. Les fichiers que vous citez sont inclus dans ce ZIP.
Benjamin
Bonsoir Benjamin.
si j’ai bien compris c’est ton prénom….
Je suis en galère avec ça quand je lance une vérification.
#include “HorizArt.h”
#include “HorizArtParamGen.h”
#include “AMS5915_simplified.h”
le message dit que c’est absent. J’en ai trouvé que j’ai mis sous ZIP pour les ajoutera aux bibliothèques mais rien ne colle !!!! ça dit c’est vide qu’il n’y a pas de librairie….
Merci d’avance pour ton aide précieuse.
Bonjour Jacques,
Merci pour votre aimable commentaire.
Il est vrai qu’il est compliqué de se procurer les capteurs de pression Amsys/Analog-Microelectronics, car les grossistes habituels ne distribuent pas les produits de cette société. Il faut les acheter en direct, et malheureusement, le service commercial ne fait pas beaucoup d’effort pour faciliter la tâche des clients.
Il existe d’autres capteurs numériques de pression atmosphérique ou différentielle aussi performants, et dans la même gamme de prix.
Comme capteur atmosphérique pour l’altitude, celui-ci est parfait. Adafruit fournit une “breakout board” disponible ici.
Comme capteur différentiel, celui-là est parfaitement adapté, et ne nécéssite pas de breakout board. Je l’utilise dans une autre application, avec cette bibliothèque.
Benjamin
Bonjour,
Jolie réalisation. Je suis très intéressé par cet efis, mais il semble très difficile de se procurer les capteurs de pression. Je n’ai aucune connaissance en programmation, mais en suivant toutes les explications je pense que cela est possible.
Actuellement je suis entrain de restaurer mon ulm MC30 et je dois refaire tout mon tableau de bord.
Une occasion pour inclure cet efis.
Merci vraiment pour ce travail réalisé.
Jacques
Bonjour Florent,
Je réalise aussi l’EFIS proposé ici. J’ai un afficheur 7″ en 700 x 480 pixels, donc l’équivalent de ton 5″.
J’ai commencé l’évolution du logiciel, mais il reste encore pas mal de travail pour cette adaptation. Je vois dans ton dernier post que tu as terminé cette évolution logicielle, serais tu prêt à la partager ?
Amicalement
Jean-Claude
Bonjour Florent,
Bravo pour l’adaptation du code de l’EFIS pour un écran 5″ de définition 800×480. D’autres pourront être intéressés par cette adaptation si elle peut être partagée.
Concernant les capteurs de pression, ce produit peut être utilisé pour la mesure absolue de la pression atmosphérique, il est bon marché, il existe une bibliothèque, il est facilement raccordable au circuit statique grâce à son port métallique. Il est utilisé dans notre EMS pour la mesure de la pression d’admission.
Pour la mesure de la vitesse air, il faut un capteur différentiel avec deux ports, et si on souhaite une sortie I2C, le choix n’est pas énorme, car il faut exclure les capteurs Honeywell malheureusement vendus par 100 unités pour ceux qui pourraient nous intéresser. Ce capteur de TE Connectivity semble bien adapté, mais il n’est pas donné. Cette bibliothèque doit pouvoir être adaptable facilement.
Il y a certainement d’autres solutions, merci d’avance de les partager sur ce fil de discussion.
Benjamin
Bonjour Benjamin,
Super cela fonctionne maintenant, j’ai modifié le code, tout est dans l’ordre je suis sur le remplacement des capteurs de pression par des honeywell.
Merci,
Florent
Bonjour Florent,
Ce n’est pas un problème de connexion.
L’écran mentionné sur la page de l’EFIS est un LCD TFT IPS 4.3″ 480 x 272 1000 cd/m² de marque Riverdi, référence RVT43HLTFWN00.
L’écran RVT50HQTFWN00 est un 5″ avec une définition de 800 x 480, c’est celui qui est utilisé pour l’EMS.
Le programme de l’EFIS est conçu pour une définition de 480×272, c’est pour cela qu’il n’occupe qu’une partie de l’écran 5″ 800×480, en haut et à gauche.
Je vois au moins 3 manières d’arranger ce problème.
1) changer d’écran et prendre un 4.3″ en 480×272, c’est la solution la plus simple et la plus rapide, aucune modification logicielle n’est nécessaire. Il faudra juste imaginer un autre usage pour le 5″…
2) conserver l’écran 5″ 800×480, accepter que l’horizon n’occupe qu’une partie de l’écran, et profiter du reste de l’écran pour afficher d’autres informations, ce qui nécessite de compléter le programme en fonction de ses besoins pour exploiter la place disponible.
3) modifier le programme de l’EFIS pour qu’il occupe toute la place. Pour cela, il faut commencer par faire les quelques modifications simples suivantes :
Dans le setup du fichier .ino, il faut remplacer la ligne
tft.begin(Adafruit_480x272);par
tft.begin(Adafruit_800x480);Dans l’onglet des paramètres généraux de l’horizon artificiel, il faut remplacer :
#define Cx 240#define Cy 136
#define DH 135
#define DL 239
par
#define Cx 400#define Cy 240
#define DH 239
#define DL 399
On obtient alors l’écran suivant :
La durée d’un itération de la fonction Loop() augmente un peu, car il y a pas mal plus de pixels à gérer, mais cela reste tout à fait raisonnable.
Après cela, il y a encore un peu de travail à fournir pour modifier les emplacements des affichages textuels, de l’horloge, de la barre du vario…etc. mais ça ne représente pas de difficulté particulière.
Benjamin
Bonjour,
j’ai eu un retour pour les capteurs de pressions effectivement ils sont pas internet friendly … et comme d’habitude maintenant, 8 semaines pour les avoirs.
j’ai fini de monter mon ensemble (sans les pressions du coup), j’ai un soucis d’affichage, j’ai tout mais en tout 1/4 en haut à gauche. Je trouve pas de variables pour une éventuelle taille d’écran à déclarer, j’ai celui-ci :
SM-RVT50HQTFWN00
comme si il était mal branché mais je trouve pas de connexion mauvaise…
A suivre.
Bonjour Florent,
J’ai effectivement souvenir d’avoir eu des difficultés de commande avec Analog Microsystems. J’ai cherché dans mes archives Outlook, j’avais en fait finalement commandé chez Amsys. Mais le circuit est en gros le même qu’avec Analog Microsystems, simplement un peu plus réactif, ils ne cherchent manifestement pas à développer la vente en ligne. Je ne connais pas les liens qui unissent ces deux entités qui vendent les mêmes capteurs, avec des adresses postales quasiment identiques, mais les numéros de téléphone et adresses mail diffèrent.
Compte tenu de ces difficultés, si je devais commander à nouveau des capteurs de pression, je pense que je chercherais plutôt du côté de Honeywell : très gros choix de capteurs numériques, avec un circuit commercial “normal”, via les grossistes habituels. Beaucoup de capteurs Honeywell disposent de bibliothèques dédiées Arduino/Teensy.
Benjamin
Bonjour, Super travail !
j’ai presque fini l’assemblage des composants sur la carte électronique EFIS. une coquille de commande, j’ai oublié 3 résistances …
j’ai un souci sur les capteurs pressions (statique et dynamique) j’arrive pas à obtenir de prix sur le site du fabriquant, j’ai jamais eu de réponses, vous vous fournissez ou ?
Merci
Bonjour Jean Claude,
L’adaptation des logiciels AHRS et EFIS pour n’utiliser qu’un seul récepteur GNSS est très simple et rapide à faire. Mais d’une part je n’ai pas de GPS chez moi, d’autre part je ne suis pas sûr de pouvoir tester cela très rapidement dans mon MCR, et enfin comme cela va possiblement demander quelques menus ajustements, je vais te contacter sur ton mail privé pour ne pas encombrer cette discussion sur le site. Mais dès que tout sera bien au point, je publierai cette nouvelle version sur le site.
Benjamin
Bonjour Benjamin,
Le retour. J’ai reçu le Teensy4.0 et RA8875 de Digi-Key. J’ai donc tous les composants pour la réalisation de l’EFIS, sauf le deuxième GPS, remplacé par une évolution logiciel de l’AHRS et du calculateur; quand penses tu mettre à disposition cette version EFIS ?
Comme je te l’ai dit, j’ai fait une (des) compilation(s) qui me donnent des erreurs. Je vais installer IDE 1.8.19 et Teensyduino 1.57 sur mon PC portable qui a été entièrement réinstallé (W10) et qui est donc sain! Je vais faire la compilation dessus, et si j’ai les même problèmes, je te ferai signe.
A bientôt.
JCB
Bonsoir Benjamin,
Merci de tes explications sur les bibliothèques.
J’ai compilé le programme EFIS_V2 et j’ai des erreurs, on verra cela à mon retour de vacances.
Bien à toi.
JCB
Jean-Claude,
Je ne connais pas les emplacements des bibliothèques sous Mac OS et Linux.
Sous Windows, dans la version 1.8.x de l’IDE Arduino, elles sont stockées dans 3 emplacements.
1) Les bibliothèques personnelle ou ajoutées par l’utilisateur sont placées dans un unique sous dossier du dossier Arduino, celui où sont stockés les sketchs. Pour moi, cela donne C:\…….\Documents\Arduino\libraries.
Ces bibliothèques ne sont en rien affectées par une mise à jour de l’IDE et/ou de TeensyDuino.
2) Les bibliothèques incluses dans TeensyDuino sont stockées dans ce dosier : C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries. Une mise à jour de TeensyDuino remplace toutes ces bibliothèques. Si certaines ont été modifiées par l’utilisateur, les modifications seront perdues. D’éventuelles bibliothèques ajoutées (à tort) par l’utilisateur à cet emplacement seront également perdues lors d’une mise à jour de TeensyDuino.
3) Les bibliothèques incluses dans Arduino sont stockées dans ce dosier : C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries. Une mise à jour de l’IDE Arduino remplace toutes ces bibliothèques. Si certaines ont été ajoutées ou modifiées par l’utilisateur, les modifications seront perdues.
Il ne faut pas non plus hésiter à aller fureter dans les “cores” Arduino ou TeensyDuino.
Cores Arduino : C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores
Cores TeensyDuino : C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores
Concernant l’ajout de bibliothèques, un lien utile ici. j’ai une préférence pour la méthode “Ajouter la bibliothèque .ZIP…” (menu Croquis > Inclure une bibliothèque). En effet, la méthode avec le gestionnaire de bibliothèque, si elle est très utile pour trouver les bibliothèques et leur dépôt GitHub (en cliquant sur le lien “More info”), s’avère gênante par le fait qu’elle installe les bibliothèques dans un dossier renommé, du genre “arduino_545164”. Il n’est alors pas facile de savoir que c’est la bibliothèque “Adafruit_ADS1X15” qui se trouve (ou plutôt qui se cache…) dans ce dossier. Alors qu’en téléchargeant le ZIP sur le dépôt GitHub de cette bibliothèque, et en appliquant la méthode “Ajouter la bibliothèque .ZIP…”, on obtient un dossier propre et net qui s’appelle “Adafruit_ADS1X15-master”. Nettement plus simple pour s’y retrouver !
Bonjour Jean Claude,
Tant mieux si tu as pu facilement rattraper cette erreur de PCB. Moi aussi, j’ai eu à corriger “micro-chirurgicalement” une erreur sur le premier PCB où j’avais interverti les pins 35 et 36… Du coup SW était sur 36 et phase 4 sur 35, ce qui évidemment ne pouvait pas fonctionner avec la bibliothèque Quad Encoder.
Mais la version en ligne des fichiers Kicad du PCB EFIS est corrigée.
Amicalement,
Benjamin
Oup, j’ai oublié de te répondre pour le codeur optique. En fait plus de peur que de mal, comme je te l’avais expliqué dans un post précédent, j’ai mis un aiguilleur avec pontet pour les fils A et B. Donc je ne mets plus de pontet mais un 2 fils soudés pour aller vers les bonnes broches.
Pour info, je ne comprends pas comment j’ai pu commettre cette bourde, j’ai travaillé directement avec les infos de Github, et je me suis vautré, c’est fou ou c’est l’âge…
Merci pour ta réponse qui ne laissait aucune ambiguïté.
Jean-Claude
Bonjour Benjamin
Je viens vers toi pour avoir des informations sur les bibliothèques gérées avec l’IDE car je ne comprends pas comment elles sont gérées au niveau emplacements. L’option “préférences” de “fichiers” ne permet pas de définir ces emplacements (sauf celles Arduino qui sont dans le dossier Arduino où se trouve l’exécutable). L’IDE fait il une recherche de bibliothèque au moment de son démarrage, comment opère t’il ? Y a t’il moyen de lui fixer un ou des emplacements ? Y a t’il de la littérature sur ce sujet, car je trouve que les informations sur Arduino.cc sont très limitées. Si tu as les réponses, je ferais un grand pas…Merci d’avance
Je pars au ski jeudi pour 10 jours, donc trêve durant ce séjour.
Jean-Claude
Bonjour Jean Claude,
Il n’y a effectivement pas de bibliothèque TimeLib. Mais dans la bibliothèque Time (de TeensyDuino), il y a un fichier TimeLib.h
Il faut ouvrir ce fichier TimeLib.h (et le fichier Time.cpp du même dossier) pour comprendre ce que le programmeur a voulu faire, et qu’il qualifie lui-même de “ugly hack” !!
Sur Teensy 4.1, avec la bibliothèque Quad Encoder, les pins utilisables pour les broches A et B de l’encodeur sont expliquées ici :
“There are 4 hardware quadrature encoder channels available the Teensy 4.x. The Teensy 4.x Encoders are supported on pins: 0, 1, 2, 3, 4, 5, 7, 8, 30, 31 and 33. On the T4.1 the following additional pins are supported: 36 and 37.”
Donc si tu connectes les phases A et B sur les pins 27 et 29, cela ne peut pas fonctionner avec cette bibliothèque. Sur le PCB et dans le programme, A est sur la pin 36, B sur la pin 37 et SW est sur 35.
Benjamin
Benjamin,
Je ne trouve pas la bibliothèque TimeLib, seulement Time; est ce la bonne ?
Je ne retrouve plus les informations concernant les broches à utilisées pour l’encodeur optique, j’ai mis 2 aiguilleurs à base de pontets, j’ai donc SW sur sur le port logique 36 (pin 28), A sur port 35(pin 27) ou 38 (pin 30) et B sur port 37 (pin 29) ou port 39 (pin 31); quels sont les liens à effectuer ? (je m’excuse mais je n’ai pas enregistrer l’adresse et je rame…
Jean-Claude
Benjamin,
Voilà une réponse qui me satisfait, et je suis d’accord avec toi sur tes remarques.
Je vais donc désinstaller la version 2 qui apporte plus de problèmes que de satisfaction.
Je te tiens au courant des résultats avec la version 1xx.
Merci pour tout..
JCB
Bonjour Jean Claude,
J’ai longuement testé la version 2 de l’IDE Arduino à partir d’octobre dernier. Au départ, le nombre d’avertissements et d’erreurs de compilation était énorme, en raison de bibliothèques mal installées, ou de définitions incorrectes des cartes Teensy, sans parler des conflits avec la version 1.8.19 précédente (+ Teensyduino 1.57) toujours installée.
Après une semaine d’efforts, j’ai enfin réussi à régler tous ces problèmes, en réinstallant toutes les bibliothèques nécessaires (donc en double…) pour finalement m’apercevoir qu’à l’usage, cette version 2 n’apporte pas suffisamment d’améliorations pour compenser les dégradations. La complétion automatique est un vrai plus, mais je n’aime pas du tout le moniteur série dans sa petite fenêtre en bas, la fonction “rechercher-remplacer” est très malcommode, les emplacements des divers fichiers (du core et des bibliothèques ajoutées) sont difficilement compréhensibles/accessibles (au moins sous Windows) et le débogueur, qui constitue la véritable révolution de cette version, n’est utilisable ni avec les cartes Arduino, ni avec les cartes Teensy. Si le débogueur était utilisable, j’aurais évidemment conservé cette version 2, en m’accommodant provisoirement de ses menus inconvénients, et en attendant des correctifs.
Mais comme ce n’est pas le cas, et comme beaucoup d’autres, je suis revenu à la version 1.8.19 + Teensyduino 1.57. En attendant des jours meilleurs pour cette version 2…
Je te conseillerais donc volontiers de faire tes essais de compilation avec la version 1, en vérifiant bien les bibliothèques, car je ne te serais malheureusement d’aucune aide avec la version 2 !
Amicalement,
Benjamin
Bonjour Benjamin,
Merci pour cette réponse rapide.
La carte sélectionnée dans IDE 2.0.2 est Teensy 4.1.
J’ai aussi beaucoup de warnings, mais le contenu du résultat de la compilation serait beaucoup trop long à mettre ici, il faudrait communiquer sur un autre support.
JCB
Bonsoir Jean Claude,
Avec quel type de carte as-tu lancé cette compilation ?
BUILTIN_SDCARD fait référence au lecteur de carte micro SD présent sur les Teensy 4.1 (et 3.6 également).
Si on essaye de compiler sur une autre carte, cela déclenche cette erreur.
Amicalement,
Benjamin
Bonsoir Benjamin,
Voici le résultat de la compilation :
Compilation error: ‘BUILTIN_SDCARD’ was not declared in this scope
qui correspond à la ligne 374 bool result = (SD.begin(BUILTIN_SDCARD));
As tu une explication sur cette erreur, merci d’avance.
JCB
Bonjour Jean Claude,
Tous mes meilleurs vœux également !
Bonjour Benjamin,
Meilleurs vœux pour 2023 ainsi qu’une bonne santé, sans oublier la réussite des développement en cours et des beaux vols.
Pour ma part, je vais compiler le programme EFIS V2 et faire l’essai car les tests TFT avec Arduino n’ont pas été concluants. Je te tiendrais au courant des résultats.
Jean-Claude
Bonjour Jean Claude,
Il y a aussi beaucoup d’exemples prévus pour des microcontrôleurs beaucoup plus puissants que l’ATmega328P de l’Arduino UNO. La version de la bibliothèque RA8875 qui est incluse dans Teensyduino a été spécialement optimisée pour le microcontrôleur NXP MIMXRT1062 qui équipe les Teensy 4.x, un ARM Cortex-M7 à 600 MHz. Cette puissance et toutes les ressources associées ne sont pas superflues pour animer un EFIS. Est-ce que ce n’est pas dommage de tenter de ralentir le RA8875 ? D’autre part, quand je compare les caractéristiques des dalles LCD Newhaven et Riverdi, ces dernières sont nettement plus lentes (27 Mhz contre 40 MHz), et pourtant, il n’a pas été nécessaire de modifier le paramètre setSysClock par défaut pour “ralentir” le RA8875… Mais je ne suis pas un spécialiste ! Tiens nous effectivement au courant de tes essais.
Amicalement,
Benjamin
Bonjour Benjamin,
Pour l’afficheur, MB signifie “Mounting Bracket”, le datasheet est donc celui du EF-ASXN comme tu l’as indiqué. Pour le RA8875, les exemples donnés avec la bibliothèque sont prévus pour tourner sur Arduino UNO, que j’alimente avec un chargeur USB 5V/2A. Je vais faire des essais en modifiant la fréquence “System Clock” car de base elle est de 60MHz dans la bibliothèque, et donc trop rapide pour l’afficheur qui supporte 40MHz max. Je te tiendrais au courant.
Pas de vol en ce moment, temps bouché et humide et le froid qui arrive !
Amicalement.
Jean Claude
Bonjour Jean Claude,
Je n’ai jamais essayé la carte Adafruit RA8875 avec une carte Arduino UNO, il n’y a pas de raison particulière pour que cela pose un problème, en dehors d’une lenteur des affichages incompatible avec un EFIS. Mais la carte UNO ne peut sans doute pas fournir l’alimentation de la carte RA8875 ET celle de l’écran, sans une autre alimentation externe. Je n’ai pas trouvé la datasheet du NHD-7.0-800480MB-ASXN sur le site Newhaven, celle du NHD-7.0-800480EF-ASXN (c’est peut-être le même produit…) ne semble pas montrer d’incompatibilité avec le RA8875.
Ce qu’il est possible de régler dans la bibliothèque RA8875, c’est la fréquence du bus SPI. Il y a bien une fonction _setSysClock dans la bibliothèque RA8875, mais c’est une fonction privée de la classe RA8875… Il ne faut bien sûr pas utiliser la bibliothèque Adafruit RA8875.
La publication de l’EMS sur le site tarde un peu, car j’ai corrigé le bug de pistes sur le PCB, bug qui perturbait le fonctionnement de l’encodeur, et j’ai rajouté des fonctionnalités comme la pression d’admission, un système de menu, et une sortie série USB des paramètres pour connecter le flight recorder. J’ai remonté le tout dans l’avion il y a quelques jours, il me faut maintenant une météo favorable pour les enregistrements…
Je ne comprends pas la question sur les retours à la ligne…
Pour les photos, il n’est pas possible d’en mettre directement sur le site dans les commentaires, cela exposerait à un risque de saturation des capacités de stockage de l’hébergeur. Mais il est bien sûr possible, dans un commentaire, de mettre une URL pointant sur une photo stockée ailleurs (imgur par exemple). Lorsque le commentaire sera approuvé, l’URL apparaitra comme un lien cliquable.
Amicalement,
Benjamin
Bonjour Benjamin,
Voici les nouvelles, je viens de recevoir mes circuits imprimés aujourd’hui, CI principal et CI AHRS.
Je me bats avec mon afficheur 7″ pour le faire fonctionner; les essais effectués avec les exemples du RA8875 et un bon vieux Arduino UNO. Il semblerait que le RA8875 soit trop rapide pour l’afficheur. Je vais regarder s’il est possible de faire varier la fréquence de fonctionnement pour ralentir ralentir le RA8875 qui comporte un PLL. Sinon, afin de valider le bon fonctionnement, j’ai acheter un TFT 7″ chez Adafruit hier, qui me servira pour valider le bon fonctionnement tant que mon problème avec mon TFT 7″ sunlight ne sera pas réglé.
De ton coté, des nouvelles ?
Sinon, sur ce blog, comment faire pour avoir des retour ligne correct de mise en page, et est il possible de mettre une photo avec un commentaire ?
Amicalement.
Jean-Claude
Bonsoir Jean Claude,
J’ai corrigé le lien de téléchargement du code source de l’EFIS. J’avais remplacé le fichier il y a deux jours, mais en oubliant de refaire le lien.
Bon courage pour la soudure !
Amicalement,
Benjamin
Bonjour Benjamin,
Pour info, le lien “Download EFIS V2 source code” de la partie anglaise renvoie une erreur, le lien n’est pas trouvé, une coquille doit être présente. De mon coté, j’ai commandé un RA8875 chez eBay que j’ai reçu, je vais faire les essais du display, mais je pense que je vais être obligé de faire une verrue sur la partie génération de courant pour obtenir les 180mA requit. Je ne comprends d’ailleurs pas Adafruit d’avoir fait ce générateur trop limité sur leur RA8875. Les branches de tous les TFT consomment 20MA, il aurait fallu avoir les options 20, 40, 80, 160 MA (avec les pontets de soudures) pour adresser tous les afficheurs 40 broches compatibles et un générateur de courant type TO220. Là, 25mA, +25mA et +100mA; ce qui fait 150mA max, au cas oui le FAN5333 le supporte en température ! Atre info, mes CI ont été expédié par Seeed, j’ai reçu les capteurs de pression de ches Analog Mocroelectronics, donc je ne vais pas tarder à être dans le “dur”.
Amicalement, JCB.
J’ai mis en ligne sur la page anglaise de l’EFIS les versions corrigées du schéma électrique, du PCB et du code source de l’EFIS V2. La qualité de la navigation dans les menus est nettement améliorée.
Benjamin
Re bonjour Jean Claude,
Si, il y a bien un connecteur pour le GNSS, c’est le J5. Voir la figure 6 sur la page anglaise de l’EFIS, et cette figure. Si on souhaite n’utiliser qu’un seul GNSS pour l’ensemble AHRS-EFIS, c’est tout à fait possible, même en conservant une simple liaison série entre l’AHRS et l’EFIS. Il faut localiser ce GNSS dans l’AHRS et non dans l’EFIS. La trame de données envoyée par l’AHRS comporte de nombreuses places libres. Lorsque tu en seras là, je mettrai en ligne une variante logicielle tenant compte de cette modification.
Je vais par ailleurs corriger le schéma et le PCB de l’EFIS pour que les phases A et B de l’encodeur optique GrayHill utilisent les pin 36 et 37 de la carte Teensy et non 35 et 37. C’est le switch central qui doit utiliser la pin 35. Et simultanément, je corrigerai la version du logiciel pour tenir compte de cette modification du hard et implémenter la librairie Quad Encoder, nettement plus efficace.
Amicalement,
Benjamin
Bonjour Benjamin,
J’ai fait mon CI en partant du schéma V2 de la partie anglaise. Je viens de me rendre compte que ce schéma ne comporte pas le connecteur pour le GPS_NEO M9N avec les broches 24 et 25 du Teensy pour la liaison série. Est-ce volontaire en attente d’une version logicielle récupérant les mêmes informations de l’AHRS. Sinon c’est liaison volante connectées sur le CI.
Bien cordialement.
JCB
Bonjour Jean Claude,
Je n’ai pas encore pris le temps de rédiger la page sur l’alimentation 5 volts. Mais c’est sur ma liste de tâches…
Il y a un module convertisseur 12-14 vers 5 volts dans l’EFIS-EMS, il alimente aussi le module AHRS et le module magnétomètre-température extérieure-humidité relative. Le Micro-EMS a sa propre alimentation.
Je vais mettre ce module en ligne très rapidement.
Bien cordialement,
Benjamin
Bonjour Benjamin,
L’EFIS est alimenté en 5V, alors que nos machines ont du 13V. Question, la version finale contiendra t’elle un convertisseur 12V/5V pour alimenter l’ensemble de l’EFIS, ou restera t’elle comme actuellement, obligeant à ajouter un module d’alimentation dans le tdb ?
Très cordialement
Jean-Claude
Bonjour,
Effectivement, le site n’a pas été alimenté en nouveautés depuis plusieurs mois. Ce qui ne signifie pas que nous n’avons pas travaillé ! Nous avons même beaucoup travaillé ! Entretenir un site Web prend du temps, mais développer l’EMS (et un nouvel AHRS, voir ci-dessous) en a pris encore plus. Sans compter la maintenance et le suivi de navigabilité d’un avion.
Je vais publier dès ce soir sur le site, sur la page EMS en français qui est en construction, une très courte vidéo en vol de l’EFIS-EMS dans sa version actuelle, vidéo faite il y a 3 jours ! Pas encore de beaux graphismes sophistiqués pour cet EMS, mais l’essentiel y est. Vous verrez que nous n’avons pas chômé ! Dans le même temps, il a fallu gérer une longue immobilisation d’un de nos avions, pour maintenance et réparation, cet avion n’a repris les vols que le 1er septembre, et c’est dans cet avion que cette vidéo a été faite.
Parallèlement, la société Naveol ne nous a plus donné de nouvelle, en particulier à la suite de ma sollicitation début juillet. Nous avons donc décidé de tenter une autre piste. Plusieurs essais en vol ont déjà été fait avec un nouvel AHRS de notre fabrication, et les résultats sont particulièrement encourageants. Ce nouvel AHRS est basé sur un GNSS U-Blox NeoM9N, une carte microcontrôleur Teensy 4.0, et (provisoirement) un IMU 9DOF MPU9250. Il n’a pas été simple d’adapter le logiciel de fusion des données, mais cela semble désormais acquis. L’horizon artificiel semble fonctionner aussi bien qu’avec l’AHRS Naveol, le point de comparaison étant un EFIS commercial Dynon D10A. Le capteur inertiel Invensense MPU9250 est assez ancien, nous allons travailler à le remplacer par un capteur plus récent et plus performant. Le MPU9250 a surtout servi à démontrer que le concept et le logiciel fonctionnaient comme attendu. Si nos espoirs se confirment, ce sera beaucoup plus simple (et plus économique) que d’attendre une version commerciale de l’AHRS Naveol, qui tarde à venir…
Benjamin
Bonjour,
Je viens aux nouvelles de vos réalisations.
Pouvez vous nous donner quels sont les états des évolutions de l’EFIS et de EMS. Avez vous assez de candidats pour lancer une mini série d’AHRS ?
Il semble que les projets soient en “stand-by” actuellement; peut on vous aider à faire avancer ces projets ? Comment ? Si vous êtes intéressé, je vous propose de dialoguer en MP.
Merci de vos réponses; à bientôt.
JCB
Bonjour,
Je suis également intéressé par ce kit. Bravo
Je reçois mon kit Alto à la fin de l’année et ce serait l’occasion de l’intégrer directement dans le tableau de bord. Cela laisse un peu de temps pour la qualification car il me faudra du temps pour le monter !
Amicalement,
Stéphane
Bonjour Soufyane,
Merci pour votre commentaire.
La commercialisation d’un kit n’est pas prévue, mais effectivement, une liste exhaustive de composants et de fournisseurs sera publiée sur le site, ainsi qu’une estimation des coûts. Il faut pour cela attendre encore un peu, cela sera fait dès que possible, c’est à dire avant la fin de l’année. Il faut au préalable terminer les essais en vol du nouvel EFIS et du nouvel EMS, mais l’avion utilisé pour ces tests est malheureusement immobilisé au sol pour encore quelques semaines, en attente d’une pièce détachée importante. Alors que tout est prêt et monté sur le tableau de bord…
J’ai relancé Naveol il y a quelques jours au sujet de la commercialisation de l’AHRS, j’attends la réponse. En période estivale, je m’attends à un délai bien normal. Dans l’attente, et avec votre accord, je peux vous rajouter à notre liste des personnes qui pourraient être intéressées par cet AHRS. Plus nous serons nombreux, plus Naveol sera motivé pour tirer une version commerciale des 3 prototypes qu’il nous a livrés.
Benjamin
Bonjour,
Votre projet est une excellente idée et laisse la porte ouverte à de nombreuses possibilités d’évolutions.
L’idée évoqué d’un kit (ou tout du moins une liste de lien matériel serait intéressant ainsi qu’une estimation de prix global du projet).
Coté AHRS est ce qu’une commercialisation est prévue prochainement ?
Merci
Bonjour,
Merci pour votre agréable commentaire.
Nous en sommes maintenant à presque 15 demandes pour une version commerciale de l’AHRS. Je vais en fait part à la société Naveol, pour voir si une précommande de 15 modules serait maintenant suffisante pour lancer une petite production. Je ne manquerai pas de vous tenir au courant par mail, ainsi que toutes celles et ceux qui ont manifesté un intérêt pour ce module. Je tiens à préciser que le site AvionicsDuino et moi-même n’avons aucun intérêt commercial chez Naveol !
Benjamin
Bonjour,
Je suis candidat pour la réalisation de cet EFIS, donc pour commander un AHRS de chez Naveol.
Merci pour cette réalisation qui est la seule a avoir ce niveau de performance, bravo.
Cordialement
JCB
Bonjour Mamadou,
Merci pour votre intérêt.
Il ne s’agit pas d’un kit, mais d’un plan. Vous pouvez réaliser vous même l’EFIS en achetant les différents composants.
Une nouvelle version comportant un GPS est en cours de tests en vol, elle sera prochainement publiée sur AvionicsDuino, avec les fichiers KICAD qui permettront de commander le circuit imprimé, et une liste exhaustive des composants.
Un EMS complet est également en cours de tests en vol. Donc plusieurs autres publications très prochainement sur le site.
Bonjour
Interessé par le kit
Merci
Bonjour Gérard,
Il est certain qu’un kit rendrait la réalisation plus simple. Ce site n’a cependant pas vraiment de vocation commerciale, donc un kit éventuel n’est pas trop à l’ordre du jour, d’autant que cela poserait aussi un épineux problème de responsabilité. Néanmoins, ce qui pourrait être fait facilement, c’est une liste exhaustive des composants nécessaires, avec les fournisseurs, ainsi qu’un manuel de montage précis, détaillé et illustré. Pour les circuits imprimés, avec les fichiers Kicad qui seront mis en téléchargement sur le site, il sera très simple pour n’importe qui de les commander. Par exemple chez Aisler, en Allemagne.
Si le prototype d’EFIS présenté sur cette page fonctionne parfaitement, les mises au point ne sont pas encore tout à fait terminées, et en particulier, le modèle définitif, intégré au tableau de bord du MCR 01, dans un boîtier en aluminium, n’a pas encore volé. En ce moment, avec Michel et Gabriel, nous consacrons en fait beaucoup de temps à la mise au point d’un EMS, qui volera en même temps que la version finale de l’EFIS, dans les quelques mois qui viennent. Cet EMS sera aussi présenté sur le site.
La société Naveol nous a fabriqué trois prototypes d’AHRS, un pour chacun de nos MCR, la disponibilité d’un modèle commercial économique de cet AHRS dépendra ensuite de la demande. Il faudrait au moins une vingtaine de candidats à l’achat pour que Naveol fasse ce petit développement commercial à partir du prototype.
Peut-être à bientôt lors d’un rassemblement Colomban !
Amicalement,
Benjamin
Bonjour,
La réalisation d’un kit me semblerait une excellente idée au regard de la demande et du nombre d’ULM en vol actuellement.
Si cela se produisait, je serais preneur….
Bien cordialement.
Gérard