• Passer à la navigation principale
  • Passer au contenu principal

Le DR400, l'atmosphère et sujets divers

J'explique ce que j'ai compris, en espérant que ça aide

  • Accueil
  • Aviation
  • Electronique
  • Articles sur WordPress
  • J’ai testé
    • Hébergement de sites web
    • Travaux de rénovation (maison et jardin)
  • Voyage au Japon
  • Autres sites réalisés
  • Mentions légales
  • Trim de roulis sur Long-EZ
  • Gestion d’un double allumage sur Dragonfly
  • Régulateur de coucou
Vous êtes ici : Accueil / Electronique / Gestion d’un double allumage sur Dragonfly

Gestion d’un double allumage sur Dragonfly

Le Dragonfly

C’est un avion de construction amateur, dérivé du Quickie de Burt Rutan, le génial père des VariEze, Long-EZ, Voyager et bien d’autres (voir Wikipédia pour plus d’informations).

Paul a équipé le sien de deux allumages électroniques, en lieu et place de l’allumage d’origine par magnéto. La magnéto, c’est moins bien sur bien des aspects, mais si on perd la batterie et l’alternateur en vol (c’est une image), le moteur continue à tourner. L’allumage électronique est plus exigeant côté alimentation…

Pourquoi un double allumage ?

Parce que sur un moteur d’avion à essence, l’allumage est généralement doublé pour assurer une redondance : traditionnellement, deux magnétos alimentent deux bougies par cylindre. Dans le cas de ce Dragonfly dont le moteur est dérivé d’un moteur automobile, la magnéto était unique.

L’inconvénient de deux allumages par rapport à un seul, est qu’on a deux fois plus de chances d’avoir une panne d’allumage ! Donc pour que le doublement de l’allumage apporte une sûreté de fonctionnement accrue par rapport à un seul, il faut que la redondance soit complète, de façon à ce que la panne d’un seul allumage n’arrête pas le moteur. C’est bien le cas avec deux magnétos et deux bougies par cylindre, et évidemment pas avec une seule magnéto.

Une méthode classique est d’assurer la redondance par deux technologies différentes, par exemple un allumage par magnéto, et un autre électronique. Ce faisant, on évite qu’un défaut systématique se produise simultanément sur les deux allumages (casse d’une pièce d’usure sur une magnéto, condensateur chimique défaillant au bout de 5000 h dans un montage électronique). Pour la même raison et sans être totalement paranoïaque, on peut sur des solutions informatisées, utiliser non seulement des bases matérielles différentes mais aussi des programmes développés par des équipes indépendantes.

Ceci étant, le pire n’est pas certain, l’utilisation de la même technologie sur les deux parties redondantes ne représente pas un risque grave dès lors que la fiabilité de ladite technologie a été prouvée. C’est bien le cas de l’allumage par deux magnétos identiques, c’est aussi le cas si on utilise un allumage électronique dont la fiabilité est avérée.  A cet égard, l’utilisation d’un allumage issu du marché automobile et connu comme fiable est une idée très pertinente. C’est ce qui a conduit Paul à choisir un allumage largement éprouvé sur véhicules Ford (Fiesta, etc.).

On le voit ici, à gauche du rouleau de fil rouge et noir passé « au cas où » en même temps que les autres (il porte la référence ESC 89FB-12A297-BB) :

L’analyse des modes de défaillance d’un système conduit à faire la chasse aux pannes dites de « mode commun », c’est à dire aux pannes pouvant réduire à néant la belle redondance qu’on a cherchée à mettre en place : deux allumages électroniques fiables, deux bougies par cylindre, mais une seule batterie, on voit tout de suite qu’un défaut électrique sur la batterie unique (ou sur l’alternateur qui l’alimente) se traduira par une panne simultanée des deux allumages et donc un arrêt du moteur. Pour cette raison, Paul a prévu d’alimenter un des deux allumages par une batterie de secours se rechargeant en même temps que la principale, mais via une diode anti-retour évitant que toute l’installation électrique de l’avion vienne décharger la batterie de secours en cas de défaillance de la batterie principale. Ainsi on a un allumage sur une batterie et un autre allumage sur une autre batterie, la panne de mode commun est évitée.

Sur cette photo, on voit la batterie de secours (12V – 7,2 Ah), sous la double bobine (de référence 88SF-12029-AA) d’un des deux allumages .

Mais alors où est le problème ?

Fondamentalement, le montage des deux allumages électroniques alimentés chacun par une batterie spécifique est sain, mais la question est de savoir où et comment connecter le compte-tours VDO. Question simple, mais réponse un peu compliquée.

L’allumage utilisé ne possède pas de sortie spécifique pour un compte-tours, mais comme il alimente deux bobines, il possède deux sorties pour ce faire. Chacune de ces sorties équivaut à un rupteur mécanique classique qu’on aurait remplacé par un composant statique. A l’oscilloscope on voit du 12V continu, qui chute à 0 quand le « rupteur » se ferme, et qui réapparait à l’ouverture du rupteur mais surmonté brièvement d’un pic de plusieurs centaines de volts. C’est normal, le but du bidule est de justement générer ce pic au primaire de la bobine pour que le secondaire fournisse aux bougies le pic de plusieurs kilovolts qui va bien. Mais peut-on impunément appliquer ce signal au compte-tours sans le griller, ni écrouler l’énergie fournie à la bobine ?

Le prudence impose d’interposer un petit circuit de mise en forme du signal. Moitié calculé et moitié pifométré, un circuit en « T » avec, horizontalement (l’horizontale du T), deux résistances de 47 kΩ et, verticalement, un condensateur de 10 nF font l’affaire. L’oscilloscope confirme que le signal est correct pour le compte-tours et que le signal appliqué à la bobine n’est pas atténué. Et le compte-tours affiche un régime plausible. Par contre, l’avance à l’allumage n’étant pas encore calée, le régime est instable et l’aiguille peu amortie du compte-tours amplifie la chose.

Un essai du compte-tours sur un générateur de signal rectangulaire 0-12V (facile à réaliser sur un Arduino) montre qu’effectivement le compte-tours n’aime pas les échelons de fréquence du signal. Un essai avec des paliers successifs de deux secondes à 500, puis 1000, puis 2000, puis 3000 tours/minute, met en évidence des oscillations de l’aiguille du compte-tours à chaque changement de palier.

A ce stade, on sait récupérer le signal pour le compte-tours, et on a bien noté qu’il faudrait l’intégrer pour calmer les oscillations du compte-tours (mathématiquement, si on intègre un escalier on obtient une rampe : normal !). Cette intégration est déjà une première complication. La seconde complication est que si l’allumage auquel on a choisi de connecter le compte-tours tombe en panne, on a un problème : le moteur tourne sur l’autre allumage, mais on n’a plus de compte-tours. Donc si on résume, on veut générer un signal pour le compte-tours qui soit toujours prélevé sur l’allumage le plus sain, et qui de plus soit intégré pour limiter les oscillations du compte-tours.

Ce sera déjà une amélioration. Le seconde amélioration bien tentante est de gérer automatiquement le cas simple d’un défaut de batterie. En effet, ce défaut de batterie entraine (en tout cas au bout d’un certain temps) la perte de l’allumage qui y est connecté, ce qui est dommage quand on sait que l’autre batterie, saine, pourrait alimenter les deux et que du coup on conserverait la redondance des allumages. Donc on va ajouter la commutation automatique de l’alimentation des allumages : chaque allumage est alimenté par sa batterie attitrée en temps normal, mais si la tension de ladite batterie est trop basse, il commute sur l’autre ; quitte à revenir ensuite à la configuration initiale si la tension de batterie est remontée à une valeur normale.

La solution retenue : BGA sur base Arduino

Le BGA, c’est le nom que nous avons donné au Boitier de Gestion des Allumages…

Le voici en place derrière le tableau de bord :

Quant à l’Arduino qui constitue le coeur du boîtier, c’est un petit circuit du commerce disponible pour pas cher en France et à vil prix sur le marché asiatique (le nôtre a couté 5 € port compris, mais c’est un clône avec quelques différences par rapport à l’original).

Voici l’intérieur du boitier en cours de câblage :

Pour le raccordement des allumages aux batteries, nous avons utilisé le module de 2 relais (2 € port compris, acheté devinez où) que l’on voit sur la gauche de la photo sous les 4 gros fils rouges. Qu’on se rassure, les fils sont gros à cause de l’isolant silicone, mais il ne passe qu’un ampère par allumage.
A ce propos, on peut s’interroger sur l’utilisation, sur le boîtier, d’un connecteur DB25 qui n’a pas vocation de connecteur d’alimentation : par précaution, toutes les broches des circuits d’alimentation sont doublées. Ce n’est pas près de chauffer autant que les prises micro-USB de nos smartphones bien plus inquiétantes à cet égard.

S’agissant d’un seul exemplaire à réaliser, le plus simple est l’utilisation d’une carte fille « proto shield » surmontant l’Arduino, sur laquelle on peut reporter toute la partie électronique (qui s’est compliquée en cours de route depuis la photo). Pour le rétablissement de la balance commerciale, ce « shield » a été approvisionné en France : circuit nu à plus de 12 €, balance dûment rétablie…

Pour le pilote, l’interface est minimaliste : un interrupteur ON/OFF spécifique à l’allumage, et 4 voyants (LEDs bicolores).

A la mise sous tension, un bref autotest permet de vérifier les voyants.

Puis (voir photo ci-contre) les deux voyants « batteries » s’allument en vert (batteries OK) et les deux voyants « allumages » s’allument en rouge (allumages éteints).

Ensuite, dès que le moteur tourne, les 4 voyants sont verts et si tout va bien ils le resteront pendant toute la durée du vol.

Cette notice d’utilisation en dit un peu plus sur les indications des voyants et sur la logique de fonctionnement du BGA.

Schéma électronique du BGA et programme de l’Arduino

Sauf à vouloir adapter la présente réalisation à une application similaire, l’exposé du détail de l’électronique et du programme Arduino ne présentent pas d’intérêt particulier.

Particularités du programme

Utilisation des interruptions

Le logiciel passe son temps à attendre des évènements « rares ».

L’horloge de l’Arduino a une fréquence de 16 MHz et donc une période de 1/16 = 0,0625 µs. Quand les choses « se précipitent » (moteur à 3000 tours/minute), l’Arduino n’a du travail urgent que toutes les 10 ms, soit tout les 160 000 coups d’horloge. C’est dire qu’il a du temps libre pour mesurer les tensions de batteries, faire divers calculs et commander les voyants.

La solution classique est que le programme principal [qui s’appelle d’ailleurs loop()] boucle sans cesse en regardant s’il y a du nouveau, ce qui fait plein de scrutations de nombreuses variables pour rien, avec le risque qu’une des scrutations tombe sur un cas mal géré et que le programme se plante dans une boucle sans fin. Il est beaucoup plus simple d’utiliser les interruptions (dont celle d’un des timers de l’Arduino) pour  cadencer le travail du microprocesseur en lui disant quand une impulsion vient d’être reçue d’un allumage ou quand telle ou telle temporisation est terminée. C’est la solution qui a été retenue.

Intégration du signal envoyé au compte-tours

Le signal envoyé au compte-tours est un signal rectangulaire normalement de même fréquence que celle des impulsions reçues de l’allumage.

Sauf que pour éviter de répercuter les variations rapides de cette fréquence des impulsions, on a vu qu’il faudrait l’intégrer. Donc au lieu de seulement mesurer la durée entre les deux dernières impulsions, on va calculer la moyenne des 25 dernières durées mesurées, dite « moyenne glissante ». On va donc calculer la « somme glissante » qu’on divisera ensuite par 25 pour avoir la moyenne.

Pour réaliser cela, on utilise une structure faite pour ça : un tableau de 25 cases. Trop simple !

Le mécanisme est le suivant : on imagine 25 cases disposées en cercle, et on remplit ces cases, une à une, avec les mesures successives comme on distribuerait des cartes à jouer, chaque case à son tour. A cette différence près avec le jeu de cartes que chaque nouvelle carte dans une case remplace l’ancienne au lieu de se placer au-dessus.
Quand une mesure nouvelle arrive, elle doit aller dans une case contenant déjà une mesure ancienne. Je lis cette mesure ancienne (que je peux maintenant jeter), je la retranche de la somme glissante actuelle et j’y ajoute la valeur de la nouvelle mesure (que je place à son tour dans la case, à la place de l’ancienne, pour la conserver jusqu’au prochain passage). C’est tout ! La prochaine mesure tombera dans la case suivante et ainsi de suite. A chaque nouvelle mesure, la somme glissante est recalculée : en quelque sorte elle oublie la mesure la plus ancienne pour la remplacer par la plus récente, de sorte qu’elle est toujours égale à la somme des 25 dernières mesures.

On pourrait procéder de façon moins astucieuse et calculer benoitement à chaque nouvelle mesure la somme des 25 cases, mais ce serait beaucoup moins rapide, et tellement moins beau…

Juste un conseil : arrêtez les mots croisés et le sudoku, et mettez vous à l’Arduino, c’est bluffant.

Copyright © 2023 - Claude Goumain · Développé en environnement Genesis Framework · Site WordPress

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mémoriser vos préférences et nous permettre de réaliser des statistiques sur l'usage du site.
Configurer les CookiesJe refuseJ'accepte
Gestion des cookies

Aperçu de confidentialité

Ce site Web utilise des cookies pour améliorer votre expérience de navigation. Parmi ceux-ci, les cookies classés comme nécessaires sont stockés sur votre navigateur car ils sont essentiels au fonctionnement des fonctionnalités de base du site Web. Nous utilisons également des cookies tiers qui nous aident à analyser et à comprendre comment vous utilisez ce site. Ces cookies ne seront stockés dans votre navigateur qu'avec votre consentement. Vous avez également la possibilité de désactiver ces cookies. Néanmoins, la désactivation de certains de ces cookies peut affecter votre expérience de navigation. Encore que sur le présent site ce soit sans risque puisque les seuls cookies sont ceux servant à la gestion des cookies ;-)
Nécessaires
Toujours activé
Les cookies nécessaires sont absolument essentiels au bon fonctionnement du site Web. Ces cookies assurent les fonctionnalités de base et les fonctions de sécurité du site Web, de manière anonyme.
CookieDuréeDescription
cookielawinfo-checkbox-advertisement1 yearThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Advertisement".
cookielawinfo-checkbox-analytics1 yearThis cookies is set by GDPR Cookie Consent WordPress Plugin. The cookie is used to remember the user consent for the cookies under the category "Analytics".
cookielawinfo-checkbox-necessary1 yearThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance1 yearThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
Fonctionnels
Les cookies fonctionnels aident à exécuter certaines fonctionnalités telles que le partage du contenu du site Web sur les plates-formes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités tierces.
Performance
Les cookies de performance sont utilisés pour comprendre et analyser les principaux indices de performance du site Web, ce qui contribue à offrir une meilleure expérience utilisateur aux visiteurs.
Analytiques
Les cookies analytiques sont utilisés pour comprendre comment les visiteurs interagissent avec le site Web. Ces cookies aident à fournir des informations sur les mesures du nombre de visiteurs, du taux de rebond, de la source du trafic, etc.
Publicitaires
Les cookies publicitaires sont utilisés pour fournir aux visiteurs des publicités et des campagnes marketing pertinentes. Ces cookies suivent les visiteurs sur les sites Web et collectent des informations pour fournir des publicités personnalisées.
Autres
Les autres cookies sont ceux qui sont en cours d’analyse et n’ont pas encore été classés dans une catégorie particulière.
CookieDuréeDescription
cookielawinfo-checkbox-functional1 yearThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-others1 yearNo description
Enregistrer & appliquer
Propulsé par CookieYes Logo