Projet Cockpit A330

Je me demandais quelle était la raison, et après réflexion je pense que c'est pour une histoire de jonction entre les couleurs au niveau de la dérive qu'ils ont choisi cette disposition des couleurs.
Ainsi quand l'avion arrive de face, on verra le bleu des deux côtés de la dérive au lieu d'un rouge/bleu qui aurait fait bizarre.
La porte où débarque le président étant de toutes façons toujours l'avant gauche, ce qui est important c'est que les couleurs du drapeau soient dans le bon sens pour la photo/TV quand l'avion est vu de bâbord. Comme on le voit sur ta dernière photo.
 
Je pense que tous les aeronefs (avions, hélicoptères…) militaires portent le drapeau inversé du côté droit. J’utilise à dessein le terme ‘drapeau’ (la dérive est vue comme un drapeau). La raison n’est pas la jonction des couleurs.

exemple : dérive des A400M (même le drapeau turc avec son croissant est inversé)
 
Bonjour tous le monde,

Ca avance doucement, mais avec l'assemblage actuel je me rends compte que de quelques problème , surtout concernant les écrans CPT / FO (beaucoup trop grand c est du 20'' j'ai eu du mal a me procurer plus petit avec HDMI)

Donc les écrans vont être déposés puis remplacer par des dalles 15.6 '' avec leurs carte de contrôleur [ie hdmi ] comme il sera fait pour les écrans ecams.

Les écrans 27'' (vue principale sur bras) me semble petit maintenant

Les barres de fenêtre blanches qui apparaissent sur les écrans PFD et ND sont du au fait que je ne peux pas remonter suffisamment les écrans (problème qui sera résolus avec les dalles 15.6'')

IMG_20221106_220200.jpg


Du coup les écrans étant quand même fonctionnel j'ai pus me remettre à l'écriture du plugin de communication avec mon hardware.

@ bientôt

David
 
Bonjour tous le monde,

Je n'ai pas de grosse nouvelles à donner en ce moment, c'est plutôt un pétage de câble ...
Coté structure , rien n'a vraiment bougé pour le moment, le minimum syndicale a été fait pour pouvoir voler sur le simu, et je me suis mis au boulot pour écrire le plugin X-Plane <=> hardware. Juste pour rappel il s'agit de carte I/O totalement maison (design et conception) sur une base Raspberry PI.

Que je vous explique, la première étape a déjà été franchie il y a quelques semaine, la communication entre le simu et le hardware est opérationnelle, je récupère les infos du simu et j'arrive à en envoyer.
IMG_20221202_154721.jpg

La ou je commence sérieusement a devenir dingue c'est finalement d'arriver a déterminer quelles dataref il faut employer ....
Les référence / docs sont vraiment pas claires, voir inexistante. Autant trouver celle à interroger pour les les valeurs sont plus ou moins facile a trouver , autant celle qui détermine le comportant de l'affichage peut vous faire sombrer dans la folie :poop:... Et pourtant je me sert du plugin datareftool

je viens de trouver après plusieurs jours de recherche les "xxx_window_open" planqués dans l'abro du 330 et pas de l'arbo générique du PA (cockpit/autopilot ou cockpit2/autopilot)

Bref j'ai un peu l'impression de stagner en ce moment et d'avancer a pas de fourmis ... :(

Accéder au coeur du simu n'a pas été si compliqué que ca, c'est plutôt pas mal documenté de ce coté la , mais parvenir a se mettre dans la tête du gas qui a pondus la logique de gestion, c est une autre histoire :LOL:

Je vois la fin de l'année arriver à grand pas et je me dis que j'ai encore pas mal de boulot

Je voudrais arriver a quelques chose de stable afin de pouvoir définitivement publier les plans, les pcb et le plugin (tous ça en full open source / open hardware)

@ bientôt

David
 
Bonjour tous le monde,

Voila un moment que je ne suis pas passé.

J'ai finalisé de façon stable et fiable la communication entre le hardware et le simulateur.

J'ai besoin d'un petit coup de main pour la suite. Je cherche le moyen de déterminé quelle "action" est effectué quand on appuis sur un bouton dans le cockpit.

Pour exemple, comment puis déterminer ce qui se passe lorsque je pousse le bouton KTS/MCH sur le FCU du A330-300 (bascule de l'affichage de la vitesse entre MACH et KNOTS). Est ce l'action modifie directement des DataRef ou bien est ce qu'une commande est exécuté.

Comment le liens entre l'objets 3D et l'action dans le simu est constitué ?

Est ce que cette information est trouvable dans le planemaker ?

Le DataRefTools ne semble pas répondre a mes besoin [ ou ce qui est probablement le cas je ne sais pas correctement m'en servir ], trop de chose reste affiché, je n'arrive pas a déterminer ce qui est vraiment déclenché.

D'avance merci

David
 
Bonjour tous le monde,

Voila un moment que je ne suis pas passé.

J'ai finalisé de façon stable et fiable la communication entre le hardware et le simulateur.

J'ai besoin d'un petit coup de main pour la suite. Je cherche le moyen de déterminé quelle "action" est effectué quand on appuis sur un bouton dans le cockpit.

Pour exemple, comment puis déterminer ce qui se passe lorsque je pousse le bouton KTS/MCH sur le FCU du A330-300 (bascule de l'affichage de la vitesse entre MACH et KNOTS). Est ce l'action modifie directement des DataRef ou bien est ce qu'une commande est exécuté.

Comment le liens entre l'objets 3D et l'action dans le simu est constitué ?

Est ce que cette information est trouvable dans le planemaker ?

Le DataRefTools ne semble pas répondre a mes besoin [ ou ce qui est probablement le cas je ne sais pas correctement m'en servir ], trop de chose reste affiché, je n'arrive pas a déterminer ce qui est vraiment déclenché.

D'avance merci

David
Salut David
1678052834259.jpeg

Tu coches CH pour n'avoir que les changements daratarefs et les commandes (D+C)
Si tu mets un mot dans le champs de recherche , tu n'auras que les paramètres qui concernent ce mot
engine , lights , brake par exemple .
Si tu actionnes un switch directement dans le cockpit 3D , tu dois voir la/les commande (s) générée (s) avec sa/ses dararef (s) associée (s)
 
Bonjour Frederic,

Merci pour les précisions, c'est plutôt comme ca que je m en sert, mais j ai toujours des dizaines de ligne en changement permanent qui restent (je ferais une capture d'écran).
Après mon message d hier soir, j ai continuer a fouiller, et j ai finis par trouver des choses dans les fichier 3D (les .obj) on y retrouve des Dref et des Commandes :

Par exemple pour le bouton bascule entre l'affichage MCH / KTS, dans le fichier .obj (A330_cockpit.obj) on retrouve la section suivante :

ANIM_begin
ANIM_trans -0.11846 0.85615999 1.90008 -0.11846 0.85615999 1.90008
ANIM_rotate 1 0 0 161.99981 161.99981
ANIM_trans_begin laminar/A333/autopilot/spd_mach_pos
ANIM_trans_key 0 0 0 -0
ANIM_trans_key 1 0 0 0.0024999999
ANIM_trans_end
ATTR_manip_command button sim/autopilot/knots_mach_toggle Knots MACH toggle
TRIS 60153 72
ANIM_end

Je n'ai pas encore tous ingérer mais il semble que ce soit bien la commande sim/autopilot/knots_mach_toggle qui soit exécuté (et pas la modification des Dref directement)

Je n'arrive pas a me servir d'AC3D, du coup j ouvre les .obj dans blender, mais il semble que je perde des choses au passage à l import ... :)

Bon en tous cas ca devrais me permettre d'avancer ...

Merci

David
 
Bonjour, petite précision sur le drapeau qui est sur la dérive. Il faut imaginer que le début de la dérive est un mat ou flotte un drapeau.
 
Bonsoir tous le monde,

Quelques news.

Après avoir bataillé dans tous les sens avec X-Plane, je suis enfin arrivé a une solution acceptable. C'est pas encore parfait mais ça fait vraiment le job
Il y a encore quelques config d'affichage a gérer (mais c est de la pure configuration au niveau de l'interface) comme par exemple la vitesse verticale qui s'affiche avec deux petit 0. Il faut aussi que je remplace le digit 5 pour un afficheur "+/-" mais voila, le principe est fonctionnel.
Comme on peut le voir dans la vidéo il y a des chose surprenante mais ca ne vient pas de mon système (par exemple le AP1 qui ne s'enclenche pas même a la souris ... )

Le FCU est conçus autour d'un Raspberry Pi, toutes les communications avec le simulateur se font à travers le réseau ip.
Un plugin Python gère un serveur TCP coté X-Plane et transmet les données du simulateur vers l'interface.
Les commandes de l'interface sont envoyé directement à X-Plane via le canal UDP



@ plus

David
 
Dernière édition:
@daweed , bravo , tu es fort et persévérant !

Laminar met le paquet pour améliorer l'A330 , il ne faut pas hésiter à leur poser des questions si tu as des soucis !
 
Pour le problème des afficheurs, il y a cette solution absolument brillante.
FCU display from KAV Simulations

 
Salut Jackz,

je suis déjà équipé, :LOL:
En plus cette pièce m'a été gentiment été offerte. L'afficheur communique via le bus SPI , alors que toute ma solution est basé sur l autre bus du Rpi (i2c) il me faudra donc écrire un nouveau driver .... :sneaky:

j'ai juste pas encore eu le temps de mettre en oeuvre la chose, la priorité était de stabiliser parfaitement les communications entre les interfaces et le simu.
Maintenant que c'est fait, je vais laisser un peu de coté la prog et le développement et reprendre la construction [ et j'ai un retard ... pfff une horreur :ROFLMAO: ]

Les PCB sont en cours de refonte (déjà la 4 ieme version), l'écran sera intégré cette prochaine version ... voila voila

fcu_display.jpg



David
 
Pour le problème des afficheurs, il y a cette solution absolument brillante.
FCU display from KAV Simulations


En plus de cela il semble que cela correspond à une réalité : il y a une différence dans la technologie d'affichage entre le FCU et les EFIS sur l'OEM [LCD / Led] ...... Pour un prix tres raisonné . 👍
 
Je ne m'attache qu'au visuel et a la cosmétique dans mon commentaire ... Arduino pas connaitre excepté que c'est un micro controleur prêt à l'emploi .... Je crois ??? 😟
 
j'ai eu ma réponse depuis ..en effet arduino et programmation mobiflight.

comme d'hab ca doit etre galere avec le Fenix à mon avis !
 
En plus de cela il semble que cela correspond à une réalité : il y a une différence dans la technologie d'affichage entre le FCU et les EFIS sur l'OEM [LCD / Led] ...... Pour un prix tres raisonné . 👍
Sur le "Vrai" c'est de la technologie LCD avec un filtre polarisant inversé, comme sur certaines calculatrices ou radio réveil, où on laisse passer la lumière à l'endroit des chiffres et du texte et on opacifie tout le reste. Du coup on a une netteté des chiffres et du texte sans équivalent avec de la LED.
 
Bonjour,
Quelqu'un sait ce qu'il est advenus du site www.homecockpits.fr ?
Je voulais envoyer une demande de cotation pour des panels perso mais le site semble offline.
Je précise que internet fonctionne bien a la maison, j'ai essayé de joindre le site web avec plusieurs navigateur et que à chaque fois quelque soit le navigateur mais je prends l'erreur suivante :

www.homecockpits.fr n'autorise pas la connexion.


Voici quelques conseils :
ERR_CONNECTION_REFUSED

Est ce que va fait pareil chez vous ?

D'avance merci
 
C’est juste un indicateur (lumière ambre) qui indique que l´affichage actuel sur une des radios est différent de celui du RMP en service.

Exemple: le bouton VHF1 est sélectionné sur le RMP2 (côté copi) qui contrôle normalement la VHF2 —> SEL s’allume sur les trois RMP à la fois. Ça marche de l’autre côté aussi.

On l’utilise tout le temps car VHF2 est normalement réservé à la veille 121.5 en croisière et pour prendre l’ATIS. Donc le copi s’il est PM doit changer les fréquences sur VHF1. Et on ne doit pas interférer avec le RMP côté opposé surtout si le PF a la main sur les gaz en approche par exemple.

Extrait FCOM
1687623113766.png
 
?!?!?!?!?
Le domaine homecockpits.fr existe depuis un moment est n'est pas sensé être disponible à la vente :oops:
 
J’ai toujours pas compris le rapport avec la question initiale????
Franck de HC est en pleine forme aux dernières nouvelles!
 
@albesoft a pris ce virage, en postant je ne sais pas pourquoi ce message, probablement qu'en lien avec ce sujet il a voulu aller sur HC.
Message laconique s'il en est, je comprends maintenant que c'est le message qu'il a du voir en s'y rendant. Moi j'ai cru qu'il avait pu acheter le domaine ce que je ne comprenais pas. Ensuite ca a suivi les rails que j'ai placé 😅
 
Retour
Haut