ceci dit j’ia l’impression que j’ai un pb d’écriture sur la carte SD: en laissant le vario allumé et en bougeant un peu je n’ai pas de trace. C’est bizarre car l’écriture fonctionnait au tout début. J’ai essayé de mettre un ancien FIRM pour être sur de ne pas avoir le seuil dde démarrage de l’enregistrement mais idem, pas de fichier créé. Il y a un moyen de tester l’écriture?
DIY GnuVario : variomètre opensource - openhardware Arduino
Il y a une interaction entre l’écran et la carte SD. Les 2 périphériques utilisent certaines pattes en commun.
Regarde si tu n’a pas un problème sur la carte SD en utilisant les firm de test - test sdcard sans écran puis test l’écran en désactivant la SDcard
Il y a un soucis de masse avec la SD mais pour l’instant l’endroit n’est pas exactement identifié, il ne faut pas serrer la batterie contre la SDcard, mettre des vis plus long
Super ! merci.
Je vais essayer de retravailler la “Vue schématique”. Je n’ai jamais fait jusque maintenant.
Si j’arrive à qq chose de convaincant, je le mettrais à dispo.
Je confirme. J’ai un fritzing installé de manière basique, et je n’ai pas d’erreur au chargement du fichier envoyé par jpg63.
je te mets les fichiers mais tu dois peut être avoir un problème avec ton fritzing
ok merci, c’est tout à fait possible que le pb vienne de la carte SD. Je vais faire les tests
j’ai testé tout d’abord l’écriture de la carte SD seule et ça marche (3 bips et un fichier). Par contre, avec l’écran intercallé ça ne marche plus (2 bips graves), que l’écran soit installé ou non. Du coup ça doit être le problème de Jpg63 mais je retrouve pas le post en question…
Ton problème est lié à un cour-circuit sur la patte qui commande l’activation de l’écran ou de la SD. Il faut éviter de serrer le capot du boitier. Vérifie capot ouvert tu ne dois plus avoir le problème
Mets des vis longues et laisse un peu de place, pour éviter compresser les cartes. Pour l’instant je n’ai pas mieux
je ne suis plus dans le boitier depuis belle lurette 
J’ai essayé de soulever la carte SD pour qu’elle ne soit plus en contact avec le circuit (j’ai un espace complet sous la carte) et ça ne change pas le pb. Je vais déssouder la carte SD, tout bien nettoyer en dessous, et la ressouder pour voir si ça règle le pb. Vous auriez un conseil pour déssouder? Je n’ai jamais eu l’occasion de pratiquer
On est plusieurs à avoir le problème, la solution du post plus haut a marché, mais le problème persiste, si tu trouve d’ou vient le problème, nous pourrons l’éviter pour les futurs kits. Il me semble que le problème vient de la patte CS qui passe à la masse. Bon courrage
bon je capitule… après moulte effort j’ai réussi à enlever le lecteur SD (quelle misère à déssouder!). J’ai ensuite voulu rechauffer toutes mes soudures limées et là catastrophe j’ai fait des ponts partout. Aprèse avoir fait un mieux (et m’etre brule trois fois;) ) j’ai voulu ressouder le lecteur mais impossible, trop abimé. Bref c’est de pire en pire et je crois pas que ce soit récupérable en l’état. Je pense que je vais attendre la version 2!
Pour dessouder, comme je n’ai pas de pompe ou de matériel sophistiqué comme certains :roll:
j’utilise la méthode du “choc” 
au-dessus d’une table
tu prends la carte dans la main gauche, le fer dans la main droite,
tu chauffe bien fort
tu cognes ton poignet gauche sur la table (rapide et fort)
tu pourras déboucher tes œillets et enlever tes surplus de soudure
J’ai presque tout démonté et tout remonté à l’époque ou j’avais plein de problèmes … j’avais le poignet qui commençait à devenir bleu
on ne dirait pas, mais c’est du solide ces petits machins pleins de trucs et de bidules :mdr:
j’en suis venu à la même technique ;). J’ai bien une pompe à déssouser mais pas du tout efficace ce truc.
Je viens de ressouer le lecteur SD avec des fils en ultime tentative mais toujours rien.
Essais fait sur XCSoar, avec driver LXNAV. J’ai affiché dans XCSoar, entre autres, les infobox correspondant au vario, l’alti GPS, l’alti baro
J’ai paramétré XCSoar pour qu’il écrive en log les trames NMEA recues.
Essais fait dans une voiture
low_freq_gps :
XCSOar indique qu’il reçoit Position GPS, Baro, vario
Le vario affiché par XCSoar est aléatoire. Il ne correspond pas vraiment aux infos affichées par le gnuVario :
Lorsque la valeur varie entre -0.8 et -0.9 sur le gnuVario, le vario varie en général entre -0.1 et +0.1 sur XCSoar.
Lorque la valeur est plus élevée (> 1m/s, ou < 1m/s), c’est plus juste. Il y a juste parfois un affichage furtif à 0.1 (par exemple), alors que ca semble constant à 1.4 (par exemple) sur le gnuVario.
alti GPS : varie de qqs m par rapport à l’alti donnée par le gnuVario. La différence n’est pas constante : parfois presque pas (2m), parfois bien plus (15m). Je trouve cette variation de diff étrange.
alti baro : J’avais réglé le QNH du moment (1012). Il y avait une diff d’environ 16m avec la valeur alti vario. Pour annuler la diff, j’ai du rentrer un QNH de 1014
high_freq :
XCSoar indique qu’il reçoit Baro, vario
Même constat que précédent pour l’affichage vario sur XCSoar. Donc, erratique.
Si je règle le QNH à 1013 sur XCSoar, L’alti baro affichée est identique (à 2m près) à l’alti affichée sur le gnuVario ; c’est cohérent.
Je joins les trames NMEA que XCSoar a recues (en tout cas, ce qu’il a logué). Il y a 4565 lignes, soit environ 15mn.
J’ai changé les virgules en point-virgule pour lire directement sous excel.
Ca correspond à un trajet aller/retour départ de mon domicile ; avec du plat relatif au début, une montée, une petite descente, puis demi-tour.
Ces trames correspondent, je pense, à ce que XCSoar m’a affiché : la plupart du temps, entre -0.1 et + 0.1. ET des périodes à +1.x et -1.x.
Alors que le gnuVario m’affichait autre chose, surtout dans les tranches -0.1 et +0.1.
choses remarquables :
par exemple,
lignes 2062 et 2063 : on passe de -1.08 à -0.092 ; donc en 1/5eme de secondes. L’altitude transmise n’a pas changé : 236.7m
lignes 2110 à 2140 : on est dans une descente continue. On passe subitement d’un vario à -1,xx vers un vario à -0.09X (ligne 2124), alors que l’altitude continue de baisser assez régulièrement ; j’ai du mal à comprendre.
Conclusion (sur de tout petit essais) :
- la partie GPS et alti baro semblent cohérents
- les infos vario transmises en NMEA semblent douteuses
Oui, je crois le fix doit être fait pour disposer de trames GPGGA et GPRMC correctes et complètes
Je crois avoir vu des trames GPGGA et GPRMC sans infos GPS lorsque le fix n’était pas fait ; je ne suis pas certain à 100% de cela, mais j’avais vu passer des trames bizarres avant le fix.
Sinon, je me comprends pas trop ce que tu appelles les trames NMEA ; toutes les trames transmises par le gnuVario sont des trames NMEA.
Pour ma part, avec XCSoar, l’utilisation du driver LXNAV permet de récupérer les infos GPS (trames GPGGA et GPRMC) et baro-vario (trames LXWP0)
Pour mesurer l’intensité, je pense que le plus simple c’est un petit capteur de courant
http://www.ewallpk.com/home/1142-max471-voltage-current-volt-amp-test-sensor-module-for-arduino.html
il y en a plein, le max741 fonctionne de 3v à 40v, à voir pour les autres modules
après on mesure la tension sur une entrée et avec une petite règle de 3 on en déduit le courant.
Si personne ne l’a fait d’ici la, je pourrai faire des mesures précises début août, j’ai le matos au boulot.
Keep in touch…
Il serait intéressant d’enregistrer simultanément la tension et le courant, et faire des mesures au repos et en fonctionnement - GPS, buzzer, BT,…
Salut à tous !
Bon ça y est je me suis enfin décidé à mettre un peu à jour la doc sur le GitHub :? J’ai détaillé le README avec la nouvelle procédure et j’ai mis un schéma de montage (fait avec KiCad). Ca parait plus compliqué que ceux fait avec Fritzing mais c’est tout à fait lisible quand même.
@Finlard : Si tu veux un coup de main pour ta réparation tu peux me contacter directement par mail. Ca permettra d’échanger plus rapidement. Au pire tu pourra me renvoyer le circuit que j’y jette un oeil. Je suis sur que ce n’est pas très grâve. Mais ce n’est pas toujours évident de trouver le problème.
Un grand merci VMath54 et Xiboard pour vos retours ! 
Sans ça je ne pourrais jamais débugger le bluetooth. Vous semblez constater des choses similaires. A savoir une altitude baro relativement cohérente mais un vario qui affiche des résultats étranges. Xiboard vois tu une différence entre la version “high_freq” et ta version perso au niveau du résultat sur XCSoar ?
Je crois malheureusement qu’il va falloir se plonger dans le code de XCSoar ou alors les contacter pour comprendre comment leur logiciel fonctionne.
Je vais sous peu vous faire une version avec les trâmes LK8000 à la place de LXNav. Il semble de toute façon que ce soit obligatoire pour faire fonctionner XCTrack.
Je vais chercher avec vous pour la mesure de l’intensité.
A suivre !
A mon avis, on va pas échapper à LXNav ou LK8000 au choix au moment de la compilation.
Quand tu aura fait la version LK8000 je serai curieux de voir ce que ça va donner avec les trames GPGGA et GPRMC.
Je pense que XCSoar recalcule et filtre la valeur vario à partir de la valeur de l’alti. Et comme la valeur de l’alti est moins précise (combien de chiffres après la virgule ?) on a des ‘saut’. C’est un peu dommage si c’est ça mais bon.
En fait je me reposait la question de l’intérêt d’avoir une valeur précise et réactive de la valeur du vario pour une appli : Calcul de la finesse, aide au centrage des thermiques (XCTrack et FlyMe indiquent sur une petite carte là où on a pris le dernier gros vario, il en déduit où peut être le thermique avec la dérive du vent calculé et l’altitude. Des fois ça marche étonnamment bien, surtout en plaine dans du petit)
Prunkdump : non pas constaté de diff majeure entre la highspeed et ma version. Ça doit sensiblement tourner à la même fréquence. En tout cas 5Hz je pense c’est bien. Je te dirai avec XCTrack.
Super ! Merci beaucoup.
Je crains que le problème soit du coté gnuVario (c’est bien comme cela qu’il faut le nommer ?).
J’ai refais un essai hier avec le firm high_freq ; il envoie 5 trames LXWP0 par secondes ; donc juste les infos baro, et de vario.
Ce coup ci, j’ai mis XCSoar en mode “debug” pour la partie NMEA recue ; pour les connaisseurs, c’est dans “Config - Periph” ; on n’active que “LXNAV sur bluetooth”, et on sélectionne cette entrée.
On clique ensuite sur le bouton “Controle”, et on voit les trames NMEA recues.
Je suis certain maintenant qu’il y a un décalage d’une décimale entre le vario affiché par le gnuVario, et les trames NMEA “LXWP0” transmises ; ceci entre -1m/s et + 1m/s.
Quand je vois sur le gnuVario un “+0.3” ou un “-0.5”, la trame affichée dans la fenetre de debug de XCSoar (donc je suppose celle transmise) est de l’ordre de “0.03x” ou “-0.05x”
Après, une fois que l’on a dépassé le +1 ou le -1, l’info de vario semble cohérente.
Je vous joins le dernier fichier d’enregistrement NMEA de XCSoar ; brut ce coup ci.
Vous verrez des transitions de “0.09” à “1.x” régulièrement. Pareil en négatif.
Et je ne pense pas que l’on voie des infos de l’ordre de “O.3” ou “-0.5”.
Par ailleurs, sur la partie BT :
actuellement, je crois que l’envoi de l’info BT se fait en même temps que l’enregistrement d’une trame IGC sur la SDcard.
Je pense que ce n’est pas une bonne chose, et qu’il faut dissocier.
-
IGC
C’est qq chose qu’on consulte à postériori, pour une compét ou autre. L’intervalle entre 2 enregistrements n’a pas besoin d’être très court.
La valeur par défaut pour un FLARM (appareil anti-collusion imposé sur les planeurs en France, et qui sert pour la compet) est de 4 secondes. Pour XCSoar, c’est 5 secondes. -
BT
La, on envoie de l’info à une appli de navigation aérienne. Il faut être le plus rapide possible.
je suis pas tout à fait d’accord, beaucoup de vario enregistre toutes les 1sec, je pense que c’est une bonne valeur pour apprécier et revoir une trace après un vol ou pour voir ton altitude max, vario max …