projet: améliorer la gestion de l'électricité sur le c172

zakharov · 31/03/2006 20:06:02

salut,

ce thread fait suite à ces posts batterie + petites choses lui-même suite de problèmes moteur.

l'objectif est de modéliser un circuit électrique évolué pour le cessna, qui permettrait ensuite via un logiciel externe d'y apporter un petite touche de sel en insérant quelques pannes (en plein vol bien sûr, c'est plus rigolo )

pour débuter j'ai modélisé le circuit électrique du cessna 172p (attention, pas celui qui est prévu de base dans fgfs 0.9.9, un autre qui était à côté et inutilisé bien que plus complexe). le schéma se trouve ici en pdf. le fichier xml qui a servi à faire ce schéma est Aircraft/c172p/c172-electrical.xml. A vue de nez, ce schéma me convient même si j'y verrai bien quelques améliorations, notamment avec les connexions de l'electric bus 2.

voila, c'est un début. j'ai fait quelques avancées aussi avec un script nasal que je suis en train de bidouiller.

si certains sont intéressés par l'aventure... on peut discuter ici de nos avancées et idées respectives.

@+

teo · 1/04/2006 11:10:12

Hello,

J'ai commencé à me documenter sur l'alternateur, car tu disais qu'il donnait toute sa puissance à partir de 600 tr/min, ce qui est loin de représenter la réalité. En fait à faible vitesse, il consomme plus qu'il ne délivre de courant (car l'alternateur n'étant pas à aimants permanents, il faut ammener un courant d'excitation dans les bobines). Et en plus la puissance délivrée n'est pas une fonction linéaire de la vitesse de rotation (encore que ça dans un premier temps, ce n'est pas grave, on peut considérer que si en première approximation).

Dernière modification par teo (16/04/2006 15:49:21)

teo · 2/04/2006 11:00:16

Hello,
J'ai refait quelques tests. Et effectivement, il y a pas mal de choses à revoir. Lorsque le moteur ne tourne pas, il y a 15 A de tirés sur la batterie. Ce chiffre ne varie pas lorsqu'on fait fonctionner ou non les feux, les volets...
Les feux restent allumés avec une tension de 1 V...
Si l'on souhaite simuler une panne d'alternateur par exemple, il faut pouvoir appliquer les procédures d'éconnomies d'energie existantes pour l'avion. Il faut donc bien que la consommation varie en fonction de ce qui est branché, et un appareil ne doit fonctionner que s'il a la tension nécessaire.
Ca nous laisse du boulôt (enfin, si tu acceptes ma participation ).

a+

Dernière modification par teo (16/04/2006 15:51:05)

zakharov · 3/04/2006 1:11:31

salut téo,

Ca nous laisse du boulôt (enfin, si tu acceptes ma participation smile.

bien sûr! avec grand plaisir!

Lorsque le moteur ne tourne pas, il y a 15 A de tirés sur la batterie. Ce chifre ne varie pas lorsqu'on fait fonctionner ou non les feux, les volets...
Les feux restent allumés avec une tension de 1 V...

j'ai pas trop eu le temps de regarder dans c172-electrical.nas ce week-end, mais en fait la décharge de la batterie se fait par la fonction BatteryClass.apply_load, cette fonction renvoie une valeur que je ne comprends pas, et qui n'est utilisée par personne. et dans la fonction update_virtual_bus (fonction qui centralise toutes les demandes en jus de l'appareil, via un bus virtuel) il y a une ligne qui dit que la "charge normale" est de 15 A, cette charge s'ajoute à toutes les autres charges éventuelles (litghs, etc. qui ne sont pas toutes implémentées en plus), sans compter sur l'ésotérique constructeur BatteryClass.new qui comportent des valeurs bizarres (constructeur?)...
de plus peut-être que la batterie délivre réellement un courant constant pour une grande amplitude de tensions.
la tension chute jsuqu'à 1V à cause d'une condition qui fait que la décharge continue tant que la tension > 1.0V, peut-être pour éviter des futurs problèmes de division par zéro qui sait? (cas du court-circuit par exemple pas encore géré)

bref ne vaudrait-il pas mieux recommencer un script nasal tout neuf (en prenant exemple sur celui qui existe déjà pour des idées mais pas plus) et en se basant sur une construction d'arbre de propriétés fournie par le fichier xml fourni Aircraft/c172p/c172-electrical.xml mais non utilisée actuellement?

peut-être pourrons-nous nous dégager de savoir pourquoi telle ou telle valeur est utilisée et reprendre un chemin d'une logique qu'on pourra démontrer.

@+

Dernière modification par zakharov (3/04/2006 1:17:31)

teo · 4/04/2006 18:09:13

Salut zakharov,

zakharov a écrit :

de plus peut-être que la batterie délivre réellement un courant constant pour une grande amplitude de tensions.

Ce qui serait le contraire du fonctionnement réél, qui normalement est une tension (à peu près) constante pour une grande plage de courants.

bref ne vaudrait-il pas mieux recommencer un script nasal tout neuf (en prenant exemple sur celui qui existe déjà pour des idées mais pas plus) et en se basant sur une construction d'arbre de propriétés fournie par le fichier xml fourni Aircraft/c172p/c172-electrical.xml mais non utilisée actuellement?
peut-être pourrons-nous nous dégager de savoir pourquoi telle ou telle valeur est utilisée et reprendre un chemin d'une logique qu'on pourra démontrer.

Oui, je pense que c'est mieux effectivement bien de tout remettre à plat.

Je me suis imprimé le fichier nasal, je vais commencer à le regarder pour me familiariser avec ce langage (au fait, je ne suis pas programmeur, je bidouille juste un peu et le seul langage que je connaisse, c'est le C).

a+

zakharov · 5/04/2006 1:42:05

resalut teo,

le nasal est hyper simple, et je suis en train de me plonger justement dans le code C du langage Nasal utilisé par fgfs pour en voir les fonctions déjà implémentées (j'ai aussi comme projet de porter les script plandevol et ballade en nasal pour une utilisation directe dans fgfs).

il y a les autres scripts nasal aussi qu'on peut voir.
sinon dans le fichier docs-mini/README.electrical Curt dit que le système de gestion du système électrique par fichier xml doit être abandonné au profit d'une gestion (seule?) par script nasal. je lui poserai la question via la list flightgear-devel pour savoir si dans le futur le xml sera complètement abandonné, ou si on peut continuer à modéliser les circuits en xml (cad les branchement depuis les sources d'énergie, jusqu'à la petite loupiotte qui dit d'attacher sa ceinture) et gérer les flux électrique via un script .nas

sinon j'ai zieuté rapido dans les sources Systems/electrical.cxx et hxx pour voir ce qui s'y passait, et également dans FDM/JSBSim/models/propulsion/FGPiston.cpp et h, et dans FDM/YASim/PistonEngine.cpp et hpp pour voir s'ils y causent de consommation électrique.

une tension (à peu près) constante pour une grande plage de courants

ben c'est simple alors , tentons de voir comment ça se passe:
chacun des éléments consommateurs d'énergie est utilisable pour une gamme de tension (disons 24V), en dessous, ou au-dessus, le constructeur ne garantit rien.
en général on connait plutôt la puissance nécessaire (exemple une ampoule de 75W), on pourrait alors déterminer l'intensité qu'elle réclame P(W) = U(V) * I(A) non?
donc une fois qu'on connait la somme de toutes les intensités demandées, il faudrait trouver quel est l'effet sur la batterie (ça se décharge, oui, mais comment?).
dans le script electrical.nas il y a le concept de "charge" (charge_percent) qui m'embrouille, et pourtant qui a l'air si vrai (cf l'indicateur sur nos téléphones ou ordis portables).

@+

Dernière modification par zakharov (5/04/2006 1:48:24)

teo · 6/04/2006 17:22:15

Hello,

chacun des éléments consommateurs d'énergie est utilisable pour une gamme de tension (disons 24V), en dessous, ou au-dessus, le constructeur ne garantit rien.
en général on connait plutôt la puissance nécessaire (exemple une ampoule de 75W), on pourrait alors déterminer l'intensité qu'elle réclame P(W) = U(V) * I(A) non?
donc une fois qu'on connait la somme de toutes les intensités demandées, il faudrait trouver quel est l'effet sur la batterie (ça se décharge, oui, mais comment?).

La puissance donnée par le constructeur est celle qui est consommée à la tension normale de fonctionnement. Pour une autre tension, la puissance ne sera donc pas forcement la même (même rarement en continu) et donc on ne pourra pas en déduire le courant, car à priori, on ne connaît pas la tension sur le bus.
Un système qui serait pas mal (enfin, d'après moi) : pour chaque appareil consommant de l'électricité on donne la puissance. Comme ça si quelqu'un veut ajouter un instrument, changer une ampoule par une autre plus puissante... il n'a que ce paramètre à indiquer. A partir de la puissance, et sachant que c'est la puissance à 24 V (dans notre cas), on calcule la résistance équivalente P=U.I ; U=R.I => P=U²/R (ou éventuellement la conductance G=1/R car tous les circuits étant en parallèle, ce sera plus simple pour les calculs). Du coup on peut calculer la résistance de chaque bus et donc la résistance aux bornes de la batterie. La batterie étant modélisée par un générateur de tension (dont la valeur dépend de la charge) et d'une résistance (qui peut être fixe dans un premier temps, mais que l'on pourra faire varier selon certains critères si l'on souhaite une meilleure modélisation ; mais déjà avec une valeur fixe on aurra un meilleur modèle que celui existant).
On se retrouve donc avec un générateur de tension et un simple pont diviseur. Il est alors aisé de calculer la tension disponible sur les bus et donc sur chaque appareil. Et partir de chaque résistance, on peut calculer l'intensité, ce qui peut être utile pour les fusibles par exemple.
Bien entendu là c'est le cas avec uniquement la batterie, mais on peut ajouter ensuite l'alternateur, et ça ne complique pas vraiment, car avec thévenin, on ramène le tout à un seul générateur de tension pour le calcul du virtual bus. Même chose si on ajoute une prise externe.
L'avantage de ce système, c'est qu'il est évolutif, si quelqu'un veut par exemple affiner la modélisation des ampoules (pour tenir compte de la surintensité à la mise sous tension par exemple), il n'aura qu'à changer le calcul de R.
C'est clair ou pas ? J'ignore ton niveau en electr[icité|onique|otechnique]. Je vais essayer de faire ce we un petit schéma explicatif, et quelques calculs, en me basant sur ton schéma des connexions électriques.

dans le script electrical.nas il y a le concept de "charge" (charge_percent) qui m'embrouille, et pourtant qui a l'air si vrai (cf l'indicateur sur nos téléphones ou ordis portables).

Je n'ai pas trop regardé comment le charge_percent était calculé, mais à vu de nez, ça me semble pas trop mal. Par contre, j'ai tracé la courbe de la fonction de get_output_volts avec gnuplot. Le factor donne une valeur proche de 1 pour un me_charge_percent entre 50 et 80 %, une valeur légèrement supérieure à 1 au dessus de 80 %, et une valeur qui décroit rapidement en dessus de 50 %. Ce facteur est ensuite multiplié par la tension idéale de 24 V.
Ce n'est pas terrible comme modélisation, mais ça permet d'avoir une baisse de la tension en fonction du niveau de charge de la batterie. Dommage que cette tension ne soit pas exploitée par la suite (moteur qui démarre quand même, feux qui restent allumés...).
La même fonction sert pour get_output_amps ce qui est complètement aberrant dans ce cas.

a+

Dernière modification par teo (6/04/2006 17:43:12)

zakharov · 7/04/2006 1:45:16

salut teo!

J'ignore ton niveau en electr[icité|onique|otechnique]

quasi nul, ça fait un bail que j'y ai pas touché et en plus j'étais pas une flèche en électro.

sinon j'ai trouvé quelques infos intéressantes sur le cessna 172Skyhawk. pour info type manifold signifie que la battreie est scéllée et ventilé par un tube pour évacuer les gaz (notamment hydrogène), typique sur les batteries lead-acid.

et comment cela fonctionne-t-il? j'ai trouvé un site intéressant même si j'ai perdu un certaine gymnastique scientifique. la page indiquée est celle du déchargement d'une batterie, il y en a tout un tas d'autres sur la charge, et autres sujets.

j'y ai appris qu'il ne fallait pas laisser se décharger une batterie en-dessous d'un certain voltage (dépend des batteries mais dans notre cas, je pense, aux alentours des 21~22V) sous risque de ne plus pouvoir la recharger, et certain critères comme le "C-rate" qui (si j'ai bien compris 1C c'est l'intensité que peut fournir une batterie pendant une heure, dans notre cas 12,75A), il y a des calculs à partir de ce nombre (C pour charge?) notamment un nombre de Peukert qui représente la résistance interne de la batterie, et donc son efficacité (un fichier xls qui modélise le nombre de peukert, pour pouvoir lire les fonctions il faut enlever la protection de la feuille).

sinon en fouinant dans le code de fgfs j'ai trouvé que le système électrique est géré par Systems/electrical.cxx qui est ... identique à c172-electrical.nas! (à part que c'est du C). j'ai posé la question aux développeurs. mais en pleine période de sortie d'une nouvelle version... ils ont d'autres chats à fouetter apparemment je retenterai plus tard. et puis ils sont plus intéressés par une réécriture complète de la gestion électrique.

Un système qui serait pas mal (enfin, d'après moi) : pour chaque appareil consommant de l'électricité on donne la puissance.

tout à fait d'accord
http://seam.avionics.free.fr/pdf/KT76C+ … 8-0003.pdf -> ici ils donnent U et I
http://www.bayo.com/produits/ci_102.pdf -> ici ils donnent directement la résistance de l'équipement

pour ce qui est de la modélisation du non fonctionnement des instruments j'ai pensé à un schéma:
supplier<-->buses[<-->switches<-->circuit-breakers<-->test]<-->equipement
changer les valeurs de switches dans l'arbre des propriétés modifie également la position des boutons sur le tableau de bord (par exemple la correction que j'avais tentée dans le script repositionnait le bouton starter sur "both"). or si on ajoute un test supplémentaire (par une balise xml <switch>) qui n'est géré par rien d'autre que par le script, les boutons resteront en place et pourtant ce qui se trouve en aval ne sera plus alimenté (si test est faux cas de la batterie plus assez efficace).

@+
seb

teo · 9/04/2006 20:51:24

Bonsoir zakharov,

zakharov a écrit :

quasi nul, ça fait un bail que j'y ai pas touché et en plus j'étais pas une flèche en électro.

C'est que tu y as touché un peu alors

sinon j'ai trouvé quelques infos intéressantes sur le cessna 172Skyhawk. pour info type manifold signifie que la battreie est scéllée et ventilé par un tube pour évacuer les gaz (notamment hydrogène), typique sur les batteries lead-acid.

Bon bein, il faudra en tenir compte dans les calculs
Au moins ça confirme certaines données. Ca me semblait faible comme capacité pour la batterie, mais visiblement c'est bien ça.

sinon en fouinant dans le code de fgfs j'ai trouvé que le système électrique est géré par Systems/electrical.cxx qui est ... identique à c172-electrical.nas! (à part que c'est du C). j'ai posé la question aux développeurs. mais en pleine période de sortie d'une nouvelle version... ils ont d'autres chats à fouetter apparemment je retenterai plus tard. et puis ils sont plus intéressés par une réécriture complète de la gestion électrique.

Donc finalement, lequel sert/doit être modifié, le cxx ou le nas ?

http://seam.avionics.free.fr/pdf/KT76C+ … 8-0003.pdf -> ici ils donnent U et I

Cet exemple me contredit un peu car la puissance reste constante. Mais il doit y avoir un sélecteur interne. Ce qui ne veut pas dire que cette puissance reste constante autour d'une des 2 tensions. Et de toute façon, le calcul de R (en fait G) peut être dynamique et gérer ce type de cas.

pour ce qui est de la modélisation du non fonctionnement des instruments j'ai pensé à un schéma:
supplier<-->buses[<-->switches<-->circuit-breakers<-->test]<-->equipement
changer les valeurs de switches dans l'arbre des propriétés modifie également la position des boutons sur le tableau de bord (par exemple la correction que j'avais tentée dans le script repositionnait le bouton starter sur "both"). or si on ajoute un test supplémentaire (par une balise xml <switch>) qui n'est géré par rien d'autre que par le script, les boutons resteront en place et pourtant ce qui se trouve en aval ne sera plus alimenté (si test est faux cas de la batterie plus assez efficace).

heuu, il fait quoi le << test >> ?
Dans ma vision des choses, débrancher un équipement revient à mettre à zéro sa conductance, plus simple à gérer que de mettre une résistance à l'infini ou de faire un test pour en tenir compte ou pas.
marrant ces boutons qui se baladent

J'ai un début de schéma, et un début d'explication pour le schéma.
J'ai également en parti modélisé le bus virtuel, mais ce n'est pas encore sur le site. De plus il me manque deux choses : l'alimentation externe (utile ?) et la limitation de courant qui je suppose existe, car sinon, lorsque la batterie est très déchargée, elle aurait un courant de charge trop important, et il faut également limiter la charge une fois quelle est chargée. Il est probable qu'il n'y ait qu'une résistance pour la limitation, mais je préfère encore chercher.
Tout se trouve là. (nécessite un navigateur qui supporte le SVG.)

A+

Dernière modification par teo (16/04/2006 16:01:38)

zakharov · 9/04/2006 23:56:25

salut téo!

lequel sert/doit être modifié, le cxx ou le nas

le nas, car le code en C est réservé aux avions ne fournissant pas de script gérant l'électricité (modèle par défaut si rien de mieux existe). je pense qu'il vaut mieux se concentrer sur la nas, et ensuite proposer un modèle à traduire en C, comprenant tes avancées en conductance et tout.

à part cela le "test" que je proposais est une propriété dans l'arbre des propriétés de fgfs. nous la créons au lancement de fgfs.
modifier la propriété "switch" modifie également les propriétés qui en sont "dépendantes" (par exemple l'affichage sur le tableau de bord d'un interrupteur), je pensais donc créer une propriété qui n'avait pas d'incidence sur l'affichage (c'est pas parce qu'il n'y a pas assez de jus dans la batterie que l'interrupteur doit revenir à sa position "off", et le moteur doit continuer à faire "tuf tuf" ).
la valeur de "test" est vraie si la batterie dispose de suffisamment d'énergie pour alimenter le(s) équipement(s) en aval, "faux" dans le cas contraire. elle est utilisée via les "connectors" (exemple fictif):

  <connector>
    <input>Electrical Bus 1</input>
    <output>Cabin Lights Equipements</output>
    <switch>/controls/switches/cabin-lights</switch> <!-- interrupteur manuel -->
    <switch>/controls/test/cabin-lights</switch>  <!-- interrupteur logiciel "test" -->
    <switch>/controls/circuit-breaker/cabin-lights</switch> <!-- fusible -->
    <initial-state>off</initial-state>  <!-- état initial (optionnel, si non spécifié est "on") -->
  </connector>

pour que la sortie "Cabin Lights Equipements" soit alimentée, il faut que les trois switch soit vrais (ou différent de zéro).

en gros, il faudrait
1- déduire la conductance de chaque équipement
2- appliquer pour l'ensemble du circuit la conductance globale (uniquement pour les équipements sous tension)
3- déterminer qu'elle est la décharge sur la batterie (C-rate, nombre de peukert?)
4- calculer la charge restante sur la batterie, en tenant compte de son chargement éventuel par APU (alim externe) ou par les alternateurs.
5- vérifier que la charge restante sur la batterie est suffisante pour alimenter les équipements,
si oui: le switch "/controls/test/équipement" est vrai
si non: le switch "/controls/test/équipement" est faux -> l'équipement n'est plus alimenté
6- recommencer l'opération (une fois tous les dix frames pour ne pas trop gêner le reste de la simu)

également si l'équipement n'est plus alimenté il faudrait qu'il s'éteigne en vrai, ce qui n'est pas encore le cas. par exemple le tableau des NAV et COM ne s'éteint pas, et l'éclairage du tableau de bord est tout le temps allumé. hors justement ce qui est rigolo, c'est que si on a oublié de mettre l'interrupteur Master-Alt sur On, en plein vol de nuit au bout d'une demi-heure tout s'éteint! et à moins de connaitre parfaitement son tableau de bord les yeux fermés (ce qui est réellement demandé pour la certification "vol de nuit") ça devient très dur, voire impossible, de voir quoi que ce soit (horizon artificiel, altimètre, etc.) ce qui peut avoir de fâcheuses conséquences
pour cela il faudra toucher quelque chose que je ne connais pas encore. je pense que l'éclairage est géré par un masque rouge appliqué aux instruments, je ne l'ai pas encore trouvé.

l'alimentation externe (utile ?)

je pense que l'alim externe est utile si, par exemple, on fait payer via paypal le chargement de la batterie au sol avec tarif préférentiel pour les inscrits à ce forum

@+

teo · 16/04/2006 16:08:58

zakharov a écrit :

je pense que l'alim externe est utile si, par exemple, on fait payer via paypal le chargement de la batterie au sol avec tarif préférentiel pour les inscrits à ce forum

Ok, mais s'il faut payer, je veux une animation qui montre une personne qui vient avec sa station d'énergie, pour aider à démarrer
En fait, il faudrait également tenir compte de la date de dernière utilisation de l'avion pour prendre en compte l'autodécharge naturelle de la batterie lorsqu'elle n'est pas utilisée

a+

zakharov · 17/04/2006 3:01:45

salut teo!

bon, cette semaine j'ai pas eu trop de temps pour faire tout ce que je pensais faire. j'ai tenté d'implémenter des nouvelles fonctions nasal dans le code de flightgear:
- une pour modéliser la décharge de la batterie avec en paramètre l'ensemble des charges appliquées
- d'autres pour déterminer la charge d'un équipement en fonction de divers paramètres
- pour un autre projet (plandevol): des fonctions qui mettent à dispo via nasal des infos sur les aéroports et les navaids.
résultat: jusqu'à présent, y 'en a aucune qui marche (même ça compile pas du tout!!!). je vais devoir me plonger dans des bouquins de C/C++... les possibilités sont très très intéressantes.

l'objectif de passer par là est de proposer des fonctions dispos en plus de celles qui existent déjà et valables pour tous les appareils, en simplifiant l'écriture du script.

voili
@+

teo · 17/04/2006 9:26:58

Tout se trouve là. (nécessite un navigateur qui supporte le SVG.)

Page mise à jour avec le schéma du bus virtuel. Il faut également maintenant un navigateur compatible MathML (page de test).
(Testée uniquement avec firefox 1.5.0.2.)

zakharov · 18/04/2006 13:24:14

bien tout ça un peu compliqué pour moi mais bien...

sinon j'ai appris hier que je ne vais plus avoir une minute à moi avant le 13 mai, donc je ne pourrai pas continuer jusque là. j'ai demandé aux développeurs de bien vouloir m'implémenter les fonctions nasal que je n'ai pas réussi à coder. j'espère qu'ils le feront... comme ça dès le 14 mai on utilise les fonctions nasal toutes fraîches pour la gestion de la batterie, et on y applique tes avancées sur les calculs (quitte à remodifier le code pour les ajuster). ça devrait alors aller assez rapidement.

voili
@+ seb

Dernière modification par zakharov (18/04/2006 13:24:51)

teo · 19/04/2006 19:16:27

Salut,

Bon et bien tant pis, je vais continuer tranquillement en attendant, et si je ne peux plus avancer, j'ai d'autres projets en cours qui m'occuperont bien assez.

En plus au niveau de mes calculs, je bloque un peu, j'aurais aimé avoir une bonne grosse formule synthétique pour Uvb, mais la diode et le régulateur me gènent. Je vais probablement devoir ajouter quelques tests (ou changer de mode de calcul ?).

a+

teo · 14/05/2006 23:20:04

Hello,
La modification du circuit électrique ne pouvant pas se faire sans l'ajout au tableau de bord des boutons master-alt, master-bar et avionics-power, j'ai modifié le sélecteur de magnetos afin d'y intégrer ces trois interrupteurs.
Une copie d'écran et le fichier modifié ici : elec-c172p.xhtml.
Je ne l'ai testé qu'avec le cessna 172p, j'espère que ça ne posera pas de problème avec d'autres avions.

a+

teo · 15/05/2006 22:56:01

La modification du circuit électrique ne pouvant pas se faire sans l'ajout au tableau de bord des boutons master-alt, master-bar et avionics-power, j'ai modifié le sélecteur de magnetos afin d'y intégrer ces trois interrupteurs.

J'ai ajouté un fichier clic-inter.tgz qui permet de sonoriser ces trois interrupteurs (fortement inspiré du fichier Hunter/Sounds/hunter-sound.xml).

teo · 15/05/2006 23:05:27

zakharov a écrit :

également si l'équipement n'est plus alimenté il faudrait qu'il s'éteigne en vrai, ce qui n'est pas encore le cas. par exemple le tableau des NAV et COM ne s'éteint pas, et l'éclairage du tableau de bord est tout le temps allumé. hors justement ce qui est rigolo, c'est que si on a oublié de mettre l'interrupteur Master-Alt sur On, en plein vol de nuit au bout d'une demi-heure tout s'éteint! et à moins de connaitre parfaitement son tableau de bord les yeux fermés (ce qui est réellement demandé pour la certification "vol de nuit") ça devient très dur, voire impossible, de voir quoi que ce soit (horizon artificiel, altimètre, etc.) ce qui peut avoir de fâcheuses conséquences
pour cela il faudra toucher quelque chose que je ne connais pas encore. je pense que l'éclairage est géré par un masque rouge appliqué aux instruments, je ne l'ai pas encore trouvé.

Je viens de découvrir que lorsque master alt et master bat sont ouverts, le tableau de bord s'éteint (mais les équipements radio restent allumés).

a+

Forum Flightgear France

Annonce

#1 31/03/2006 20:06:02

projet: améliorer la gestion de l'électricité sur le c172

#2 1/04/2006 11:10:12

Re : projet: améliorer la gestion de l'électricité sur le c172

#3 2/04/2006 11:00:16

Re : projet: améliorer la gestion de l'électricité sur le c172

#4 3/04/2006 1:11:31

Re : projet: améliorer la gestion de l'électricité sur le c172

#5 4/04/2006 18:09:13

Re : projet: améliorer la gestion de l'électricité sur le c172

#6 5/04/2006 1:42:05

Re : projet: améliorer la gestion de l'électricité sur le c172

#7 6/04/2006 17:22:15

Re : projet: améliorer la gestion de l'électricité sur le c172

#8 7/04/2006 1:45:16

Re : projet: améliorer la gestion de l'électricité sur le c172

#9 9/04/2006 20:51:24

Re : projet: améliorer la gestion de l'électricité sur le c172

#10 9/04/2006 23:56:25

Re : projet: améliorer la gestion de l'électricité sur le c172

#11 16/04/2006 16:08:58

Re : projet: améliorer la gestion de l'électricité sur le c172

#12 17/04/2006 3:01:45

Re : projet: améliorer la gestion de l'électricité sur le c172

#13 17/04/2006 9:26:58

Re : projet: améliorer la gestion de l'électricité sur le c172

#14 18/04/2006 13:24:14

Re : projet: améliorer la gestion de l'électricité sur le c172

#15 19/04/2006 19:16:27

Re : projet: améliorer la gestion de l'électricité sur le c172

#16 14/05/2006 23:20:04

Re : projet: améliorer la gestion de l'électricité sur le c172

#17 15/05/2006 22:56:01

Re : projet: améliorer la gestion de l'électricité sur le c172

#18 15/05/2006 23:05:27

Re : projet: améliorer la gestion de l'électricité sur le c172

Pied de page des forums