DIY GnuVario : variomètre opensource - openhardware Arduino

[prunkdump]

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

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    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    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  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

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

A+

[ptitkiki]

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+

[Van Hurlu]

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

[ptitkiki]

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 ?

[prunkdump]

Salut 

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+

[jpg63]

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

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    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    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  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

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

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   

[francoish]

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    .

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 ?

[GtD73]

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 ?

[ptitkiki]

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 !

[prunkdump]

Salut  

Je vous ai préparé une petite suprise  

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

Amusez vous bien !  

Je m'occupe bientôt de vos soucis de démarrage    

[whistler]

Popooooooooooooop!!   Bravo Prunkdump! Tellement utile, je vais enfin pouvoir faire des tests au bureau discrètement .

Concernant les problèmes de démarrage, j'ai eu pas mal de soucis ces 2 dernières semaines, du coup j'ai imprimer la pièce du milieu du boitier en 3D afin de moins forcer à la fermeture et depuis le démarrage à chaud ou à froid s'effectue parfaitement à 100%.
J'espère pouvoir faire mes premières traces ce week end!
D'ailleurs concernant la pièce je ne trouve plus le post. mais bravo à celui qui l'a modélisé (et je suis preneur du fichier original pour faire des motifs si possible ;D)

[josecarbon]

super!
1 coup vol 0
2 coups vol 1
3 coups vol 2
...Non?

[jpg63]

Salut,

de retour, je rajouterais par rapport au problème de démarrage, que j'ai constaté 2 cas bizarre sur mon V2. Dans certain cas, le démarrage se passe bien mais le vario passe par une valeur totalement énorme qui dépasse l'affichage puis se stabilise et un deuxième cas ou l'écran se coupe après un moment, on a les bips mais dès que l'on essai de redémarrer le vario, grosse galère, plus rien ni même les bips de mise à jour. En le laissant quelques minutes éteint, il finit par redémarrer.

Je constate aussi sur ma V1 un problème aléatoire d'enregistrement sur la carte SD qui n'existé pas avec la précédente version (avant les nouvelles bibliothèques) et j'ai l'impression mais la rien de sur, c'est très subjectif, que le fix du GPS est plus long

Pour les utilisateur de ma version, je vous dépose rapidement le code sur le github

[prunkdump]

Salut Jpg63 ! 

Ouai désolé j'ai pas eut le temps de mettre à jour ta branche. J'espère qu'il n'y aura pas trop d'adaptation à faire... A part l'organisation de l'écran je ne pense pas qu'il y ait trop de difficultés.

Il me tarde de trouver d'où viennent ces problèmes de démarrages !!! C'est vraiment très étrange !

Surtout que sur le GnuVario que l'on m'a passé (qui avait lui aussi les deux problèmes : carte SD + démarrage après repos) le mise à jour vers le dernier firmware a résolu les deux problèmes ! En tout cas je n'ai pas constaté une seule fois le problème depuis.

Une fois que tous le monde auras mis à jour son firmware. On feras un fichier relevant les problèmes constatés. Peut être que ça nous éclairera sur leur origine. Ou du moi nous donnera des pistes. Je ne sais toujours pas si c'est logiciel ou matériel, ou les deux ? ...


A+

[josecarbon]

Il semblerait que pour moi aussi la mise à jour ai résolu les deux problèmes 

[Van Hurlu]

j'attends mon nouvel écran pour tester

[whistler]

Salut à tous!

Tests en vélo aujourd'hui de la dernière version de prunkdump.

- Aucun problème de démarrage (testé plusieurs fois dans la journée)
- La fonction mute fonctionne parfaitement (merci prunkdump!!)
- L'affichage à freezé 2 fois sur un trajet de 10min
          --> OFF/ON --> 1ère fois redémarrage OK et retour à la normale 
                            --> 2 ème fois redémarrage OK mais affichage altitude 30m au lieu de 630m (la trace GPS est ok avec 630m)
- L'enregistrement des traces est ok --> testé sur doarama.

A noter que le vario subi des petits chocs répétés car je le tenait à l'arrache sur mon guidon (bientôt un support pour le guidon ) donc si je suis le seul à avoir ces problèmes il est possible que cela vienne de ça.

J'ai également quelques questions:
1: que signifie déjà le sigle Gr dans le coin en bas à droite de l'affichage svp?
2: pour les conditions de start, parmi les 3 conditions (vitesse, montée ou descente), suffit-il d'une seule conditions remplie pour que l'enregistrement démarre?
3: Pour le stop c'est bien le fait d'éteindre le vario qui arrête l'enregistrement de la trace? Pas de risque de fichier corrompu si le alimentation se coupe trop vite?

[prunkdump]

Bon il semble qu’il y ait quand même quelques bonnes nouvelles avec le dernier code. Ça fait au moins quatre varios ou le problème n’apparaît plus. J’espere que je me fait pas une fausse joie ... j’attend encore un peu avant de confirmer l’amelioration.

@Ptikiki : je pense qu’il doit y avoir un mauvais contact quelque part. Ça m’etonne Quand même que ça marche beaucoup moins bien qu’avec le code précédent. Il y a pas tant que ça de différences.

@whisker : le bug de l’altitude arrive parfois lorsque le GPS fixe très vite après le démarrage. Il envois l’information que l’altitude est suffisamment précise pour la calibration avant même d’avoir envoyé une altitude. Et du coup le vario se qualibre avec une altitude nulle. C’est bien un bug.

Pour ton problème de freeze. Il faudrait nous dire si le vario beepe encore. Pour savoir si c’est un plantage de l’écran ou de tout le vario.

Autrement Gr signifie Glide Ratio. C’est là finesse sol.

Pour les conditions de start il faut que les trois conditions soient vérifiées. Il n’y a pas de condition d’arret et du coup effectivement parfois cela coupe la dernière trame au milieu. Mais ça ne semble pas poser problème dans les logiciels.

Mais jpg63 a commencé à travailler sur une extinction « propre ».

[ptitkiki]

Hello,
Oui, j'ai testé vite fait l'autre jour, je vais prendre le temps de faire ça mieux dés que je pourrai...
Cool en tout cas si ça semble fonctionner 

[jpg63]

Salut à tous,

je viens de mettre à jour la branche jpg63 sur le gitHub. Toutes les dernières corrections ont été intégrées. La version reste en 63.5
Pour le mute vous verrez un petit logo apparaître à gauche sous l'indicateur de fix gps / record. Je pense qu'il ne chevauche pas l'affichage de l'altitude, mais je veux bien une confirmation d'un pilote qui habite à plus de 1000m ou mieux qui passera les 2000m

Du coté M0, je viens de publier une version avec les nouvelles bibliothèques. Je vais procéder à des tests sur les accéléromètres, le GPS et terminer le codage de la récupération des vols via usb et la calibration de l'accéléromètre

 

[whistler]

Pour ton problème de freeze. Il faudrait nous dire si le vario beepe encore. Pour savoir si c’est un plantage de l’écran ou de tout le vario.

Merci pour les infos prunkdump!
Vario testé encore hier soir et ce matin sur des trajets en vélo et plus de problème de freeze ou d'autres problèmes, je te tiens au courant si cela réapparait ;D

[ptitkiki]

J'ai refait les tests.
Voila ce que j'ai observé:
- Demarrage avec la nouvelle version de Github (que je n'avais pas désinstallé depuis l'autre jour): ça démarrait à tous les coups, mais en faisant n'importe quoi niveau vario

- Re flash d'une version antérieure: retour du démarrage aléatoire à froid, allumage OK après une quinzaine de tentative. Vario stable, RAS. démarrages suivants OK.

- Re flash de la derniére version, démarrage à tous les coups, mais vario n'importe quoi. J'ai pris le temps de faire des photos:
Tantot vario instable avec des valeurs énormes :


Tantot carrément l'affichage qui bug.


A force d’éteindre / allumer, il a finit par se stabiliser !

Ce que je constate, c'est qu'a chaque allumage, le vario mets un petit temps pour se caler.
C'est plus marqué avec la nouvelle version : Avant il traversait rapidement du +/-1m/s puis convergeait. Avec la nouvelle version il traverse des varios énormes, puis parfois converge, et parfois diverge carrément, (un emballement du filtre de kalman sur des valeurs initiales aberrantes?)

Et comme précédemment, si ça marche une fois, on dirait que les fois suivantes à chaud sont OK  (mais il continu de traverser un +/-12m/s avant de se caler...).
D'ailleurs, ça marchera maintenant peut-être à chaque fois, il faut que je laisse refroidir pour être sur.

Bon, si je suis le seul à avoir ce comportement,  pas la peine d'y passer du de temps. Peut-être lié à ma config sur breadboard (vario exposé à la lumiére etc), et eventuellement je changerai l'arduino et/ou l'imu en le montant.

[ptitkiki]

confirmé que ça rebug aprés "refroidissement"

[air]

une petite mousse opaque sur le 5611 ?

[prunkdump]

Haha il y a des connaisseurs !    C'est étonnant qu'il y ait autant de gens au courant du problème du "petit bout de mousse". Mais là ce n'est pas l'origine des soucis de Ptikiki. La lumière influence un peu mais pas au point de faire varier l'altitude à ce point.

@Ptikiki.

C'est étonnant parceque le problème que tu semble décrire c'est un problème de fréquence d'échantillonnage du ms5611 qui est trop élevée que l'on avait au tout début sur les premières versions. Tu peux tester si tu veux de changer dans : librairies/ms5611/ms5611.h :

Code:

#if F_CPU >= 16000000L
//#define MS5611_INTERRUPT_COMPARE 130
#define MS5611_INTERRUPT_COMPARE 154
#else
//#define MS5611_INTERRUPT_COMPARE 66
#define MS5611_INTERRUPT_COMPARE 78
#endif

en

Code:

#if F_CPU >= 16000000L
//#define MS5611_INTERRUPT_COMPARE 130
#define MS5611_INTERRUPT_COMPARE 154
#else
//#define MS5611_INTERRUPT_COMPARE 66
#define MS5611_INTERRUPT_COMPARE 85
#endif

Pour voir si cela résout le problème.

Question bête.  Est-ce que tu es sûr de ne pas te tromper de carte lors de la compilation ? ("Arduino pro mini 328P 3.3V 8Mhtz") 

Ensuite le problème vient sûrement d'une des cartes qui n'est pas bien alimenté. Prends la tension en entrée du module ms5611/mpu9250 et regarde si tu as bien une tension supérieure à 3.3V. Globalement vérifies que toutes les cartes sauf l'écran recoivent bien la tension "RAW" de la batterie (>3.3V lorsqu'elle est chargée).

A mon avis tu n'auras pas de soucis le vario monté. C'est sûrement un problème de fiabilité des connexion sur breaboard. Par contre ça peut être interessant d'investiguer pourquoi "à chaud" cela fonctionne.

@whistler

Super que tu n'ai plus de problème  Malheureusement je sais pas si la semaine prochaine va être volable    Garde ton velo  !