je viens de mettre à jour la librairie beeper et le code variometer.ino
j’ai juste un problème, la compilation se passe bien mais le code ne marche pas, j’ai l’impression que mon FIRM.HEX n’est comme le tiens Prunkdump, car quand j’appuie sur reset, au lieu d’avoir la led qui clignote vite et le vario qui reboot, ma led reste allume et plus rien le vario reste planté
Si tu as une idée
salut les gars je suis en train de me lancer dans ma v2 avec celui de punkdump je me pose une question on peut se servir d un arduino nano ?
salut les geeks soudeurs,
l’initiative à l’air sympa et ca fait plaisir de voir que vous vous amusez …
mais heu … ca parle pas des masses de parapente ces 20+ pages !?! 
ca vaudrait pas la peine de migrer tout le helpdesk sur github, et venir poster les trucs (un peu) comprehensibles ici ? :canape:
bonne continuation :ange:
ça marche pas à tout les coup : supprimer le volume de la SD est souvent “grisé”. Même en ‘démontant’ la carte SD. Peut-être ça dépends du type de lecteur de carte utilisé ??
Oublie XCSoar 
XCTrack bien plus sympa. Sinon XCSoar pour la prise en main tu l’install sur PC ou tablette et tu l’utilise en mode SIM.
C’est pas forcément vrai.
La je conclu juste que si tu envoie un fichier IGC à Logfly sans alti-pression mais avec alti-gps il se contente de ça.
A réfléchir.
Autrement, mon avis à 5 centimes par rapport au différents messages précédents :
-C’est quoi l’intérêt de commencer d’enregistrer la trace sur la carte SD tant que le fix n’est pas fait ?? A part avoir le temps de vol et les valeurs vario, aucun, non ?
De plus, essayer de faire un fix en déplaçant le GPS est ce qu’il y a de plus dur. L’allumer en vol… j’y crois pas trop.
-L’accès au reset, c’est quand même le truc le moins indispensable non ? On peux bien démonter 4 vis pour atteindre le reset, non ?
-Comme de nombreux ali-vario-gps : je calerai l’alti baro avec l’ali gps avant le déco dès que la précision est correcte (4-5 satellites, non ? ou utiliser la valeur précision alti du gps) Ensuite tout reste : alti baro.
-Par contre quel valeur enregistrer/envoyer : GPS ou Baro ? Je ne sais pas comment gérer ça dans le NMEA. Dans l’IGC on sauvegarde les deux valeurs comme jpg63 l’a montré. Je veux bien faire des essais avec XCSoar et XCTrack mais pour le moment, il semble qu’ils reçoivent toutes les trames NMEA mais ils ne les interprétent pas ?
Dans XCTRack on peux choisir utiliser GPS Externe (on/off) et utiliser baro interne ou baro externe. Je vais essayer de trouver dans la doc ou autre si c’est en passant par trames NMEA + Openvario.
Salut à tous,
Votre projet est vraiment sympa! 
En ce qui concerne le protocole échange externe, il semble que XCTrack se soit inspiré du projet LK8000
http://xctrack.org/External_Sensors.html
https://github.com/LK8000/LK8000/blob/master/Docs/LK8EX1.txt
je voulais juste indiquer que les enregistrement NMEA n’étaient pas bien convertis par GPSBABEL et que du coup les altitude barométrique n’était pas dans le fichier IGC. LogFly gère les 2 altitudes et fait des stats sur l’altitude GPs si il n’a pas l’altitude barométrique, comme le ferait XcGlobe ou d’autre site de dépo de trace. Le soucis c’est que l’altitude GPS est vraiment pas très juste, est fluctuante, dû à la méthode de calcul. Il me semble important d’avoir les altitudes barométrique donc de réfléchir pourquoi elle ne sont pas convertis
Avoir le temps de vol à l’affichage comme sur les traces me semble important, mais c’est mon avis. Par exemple tu allume le vario, tu séche pendant 30min en attendant les bonne conditions, tu vol 1h, ta trace indique 1h30 avec un grand plat de 30min. Tout les vario même les plus basiques, mon vieux digifly (non gps) n’enregistrée que le vol, je crois quant plus c’est implementé dans le code, avec une vitesse de 10km/h mais je ne sais pas pourquoi ça ne marche pas, je signalais le problème
Allumage en vol, aucun problème, fixé aux élévateurs, avec mon sysride je passe d’un écran à l’autre et avec mon petit bouton aucun soucis sur ce petit vario. C’est un projet open du coup chacun pourra y apporter ses envies et ça façon de voler. Ça met déjà arrivé d’attendre au déco près, le vario coupé et de sauter dans la sellette en oubliant de l’allumer, mais c’est plus souvent en bi que je l’oublie, tu prépare le passager et les instruments ce n’est pas la priorité, tu décolle et la tu te dis que le vario ça peut aider
Je suis d’accord, ce n’est pas indispensable, juste que pendant la phase de test et de beta-test le code va souvent changer, les pilotes qui vont s’impliquer vont certainement démonter des dizaines de fois le boitier, les vis ne vont plus tenir et à chaque fois il y a un risque de déconnecter l’écran, dessouder la batterie, voir de la coincer et la percer (les lipos sont des batteries hautement dangereuses). Si la méthode de mise à jour est simplifié, c’est plus agréable. Je suppose que Prunkdump a envie que son petit vario soit diffuser à plus de 10 pilotes, il faut penser aussi aux futur utilisateurs, peu être moins à l’aise avec l’électronique et l’informatique
Je pense que le GPS doit effectivement ne servir que de calage du baromètre. Le baromètre est précis mais dépendant de la pression atmosphérique, le GPS est la pour fixer la pression de référence. La pression atmosphérique peut changer dans le temps et en fonction du lieu, c’est pour cela que sysride et je crois que c’est les seuls, recale leur baro toutes les 15min.
Il est possible dans NMEA de tricher est de remplacer l’altitude du GPS par l’altitude BARO lors de l’enregistrement. Du coup après conversion on aura juste l’info GPS mais altitude sera juste.
pour Xctrack ou xcsoar je ne sais pas comment ils marchent et quelle trame ils acceptent
Pour une fois que j’ai un truc qui fonctionne sans me prendre la tête … :mrgreen:
J’ai même pu formater une partition de 3Go en FAT,
j’espère que ce n’est pas idiot de choisir un volume plus grand, cela me permettra de garder plus de traces.
Je doute que ton post espérait une réponse ?
Permet moi de te dire qu’avant de lire ce post dans le CDV, je ne connaissais même pas l’arduino et encore moins github.
Donc oui c’est intéressant que ce fil soit sur ce forum et on ne parle que d’instruments de vol, donc de parapente entre parapentistes.
Juste que la tournure du fil et la qualité du travail de Prunkdump mériterait que ce fil soit déplacé dans : “instruments de vol”
Car, oui “notre amusement” va déboucher sur une alternative “libre” aux instrument de vol de marque.
Salut à tous
J’ai intégré ton code sur le GitHub du projet avec quelques modifs légères. J’ai pas eu le temps de le tester par contre.
Lorsque tu compiles as-tu bien choisi “arduino pro, pro mini, 3,3V 8Mhz” dans le menu “outil” ? Ton fichier HEX a l’air d’être formaté normalement. Je t’envois le firmware compilé depuis mon PC pour voir s’il y a une différence. Attention de bien prendre le firmware sans bootloader et de ne renommer avant de la copier sur la carte.
Vérifies également qu’il n’y a pas de vieilles librairies qui traînent dans ton arborescence Arduino. Vide tout et remplace par l’intégralité du code du GitHub.
Salut Guillaume ! Ca faisait un petit moment.
Tu peux monter le projet avec un arduino nano mais c’est dommage. Tu vas devoir augmenter la tension de 3.7V à 5V en sortie de la batterie puis redescendre toutes les sorties de l’arduino en 3,3V. En plus cela va diminuer fortement l’autonomie du vario.
Je te conseilles de passer plutôt au pro mini. Ou si tu n’aimes pas le fait qu’il n’ai pas d’USB tu peux aller voir chez sparkfun. Ils ont des plaques 3,3V avec un micro USB.
Salut ! N’hésites pas à te lancer si ça t’interesses. L’objectif de ce fil est d’avoir une maximum de retour sur les fonctionnalités attendues d’un vario. Puisque le projet est ouvert, tous le monde est libre de le modifier comme il le souhaite.
Super le lien je vais potasser ça.
Pour le début de l’enregistrement de la trace :
Effectivement il y a déjà dans le code une “reconnaissance” du début du vol. Elle servait à la base pour le bip de zerotage qui bipperai sinon sans arrêt au déco. C’est donc très facile de changer le code pour avoir cette fonctionnalité.
Mais pendant les phases de test. Je préfère laisser comme ça pour qu’on ait pas tous besoin de courrir dans le jardin pour lancer la sortie du GPS.
Autrement le recallage du baro avec l’alti GPS est déjà implémenté. Si vous observez bien votre vario, au moment du fix l’altitude change. Mais pour l’instant il ne regarde pas le nombre de satellites ni la précision. Il prends simplement la cinquième valeur d’altitude. Il faudrait peut-être ajouter ça dans les “issues”. Et aussi il ne relance jamais le recallage.
L’accès au reset
Je suis d’accord ça serait bien qu’on ait plus à démonter les vario. C’est un risque à chaque fois d’abîmer le matériel. C’est d’ailleurs pour ça à la base que j’ai programmé le bootloader. Mais après coup je trouvais génant qu’il se lance à chaque allumage. D’où le bouton reset pour le moment.
La j’ai un peu de boulot mais dans la semaine je vous fait ça.
Pour les altitudes GPS et barométriques :
Bon le problème n’est pas complètement résolu. Mon idée de substituer l’altitude baro dans les trames NMEA n’est pas complètement idiote donc. Elle permet pour l’instant de l’utiliser dans logfly (qui croit que c’est l’alti GPS).
Mais globalement il semble que presque tous les logiciels/formats gèrent les deux altitudes. Il n’y a que le passage NMEA->IGC qui n’est pas très clair.
Il faut que je trouve le temps de travailler sur le code du bluetooth pour pouvoir tester XCtrack.
Tiens Xiboard si tu peux tester ce code avec le bluetooth (en pièce jointe). Chez moi ça marchait. Mais peut être qu’il y a une question de timing qui m’échappe.
Van Hurlu pas besoin de passer à 3Go. Je ne suis plus bien sur que ça soit bien supporté par le FAT. Et de toute façon avec 2Go tu peux stocker des années de traces GPS 
Merci prunkdump,
j’ai bien compiler avec pro-min 3.3v, je vais vérifier mes bibliothèques car mon .HEX fait 74ko et le tien 82ko.
c’est peux être le bluetooth qui est ajouté ?
Sinon c’est qu’il y a forcément quelques choses de différent chez moi.
Tu utilise quelle version du compilateur ?
c etait juste un appel à modération
si on pouvait eviter les gory details des commandes de partition de SD et les patches de code … !
bizarrement ca n’avait pas dépassé 1 page là https://forum.arduino.cc/index.php?topic=237376.0 :init:
oui c est clair que y a pas de grosse barriere technologique.
y a aussi des chances que le temps que vous finissiez les soudures, les accelerometres des telephones seront suffisamment précis pour ne plus avoir besoin de bricoler du hardware :ange:
J’utilise une vieille version “1.0.5”. Sous linux presque tout le monde est resté à cette version, je ne sais pas pourquoi.
Non je n’ai pas ajouté le bluteooth dans la version que je t’ai envoyé. Elle fonctionne d’ailleurs ?
Je pencherais plutôt pour une ancienne bibliothèque qui traîne. Vérifies bien dans ton dossier “librairies” qu’il n’y a aucune autre bibliothèque que les miennes. Il peux y avoir des incompatibilités sinon. (Par exemple j’ai modifié la bibliothèque I2CDev donc il ne faur plus que la version originale soit présente).
Toujours plus que dans les posts politiques non ?
Continuez les gars ! C’est top et tout le monde peut jouer (en plus ça ne vole pas !) !
houla oui !
et d’une façon tellement plus constructive, c’est une belle leçon ! :ppte:
Entièrement d’accord, je vais faire qq essais. Mais ça m’étonne pas NMEA c’est du pur GPS. J’ai pas bien regardé mais Prunk à rajouter des trames OpenVario ($POV, n’est ce pas ?). On a l’alti baro et valeur vario dedans c’est ça ? Je pense que GPSBABEL n’utilise pas ces lignes $POV. Donc avec GPS Babel ça saute.
D’où la bonne idée de dev un petit prog très lèger de décharge des traces. Il nous fera le NMEA + OpenVario > IGC. Je verrai bien dans ce log la detection du déco et attero. Et ajustable à la main si on veux : Je vole pas mal en soaring, il arrive de ne pas avancer et de ne pas varier d’alti pendant plusieurs minutes des fois (pour admirer le coucher de soleil par exemple) Bon, les traces IGC des vols de soaring osef un peu… (juste bien pour les temps de vols des voiles)
Entièrement d’accord. Je disais juste “je n’y crois pas” dans le sens, je doute que le fix GPS y arrive. Hier j’ai allumé le vario en voiture en roulant à 90km/h. Il n’a jamais réussi à fix sur 15min. Je m’arrête, il a fix en 30s.
D’ailleurs pour info sous un ciel très couvert (orageux) et derrière par-brise(Pour Van Hulu, on trouve le nombre de GPS dans le fichier généré sur la carte SD) :
17h44m31 3sat (fix à l’arrêt)
17h44m33 5sat (tjr à l’arrêt)
(Là j’ai repris la route à 90km/h)
17h45m03 6sat
17h47m03 7sat
17h56m07 8sat
17h58m05 9sat
18h11m16 10sat
Précision très bonne et pas de fluctuation de la vitesse GPS.
[HS]: Passé 100km/h l’affichage n’apprécie pas Vous allez me dire, 100km/h en parapente, on a de la marge… bin pas tant que ça pour certain :
http://parapente.ffvl.fr/cfd/liste/2016/vol/20212161 (Pointe à 89km/h à la fin du vol !! :bu: )
Et les affolement de varios quand on double un camion ou que l’on se fait doubler c’est assez amusant. Idem lorsque l’on ouvre une fenêtre !
[/HS]
Autrement il me semble avoir remarqué quelque chose, toujours en voiture, lors de grandes courbes à plat (vive les landes) le vario fluctue beaucoup. Je me suis demandé si c’était dû au décalage du vecteur accélération vers l’extérieur du virage ? Bon, en voiture le vario reste à plat. En parapente, le vecteur accélération va plus ou moins toujours resté dans l’axe voile-pilote (sauf en SIV ROTFL )
Bref, des détails, d’un point de vue hardware chez moi tout marche impec.
@PrunkDump, je vais test ta version bluetooth dès que j’ai un moment…
Je n’ai pas eu le temps d’avancer sur le kit prunkdump ; je suis occupé par ailleurs.
Le mien semble fonctionner…
mais il semble avoir des problèmes de réception GPS :
. mise en marche chez moi à l’extérieur, immobile : il fini par capter au bout de 3 à 5 mn.
. mise en marche dans la voiture en mouvement : incapable de faire un fix GPS ; alors que le smartphone fait un fix GPS en quelques secondes.
Je n’ai pas du tout creusé ; 2 essais sur mon rebord de fenetre, et 2 essais dans la voiture.
Je crois avoir vu sur le module GPS quelque chose qui ressemble à une petite pile ; est-ce bien le cas ?
Est-ce que le module GPS qu’on utilise a la capacité de mémoriser son “environnement”, ou bien doit-il le redécouvrir à chaque fois ? S’il doit le redécouvrir, ca expliquerait le temps pour le fix.
Pour la partie XCSoar, et trames NMEA :
je crois comprendre (à confirmer) que le prunkVario enregistre les mêmes trames NMEA sur la sdcard et vers le bluetooth ; si c’est le cas, merci de mettre en ligne ou de me passer la trace d’un vol, j’essaierais de voir ce que ca donne sous XCSoar
ou si vous voulez tester, j’ai déposé sur github du code (perl) qui permet de “pousser” vers XCSoar en TCP ou UDP des trames NMEA.
C’est à https://github.com/vmath54/xcsoar/tree/master/IGC ; c’est du “brut”
J’ai fait cela lorsque prunkdump a parlé de son vario, et qu’il envisageait la connexion bluetooth. J’ai fait qqs essais, et j’ai un peu abandonné, faute de temps …
Pour le fonctionnement de XCSoar :
Je me suis fait des petites docs perso, mais je n’ai pas d’expérience : un seul vol en réel avec XCSoar, récent, en planeur.
Je vous passe ces docs, c’est aussi “brut de fonderie”.
Je vais essayer d’avancer sur les trames NMEA qui vont bien pour XCSoar, et le paramétrage adéquat coté XCSoar.
vmath54 salut, je te mets 2 petits ploufs enregistrée avec mon vario fraîchement soudé, si ça peut aider
Prunkdump, merci pour ton aide,
coté compilateur c’est bon, j’ai pris la dernière version 1.8.2, les bibliothèques SPI et EEPROM de la version 1.0.5 et tes bibliothèques. Le code fait 74ko au lieu de 82ko et il fonctionne parfaitement.
j’ai testé le code avec réglage du volume c’est tout bon, avec 6 je trouve que le volume est largement suffisant
Je vais m’attaquer à une petite modification de la bibliothèque NMEA pour ajouter 2 fonctions qui me permettront d’afficher l’heure et de gérer l’affichage du temps de vol
Quelques essais du soir pour l’interface avec XCSoar ou XCTrack :
J’ai testé ça :
void loop(){
delay(1000);
Serial.println("$POV,P,1011.35,E,2.15*6D");
}
La transmission avec le Bluetooth marche bien : dans XCSoar on peux voir les trames.
J’ai pas réussi à les faire reconnaître par XCTrack.
Ça marche bien dans XCSoar mais seul, sous le protocole OpenVario (logique) et pas NMEA. Donc je vois pas comment ‘noyer’ des trames OpenVario au milieu du NMEA et que XCSoar interprète les deux.
puis j’ai test ça :
void loop(){
delay(1000);
Serial.println("$LK8EX1,1009,1050,156,99,999,*14");
}
Ça marche impec avec XCTrack. Pas réussi à trouver dans XCSoar (alors que je pense que c’est possible)
Quelqu’un connais le protocole BlueFly Vario ? Il semble être pris en charge par les deux et inclure vario, alti, gps…