Reprise du message précédent :
Sympa en effet.

Tu as déjà pensé à la base afin que cela reste en place quand tu tripoteras les bitonniaux ? Avec un vis de serrage comme la plupart des yokes ou plutôt avec un poids au-dessus type écran ?

J'avais pensé à une boîte en medium, avec l'écran posé dessus, oui ; ou alors la boîte calée devant.
 
Ce soir j'ai branché le second MAX, et un nouveau set de displays. Ca commence à faire beaucoup de fils
 

Ça rend propre l'enduit... C'est un enduit particulier ? Genre résine ou autre ?

Faut que je reprenne mon projet et que j'organise correctement boutons et rotateurs.

Mais le fait de devoir programmer une accélération ça a ralenti le projet  

Je posterai mon code si tu veux pour l'accélération et tout (vu que je vise aussi X-Plane).

Dernièrement, mes test ça a été juste de brancher deux encodeurs + une teensy sur une breadboard.

Donc ça marche, je simule bien mes doubles encodeur pour chaque encodeur physique en utilisant le bouton poussoir que possède chaque composant. Donc nickel de ce côté.

Ce qui m'embête en ce moment, c'est que je vise surtout le marchetti sf260, et j'ai pas vu dans les paramètres de X-Plane une option pour mapper à un bouton les fréquences sur les instruments que je voulais manipuler. J'ai juste vu une option pour permuter entre la fréquence active et celle en attente et ça se limite un peu à ça.

Il y a bien les paramètres pour mapper un bouton sur le réglage des fréquences nav 1 et co. qui marchent, mais ça va sur le realty XP gns et pas les KX 165 navcom & KR87 ADF Receiver comme j'aurai voulu

Donc faut peut-être que je passe par la bibliothèque flightsimconnect et passer par les xref et co. Mais ça m'embête de faire du code spécifique à X-Plane. J'aurai aimé une boîte à boutons qui envois des événements générique. Bref, faut que je creuse.

Sinon j'ai aussi essayé de brancher mon petit écran OLED, mais ça marche pas encore. Sur les pattes du teensy ça sort que du 3.3V, et les infos de l'écran disent qu'il faut du 5V. J'avais tenté car sur le net je voyais que ça pouvait marcher quand même, mais non...

C'est pas vraiment un problème car la carte teensy a une prise 5V, mais faut que je soude une patte, et je l'ai pas encore fait. A suivre.

Voilà où j'en suis

 
C'est un enduit gras (enduit laque). Il faut le poser en fine couche (sinon ça ne sèche pas), et une fois poncé finement, si on s'applique bien (ce qui n'est pas le cas ici ), ça laisse une surface parfaitement lisse.
 
J'ai de mon côté fini de branché les écrans, tout fonctionne bien, mis à part certains faux contacts qui font que de temps à autres, certains displays s'éteignent carrément. Voilà qui va me pousser à faire une V2 sur PCB  
 
Je passe aux codeurs mécaniques et aux switches, qu'il va falloir connecter proprement maintenant. Ils occuperont un seul MCP23017, un second sera dédié aux poussoirs.
 

 
A mon avis, faire un truc générique, c'est mort ; à moins de faire du hardware générique et faire un software spécifique par application qui va faire le pont au milieu.

Oui, ça risque de finir comme ça...  
 
Sinon, petite question, vu que j'ai prévu plein de boutons. J'ai vu que pour le multiplexage je pouvais utiliser un 74HCT4051.  
cf:

(Mais avec un 74HCT4051 et pas 74HC4051)
 
Mais je trouve plein de variantes en ligne 74HCT4051N, 74HCT4051E, ...
https://www.alldatasheet.com/view_d [...] 74HCT4051E
 
Ils sont tous fonctionnellement pareil?  /noob

J'aurais tendance à dire que oui, la seule différence se situant au niveau du format de boitier.
 
https://assets.nexperia.com/documen [...] CT4051.pdf page 2

Ah ok, merci

 
Comme ça on dirait pas, mais j'ai bien nettoyé le câblage

Un peu d'explications :
 

• La grande plaque au fond (à recouper) sert à l'alimentation : une ligne Vcc, une ligne GND
• Il y a 3 plaques avec chacune un MAX dessus. Pour chacune de ces plaques, on a 8 fils qui partent chacun vers 1 digit
• De ces plaques partent aussi 8 fils pour chaque segment (7 + le point décimal) vers une carte fille. Cette carte fille permet de redistribuer en parallèle les segments vers les afficheurs (les nappes arc-en-ciel)
• Il y a également une carte fille qui gère l'alimentation de chacun des MAX (les condos de filtrage, la résistance Rset, et ce pour chaque MAX)
• Enfin, il y a une dernière carte fille qui permet de mettre en parallèle les lignes CLK et CS à partir de l'Arduino

J’ai branché les 6 codeurs, et ... ça déconne.
 
En vrai ça marche, mais l’utilisation est laborieuse, tantôt ça avance, tantôt ça recule alors que je ne fais tourner qu’un bouton toujours dans le même sens.
 
Je pense que ça « rame » du fait que ça scanne pour les 6 roues à chaque runloop a travers le bus I2C.
 
Je pourrais utiliser les interruptions, mais ça demanderait une grosse refacto du code pour réussir à recoller entre le pin qui a reçu l’interruption et la structure de codeur dans le code, qui est l’objet qui sait quel est l’événement à envoyer.
 
Du coup je pense que je vais me coder mon système « d’interruption » dans lequel je vais surveiller tous les encodeurs, mais n’en écouter ensuite qu’un seul quand il sera mis en action, jusqu’à ce qu’il ne soit plus utilisé pendant un certain temps, genre 50ms, ça devrait le faire.

Bon bah c'est implémenté, mais le résultat reste le même Ca déconne surtout dans le sens inverse des aiguilles d'une montre, étrange.

 
Preneur si tu as le courage j'ai pas trop le temps d'apprendre la progra pour le moment.
 

 
Étrange ce comportement. Ca se reproduit sur tt les rotateurs? Problèmes de branchement? Si tu enlèves  du circuit des touches ça se produit toujours?

Oui, tous les encodeurs.
 
Et même si, au final, je n'en connecte qu'un seul tout seul directement à l'Arduino. Le changement ? J'ai mis un bouton sur les encodeurs, donc j'ai une meilleure prise en main, donc je peux les tourner plus vite que lors de mes précédents tests

Problème réglé, et ma première intuition était la bonne : y'a un truc qui fait ramer l'Arduino et qui fout la merde dans le comptage des crans. Et le coupable est ... les afficheurs ! Je mettais à jour toutes les valeurs à chaque fois que je bougeait un encodeur, maintenant je mets à jour uniquement la valeur qui a bougé, et c'est bien mieux.
 
J'en ai profité pour réimplémenter la gestion des codeurs, en pompant honteusement sur le net, et les "mauvais sens" sont maintenant très rares. C'est largement utilisable !

Et la vidéo kivabien : https://www.youtube.com/watch?v=n8F8eUKqGD8
 
Dans l'ordre je bouge le cap (visible sur l'écran de droite), la course (pas de retour sur cette vue), la vitesse (bandeau de gauche sur l'écran de gauche), l'altitude (bandeau de droite sur l'écran de gauche) et la vitesse verticale (on peut voir l'avion plonger sur le bandeau de gauche sur l'écran de gauche avant que je recentre la vue sur le MCP virtuel)
 
EDIT : on doit aussi les quelques faux contacts sur les displays

Bah oui, si tu lis les codeurs avec une fréquence trop basse tu vas rater des tours ou avoir des trucs éronnés. Voir théorème Nyquist-Shannon toussa.

Nickel

Et c'est cool les retours, ça pourra nous servir à identifier les problèmes sur nos montages

c'est plus réaliste comme ça, après tout c'est un boeing
 
Super boulot au passage

 
Hier j'ai câblé les 4 switches, et là je suis en train de monter les boutons. Une fois câblés, il ne restera "plus" que les différentes LED d'état, et un boîtier !

Up,
 
J'ai câblé 16 boutons sur 17 sur un MCP. Le 17ième viendra sur un troisième MCP, qui me servira également de sortie pour les annonciateurs (les LED sur le boutons), ce qui fera 15 broches utilisées sur le MCP sur 16.
 
Il restera 3 LEDs en façade à câbler, je pensais les mettre en direct sur l'Arduino.
 
EDIT : du coup, j'ai réalisé mon premier atterrissage sans regarder dehors, juste en ayant les 2 écrans principaux de l'avion sous les yeux, et sans aller voir le MCP virtuel

 

 
Ca devient sacrément bordélique

Conseil : pistolet à colle sur tes fils de protos une fois testé.
Et groupe tes câbles avec de la gaine thermo.

Yep, je pistocolle déjà un peu (on peut le voir sur les connecteurs des afficheurs), mais je vais en mettre plus je pense.
 
J’ai pas de gaine thermo, mais je viens de me souvenir que j’ai plein de rislans ; je vais grouper avec

Pas sur de comprendre l'usage du pistocolle? Juste pour l'organisation des câbles ?

La gaine thermo j'en met partout par contre  

Pour sécuriser, les fils protos ont tendance à se débrancher facilement après quelques utilisations.  
 
Un autre conseil : remplacer les fils protos qui semblent fragiles (longs/exposés/contraintes/...) par du multibrins/silicone genre : https://www.amazon.fr/gp/product/B0 [...] UTF8&psc=1
 
Conditionnement ultra pratique.
edit : gaffe à la taille.

Oui, ça j'en utilise (les blancs, bleus et jaunes qu'on voit sur la photo, les premiers reliant les boutons, les 2 autres les encodeurs aux MCP)

 
Ca me semble pas mal
 
Les LED F/D et A/T Arm ne sont pas câblées, et les 4 de droite, qui commandent l'activation ou non du pilote automatique, sont mal mappées dans mon code. Mais sinon ça tourne !

Premier vol managé bouclé. Un seul oubli dans le code : un event est envoyé lorsque la lnav entre en piste pour couper l'affichage de la vitesse cible. J'ai implémenté ça en cours de vol
 
Il en reste plus qu'à câbler les LED F/D et A/T arm, et à faire un boitier pour y coller tout ce bazar

Chapeau l'artiste

   
 
Ça a l'air nickel
 
 
Sinon ça a même pas l'air bordélique derrière

Très chouette.

Merci ! Je suis moi-même épaté d’être allé aussi loin
 
Merci aux vacances qui m’on permis d’avancer rapidement quand même

Moi j'dis... un p'tit PDF avec un howto pour la communauté et ce serait parfait    
 
Très sympa en tout cas !  

Oui, je termine le bousin et je pense que je vais prendre un peu de temps pour compiler quelques infos

à ton aise hein, profites-en avant !