DIY GnuVario : variomètre opensource - openhardware Arduino

Heureusement, j’avais le casque sur la tête :mdr:
j’ai pensé la même chose que toi, mais par x5 pour commencer.

Pas de bobo, juste l’égo qui en a pris un bon coup :roll:
j’ai trouvé ma limite, bonne leçon … pas chère payée (5€)
Si Nicolas di Bernardo me lit, il va rigoler en se rappelant de bons souvenirs de poilades de mes débuts sur ce déco en plein venturi

Salut à tous

je viens de mettre à jours le github, vous trouverez la version 63.5 dans la branche jpg63. Elle reprend l’ensemble des modifications de Prunkdump

Bon vol

Il s’agit bien d’un comportement anormal, puisque le retournement en question n’était pas particulièrement rapide. En tout cas, le même retournement n’ entraîne pas la même conséquence selon le firm. Le taux de descente affiché et traduit sonorement est même pas de +/- 1 m/s alors qu’il est d’une valeur proche de -5m/s qui revient à 0 au bout de 2 à 3 secondes.

Salut francoish,

As tu refait la calibration récemment? Je pense que ça mérite de la refaire et refaire le test.

PS : bravo baptiste pour l’optimisation de la librairie baro !

Ce que dit François est plausible car on peut choisir la sensibilité des gyroscopes.

Si pour une raison qui m’est inconnue elle n’est pas celle qu’attend le DMP dans la nouvelle librairie il peut y avoir des erreurs en rotation.

La calibration ne joue qu’en translation.

Ce n’est pas dramatique mais c’est à étudier …

Salut ptikiki,

Non, aucune calibration faite jusqu’à maintenant.

je confirme que si on bascule le vario, il n’aime pas ça, il beep comme pour une dégueulante pendant 1 à 2 sec. Cela se produit si on le met d’un coup la tête en bas ou en haut, ou à gauche ou à droite sachant que ça position initiale est droit écran vers l’avant, fixation sur élévateur. A part pendant des manœuvre extrême je ne pense pas que le vario puisse passer par c’est position aussi vite en vol

Un grand merci pour les tests ! :pouce:

Effectivement François avait raison. Il y a clairement un problème (j’ai testé moi aussi avec le MPU tout seul).

J’ai trouvé la solution. J’avais confondu le sample rate du dmp (100 calculs par seconde) et le sample rate des appareils de mesure (il devait être à 200 par seconde, j’avais mis comme le dmp à 100 par seconde).

Le temps de corriger le code et je publie ça ce soir ! :wink:

A+

Voilà c’est en ligne avec le bug corrigé !

Mettez à jour vos GnuVario.

https://github.com/prunkdump/arduino-variometer

Pour ceux interessé, je peux vous envoyer la version de Jpg63 à jour.

A+

Salut,

je viens de mettre à jours la version 63.5 avec le connectif du bug des accéléromètres sur le github

Désolé Jpg63 mais j’ai encore corrigé quelques bugs :? En tout cas tu dois avoir beau temps pour voler :pouce:

Tu veux que je te fasse le merge pour toi ?

Donc j’ai pu vérifier avec un GnuVario que l’on m’a prêté : La dernière version de la bibliothèque ne corrige pas le problème du vario qui ne démarre pas :frowning: Du coup j’ai fait quelques tests pour cette histoire de délais. J’ai enlevé complètement les délais et j’ai mis l’initialisation de l’accéléromètre tout au début.

-> J’ai testé des dizaines de fois le démarrage et aucun problème :grat: Ca démarre instantanément. Du coup je me suis dis que le délai n’avais rien à voir…

-> Puis j’ai laissé le vario “reposer” quelques heures. Et là impossible de le démarrer :shock: Même avec la technique d’allumage/extinction successives.

-> J’ai remis 2 secondes de délai au démarrage du code et là ça à remarché. Donc je me suis re-dis que le delais était important :wink:

Du coup voilà ce que je pense qu’il se passe. Lorsque le MPU a été bien itialisé une fois, le code du firmware reste un peu en mémoire du MPU grâce à l’énergie stocké dans les condensateurs. Donc lorsqu’on le rallume, même si l’initialisation se passe mal, ça marche quand même car le code du MPU est bon.

Au bout d’un certain temps de repos, il n’y a plus assez d’énergie et le firmware du MPU s’efface. Et du coup cette fois, si l’initialisation se passe mal et bin ça ne démarre pas.

Du coup je me suis dis que le problème de la carte SD était peut-être le même. Il est mis trop tôt dans le code et la carte SD n’a pas encore démarré. Du coup :

-> J’ai enlevé tous les délais de chaque bibliothèques.
-> J’ai ajouté un gros délai de deux seconde au démarrage.

On verra si cela résout les problèmes :smiley:

A+

Salut,

Mon vario sur breadboard pour les mesures de conso a exactement ce pbm! (Demarrage trés aléatoire, et surtout démarrage " à chaud " ok, puis à nouveau totalement aléatoire (parfois + de 20 fois pour rien) après “refroidissement”

Je n’avais pas voulu t’embêter avec ça Baptiste, car je pensais que c’était mon montage qui avait un faux contact scélérat… Content de savoir que c’est un bug et surtout qu’il est en voie de résolution, car c’est vraiment bien embêtant! Je vais tester avec le nouveau firm, je te dis quoi.

A+

:grat: comment vous expliquez que je n’ai jamais eu ce problème ???
même pas une fois :grat: :grat:

Possible que les clones chinois d’arduino que nous utilisons ne soient pas tous rigoureusement identiques, en particulier sur les fréquences de CPU, induisant ces comportements aléatoire lors de l’initialisation ?

Salut :coucou:

Oui c’est aussi ce que je pense. De plus j’ai l’impression que :
-> plus l’alimentation à une bonne capacité (batterie bien chargée, plus grosse batterie, alimentation externe…)
-> plus le problème apparaît car la carte arduino démarre plus vite et a une fréquence plus élevée (la fréquence dépend de la tension)

C’est peut être pour ça que le problème se produit beaucoup plus sur les nouveau kits à cause de la plus grosse batterie. Il y aussi la taille des condensateurs. Plus il sont en nombre et gros plus l’ensemble du circuit met de temps à se mettre en tension. Peut être que cela fini par faire de gros écarts dans la séquence de démarrage.

l’idéal ça serait de trouver une carte avec un bon régulateur 3.3V pour batterie LIPO qui peut envoyer au moins 300mA. Et une puce de charge intégré si possible. Mais malheureusement pour l’instant je n’ai pas trouvé ça pas cher. Sparkfun et Polulu en font mais a des prix très élevés.

Si on trouvait ça on pourrait virer tous les régulateurs de toutes les autres cartes et on gagnerait énormément en autonomie et en stabilité du systême.

Il faut bien comprendre en plus que si le régulateur du baromètre par exemple sort du 3.0V et celui de l’arduino du 3.3V. Il y a en plus 0.3V de “consommation” sur chaque pin connecté… En plus de la perte induite par chaque régulateur.

J’espère que le délai au démarrage vas résoudre le problème :?

A+

On a un temps magnifique, jusqu’à mardi, je veux bien que tu mettes à jours le github, comme ça tout le monde pourra profiter de tes dernières modifs

Je confirme le problème de démarrage. J’ai les 2 version. J’ai prêté la version 1 à un copain. Sur la version 1, je constate juste un problème pour mettre à jour le vario quand il est resté longtemps éteint (je n’avais jamais eu le problème avec l’ancien code), le mpu ne s’initialise pas bien, il ne détecte pas pas que le vario est la tête en bas et ne bip pas. Les nouvelles bibliothèques démarre peu être plus vite et du coup on a le problème, qui n’existait pas avant.

Je vais essayé de trouver un peu de temps pour faire la dernière mise à jours qui devrait réglé ce petit problème

Sur la version 2 effectivement le problème est beaucoup plus flagrant et empêche le démarrage. La aussi je vais essayer de faire la mise à jours pour confirmer avant de rentrer

Hier en fin d’aprèm on a fait un bi avec ma compagne on a pu tester le gnuvario V2 en parallèle avec un syride. Plus simple quant on pilote pas. Je pense qu’il serait judicieux de baisser les déguelantes à -2.5 enfin c’est que je vais faire car on a trop souvent le bip de descente, normal quant on voit le site de st andré, foret et gros pierrier, même avec des thermiques plus faible je trouve que le vario déclenche un peu trop en descente. Pour la monté on est assez bien en phase. Je n’ai pas mis le zérotage sur le gnu il est activé sur mon syride mais on pouvait constaté la synchro dès qu’on était dans les thermiques

Notre vario se comporte très bien en vol, par contre le miens a toujours un soucis avec la SDcard, tout les vols ne se sont pas pas enregistré, surement une vilaine soudure :bang:

Nette amélioration pour mon v2, cela semble résoudre les non démarrages avec carte SD. Il démarre maintenant à tous les coups aussi bien à l’endroit que à l’envers :bravo: :jump: .

Je pars voler tout à l’heure, je vais sûrement pouvoir essayer véritablement.

Je reviens sur les bips qui apparaissent lorsque l’on passe de la position à l’endroit vers à l’envers: un peu de bips puisque la valeur du vario devient différente de zéro. Rien de grave, d’autant que cette situation ne nous arrive pas vraiment en vol.
Ce qui me surprend, c’est que tous les autres changements de positions (rotation sur lui même sans changer d’elevation) n’entrainent pas de bip; cela concerne uniquement le passage de endroit vers envers. Avez-vous une idée ?

Moi j’ai fait la maj il y a deux jour (avec mon v1).
Pas de soucis en fonctionnement courant.
Par contre j’ai de plus en plus de mal avec la mise en place d’un nouveau firm.
J’ai bien les 3 bip grave quand il est à l’envers, mais le démarrage d’apres est compliqué.
J’avais conclu à un pb de mon boot loader parce qu’en faisant un C.C. sur les pins du reset (que j’ai dessoudé), ça marche. C’est peut être lié.
J’avais commencé à intégrer tous les composants sur un seul pcb mais cette histoire de regulateur m’a un peu calmé (et aussi les contrôleurs i2c/spi des Shield :? )
Point de détail : mon écran semble être comme rafraîchi toutes les 2 - 3 secondes: s’eteint une toute petite fraction de seconde puis se rallume.
Et autre chose, est ce qu’on peut régler le moyenage de la finesse ? Sa variation est un peu rapide a mon goût. A moins qu’on aie déjà le paramètre dans variosettings ?

Salut,

J’ai tésté aussi la derniére version du Github sur ma platine d’essai.
Malheureusement, démarrage toujours aléatoire à froid. (peut-être un peu moins de tentatives nécessaire, à confirmer), par contre, la valeur du vario fait n’importe quoi.
Le vario se remet à marcher correctement (hormis la fiabilité du démarrage) avec la version précédente…
Voilou, désolé Baptiste !

Salut :coucou:

Je vous ai préparé une petite suprise :smiley:

-> Chargez le firmware en pièce jointe sur votre vario.
-> Alumez le et attendez qu’il démarre.
-> Tapez lui dessus !!! ( :shock: si ! si ! :wink: )

Amusez vous bien ! :trinq:

Je m’occupe bientôt de vos soucis de démarrage :pouce: