Salut a tous!
Bon je suis beaucoup moins réactif que vous! Mais j’ai pu tester une fois le vario depuis. Il marche impec’ avec le code prévu initialement!
Par contre je dois être neuneu mais je n’arrive pas a compiler votre code comme décrit ci dessous
Du coup je n’ai pas pu tester les nouvelles fonctionnalités… Notamment le changement de volume qui pour moi est trop fort aussi…
Est ce que quelqu’un peu m’expliquer comment ca marche? Merci d’avance
vmath54 je te confirme la gestion de la batterie bug un peu - pas d’affichage de la tension, mon montage est ok, je vais regarder pourquoi cela ne marche pas
Pour l’enregistrement sur la sd j’ai le même problème - plus rien ne s’enregistre
Il y a aussi une petite modif à faire pour que l’enregistrement débute sans control
if( (millis() > FLIGHT_START_MIN_TIMESTAMP)
#if defined(VARIOMETER_RECORD_WHEN_FLIGHT_START)
&&(kalmanvert.getVelocity() < FLIGHT_START_VARIO_LOW_THRESHOLD || kalmanvert.getVelocity() > FLIGHT_START_VARIO_HIGH_THRESHOLD) &&
(nmeaParser.getSpeed() > FLIGHT_START_MIN_SPEED)
#endif //defined(VARIOMETER_RECORD_WHEN_FLIGHT_START)
) {
variometerState = VARIOMETER_STATE_FLIGHT_STARTED;
enableflightStartComponents();
}
Pour la batterie j’ai du oublier de configurer le port en input …
Si tu peux tester jpg63.
Edit : A non, finalement ce n’est pas nécessaire à priori. Le problème doit être ailleurs.
On peut pas vous laisser une petite semaine sans que vous en rajoutiez 3 pages !!
Pour vous faire part de mes derniers vols avec le GNUvario (c’est officiellement son nom ? On pourrait trouver un truc plus sexy quand même !)
J’ai volé presque 2h30, sans compter la prévol. À Aiguebelette ca peut être long, du moins pour moi…
Je n’ai pas de pb de fix GPS, ni de carte se qui pourtant est une 4Go toute neuve en fat16.
Par contre mon bt est toujours désactivé.
C’est pas mal de voir revenir la finesse. Moi qui commence à faire de petites transitions c’est une info qui m’intéresse de plus en plus.
J’ai constaté le pb de durée de vol affichée mais je crois que c’est réglé. En alternance de l’heure toutes les secondes me paraît idéal. Tapoter pour changer pendant le vol me semble pas pratique quand fixe sur l’élevateur.
Au boulot on m’a vanté les teensy. Moi et le code on n’est pas encore de grands amis mais ca a l’air compatible avec l’ide et à priori seraient bien plus performant. Ça pourrait pas régler le pb de mémoire ?
Il semblerait que le temps s’améliore alors je fait me faire une petite maj et :ppte: :ppte: vol !
effectivement si c’est compatible
Teensy 3.2 - freq : 72Mhz contre 8Mhz, Flash : 256Ko contre 32Ko prix 20€ contre 10€
teensy est plus ou moins compatible, il faudra revoir les lib, mais c’est plus performant.
Sinon, il y a les nucleo de STM32 (http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html?querycriteria=productId=LN1847) qui sont pas mal non plus, plus simple a intégrer ensuite dans un circuit perso, mais plus dans l’environnement arduino : http://famasys.com/site/diy/debuter-avec-la-carte-stm32-nucleo/
j’avais trouvé un lien qui permettait de surveiller la batterie en la connectant directement au AREF si je me souvient bien, sans passer par un port diviseur. Si qqun a ca sous le coude, ca permettrait de pas consommer dans le pont diviseur, c’est pour la version CMS 
Merci
Le pont diviseur c’est pour surveiller une tension supérieure à la tension d’alim. Possible autrement ?
Salut à tous,
Pour :
Y’avais ça :
Si non, de mon coté c’est gros silence radio depuis un moment, parce que j’étais tout le temps en déplacement, mais surtout parce que j’ai tout pété il y a quelques semaines (aprés mes pbm de bootlaoder, j’ai perdu le son du vario. J’ai passé quelques heures à essayer de debugguer, sans succés, mais en faisant pas mal de dégats collatéraux. (c’est chaud de désouder les modules une fois en place…).
Je suis en train d’en remonter un complétement, j’attends les pièces… Mais je vous lis trés régulièrement avec attention. Merci aux contributeurs, ça avance super bien!
J’ai bricolé un peu dans le passé avec des teensy 3.1, je confirme que ça marche fort, et que la débauche de puissance permet de compenser les faiblesses du codeur. (je parle pour moi, hein). Je pense que tout devrait être compatible, sauf la gestion du beeper. ( le push-pull avec ToneAC ne fonctionne pas dessus).
mais j’aime bien quand même la version nano, pour son coté “économie de moyen”, et pour l’énergie que prunkdrump à mis dans l’optimisation pour cette plateforme…
Pour ceux qui ont sorti l’antenne : pour renforcer l’ensemble et faire un congé propre, je vous conseil d’acheter ça, c’est canon :
https://sugru.com/
A+ !
Salut à tous !
J’ai enfin intégré tout le code de jpg63 avec le double affichage 
!!!
Vous avez maintenant l’affichage du temps de vol sur un écran séparé.
Amusez vous bien !
https://github.com/prunkdump/arduino-variometer
(Du coup je suis un peu fatigué ;), je réponds aux autres demain 
)
A+
Merci Prunkdump pour ce super boulot,
bon repos
j’ai travaillé un peu, voici ton code légèrement modifié avec les améliorations suivantes :
Il reste un petit bug, je ne sais pas comment tu veux le gérer Prunkdump donc j’ai rien fait, l’heure est décalé, le gps est en heure GMT, il faut rajouter 2h en été et 1h en hivers
A+
j’ai fait un petit test ce matin en voiture, voici mes quelques constations :
Le système de bascule d’un écran à un autre fonctionne bien
L’affichage bouge moins - système de temps de rafraîchissement opérationnel et fonctionnel
Le vario fonctionne bien - gps, son
Coté soucis
petit bug d’affichage sur l’heure - on voit des 72, 90… minutes
décalage de l’heure du au temps GMT - affichage 6h alors qu’il est 8h
gros bug avec la carte sd - je n’est plus du tout d’enregistrement
concernant le double affichage - personnellement je suis pas fan, je m’explique, le temps sur l’affichage, de l’heure et du temps de vol, sont très court, il est difficile de tombé dessus et de pouvoir bien lire l’information, les secondes alourdissent l’affichage et n’apportent rien car l’affichage est figé. Encore une fois ce n’est que mon avis personnel mais même serré dans la version précédente (affichage du temps, de la finesse, …) les informations étaient plus disponible et restaient lisible
-On pourrait essayer pour l’affichage de l’heure de n’avoir que hh:mm et pour la durée du vol avoir en fonction mm:ss si pas dépassé 1h et apres hh:mm
-Le nouveau rafraîchissement de la batterie et des satellite a des avantages mais aussi un inconvénient. Comme ce temps est relativement long, une information erronée reste affiché plusieurs secondes, je m’explique, si le rafraîchissement se fait lors d’un bip (écroulement de la tension de la batterie), on a un affichage de la batterie presque vide pendant plusieurs secondes. Je me demande si nous n’aurions pas intérêt à intégrer la mesure entre 2 affichages et ne faire afficher qu’une valeur lissée et non instantanée - sachant que normalement l’enroulement de la batterie ne devrait pas se produire (prévoir une batterie suffisante pour la prochaine version) il est peu être inutile de se lancer dans du développement
Enfin vu l’avancé du projet, je me demande si dès maintenant, il ne serait pas intéressant de rajouter un numéro de version et une date dans le code et de les faire apparaître lors de l’allumage. Beaucoup de FIRM.HEX circule et il va devenir rapidement difficile de s’y retrouver
je m’occupe de trouver le bug sur l’affichage le l’heure
A+
Salut ! 
Voilà j’ai ajouté de quoi corriger l’heure UTC selon la Timezone. Et j’ai corrigé le bug sur le niveau de batterie. Merci Jpg63 ! 
Par contre je ne comprend pas trop ta modification sur l’enregistrement du vol. Pour moi, même si on veut commencer l’enregistrement sur la carte SD dès le Fix du GPS il ne faut pas activer tous les autres composants (le temps de vol et les bips de zerotage qui doivent attendre le vrai début de vol). Même si c’est effectivement moins facile à débugger du coup. Moi je met en commentaire juste pendant le débuggage.
Pour les bips il y a un problème qui fait que je ne peut pas encore les intégrer. Tu mets un “delay” directement dans la boucle principale qui du coup la bloque pendant un certain temps. Ce n’est pas bon pour la stabilité des mesures.
De toute façon il faut que je réécrive complètement la bibliothèque “beeper”. Elle utilise beaucoup trop de “doubles” et prends beaucoup trop de place. Je prévoirai du coup une fonction non bloquante pour faire des “alarmes”.
Pour le pont diviseur :
Je ne suis pas sûr de tout comprendre mais il me semble que l’astuce d’utiliser la référence interne de l’arduino ne dispense pas du pont diviseur lorsque l’on mesure des tensions supérieures à la tension du régulateur (ici 3,3V).
Donc à mon avis on ne peut pas s’en passer ici. Et oui malheureusement ça consomme un tout petit peu de batterie en permanence.
@Ptikiki :
C’est dommage quand même de devoir tout recommencer juste pour le buzzer. Tu n’as rien pu récupérer ? Tu n’as quand même pas du déteriorer le circuit, l’arduino et la plaque baromètre non ?
Mais c’est sûr que c’est très difficile de déssouder les modules sans fer à air chaud.
Pour Teensy :
Teensy ce n’est pas complètement OpenSource ! Pas bien ! Leur succès vient surtout du fait qu’ils développent des très petites plaques. Parceque maintenant chez Arduino on trouve les même microcontrolleurs.
Passer sur l’architechture ARM me parrait quand même encore excessif pour ce projet. Pour l’instant tout rentre. On est un peu limite mais une fois qu’on aura enlevé toute les utilisation inutiles de flottants je pense que l’on va gagner beaucoup.
Pour les projet plus gourmand moi je passe carrément sur Raspberry Pi. Du coup on peut développer très vite grâce au systême d’exploitation embarqué.
Pour le nom du vario :
Ouai “GNUVario” j’ai trouvé ça en 10 seconde quand il a fallut créer la bibliothèque pour les entêtes IGC. Après j’aime bien la référence au projet “GNU” :
https://www.gnu.org/gnu/thegnuproject.html
A vous de trouver Peut être “GNUFly Vario” … petit clin d’oeil à un autre projet
Fsgecko :
Content que tu sois de retour !
Il va quand même falloir mettre à jour le firmware Tu n’arrives pas à compiler parceque tu n’as pas téléchargé la dernière version de l’IDE d’arduino. Après ça devrait marcher tout seul.
A+
Salut Prunkdump,
[quote]Fsgecko :
Content que tu sois de retour !
Il va quand même falloir mettre à jour le firmware Clin d’oeil Tu n’arrives pas à compiler parceque tu n’as pas téléchargé la dernière version de l’IDE d’arduino. Après ça devrait marcher tout seul.
A+
[/quote]
Ok bon je vais installer la derniere version de l’IDE j’esoère que cette fois cela va marcher! Je sais que je peux mettre le HEX directement sur la carte SD mais je voulais pouvoir acceder au code pour ajuster les parametres comme certains le font aussi! Je tente ta solution ce week end!
Pour l’enregistrement de vol je ne vois pas l’intérêt de débuter l’enregistrement avant le début du vol. Dans le pire des cas - tu coupe le vario avant le début, il te reste des fichiers vides, je pense que la seule utilité à la variable device en modifiant un peu le control, c’est pour les tests ou si tu souhaite tout activer des le fix.
Prunkdump comment tu vois l’utilisation de VARIOMETER_RECORD_WHEN_FLIGHT_START ?
Pour les beeps tu as raison, j’ai fait cela en vitesse; c’est 1 fois en début et c’est plutôt pratique
Je cherche pour problème de la carte SD, il faudra que l’on travaille ensemble pour trouver pourquoi ça bloque pour certain
résistances installées
malheureusement l’affichage du niveau de batterie ne fonctionne pas mieux (sur le FIRM de jpg)
j’ai donc récupéré le dossier arduino sur GitHub et recompilé un FIRM
pas mieux pour l’affichage de charge :mrgreen: … et en plus l’affichage par en vrille et le vario s’affole (voir photo)
https://i58.servimg.com/u/f58/12/58/57/57/vario-10.jpg
@Baptiste
Question ?
le Set Vario Parameters sur GitHub n’a pas les infos vario, pilote, aile
J’avais lu que tu avais fait beaucoup de mise à jour sur GitHub ?
/* set the params here */
#define VARIOMETER_MODEL "GNUVario"
#define PILOT_NAME "VAN HURLU"
#define GLIDER_NAME "EDEN 6 - 24"
Salut Van Hurlu !
Jpg63 pourra vérifier mais je pense que le pont diviseur est à l’envers. On part de RAW, on doit d’abord passer dans la petite résitance (270k) puis dans le grosse (1M). Il faut que tu inverses tes deux résistances. Vérifies bien aussi ta résistance bleu. La photo n’est pas en assez haute définition pour que je puisse vérifier sa valeur.
Pour le bug d’affichage. Je pense que tu as du mélanger un peu les versions du code. Parceque l’affichage ne correspond pas à la dernière version du GitHub. Nettois bien tous les fichiers et retélécharge l’ensemble du code.
Les paramètres du vario se trouvent maintenant tous dans :
“librairies\VarioSettings\VarioSettings.h”
Et il y a des commentaires pour mieux comprendre le sens de chaque variable.
A+
Bon bricolage !
Edit : Idée pour les kits
J’aurais du plus réfléchir pour le tuto ! Mais au lieu de limer les soudures par dessous on aurait pu perser la coque du logement de la carte SD en face des soudures. Il y aurait eut plusieurs avantages :
-> Moins de risque de faux contacts ( plus besoin de limer très fin )
-> Moins de risque de cours circuit avec la coque ( les bug quand on serre trop le boîtier )
-> Le module de la carte SD aurait été plus stable car il aurait bien reposé contre le PCB
-> On aurait gagné encore un précieux millimètre en épaisseur.
Salut Baptiste, je voie que tu est devant ton ordi merci pour ta réponse rapide.
J’ai beau lire au fur et à mesure, je n’avais pas compris que le SetVarioParameters avait changé et qu’il fallait le rebooter.
Pour mieux comprendre
dans SetVarioParameters il y a un #include <VarioSettings.h> est que ça veut dire que le code de VarioSettings.h est compilé dans le SVParam ?
Dans ce cas comment se fesse qu’il y a aussi un #include <VarioSettings.h> dans variometer ???
que se passe quand tu change le VarioSettings.h et que tu as 2 versions dif entre SVP et parameter ?
Je comprends plus trop l’intérêt du SetVarioParameters ni comment ça fonctionne
si j’ai bien compris il faut faire un FIRM.HEX avec le SetVarioParameters et le booter
PUIS
faire un FIRM.HEX avec le parameter et le booter aussi
? comment ça se passe dans la mémoire de l’arduino ? comment l’un n’efface pas l’autre ?
Je me dépêche de trouver une config qui marche, car ça vole bien en ce moment autour de chez moi 
PS: la 270ko est en bas connectée sur le RAW et la 1 M est au-dessus connectée à la masse,
normalement j’ai tout bon ?
Salut !
Je comprends ton interrogation. En fait les “.h” se compilent pas. Ils donnent juste des infos sur comment compiler.
Donc même si les infos du pilote sont dans “VarioSettings.h” et que ce fichier est inclus dans “variometer.ino”. Elle ne sont pas utilisées. Le programme variometer.ino va chercher ces informations dans l’EEPROM.
Le “SetVarioParameters.ino” lui utilise cette information pour la stocker dans l’EEPROM mais pas toutes les autres variables.
Donc conlusion :
-> Le “SetVarioSetting.ino” utilise uniquement les infos du pilote. Et aucune des autres infos. A chaque fois qu’on veut changer ces informations il faut relancer le programmer pour les stocker dans l’EPROM.
-> Le “variometer.ino” n’utilise pas les infos du pilote. Il va les chercher dans l’EEPROM. Par contre il utilise toutes les autre infos de “VarioSettings.h”. C’est là où on rêgle tout le comportement du vario.
Je sais pas si je suis clair :?
Pour le pont diviseur :
-> La résistance jaune est une résitance de 270k, actuellement elle est en bas de la photo est elle est soudée à GND. Donc ce n’est pas bon à priori.
-> La résistance bleu, je n’arrive pas à lire le code couleur, supposons que c’est celle de 1M. Elle est en haut sur la photo et connecté à RAW.
Donc pour moi c’est inversé. Mais c’est vrai que les écritures sont ambigues. Regardes ici :
http://www.dominicdube.com/wp-content/uploads/ProMiniPinout.png
Bon vols !
Pour moi ça va être un peu fort aujourd’hui je pense.
A+
:grat: on va dire que j’ai compris :mrgreen: j’aurai juste 279 autres questions à te poser
Tu as de la chance d’habiter loin de chez moi, sinon je passerai régulièrement t’apporter des binouzes pour te demander des explications.
Merci, avec le plan je comprends mieux mon inversion,
j’ai vérifié 3 fois, mais a chaque fois j’interprétais de travers :bang:
C’est OK pour le niveau de batterie, OK pour le nouvel affichage
le Vario fonctionne bien mais le Fix satellite ne se fait plus
:bang: