+ Le chant du vario +

Merci Eric pour le tuyau !  :trinq: Je suis pas encore suffisamment équipé... Mais c'est sur que c'est un bon outil ! du coup tu as une évaluation précise de la consomation.

Pour le choix du microcontrolleur :

Pour moi l'essentiel c'est de choisir une plaque qui fonctionne en 3,3V car tous les composant (batterie, ms5611, mpu9250, gps, carte sd, écran ... ) fonctionnent en 3,3V. Donc cela simplifie grandement les circuits. Chez Sparkfun par exemple on trouve des plaques avec le ATmega32U4, un micro usb, et en 3,3V. Pour moi c'est idéal pour ce projet. Ya plein d'équivalent chez les autres constructeurs.

Pour le passage au processeurs ARM, on change d'architecture. C'est du 32bit et il y a souvent plus de performance et de mémoire. Mais je pense que tout (alti, acceleromètre, écran, GPS, carte sd, bluetooth) rentre dans un ATmega328p ou un ATmega32U4. Et les performences sont suffisantes même en 3,3V. Donc je pense que le changement de processeur sera avantageux lorsqu'il faudra proposer des fonctionnalités plus avancées (direction du vent, cartes etc ...)

Autrement pour répondre à Vmath54 il n'y à pas de problème à changer de processeur. Comme le disait Whistler il faut juste changer le code du timer pour l'altimètre. Je peux donner des infos à ceux qui seraient interessés.

L'interêt du 4050 :

Pour Guillaume1 le 4050 sert à changer le voltage des signaux logiques. Le nokia 5110 utilise du 3.3V et donc ce n'est pas idéal de lui envoyer du 5v. Il faut voir le 4050 comme un simple interrupteur. Il ouvre du 3,3V au besoin. Mais comme je le disait plus haut, l'idéal est de tout faire fonctionner en 3,3V et le composant devient inutile. Le schéma sur mon Github est un peu obsolète j'en ai donné uen version à jour dans les pages précédentes.

 
Proposition pour les bricoleurs :

Comme je trouve que je ne vole pas suffisament pour faire évoluer mon vario, j'avais pour idée de fournir des kits tout prêt pour construire le vario de la vidéo ci-dessous. Il resterait plus qu'à souder et éventuelleement à percer le boîtier. Si il y a du monde on pourrait grouper les achats. Enfin je lance juste l'idée. Il me faut encore un bon mois pour être sur que le montage est au point et fiable.

Amusez vous bien !

 http://www.youtube.com/watch?v=60fqfbTenkc

A+

 

intéressé ! même si je suis équipé cela donne envie de jouer

intéressé aussi par curiosité
cela dépendra quand même du prix du joujou

très intéressé.
Mais, qu'y aura-t-il dedans ?

Intéressé aussi.  :+1:  La flemme et pas le temps de m'y mettre  :ange:

Salut à tous !  :trinq:

Alors l'idée c'est de préparer à l'avance tout ce qui est difficile à adapter pour finaliser le vario.

Déjà tous les éléments qui demandent des mesures précises :

-> Un boîtier prêt et déjà ouvert pour l'écran, le switch on/off , l'écran et la carte sd.
-> Un circuit imprimé ajusté au boitier, percé, et prêt à acceuillir toutes les plaques de composants.
-> Un scratch autocollant de fixation au cockpit

Ensuite tous les composants pénibles à trouver. Dans ma version finale je ne veux plus de fil soudé. Ils sont cassants et font de mauvais contacts. C'est une plaie. Il y aurait donc :

-> un systême de connecteur pour l'écran afin de ne pas souder de fils. Le connecteur serait à souder sur l'écran et de l'autre côté sur le circuit impimé. Les câbles seraient préparés et ajusté à la bonne longueur.
-> un systême de switch on/off (à souder) intégré au circuit imprimé
-> un buzzer (à souder) intégré au circuit imprimé

Ensuite il y aurait toutes les plaques de composant nécessaires :
-> un arduino pro mini 3,3V
-> une plaque avec altimètre et acceleromètre
-> une plaque avec une chargeur lipo
-> une batterie lipo 600mah
-> une plaque avec un module GPS
-> une plaque avec un lecteur de carte SD
-> une plaque avec un module bluetooth

Donc comme boulot il y aurait à souder toutes ces plaques sur le circuit imprimé. Et à fixer tout ça dans le boîtier. Donc comme matos non fournis il faudrait :
-> un fer à souder fin
-> de l'étain et de la tresse à dessouder
-> du papier de verre fin
-> un pistolet à colle
-> une carte SD

Le but n'étant pas de gagner de l'argent, ça sera au prix coutant internet. Mais il faudra compter quand même le matos dont j'ai besoin pour réaliser les circuits imprimés, pour percer et pour préparer les câbles.

Dès que j'ai le temps je ferais une estimation. Mais je pense que ça doit passer en dessous de 60 euros.

Je vous tiens au jus.

A+

Super, prunkdump !

Finalement, équipé au complet, on n'est pas loin des fonctionnalités d'un XC Tracer, non ?
Avec la satisfaction d'avoir fait soi-même, de maitriser le code, de disposer d'un afficheur et pour un coût très attractif.

Si j'osais une proposition : pas possible de prévoir un "bouton" genre encodeur, pour ceux qui seraient tentés d'ajouter des choses, comme par exemple spécifier l'altitude de départ ?

Salut.

Bin au niveau hardware on est pas loin du XC Tracer. Après il manque tout le développement des logiciels qui gravitent autour. La gestion des traces, les mises à jours de firmware, la visualisation des traces, les convertions de formats de traces.

D'ailleurs je suis en train de programmer un bootloader qui permettrait de mettre à jour l'arduino par la carte sd et non par l'USB. Parceque je trouve pénible d'avoir à démonter le boîtier chaque fois qu'il faut mettre à jour le programme.

Pour l'idée du bouton, si tu regarde la vidéo il y a pas mal de place sous l'écran pour placer différents types de boutons. En plus l'arduino est juste en dessous pour la connectique. Donc ça ne posera pas de soucis. Mais j'aime pas trop les boutons et pour l'instant l'altitude est recalée avec le GPS. C'est quand même relativement précis. Après il est possible également de contrôler le vario avec l'accelerometre. Par exemple pour terminer la calibration dans le programme de calibration il faut le tourner à l'envers. On peut imaginer contreller des menus en "penchant" le vario.

Mais bien sur l'idée c'est que tout le monde puisse adapter le montage comme il veux. Mais pour l'instant je ne pensais pas mettre de boutons dans le "kit".

- Pour le bouton : je m'attendais à ta réponse.
Tu as raison : S'il y a de la place pour rajouter, a chacun de faire.
Sur la vidéo, pas évident de savoir : on voit le boitier de l'extérieur, sans voir comment c'est dedans.

- pour l'USB : pas moyen de donner accès sans ouvrir le boitier ?
  Alors, comment fais-tu pour charger l'accu ?

bonjour à tous, super projet! Je suis preneur aussi.

Dans l'idée de développer l'outil encore plus loin, je me demande ce qui serait possible de faire en soft. Je rêve d'avoir ce genre de vario-gps à code ouvert pour développer des scripts. Deux problèmes: 1) je n'ai pas de connaissance en électronique suffisante pour construire une boitier moi même, et 2) je ne sais coder qu'en matlab. J'ai aucune idée de la puissance du processeur de l'arduino ni de jusqu’où on peut aller en terme d'algorithme.

Les deux idées que j'ai actuellement en couche soft sont:

- proposer une aide en live (aller à gauche ou a droite, accélérer ou freiner) basée sur les mesures à court terme (cf le post http://www.parapentiste.info/forum/techniques-de-base-du-pilotage/modele-physique-pour-exploiter-au-mieux-les-thermiques-t46079.0.html)
- permettre les échanges dynamiques entre parapentistes pour cartographier l'aérologie locale (base sur une inférence bayésienne des mouvements passés et sur la topographie)

Salut !

@vmath54 : En fait il n'est pas possible de charger la batterie avec l'USB de l'arduino car lorsqu'il est sous tension il démarre. Ce n'est pas très pratique. Donc l'USB qui sort à l'extérieur du boîtier est l'USB du chargeur qui est indépendant de l'arduino. Il sert uniquement à la charge, il ne peut donc pas servir à uploader les programmes.

@finlard : Les deux points que tu cites sont très au dela de la performance d'un arduino. Il faudrait plutôt programmer cela sur une tablette ou un portable qui reçoit les données du vario. Il faut voir avec l'équipe de XCsoar. Je ne sais pas ce qu'ils utilisent comme language de programmation et les fonctionnalités qu'il ont déjà implémentées.

Mais je répète le but n'est pas de juste fournir un vario à monter qui fonctionne. Mais bien de permettre à tout le monde de le modifier comme il le souhaite. J'espère d'ailleurs profiter moi même de toutes les idées intéressante qui vont émerger !   ;) 

A+

ok merci pour la réponse! Je viens de voir que pour le point 2 c'est déjà fait chez XCsoar ;)
https://www.xcsoar.org/discover/2016/08/12/xcsoar-6-dot-8-7-released.html

Pour le point 1, je pense que l'algorithme est beaucoup plus simple et peut facilement est importé sur un arduino.

idéalement, il faudrait deux petits accéléromètres accrochés à chacun des élévateurs qui enverraient en bluethoot (ou autre) les données au boitier principal afin de mesurer le roulis. C'est envisageable?

Salut,

@Prunkdump, merci encore pour les fichiers, j'ai eu beaucoup de boulot ces derniers temps et je me suis arraché encore un peu sur l'écran oled en fastwire mais cela ne fonctionne toujours pas, à la place du coup j'ai utilisé un écran oled en SPI. Du coup c'est parfait et cela laisse le bus I2C pour le MS5611.

@Vmath54, idem que prunkdump à propos du M0, j'en ai un et ai déjà essayé de faire fonctionner le code dessus mais sans succès pour l'instant car je ne sais pas comment gérer les timer. Si quelqu'un avance avec un Cortex M0  je suis preneur d'infos car le 328 est limite si on veut ajouter de nouvelles fonctionnalités au vario, surtout pour l'affichage.

Je commence tout juste à m'intéresser à l'Arduino ( grâce à vous)
Je retrouve mes bricolages d'ado à base de CI bien moins sophistiqués
Je vais me commander un kit pour faire joujou moi aussi

 :coucou:

@whistler, je suis intéressé également par l'adafruit feather m0 (pas encore commandé) ; tu peux nous expliquer les problèmes que tu rencontres ?

@vmath54: Comme dit précédemment je ne sais pas comment changer le code pour le faire fonctionner avec les timers du M0.

Il y a aussi le fait que le M0 ne laisse pas accès à son EEPROM, il faut donc utiliser un eeprom externe connecté en SPI (que je n'ai pas encore).

Bonjour !

@finlard : Je pense qu'il n'y a pas besoin de mettre deux accéléromètres sur chaque élévateur pour mesurer le roulis puisque le mpu-9250 sait déjà mesurer le roulis du vario. Il suffirait donc de constuire un support pour le vario qui communique bien au boîtier le roulis des deux maillons. Le reste c'est de la programmation et de la mise au point.

@whisler : Dommage que l'écran I2C n'ait pas marché. Je pensais que mon code était bon mais sans l'écran pour tester c'est toujours difficile de débugger. Content que tu ais trouvé une solution.

Pour le passage au Cortex M0 :

Dès que j'ai fini mon prototype complet avec le ATmega328 je vous enverrai comment paramétrer les timers sur le M0. Ce n'est pas très différent finalement du ATmega328 mais tous les noms de registre changent. Il faudrait donc adapter deux bibliothèques : ms5611 et toneAC.

Pour les interessés par le kit :

J'ai presque fini le code du bluetooth et je vais passer à la construction d'un premier prototype avec cette fonctionnalitée. Si tout se passe bien je donnerai le prix final et je redemanderai les personnes interessées pour faire la commande du matériel. Le temps de tout recevoir, cela me permettra de faire un petit manuel de construction parceque ce n'est pas non plus complètement évident. Voici une liste mise à jour du matériel nécessaire pour ceux qui voudraient prendre de l'avance :

-> un fer à souder fin
-> de l'étain et de la tresse à dessouder
-> une pince coupante fine
-> du papier de verre fin
-> un pistolet à colle
-> une carte SD

A+

Salut Prunk,
Encore une fois : Super projet !!!
une petite question : Tu es sur une version though hole ou CMS ?

@prunkdump j'imagine que fixer rigidement le vario aux maillons des élévateurs va poser un problème...Après si le vario est sur un cockpit ça devrait le faire, sur une jambe ça le fera moins.

@FRFM : Le kit serait en composants traversants. Le CMS me parait trop difficile à souder pour que le kit soit accessible à tout le monde. Mais en réalité les composants eux même sont en CMS. C'est juste qu'il seront fournis sur des plaques que l'on pourra monter en composant traversants.

@Finlard : Effectivement il faudrait un cockpit. Mais c'est également tout à fait possible de faire une fixation qui ne contrain pas les élèvateurs en écartement mais qui par contre communique totalement le roulis. On peut imaginer quelque chose qui ressemble à un règle pliable en deux avec le vario fixé sur la rotule et les extrémités fixées à chaque élévateur. Ainsi en "s'ouvrant" la rêgle peut suivre l'écartement des élévateurs et par contre il n'y a aucune souplesse dans le sens du roulis.

A suivre.

A+

Salut à tous!

je suis ce sujet depuis pas mal de temps, et je pensais fabriquer ma version cet hiver, mais je ne me suis toujours pas lancé. Du coup ce projet vario a améliorer soit même m'interesse pas mal! J'attend ton retour prunkdump pour que tu nous dise comment les commandes pourraient être faites  :)

Salut Prunkdump,

je suis en train de faire ma liste de courses. Je suis assez débutant en électronique et j'essaye de comprendre.


Si je pars sur le pro mini, est ce que j'ai besoin d'un booster de charge du coup? est ce qu'un element comme celui ci conviendrait ? https://fr.aliexpress.com/item/5PCS-Micro-USB-5V-1A-18650-Lithium-Battery-Charger-Module-Charging-Board-With-Protection/32665613547.html?spm=2114.06010108.8.48.nVhVe4

Ou cela fait double emploi avec cet élément : https://fr.aliexpress.com/item/20-PCS-BTA41-600B-BTA41-600-BTA41600B-BTA41600-BTA41-TO-247-40A-600V/32351819193.html?spm=2114.13010308.0.0.qy1oGD

Sinon ou trouver un interrupteur 1in comme tu le recommandes? J'en trouve nulle part...

Salut !

Bin oui comprendre c'est le plus interessants  ;) c'est l'interêt de l'Arduino !

Alors il faut bien distinguer deux choses. L'alimentation et la programmation de l'Arduino.

L'arduino pro mini n'a pas de connectique USB ni le composant nécessaire (usb to serial converter) pour le programmer. Il faut donc acheter un petit module comme tu as donné en lien pour le programmer. Ce module fournira aussi l'alimentation par l'USB pendant la programmation. Mais en général on ne le mettra pas dans le projet final. Il sert juste à programmer. Sinon autant acheté un modèle au il y a tout dessus (genre ceux de sparkfun).

Maintenant pour alimenter l'arduino en condition réelle on utilise généralement une batterie LIPO. Ces batteries sont un peu dangereuses car elles explosent à la surcharge. C'est pour cela qu'il faut intercaller une plaque de charge comme tu as donné en lien. Par contre attention, ce n'est pas très clair sur l'annonce, il faut bien acheter le modèle avec les deux sorties B+B- et OUT+ et OUT-. Le module plus simple (avec juste Bat+ Bat-) sert à fabriquer de batterie nomade pour téléphone portable.

Pour les interrupteur tu tape "pcb switch 0.1in". Tu vas tomber sur des trucs de ce genre :

https://fr.aliexpress.com/item/20pcs-SS12D00G3-2-Position-SPDT-1P2T-3-Pin-PCB-Panel-Mini-Vertical-Slide-Switch-Favorable-Price/32697537229.html?isOrigTitle=true

Amuse toi bien !

Autrement si tu veux profiter de l'achat groupé. Je pense que j'aurais finalisé l'évaluation du Kit d'ici la fin de la semaine (J'ai essayé de demander un prix au vendeur). Il faudra ensuite une vingtaine de jours pour que tout arrive.

Autrement si tu veux déjà commencer à t'amuser rapidement, les revendeurs français ne sont pas si chers que ça et livrent très rapidement.

A+

Merci pour la réponse rapide. Ok je vais peut être attendre ta commande pour le coup. Le module USB serial converter ne sera pas fournis dans le pack par contre si j'ai bien compris ?

En attendant je vais commander un kit arduino Uno histoire de m'exercer, aussi bien coté electronique que programmation. Ca occupera mes weekends pluvieux!

Salut !

Ca y est j'ai enfin fini de programmer le bluetooth et la communication avec XCSoar ! J'ai du batailler mais tout rendre maintenant dans le Atmega328 (arduino standard).  :?

Maintenant :
-> les trames RMC du GPS sont renvoyées par bluetooth (position et vitesse).
-> les trames GGA du GPS sont modifiées pour remplacer l'atitude par l'altitude barométrique puis envoyées (position et altitude).
-> des trames POV (openvario) sont envoyé avec la vitesse verticale (vario).

Je n'ai pas de retour du vendeur pour l'instant pour savoir s'il me fait une réduction. Mais à l'heure actuelle le kit coûterai : 46,56 euros. Avec toutes les fonctionnalités, bluetooth compris. Et pour Fsgecko il y aura le convertisseur USB to Serial dans le kit. Cela fait deux euros de plus mais c'est tout de même important si on veut changer le code du vario.

Je suis maintenant en train de monter la version définitive du kit pour vérifier que tout fonctionne bien.

Je vous tiens au courant.

A+

Wahou tu as bien bossé ! Curieux d'avoir ca entre les mains!

Et pour la boite tu fais comment? Je suis par contre assez calé en 3D et j'ai également un imprimante 3D pour faire des prototypes. Je pourrais apporter ma pierre à l'édifice en fonction du besoin et de mes compétences!

Salut !

Décidément vous avez tous des imprimantes 3d !

Pour le boîtier il y en a déjà un dans le kit. C'est un modèle standard trouvé sur internet. Mais une fois le montage de ton vario fait tu pourras essayer d'optimiser le boîtier pour le rendre plus petit. Tu pourra éventuellement ensuite, si tu le veux bien, fournir ton fichier pour ceux qui ont une imprimante 3d.

J'envois quelque photos bientôt du montage du kit de référence.

A+

Salut prunkdump,

Tu peux me compter dans la liste des intéressés par ton kit. Est-ce accessible a un débutant car ce sera mon premier projet électronique. Cela fait un moment que je voulais commencer et tu m'as donné l'envie de sauter le pas...
Merci de nous faire bénéficier de tes talents!

moi aussi je suis partant !

Salut  :coucou:

Je pense que le plus important pour parvenir à monter le kit c'est d'être patient. Il n'y a rien de très technique au niveau électronique mais tout est très petit. Il faut pas trop trembler :)

Mais une bonne loupe et un bon fer a souder et tout ira bien.

Tu pourras te faire une idée avec les photos.

A+ 

Bonsoir prunkdump,

Je suis l’avancé du projet depuis quelques temps et moi aussi tu peux me compter dans la liste des intéressés par ton kit.

Je me pose 2 questions :

1/ Si on fixe le vario à un des élévateurs (comme un syride) est-il nécessaire de mettre le capteur baro/Accéléromètre perpendiculairement au PCB ? ou ton code permet-il de calibrer les capteurs dans cette configuration ? ou est-il nécessaire de faire des modifications du code pour définir les axes XYZ ?
2/ Est-il possible d'envisager d'avoir un affichage tournant pour certaine information, l'écran est petit, il pourrait être intéressant d'utiliser une grosse font et d'avoir 2 ou 3 informations qui s'affiche alternativement au même endroit tout les X secondes 

Salut !

Content que tu sois intéressé !

Le code actuel du vario détecte la vecticale donc quelque soit l'orientation, le vario réagira de la même manière. Par contre il faudra travailler sur une bonne fixation aux maillons.

Pour les caractères en gros c'est possible. Mais il faut le programmer. C'est l'interrêt de ces varios avec le code ouvert. On peut tout modifier à l'envie. Si tu es novice en programmation tu trouvera bien des gens ici pour t'aider (moi y compris).

Si tu veut t'amuser en attendant il y a des kit arduino tout près pour débuter.

Autrement j'ai commencé les commandes pour réaliser 10 kits. Et j'ai fini le montage du prototype au niveau électronique. Il me reste à adapter au mieux le boîtier et à ajuster les connecteurs. J'envois bientôt les photos des étapes du montage.

 
A+

Salut Prunkdrump,

Un moment que je voulais monter ton vario, c'est chose faite la nuit derniére. (versio audio-only, tout monté "en l'air" )

- Tout marche Nickel du premier coup, et tout est super clair sur GitHub, bravo et merci.
- La réactivité est impressionnante. (j'ai monté pas mal de vario DIY ces derniéres années, cf mon tout premier message ici en 2006  :koi: ), le tien est au top la dessus, pas de doute.
- j'ai rajouté un potar 500ohm à la place de R1 pour régler le volume, c'est pratique et ça marche bien

L'axe d’amélioration que je vois concerne le son.
J'ai essayé plusieurs speakers dont celui de ta BOM, et je n'ai pas eu de résultat très agréable.
Après quelques bricolages vite fait sur les paramètres audios, je trouve que c'est meilleurs en baissant un peu la plage de fréquence. (avec un son trop perché d'entrée de jeux, je trouve que l'on a tendance a sur-estimé les ascendances faibles)
J'ai aussi baissé la durée de bip que je trouvais trop longue par défaut. (mais l'idéal serait que la durée des bips et l'interval soient variables et inversement proportionnels au taux de montée).

Dans tous les cas, merci pour le boulot et et partage dans le plus pur esprit opensouce, c'est la classe, et c'est une première sur les varios à IMU à ma connaissance.
(XCtracer avait promis de le faire pendant le crowd-funding, mais c'est resté une promesse de campagne : pas super fair-play).

bon bricolage à tous

Merci pour ta réponse prunkdump.

Je débute effectivement sur arduino ou pour l'instant je réalise de petit montage, je vais étudier ton code et je n’hésiterais pas à vous solliciter si j'ai dès difficultés.  Je vais attendre avec impatience les photos de ton proto et la réalisation de mon propre vario avec ton kit. Merci pour ton travail

Toujours preneur pour le kit! Super boulot en tout cas, c'est super de nous donner la possibilité d'en profiter.

Hé bien merci pour les compliments ! Content que ça fonctionne et que ça plaise !

Je suis effectivement très sensible à la philosophie de l'open source. Il va falloir d'ailleurs que j'ajoute l'entête GPL à tous mes fichers avant que certains aient l'idée de les utiliser en LGPL. Je pense d'ailleurs que si les constructeurs fournissait au minimum un systême de plugin ouvert sur leur vario ça leur permettrait de dynamiser leur communauté d'utilisateur.

Merci en tout cas pour les retours. C'est pour cela que je met le code à disposition. J'espère profiter des différentes idées et améliorations qui vont émerger. J'ai d'ailleurs eu un doute lorsque j'ai proposé le kit. Je ne voudrait pas trop casser la créativité des bricoleurs. Mais finalement ça fournira une base de travail et je voudrais surtout améliorer le code dans un premier temps. Et pour cela j'ai besoin que des gens volent avec car personellement je ne vole pas assez.

Alors pour les speakers c'est effectivement un problème. J'en ai moi aussi testé plusieurs sans vraiment comprendre d'où provenait les améliorations. A tu utilisé le L9110 dans ton montage (c'est un amplificateur) ? Voici mes quelques conclusions :

-> Le meilleurs son je trouve c'est avec un "gros" haut-parleur. Celui qui est proposé partout pour arduino. Avec en série une résistance 100ohms la puissance est suffisante et le son est bien doux. Par contre il est bien trop gros pour rentrer dans des petits varios.

-> Les mini-speakers semblent complètement inutilisables sans un vrai circuit d'amplification. Le son est soit trop faible, soit ça sature. En plus je ne comprends rien aux Watt indiqué sur le speaker. Ils ne semblent pas avoir directement de rapport avec la puissance du son. Le rendement varie beaucoup selon les modèles.

-> Les buzzers piezzos : il ne faut pas non plus qu'ils soient trop petits. Et le son est vite agressif. Je pense qu'il faut également un vrai circuit d'amplification. Ou du moins utiliser des condensateur pour fournir un signal alternatif. Et je ne suis pas encore au point dans ce domaine.

-> J'ai fait des essais avec des buzzers magnétiques. Et ça à l'air pas mal. Le meilleur que j'ai trouvé c'est le "kst-951ap". Malheureusement comme il n'est pas chinois il n'est pas facile de se le procurer en dehors des circuits professionnels. J'en ai essayé d'autres et le son est très différent. Et étonamment la résistance de ces buzzer varie pas mal selon les modèles. Je pense que c'est cela qui joue beaucoup. Le kst-951ap a une resistance de 40ohms et il est donc pas trop fort mais encaisse bien, il ne sature pas. Le modèle que j'ai mis dans le kit est plus puissant pour être sur qu'il n'y ai pas de soucis mais il sature un peu. On verra à l'usage s'il faut ajouter une résistance. (Attention ne jamais enlever les résistances sans le L9110). J'ai prévu dans le kit la possibilité d'ajuster le speaker.

-> Je pense aussi qu'on peut beaucoup jouer avec le boîtier. Si il est assez "lourd" il peut grandement adoucir le son et même faire caisse de raisonnance.

Est-ce que quelqu'un peu m'expliquer ce que signifie les Watt sur les résitances ? Si c'est le courant qu'on peut faire passer dedans cela voudrait dire que plus la résistance est faible plus il fait quelle soit grosse ?

En tout cas je veut bien des retours si tu trouve quelque chose de bien.

A l'état actuel du code la durée du bip est bien inversement proportionnel au taux de monté. C'est pour l'ensemble du "motif" que la fréquence change. Je pense aussi que la fréquence monte trop vite. Il faudrait voir pour ajuster les coefficients.

J'envois les photo bientôt.

A+

Les watt, c est effectivement le courant max a faire passer dedans avant que ca deteriore le composant.
A tension constante, la puissance est P=U*I=R*I**2
Je comprends pas trop ta question avec le correlation entre la taille et la resistance.

Salut !

Bin disons que j'ai un buzzer avec une résistance de 8 ohms que je trouve trop puissant lorsque je l'alimente directement en 3.3V. Pour baisser un peu le volume je veux ramener l'ensemble à 50 ohms en mettant une résistance en série de 42 ohms.

Le courant qui va passer dans l'ensemble est :

I = U/R = 3.3 / 50 = 66 mA

Au niveau de la résistance on a donc également une intensité de 66 mA avec une tension de 3.3V. Cela donne comme puissance :

P = U*I = 3.3 * 0.066 = 0.2178 Watt

Je suis donc presque déjà à la limite d'une résistance 1/4Watt ! Et si je veut quand même un peu plus de volume en mettant une résistance plus faible de 12 Ohms, avec le même calcul je me retrouve avec une puissance dans la résistance 0.54 W (ce genre de résistance est déjà très balèse en taille) !

Donc si je me trompe pas. Plus la résistance est faible (je veut juste diminuer un peu le volume) plus la puissance dans la résistance est forte, plus il faut une "grosse" résistance. C'est juste que c'est contre intuitif pour moi. J'aurais naturellement tendance à dire : moins la résistance "résiste" au courant moins elle chauffe (elle se rapproche d'un fil) mais en fait c'est l'inverse ....

Ou alors je dis des grosses bétises  :?    

Ben non
moins la résistance résiste et plus il passe de courant et donc plus elle chauffe

la puissance P = U x I donc plus le courant est élevé et plus la puissance a dissipée sera forte

Et comme I = U/R, ca donne P = U*U/R (U au carré sur R).
Donc, la puissance est inversement proportionnelle à la résistance

Hello Prunkdump !

Je passais par là et je viens de voir ton commentaire.
Peux-tu jouer sur le temps de commutation de ton PWM ?
Ton buzzer piezo doit avoir une certaine capacité qui te donne une constante de temps avec ta résistance série.
Si tu réduit ton temps de commutation afin de rester sous les 3*Tau, tu vas pouvoir diminuer le volume tout en préservant beaucoup d'autonomie et de chauffe.
Si ton buzzer est un 'coil', tu peux diminuer ton son en ajoutant de la capa en parallèle. Pour le reste, il faut faire très attention aux surtensions générées lors des commutations. Il est parfois nécessaire de 'clamper' le signal avec une zener.

Tu drive le buzzer directement depuis une patte de l arduino ou tu as un transistor entre les deux ?

A mon avis, il doit le driver avec un MOS ou autre. L'arduino ne doit pas être en mesure de sortir plus de 10mA....

Salut !

Je le drive avec un pont en H (le L9110 ) :

https://www.elecrow.com/download/datasheet-l9110.pdf

C'est prévu à la base pour des moteurs. C'est peut-être un peu bourrin. Peut-être pouvez vous me donner votre avis ?

L'avantage c'est que je peux commuter +3.3V -3.3V au lieu de +3.3V et 0V. Est-ce que un pont en H protège l'arduino des surtensions ? Peut-être pas ....  :?

Autrement effectivment je peut moduler le rapport cyclique du PWM pour baisser le volume. Je n'ai pas encor essayer pour voir ce que ça donnait par rapport à l'ajout d'une résistance.

Je en suis pas sur non plus que se soit bien de commuter un buzzer magnétique dans les deux sens (+5V, -5V). Ca marche mais je ne sait pas si il morfle.


Si vous pouvez m'aider de ce côté c'est avec plaisir !  :pouce:

C'est certainement mieux de moduler le rapport cyclique. Ca t evite de perdre de la batterie a chauffer une resistance ... et tu peux le modifer par le soft.
Pour le pont en H, c est peut etre un peu overkill. Avec un transistor simple, ca devarit le faire aussi.

Un truc comme ca peut etre :
https://forum.arduino.cc/index.php?topic=380219.0

Ton driver est conçu pour les charges inductives (moteur DC). Dans sa datasheet, tu peux remarquer qu'il a une diode intégrée "built-in clamp diode reverse the impact of the current ".
Quand tu pilotes ton buzzer en +3.3V/-3.3V, lui voit 6.6Vpkpk. Cette solution est 'pas mal' mais je dirais un peu surdimensionnée !
Je n'ai pas trop le temps d'y jeter un coup d'oeil, mais en jouant sur la commande de ton driver, tu devrais pouvoir ne le faire commuter qu'à moitié en gardant une des deux input à 0 ou 1.

Sinon, il y a une solution où tu devrais pouvoir obtenir un son correct avec juste un MOS / voir MOS + Booster coil.

Ton Arduino, lui est protégé car il ne fait que piloter ton driver.

Oui


Il me semble que  la librairie que tu utilises (Tone AC) permet justement de faire du Push-Pull (+3,3 / - 3,3V) sans ajouter de composants externe, non? (Dans les limites du courant que la carte peut sourcer bien-sûr).
est-ce bien ce que tu fait? (je ne sais pas comment ça se configure exactement...)


Sur d'autre vario que j'ai pu voir (base de PIC et non d'ATmega 328), ça fonctionne fort et clair sans amplification ni transistor, juste avec un buzzer piezo large bande (kingstate Kpeg006) branché sur 2 sorties PWM dephasée de 180°
(c'est aussi le buzzer qu'il y a dans le Xctracer d'ailleurs).
Je pense aussi (intuitivement) qu'un simple buzzer consomme aussi beaucoup moins qu'un speaker avec son ampli...


OK, j'avais mal vu, sorry.

Pour la fixation aux maillons je pense à 2 solution en fonction du boitier utilisé

Sur un boitier standard, je pense coller à l'araldite 2 velcros double face et de renforcé avec 2 vis. On fixe le premier velcro juste au dessus du maillon et le deuxième on le prend au dessus de la poulie d’accélérateur en laissant l’arrière libre pour pouvoir l'utiliser  pour piloter. Les velcro son en haut et en bas du boitier collés sur le dos

Pour un boitier en impression 3D on peut imaginer un passage pour les velcros (j'ai déjà conçu une fixation de go pro pour une sangle d'épaule de cette façon)

je viens de recevoir mes pieces montage ce week end  :P

sinon prulnkdump auris tu un lien pour le boitier j aime bien le tiens :jump:  le mien n apas de vis  ?

Salut !

Merci à tous pour les tuyaux sur les montages des buzzers/speakers  :pouce:  Je pense que pour l'instant je vais garder le L9110 ça permettra de faire toutes les configurations possibles par la suite puisque on garde le contrôle sur les deux sorties. On peut donc faire du push/pull en +-3.3V ou du push simple sur n'importe laquelle des deux pâtes et tout ça en software.

Pour PtiKiki c'est effectivement pour continuer à utiliser les push/pull de la librairie toneAC que je suis parti sur le L9110. Il permet de faire ça avec des limites de courant plus hautes (800ma). En plus il coûte rien. De toute façon ce n'est jamais bon de brancher un speaker directement sur l'arduino, ça peut perturber la régulation interne du courant. Avec le L9110 il ne fait plus que "commander" le courant et cela l'isole du montage du speaker.

Pour les comparatifs de consomation je ne sais pas. Je suis pas sur que ça ne soit pas plus faible avec un ampli pour un volume équivalent. Il faudrait mesurer.

@jpg63 : je veux bien voir les photos de tes prototypes si tu fais quelques essais. Je n'ai jamais vu vraiment comment fonctionnait les fixations aux maillons.

@Guillaume1 : Pour le boîtier tu cherche Szomk AK-H-13. On le trouve pas cher sur Ali..machin (j'aime pas trop faire de pub). Par contre attention ça passe vraiment très juste si tu compte tout rentrer. Mais il y a le même modèle plus gros je crois.

Des new des kits :

J'ai presque tout commandé pour réaliser 10 kits et pas d'inquiétude je ferais passer en priorité ceux qui m'ont contacté par ce fil.

Sur le prototype j'ai tout monté sauf l'écran et le bluetooth. Ca avance doucement car je doit prendre des photos de la procédure de montage pour le manuel et toutes les mesures pour préparer les 10 kits suivants. Je voulais vous envoyer les photos mais google photo n'arrête pas de bugger. Je vais réduire la taille des images et réessayer. Ca sera fait demain soir je pense.

Amusez vous bien ! +

Youpi!!  :jump:

 Merci pour le boîtier
Je reviens avec le composant 4050 pourquoi ne prends tu pas le 3 V 3 sur l'Arduino directement c'est juste pour mon info merci;-)

Salut !

Si si, je me sert de la sortie 3,3V de l'arduino pour alimenter l'écran. Mais pour toutes les autres connexions : l'arduino s'il est en 5V, envoie du 5V dans l'écran et s'est pas bon pour lui. En plus il faut savoir que du coup ça consome du jus en permanence sur certains pins.

Le principe du 4050 c'est que tu lui donne du jus à la tension que tu veux. Il il te le faut sortir sur les pattes que tu veux avec la même tension. Par contre pour controler ces "ouverture" tu peut utiliser une autre tension. Dans ce cas on fait sortir du 3.3V en commandant les ouvertures avec du 5V.

J'espère que ça éclaicit un peu la chose.

A+

a ok je comprend mieux  ;) 

parcontre dans le premier montage du premier post  l ecran est monté direct sur l arduino ( comme je lai deja monté dans ma premiere version )  c est pour  ca  que je comprends pas tous ??? 😭😭

Bonjour à tous !

J'ai monté le projet de sinseman et je suis repassé presque par hasard sur le fil.

Grâce à prunkdump je viens de comprendre: mon afficheur baisse en intensité à chaque beep...J'ai monté un bête buzzer de carte mère pc direct en sortie de l'arduino  :?

J'ai bien envie de me remonter un vario "V2". prunkdump, si tu as des kit en trop, ou si il n'est pas trop tard, je suis preneur. Sinon je suis déjà sur ton git-hub  8)

Je n'ai aucun souci pour souder /percer/coler mais niveau programmation je part de tres loin et c'est bien compliqué pour moi...

Bravo à tous

 prunkdump pour ma fixation de gopro sur l'épaule, voici les photos du modèle 3d, je fais des photos d'une fixation de syride et de ma fixation (impression 3D) - et je post tout cela rapidement

(http://img4.hostingpics.net/pics/483809supportepaulegoprov2.jpg) (http://www.hostingpics.net/viewer.php?id=483809supportepaulegoprov2.jpg)

(http://img4.hostingpics.net/pics/570777supportepaulegoprov22.jpg) (http://www.hostingpics.net/viewer.php?id=570777supportepaulegoprov22.jpg)

(http://img4.hostingpics.net/pics/29894820170318112907.jpg) (http://www.hostingpics.net/viewer.php?id=29894820170318112907.jpg)

(http://img4.hostingpics.net/pics/63279320170318112920.jpg) (http://www.hostingpics.net/viewer.php?id=63279320170318112920.jpg)

(http://img4.hostingpics.net/pics/94039320170318121842.jpg) (http://www.hostingpics.net/viewer.php?id=94039320170318121842.jpg)

(http://img4.hostingpics.net/pics/98765320170318122019.jpg) (http://www.hostingpics.net/viewer.php?id=98765320170318122019.jpg)

Salut à tous  :trinq:

@Guillaume1 : Effectivement presque tout le monde branche l'écran directement à l'Arduino. Ca marche mais ce n'est pas bon pour l'écran  :? . C'est pour ça que j'ai utilisé le 4050. On voit d'ailleurs plusieur montage sur le net qui utilisent ce composant. Mais cela complique un peu le circuit. L'idéal c'est que tu te procure un arduino 3.3V car maintenant presque tous les composants fonctionne avec cette tension.

@GtD73 : Oui brancher le Buzzer directement sur l'arduino n'est pas bon  :grrr:  et si en plus tu n'a pas mis de résistance tu risque très rapidement de le crâmer. Il faut au minimum que la résistance de l'ensemble soit de 120 Ohms.

Pas de souscis pour le kit !  :pouce:  Pour l'instant j'ai 8 personnes intéressées (avec toi) donc ça passe sans problème. Si il faut on en fera plus pour les suivants. Mais actuellement j'ai déjà avancé pas loin de 500 euros pour la commande totale. J'enverrai la potentielle suivante quand j'aurais remboursée celle ci (ça laisse immaginer  l'investissement très conséquent qu'il faut réunir lorsque l'on veut lancer un "vrai" vario).

Pour la programmation, il faut s'y mettre doucement. Je ferai sûrement un petit tuto pour indiquer les paramètres que l'on peut modifier dans mon code pour "jouer" avec le comportement du vario. Et ça c'est plutôt simple.

@jpg63 : Je suis quand même impressionné des qualité que vous obtenez avec vos imprimantes 3D  :shock: . Les fixations de GoPro c'est quand même au dixième de millimètre près et il faut des bonne propriétés mécaniques (souplesse élasticité). En tout cas à par les irrégularités de teinte le résultats fait très pro ! Joli boulot ! Tu vas pouvoir te faire un super boitier !

Des news des kits :

Alors comme promis voici les photos du début du montage :

https://goo.gl/photos/b6bAUP3xGk4so8b16

Mais malheureusement la dernière étape ne passe pas...  :? Sans le bluetooth tout rentre impec, mais avec, le vario est trop épais est je ne peux pas fermer le boîtier.

Le problème vient de la broche que vous voyez sur le dernière photo. Cette broche devait recevoir une fixation "Dupont" qui permmettait de relier l'écran. Et la plaque bluetooth devait venir par dessus (au dessus de l'antenne GPS avec la nappe qui passe dessus). Mais les aiguilles sont trop hautes. Et si je les coupe plus court la prise femelle ne prend plus dessus.

Il va falloir que je change ces aguilles droites par des aiguilles à angle droit pour fixer les broches horizontalement. Mais cela m'oblige à reprendre un peu le design du vario. J'ai testé dans cette configuration sans fixer les fils et ça rentre !  :D  Donc ça devrait passer !

Je change ces aiguilles et je vous montrerai le montage final.

A moins que l'un d'entre vous ai une idée pour fixer un fil perpendiculairement à la base d'une aiguille carré (type dupont). Ya bien des terminaison en "anneau" mais elles sont beucoup trop grosses et servent à recevoir une vis.

A suivre ....
 

 



 

superbe !!!!!!!!!!!
Quel gros boulot de documentation !

Hello prunkdrump! C'est super bravo!

Au passage, je veux bien te prendre un des deux derniers kits...

Bonne journée !

Je ne me rappelle plus si je suis sur la liste officielle mais je suis bien sur interesse pour te prendre un kit.

super les photos! C'est bien explicite, il n'y a meme pas besoin de texte ;)

On peut te faire un virement dès maintenant si tu veux rentrer vite dans tes frais.

Bonsoir

Si il reste un kit , je suis également preneur. Le vario que j'ai monté grâce à prunkdump fonctionne bien ( il a quand même quelques bugs de fonctionnement) et celui que j'ai mi en chantier avec un gps n'avance pas beaucoup ( je me disperse dans les occupations) . Effectivement, au vu des photos tu as vraiment fait un gros boulot d'optimisation...

Chapeau bas    Olivier

super taf  :vol:

tu fais ca ou la platine avec le circuit imprimé ?

Salut,

Enorme travail prunkdump, impressionné par la recherche d'optimisation de l'espace et de simplification de l'objet.

Etant assez novice en programmation, je suis également interessé par un petit inventaire des variables sur lesquelles on peut jouer et leur fonction. Ca m'aiderait à comprendre le déroulement du programme.

Merci en tout cas de mettre à la portée du plus grand nombre ce genre de projet.

Cela veut il dire qu'il faut un boitier un peu plus gros ?
difficile de t'aider sans avoir le truc sous les yeux.

Salut à tous. Merci pour les encouragements !

Pour le circuit imprimé je fais ça dans mon garage avec une imprimante laser, une crêpière et une lampe à UV de manucure :)

Je peux donner des tuyaux si ça interesse des gens.

Autrement voici la liste actuelle des potentiel interessés. Il y en a 11 mais je devrais avoir de quoi faire un kit de plus. Il y aura sûrement des désistements donc vous pouvez encore vous manifester. Je verrai après si j'ai le courage d'en faire d'autres.

- Air
- Van Hurlu
- Vmath54
- Tomrider84
- Finlard
- Fsgecko
- Nightrider
- Jpg63
- GtD73
- Ptitkiki
- FRFM

Le plus long en fait c'est de tailler les boîter. J'ai une fraise et une colonne mais je n'ai pas d'étau qui va dessus. Donc je fraise en tenant le boîtier à la main et ça demande beaucoup de concentration pour ne pas faire de bêtises  :? 

Quelqu'un sait comment ça s'appelle ces étaux avec deux manivelles pour faire coulisser dans les deux sens ? Ca existe pour les petites colonnes de précisions ? Autrement si quelqu'un à une astuce ...

a oui ca m interresse fort surtout pour bricoler des belles chose moi je fais ca avec de fil c pas bo du tous

c'est une table à coordonnée, ou "compound table".

genre ça :
http://www.proxxon.com/en/micromot/27100.php
(80 € TTC...), tu devrais intégrer une quote part dans le prix du kit ;-)

Si non, je pense que la plupart des personnes peuvent aussi faire le trou eux même, Tu nous a déja sacrement pré-maché le boulot  !

Salut Guillaume,
Le plus simple c'est OSHpark :
https://oshpark.com/
Tu dessines ton circuit et tu upload le design. Ils te font un devis automatique et tu valides. Les resultats sont tres beaux et les prix assez raisonnables.

Merci Ptitkiki c'est exactement ce que je cherchais ! Je vais voir si j'investi mais j'aimerais bien rester sous les 50 euros pour le kit. Ca fait un peu partie du défi ;) Mais si ça me fait trop de boulot je ferai les fraisages avec de la marge et je laisserai à faire la finission au cutter. De tout façon il faut finir au cutter pour enlever tous les petits fils de plastiques.

Pour ceux qui veulent faire des circuits maison. Il y a un excellent tuto ici :

http://hackaday.com/2016/09/12/take-your-pcbs-from-good-to-great-toner-transfer/

Le plus important c'est la température. Une fois qu'on a trouvé la bonne ça va super vite et on fait des circuits imprimés en 10 minutes.

Moi je les vernis ensuite avec une lampe à UV de manucure à 13 euros, du papier calque, et une seringue de "UV curable solder mask". Il y a une très bonne vidéo ici :

http://www.youtube.com/watch?v=y-bjbF8USHc

Pour le logiciel, j'utilise Kicad.

A+
 

(@) prumkdump
je cherche une carte éternet pour un Arduino Uno R3, des sondes de températures, des relais pour connecter du 220v 16A,
tu as de l'avance sur moi qui débute avec le Mooc des Gobelins (presque fini)

Chez qui ? tu te fournis
fiable et pas trop cher  :roll:

Je te répond par MP.

Salut à tous !  :coucou:

J'ai fini par trouver une solution pour faire rentrer le bluetooth  :D .  Vous pouvez donc maintenant voir le montage du kit jusqu'au bout :

https://goo.gl/photos/b6bAUP3xGk4so8b16

J'ai fait quelques ajustement niveau programmation. Mais le bluetooth n'est pas encore satisfaisant de mon point de vu. Il faut que je fasse en sorte qu'il prenne moins de ressource. Mais j'ai une idée  :prof:

Autrement, j'ai reçu les 11 boîtiers, les 11 plaques de circuit imprimé, et une grand partie des composants. Je vais pouvoir commencer à préparer les kits. Je ferai quelques photos de l'avancement.

A+

Joli tout ça !
Si je peux me permettre:
Avec une dremel  tu n'arriverai pas à "opérer" ton boîtier plus facilement ?
Pourquoi ne pas mettre de la gaine Thermos rétractable à la place du scotch sur les câbles afficheur ? J'en ai plein de plein de taille differentes
Si c'est pas trop de boulot pour toi je veux bien quelques truc pour tripatouiller le code. Je me suis amusé à faire une horloge sur 4 digit ben c'est laborieux...
Mais très beau travail  :bravo:  :bravo:  :bravo:

Très beau travail.
Chapeau d'avoir pu tout fait rentré dans ce petit boitier
j'ai hâte de construire ce petit vario. Ce projet open-source m’intéresse beaucoup. Pouvoir apporté ma maigre contribution, pour aider à l'améliorer, me parait encore plus motivant

super boulot, le boitier a vraiment de la gueule une fois fini! J'ai hate de monter ça ;)
J'essayerai d’implémenter l'aide au thermique dans la partie soft!

Salut !

Ouai c'est vrai que j'ai un peu honte de mes bouts de scotch  :oops: Mais il fallait avancer et c'est tout ce que j'avais sous la main. Effectivement pour les kits je vais commander quelques câbles thermorétractables pour faire plus propre.

J'ai bien une Dremel avec sous support colonne et une fraise HSS. Mais il faut quand même tenir le boîtier à la main et il faut rester concentré car une mauvaise manip et le plastique ça part vite. Mais bon je crois que je vais faire comme ça et vous ferez la finission au cutter.

Pour tripatouiller les code : Vous pouvez commencer par lire le début du fichier "variometer.ino" ou sont déclaré toutes les constantes. Ensuite pour chaque "libraries" il faut ouvrir l'entête en ".h" pour voir ce que l'on peut paramétrer. Par exemple la librairie "beeper" est responsable des bips du vario. Si on ouvre "beeper.h" on voit le réglage des fréquences et des temps de bip. Mais Dès que j'ai le temps je ferais une liste détaillée des paramétrages rapides.

Ensuite,  j'ai fini ma modif dans le code pour le bluetooth, mais pas moyen de faire marcher la carte SD et le bluetooth en même temps  :(  Pour l'instant ça prends trop de mémoire vive. Il va falloir relire le code pour l'alléger. Mais comme je veux pas vous faire trop attendre je vais commencer la fabrication des kits et on verra après pour améliorer le code. Comme ça vous pourrez proposer aussi vos améliorations.

Bonne continuation. Je vous tiens au courant.

slt
je n ai pas encore eu le temps de monter la version v2 de prunkdump problème de pc windows 10 de m***e lol


mais en me servant du ma v1 hier je me suis rappelé que le contraste de l écran variait suivant je ne sais quoi mais il faut que je joue avec le contraste à chaque fois .est ce que le probleme est identique sur le tient prunkdump ? car il n'y plus de boutton de réglage :(  :(

Salut.

Ouai les écrans de nokia sont assez sensibles. Voilà ve que je fais d'habitude :

-> Tu pousses les pattes métalliques de l'écran par dessous pour détacher l'écran du circuit imprimé.
-> De l'autre côté du circuit imprimé tu as 9 contacteurs parallèles. Tu les nettoies bien avec de l'acétone ou un dégraissant.
-> Ensuite tu les rayes doucement avec la pointe d'un tournevis pour que la surface ce soit pas trop régulière.
-> Tu vérifies ensuite que les pattes de l'écran ne sont pas tordues. A defaut tu les redresse avec une pince.
-> Tu réenclange le tout en vérifiant que les pattes s'emboîtent bien.

Au niveau software, sur la dernière version de mon code tu peux régler le contraste.

Tu peux le faire aussi avec la librairie de base du 5110 il y a un paramètre lors du "screen.begin(SPI_CLOCK_DIV4, contrast)". Par défaut c'est 40. Tu peux essayer 55 ou 60.

Si le constraste est encore irrégulier il faut vérifier la tension que tu envois à l'écran. Vérifie qu'il est bien raccordé à la broche 3V de l'arduino.

Bon courage.

Excellent travail Prunkdump. Je suis impatient de monter le mien!

Top top !!!
La lipo faut quand meme bien essayer de la proteger. C est des petite bestioles qui supportent assez mal d etre torturees.
En gros, ca peut prendre feu quand ca se perce ...

Bonjour à tous,
je viens de tomber sur ce forum,
j'ai betement fais de mon côté mon vario avant de chercher un peu sur le net et de tomber ici...
voilà la version de mon vario sur la meme base (arduino nano en attendant de recevoir un mini+afficheur 5110+ bmp180)
je vais lire tranquillement tout ce forum, j'ai surement raté des trucs...
mon gros soucis étant le filtrage du bruit du BMP180... (avez pris plutot le MS5611? même façon de le piloter ou il faut une librairie spécial?)
sur le github c'est encore la version de base? vous parlez de GPS, vous l'avez déjà intégré?

félicitation pour ce projet et de le maintenir comme ça sur la durée

amicalement

Salut à tous,

prunkdump, Chapeau pour le boulot et encore plus pour le partage !!  karma+  karma+

Quel temps passé, j'imagine même pas !!

J'ai aussi une imprimante 3D et je touche un peu en conception (c'est mon job).

Du coup, je suis aussi preneur d'un kit même s'il n'est pas complet et sans boitier percé, ça me vas. Sinon je me commanderai à partir de ta BOM. En plus j'ai déjà quelqu'un de ses composants.
Je m'étais fait une ancienne version mais ça déconnais pas mal... Même si ça ma beaucoup amusé.


Paul


PS : en remerciement, t'es le welcome pour un hébergement si tu reviens à la dune. (les autres aussi, hein ;)  :eclaircie:

j'ai tout lu avec avidité, je réitère: BRAVO!! superbe boulot!!!
je vais surement mettre de côté mon proto et me rapprocher du tiens qui est super abouti.

 

on pourrait imaginer un rassemblement annuel à la Dune entre ardouineurLCV
journées => wagage
nuits => codage et bidouillage

Elle est grande ta maison Xiboard ?  :roll:



 :sors:

yes, un Parhackathon à la dune !  :pouce:

Merci pour les encouragement ! Et ouai la dune ça attire du monde :) Moi j'ai changé pour la Yaute maintenant mais c'est sur que ça manque !

Oui ça prends du temps de faire tout ça mais ça m'amuse bien  :D  C'est bien foutu ces arduinos quand même ! Ca permet à M. Tout-le-monde d'accéder à l'électronique facilement. C'est concret, on a rapidement les bénifices de son travail.

J'attends avec impatience que vous aillez monté tout ça pour que vous puissiez me donner des tuyaux sur l'amélioration du vario. Je voudrais déjà bien finaliser les fonctions de bases (alti, vario, vitesse, finesse, trace GPS, bluetooth, connexion avec XCsoar). J'espère que vous avez prévu de voler avec  ;) J'ai besoin de retour sur des essais en vol.

Je commence les kits ce weekend. Je pense qu'ils seront fini d'ici la semaine suivante. J'ai fait évoluer encore un peu le PCB par rapport aux photos. J'ai ajouté un switch pour couper le bluetooth s'il ne sert pas (pour économiser de l'énergie) et il n'y à plus besoin du fil à raccorder en travers au bluetooth.

J'espère également finaliser un bootloader avant de vous envoyer les kits. Parceque pour l'instant c'est dommage il faut réouvrir le vario chaque fois que l'on veut mettre à jour le code. Je voudrais qu'on puisse mettre à jour le firmware depuis la carte SD. Ca n'a pas l'air trop compliqué. Il y a un bootloader très bien documenté : "optiboot". Il me faut juste réussir à adapter le code.

Il me faudra également des conseils pour envoyer les kits. Apparemment la poste c'est minimum 6 euros ... Mais bon je vois pas d'autres solutions. A moins peut-être d'essayer de ranger bien à plat pour que ça passe en lettre (peut-être suivie). Ca ferait donc dans les 46.89 + 6 = 52.89 euros pour le kit avec les frais de port.

@Xiboard : Tu bosse dans la conception en électronique ou en modélisation ? Parceque ça m'interesserait également d'essayer de faire par la suite une version CMS. Mais là il va falloir que j'apprenne vraiment la théorie et pas juste la programmation. Autrement pour le kit je n'ai pas très bien compris si tu voulais quand même le boîtier ? Il doit me rester de quoi en faire un dernier.

@alphatesteur : Non non, il ne faut pas mettre de côté ton proto. Il pourrait y avoir des idées d'amélioration pour le kit ! Si tu es interessé il va falloir que je m'organise. Parceque 12 ça passe encore mais 13 kits j'ai pas de quoi les faire avec la commande que j'ai passé. Je peux éventuellement passer une commande individuelle mais ça reviendra plus cher que les 46.89 euros.  Ou alors il faut trouver encore 10 personnes (ou du moins 6 ou 7 pour que ce soit rentable).

A voir.

J'envois des photos dès que commence la réalisation des kits.

Au niveau composants j'ai presque tout reçu.

A+

vraiment hate de monter et tester cet objet!

Pour l'envoi tu peux aussi essayer avec mondial relay https://www.mondialrelay.fr/ . C'est un peu moins cher que la poste (4,5€), mais les plages horaires pour déposer les colis sont plus large : Tu payes sur internet après avoir rentré l'adresse du destinataire, tu déposes le colis dans un relay et le livreur emporte le truc. Le gros avantage que je trouve par rapport à la poste c'est que les points relais sont ouverts plus tard le soir, et souvent le samedi toute la journée. La poste à coté de chez moi c'est 9h 17h... Pas très pratique!

@prunkdump : Non j'suis en conception méca, modélisation et intégration :/ Jamais mis les mains dans le CMS (bon si, une fois)
Le kit, si tu as un complet je suis preneur ! Sinon je peux faire avec les restes si pas complet :/

@Van Hurlu : Ouai, j'ai une grande maison et grand terrain ;) mais je suis tout de même à 40-50min de la dune.

Pour le CMS, je n'ai quasiment pas d experience de design de circuit imprime mais j'ai tout le materiel pour souder des protos (station a air chaud et four a refusion).

@prunkdump : Super travail! Pour les retours d'expériences en vol tu peux compter sur moi... Il me tarde de faire joujou avec et apporter mon humble contribution a ton fabuleux travail! Concernant l'avance que tu as fait, c'est également un geste généreux, quand tu auras le prix final, donnes nous tes coordonnées en MP pour le règlement. Cheque?
Je serai a la Dune fin mai début juin, si t'es dans le coin, la premiere tournée est pour moi  :trinq:

Ah c'est sûr que je vais voler avec mais par contre je ne vais peut être pas pouvoir faire un retour sur toutes les fonctionnalités  :|

merci prunkdump pour la proposition,
 je pense que je passerai dans les mois à venir à ce magnifique projet super abouti
mais pour l'instant vraiment pas de temps de dispo.
le mien est hyper rudimentaire et cheap (juste un arduino +bmp180+LCD5110), mais il fait l'affaire pour l'instant.
en tous les cas je vais suivre tous ça de pres,
et dès que je me trouve du temps je repartirai surement sur le tiens :-)
je n'ai pas trouvé de video ou de screenshot de l'interface visuelle dispo en vol de ton projet: tu as bossé dessus? ça donne quoi?
j'avoue que pour faire tenir toutes les infos interessantes sur l'affichage en vol c'est coton vu la resolution et la taille de l'écran 5110.
le seul truc que j'aime bien sur le mien: c'est le graphique de la derniere minute de vol (en terme de vario), c'est tout bete mais bien pratique pour voir ce qui vient de se passer, as tu prévu un truc de ce genre?

J'ai pas regardé les spec (conso et NITS) mais j'aime bien l'idée d'un écran 5" pour la carto
http://www.buydisplay.com/default/arduino-5-inch-tft-lcd-touch-screen-shield-ra8875-library-for-mega-due-uno

Si tu veux gerer la carto, un arduino va etre un peu court au niveau calcul non ?
Il faudra passer sur du intel edison par exemple.

Salut !

Bon ça y est j'ai fini la première étape (la plus délicate) : les circuits imprimés.

https://goo.gl/photos/THdLaiRPWwTT4MGW9

Maintenant je vais attaquer le Dremel. Découpe des circuits et des boîtiers. Je mettrais d'autre photos de l'avancement.

@alphatester. Très bonne idée ce graphique ! En plus (c'est un peu technique mais) il est possible de le programmer de façon très "light" sans les bibliothèques graphiques. C'est un point important car l'écran ça prend vite beaucoup de place sur la mémoire de l'arduino et je suis déjà très juste. Autrement sur la version actuelle le vario affiche :
-> altitude
-> vario
-> vitesse sol
-> finesse sol

J'aimerais bien ajouter le compas aussi car il y a un compas électronique intégré. Mais ça va devenir très juste sur le code. Il va falloir encore grapiller mais je pense que ça peut passer.

@air. Effectivement un arduino est vraiment trop light pour la carto. Autant partir directement sur Raspberry Pi (il y en a des version très compactes). Autrement tu peux faire comme beaucoup de varios : tu fais un modèle simple avec bluetooth et tu met un logiciel de carto sur un mobile ou une tablette.

Autrement une idée comme ça. Sur mon kit il y as encore de la place sous l'écran. Est-ce que quelqu'un aurait déjà bossé sur un chargeur solaire ? Ca pourrais être pas mal d'ajouter ça. Mais peux être que c'est vraiment trop limite pour alimenter vario, gps, carte sd et bluetooth... Il faudrait que j'évalue la consomation. Ca doit pas être trop important car depuis que j'ai fait le dernier proto j'ai jamais chargé la batterie. Mais quand même par rapport à des petit panneau solaires ....

Autrement je met en pièce jointe la dernière version du schema du circuit pour ceux qui voudrait réaliser le vario complet eux même.

A+



 

 

Salut Prunkdump,

Merci encore pour l'avancement du projet.
J'ai une interrogations concernant l'envoi des données à XCSoar via bluetooth,
Est-il facilement possible de ne pas modifier les trames nmea avant de les envoyer et d'ajouter dans la trame openVario l'info de pression du capteur baro, comme cela on aurait l'altitude GPS et l'altitude baro et cela permettrais de détecter une déviation de la mesure de pression dans le cas où cela se produirait.
De plus pour l'utilisation du vario dans des conditions plus ou moins officielles, je ne suis pas certain que de modifier les trames avant envoi soit bien vu, mais sincérement niveau compèts et compagnie j'y connais rien du tout :)

Et aussi concernant ton schema je ne comprends pas pourquoi tu connecte l'alimentation des divers capteurs ecrans et autres sur la pin RAW de l'arduino et non pas sur la sortie 3,3v?

Salut Whistler !

Honnêtement je ne connais rien à XCSoar ....  :oops:  Car malheureusement je n'ai pas de quoi le faire fonctionner. Donc je pensais bien faire en remplaçant l'altitude GPS par l'altitude barométrique dans les trames. Mais si tu me dis que cette gestion est déjà prévu dans le logiciel c'est vrai que ce n'est pas très utile ...  :? . Tu connais les autres logiciels de carto ? Ca fonctionne pareil ?

Ce n'est pas trop compliqué de modifier le code pour qu'il agisse comme tu le veux. Tu veux que je te fasse la modif ? Si oui t'as de quoi tester actuellement ? Ca m'interesserait  :D  Tu as déjà testé mon code actuel en "vrai" sur XCSoar ?

Pour le RAW à la place du 3.3V : J'ai lu sur plein de forum que le régulateur 3.3V de l'arduino était un peu léger. Donc si on lui branche trop de chose dessus la tension risque parfois de baisser. Et j'ai remarqué que toutes ces plaques de capteurs ont déjà un régulateur dessus donc autant leur envoyer du 3.7V directement. Comme ça même si la tension baisse un peu il y a encore de la marge. Le seul composant qui n'en a pas c'est l'écran. Et si tu regardes je l'ai laissé sur le régulateur 3.3V.

Ya même des trucs ou c'est un peu l'arnaque. Par exemple j'ai lu le datasheet du regulateur qui est habituellement mis sur la plaque de la carte SD. Et bin il n'est pas capable en réalité de réguler du 5V. Mais avec du 3.7V on est dans le specs.

Merci encore si tu peux me faire des retours sur XCSoar et sur les autres logiciels.

PS : Je suis en train de travailler sur une adaptation pour le planeur avec un vario à TEC  (total energy compensasion). C'est un vario qui soustrait du vario les variation d'altitude provenant des commandes. Si par hasard il y a des gens interessés pour tester ...

 PS2 : C'est toi qui bossait sur M0 ? Sur le site de teensy j'ai trouvé une bibliothèque pour les timers !

https://www.pjrc.com/teensy/td_timing_IntervalTimer.html

Du coup se serait assez facile d'adapter la lybrairie du ms5611.


  

Hello Prunkdump,

Concernant les logiciels de carto, du moins ceux open source, ils sont pour la plupart basé sur XCSoar, tu as XCTrack plus axé sur le cross et TopHat (que j'utilise actuellement sur une tablette e-ink Nook simple touch) qui est une version simplifiée de XCSoar (sans toutes les grandes options pour les planeurs et companie). Et il fonctionnent de la même façon pour la réception de données, trames avec divers protocoles gérés dont NMEA et OpenVario.

J'ai essayé de faire cette fameuse modif pour envoyé la trame nmea telle quelle, ainsi qu'une trame openvario contenant vario(E), la pression statique(P) et la température(T) mais je me suis emmelé les pinceaux dans la librairie nmea ^^  donc je serais volontier preneur d'une modif.

J'ai testé ton code actuel en avion, parapente et au sol dans plusieurs conditions et pour l'instant il fonctionne vraiment bien, juste la trace IGC en sortie qui ne comprends pas d'altitude barometrique(remplacée dans la nmea) et ne permet pas de comparer l'altitude GPS et baro pour l'instant.
J'ai eu également des problème avec mon accelerometre donc pour l'instant juste testé avec le MS5611.
Je te referais un retour plus complet dès que je pourrais comparer les données GPS et baro.

et oui c'est moi qui bossait sur le M0, pas trop eu le temps de m'y repencher ces derniers temps, j'ai vu ton lien mais je t'avoue ne pas comprendre complètement la chose...et comment exactement faire les modifs sur la librairie, j'espère pouvoir m'y mettre sérieusement bientôt mais d'abord je veux finir de tester ton code actuel et finir le montage de mon vario :)

Merci pour les retours !

Je t'envois la bibliothèque modifié dès que j'ai un peu de temps. Je voudrais faire un truc propre que je peux mettre sur le GiHub. Que les utilisateurs puissent choisir ou pas de substituer l'altitude GPS par l'altitude barométrique.

Mais il vaut d'abord que j'avance un peu sur les kits.

Merci encore.

A+

Salut à tous !  :coucou:

Ca y est j'ai fini les circuits imprimés et j'ai reçu presque tous des composants   :D

https://goo.gl/photos/THdLaiRPWwTT4MGW9

Je compte finir les kits cette semaine ! Et comme je pars en vacances la semaine d'après ça serait bien qu'ils soient tous expédié avant le lundi 17 avril (compris).

Pouvez vous me contacter par message privé pour me donner vos coordonnées et pour qu'on convienne d'une procédure d'envois. Le prix serait donc de 52.89 euros tout compris.

A bientôt !



 

 

message envoyé ;)

message envoyé

J'envoie le message :)

Message envoyé  :bravo:

Salut !  :coucou:

Ca y est j'ai fini le sertissage de tous les connecteurs d'écran ...  :D

https://goo.gl/photos/THdLaiRPWwTT4MGW9

Je passe à la découpe des boîtier.

A+

Virement OK  :trinq:

[hors sujet mais pas vraiment complètement]

Je me suis mis à bidouiller l'Arduino moi aussi  :roll:
Mais j'ai beaucoup d'interrogation sur la faisabilité de mon projet.
Comme sur ce fil il y a des cracs, je tente une demande de conseil  :bisous:

Je voudrai piloter une heure de déclenchement et un thermostat depuis une page web.
J'arrive bien a coder une page web dans mon Arduino et à lui faire afficher les valeurs de départ.
Je ne trouve pas comment modifier ces valeurs à partir de mon navigateur et à les renvoyer à L'Arduino.
????  :boude:
ça ne me semble pas être une demande bouleversante d'originalité ? Il doit bien y avoir un exemple qqpart ??

 :tomate:

[/hors sujet mais pas vraiment complètement]

 :coucou: répondez moi par mail, pour ne pas trop polluer ce fil

Salut.

Bon j'ai fini :

-> Le dessoudage/nettoyage des plaques connecteur de cartes SD
-> La découpe des plaques de cartes SD
-> La découpe des cartes GPS
-> La découpe des cartes chargeurs

https://goo.gl/photos/THdLaiRPWwTT4MGW9

Et j'ai fini la découpe du bas du boîtier.

Il reste plus que le haut du boîtier et le bootloader à programmer.  :D

A+

Bonjour.

Est-ce possible qu'une gentille personne m'envoie le code le plus simple possible pour faire fonctionner un arduino nano avec le bmp180 et un buzzer en mode vario qui fait bip que quand ca monte.

Merci beaucoup.

Salut
Ben justement le post a été créé par sinseman et dans les premières pages il a partagé son projet sur github. Si vraiment ca a disparu je devrais pouvoir mettre la main dessus.

[hors sujet mais pas vraiment complètement]  :dent:

Je viens de découvrir Cayenne (pas l'aile) https://cayenne.mydevices.com/cayenne/signup

En trois clics je pilote mon Arduino sur internet depuis mon navigateur ou mon smartphone
Presque sans écrire une ligne de code
et avec une interface pleine de graphes, de jauges, de boutons, ...

Je comprends qu'un vrai développeur preferera tout écrire lui-même
Mais pour moi, c'est génial, que d'énergie et de jus de cerveau d'économisé
 :dent:   [/hors sujet mais pas vraiment complètement]

Aucun intérêt pour ton projet Prunkdump, on n'est pas dans les mêmes contraintes

colis reçu ... et en plus ça ne vole pas  :roll: j'ai mis le fer à souder en chauffe

Salut a tous !

Voici le tutoriel de montage du vario ! Amusez vous bien !

http://glpano.free.fr/vario/index.html

N'hésitez pas à poster ici votre avancement et à mettre éventuellement des photos pour compléter les étapes qui ne seraient pas très claires.

Posez également vos questions ici pour que tout le monde en profite. Vous pouvez aussi donner les techniques que vous avez pu trouver pour le montage.

A+

prunkdump, Tu gère trop !!  karma+  karma+
Franchement impressionnant !  :trinq:  Le kit est au top, il y a tout, super propre. Il a pensé à tout !  :dent:

J'ai attaqué le montage dès hier ;) j'en suis à l'étape 6. J'allais demander à quoi sert le DIP switch rouge, j'avais trouvé son emplacement.

Quand tu parle de problèmes avec les antennes, c'est laquelle qui se trouve affectée ? bluetooth ou gps ?

 :forum:

Salut ! :trinq:

Merci pour les compliments !  ;)

Bravo pour l'étape 6 ! Attention à l'étape 7 qui est la plus technique :) N'hésite pas à faire des retour pour aider les autres.

J'espère que tout va bien se passer de façon générale. J'ai toujours un peu de stress parce que le kit n'est pas exactement identique au modèle que j'ai monté moi même puisque j'ai fait quelques améliorations. C'est pas toujours évident du tout prévoir à l'avance. C'est aussi pour ça que le kit est bien rangé ;)  Il a fallut faire une check list précise.

Oui pour le bluetooth il va falloir que l'on cherche ensemble. Je me suis rendu compte après coup que le GPS captait moins bien depuis que j'avais installé le bluetooth. Puis j'ai lu cet article qui explique qu'il faut garder un minimum d'espace autour de l'antenne :

https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf?utm_source=en%2Fimages%2Fdownloads%2FProduct_Docs%2FGPS_Antennas_ApplicationNote%28GPS-X-08014%29.pdf

Du coup pour ceux qui gère un peu le bricolage il faudrait chercher un autre positionnement de l'antenne bluetooth vers la bas du boîtier. Je peux vous faire gratuitement les connecteurs que vous voulez. Le plus difficile c'est de trouver un nouveau agencement avec la batterie.

Pour ceux qui sont interessé par l'utilisation du bluetooth et qui veulent garder une très bonne réception GPS, il est possible moyennant une toute petite encoche sur le côté du boîtier de placer l'antenne GPS à l'extérieur. Et du coup de laisser le bluetooth à sa place initiale. Mais du coup le vario ne fait pas vraiment "fini". Mais ça peut être une bonne solution temporaire.

j'attends vos réflexions ! J'ai passé beaucoup de temps sur le design du reste. Mais le bluetooth, je l'ai rajouté au dernier moment et en plus j'ai du faire le code en même temps.

De toute façon c'est l'objectif du kit ! Trouver des améliorations.

A+ 

J'ai l'info trop tard, j'ai déjà soudé le blueTooth  :mrgreen:
je vais sortir l'antenne et la coller sur le boitier

J'ai fini le montage
ou est le programme beta à rentrer ?

Salut Van Hurlu !

C'est pas bien grave. Ca marche quand même mais c'est un peu plus long à fixer les satellites. Si tu fais la modif, pas besoin de coller l'antenne. Tu la laisse juste sortir sur le côté. Tu fais une entaille sur la partie inférieure du boîtier en face de la fixation d'antenne et une entaille dans le tour plastique. Comme ça tu peux la faire sortir.

Et bin ya des rapides :D vous avancez vite !  :pouce:

Tu as fais un essai d'allumage du vario ? (attendre bien 8 secondes sans carte SD) J'avais essayé de précharger le programme sur les cartes arduino.

Autrement il faut une carte SD de moins de 2 GO de préférence pour charger le programme.

Je donne la procédure le temps de chercher sur internet comment faire sous Windows (je n'ai que linux).

tu veux dire que n'importe qu'elle taille convient ?


Ce n'est pas avec Arduino.exe et un usb que l'on charge le prog ?

prunkdump,
tu serais intéressé par un "arduino mega minimal", avec juste les sorties intéressante pour le vario ?
ca permettrait d'avoir plus de ressources quitte a compacter et rajouter directement le capteur de pression voire d'autre composants sur la platine.
MP si intéressé ;)
++

J'ai un prob, mon écran ne s'allume pas à la mise sous tension  :bang:

Et le reste fonctionne ? Le vario bippe quand tu le fais monter (après les 8 secondes d'initialisation) ?

Pour l'écran :

-> Vérifie bien le pliage du connecteur. Surtout l'inversion des deux fils centraux
-> Redémonte l'écran et vérifie que le contacteur en caoutchouc n'est pas tombé
-> Avec un petit tournevis gratte très légèrement les contacteurs metalliques sur le circuit imprimé de l'écran afin qu'ils ne soient pas trop lisses
-> Remonte l'écran et vérifie qui est bien clippé

Pour la carte SD :

En fait il faut surtout s'assurer qu'elle est formaté en FAT16. Et comme windows formate automatiquement en FAT16 lorsque la carte est < 2Go c'est pratique. Mais effectivement elle peut faire moins (1Go, 512Mo etc...) .

Pour la mise à jour du firmware :

Tu compiles avec l'IDE comme d'habitude puis :

-> tu cherche dans les menus "exporter les binaires précompilés" ça va te créer un fichier avec une extention .hex
-> tu prends celui sans le bootloader et tu le renomme en "FIRM.HEX"
-> tu le met sur la carte SD
-> tu allumes le vario et tu appuis sur le bouton reset sur la carte arduino

Après une dizaine de seconde le nouveau programme démarre.

@gargle : merci pour la proposition ! Mais tant qu'a travailler avec les composants autant réaliser le vario entier en CMS directement non ? Ca sera surement la prochaine étape. Quand le "gros" vario sera au point.

Mais n'hésites pas à partager ici tes compétences. Je ne connais pas grand chose en électronique. Je travaille plus sur la programmation. Alors ça m'interesse !

A+

je suis partant pour tout intégrer (sauf le bluetooth, c'est la misère...)
MS5611 / atmega2560 / MPU9250 / SD / GPS PA6H / FTDI / recharge batterie / régulateur
Ca te parait complet ? (écran et haut parleur externe mais avec connecteurs sur le circuit)

prunkdump,

tout fonctionne chez moi !!!
 :soleil:

Je viens de courir comme un taré en rond dans mon jardin de nuit sous la pluie, le vario à la main...

Moi il a pas mis longtemps à faire le fix. Sur son premier démarrage à froid donc et dans la maison !!

La sensibilité, le bruit et le lag semblent excellent !! Aucun mais alors aucun retard, ça va faire tout drôle en volant !

C'est quoi le 0.0Gr ? (ça fait éthylotest  :dent:  !!)

Faut que je lise un peu le prog pour voir comment t'a implémenté tout ça ;) Et voir si j'ai des idées d’améliorations.

Premier retour pour Prumkdump

1 - les entêtes traversants pour le lecteur de la carte SD sont un peu courts si on s'inspire de tes photos
c'est un peu tendu pour moi, mais ça à l'air d'aller
il n'y aurait pas d'inconvénient à les faire dépasser d'1 ou 2 mm de plus.

2 - les clips du connecteur de l'écran ne tiennent pas quand on plie la map
Cela me semble être la partie la plus délicate
Comme mon écran ne fonctionne pas, je vais démonter et souder les fils directement sur les entêtes

3 - le GPS ne peut pas trouver de satellite chez moi, les murs sont trop épais



(((@))) yes Gargle
plus vous intégrerez et moins il y aura de soudures merdique de ma part  :pouce:

La construction a débuté aussi pour moi.

Petite astuce pour éviter de limer et rayer le verni à l'étape 4, j'ai protégé un maximum le CI avec du scotch de peintre. En cas de dérapage aucun soucis.

La suite du montage c'est pour demain  :ppte:

Au final idéalement, je voulais le connecter avec XcTrack que je préfère pour mon utilisation. Mais pour tester, j'ai XcSoar aussi.
La connexion dans XCSoar avec le bluetooth semble ok (Code 1234, perif HC-06 pour moi)
Par contre pas trouvé le protocole à mettre dans XCSoar : OpenVario ou NMEA output ou Generic ? (Aucun semble marcher : "Pas de données")

J'ai réussi aussi la connexion avec XCTrack mais il ne semble y avoir aucune info non plus.

Le bluetooth n'est t-il pas désactivé dans le programme en fait ? ( #HAVE Bluetooth commenté dans le github ? )

Pour que tout soit au même endroit et facile à retrouver
serait'il possible qu'à la fin de ton tuto, tu nous mettes tous les liens utiles au projet et sa compréhension

- le fritzing si tu en as fait un ?
- un lien vers ta dernière version du programme

merci d'avance


PS: j'ai bien l'impression que mon écran est HS  :bang:

@Xiboard : Fait attention quand même ! A courrir en rond à 1 heure du mat à la lampe torche avec un truc qui fait bipbip, tes voisins vont se poser des questions :D Si en plus tu regarde ton portable en même temps ils vont plus rien comprendre...

Effectivement le bluetooth n'est pas activé dans la version du programme que j'ai envoyé car il n'est pas possible d'utiliser simultanément la carte SD et le bluetooth  :? . Mon code consome encore trop de RAM  :oops: . Voici donc l'explication pour ceux qui vaudraient tester le bluetooth :

1) Installez l'IDE de l'arduino et téléchargez mon code :

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

2) Ouvrez "variometer.ino" et commentez le "HAVE_SDCARD" puis décommentez "HAVE_BLUETOOTH" :

#define HAVE_SPEAKER
#define HAVE_ACCELEROMETER
#define HAVE_SCREEN
#define HAVE_GPS
//#define HAVE_SDCARD
#define HAVE_BLUETOOTH

3) Complilez le programme et cliquez dans le menu sur "Croquis -> exporter les binaires compilés". Cela créé deux fichier. Regardez celui qui n'a pas le bootloader et renommer le en FIRM.HEX (en majuscule).

4)Trouvez une carte SD de moins de 2Go et formatez la en "FAT" pour windows ça veut dire FAT16. Si vous n'avez que des grosses cartes cherchez sur internet comment créer un partition FAT16 sur une carte SD.

5) Mettez le fichier FIRM.HEX sur la carte SD et insérez la dans le vario.

6) Allumez le vario et appuyez sur le bouton reset sur la carte arduino. Après quelques secondes le vario va redémarrer avec le bluetooth.


Je vais mettre cette procédure sur le site dès que j'ai un peu le temps. Parceque c'est aussi comme ça que vous pouvez personnaliser le vario.

@Jpg63


Très bonne astuce ! J'ajouterai de passer un petit coup de dissolvant après coup pour être sur qu'il n'y à pas de colle restante sur les pad à souder. Il faut vraiment passer du temps sur cette étape. Plus c'est fin plus c'est facile ensuite de souder la carte SD.

(@)Van Hurlu.

On va bien trouver le moyen de le faire marcher cet écran ! Ya pas de raison. Il ne peut y avoir que deux problèmes :

-> Soit la connexion de l'écran sur son petit PCB rouge
-> Soit la connexion entre le PCB rouge et l'arduino

Dans le premier cas as tu vérifié les points que je t'avais donné ?

1) Vérifie que le contacter en caoutchouc est propre et bien positionné dans son logement (il faut qu'il soit bien droit).
2) Nettoies au dissolvant les petits contacteurs sur le PCB rouge. Puis gratte les légèrement avec une pointe pour que la surface ne soit pas trop lisse. Cela facilite le contact.
3) Avec une pince essaye de redresser les petites pattes du fixation sur l'écran. Assure toi qu'il se clippe bien sur le PCB.

Dans le second cas, a tu un testeur de continuité ? Si tu en as un tu remet l'écran sur sa broche et tu peut tester les connexion entre l'écran er l'arduino en touchant les soudures. Il y a 8 oeuillets sur l'écran :

De gauche à droite :
1) Le 1 RST -> doit être connecté au pin 2 de l'arduino
2) Le 2 CE -> au pin 3
3) Le 3 DC -> au pin 4
4) Le 4 DIN -> au pin 11
5) Le 5 CLK -> au pin 13
6) Le 6 VCC -> au pin VCC de l'arduino
7) Le 7 n'est pas utilisé
8) Le 8 GND -> au pin GND  de l'arduino

Dis moi ce que ça donne.

@gargle

Je pense qu'il faudrais :

-> un switch SMD à angle droit
-> un L9110 en version SMD (il existe en SOP8)
-> un buzzer SMD magnétique (comme sur le blueflyvario)
-> un mini USB
-> un régulateur 3,3V et la circuiterie qui va avec (condensateurs, led etc...)
-> un microcontrolleur AVR. Celui quetu propose est bien, mais ça pourrait être intrressant de prendre les nouveaux modèles avec le support de l'USB intégré. Genre ATmega32U4.
-> L'oscillateur
-> le ms5611
-> le mpu9250
-> le module de charge LIPO et le module de protection de la batterie
-> un conteneur pour carte SD
-> un controlleur GPS et son EEPROM
-> une antenne GPS patch a souder sur le circuit
-> Pour l'écran il peut être clippé directement sur le circuit. Du coup pas besoin de connecteur.

Ca fait quand même du boulot pour concevoir tout le circuit :D

Pour le moment la limitation SD ou Bluetooth me gênera pas.
Je vais jeter un oeil s'il y a des pistes pour améliorer le code pour économiser la RAM. J'avais déjà travaillé la dessus sur d'autres de mes projets arduino mais de ce que j'ai vu t'es déjà pas mal du tout il me semble.

Autrement : dans la conf actuelle (sans changer le firmware), les fichiers sur la carte SD sont bien crées (GPS000.TXT ...) mais le contenu c'est n'importe quoi : dans le TXT je retrouve l'ancien contenu de la carte sd (que j'ai bien formaté). J'ai même testé un formatage overwite avec sdformater mais c'est pareil,il me créer les fichier GPS000.TXT rempli du même caractère maintenant !

C'est normal ? J'ai pas regardé le code à ce niveau, et je ne suis pas familier avec carte sd <-> arduino.

Salut !

Non bien sur ce n'est pas normal ...  :?

C'est bizarre parceque j'avais testé un formatage avec windows (clic-droit, formater, FAT) et un formatage avec linux et dans les deux cas cela fonctionnait.

En tout cas dans ton cas le problème ne vient pas du fonctionnement de la connection arduino<->carte SD puisque le programme parvient à écrire sur la carte. C'est qu'il n'arrive pas bien à interpréter le formatage de la carte SD.

Voilà ce que je pense ce qu'il se passe  :

-> il trouve bien la partition
-> il trouve bien le répertoire racine et il arrive bien à créer le fichier
-> il arrive bien à augmenter la taille du fichier
-> mais il écrit les données au mauvais endroit sur la carte et donc ce sont les anciennes données qui apparaissent à la place. (elles ne sont pas écrasées)

Pour que je débugge il faudrait que tu m'envois les deux premiers Mo de ta carte.

-> tu télécharges Win32DiskImager
-> tu créé l'image de ta carte SD tel quelle est
-> créé en un ZIP. Si le fichier n'est pas trop gros tu me l'envois
-> sinon tu coupe le .img en m'envoyant uniquement les 2 premier Mo (cherche "windows cut binary file" sur google)

Bon courage !

Yes, c'est tout bon. Je n'avais même pas encore démonté l'écran pour faire les soudures
Par acquit de conscience (et désespoir) j'ai fait tes 3 opérations


J'ai dessoudé la carte Bluetooth pour y voir plus clair.
Toutes les connexions de l'écran à l'arduino sont bonnes.

Quand j'ai remis sous tension (sans la pile) avec le câble usb
l'écran s'est enfin allumé pour la première fois
il clignote
2s allumé / 4s éteint
sur l'écran on ne lit pas de valeur ... uniquement les unités : m m/s ...
juste avant de s'éteindre il tente d'afficher les valeurs (je les aperçois fugacement)
puis le buz fait un bip et l'écran s'éteint

On progresse  :pouce: tu as d'autres idées  ???
Je recommence le nettoyage des contacts ?

Salut !

Si il n'y a pas de carte SD le vario met 8 secondes à démarrer parcequ'il cherche pendant un moment à y accéder. Donc déjà pour gagner du temps met n'importe quelle carte SD dans le lecteur cela baissera le temps de démarrage à 1 secondes.

Ça a l'air de presque marcher. Donc c'est juste qu'il doit y avoir un mauvais contact quelque part.

1) as tu nettoyé le flux de soudure sur tout ton montage ? Sinon passe du dissolvant et gratte un peu entre les soudure pour être sur que ça ne fait pas contact

2) Esaaye d'appuyer sur l'écran pendant le démarrage pour voir si y a un faux contact à cet endroit. Si oui recommence le nettoyage.

3) Vérifie bien toutes tes soudures et réchauffe les au besoin.

4) Relis le tuto et vérifie que tu n'as rien oublié.

Et le reste ? Ça fonctionne ? Le vario bippe lorsque tu le fais bouger de haut en bas ?

À+

ou un court-jus ?

oui j'ai bien fait ces 2 points
le dissolvant ne risque pas d’endommager le baro (les ptis trous) ou le gps ?

j'hésite, déjà que j'ai des pâtés  :mrgreen: je vais quand même essayer ce point

c'est fait 3 fois  :mrgreen:

pas facile en mode dépannage, avec le fil usb et sans boitier,
de toute façon il hoquette et bib avec le clignotement de l'écran
je ne crois pas que ça bipera en fonction du déplacement

merci de ton aide, je vais tester toutes les connections avec ton shémas

prunkdump, Van Hurlu n'a pas mis la batterie. C'est pas ça le pb ?

Bin ca peut marcher quand même en théorie. Ou alors l'alim USB est un peu merdique.

C'est sur Van hurlu ca coûte pas grand chose de ressouder la batterie et de tester. Tu aura une alimentation plus stable. Et en plus tu pourras tester si le vario marche déjà sans l'écran.

Pour le dissolvant tu n'en met pas partout mais juste sur les soudures.

merci Xiboard
Avec la batterie grosse amélioration l'écran ne clignote plus
il affiche des valeurs qui changent sans arrêt limite illisible (dans les 8000m d'altitude)

j'avance, mais je pense qu'il y a encore un truc de mauvaise connexion

Alors ça peut venir d'un autre problème.

Il m'est arrivé sur certaines cartes que le baromètre ne supportait pas la fréquence indiquée dans le datasheet. En gros la carte était un peu plus lente. Je ne sais pas pourquoi. Et l'arduino lui en demandait trop.

Verifie juste les soudure du baromètre et les deux soudures au centre de la carte arduino pour le moment.

Puis il faudrait charger un firmware avec une fréquence plus faible pour le baromètre.

As tu trouvé une carte SD de moins de 2 Go ? Verifie si le vario créé des fichiers dessus (vides) lorsque tu l'allume.  Il faudra qu'on s'en serve pour mettre à jour le firmware.

Game Over - écran tombé de la table bien à plat sur les carreaux
seule la moitié sup de l'écran s'allume
  :bang:

PrunkDump,

A priori ça venais de ma carte SD, avec une 8Go avec partition de 1Go ( à mettre en FAT16, Primary, Active) ça marche impec.

Par contre, question, c'est trop lourd de générer directement un format igc ?

Salut Xiboard !

Content que tout marche  :pouce: Plus qu'à tester le Bluetooth.

J'ai pas eut le temps de regarder le fichier que tu m'as envoyé.

Mais tu pourrais nous dire comment tu as fais sous Windows pour créer la partition et la formater ? Ça pourrais intéresser tout le monde.

Pour le format IGC, malheureusement oui ça prends pas mal de place de le mettre le code sur le vario. Mais je comptais faire un petit programme pour convertir rapidement les traces depuis la carte SD.

Je ferais ça quand j'aurais un peu de temps. Pour l'instant il faut utiliser les outils en ligne pour convertir de NMEA vers IGC.

Bon,

2 Nouvelles !

1. Le Bluetooth marche. Je reçoit les trames NMEA sur la tablette Android avec XCSoar (mais cela dit il ne semble pas les interpréter...)

2. Lorsque le GPS a fix et envoie les trames. Le vario part complètement en couilles ! ça bip dans tout les sens et les valeurs varient dans tout les sens aussi. l'affichage deviens aussi instable avec des chiffres qui 'dépassent'

Question : J'avais vu parler de OpenVario, mais pas tout suivi. Par les trames NMEA t'envoie les données vario et alti ?? Pour moi c'est le plus important : Une tablette à pas cher avec XCTrack fait un super instru. Le GPS intégré à la tablette suffit. Par contre l’absence de bonne données vario limite le bon retour de la finesse et divers calculs.
Après sur des petits vols, l'idée d'avoir la sauvegarde de la trace sur la carte sd au top. Et aussi en sauvegarde en cas de défaillance batterie de la tablette.

PS_1 : lors de la compilation, c'est bien Arduino Pro Mini et ATmega328 (3,3V 8MHz) ?

PS_2 : Tu devrai pas ouvrir un post dédié dans http://www.parapentiste.info/forum/instruments-de-vol-b49.0/ (http://www.parapentiste.info/forum/instruments-de-vol-b49.0/) ? Remarque tu fait déjà tellement de trucs !

Oui c'est ça.

Pour le bug tu as du oublier d'enlever la carte SD dans le code si tu active le Bluetooth ;) il faut commenter HAVE_SDCARD.

Pour l'instant il faut que j'optimise la RAM on peut pas activer les deux .

Si si j'ai bien désactivé :

Mon vario est presque terminé

Quelques petites remarques

1/ sur le tuto

entre l'étape 8 et 11 au moment de couper et tordre les entêtes, il serait intéressant d'avoir une photo en gros plan avec des marques (gros point rouge) sur les pattes à couper
A l'étape 11 lors de la connexion de l'écran, il serait bon d'ajouter une photo avec le numéro des bonnes du connecteur et leur emplacement, pour ma part les couleurs des câbles sont  différentes des photos du coup il est plus difficile de tout repérer. On gagnerait en clarté

2/ Kit

Je trouve le petit inter sur le coté difficile à utiliser

3/ quelques idées d'amélioration qui me viennent

- dommage pour igc, la vario aurait pu être directement compatible avec LogFly le carnet de vol sur PC compatible avec la plus grosse majorité des varios

- il serait intéressant d'avoir une petit indication sur l'écran quant le GPS est calé
- Il serait utile d'avoir l'affichage de l'heure et du temps de vol en alternance
- Je vois bien 3 lignes sur l'écran alternance heure+temps de vol - Vario - alternance Vitesse+altitude   
- Avoir un petit indicateur quant l'enregistrement commence - avoir un déclenchement et un arrêt automatique (vitesse + de 3Km/h avec changement altitude ou de position pendant au moins 5secs)



Liste des liens utiles


Tuto
http://glpano.free.fr/vario/index.html

Photo
https://photos.google.com/share/AF1QipNNEoMqtY_Vedgpb0bXJ6P9cAKNFtBX3-fTW9MW-yde3P0uNZWkR7KzIRnJyprkBA?key=NEMzNk5XR0lwYVEtSTVvUG5rdXRxaURjbzA2emJB

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

Bravo jpg63  :pouce: !

Plus qu'à faire des essais en vol !

Tu pourras nous dire si le tiens accroche vite les GPS ? As-tu soudé le bluetooth pour le moment ?

Merci pour les idées. Une fois qu'il y aura pas mal de retours on pourra commencer à travailler sur le programme. Il faut aussi que je montre à tout le monde comment charger le firmware et changer les différents paramètres du Vario.

Apparemment Xiboard a déjà trouvé comment faire :D

Pour l'IGC pas d'inquiétude. Il suffit de faire un programme qui va chercher les traces sur la carte et qui les convertis à la volée. D'ailleurs c'est souvent comme ça que ça marche sur les autres varios. Il faut un programme pour extraire les traces.

@Xiboard : Si tu as bien désactivé la carte SD c'est que le bug du bluetooth ne vient pas d'un problème de RAM (enlever la carte SD libère 512 bytes ). J'avais pensé à ça parceque moi ça s'était mis à marcher comme cela. Mais apparemment le problème est plus complexes. J'ai un peu de boulot pour le moment mais je m'y colle dès que possible. Avant d'améliorer le vario il faut que tout ce qui est déjà implémenté fonctionne bien.

@jpg63 : Merci pour les liens. C'est vrai qu'il faut que je les rapelle de temps en temps pour ceux qui arrivent en cours de discution.

Bon bin on avance.

A+

Prunkdump, je n'ai pas soudé le bluetooth et je n'est pas prévu de le faire pour l'instant. Je vais faire des essais sans. Je ferais un retour dès demain car j'aurai fini ce soir.

Petite astuce supplémentaire, j'ai ajouté un petit morceau de scotch double face pour fixer l'écran, pour éviter qu'il s'enfonce si on appuie dessus par mégarde.
J'ai peu être trouver une solution pour inter, je ferais une photo quant ça marchera.

A+

Nickel !

J'attends avec impatience tes idées d'amélioration.

@Xiboard : Si tu passe par là tu pourrais nous donner ta manip sous Windows pour créer la partition FAT16 sur ta carte SD ? Ya d'autres utilisateurs du kit qui ont le même problème.

(https://img4.hostingpics.net/pics/442017connectiqueecran.jpg) (https://www.hostingpics.net/viewer.php?id=442017connectiqueecran.jpg)

https://img4.hostingpics.net/pics/442017connectiqueecran.jpg

(https://img4.hostingpics.net/pics/493985cossesacouper.jpg) (https://www.hostingpics.net/viewer.php?id=493985cossesacouper.jpg)

https://img4.hostingpics.net/pics/493985cossesacouper.jpg

((@)) jpg63
ta numérotation du câble de l'écran aurait été mieux en respectant les num du slot de l'écran
c.a.d. dans l'autre sens

1) Le 1 RST -> doit être connecté au pin 2 de l'arduino
2) Le 2 CE -> au pin 3
3) Le 3 DC -> au pin 4
4) Le 4 DIN -> au pin 11
5) Le 5 CLK -> au pin 13
6) Le 6 VCC -> au pin VCC de l'arduino
7) Le 7 n'est pas utilisé
8-  Le 8 GND -> au pin GND  de l'arduino

Arf, j'ai partition magic sur mon PC donc j'ai utilisé ça (c'est gratuit de mémoire)
A partir d'une 8Go, j'ai fait une FAT(=FAT16) de 1Go. A mettre en Primary et Active.

Je jetterai un oeil, ça doit être faisable avec l'outil de gestion de disques de windows. -> j'te ferai un mini tuto si ça peu servir

Pour info moi même avec le Bluetooth allumé et activé, dans la maison, avec ciel couvert, il mettais 3-8 min pour faire le fix (mais du coup que sur 3 satellites au début)
Effectivement, le petit logiciel pour faire l'interface NMEA vers IGC est tout à fait envisageable. Et utiliser se log pour "nettoyer" (auto/manu) avant le déco et après l'attero (comme ça dans logfly on a un bon temps de vols).

Van Hurlu, je modifie l'image et je republierai tout ça ce soir

salut à tous! de mon coté j'attends toujours le kit, je me demande s'il est pas dans la boite aux lettres du voisin ;)
De toute façon je suis en travaux, je n'ai pas le temps de m'en occuper tout de suite. Je laisse les fusibles dégrossir le terrain en premier ;)

Bonjour à tous,

Ca y est, c'est bon pour moi ; le kit est monté.
Merci prunkdump. Pour le boulot, la qualité du kit, du tuto ...
Super boulot d'intégration des différents modules ; c'est impressionnant. C'est chaud pour faire rentrer tout cela dans le boitier.

J'ai appris pas mal de choses en montant le vario. En particulier, les astuces pour les connecteurs.

J'ai un peu galéré sur les soudures à limer : je n'avais pas assez limé, 2 ou 3 soudures genaient la mise en place de la sdcard ; j'ai voulu les réduire à la dremel, et ce n'était pas un bon plan.
La dremel fait "baver" les soudures, et ca a fait des ponts entre les plots.
J'ai du jouer de la pompe à dessouder, bien nettoyer, ressouder ... et limer.

A part ca, pas trop de difficultés.

Pour le moment, comme conseillé, je n'ai pas encore soudé le module bluetooth ; j'espère le faire bientot, j'aimerais tester avec XCSoar.

Je n'ai fait qu'un premier test de mise en route, le boitier est encore ouvert.
Que je démarre avec une sdcard ou non, c'est rapide ; une ou deux secondes.

Comme je compte l'utiliser principalement dans un planeur, déja équipé d'instruments, j'aimerais que le son soit moins fort.
Je suppose que je remplace le pont du buzzer par une résistance ; vous avez un ordre d'idée de la valeur, ou j'y vais au pif pour voir ?
Je n'ai pas encore mis le nez dans le code ; je suppose qu'on ne peut pas réduire le son par ce coté ?

Au fait, le code est bien celui-ci : https://github.com/prunkdump/arduino-variometer ?
Je suis surpris, les date des fichiers dans le github sont anciennes. Les images et le fichier fritzing datent du début du projet de prunkdump.

Autre question : le switch rouge à l'intérieur ; il sert à quoi ? Je l'ai mis sur "ON" sans savoir ce que ca faisait.

Bon, j'ai hate de faire joujou avec, et de zieuter le code ...

permet la mise sous tension du module bluetooth

la limitation de puissance du GPS liée à la proximité du bluetooth avac l'antenne GPS ; c'est tout le temps, ou uniquement si le bluetooth est alimenté ?

@jpg63

Nickel les photos ! Tu pourrais m'envoyer les photos annotées sans la mosaïque que je puisse les intégrer au Tuto ? Je crois voir un petit capuchon sur le switch aussi :D Je pense que c'est l'idée pour le rendre plus facile à manipuler :)

@Xiboard

Si tu arrives à me faire un petit tuto ça serait super ! Apparemment j'ai cru comprendre qu'il y avait une commande native "diskpart" sous windows. Il faudrait juste trouver la liste des instructions à taper.

@finlard

J'ai revérifié le colissimo et le colis est marqué livré depuis le 24. Il faudrait peut-être aller voir ton voisin effectivement. J'espère que la poste n'a pas fait de connerie. Vu ou tu habites ça serait un comble. J'espère qu'il n'y aura pas de soucis.

@vmath54

Bravo pour le montage  :pouce: ! Oui effectivement l'étape de la lime est vraiment l'étape la plus importante. Elle conditionne toute l'épaisseur du vario. Content que tu ai trouvé une solution.

Ca m'interesse beaucoup les pilotes de planeurs :D car je travaille en ce moment sur une vario à énergie compensée. L'algo est au point mais il faut trouver le moyen de transmettre la mesure de vitesse air au vario. Oui je sais je fais trop de truc différents ... :? Il faut que je finisse bien ce que j'ai commencé.

Pour le volume c'est effectivement possible de le régler avec le code. Je comptais faire la modif. Il faut remplacer tous les toneAC(freq) en toneAC(freq, VOLUME) avec un volume entre 1 et 10. Mais encore une fois il faut que j'explique comment mettre à jour le code.

La dernière version est bien https://github.com/prunkdump/arduino-variometer. C'est juste le schéma et le README qui sont des vielles versions. Le reste est à jour.

Pour le bluetooth avec le GPS :

Je ne sais pas trop ce qui joue vraiment. Mais apparement ne n'est pas très bon de mettre des composants à proximité de l'antenne GPS. Je trouve que le mien ne capte pas très bien les satellites mais en même temps il y avait un soucis sur la plaque GPS que j'ai du ressouder (le module Ublox en dessous). Xiboard trouve ça capte bien. L'ideal ça serait de tester quelques jours sans le bluetooth pour pouvoir comparer ensuite avec. Si vous avez un fer à air chaud vous pouvez le souder sans problème puisqu'il sera facile à dessouder dans tous les cas.

J'ai juste une suspition que le bluetooth puisse avoir un effet négatif.

 

(https://img4.hostingpics.net/pics/664224connectiqueecranv2.jpg) (https://www.hostingpics.net/viewer.php?id=664224connectiqueecranv2.jpg)

voila l'image modifiée

Tu as une bonne vu prunkdump, effectivement je test avec un petit connecteur qui à la chance de laisser parfaitement rentré le micro switch, encore un peu de ponçage et je pourrais proposer ou non l'idée

Je viens de terminer et je vais avoir besoin d'aide

Pas de son, pas d'affichage, seul la led de l'arduino est allumée

Petite notice donc pour passer une carte SDHC de 8Go par exemple en 2Go FAT16 sous Windows :

Lancer DiskPart :

Ensutie dans DiskPart :
/!\ attention à être bien sûr de faire ça sur le disque correspondant à la carte SD. Ne faites rien en cas de doute.


Normalement, le disque apparaît dans Explorateur.

Effectivement, des outils online permetent facilement de convertir les traces nmea en igc :

http://www.gpsvisualizer.com/gpsbabel/?lang=fr (http://www.gpsvisualizer.com/gpsbabel/?lang=fr)

Choisir :
Types de données GPS : Traces
Format entrée : NMEA 0183
Format sortie : FAI/IGC

 karma+

En attendant vos suggestion pour faire marcher mon vario, voici mon astuce pour améliorer facilement l'interrupteur

un simple connecteur jst male coupé

(https://img4.hostingpics.net/pics/263317jstmale.jpg) (https://www.hostingpics.net/viewer.php?id=263317jstmale.jpg)

(https://img4.hostingpics.net/pics/27567820170427210535.jpg) (https://www.hostingpics.net/viewer.php?id=27567820170427210535.jpg)

@jpg63

Soude la batterie et test.
C'est super facile à dessouder au besoin après.

Prunk, le chargeur il fait aussi régulateur ?

Tout est soudé, l'arduino s'allume mais ni affichage ni son. Je vais vérifier toutes les soudures mais si vous avez une idée de ce qui pose problème je suis preneur. Je commence par la carte SD car il n'y a aucun fichier qui se crée, j'ai une SD de 256Mo

Salut jpg63 !

C'est peut-être tout simplement que j'ai oublié de mettre le programme sur l'arduino...  :?  J'ai fais ça à la chaine et j'en ai peut-être zappé un ou alors je l'ai déconnecté trop tôt.

Voilà ce que tu dois essayer :

1) Formate la carte SD en "FAT" (je pense que vu la taille elle sera formaté automatiquement en FAT16). 256Mo c'est parfait pour le vario.
2) Met dedans le fichier FIRM.HEX en pièce jointe.
3) Insère la carte dans le vario
4) Allume le avec la batterie et une fois allumé appuis sur le bouton reset de l'arduino
5) Regarde bien si il y a une LED qui clignotte très rapidement sur l'arduino, juste après la pression du bouton, pendant 1.5s environ. Tu peux répéter l'opération plusieurs fois au besoin pour bien vérifier.

-> Dis nous déjà dans un premier temps si tu parviens à charger les firmwares.

PS : A oui c'est normal que tu ai du mal à accéder au bouton. Tu n'as pas taillé l'ouverture en ellipse. Mais très bonne idée ton connecteur ! Je mettrais ça sur le tuto dès que j'ai le temps.

Merci pour ta reponse, j'essai de mettre à jour l'arduino ce soir

La matière du boitier est très dur et difficile à tailler et à limer.
je comprends que l'on cherche une solution plus facile, mais ... avec un peu de patience on y arrive (cutter + limes rondes) et je trouve la solution de l'ellipse parfaite en fonctionnalité.
Le bouton est profondément enfoncé et il est impossible qu'il soit actionné accidentellement. Il faut juste avoir un minimum d'ongle à l'index.

D'ailleurs d'une manière général je suis admiratif du travail de conception de Prunkdump  :bravo:  :bravo:  :bravo:
L'intégration dans le boitier est optimum et l'assemblage fait pour durer.

Je ferai juste 3 remarque:
1 - Ma démarche est aussi avant tout pour apprendre (j'ai un skytraxx qui me donne toute satisfaction), donc si le boitier avait été un peu plus gros cela ne m'aurait pas rebuté. Mes gros doigts y aurait trouvé plus de place pour monter et démonter mon nouveau joujou. De toute façon la deuxième génération sera encore plus intégrée, n'est-ce pas Xiboard ?
2 - Que l'écran ait un connecteur est très utile. Mais le montage aurait été plus facile pour moi si à l'autre bout, les fils avaient été directement soudé sur les broches traversantes avec un peu de gaine thermorétractable. (je crois avoir lu que Prunkdump n'en a pas trouvé). J'ai été obligé de souder les connecteurs sur les broches pour éviter quelles bougent (c'est pas terrible)
3 - Il n'était pas possible de mettre un lecteur de carte micro SD comme sur un Shield ethernet, au lieu de ce gros lecteur qui tient beaucoup de place ?????


J'attends impatiemment un nouvel écran et un lecteur de carte SD pour mon PC, pour finaliser mon premier "Prunky"

 :coucou: JM

Merci Xiboard !

Ton tuto est nickel ! Je vais le mettre sur le site. Il sera très utile car on ne trouve plus beaucoup de carte de moins de 8 Go.

Merci aussi pour le site de conversion de traces.

Et non le chargeur n'a pas de régulateur. C'est pour ça qu'il ne vaut mieux pas alimenter le vario autrement que par la batterie. D'ailleurs on pourrait peut être enfiler une petite fibre optique pour avoir le témoin de charge à l'extérieur du vario.

Pourquoi dis tu Van Hurlu que c'est pas terrible de souder les connecteurs ? C'est ce que j'avais prévu à la base. Côté circuit imprimé il n'y a pas de raison de les déconnecter. Ce qu'il ne faut pas faire c'est souder les fils directement. J'ai eut pleins de problèmes avec ça sur mes précédents vario. Le fil avec l'étain devient très cassant. Il faut toujours que les fils soient sertis.

Oui bien sûr on pourrais passer en micro sd. Mais j'étais partis sur SD classique et comme ça passait j'ai pas cherché plus loin.

Par contre ce qui serait intéressant c'est de pouvoir accéder à la carte sd par l'usb. Mais cela demande un composant de plus.

Passage en micro sd avec accès depuis l'usb ça serait top

tu as l'air d'avoir plus d'expérience que moi, donc je te crois,
mais dans ton tuto tu ne dis pas qu'il faut les souder, ou je n'ai pas vu.

avec un micro usb tu aurais peut être la place ? et plus besoin d'accéder depuis l'extérieur à la carte !

la critique est facile ...  :ange:
laisses moi te renouveler mes félicitations sur ton travail
 karma+

Dans le même genre, t'as vu que lorsque l'on a le bluetooth et comme l'arrière de l'écran est découpé, on voit très bien le clignottement de la led du bluetooth à travers l'écran !! Mais c'est pinailler, ça gène en rien.
Pareil, lorsque l'on met en charge, on arrive à la voir la led de charge par le côté. (J'ai pas test, elle s’éteint quand c'est fini ?)

un boitier transparent serait super Geekwarriorgamer  :dent:

Sauf que le capteur baro est sensible à la lumière :/

Arff ! Quand j'ai voulu mettre en charge l'accu, je me suis apercu que la micro usb était arrachée !

Peut-être que ca s'est passé lors de la mise dans le boitier ; j'avais pourtant fait attention.

Faut que j'arrive à dessouder proprement la sdcard et le module d'alim, c'est pas gagné.
J'ai acheté récemment une station à air chaud (ZD-939L), ca va être le bapteme.

Seul point positif : je dispose d'un module d'alim identique ; je l'avais acheté lorsque prunkdump avait donné une liste de matos pour le vario.
Si j'arrive à travailler proprement, je devrais pouvoir remettre tout cela d'aplomb...

Qu'est ce qui est arraché ? Si c'est juste l'embout micro USB pas besoin de changer toute la plaque. Tu ressoude juste la prise.

Si c'est  la plaque tu devrais réussir à la ressortir par dessus sans dessouder la carte SD.

J'espère que c'est pas le circuit imprimé...  :?

Vous me faites peur avec vos soudures :) je serais plus tranquille quand tous les kits seront montés et fonctionnel...

Édit : s'il est abîmé tu peux aussi dessouder l'embout micro USB d'une plaque pour le remettre sur l'autre. Attention de protéger le plastique interne si tu fais à l'air chaud.

 prunkdump, je viens de mettre le firm.hex, l'arduino c'est mis à jour, car maintenant j'ai des fichiers qui s'enregistrent sur la carte sd, mais toujours pas d'affichage et de son.

J'ai vérifier les connexions de l'écran jusqu'à l'arduino tout est bon.
Je pense que je dois certainement avoir une soudure qui déconne

 

Oui, c'est l'embout micro USB. Mais je ne me vois pas trop le ressouder... et j'ai déja poubellisé  :oops:

C'est bien plus facile à changer tout le module (de toute manière, il faut le dessouder), et vu le prix je préfère cette option.

J'ai bon espoir d'y arriver : j'ai pu démonter à peu près proprement la sdcard et ce module.
Je ne peux pas continuer pour le moment, je suis pris par ailleurs.

Ca m'a permis de voir que tu as du jouer de la dremel ou autre lime pour que le module d'alim s'intègre correctement. Et je suppose que tu as du faire la même chose pour d'autres modules.
Ceci pour les 10 kits, et les essais que tu as du faire avant.
Quel boulot ! encore merci.

jpg63, ce qui m'inquiète c'est surtout le son.

Les écrans ont souvent des faux contacts. Si tu cherche un peu avant dans le fil, je donne quelques astuces pour y remédier.

Voici un firmware qui fait juste un son pour tester le buzzer.

Testes déjà ce que ça donne.

Ensuite si ça marche tu peux tester ce firmware avec un vario minimal (ms5611 + buzzer).

je pense que le problème vient des soudures ponsées sous l'arduino. du coup scl et sd0 de la carte ms5611 sont pas raccordé à l'arduino

je vais mettre un fil entre scl et A5 car je ne peux pas accéder aux soudures sous la carte SD

la pin sd0 est connecté à quelle pin de l'arduino ?

Le son fonctionne
Le Ms5611 + le son fonctionne

J'ai vérifier la connections de l'écran, j'ai nettoyé les connections et j'ai tout remonté, remis le firmware et tout fonction
 :D

Nickel  :pouce:

Je suis soulagé :D

Édit : j'ai pas rêvé le message était avant nettement moins rassurant ;)

non tu as pas révé, j'ai tout nettoyée une 2eme fois et c'est bon par contre je ne sais pas si c'est un bug juste chez moi, mais le verrouillage de l'altitude est aléatoire, sur 10 ou 15 allumage 3 ou 4 fois pas d'altitude, 1 ou 2 plus de 5 sec et sinon moins d'une seconde. A voir

Ce matin il fait beau  :soleil: , le "PrunkDVario" va faire son premier vol  :ppte:
Il sera dans la poche de ma sellette  :grat:  car j'ai encore quelques bricole à lui faire, cordelette de sécurité et fixation sur les élévateurs 

Prunkdump,

j'ai

2 questions :

1- sur la carte du baro la pin SD0 est reliée à quelle pin de l'arduino ?
2- peut-on mettre à jour le firmware sans appuyer sur le reset de l'arduino ? juste avec le FIRM.HEX sur la sd et en allumant ?

1 constatation :

1- sur mon vario en fonction de la pression sur les vis de fixation du boitier, je n'ai plus l'accrochage de l'alti (GPS) je suppose, un court-circuit ou juste l'antenne qui est trop proche de l'écran - si d'autre on constaté la même chose ce serait intéressant de voir d'ou vient le problème

3 suggestions :

1- dans le tuto il pourrait être intéressant de rajouter juste après le limage et avant de souder la carte SD une verification complète de la continuité - car dans mon cas une soudure s'est décollé ou était mal faite, sous la carte SD impossible d'y accéder sans tout démonter donc 10min de verification c'est beaucoup moins de problème après enfin je pense
je joins un fichier des connexion

2- il pourrait être intéressant de prévoir 2 trous pour le passage d'une cordelette de sécurité (un bout de suspente récupéré après un contrôle de voile) et d'ajouter sa mise en place dans le tuto

3- Si il est indispensable d'appuyer sur le bouton reset pour la mise à jour, alors il pourrait être judicieux de percer un trou sur le capot pour appuyer sur le reset avec un stylo sans ouvrir le boitier

Retour d'info ce soir

Salut PrunkDump, bravo pour ta réalisation, ça fait vraiment très pro et le code est super propre!
J'ai construit un vario à base d'arduino/ms5611 et module bluetooth le tout commandable avec le téléphone (pas d'écran ni de boutons sur le vario).

Deux petites question.
- As-tu un lien et une référence pour le buzzer, le volume est-il suffisant en vol (trop faible pour le miens..).
- As-tu un lien pour le boitier?
Merci à toi et bon vol!

@jpg63

Pour faire une cordelette rapide moi j'ai attaché une ficelle a rotis a un des anneaux internes de l'entretoise plastique. Je laisse ensuite la ficelle se laisser pincer lors de la fermeture du vario. Je pensais essayer de percer en diagonale un coin du vario pour enfiler une dragone comme pour les petits appareil photos.

Pour la mise à jour du firmware :

Effectivement pour le moment il faut encore ouvrir le vario pour mettre à jour le firmware puisqu'il faut appuyer sur le bouton reset.

Mais l'idée c'est ensuite d'ajouter au code du vario une instruction pour lancer cette mise à jour. Je pensais faire en sorte que lorsqu'on allume le vario avec l'écran pointant vers le sol, cela charge le nouveau firmware. Autrement il est possible aussi :
-> De le lancer à chaque démarrage. Mais ça ralenti le lancement du vario et cela oblige de retirer le fichier de la carte SD
-> De déssouder le bouton reset de l'arduino pour le raccorder avec des fils et le coller au boîtier.
J'espère bien sur arriver à aboutir la première solution rapidement.

Pour l'étape de la lime :

Effectivement ça peut être une bonne idée de tester. Ou peut être simplement de chauffer à nouveau toutes les soudures après les avoir limées.

Dans ton cas as tu trouvé laquelle des soudure posait problème ? Peut-être que dans ton cas il suffirait de chauffer assez longtemps (8-10 secondes) les pins du barométre et les deux pins centrales de l'arduino. A tu résolu ton problème de baromètre que ne démarre pas à chaque coup ?

Pour ta question la pin SD0 du baromètre n'est connecté à rien ...  :D Désolé de t'avoir fait chercher pour rien. Cette soudure sert juste à bien maintenir la plaque en place.

Pour le GPS :

Effectivement il va falloir qu'on fasse des essais tous ensemble car il semble de selon les configurations, la performance du GPS varie beaucoup.

Je sais pas si vous avez remarqué mais, sous le GPS, sur la plaque, il y a 4 contacteurs. Je ne sais pas trop à quoi ils servent mais peut-être que si l'antenne est bien en contact avec les 4, cela améliore la réception. Ou peut-être pas ... Il faudrais essayer en insérant une feuille d'isolant. Puis avec le contact. Puis peut-être en soudant l'antenne à ses 4 coins. Je sais pas si quelqu'un a de l'expérience la dedans. Mais l'histoire de la pression je comprends pas. Dans tous les cas il faut essayer de bien tout caler pour que ça ne force pas.

On attends tes retours !

@carambar

Beau projet ! Hésite pas à donner ton code ici si tu es sur GitHub.

Oui je t'envois par message privé les références du buzzer et du boitier. Mais pour la puissance du buzzer l'essentiel c'est le L9110.

A+

DiskPart est sympa, mais ...

Pour un utilisateur de PC lambda, cela me semble plus facile de lancer "Gestion de l'Ordinateur"
de choisir "Gestion des disques"
de sélectionner la SD
de supprimer le ou les volumes de la SD
et de créer un nouveau volume de 2048 formaté en FAT

 :coucou:

écran changé, nickel + carte SD formatée et en place.

quand j'allume après 4s, les chiffres défilent à toute vitesse et le buzzer crachote.
à chaque mise en route se créé un fichier GPS000.TXT, puis GPS001.TXT,puis GPS002.TXT ... tous vides

Quelqu'un a une idée ?
fréquence trop haute pour le baro ?

Oui c'est sûrement ça.

Il faut que tu arrives à compiler mon code maintenant.

Tu déplaces tout le contenu de "arduino" ailleurs et tu le remplaces par mon code.

Ensuite tu ouvre libraries/ms5611/ms5611.h avec notepad++

Tu change :
#define MS5611_INTERRUPT_COMPARE 69

Par :
#define MS5611_INTERRUPT_COMPARE 71

Tu compiles. Tu exporte les binaires compilés. Tu renomme en FIRM.HEX. Tu charge sur la carte SD. Tu reset L'arduino.

Tu peux aussi vérifier que t'arrive à charger les firmware avec le buzzer minimal que j'ai donné précédemment.

 :koi: cool, je comprends pas tout, tu va trop vite




c'est pas clair pour moi, j'ai besoin de plus de détails

j'ai notepad ++, je suppose que la libraries/ms5611/ms5611.h je vais la trouver dans ton code


Il faut que je retrouve tes explications, c'est dans ce fil, je crois.  :grat:

les FIRM.HEX se chargent bien
j'ai pu tester le buzzer et remettre le FIRM (pas celui modifié, je n'ai toujours pas compris)

Bin tu as du déjà programmer des trucs. Donc il faut que tu les sauvegardes ailleurs pour le moment. Donc tout le contenu de ton dossier "arduino" tu le coupes et tu le déplace ailleurs.

Ensuite tu met à la place mon code :

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

Oui ms5611.h est dans le code.

Et pour charger le firmware relis les messages précédents du fil. Au pire je t'envoies ce soir le fichier.

Et surtout tu utilises toujours les HEX sans bootloader ! Tu verras il t'en fait deux à chaque fois.

 :soleil:  :soleil:  :soleil:  :soleil:  :soleil:  :soleil:

un de plus qui fonctionne, merci de ton aide

(https://i58.servimg.com/u/f58/12/58/57/57/monvar10.jpg)

Comment tu le vois ?

Les fichiers sur la carte sont tous vides, pas de trace GPS  :grrr2:

Et le GPS arrive à se fixer ?

Tant que tu n'as pas l'affichage de la finesse et de la vitesse sol à l'écran c'est normal que les fichiers restent vides.

Ca y est ; mon vario fonctionne à nouveau, après manip de fer à souder (et pompe à dessouder !).
Sans le module bluetooth, que je n'ai pas encore soudé ; j'attends un peu, pour comparer ensuite les effets sur la réception GPS.

Pour le switch de mise en route ; ca me convient "tel quel" ; si on encoche assez large le boitier, ce n'est pas difficile de l'actionner, et pas de risque de mauvaise manoeuvre.

J'ai à l'écran la même chose que Van Hurlu dans le post précédent.
Donc, l'altitude qui semble correcte, le vario qui indique -0.3m/s alors que c'est immobile ; puis, en dessous, la vitesse en km/h qui n'est pas valuée; puis en bas à droite un "Gr".

Qu'est-ce qui est censé s'afficher de manière générale ? Comment savoir si on est en portée GPS, et quelle "puissance"  (intéressant de savoir, pour comparer après avoir mis en place le module bluetooth). ?

Je crois qu'il y a une procédure à exécuter pour calibrer l'installation ; c'est probablement ce qui explique le -0.3m/s à l'arret. Comment faut-il faire ?

C'est probablement dans ce fil de forum ; mais je n'ai pas trouvé ...
Et aussi dans le code ; mais je suis impatient de tester mon nouveau joujou ;-)

 :grat: j'ai posé la question plus haut, comment on fait pour savoir ?

Salut !

Lorsque le GPS "fix" le vario se met à afficher la vitesse sol devant l'unité "km/h". Et la finesse devant l'unité "Gr" (glide ratio).

En gros il doit y avoir deux zéro de plus qui s'affichent en bas de l'écran. Sauf si comme Xiboard on cours dans le jardin :D

Il y a effectivement un programme "calibration_nointeractive" sur mon github qui sert à calibrer l'accelerometre. Il faut charger sur le vario.

Il réalise un enregistrement toutes les 5 secondes. Il faut prendre des mesures dans toutes les orientations sauf pointant vers le bas. On repette les mesures en changeant chaque fois d'orientation. Le vario bippe aiguë chaque fois qu'il améliore la mesure. Une fois qu'il bippe toujours grave dans toutes les orientations il suffit de l'orienter vers le bas pour qu'il se calibre.

Après il faut charger à nouveau le code du vario. Je ferais un tuto la dessus. Il faudrais déjà que tout le monde maitrise le chargement des firmwares et la compilation du code.

À suivre.

Quelques retour après 2 petits vols

1- Le son mériterait d'être un peu moins fort - il semble qu'il soit possible facilement de le rendre paramétrable réglable par chacun
2- L'enregistrement me semble bien, il manque juste les altitudes barométriques - seul l'altitude gps est enregistrée
3- je trouve que le vario bip beaucoup dans du 0 à +1, prunkdump pourrait-tu nous donner la liste des variables de réglage afin de pouvoir affiner le comportement du vario.
4- le calage du gps en extérieur reste raisonnable, si le vario est allumé lors de la préparation de la voile, il est opérationnel lors du déco, c'est quelques choses qu'il faudrait essayer d'amélioré si on veut allumé le vario juste au moment du déco

une idée serait de mettre tout les réglages dans un fichier sur la carte sd ainsi on pourrait facilement sans compilation modifier, les seuils de monté et de descente, le volume, le zerotage, ....


super vario, merci prunkdump

Pour mon soucis de fermeture du boitier, il me semble que la carte baro vient faire court-circuit avec l'écran, du coup j'ai trouver une position de la batterie et un serrage des vis qui ne pose plus de problème
Pour le bouton reset je vais essayer un trou dans la face avant juste au dessus du bouton, du coup il sera possible de l'actionner boitier fermer, je vous ferais un retour dès que ce sera fait.
Pour le bouton marche l'idée c'est de pouvoir facilement allumé le vario avec les gants ou même en vol si on a oublier de le faire au déco

j'ai une suggestion, il pourrait être intéressant de mettre en place un système de suivi des améliorations
je m'explique, à chaque fois que quelqu'un propose une amélioration, on la liste et l'un d'entre nous en fonction de nos compétences pourra se charger de test, de recherche d'info ou de développement, du coup cela pourrait faire avancer le projet et décharger un peu prunkdump
Si une fonctionnalité est développé par un de nous prunkdump pourrait se charger de l’intégrer au code et en faire profité tout le monde

Je suis resté une heure sur ma terrasse, et je n'ai jamais vu de zéro en bas,
 il me semblait bien que je me réjouissais trop vite  :tomate:


... Et comme jpg63,
je suis preneur rapidement d'une soluce pour baisser le volume du buzzer.


Quelqu'un a-t-il une idée approximative du temps d'autonomie de la batterie bien chargée ?

Pour connaitre la capacité de la batterie il serait possible de faire une approximation.
Les batteries lipo n'ont pas une décharge linéaire mais il existe des tables qui donne une bonne idée de la charge

Si la tension mesuré est supérieur à 4.2 la batterie est full = 100%
en dessous de 3.683v c'est 0 est la batterie est pas loin d'être morte si elle n'est pas vite chargée

pour éviter la d'endommager et de réduire la durée de vie d'une lipo il faut éviter que sa tension descende en dessous de 30%, soit environ 3.8v

après voici une table de conversion tension - pourcentage de charge

{{3, 0}, {3.093, 1}, {3.196, 2}, {3.301, 3}, {3.401, 4}, {3.477, 5}, {3.544, 6}, {3.601, 7}, {3.637, 8}, {3.664, 9},
{3.679, 10}, {3.683, 11}, {3.689, 12}, {3.692, 13}, {3.705, 14}, {3.71, 15}, {3.713, 16}, {3.715, 17}, {3.72, 18}, {3.731, 19},
{3.735, 20}, {3.744, 21}, {3.753, 22}, {3.756, 23}, {3.758, 24}, {3.762, 25}, {3.767, 26}, {3.774, 27}, {3.78, 28}, {3.783, 29},
{3.786, 30}, {3.789, 31}, {3.794, 32}, {3.797, 33}, {3.8, 34}, {3.802, 35}, {3.805, 36}, {3.808, 37}, {3.811, 38}, {3.815, 39},
{3.818, 40}, {3.822, 41}, {3.825, 42}, {3.829, 43}, {3.833, 44}, {3.836, 45}, {3.84, 46}, {3.843, 47}, {3.847, 48}, {3.85, 49},
{3.854, 50}, {3.857, 51}, {3.86, 52}, {3.863, 53}, {3.866, 54}, {3.87, 55}, {3.874, 56}, {3.879, 57}, {3.888, 58}, {3.893, 59},
{3.897, 60}, {3.902, 61}, {3.906, 62}, {3.911, 63}, {3.918, 64}, {3.923, 65}, {3.928, 66}, {3.939, 67}, {3.943, 68}, {3.949, 69},
{3.955, 70}, {3.961, 71}, {3.968, 72}, {3.974, 73}, {3.981, 74}, {3.987, 75}, {3.994, 76}, {4.001, 77}, {4.007, 78}, {4.014, 79},
{4.021, 80}, {4.029, 81}, {4.036, 82}, {4.044, 83}, {4.052, 84}, {4.062, 85}, {4.074, 86}, {4.085, 87}, {4.095, 88}, {4.105, 89},
{4.111, 90}, {4.116, 91}, {4.12, 92}, {4.125, 93}, {4.129, 94}, {4.135, 95}, {4.145, 96}, {4.176, 97}, {4.179, 98}, {4.193, 99},
{4.2, 100}}   

pour être exacte il faudrait mesuré le courant de décharge mais pour nous la tension c'est largement suffisant

je crois qu'il n'existe pas d'instruction qui retourne la valeur de la tension Raw (tension directe de la batterie), donc une solution simple serait de raccorder la patte RAW à une entrée Analogique, A3 par exemple et de faire un petit barre graph pour indiquer la charge ou simplement le pourcentage

j'en profite pour lister les points qui reviennent ou qui on été abordés

- pouvoir régler le volume du son
- amélioré le fix du gps
- ajouter la mesure barométrique aux enregistrements sur la carte SD
- régler le problème du bluetooth
- trouver une solution simple pour mettre à jour l'arduino (bouton reset)
- rassembler tout les réglages (seuls, volume du son,...) dans un fichier de config sur la carte SD
- afficher l'heure et le temps de vol
- afficher la charge de la batterie et faire des tests d'autonomie, savoir quant la batterie est totalement chargée
- créer un programme qui récupère et convertie les trace en IGC et nettoie la carte SD des fichiers vides - (GPSBabel marche très bien mais cela demande pas mal de manip) - je pense que l'idée est aussi de rendre ce petit vario accessible au non informaticien et électronicien
   

@Van Hurlu

Décidément Van Hurlu tu n'est pas très chanceux :D ! Il t'arrives toutes les galères possible avec le vario. Au moins ça t'aura fait bricoler tu vas devenir un pro de la soudure ;)

Alors voilà ce que tu dois vérifier pour le GPS :

-> Vérifies la connexion de l'antenne en dessous et sort l'antenne de son logement de façon à la poser à côté du vario pointant vers le ciel. Testes si dans cette configuration tu arrives à capter les GPS. Si ce n'est pas le cas c'est qu'il y a un problème de connexion quelque part.

-> Vérifies au testeur de continuité les soudures du GPS. Sert toi de ce qui reste des connecteurs qui sortent en haut à gauche du vario. Et de haut en bas :

1) VCC -> pin RAW de l'arduino
2) RX -> non connecté
3) TX -> pin RXI de l'arduino
4) GND -> pin GND de l'arduino

-> Si c'est encore bon et bin il faut vérifier la soudure de l'antenne sur sa plaque. C'est le problème qui m'est arrivé sur mon vario à moi. Déconnectes l'antenne et suit le circuit du connecteur jusqu'au composant central avec son étiquette blanche. A la loupe regarde la soudure. Dans mon cas le composant n'étais pas bien plaqué sur sa plaque et du coup la soudure touchais le bas du composant mais ne montait pas suffisamment pour faire contact. Regardes bien. Si tu pense que c'est ça le problème. Dis le moi je t'expliquerais comment le ressouder.

@jpg63

Super la liste ! Pour faire un suivit et que tout le monde puisse participer je pensais ajouter un repo sur mon GitHub concernant le kit. Cela permettrait déjà à tout le monde de parler en français (je mentiens le code du vario en anglais). Et il y a une menu "issues" pour lister la liste des problèmes actuels du vario.

Ce qui est bien c'est que du coup il y a un fil de discution par "issues" et on peut en discuter séparément. C'est plus facile à suivre que sur le forum.

Pour la charge de la batterie il y plusieurs personnes qui sont passé sur ce fil et qui avaient implémenté cette fonctionnalité. Il faudrait qu'il nous disent comment faire.

J'aurai distingué plusieurs niveaux d'urgence :

1- l'indispensable pour que l'on puisse l'emmener en vol avec utilité tout de suite
- pouvoir régler le volume du son
- pouvoir changer la valeur de début de bip de montée et/ou la valeur d'intégration ?
- améliorer le fix du gps (là je répète, car le mien ne fixe rien du tout pour l'instant)

2- ce qui serait encore plus chouette
- trouver une solution simple pour mettre à jour l'arduino sans utiliser de bouton reset
- rassembler tout les réglages (seuils, volume du son, intégration, alarme de descente...) dans un fichier de config sur la carte SD  :pouce:
- afficher l'heure et le temps de vol

3- ce qui me ferait peut-être revendre mon skytraxx  :roll:
- écrire directement de l'IGC sur la carte SD (est-ce possible ?)
- faire l’interfaçage avec XCSoar (ou autre)
- que Logfly puisse lire directement la carte SD
- afficher la charge de la batterie

mon investissement de 50€ est déjà une réussite au vu du nombre de choses que j'ai apprises ... merci Baptiste  :trinq:


Question: quelqu'un connait un tuto pour apprendre à se servir XCSOAR ? La doc est un peu rebutante.



Dans ma jeunesse, j'ai été longtemps un pro de la soudure.
Je galère un peu, car j'utilise du fil de diamètre trop gros (1.5mm) Je conseille vivement à ceux qui n'ont pas commencé leur montage de se servir de fil beaucoup plus fin.

Je n'ai pas beaucoup de réussite sur ce coup, mais je suis un têtu et je finis toujours par réussir  :roll:
je me lance dans le dépannage du gps aujourd'hui (de toute façon la MTO est désastreuse)

Je me suis permis d'ajouter quelques issues à ton github

j'ai fait des test, mon GPS fixe en à peu prêt 2min

je viens de constaté que l'enregistrement des données débute au fix du GPS, il serait mieux que l'enregistrement début au début du vol - vitesse 3km/h changement altitude +- 3m en moins de 5sec

je vais travailler sur la modification de la bibliothèque nmea pour ajouter 2 fonctions - récupération de l'heure et récupération de l'heure en sec. Après je travaillerai sur l'affichage de l'heure et le calcul du temps de vol   

Salut à tous !

Désolé d'insister. Mais les "issues" concernant le Kit ne devraient pas se trouver dans "arduino-variometer". Uniquement celles concernant le code. Et il serait normalement mieux de les rédiger en anglais. Même si ce dernier point n'est pas très grave ...

J'ai créé un nouveau repository pour vous :

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

On pourra y mettre  les tutos concernant le kit et les différentes idées qui emmergent du forum. Vous pouvez vous lâcher ici  :D  et même en français  :prof:  Je dis ça parceque pas mal de personnes me contactent en anglais concernant "arduino-variometer" et je ne voudrais pas qu'ils croient que je ne réponds qu'en français.

Question importante pour ceux qui ont l'habitude d'utiliser les trames NMEA et les logiciels type XCSoar.

Je me suis donné de la peine pour substituer dans les trames NMEA les altitudes GPS par les altitudes barométrique puisqu'elles sont plus "précises".

Apparemment il semble que cette modif soit inutile puisque la majoritée des logiciels gèrent bien les deux données simultanément.

-> Pouvez vous me confirmer que c'est bien géré par XCSoar ? Comment reçoit-il les altitudes baro ? Uniquement avec la pression statique des trames open vario ?

-> Pouvez vous me confirmer que l'altitude baro est bien géré par le format IGC ? Lors de la convesion NMEA -> IGC comment le convertisseur extrait-il cette information ? Connait-il les trames OpenVario ?

-> Dans les programmes en ligne de type Logfly. L'altitude barométrique est-elle utilisée ? Ca serait dommage dans le cas contraire.

Il faut décider de cela pour savoir comment réécrire le bibliothèque NMEA.

A+

Désolé pour les issues, je vais les déplacer et les fermer sur "arduino-variometer"

merci pour le repository "variometer-kits"

converti avec gpsbabel les traces igc n'ont pas l'altitude baro

B0952074537844N00307002EA0000000802

B 095207 4537844N 00307002E A 00000 00802


l'enregistrement B de l'igc

B160245 5107126N 00149300W A 00288 00429 195 09 020

B
Time UTC      6 bytes   HHMMSS
Latitude      8 bytes   DDMMmmmN/S
Longitude      9 bytes   DDDMMmmmE/W
Fix validity   1 byte.   A or V
Press Alt.      5 bytes   PPPPP         Baro
GNSS Alt.      5 bytes   GGGGG         GPS

du coup l'altitude baro n'est pas géré dans LogFly

tout le reste est contrôlé, tout ok
je ne peux pas suivre le circuit de l'antenne qui est dessous
je ne peux pas facilement dessouder la carte GPS, il faudrait que je dessoude le lecteur

à la loupe toutes les soudures ont l'air bien sur le composant central

Si si tu peux voir la connexion de l'antenne. Elle n'est pas traversante.

-> Retourne le vario de façon à voir le petit cercle de connexion de l'antenne.
-> Suit le chemin qui part du petit cercle vers le composant avec l'étiquette blanche
-> Regarde s'il est bien soudé et s'il ne fait pas contact avec les composant adjacent.

J'essairai de te faire une photo détaillé.

https://lh3.googleusercontent.com/bT9Mnav-UKn0gTTUHpdshfXWAQrtf3wtRr7_TbvLXbR_Yt_GKwiJE34gRYUaiG2shkE1hlBhu8bY73HI7n_sbegS0OgAkyXJJKJaqdwhXlxHaZ0JwPm-aLhU2b5j_RzhXc0JLw=w1148-h765-no

Le chemin est juste à gauche de mon doigt.

tout semble bon,
toi tu as fait quoi ? tu as chauffé les soudures du gros ?

si j'étais sur que ça vienne de cette carte, j'en commanderai une autre !

Fixation au élévateurs et lien de sécurité

(https://img4.hostingpics.net/pics/73209320170430160344.jpg) (https://www.hostingpics.net/viewer.php?id=73209320170430160344.jpg)

(https://img4.hostingpics.net/pics/68379320170430160353.jpg) (https://www.hostingpics.net/viewer.php?id=68379320170430160353.jpg)

(https://img4.hostingpics.net/pics/45643020170430160549.jpg) (https://www.hostingpics.net/viewer.php?id=45643020170430160549.jpg)

(https://img4.hostingpics.net/pics/51648620170430160558.jpg) (https://www.hostingpics.net/viewer.php?id=51648620170430160558.jpg)


(https://img4.hostingpics.net/pics/38048520170430160400.jpg) (https://www.hostingpics.net/viewer.php?id=38048520170430160400.jpg)

(https://img4.hostingpics.net/pics/91427220170430160408.jpg) (https://www.hostingpics.net/viewer.php?id=91427220170430160408.jpg)

(https://img4.hostingpics.net/pics/92752020170430160433.jpg) (https://www.hostingpics.net/viewer.php?id=92752020170430160433.jpg)

Oui mais moi on voyait clairement qu'il n'y avait pas de soudure dans les creux du composant GPS. J'ai donc remis de la soudure au fer à souder. Mais c'est une soudure très delicate il faut faire attention.

L'antenne est elle bien connecté à la deuxième "patte" du composant ?

Est-ce que le petit voyant bleu du GPS s'allume lorsque tu met vario sous tension ?

Essayes de tout vérifier visuellement. Regarde s'il n'y a pas de composants qui semble mal positionné.

Joli boulot jpg63 !  :bravo:

Avec ça tu aura une visibilité nickel !

Plus qu'à tester tout ça en vol !  :D

pas de petit voyant bleu sur le GPS, je ne l'ai jamais vu s'allumer, je ne savais même pas qu'il y en avait un  :mrgreen:
pourtant il y a 3.6v à l'entrée du module gps ?
je t'ai fais un mail pour te demander la ref. je vais en commander un autre et arrêter de perdre du temps

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 !?! ;)  :sos:
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 :P 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! :pouce:
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.

 :coucou:

Salut à tous  :coucou:

@jpg63

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.

@guillaume1

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.

@Gej

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  :pouce: 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 :D

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 ... ! :sos:

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)


 :pouce:
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  :P 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 (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 :

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 :

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

ca yest ma v2 est monté :P  :P  :P  :P
 par contre on lit la trace gps avec quel logiciel  :soleil:

salut, tu peux convertir la trace NMEA fichier.txt en IGC avec GPSBABEL et l'importer dans LogFly, dans xcglobe ou même dans doarama

http://www.gpsvisualizer.com/gpsbabel/?lang=fr

http://logfly.org/index.php?id=google-earth-utilisation

http://xcglobe.com/login

https://doarama.com/

yes merci cool

ouf ca y est j'ai recu le mien! en effet il était dans la boite aux lettres du voisin ;)
Je me mets au montage la semaine prochaine

Salut à tous !

Bon courage encore à ce qui m'ont contacté et qui n'ont pas encore commencé où fini de monter leur vario ! ;)

Super guillaume1 pout ton montage. Tu vas pouvoir travailler avec nous. Merci jpg63 pour le test du code  :pouce:  Au moins un truc de résolu ! Il est possible maintenant de régler le volume du vario :D. Attends peut-être un peu pour modifier la bibliothèque nmea (Cf. ci-dessous). Merci pour ta video Xiboard ! Effectivement pour le moment le bluetooth doit être amélioré :? Selon la vitesse de la carte SD il fait bugger le vario.  J'explique ci-dessous d'où vient le problème. Tu n'as pas converti ton voisin au passage finlard   ;)  Si ça se trouve il est bon en électronique :D

Alors plus sérieusement :

Pour les trames du bluetooth/carte SD :

Il semble que le mélange actuel NMEA/Openvario ne soit pas une bonne idée. Il n'est ni pratique pour le fichier de trace (logfly, doarama ne le prennent pas) ni pour la communication bluetooth (Ca ne marche pas avec XCSoard ou XCTrack). Je pense qu'il n'y a pas le choix il faut changer de design...

Mais bonne nouvelle j'ai étudié le format IGC :

http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html

et les trames "IGC->B" sont très proche des trames "NMEA->RMC". Du coup il pourrait finalement ne pas être si difficile de sortir du format IGC du vario. Du coup cela règlerait le problème des traces sur la carte SD qui serait compatibles avec la majorité des logiciels.

Mais XCSoard et XCtrack supportent-ils la communication au format IGC ?

Je comprends pas tout mais il semble que IGC supporte également des trames permettant d'envoyer la variation d'altitude. Est-ce que les experts peuvent étudier la chose ?

Pour le bug du vario avec le bluetooth :

Le problème de stabilité du vario avec le bluetooth vient du fait que la boucle principale fonctionne ainsi :

-> Elle lis les capteurs de pression et d'acceleration et met à jour Kalman
-> Elle regarde si le GPS envoie des données :
-> Si oui :
----> elle lis les données du GPS
----> elle les interprète
----> elle les écrits sur la carte SD
----> elle les envoi en bluetooth

Ainsi comme le GPS envoi toutes les 2 secondes une grosse quantité de données. Lorsque le GPS n'envois rien le vario n'a presque rien à faire. Lorsque le GPS se met à envoyer il a tout d'un coup plein de travail. El il doit le finir avant de recommencer à lire les capteurs ! Et si en plus la carte SD est un peu lente...

Il faut que j'arrive à répartir les calculs du vario de façon plus régulière.

Autre chose. Le vario envoie plein d'info inutiles. Comme toutes les trames GPGSA et GPGSV.

A étudier ;)

@PrunkDump

Je pense que aucune appli ne gère la réception d'IGC. Mais oui les IGC c'est très simple et proche du NMEA.
J'ai fait une demande à la team de XCTrack pour qu'il me propose un protocole qu'il prennent en charge (XCTracker, GPSBip, BlueFly, ...). Moi j'ai cherché est j'ai pas réussi à trouver. Je sais que le protocole BlueFly est pris en compte par XCTrack et XCSoar. Mais j'arrive pas à le trouver. Il me semble que XCTracker et GPSBip étaient opensource mais pas trouvé ?


La vidéo que je t'ai envoyé, la carte SD était désactivée.
J'ai analysé le code mais je pige pas. hormis que effectivement se soit un problème de timing. Mais la lenteur de la carte SD ne doit pas rentrer en compte puisque je la désactive.
Je vais tenté de faire un essais en envoyant un "paquet" court par bluetooth pour voir s'il bug de la même manière.

prunkdump pas de soucis, je vais attendre un peu avant de développer l'affichage de l'heure et de la durée du vol.

pour IGC, j'ai regardé la même source que toi, pour comprendre un peu ce que renfermé ces fichiers

Voici un bout de fichier tiré d'un syride nav

AXSR
HFDTE220417
HFFXA035
HFPLTPILOTINCHARGE: jpg63
HFCM2CREW2:
HFGTYGLIDERTYPE: not set
HFGIDGLIDERID: 0
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 3.25
HFRHWHARDWAREVERSION: 1.0
HFFTYFRTYPE: Syride, SYS'Nav
HFGPS: UBlox,MAX7Q,56ch,10000m
HFPRSPRESSALTSENSOR: ST,LPS331AP,11000m
HFCIDCOMPETITIONID:
HFCCLCOMPETITIONCLASS: 3BB13301
I023638TAS3940SIU
B1415534537980N00306970EA007050082101709
B1415544537980N00306970EA007060082101909
B1415554537980N00306974EA007060082102009
B1415564537980N00306978EA007060082101909

..
G84A0EE5A3659F8099431432FDFE192CC09DAD7A77ADC8617334BA3B655E382EC
GBB88922E3E593FD42F3BA05D6C45A570C62573BA551819BB5B0B2F96B02180C4
GFC9430969F4EACB47C17F77916C7B4078703342A140FCD17AFE6FFEB6022D8B2
G5BBB6FDFA3E906F5DF0E8CEACFE73CB8217BB06F5BDD9B6D537838003598D13F

on voit que tout le début c'est juste du blabla et à la fin c'est une sorte de checksum. Le plus important c'est les enregistrements B qui restent très simple mais complet heure, position, alti baro et alti gps - le reste est gérer par logfly et autre (stat )

Pourrait-tu nous préciser à quoi servent chaque variable et si il en existe d'autre pour régler le vario, je vais faire quelques tests en vols des que possible

VARIOSCREEN_CONTRAST                   60         Contrast de l'écran      

VARIOMETER_BEEP_VOLUME                   6         volume du beeper

VARIOMETER_SINKING_THRESHOLD             -2.0      
VARIOMETER_CLIMBING_THRESHOLD             0.2         
VARIOMETER_NEAR_CLIMBING_SENSITIVITY          0.5

VARIOMETER_ENABLE_NEAR_CLIMBING_ALARM
VARIOMETER_ENABLE_NEAR_CLIMBING_BEEP

/* mean filter duration = filter size * 2 seconds */
VARIOMETER_SPEED_FILTER_SIZE                5

FLIGHT_START_MIN_TIMESTAMP                      15000
FLIGHT_START_VARIO_LOW_THRESHOLD                (-0.5)
FLIGHT_START_VARIO_HIGH_THRESHOLD                0.5
FLIGHT_START_MIN_SPEED                         10.0

Ouai ! La fin (ou d'ailleurs aussi pendant sur les gros enregistrements) c'est la signature pour certifier le fichier pour la FAI. Il faut être constructeur autorisé pour permettre ça, un bordel, faut oublier pour nous. (si j'ai bien tout compris)

@PrunkDump :
C'est quoi le moyen le plus simple pour faire le checksum ? pour un essai juste.

Salut. Comme ça rapidement le temps de faire un truc mieux :

Sinking -> seuil d'alarme de degueulante
Climbing -> seuil d'alarme d'ascendance
Near climbing -> distance du seuil d'ascendance à partir duquel le bip de zerotage s'enclenche

Near Climbing alarm -> trois bip lorsque l'on rentre dans la zone de zerorage, un bip grave lorsqu'on en sort
Near climbing beep -> beep de zerotage (! Active uniquement si le vol est détecté )

Speed filter size -> lissage de la vitesse pour le calcul de la finesse . Plus c'est long plus c'est lissé mais moins c'est réactif

Après c'est les réglages du détecteur de vol

Min timestamp -> temps minimal après allumage (ici 15 sec)
Low/high -> seuil d'ascendance ou degueulante
Min speed -> vitesse minimale

Pour le checksum

http://www.hhhh.org/wiml/proj/nmeaxor.html

Hello,

pour faire de l'IGC, c'est simple, il suffit de suivre ce doc :
http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/ (DSL, en anglais ...)
pour le valider FAI, c'est un peu plus casse pied :
Il faut faire genre un MD5 sur quasi tous les champs, et ensuite crypter le résultat du MD5 par un algo genre sha256, et ca deviendra la ligne G
Pour encrypter, il faut une clé privée et une clé publique. La FAI oblige a garder la clé privée d'encryptage secrete (pas compatible avec de l'open source ....)
Ensuite, ils demandent de faire un programme en ligne de commande qui dit si le fichier a été modifié ou pas. Cela leur servira sur leur serveur a valider le fichier.

Si on ne crypte pas le fichier, le GPX suffit amplement car c'est reconnu par la FFVL. (Sinon, on trouve des convertisseurs qui encryptent le GPX a la volée pour le rendre valide FAI)
Si vous avez des questions, j'ai déjà validé FAI un vario ;)

Salut,

Concernant l'enregistrement sur sdcard :
je crois que ca ne devrait pas se faire au rythme des infos GPS, mais toutes les n secondes (3, voire 5) pour limiter la taille de la trace, eet surtout ne pas pénaliser le fonctionnement du reste.

Concernant les trames NMEA utiles a transmettre en bluetooth :

je pense en effet qu'il faut élaguer les trames actuellement générées par le vario (si ce sont les mêmes trames que celles enregistrées sur la sdcard).
A coup sur : on peut abandonner les trames GPVTG (direction et vitesse), GPGSA (précision et satellites actifs), GPGLL (latitude, longitude, heure), GPGSV (satellites en vue)

Les trames essentielles sont  :
GPRMC et GPGGA : elle délivrent des infos GPS :

GPRMC : c'est le minimum syndical.
        heure UTC, info de fix GPS, latitude / longitude GPS, vitesse sol (en noeuds), azimut de déplacement (en degrés - pas renseigné ici), ...

GPGGA : heure du système GPS, et les infos GPS. redondant par rapport à la trame précédente, mais très utilisée

Après, il faut pouvoir envoyer au moins les infos de vario et d'altitude barométrique, ou de pression ; c'est la plus-value de ce vario pour un système de navigation extérieur.

Il y a les trames openvario ($POV) ; décrite à http://www.openvario.org/doku.php?id=projects:series_00:software:nmea

Le vario actuel ne semble envoyer que des trames de type "$POV,E" ; donc l'info de vario. Si on choisi d'utiliser les trames openvario, il faudrait au moins ajouter l'info de pression atmosphérique


J'ai regardé les trames envoyées par le simulateur de vol condor, qui sont interprétées par les logiciels de navigation aérienne :
GPRMC, GPGGA, et LXWP0

A noter également que la trame LXWP0 est aussi utilisée par XCtracer pour XCSoar : http://www.windeckfalken.de/51-diverses/diverses/228-xcsoar-en

Ca semble une valeur sure.


description d'une trame LXWP0 :
0 loger_stored (Y/N)
1 IAS (kph)    IAS : Indicated Air Speed (vitesse indiquée, avec les erreurs)
2 baroaltitude (m)
3 vario (m/s)
4-8 unknown
9 heading of plane
10 windcourse (deg)
11 windspeed (kph)


A savoir pour XCSoar :
si on déclare un driver spécifique, il sait interpreter en plus un certain nombre de trames standard ; au moins les trames GPRMC, GPGGA

On choisi le driver dans le menu "config - Périph"
Ca propose un nombre important de drivers, dont openvario (trames POV) et LXNAV (trames LXWP0)

Conclusion :
- il faut les trames GPRMC et GPGGA
- si on choisi d'ajouter la trame POV openvario, ca serait bien d'avoir en plus de l'info de vario celle de pression atmosphérique
- sinon, il faut remplacer les trames PVO par des trames LXWP0

Tout cela est théorique : je n'ai pas fait de tests ...

Merci beaucoup pour ces précisions, Prunkdump

pour les variables

Climbing -> seuil d'alarme d'ascendance
Near climbing -> distance du seuil d'ascendance à partir duquel le bip de zerotage s'enclenche

une petite précision pour que je comprenne bien

si j'ai Climbing = 0.2
et Near climbing = 0.5

le zérotage bip de 0 à +0.5 ?
et le bips de monté démarre à partit de 0.2 ?

Si je veux que les bips de montés débutent à +0.5 et le zérotage entre 0 et +0.5 tu peux me dire quelles valeurs doit-on mettre ? pour que je comprenne bien  

Attention logfly et xcglobe n'accepte que l'igc

je vais tester un igc sans la validation sur logfly et xcglobe pour voir si ils acceptent le fichier

Merci beaucoup  vmath54 ! Effectivement ta proposition semble la plus "universelle".


Pourtant Xiboard semblait dire que s'il mettait le driver openvario dans XCSoar, il ne reconnaissait plus les trames NMEA. Il faudrait être sur avant de se lancer dans le développement. Dommage que je n'ai rien pour tester.

@jpg63

"Near climbing sensibility" est la sensibilité du détecteur de zérotage.

Avec climbing = 0.2 et sensitivity = 0.5 le zerotage commence à 0.2-0.5=-0.3 et le bip commence à 0.5.

Donc dans ton cas tu met climbing = 0.5 et sensitivity = 0.5

Je peux faire des essais.

Peut-être que le protocole "Condor Soaring Simulator" permet de lire en même temps trames GPRMC, GPGGA, et LXWP0 ?
C'est ça vmath54 ?

hello,

Rentré de vacances hier, le kit du vario m'attendait dans la boite avec impatience depuis plus une semaine...
Monté dans la soirée : nickel, super impressionné par l'optimisation de la conception de Prunkdump c'est vraiment bluffant, tu es trop fort  :pouce: .  (et merci pour le pre-machage de boulot...)

Infos dans ce fil trés utiles en complément du tuto (n'en déplaise à Pseudo !).
en particulier:

Aprés ça, tout fonctionne bien, testé au sol dans plusieurs modes (avec et sans accel, avec sans écran etc.)
1er fix un peu long, mais les suivants semblent plus rapides.

Mon seul point d'inquiétude concerne l'antenne du GPS, qui est masquée non seulement par le module BT (en en a causé plus haut) mais aussi par l'écran, ce que je n'avais pas compris, et qui est plus dur à changer...
Ca risque de poser des pbms un peu aléatoires dans certaines conditions, à tester.
J'ai aussi quelques doutes sur l'autonomie, vue la taille de la batterie, et avec toutes ces fonctions, on verra bien.

Concernant le reset non accessible, j'ai fait une petite mod qui marche impec :  j'ai routé la pin "rst" de l'arduino vers une pin Data non utilisée sur le port µUSB.
J'ai sacrifié une prise mâle pour faire un shunt externe entre gnd et la pin cablée.
Il suffit de brancher la prise momentanément pour faire un reset, c'est trés pratique. (cf fil jaune et prise shunté ci dessous):

(https://img4.hostingpics.net/pics/811389IMG20170502232731HDR.jpg) (https://www.hostingpics.net/viewer.php?id=811389IMG20170502232731HDR.jpg)

il va aussi falloir que je test la procédure de calibration, car avec accel,  j'ai un offset selon l'orientation.
Une question Prunkdump : en l'absence d'eprom, ou seront stockées les coefficients mis à jour aprés calibration? dans un fichier sur la carte SD? quid des modes "//define HaveSD"?
merci d'avance !

A+

salut ptikiki

:+1:
j'en rajoute une couche, super boulot, du travail de pro, c'est un plaisir à monter et à regarder. Merci


Totalement d'accord


je crois avoir lu que ce GPS, récupère et stocke les positions des satellites, il est peut être possible de lui injecter des données pour accélérer le Fix

http://aprs.facile.free.fr/APRS%20FACILE%20gps%20gratuit.php#.WQlU5_nyjIW

je pense qu'après le 1er fix il trouve directement les satellites. Je pense aussi que si tu ne l'utilise pas de quelques jours, le fix au rallumage va être long, à confirmer


je pense qu'on pourra avoir une idée, dès que la modif de la mesure et de l'affichage de la tension sera en place - je travaille dessus



Super idée, si on opte pas pour la mise à jour sans reset (modif du bootloader), je monte ton idée, car j'aimerai bien fermer définitivement mon vario

Pareil

Pour le BlueFlyVario, j'ai trouvé cette page http://blueflyvario.blogspot.fr/2013/11/


Si cela peut vous aider...

Voici la procédure de qualibration de l'acceléromètre.

Dites moi si vous voyez bien les sous-titres ?

http://www.youtube.com/watch?v=fc0vIsZJvsw

Attention de bien prendre la dernière version de "calibration_nointeractive" !

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

Merci Gej pour ces infos ! En gros le blueflyvario supporte tous les formats de sorties possibles !  :shock:  Mais je ne sais pas comment il mélange les trames GPS. Malheureusement ce n'est pas détaillé sur cette page :

http://blueflyvario.blogspot.fr/2016/04/blueflyvariottlgpsv11-released.html

Mais c'est bien compatible avec XCSoar...

Nickel la proc de calibration ! Oui, c'est ok les sous-titres.  :pouce:

Moi je teste ce soir une version du code modifié sans sd et sans gps pour juste envoyer Pression, Alti, Vario via les trames  LK8EX1 via Bluetooth (toutes les 0.5s).
Je fait un retour. Si ça déconne pas je le laisse comme ça, couplé à XCTrack, je suis en principe en stage cross la semaine prochaine vers StHill & Co.

Le BlueFly Vario, le GPSBip et XCTracker, tu choisi le protocole il me semble mais oui ils sont tous compatibles de quelques protocoles.

J'avais vu l'info sur type de output du bluefly, je suis étonné que le standard c'est d'envoyer le raw pressure non filtrée.

Merci également ptitkiki pour les encouragements !  :pouce: Qu'il est malin celui là ! Jolis le coup pour le bouton reset.

Content que le montage t'ai plu ! ;)

Pour la réception GPS il me semble bizarrement que l'écran ne perturbe par trop alors que le bluetooth un peu plus. Il va falloir étudier ça.

A la base j'avais pensé retourner complètement le vario et mettre l'écran de l'autre côté au dessus de la batterie. Mais cela met l'ouverture de la carte SD face au vent et ce n'est pas une bonne idée.

Il faut réfléchir encore.

J'essai désespérément de convertir les fichiers xbm du répertoire fonts en bmp afin de pouvoir m'en servir d'exemple pour dessiner des petits  logos de batterie pour l'affichage de la capacité de charge du vario, et j'avoue que je me heurte à un soucis. Tout les convertisseurs que j'ai testé me donnent des trucs bizarre mais vraiment pas les logos affichés sur l'écran nokia. Quelqu'un aurait une idée 

Merci prunkdrump pour la procédure de calibration, c'est parfait.
(et oublie ma question  bête sur le stockage des coeffs de calibration dans l'eeprom  :bu: )

ca yest le miens est monté et je l ai testé hier en bord de mer

il est super réactif par contre l altitude est du n importe quoi une fois 6m je reallume 20m et une 3eme fois 45 mla c etait bon  :(  comment est initialisé l altimètre ?

pour l enregistrement de la trace j ai des fichier avec plein de symbole bizare le pense que cela vient du fait que jutilise une micro sd avec adaptateur .

quand un eteint le vario et qu on le reallume cela creer une nouvelle trace ou ca ecrase la premiere?

Ouai c'est pas évident ....  :?

Déjà je ne sais pas si tu as vu mais il faut travailler sur des lignes de 8 pixels. Chaque octet donne l'état des pixels en colonne. Donc pour dessiner un truc du genre d'une largeur de 10 :

1111111111
1000000001
1011001101
1011001101
1011001101
1000000001
1000000001
1111111111

Il faut taper un octet par colonne { 0xff, 0x81, 0xb9, 0xb9, 0x81, 0x81, 0xb9, 0xb9, 0x81, 0xff }.

Si tu as plusieurs lignes tu continues les lignes de haut en bas à la suite. Malheureusement XBM ne fonctionne pas dans le même sens... Pas de chance... Chaque octet donne une ligne de 8 et pas une colonne. Donc voici comment tricher avec un éditeur d'image genre Gimp :

1) Tu créé ton image classiquement. Elle doit avoir une hauteur multiple de 8. Pour la largeur tu met ce que tu veux.
2) Tu tournes ton image de 90° dans le sens anti-horaire.
3) Tu fait un mirroir horizontal

-> Tu as maintenant une image d'une hauteur quelconque et d'une largeur multiple de 8. Tu découpes mentalement verticalement  cette image en bloc de largeur 8. Je prends l'exemple d'une image de 24*8. Tu as donc trois blocs disposés horizontalement :

(bloc A de 8*11) <-> (bloc B de 8*11) <-> (bloc C de 8*11)

4) Tu créé une nouvelle image de largeur 8 et de hauteur 3*11=33 et tu colle les blocs l'un sous l'autre :

(bloc A de 8*11)
(bloc B de 8*11)
(bloc C de 8*11)

5) Tu enregistres en XBM. Et tu n'as plus qu'a copier dans le code. Dans le github tu as des exemples sous le répertoire "fonts".

Pour ton idée de charge de la batterie :

Effectivement ça serait peut-être mieux de mettre juste un symbole avec trois bloc [###] plutôt qu'un pourcentage. Ca prends moins de mémoire et en plus c'est plus simple à coder. Il n'y a plus que trois seuils à enregistrer !

@guillaume1

Attention le ms5611 est très sensible au vent et à la lumière. Est tu certain que ton boîtier est suffisamment opaque et bien fermé ? Sinon met un bout de mousse dessus scotché (attention pas de scotch sur le composant, il faut passer large).

Essaye aussi de ralentir une peu la fréquence tu baro :

-> librairies/ms5611.h

Change :

#if F_CPU >= 16000000L
#define MS5611_INTERRUPT_COMPARE 130
#else
#define MS5611_INTERRUPT_COMPARE 69
#endif

en

#if F_CPU >= 16000000L
#define MS5611_INTERRUPT_COMPARE 134
#else
#define MS5611_INTERRUPT_COMPARE 71
#endif

Autrement c'est que tu t'es pris une perturbation :D Sans rire ça peut faire vite varier l'altitude barométrique. Normalement l'altitude se recale quand le GPS fait le fix.

Pour la carte SD c'est peut-être le formatage. Cherche le tuto de Xiboard (page 21) sur le formatage avec diskpart. Autrement chaque fois qu'on éteint le vario ça créé une nouvelle trace.

@ptitkiki

Pas de soucis ! Effectivement les atmega328P sont équipé d'une EEPROM.

Merci pour l'explication.
Bonne idée les 3 blocs, je vais travailler mes petits dessins  :D

Effectivement, mon soucis avec une carte de 1Go, c'était aussi une micro-sd dans un adaptateur. J'ai rien pu faire, j'avais bien les enregistrements mais que des symboles ou des morceaux de l'ancienne mémoire. A voir effectivement !

pour info ça marche bien chez moi avec un adapteur et µSD 4Go...
Formatée en FAT sous windows dans l'utilitaire de gestion de disc intégré à l'OS

A noter aussi que plusieurs protocoles permettent de remonter l'info batterie ($LK8EX1 par exemple). Dans ce cas le niveau de batterie s'affiche sur XCTrack par exemple.

Moi une autre info que je verrai à rajouter, c'est la température. J'avais dans l'idée de tester des choses genre alti vs température pour déterminer l'inversion ou d'autres idée dans ce style. (Pb : difficile de pas avoir l'influence du soleil sur cette mesure) Pour info, on peux extraire la température interne de l'Atmga mais ça doit être bon pendant 1-2 min après il chauffe. Tout ça c'est de l'expérimental, donc, je m'amuserai peut-être sur un autre montage....

Remarque. Il y a déjà deux "vrais" capteurs de température dans le vario.

Un dans le ms5611 :

-> dans libraries/ms5611.h

Et un dans le mpu9250. Dans ce deuxième cas aucune idée à quoi il peut servir  :grat:

A part pour déterminer la pression dynamique je crois qu'on est bien équipé :D

A ouai le con !! J'avais même pas vu  :tomate:  Alors que j'ai lu 2-3 fois ta lib ms5611 !!

Pas trop d'accord ; NMEA n'est pas que du pur GPS.
Les trames "standards" NMEA sont très branchées GPS ; mais d'autres trames NMEA "privées" sont utilisées, comme openvario, LXNAV, ...
Ces trames peuvent ajouter d'autres infos, si on a les capteurs qui vont bien : vitesse par rapport à l'air, température, pression, vario, ...
Les trames openvario sont assez spécifiques : elles sont "typées". Voir http://www.openvario.org/doku.php?id=projects:series_00:software:nmea

Je crois que notre vario n'utilise que le type "E", qui envoie les infos de vario (variation en m/s)
openvario propose aussi des types de trames qui contiennent la pression, la température, la vitesse par rapport au vent, ...


Je ne pense pas. en tout cas, pour XCSoar, c'est non. Les périphériques d'entrées doivent communiquer en NMEA ; par contre, XCSoar enregistre les logs des vols en IGC




Pour XCSoar ; j'ai regardé dans le code.
Si je ne me trompe pas, Parser.cpp (https://github.com/XCSoar/XCSoar/blob/master/src/Device/Parser.cpp) indique les trames traitées systématiquement. On y voit dedans entre autres GPRMC et GPGGA

Voir le  code du driver openvario : https://github.com/XCSoar/XCSoar/blob/master/src/Device/Driver/OpenVario.cpp et de LXNAV : https://github.com/XCSoar/XCSoar/blob/master/src/Device/Driver/LX/Parser.cpp
C'est intéressant, le format NMEA de ces trames est décrit dedans

prunkdump, je vais faire des essais avec condor et XCSoar en utilisant le driver openvario ; ca validera (ou non) le fait qu'il continue à traiter les trames GPRMC et GPGGA


Non, c'est l'inverse. Condor peut exporter les informations de vol en simu dans des trames NMEA vers la sortie série (et en bricolant un peu, vers du TCP) ; si on le fait, il exporte les 3 trames précédentes.
Et donc, on peut brancher une appli de navigation aérienne (testé avec XCSoar) au simulateur.
C'est très sympa, et ca permet de prendre en main une appli comme XCSoar chez soi, au lieu de bricoler en vol.

Arff ! Xiboard, je viens de m'apercevoir que j'ai mal compris ta question.
En fait, tu demandais si le driver XCSoar "Condor Soaring Simulator" permettait de lire en même temps trames GPRMC, GPGGA, et LXWP0.

Désolé pour ma réponse à coté.

Voici un premier essai que je viens de faire ; je vais creuser.

- utilisation du simulateur condor, qui envoie des trames GPRMC, GPGGA, et LXWP0

- essai avec le driver XCSoar "generic" ; on a les infos GPS, pas barométriques

- essai avec le driver "openvario" ; idem. C'est le résultat supposé. Donc, les trames "de base GPS" sont reconnues, avec ce driver

- essai avec le driver "Condor Soaring Simulator" ; c'est intéressant. En plus des infos GPS, j'ai bien l'info barométrique.
  Ca répond donc à ta question : oui, ce driver interprete bien les trames GPRMC, GPGGA, et LXWP0

- essai avec le driver LXNAV ; ben, comme generic et openvario. Seules les infos GPS sont reconnues. J'aurais bien aimé que les trames LXWP0 le soient également

Ces qqs essais rapides semblent confirmer que les trames GPRMC et GPGGA sont toujours interpretées, quelque soit le driver (je n'ai validé que pour 3 d'entre eux, mais le code semble le confirmer).

Je vais creuser.

  . d'un coté, essayer de voir dans les sources XCSoar pourquoi les trames LXWP0 ne sont pas reconnues avec le driver LXNAV ; au moins pour les infos barométriques
  . d'autre part, essayer de générer par script des trames NMEA openvario de type "baro", pour voir si c'est reconnu.

J'ai rajouté un bout de code (dégeux) pour faire quelques essais :

GPS et SDCard désactivés.

Envoie de 10 paquets par secondes. (testé à 1/s et 5/s)
Test sur XCSoar, XCTrack et FlyMe sur tablette.
Test avec les protocoles : LK8EX1, LXWP0 et PRS (BlueFly).

XCSoar :
LXWP0 et PRS fonctionnent.

XCTrack :
PRS fonctionne bien.
LK8EX1 fonctionne mais très mal, ça tourne à 1 point toute les 5-10s. Je pige pas !
Faut que je vérifie que je me plante pas dans le checksum ou autre.

FlyMe :
PRS fonctionne.

Donc on pourrai penser que le protocole BlueFly est le mieux psk il marche pour tous, sauf que. ça envoie que la pression en brut. Donc on perds le gros avantage de l'accelero et du filtre de kalman. D'ailleurs on le vois tout de suite, même si les valeurs sont bonnes, le vario 'ram' à l'affichage par rapport au son et l'indication sur l'écran.
J'ai du mal à comprendre que BlueFly n'envoie que la pression en brut dans son protocole. vmath54 t'as vu des choses dans le code de XCSoar ?

Dans le mpu, il sert a faire la compensation en temperature pour compenser les variations d'acceleration et de gyro qui sont super sensible a la temperature.
Dans certaines centrales inertielles, il y a meme un boitier qui maintient une temperature fixe afin de limiter les variations.

J'ai bien un problème de checksum avec le protocole LK8EX1.
Faut que je cherche à comprendre, car ça semble un bon protocole pour XCTrack, à voir donc.

EDIT : Quel con, je viens de comprendre, j'ai oublié de faire le reset du Checksum  :tomate:

Je lis dans ce post : http://blueflyvario.blogspot.fr/2016/04/blueflyvariottlgps-over-usb-on-android.html que l'intéret principal d'utiliser le driver blyeflyvario dans XCSoar est de pouvoir "manager" le blueflyvario depuis XCSoar (par exemple, pour régler le volume du blueflyvario) ; j'en déduis que les trames NMEA sont bi-directionnelles :
  . du blueflyvario pour transmettre à XCSoar les infos de pression et de GPS
  . moins courant, de XCSoar vers le blueflyvario pour envoyer des settings comme le niveau sonore, ...
Sinon, ce post préconise les trames LXWPO et le driver LXNAV depuis blueflyvario.

Voir aussi ce manuel : https://www.blueflyvario.com/files/BFV_HardwareSettings_Manual_v1.6.pdf à la section "outputMode" ; c'est la ou on indique à blueflyvario le type de trames NMEA qu'il va envoyer (en plus des trames $GPGGA qui contiennent les données GPS et $GPGSA qui indiquent les satellites captés)
0 : trames PRS : n'envoie que la pression, non filtrée
1 : trames LK8EX1, à destination d'un LK8000
2 : trames LXWPO. Il est indique de le blueflyvario se limite à transmettre les infos d'altitude baro, et de vario. Il est indiqué que l'info d'altitude baro est calculée à partir d'un filtre, qui utilise un setting de QNH (a parametrer dans blueflyvario)
3, 5 et 6: trames BFV. Le format est : "$BFV,pressure(Pa),vario(cm/s), temp(deg C), battery(%),pitotDiffPressure(pa), volts(V)*checksum\r\n".

Coté code XCSoar du driver blueFlyVario : https://github.com/XCSoar/XCSoar/blob/master/src/Device/Driver/BlueFly/Parser.cpp et Settings.cpp
On voit dans le code que ce driver est capable de traiter différentes trames spécifiques : PRS, BAT, BFV, BST, SET (fonction ParseNMEA)
. BAT (fonction ParseBAT) : infos sur niveau de batterie
. PRS (fonction ParsePRS) : pression atmosphérique. On voit qu'il y a application d'un filtre kalman lors de la recup d'une trame PRS, ce qui est normal, puisque le blueflye envoir des infos non filtrées
. BFV (fonction ParseBFV) : le driver n'a pas l'air de traiter
. BST et SET : je crois comprendre que c'est en lien avec la partie "management", donc l'envoi de trames de XCSoar vers le blueflyvario


Donc, la trame PRS est trop pauvre, et la trame BFV qui pourrait être intéressante n'est à priori pas traitée par XSSoar.



D'une manière plus générale : je ne comprends pas comment notre vario peut envoyer une altitude barométrique ; je ne vois pas comment il peut la calculer.
Il a connaissance de la pression, mais comme on ne peut pas entrer l'altitude de décollage (le QNH), il ne peut pas en déduire une altitude : celle-ci dépend des conditions atmosphériques du jour. Je suppose que le vario le déduit de l'info GPS, mais l'info n'est donc plus vraiment une pression barométrique.
Je me trompe ?

Un truc intéressant, quand on regarde le code du driver LXNAV (en particulier, Settings.cpp) : il a aussi la possibilité de "manager" le LXNAV ; et en particulier de remonter vers le LXNAV l'info de QHN (altitude du terrain de décollage) qu'on peut entrer dans XCSoar avant de décoller. CA pourrait être sympa, non ?


En tout cas, très intéressant, Xibord, ta manière de tester.

De mon coté, je vais essayer de rejouer des trames IGC récupérées de vols réels.
J'aimerais tester les trames openvario, en transmettrant des trames de type E (vario en m/s) et P (pression statique en hPa)
voir http://www.openvario.org/doku.php?id=projects:series_00:software:nmea

J'ai l'impression, en regardant le code, que XCSoar ne réapplique pas de filtre lors de la lecture de pression ; et comme on envoie également les infos de vario, ca devrait être tout bon, non ?

Yess génial ça, merci, j'avais pourtant lu les documents cités mais je suis passé à côté.
Je vais tester les trames BFV

Honnêtement, j'ai utilisé XCSoar un peu. Je l'ai même paramétré à ma sauce. J'ai passé pas mal de temps à 'jouer' avec en mode simu sur PC. Je lui trouve des qualités mais après, j'accroche pas. (LE truc que je trouve sympa, c'est la projection de la finesse évalué sur le sol topo, le reste tout est mieux chez XCTrack, je trouve)

Bref, Je vais teste la trame BFV sur XCTrack et FlyMe pour voir s'il utilisent la valeur vario que l'on envoie.
Actuellement même avec la trame LK8EX1 dans XCTrack et LXWPO dans XCSoar, ils ne semblent pas utiliser l'info vario mais le recalculent avec la valeur de la pression. Donc retard. Mais tout de même bcp plus précis que GPS.
Sous XCTrack, tu peux choisir de 'recaler' en continu alti baro avec l'alti GPS.

Dans notre vario actuellement, on recale l'alti baro lorsque que l'on à fait le fix GPS et à la 5eme réception de données GPS. Ça marche mais c'est un point à améliorer plus tard, on le sait.

Par rapport à la com XCSoar vers un vario (BlueFly par exemple) oui c'est possible d'envoyer des commandes. Mais avec notre vario on ne pourra pas je pense. En effet on utilise le port Serial déjà dans les deux sens :
TX > Bluetooth
RX < GPS

Donc on ne peux rien envoyer au GPS et on ne peux rien recevoir du Bluetooth.

Les trames LK8EX1 fonctionnent au top dans XCTRack. Mais comme je l'ai dit, je pense qu'il utilise pas la donnée vario envoyé. J'affiche même la température à la place du voltage batterie. (XCTrack n'a pas de widget Température)

Au top le Github de XCSoar, on trouve toute les infos :

 * Native XTRC sentences
 * $XCTRC,2015,1,5,16,34,33,36,46.947508,7.453117,540.32,12.35,270.4,2.78,,,,964.93,98*67
 *
 * $XCTRC,year,month,day,hour,minute,second,centisecond,latitude,longitude,altitude,speedoverground,
 *      course,climbrate,res,res,res,rawpressure,batteryindication*checksum
 *
 * OR in LXWP0 mode with GPS sentences
 * $GPGGA,081158.400,4837.7021,N,00806.2928,E,2,5,1.57,113.9,M,47.9,M,,*5B
 * $LXWP0,N,,119.9,0.16,,,,,,259,,*64
 * $GPRMC,081158.800,A,4837.7018,N,00806.2923,E,2.34,261.89,110815,,,D*69

On va bien finir par trouver une trame un peu universelle pour tous.

J'ai un peu gratté coté trames NMEA.

J'avais sous le coude quelques scripts perl qui sont capables de lire un fichier .igc, et d'envoyer des trames NMEA correspondantes en UDP ou TCP ; l'idée était de  faire des tests avec XCSoar et de les rejouer.

En fait, XCSoar propose déja un mode simulation, ou il est capable seul de rejouer un IGC ; je voulais être capable de transformer de l'IGC en trames NMEA, et de vérifier.

Je ne traitais jusqu'alors que les trames GPGGA et GPRMC ; j'ai rajouté les trames POV (openvario) et LXWPO (LXNAV).

C'est dispo à https://github.com/vmath54/xcsoar/tree/master/IGC , avec 2 fichiers IGC issus d'un vol réel, un produit par un FLARM, l'autre par XCSoar.
Ce sont des scripts perl.

Essais avec les trames POV (openvario)
--------------------------
J'ai fait avec les trames de type E (infos de vario en m/s) et P (pression statique en hPa).
Ca marche impecc : je récupère bien dans XCSoar l'altitude barométrique et l'info de vario.

Ces infos ont précédence sur les infos calculées à partir du GPS.

A noter que XCSoar l'affiche l'info d'altitude barométrique que si on a saisi le QNH (pression atmosphérique du moment à 0m), ce qui est cohérent.

A noter également qu'on peut transmettre d'autres infos avec les trames POV ; pour ce qui nous intéresse, la température et la tension en volts.


Donc, les trames d'openvario semblent très intéressantes pour notre affaire. A voir si compatible avec d'autres logiciels que XCSoar.


Essais avec les trames LXWPO (LXNAV)
----------------------------
Ca ne fonctionne pas ; XCSoar n'interprete pas ces trame, je ne sais pas pourquoi. J'ai bien déclaré le driver LXNAV, et XSCoar recoit bien ces trames.

Je n'envoie que les infos d'altitude barométrique, et de vario :
$LXWPO,Y,,1603,0.00,,,,,,,,*1F
$LXWPO,Y,,1607,1.00,,,,,,,,*1A
$LXWPO,Y,,1608,0.25,,,,,,,,*13

Xiboard, j'ai aussi essayé de faire comme toi, et de mettre 0 dans certains champs :
$LXWPO,Y,0,1603,0.00,,,,,,0,0,0*1F
$LXWPO,Y,0,1607,1.00,,,,,,0,0,0*1A
$LXWPO,Y,0,1608,0.25,,,,,,0,0,0*13

Pas mieux. Je pense qu'il y a une gougoune de mon coté, je ne vois pas ou.
Si tu as une idée, je suis preneur

Salut à tous !  :coucou:

Moi aussi j'ai bossé ! :D  J'ai fini la mise à jour du firmware sans le bouton reset. Voilà comment procéder :

-> Téléchargez la dernière version du code https://github.com/prunkdump/arduino-variometer et compiler variometer.ino
-> Chargez le code avec la SDCard et le bouton reset (pour la dernière fois  ;) )
-> Remontez le boîtier.

Pour mettre à jour le firmware par la suite :

-> éteindre le vario
-> le retouner face posé vers le bas sur une table
-> mettre sous tension
-> au bout d'un moment il fait 3 bips longs.
-> pendant ces bips retourner le vario pour qu'il ne relance pas la mise à jour à nouveau au prochain démarrage.

Voilà.

Pour la communication avec le bluetooth :

Merci Xiboard et Vmath54 pour tout ce boulot ! Au point où on en est, on peut très bien programmer plusieurs drivers pour que l'utilisateur puisse choisir le type de trames à envoyer par le bluetooth lors de la compilation. Mais trouver une trame "par défaut" qui fonctionne avec un maximum de logiciels serait quand même bien !


Ca serait vraiment dommage qu'aucun des logiciels ne sache lire directement la valeur de vario ....  :?  En plus elle est précise et réactive ici. Par contre je pense que ce n'est pas grave d'envoyer la pression barométrique non fiiltré si l'info vario est utilisé. Vu la faible fréquence... On est quand même à une précision de 18cm sans filtrage  et le décalage n'est pas très grave pour l'affichage de l'altitude.


En fait la pin TX du bluetooth est quand même connecté à l'arduino. Donc c'est possible de communiquer dans les deux sens avec la bibliothèque "SoftwareSerial". Mais je pense qu'on pourra voir cela dans un deuxième temps. Il y a aussi un compas dans le vario :D Ya plein de choses qu'on pourra faire.


Je dis peut-être une grosse bêtise mais je pensais que les logiciels (et les formats de type IGC) attendait d'avoir l'altitude barométrique en atmosphère normalisée. Et c'est justement les infomations GPS ou un QNH qui permettait après coup de les interpréter.

Pour tes test Xiboard :

En réalité il faut éviter d'envoyer sur le bluetooth avec "Serial.print" car il envoit tout d'un coup. Et donc si le buffer est plein il est obligé d'attendre qu'il se vide un peu. Et pendant ce temps on ne s'occupe plus de l'écran ni tu baro.

Il faut vaudrait mieux envoyer octet par octet et parcourir toute la boucle entre temps.

Je vais t'envoyer un exemple de code pour faire ça.

A+

Du coup il faut prendre celui compilé avec le bootloader ? ou sans ?


Oui, je suis conscient que c'était un code dégeux ! Mais ça marche !

Oui toujours le firmware sans le bootloader !

D'ailleurs il faut faire attention car dans le cas contraire cela écraserai mon bootloader et même le bouton reset ne marchera plus.

Mais non ! il est pas dégeu le code ! Pour préciser le buffeur d'envois fait 64 bytes. Donc tant que tu envois des trames de moins de 64 caractères y'a aucun soucis. Autrement il faut juste les couper et les envoyer avec un délai entre les envois.

De toute façon on aura tout le temps de faire du code propre une fois qu'on sera décidé sur le design.

Je suis déjà super content qu'il y ait autant de bon codeurs ici !  :pouce:

J'ai pas d'idée, mais je viens de refaire un essai et ça marche impec.
(J'ai juste du mal à faire mon sprintf :
sprintf(paquetBluetooth,"LXWP0,Y,0,%f,%f,,,,,,0,0,0",kalmanvert.getPosition(),kalmanvert.getVelocity());
ça marche pas...)

Par contre sur la version android 6.8.6 j'ai pas le XCTracer comme Driver.

Et sous XCTrack ça marche bien le protocole XCTracer ($XCTRC). Le protocole LXWP0 marche aussi mais je suis toujours géné par l'envoie de l'alti au lieu de la pression.

J'en deviens fou ! J'vais faire un tableau croisé dynamique lol

Edit : je vais vraiment faire un tableau en fait !! FlyMe accepte bien aussi les trames LXWP0 !
Il faut que j'arrive à passer les float pour voir si c'est réactif.

Xiboard,

Je ne comprends pas tout de ton post.

Tu peux me passer une trame LXWPO qui est généré par ta moulinette, et qui fonctionne ?
Tu utilises bien le driver LXNAV dans XCSoar ?

Hello !

Voilà, de retour de vacances, et le colis de prunkdump m'attendais !
Alors je me suis mis au montage, et refermé l'engin ce matin.
Il me manque plus qu'à lire vos nombreuses pages !...

Déjà un grand bravo, le travail réalisé est vraiment top !
Que ce soit pour la découpe des éléments, l'emballage ou la rédaction du tuto, c'est vraiment de l'excellent boulot, chapeau bas !!

Il me reste la carte bluetooth à monter mais je voulais avoir un aperçu du fonctionnement sans cette carte. Je ne suis pas sûr de la monter car la suite de mon projet est de raccorder ce vario sur un kobo, via une liaison série classique.
Et juste après ces mots je vais aller voir quoi faire de ce qui se trouve sur la carte sd qui pour l'instant est formatée via windows en Fat.

J'ai fait un petit test en voiture ce matin et tout à l'air de fonctionner.
Juste un petit truc, au-delà de 100 km/h l'affichage de la vitesse et de l'accélération bug un peu.
Alors je vous entends de là, sous nos voiles on a de la marge !  :jump:
Mais je crois avoir lu que quelqu'un bossait sur un vario pour planeur, alors peut-être que là ce sera plus important.

 :ppte:  :ppte:
Test en vol demain, il paraitrait qu'on a une petite ouverture avant un week end pourri.
 :ppte:  :ppte:

Encore merci à prunkdump, et à tous les autres aussi !
 :forum:

Je n'avais pas encore eu le temps de tester une mise à jour de firm.
Et je 'merde' dans la compil du code. Manque de connaissance de l'environnement arduino, ca couine du coté des librairies.
Je suis sous windows ; est-ce qu'il faut nécessairement charger les librairies dans l'environnement de l'IDE arduino (c:\Users\<login>\AppData\Local\Arduino15\libraries), ou bien on peut les laisser dans un dossier local au sketch courant (ici variometer) ?
De toute manière, ca ne règlera pas mon problème, je pense :
  ArduinoRobot.cpp: In constructor 'RobotControl::RobotControl()':
  ArduinoRobot.cpp:26:42: error: 'LCD_CS' was not declared in this scope
  ...
Bon, faut que je cherche, je trouverais




D'accord avec toi. A priori, on est quasi certain qu'il faut le socle de base des trames liées aux infos GPS : GPGGA et GPRMC
Et ca serait plus sympa d'avoir qq chose qui convienne au maximum de logiciels pour les autres infos :
  . vario. Evidemment, c'est l'info essentielle dans notre cas. Il ne faut pas que l'info remontée repasse à nouveau par un filtre dans le logiciel externe
  . pression atmosphérique
  . température ; quoique j'ai des doutes sur la pertinence : ca sera celle du composant dnas le boitier, pas la température extérieure
  . voltage ; est-ce intéressant ?
  . ....
Coté XCSoar :
  . c'est certain que les trames openvario remontent les infos nécessaires, et traitent correctement les infos de vario et de pression atmosphérique
  . je n'ai pas réussi à valider les trames LXWPO ; mais c'est probablement une erreur de ma part.
    Xiboard, les tests que tu as fait avec XCSoar, c'est bien avec le driver LXNAV ?



Je n'avais pas pensé à cela, et ca serait bien sympa. C'est à vérifier coté des logiciels.

Est-ce que cette altitude normalisé est disponible dans le code ?
Xiboard, dans un post précédent, envoie l'info d'altitude barométrique dans la trame LXWPO grace à l'appel de la fonction kalmanvert.getPosition() ; c'est l'altitude barométrique en atmosphère normalisée ?
Est-ce que ce n'est pas l'altitude déduite des infos GPS ?

Oui, c'est bien un probléme de conflit de librairies.
Le plus simple :
- Virer (et conserver momentanément ailleurs) les librairies qui sont dans le dossier racine de l'ide arduino.
(par exemple: C:\Program Files (x86)\Arduino\libraries)

- copier à la place les librairies modifiées ou crées par prunkdrump, contenues dans le sous dossier "libraries" de "arduino-variometer-master" téléchargé depuis repo Git.

a noter que le sketch "variometer.ino" peut lui être rangé n'importe ou sur le disque, et que les exports des binaires compilés (fichier.hex) seront automatiquement mis au même endroit.

bon courage et merci pour le boulot sur les trames.

1. Oui c'est bien avec le driver LXNAV

2. L'alti baro est normalisé par rapport à 1013hPa sauf que le GPS est activé et après le fix : là il est recalé par rapport à l'alti GPS.

Autrement, je reviens sur ce que j'ai dit : finalement je trouve le protocole LXWP0 pas mal : En effet, on envoie l'alti baro filtré. Et surtout avec notre filtre de kalman combiné à l'accelero qui est super robuste. Résultat côté logiciel t'a déjà quelque chose de filtré bien propre.
Bon à mon avis ça sera selon les goûts et les différents essais ces histoires de protocoles. De toute façon c'est quand même super semblable juste l’entête, l'ordre et le formatage changement.

Je refait des essais mais pour moi il restait un soucis d'instabilité lorsque j'active le GPS et le bluetooth. Comme t'as dit prunk, je me demande si c'est pas un dépassement de mémoire ou soucis avec l'interrupt et la réception des data Rx du GPS ? ou encore une histoire de "timing" ??

Salut à tous,

La mesure de la batterie est dans la boite

(https://img4.hostingpics.net/pics/50219020170505071908.jpg) (https://www.hostingpics.net/viewer.php?id=50219020170505071908.jpg)

j'ai modifié la bibliothèque varioscreen et ajouté

quelques variables de configuration en plus du code d'affichage

#define HAVE_VOLTAGE                       Si vous souhaitez mesurer et afficher la capacité de la batterie

int     VOLTAGE_PIN = A2;                    Entrée de l'arduino
#define DIVIDER_VOLTAGE 1.27             valeur du pont diviseur - cette valeur peut être ajuster en fonction des résistances choisies afin d'obtenir une mesure plus juste

L'arduino est en 3.3V du coup impossible de mesurer des tensions de plus de 3.3V du coup on intercale entre la patte RAW et A2 un pont diviseur

l'explication est sur le github section issues charge batterie

URL=https://www.hostingpics.net/viewer.php?id=727650220pxPontdiviseurtensionsvg.png](https://img4.hostingpics.net/pics/727650220pxPontdiviseurtensionsvg.png)[/URL]

U2 = U X ( R2 / ( R2 + R1 ) )

R2 = 1M et R1 = 270K

le coefficient de 1.27  est égale (R1+R2)/R2

la patte coté U correspond à la patte RAW de l'arduino
la patte coté U2 correspond à la patte A2 de l'arduino

Bravo GtD73 pour le montage ! Et bin dis donc ya des rapides du fer a souder  :shock:  Je vais vous faire monter des varios à la chaine :D

Oui essayes si possible de voir les temps de fix du GPS. Ca sera dans tout les cas très variable, mais regardes si il t'arrive de rester plus de 10 minutes sans fix en extérieur. Moi ça m'est malheureusement arrivé avec le bluetooth monté. Mais sur mon vario (ancien proto) le bluetooth est placé bien plus haut et donc couvre beaucoup plus l'antenne GPS.

Il semble que le vario de Xiboard fixe bien avec le bluetooth. Et pourtant il habite pas sur une autre planète ;) .

Si tu veux raccorder le vario en série tu as de la chance car le bluetooth était raccordé en série aussi. Il suffit donc d'utiliser sa broche et de faire sortir un connecteur à l'extérieur ! Ca ne demandera pas beaucoup d'adaptation.  :pouce:

Pour les bugs de compilation :

Vérifiez quand même que vous avez choisit la bonne carte arduino (pro mini 3.3v 8Mhz).

Bizarre ce bug de compilation  :grat: . Il vient du fait que cette librairie "Robot_Control" utilise des noms de fichiers similaires au miens. Mais normalement l'IDE devrait choisir en priorité les bibliothèques "perso". Moi sous linux j'ai bien cette bibliothèque installé et l'IDE mais la prends pas en compte.

J'ai déjà compilé le code du GitHub sous windows sans problème donc le problème doit être relativement subtile :

-> Avez vous bien placé le contenu du GitHub dans "Mes Documents\arduino" ? Peut être que l'IDE regarde en priorité les bibliothèques de "Mes Documents\arduino\libraires". Mais peut être qu'il ne le fait pas si vous le placez le code dans un autre dossier.

-> Bizarre ce dossier "libraires" dans le profil sous windows... (c:\Users\<login>\AppData\Local\Arduino15\libraries) Ya quoi dedans ? Faites peut être attention qu'il n'y ait pas de vieilles libraires dedans datant d'une ancienne installation de l'IDE (sous windows c'est la version 1.8 maintenant). Supprimez le dossier complet du profil et refaites l'install. Mais ça ne m'explique pas l'utilisation de ce dossier....

-> A défaut si aucune de ces solutions ne marche. Déplacez simplement ailleurs le dossier :

C:\Program Files (x86)\Arduino\libraries\Robot_Control

Mais laissez le reste intact.


Une remarque sur l'installation du code :[/u]

Il vaudrait mieux laisser toute l'arborescence du GitHub intacte sur votre PC. C'est à dire le pas placer les bibliothèques d'un côté et les programmes de l'autre.

Car cela vous permettra à l'avenir d'utiliser Git. Vous pourrez ainsi mettre à jour votre code en téléchargeant les dernier correctifs tout en gardant vos modif "perso" sur le vario.

Je ferais un petit tuto rapide sur Git dès que j'ai un peu de temps.

Pour les soucis de stabilité du bluetooth/GPS :

C'est pas évident. Je vais essayer d'expliquer pourquoi.

Les buffeurs d'entrée et de sortie de la liaison série sont de 64 octets. Malheureusement lorsque le GPS envois ses données, l'ensemble des trames fait bien plus que 64 octets. Donc si on ne verifie pas très régulièrement le buffeur d'entrée pour le vider on peut très vite perdre des données provenant du GPS. Mais du coup si on vide au maximum on est obligé de traîter ce que l'on reçoit et pendant tout ce temps on ne s'occupe plus du reste (kalman, baro, accelero).

-> Sur ce point pas de solution miracles. Il va falloir reprogrammer la bibliothèque "Serial" d'arduino pour qu'elle fasse un tri en entrée. Et qu'elle ne mette dans le buffer que les trames qui nous sont utiles. De cette façon on pourra plus facilement rester sous les 64 octets. Je vais m'y coller dès que possible. On pourrait aussi agrandir le buffeur. Mais l'ensemble des trames fait plus de 300 octets donc ça ferait un buffer beaucoup trop gros. Il ne resterai plus assez de mémoire. L'ideal ça serait de faire une peu des deux : Filtrer en entrée pour ne garder que GGA et RMC et trouver une taille de buffer où on est sur que les deux trames rentrent. Ainsi on pourrait tranquillement analyser les trames relativement lentement.

Pour le buffeur de sortie c'est plus simple pouisque c'est nous qui envoyons. Il faut juste faire attention de ne pas le remplir.

-> On peut donc par exemple juste laisser un peut de temps entre les envois de 64 octets. Voire même envoyer octet par octet. Et entre chaque octet on s'occupe de tout le reste.

Je vais essayer d'envoyer un exemple. Xiboard malheureusement sprintf ne marche pas sous arduino avec les flotants... Tu peux peut être essayer avec la bibliothèque "digit". A voir.

Magnifique jpg63 !!  :bravo:

Je me disais bien que tu allais nous sortir un truc super bien fini !

Au moins mon code n'est pas complètement illisible  :lol: Tu as réussi à bien réutiliser les fonctions de la bibliothèque varioscreen. En plus ça rentre nickel sur l'écran !  :pouce:  Il reste de la place. Dans les prochaines versions on fera en sorte de prévoir le pont diviseur sur le circuit.

J'intègre ça dans le code dès que j'ai un peu de temps !

Quelqu'un aurait-il une bibliothèque de composant Fritzing pour le L9110 ou saurait facilement en faire une ?
J'aimerais bien mettre à jour le plan variometer.fzz

Super Jpg63, merci pour l'affichage bat !

Pour info, il existe une possibilité de mesurer la tension batterie en utilisant le ref voltage de l'ADC, donc sans avoir à utiliser de pont diviseur, et sans mobiliser une entrée analogique supplémentaire.
voire : https://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/

Ca permettrai éventuellement de ne pas avoir à retoucher le HW, non? Qu'en penses tu?

A+

C'est variable. Hier, avec mon code modifié pour tests qui communique déjà en Bluetooth sans attendre le fix du GPS. Dans la maison, il n'a jamais réussi à fix...
Je vais refaire quelques essais...

J'ai réussi à coup de "%i.%2i" et des astuces de (int)()*100 et ((int)*100), pas propre mais fonctionnels pour les essais.

Merci pour l'explication des buffer du Serial.
Ton idée de faire une biblio Serial custom me parait pas déconnant. On est tellement ric-rac niveau mémoire qu'il va nous falloir optimiser un max si on veux rajouter des "fonctions".

Concernant les trames LXWP0 et XCSoar : la nuit porte conseil ;-)

Je me suis fait piéger bêtement : j'envoyais des trames LXWPO au lieu de LXWP0 (donc, la lettre "O" au lieu du chiffre 0.

En changeant, ca va tout de suite mieux :
$LXWP0,Y,,1603,0.00,,,,,,,,*60
$LXWP0,Y,,1607,1.00,,,,,,,,*65

Je récupère bien maintenant dans XCSoar l'altitude barométrique, et le vario avec ces trames.
XCSoar réagit comme avec les trames openvario (j'envoyais une pression) : il faut saisir le QNH pour que l'affichage de l'altitude barométrique fonctionne.
Ca valide donc le fait que XCSoar considère l'info transmise comme  une altitude barométrique en atmosphère normalisée


On peut donc penser de ces tests et de ceux de Xiboard que l'envoi des trames GPGGA, GPRMC et LXWP0 devraient convenir à la majorité des applis de navigation aérienne.


Pas eu le temps de regarder le reste ... vous allez trop vite pour moi  :lol:

Pour moi aussi, mais ce n'est pas un reproche, je n'ai pas le niveau pour les aider de toute façon.

j'espère juste qu'en tout reprenant doucement (quand j'aurai reçu le module GPS) je pourrai me refaire le film  :pouce:

J'ai fait un test de batterie cet aprem:

Départ batterie vide, puis 8 heures de charges dans la journée. (bien plus que nécessaire, puisque le module de charge sort 1A, soit une charge compléte en 45 minutes environ.)
Vario laissé en champ libre GPS fixé
Module BT en place, mais switch sur off.
Bip régulièrement 1/2 du temps environ (en réglant le seuil trés bas, les courants d'air suffisaient à déclencher réguliérement)

résultat : Batterie vide après 1h10 à 1h40 de fonctionnement... (je n'ai pas checké très régulièrement).

Ce résultat était prévisible car les 600 mAh de la batterie ne sont pas énorme pour µC au taquet + IMU + GPS + écran + carte SD en écriture continue + buzzer amplifié...
Pour des vols long il faudra prévoir de brancher sur une batterie externe comme le tel, avec un cordon en Y.

Edit : je soupçonne l’écriture sur SD d'étre le plus gros contributeur de conso. J’essaierai à l'occasion de mesurer ça.

Pour le moment j'ai le code livré d'origine et toujours pas de module bluetooth.

Petit retour sur mes premiers essais:
Celui d'hier en voiture s'est bien passé: enregistrement de la trace que j'ai pu récupérer via gpsbabel et pour le moment google earth.
Le fix gps est possible sous le parebrise. Je n'ai pas réussi à avoir de fix à l'emplacement du téléphone.

Celui en vol, nettement plus intéressant non ?
Le fix du GPS s'est fait en accédant au déco (Montlamb !!!) et il aura fallu 10 mn montre en main. Mais c'était en marchant et parfois en sous-bois.
J'essaierai de faire la même mesure immobile ciel dégagé pour avoir une bonne comparaison avec le montage du bluetooth réalisé.
Sur la prévol, je n'ai pas remarqué de perte de gps
 Bip un peu envahissant sur le déco mais je n'ai pas encore fait de calibration, peut être que après cette calibration les prévol/déco seront plus paisibles.
Comme je n'ai pas encore de quoi le monter sur l'élévateur je l'ai gardé dans une poche et le son ne m'a pas semblé trop fort.
Une fois en vol c'est vraiment bien. Belle réactivité. Xctrack qui tournait sur mon tel (galaxy S5) est à la ramasse !
Après les conditions de vol n'étaient pas fameuse donc je n'ai que 15 petites mn de recul...
Le gros point négatif c'est que cette poche a du me priver du GPS car je n'ai aucune trace enregistrée de ce vol... :canape:
Un détail, tous les fichiers enregistrés (de la veille donc) le sont à la même date/heure :6/9/2016 17h14

Par contre niveau autonomie je suis étonné car pour le moment je n'ai pas rechargé du tout et ca tourne toujours (env. 45mn je dirais)

Et dernier point, ce vario a bien plus à mes pots !

Oui c'est vrai moi non plus je n'ai pas fait d'essais d'autonomie  :grat: je vais essayer de faire ça des que possible. Mais on a un expert de la batterie maintenant :D ! Jpg64 va sûrement tester son témoin de charge et nous donner des infos. Et tout cas super Ptitkiki d'avoir pris le temps d'expérimenter  :pouce:

Y'a peut être quelque chose qui pourrai améliorer la conso. Pour l'instant on envois du 3,7v sur tout les régulateur 3,3v de chaque carte. Mais chaque régulateur dissipe de l'énergie.

J'avais fait des essais en envoyant partout du 3,3v avec le régulateur de l'arduino mais j'ai eu des mauvaises expériences. Je pense qu'il n'est pas d'assez bonne qualité pour tout ce qui est alimenté.

Mais peut être qu'en rajoutant UN bon régulateur en sortie de la batterie on aurait des meilleurs résultats. Si quelqu'un s'y connaît pour investiguer ;)

Content que tu ai pu faire un test en vol GtD73 ! Mais je ne sais pas ce qui s'est passé pour la trace... Peut être aussi que la carte s'est déconnecté dans la poche.

Pour les dates des fichiers c'est une petite triche pour économiser du code. Je met toujours la même date  :oops:

 :grat:  :grat:
Je capitule pour ce soir je n'arrive pas à compiler les firm.hex...

Bizarre  :grat:

Faudrait que tu nous donne le message d'erreur.

GtD73

j'ai remarqué que l'arduino.exe en 1.8.2 m'avait ajouter un répertoire dans AppData après avoir mis à jour les cartes - proposition en bas à gauche.

C:\Users\jpg63\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.18\libraries

j'ai renommé le répertoire en old
 
J'ai aussi eu des erreurs avec la bibliothèque SPI et EEPROM, j'ai installer la version 1.0.5, j'ai sauvegardé les librairies, j'ai réinstallé la 1.8.2
ensuite j'ai supprimer toutes librairies dans C:\Program Files (x86)\Arduino\libraries et j'ai mis les librairies du github puis SPI et EEPROM de la version 1.0.5

si cela peut t'aider

-----------------------

j'ai fais une constatation bien embêtante avec l'affichage de la batterie, il est possible que ce soit mon code mais je crois plutôt que cela vient de la batterie - j'explique le soucis, à chaque fois que le beeper bip, la tension chute
Mon explication c'est que courant demander par le beeper et l'ensemble du vario est supérieur au courant de décharge de la batterie. La batterie a certainement en "C" (facteur de décharge) trop faible vu les 600 mh et la consommation de l'ensemble des modules.

Il va peut être est nécessaire de recalibrer la batterie pour les futurs versions

A tester pour confirmer le problème

Caractéristiques électriques des batteries LiPo

La tension nominale d'un élément LiPo est de 3.7 V. (C'est la tension à vide d'un élément chargé à 50%).

La capacité : elle s'exprime en Ah (Ampère x heure et non pas Ampère / heure). Une batterie de 2000 mAh soit 2 Ah a la capacité de débiter 2 A pendant 1 h ou 20 A  pendant 0,1 h (6 mn).

L'agencement d'un pack : pour obtenir une tension plus élevée, on met plusieurs batteries élémentaires en série. Un pack 3S possède 3 éléments en série (le + d'une batterie est relié au - de la suivante), sa tension nominale sera de 3 x 3.7 V soit 11.1 V (à vide).
Pour augmenter la capacité d'un élément, on peut en mettre 2 en parallèle soit 2P en abrégé (les + des deux batteries sont reliés ensemble, idem pour les -). Tenant compte de l'augmentation de capacité des éléments, ceci n'est plus très utilisé pour les applications courantes.

Le facteur de décharge : une batterie 2000 mAh de 20 C a une intensité maximale de décharge de 20 fois sa capacité soit 20 x 2 A = 40 A (et non pas Ah ).
Les fabricants ont toujours tendance à gonfler ces chiffres, aussi il vaut mieux prendre un peu de marge pour prolonger sa durée de vie... et puis n'oubliez pas, décharger une batterie à 20 C, ça fait 1/20 h soit 3 mn d'autonomie .

Résistance interne : c'est la résistance équivalente mise en série avec une batterie théorique. Rarement indiquée par les fabricants, c'est vraiment dommage. Elle influence la capacité de décharge d'une batterie.

Tension minimale de décharge : les batteries LiPo ne doivent jamais être déchargées en-dessous de 2,5 V par élément. La valeur recommandée si vous voulez faire durer vos batteries est de 3.3 V par élément et personnellement je m'arrête à 3.6V.

La charge des batteries LiPo commence à courant de charge constant (I = 1C*) et lorsque la tension atteint 4.2 V elle se termine à tension constante, le courant de charge décroissant pour arrêter la charge à I = 0,1C.
* Les batteries de 3ème génération peuvent se charger à 5C, encore faut-il le chargeur qui en est capable.

Tension de charge maximale : les batteries LiPo ne doivent jamais être chargées au-dessus de 4.2 V par élément. Attention, danger d'incendie ! C'est pourquoi il est impératif d'utiliser un "égaliseur" dans le circuit de charge. En effet, après utilisation, les tensions aux bornes de chaque éléments peuvent être différentes, et si vous charger un pack d'éléments en série un des éléments peut se trouver en surtension.

Tension de stockage recommandée : si vous voulez prolonger la durée de vie de vos chères LiPo, il vaut mieux les stocker au froid et seulement à 3.7 V par cellule. Contrairement aux NiMh l'autodécharge des batteries LiPo est faible.
Mais les batteries LiPo vieillissent à ne rien faire...

Je vous avez bien dis qu'on avait un pro de LiPo  :pouce:  ! Je vais étudier ça !

Autrement j'ai fais un essai sous windows.

-> J'ai pris un windows 7 (ou l'IDE n'avait jamais été installé)
-> J'ai installé le dernier IDE (1.8.2) https://www.arduino.cc/en/Main/Software
-> J'ai téléchargé le code du GitHub https://github.com/prunkdump/arduino-variometer/archive/master.zip
-> Je l'ai extrait dans "Mes document\Arduino". Il me demande d'écraser le dossier "librairies"
-> Je choisit "pro mini" et "3.3V, 8Mhz"

Et tout se compile bien ...  :grat:

J'arrive pas a comprendre d'où peut venir vos problèmes de compilation. Et apparamment plusiers personnes sont concernées  :shock: . Essayez :

-> de désinstaller l'IDE
-> supprimez "Mes documents\Arduino"
-> supprimez "c:\utilisateurs\login\AppData\Local\Arduino15" (si vous ne voyez pas AppData tapez "AppData" dans la barre d'adresse.
-> supprimez "c:\Program Files (x86)\Arduino"

Puis réinstallez l'IDE avec la procédure ci-dessus. Et si vous trouvez d'où vient le problème dites le moi :D Je le mettrais sur le Tuto. En tout cas le code est compatible avec la dernière bibliothèque arduino.

Ou alors vous avez pris la version "beta" ? Le "hourly build" ?  :grat:

Salut

Pour le chargeur de la batterie, si vous ne l'avez pas vu, en regardant par l'ouverture de la prise USB on peut voir une led qui reste rouge si la batterie n'est pas pleine et passe bleu quant elle est complètement chargée

Pour comprendre pourquoi la batterie s'effondre il faudrait mesurer le courant qui lui est demandée et en fonction calibrer la batterie et l'autonomie

Exemple avec le beeper à font si on tire 600mA et que l'on veut 4h d'autonomie il faudra choisir une batterie de 0.6X4 = 2400mAh avec par sécurité un C de 20 à 35. Plus de chute de tension et une autonomie calculer théoriquement

La chute de tension n'est pas si grave en soit car à 3.6V la lipo est pas loin d'être morte et l'ensemble des éléments s’alimentent en 3.3V, juste l'affichage de la batterie qui passe de 100% à 50% dès que ça bip. Cela renforce l'idée d'avoir un régulateur 3.3v externe pour alimenter sans fluctuation les composants.

Il sera peut être utile de revoir la taille du boitier à la légère hausse pour pouvoir loger une plus grosse batterie et éloigner le bluetooth, l'écran et le GPS, pas trop non plus on est juste légèrement plus petit qu'un syride. L'idée est de rester petit pour s’accrocher au élévateur, c'est le top pour un petit vario, pas de cockpit, poids mini, le vario juste au niveau des yeux et des oreilles idéale avec un petit écran. Coté écran 1" de plus et du E-Paper  :dent:

(https://img4.hostingpics.net/pics/59986920170506102912.jpg) (https://www.hostingpics.net/viewer.php?id=59986920170506102912.jpg)

(https://img4.hostingpics.net/pics/16970920170506102924.jpg) (https://www.hostingpics.net/viewer.php?id=16970920170506102924.jpg)

(https://img4.hostingpics.net/pics/76462020170506102851.jpg) (https://www.hostingpics.net/viewer.php?id=76462020170506102851.jpg)
       

Quelqu'un peut expliquer pourquoi un syride, un skytraxx, un Reversale, ...
ont une autonomie nettement supérieure avec tout autant de fonctions.
ils n'ont pas un volume nettement plus gros et n'emporte donc pas des batteries énormes????

C'est la technologie employée qui est plus gourmande ??

Allez un petit quiz pour s'amuser  :D :

->le OKW Minitec D drop : https://www.okw.fr/fr/Boitiers-en-plastique/Minitec.htm
->le OKW Soft-Case : https://www.okw.fr/fr/Boitiers-en-plastique/Soft-Case.htm
->le Hammond 1553A :  http://www.hammondmfg.com/pdf/1553A.pdf (http://www.hammondmfg.com/pdf/1553A.pdf)

Retrouvez à qui appartiennent ces boîtiers !

Autrement Van Hurlu pour l'autonomie c'est juste qu'on y a pas encore beaucoup réfléchit....  :oops: Avec quelques petites modifs sur le circuit on peut parfois améliorer grandement la durée de la batterie.

J'ai bien envie de tester l'ajout d'un bon régulateur en entrée. Mais j'ai pas ça à la maison.

Autrement je suspecte aussi le petit circuit de protection posé sur la batterie d'être conçu "très large". Essayez si vous voulez. Il est impossible de faire un court circuit avec la batterie. Ya un composant qui doit couper à partir d'une certaine intensité. Peut-être qu'ils l'ont réglé pour couper un peu vite ... En tout cas moi la batterie ne chauffe pas du tout dans le vario. C'est qu'on doit pas lui tirer beaucoup dessus.

Edit :

J'ai peut-être trouvé une position pour le bluetooth ! : Posé sur le baro et l'arduino sous la nappe de l'écran, contre les connecteurs dupont. Il faut du coup descendre à peine un peu plus la batterie et raccorder le bluetooth avec une nappe. Mais ça à l'air de passer ! Si les bricoleurs se sentent de tester.

Pour l'écran on pourrait simplement le mettre de l'autre côté. Mais l'entrée de la carte SD serait alors face au vent. Il faudrait trouver une manière de la protéger. Avant qu'on arrive à accéder à la carte SD par l'USB :D

je pense que oui
la prouesse de faire rentrer toutes les cartes dans un si petit volume est énorme,  un énorme boulot d'optimisation et d'astuce que l'on doit à Prunkdump, et qui permet à tout le monde de le fabriquer. Je pense que la différence avec les vario pro réside dans l’intégration des composant, un minimum, pas de composant additionnel inutile est consommateur,  un circuit et du cms, du coup pas de surprise ça consomme moins. Plus de place, batterie un peu plus grosse

génial les liens vers les boîtiers

un syride one lol

Ya pas que le Syride One ! :D

Regardez bien ! Ya deux varios commenciaux rien que dans cette page :

https://www.okw.fr/fr/Boitiers-en-plastique/Minitec.htm

Et le Hammond c'est facile ... ;)

http://www.hammondmfg.com/pdf/1553A.pdf

 ROTFL

je voulais laisser une chance au autre  :P

je vais pouvoir customiser mon syride Nav en jaune  :grrr:  :averse:

Pour gagner de la place il y aurait aussi l'utilisation d'une antenne plus petite
le Ublox NEO-6M GPS existe aussi avec une antenne plus étroite

je n'arrive pas à vous faire un lien ??? mais si vous cherchez Ublox NEO-6M GPS sur ebay, vous trouverez le modèle avec mini antenna

Je ne les ai pas démontés, mais je pense que syride et autre ont  des batteries au moins du triple de la.capacité.... 600, c'est pas énorme. Ils ont bcp plus de place de libre car tout est intégré sur une seule carte en cms...
Aussi plus d' optimisations logiciel et hw, comme évoqué sur les alims.

Jpg63: ton background  sent la culture modélisme, non?  :trinq:

Prunkdrump: comment installe t'on le bootloader sur une carte "neuve" stp? Sur une carte avec bootloader, est-il encore possible de flasher depuis l'IDE via un adapteur série? Le code actuel est-il compatible pour ça?

Je pense aussi que le buzzer suce pas mal, à creuser....

Salut !

Pour installer le bootloader il faut un autre arduino (5V ou 3.3V).

1) Tu met un sketch spécial sur l'arduino qui va servir à programmer :

-> Dans l'IDE tu choisis le modèle de la carte de l'arduino "programmeur"
-> Dans "Exemples" tu ouvre "Arduino ISP"
-> Tu compiles et tu charge sur l'arduino.

2) Tu prends maintenant l'arduino que tu veux programmer et tu connectes ainsi :

Aduino qui programme -> Arduino programmé :
pin 13 -> pin 13
pin 12 -> pin 12
pin 11 -> pin 11
pin 10 -> pin Reset
pin 5V (ou 3.3V sinon) -> pin RAW
pin GND -> pin GND


Quand  tu programmes un pro mini tout est du même côté. J'ai donc utilisé une pin header plantée dans une breadboard pour faire les contact sans souder. Autrement il y a une broche exprêt sur les cartes.

!!! Parfois il faut connecter un condensateur de 10uF entre la pin Reset et la masse de l'arduino "programmeur". N'en met pas au départ. Met le si tu as des erreurs bizarres qui ne sont pas des timeout. Si tu n'as pas de condensateur tu peux souder deux fils sur un condensateur SMD recupéré sur une plaque de charge LiPo ou autre !!!


3) Tu fais un essais avec le bootloader Arduino d'origine.

-> Dans l'IDE tu choisis le modèle de la carte que tu programme
-> Tu connectes l'arduino programmeur
-> Dans "programmeur" tu met arduino "Arduino ISP"
-> Dans "outil" tu lances "graver la séquence d'initialisation"

4) Si ça marche tu n'as plus qu'à remplacer le bootloader arduino par le mien.

-> Dans "préférences" de l'IDE tu met que tu veux un affichage détaillé pour "l'upload".
-> Tu lances encore la programmation du bootloader d'Arduino.
-> Tu récupères les deux commandes (en blanc) qui ont été lancées.
-> Tu relances les deux commandes en enlevant les -v -v -v et dans la deuxième tu change le chemin du bootloader par celui de "optiboot-sdcard". (Tu peux te faire un .bat)

Je te met en pièce jointe le bootloader pour l'arduino pro mini. Dis moi si tu le veux pour une autre carte.

Remarque : Ce bootloader fonctionne aussi sur la liaison série habituelle si besoin. Mais il faut quand même qu'une carte SD soit connecté.

A+   

du m'a démasqué ptitkiki, je fais un peu de d'aero-modélisme, j'ai plus beaucoup de temps pour faire voler mes moto-planeurs mais quant il pleut et que ça ne vole pas, il m'arrive de construire (balsa) ou de concevoir quelques petit truc

(https://img4.hostingpics.net/pics/122764maglifuselage3dv102.jpg) (https://www.hostingpics.net/viewer.php?id=122764maglifuselage3dv102.jpg)

(https://img4.hostingpics.net/pics/20329020170314073951.jpg) (https://www.hostingpics.net/viewer.php?id=20329020170314073951.jpg)

(https://img4.hostingpics.net/pics/62515420170314074417.jpg) (https://www.hostingpics.net/viewer.php?id=62515420170314074417.jpg)

(https://img4.hostingpics.net/pics/44631820170309075127.jpg) (https://www.hostingpics.net/viewer.php?id=44631820170309075127.jpg)

hello,

Merci bcp prunkdrump pour les conseils sur le bootloader, je vais tester ça.
J'ai l'impression d'avoir cassé le bootloader de mon vario, car je n'arrive plus à mettre a jour le firm via la carte SD, même avec le bouton reset.
Ca s'est produit lorsque j'ai essayé de mettre la version sans reset avec le bouton. Les autres: vous avez réussi sans encombre?

Mais avec tes explications, je devrais pouvoir réparer ça se soir.  :pouce:

Pour la position du BT, j'étais arrivé presque à la même conclusion, mais je pensais le déporter au dessus de la batterie avec  une nappe et non en dessous. j'ai testé ça devrait passer, je ferais une photo.

@jpg63 pour le modelisme, je m'en doutais bien  ;)  J'ai pas mal conçu/construit/volé aussi dans le passé.  ;)

je suis passé sans encombre à la version sans reset, j'avais juste avant mis en place l'astuce du plug USB, qui marche aussi très bien

Salut ptikiki !

Tu aurais pas pris par erreur le fichier généré par l'IDE avec bootloader ? il faut toujours prendre les .hex sans meme pour le code sans le bouton reset. Ce n'est pas le bootloader qui change. C'est juste le code qui sait lancer le bootloader.

Pour reprogrammer tu peux utiliser la broche de l'écran.

1) Tu prends un câble de breadboard que tu coupes en deux.
2) t'en soude un sur la pin reset (libre) et l'autre sur la pin 12.
3) tu peux alors Connecter l'arduino programmeur comme suit :
Pin 13 -> entrée 5 de l'écran
Pin 12 -> pin 12 arduino
Pin 11 -> entrée 4 de l'écran
Pin 10 -> pin reset de l'arduino
Pin 3v -> entrée 6 de l'écran
Pin Gnd -> entrée 8 de l'écran

Ensuite tu verifie au testeur de continuité que ça correspond bien au raccordement de mon message précédent.

Ça serait super que tu nous trouve une solution pour le Bluetooth !!  :pouce:

Edit : utilise le connecteur de l'écran ! Pas la broche... tu plante tes câbles de breadboard dedans.

@ptikiki,

Je viens à l'instant de compiler et charger le dernier firm du vario ; j'étais resté jusqu'alors à la version initiale, pré-chargée par prunkdump.

Et je viens de vérifier la nouvelle procédure de mise à jour de firm proposée par prunkdump, bien plus sympa car ne nécessitant pas l'accès au bouton de reset.

Pour moi, ca marche.
J'ai fait 3 tentatives, en modifiant le code (niveau sonore de 2 à 10) à chaque fois pour controler le chargement.

Ca a marché à chaque fois. Donc, à priori, pas de pb de bootloader.


Sinon, pour les problèmes de compilation rencontrés auparavant :
c'était bien lié à des conflits de librairies.

L'IDE arduino, en tout cas sous Windows, n'est pas très souple ; je ne vois pas comment ne lier certaines librairies qu'a un projet.

Dans ce que je comprends :
- il y a le dossier initial d'install de l'IDE. Pour moi, D:\Soft\Arduino-1.8.2
  J'ai fait une install à partir d'un fichier zip, en dézippant le tout dans ce dossier.

- puis, le dossier C:\Users\<login>\AppData\Local\Arduino15\ qui est créé automatiquement au premier lancement de l'IDE.
il y a dedans, d'abord, le fichier preferences.txt qui contient les préférences utilisateur
puyis, au fur et à mesure que l'on fait des mises à jour de librairies ou autres depuis l'IDE, celles-ci se font dans ce dossier C:\Users\<login>\AppData\Local\Arduino15\ ; ca peut devenir volumineux.

- enfin, le dossier "Documents\Arduino", qui contient les librairies utilisateur. Ca reste global aux différents projets en cours.

 :bravo:  :bravo:  :bravo:

Ca y est !!
J'ai la dernière version du vario, j'ai fait la calibration, plus besoin d'appuyer sur le bouton reset, nickel !!
A priori c'était bien un pb de librairies ou un truc du genre parce que tout est rentré dans l'ordre après l'installation d'un IDE toute propre.
J'ai eu une trace d'enregistrée en allant faire pisser le chien donc pendant le vol soi j'ai perdu la visu des GPS soi la carte s'est désenfichée.


y'a plus qu'à bouffer du code (et de la lime pour le bluetooth)


ET VOLER !

bon, pas réussi à résoudre pour de bon mon pbm de boot-loader, la nuit devrait porter conseil.
J'ai même cru à un moment avoir brické completement mon vario...
Mais finalement j'arrive quand même à mettre à jour le firmware en téléversant "classiquement" depuis l'IDE, (donc sans passer par la carte SD), c'est déja ça. J'ai fait sortir provisoirement un petit connecteur pour le FTDI.

Baptiste: une petite question sur la sélection du programmateur dans l'étape 4 de ton mini tuto,  il faut prendre "arduinoISP" (sans espace) ou "arduino as ISP"?
Avec le premier, j'ai un message d'erreur : "avrdude: Error: Could not find USBtiny device (0x2341/0x49)"
(note: J'ai bien mis le condo 10µF)
Avec le second, j'ai un message plus long, et je brick carrément la carte programmateur, (impossible de re-televerser dessus classiquement)... à priori j'ai fumé 2 arduinos  :tomate:

si non, j'ai fait les essais de déplacement de la carte BT
Finalement ça ne passe pas du tout dans aucune des 2 solutions évoquées.

J'envisage 2 autres pistes :

- Décaisser un petit rectangle dans le fond du boitier de la taille de la carte, l'insérer et refermer avec le velcro sur toute la surface.
Pas super élégant mais ça devrait faire le job.
Dans cette position :
(https://img4.hostingpics.net/pics/254230IMG20170507001934.jpg)

- Remplacer le lecteur de carte SD par un mini SD, avec un petit connecteur en fils fin (ça devrait être neutre d'un point de vue du code), et ainsi gagner la place de mettre à coté le module BT.
(https://img4.hostingpics.net/pics/589943IMG20170507001845.jpg)

Je pense partir sur la première solution pour l'instant.

Moi j'ai monté la carte bluetooth à l'emplacement prévu et j'ai réussi à avoir la vitesse au bout de 3mn30 ! C'est pas si mauvais !
Je verrais demain si le fix gps est stable

Quand on voie la différence de taille entre un lecteur  de carte SD vs un miniSD, il est évident que si on veut gagner de la place c'est une voie intéressante. le module BT pourrait utiliser cette place économisée.
je vais me commander un lecteur de mini-carte pour voir.
mon inquiétude est que la mini-carte SD risque d'être plus difficile à insérer et sortir du boitier.

Pas de panique Ptikiki !

C'est juste moi qui ait mal expliqué :oops: Et c'est impossible que tu ait brické une carte Arduino sans vrai programmateur. En plus j'avais oublié que Arduino avait créé eux même un programmateur : d'où le "ArduinoISP".

Alors voici les précisions que j'ai oubliés :

-> Si tu n'arrives plus à uploader sur ton Arduino "programmateur" c'est à cause du condensateur et du fait qu'il soit connecté à l'autre Arduino. En fait le condensateur sert à empêcher le Reset de l'arduino. Donc déconnectes juste ton arduino de la breadboard et tu pourras à nouveau télécharger des sketchs dessus par le port série.

-> Ensuite rebranche le sans condensateur dans un premier temps. Et effectivement il faut mettre dans l'IDE "Arduino as ISP" et choisir le modèle de la carte que tu programmes (pas le modèle de la carte "programmeur").

-> Vérifie les connexions entre les deux arduinos pin à pin (pour vérifier que je ne t'ai pas dis de bêtises avec le connecteur d'écran). Puis fais un essai : "burn bootloader".

-> Si ça ne fonctionne pas ajoute le condensateur.

-> Une fois que c'est bon. Récupère les deux commandes et change le firmware du bootloader.

Pour le repositionnmeent du bluetooth :

T'es sur que ça ne passe pas ? Moi je viens de faire un essai rapide et c'est vraiment pas loin avec le bluetooth posé contre les cartes. As-tu tordu les broches de l'écran ? Parceque je pense que ça pourrait passer (mes excuses pour les tirets à répétitions) :
-> En tordant les broches dans l'autre sens vers l'antenne.
-> En refaisant un connecteur d'écran plus court qui se connecte directement côté antenne. (Je sais pas si je suis très clair, pour l'instant les "pipes" du connecteur sont tournées vers le bas du vario. On pourrait les tourner vers le haut, vers l'antenne)
-> En dessoudant le bouton reset (il fait pas mal de hauteur inutile)
-> Peut-être en tournant à 90° la batterie dans l'autre sens partie jaune vers le bluetooth.


Super que tout le monde ait réussi à faire marcher l'IDE !  :pouce:


Non mais là il faut juste le sortir plus souvent ou arrêter de tirer sur la laisse...

 :sors:

J'ai un petit soucis de temps en temps que je n'arrive pas à comprendre :
Le vario ne initialise pas :

m/s et m s'affichent mais c'est tout. Pas de bip, ni rien. Je suis dans cette conf :

J'ai pourtant réussi à faire firmwareUpdate() en le retournant donc j'imagine que c'est pas un pb de Fastwire. Est ce que ça bloque à ce niveau :
??

ça me la fait que 2 fois pour le moment, et j'ai réussi à faire un FirmUpdate et après ça ne fait plus... Étrange. A noter : jamais aucune interruption du vario après.

Ca m'est arrivé aussi. Deux hypothèses :

-> Soit on initialise trop vite l'accéléromètre à l'allumage sans lui laisser le temps de "démarrer". Ca expliquerait pourquoi le problème n'apparait pas quand la SD Card est activée car elle s'initialise avant et laisse donc un petit délais à l'accéléromètre.

-> Soit la batterie est à un niveau suffisant pour alimenter l'arduino mais pas pour alimenter l'accéléromètre. Du coup parfois l'un démarre et pas l'autre.

On va peut être devoir ajouter à la bibliothèque de l'accéléromètre une vérification du temps minimal depuis l'allumage. Vérifie aussi qu'il n'y à pas un court circuit avec les deux connecteurs de gauche de l'écran (VCC et GND). Je n'aurais pas du les mettre si proche. Il faut vraiment faire attention de bien les isoler.

Pour le GPS/Bluetooth :

Ca y est je me suit lancé dans le code. Voici le principe :

Il n'y aura plus qu'un buffer pour la réception et l'émission de 128 octets. Lorsque le GPS envoie des données elles sont écrites dans ce buffer et l'entête NMEA et la parité sont vérifié. Si la trâme n'est pas GGA ou RMC ou si la parité n'est pas bonne la trame est enlevée du buffer. Ainsi lors de l'envois du GPS tout devrait rentrer dans le buffer sans avoir besoin de lire les données pour le libérer.

Une fois les données reçues ont peut les analyser dans le buffer tranquillement. Il contient simplement les deux trâmes GGA et RMC. Pendant ce temps le buffer est aussi utiliser pour envoyer les deux trâmes sur le bluetooth.

Ensuite on jette l'ensemble et on écrit les données supplémentaires à envoyer dans le même buffer. Il sera assez grand pour recevoir les trâmes LXNAV ou openvario que l'on envoie. Il pourra alors faire l'envoie efficacement.

A+

niveau batterie, le reversale est en 2000mAh, aidé d'un microcontroleur qui s'endort de temps en temps .... ;)

En passant sur un circuit unique et pas des briques ensemble, je pense qu'il est possible de gagner un peu d'autonomie (pas de passage de 5V a 3.3 dans chaque brique)
Il avance petit a petit, Si des personnes veulent vérifier d’ailleurs mon schema, je suis pas a l'abris d'une boulette. (mon objectif est de passer le vario en CMS sur un seul circuit imprimé)

Il est chargé à fond et pas de cc, j'ai tout isolé très proprement avec de la gaine thermo à la taille idéale (merci le taf...)

Le délais, m'étonnerai pas. Là ça me le fait presque à tout les coups.
Je viens de rajouter un delay(500) et une petite musique d’allumage. Là je ne semble plus avoir le soucis. A voir si ça le refait.

Super pour la partie optim du buffer !!!  karma+

@gargle : il me semble que l'on a pas de 5V. On passe du 3,7 au 3,3 dans chaque brique effectivement, pas de quoi trop perdre tout de même. Effectivement pour le futur si vous faites une version tt intégré, ça devrai être mieux avec -comme dit prunkdump- un seul bon régul.

Moi avant de souder la batterie, je l'ai cyclé une fois sur un chargeur modélisme. Il me semble avoir tenu facilement 2h avec fix GPS en auto.
Et pour avoir testé pas mal de batteries, les infos des batteries pas cher sont souvent un peu fausses. Normal, il y a une tolérance, mais rarement à notre avantage ! (C'est flagrant sur les accu 18650)

PS : ancien modéliste aussi =) (encore un peu mais vachement moins !).

Que l'alti affichée sur l'écran du vario soit rectifiée après le fix GPS ; c'est bien. de toute manière, on ne peut pas le rectifier autrement.

Mais je crois que si on transmet en NNMEA une altitude barométrique à une app externe, il faut transmettre l'alti normalisée.
Si on transmet l'altitude qui a été recalée par rapport au premier fix GPS, on envoie alors une alti calculée GPS ; c'est très différent, et ca ne présente plus d'intéret.


J'en profite pour signaler un petit "bug" je pense, dans la manière de traiter le premier fix GPS :
J'ai des problèmes de fix GPS avec mon vario ; je vous en ferais part dans un prochain post.

Tout à l'heure, j'ai démarré mon vario à l'extérieur, dans un espace libre, immobile.
Affichage de l'altitude largement inférieure à l'altitude réelle ( différence de 50 m ?) ; donc, je pense que c'était l'altitude baro normalisée
Il a mis un certain temps (5 mn ?) pour arriver à faire le fix GPS ; ou plutot, à afficher en bas O km/h et O Gr.

Mais visiblement, la qualité du signal GPS était très mauvaise :
  . il continuait à afficher une vitesse de 0 km/h alors que je marchais assez rapidement ; ceci pendant au moins une minute.
  . pendant tout ce temps, il n'a pas recalculé l'altitude comme il le fait normalement, lorsqu'il a les infos GPS.

Le problème : au bout d'environ une minute, les infos GPS ont bien été prises en compte ; en tout cas, la vitesse s'est bien affichée.
Mais l'altitude recalculée, probablement à partir d'infos GPS par encore stable, était très largement surévaluée ; plus de 50m dans l'autre sens (en positif)
Ensuite, je me suis baladé à pied, sur un terrain avec du dénivellé ; l'altitude affichée a bien suivi ce dénivellé (varie positivement quand ca monte, négativement quand ca descend), mais le décalage erroné positif de plus de 50m a persisté.


Je ne sais pas comment on peut traiter ce problème correctement.
Il faudrait :
  . soit pouvoir forcer à nouveau le recalcul d'altitude à partir des infos GPS
  . soit pouvoir saisir un QHN ; peut-être dans une future version du vario ?

Je vous fais part de mes petits soucis avec le vario.

pour le moment, le module bluetooth n'est pas encore installé.

1er problème :
--------------
Le fix GPS est très difficile ; environ 5 mn sur une terrain dégagé, en restant immobile.
Je vais essayer de sortir l'antenne GPS du boitier pour voir si ca améliore la réception.

2eme problème
-------------
Un blocage du vario, lorsque je démarre avec une sdcard insérée (à priori, pas de blocage si pas de sdcard dans le lecteur) :
environ 1 ou 2 mn après le "fix GPS", le vario se bloque ; je suppose que c'est au moment de l'écriture de la trace sur la sdcard ?

Coté sdcard, je retrouve des fichiers GPS000.TXT, GPS001.TXT, ... tous à 0 octets

J'ai lansé un fsck linux sur la sdcard ; ca donne ceci :
fsck de util-linux 2.27.1

fsck.fat 3.0.28 (2015-05-16
)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 
Automatically removing dirty bit.

/GPS000.TXT
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.

/GPS001.TXT
  File size is 0 bytes, cluster chain length is > 0 bytes.  Truncating file to 0 bytes.
...

C'est une sdcard de 16 Go, que j'ai repartitionnée sous linux avec gparted :
1 seule partition principale de 2 Go, formatée en FAT16

Je l'utilise pour la mise à jour de firm ; elle est donc bien  reconnue par le vario

Une idée ?

Hello,

Pas d'idée pour ton probléme, mais je me demande si mon "pbm" de bootloader n'était en fait un pbm de sd card également...

En tout cas, j'ai réussi à recharger le bootloader, un grand merci à prunkdump pour l'aide précieuse.
Et il à fallut que je reformate la SD pour que ça marche, c'était peut-être la root-cause, même si comme toi vmath54, les fichiers se créaient bien...

Bcp de temps perdu, mais je vais pouvoir maintenant repasser à des choses plus utiles, ce sont les joies du bidouillage  :pouce:

@vmath54
Entièrement d'accord :
Trames RMC et GGA : alti GPS - donnes gps
Trames lxnav ou autre : pression baro non corrigée ou alti non corrigée.
Bon d'après mes essais avec XCtrack c'est pas grave. Il fait le recalage avec l'alti gps en permanence et utilise la donnée baro pour les variations. (Enfin c'est paramétrable)

Par rapport au fix et la correction juste après, on en a parlé il y a qq pages. On sait que c'est à revoir.
Correction continue (98% alti baro + 2% alti GPS) ou dès que la précision est correcte...

Entrer un QNH : ça doit être faisable via XCSoar. Mais bon.... Bien pour toi en planeur peut être ;)

Désolé Gargle je n'arrive pas pour l'instant à trouver le temps de bien analyser ton schéma. Je veux pas dire de bêtises. J'ai juste vu que tu étais resté sur un schéma à 5V. A mon avis il faudrait mieux repasser à 3.3V qui est plus standard pour tous les composants.

Justement pour les régulateurs :

J'ai trouvé que pololu faisait des régulateurs "haute performances" :

https://www.pololu.com/product/2122

C'est bien trop cher pour nous mais ça pourrait être interessant d'en avoir un équivalent pour tester. Gargle tu pourrais utiliser le schéma sur leur site. En enlevant quand même quelques condensateur (la c'est un peu à la limite du ridicule).

@vmath54 je pense aussi à un problème de formatage (A moins que tu ais activé le bluetooth dans le code qui pour l'instant bugge avec la carte SD ?). Est tu sûr que ta partitition ne fait pas plus de 2Go ? Attention même quelques octet en plus la rende incompatible. Puisque tu est sous linux reteste avec une partition de 1G avec la procédure suivante :


Pour l'envois des infomations sur bluetooth/carte SD :

Effectivement je pense que vous avez trouvé la meilleure solution  :pouce:

-> On envois sur le bluetooth les trames GPS non modifiées. En les ayant interprété au passage : affichage de la vitesse, recalage de l'altitude barométrique (à améliorer :D), date heure, nombre de sattellites.

-> On envois aussi des trâmes LXNav avec l'altitude normalisée, le vario (et plus si on arrive à implémenter)

-> On envois au démarrage une entête IGC sur la carte SD. Puis des trâmes "B" au fur et à mesure du vol.

Est-ce que quelqu'un à testé si on pouvait enlever des fichiers IGC tout le bordel à la fin ?  :grat: Est-ce encore accepté par les logiciels ?


Edit :

Super ptitkiki que tu ais réussi. Et ce n'est pas du temps perdu ! Ca t'as appris comment programmer des bootloader et ce n'est pas rien. Moi il m'a fallut une semaine pour bien maîtriser tout ça et pouvoir vous envoyer les cartes pré-chargé. Je suis sûr que  tu t'en servira un jour.

A+

 :+1: pour tout !
Les igc j'avais déjà test, ça peux s'arrêter comme ça. Par contre faudra tester la dernière trame B incomplète si ça merde. Mais assez facile à corriger.

J'avais bien formaté FAT 16, avec une seule partition primaire de taille inférieure à 2 Go.
Et avec le dernier code du dépot git sans modification (sauf le niveau sonore) ; donc le code bluetooth est bien désactivé.

J'ai reconfirmé en suivant à la lettre ta proposition.
Même problème : ca bloque dans la minute qui suit le fix GPS. A chaque fois, il crée le fichier GPS000.TXT avec 0 octets.

Confirmé plusieurs fois ; confirmé aussi que ca ne bloque pas si je retire la sdcard.

Bon, faut que je me sauve, je continuerais plus tard ...

Je rentre d'une après de vol, petit retour et gros bug

j'ai fixer le vario sur le faisceau d'élévateur gauche et mon syride nav à droite.
1ere constatation la vario est très réactif, il  est presque aussi sensible que mon syride, il n'a pas de retard, le volume est niquel et l'affichage est très lisible

Malheureusement, j'ai eu un fonctionnement très bizarre, je m'explique :

1er problème : après 5 à 10min de vol, l'écran du vario est passé en inverse vidéo, il s'est éteint, plus d'affichage, le son fonctionné toujours.
2eme problème : En vol, j'ai éteint et rallumé le vario, l'affichage est revenu. Vario et de l'altitude se sont affiché pendant quelques minutes, je pense le temps du fix du gps et la tout à planté, plus de son ni d'affichage
3eme problème : après ce second bug, j'ai essayé de rallumé le vario 2 ou 3  fois sans succès.  de retour à la maison tout remarche mais aucun enregistrement sur la SD


je pense qu'il y a un bug au fix du GPS ou à la perte du fix, j'ai volé avec une couche de nuage totale et un plaf de 300 à 400 m au dessus, les GPS n'aiment jamais bien ça.
couverture nuageuse 8/8, aérologie dynamique, thermique malgré la couverture nuageuse et vent fort, le vario bipper pas mal

Décidément vous excellez en bug bizarre ...  :shock:  Bin au moins le vario est bien testé ! Mais il va falloir débugger  :grat:

Pour vmath54, si tu as formaté comme moi le problème vient forcément du driver de carte SD que j'ai programmé (sur le vario)  :? Il ne serait pas compatible avec toutes les cartes. Malheureusement cela vas être très difficile pour moi à debugger sans avoir la carte en main.

Il faudrait déjà que tu essayes avec une autre carte (plus ancienne si possible) pour être sur que le problème viens de la bibliothèque.  Dès que j'ai un peu de temps de t'enverrai un petit programme tester la lecture de la carte SD. As tu par hasard une breadboard, un arduino et un lecteur de carte SD ?

Pour jpg63. Quel dommage qu'il y ai eu un problème en vol ! On aurait pu avoir une première vrai trace :D Alors ici je suis presque sur que cela viens d'un faux contact. Et comme l'écran et la carte SD partagent les même connexions : un faux contact sur l'un peu avoir une influence sur l'autre.

Je dis ça parceque la bibliothèque de l'écran n'envois jamais la commande de retournement d'écran. As-tu vérifié l'isolation de tes connecteurs d'écran ?


Je veux bien la référence de la gaine thermo idéale Xiboard  :D

Arff ! pas facile à trouver une vielle sdcard. J'avais cherché dans les magasins une sdcard <= 2Go, je n'ai pas trouvé.
Celle que j'utilise est une samsung 32 EVO+ achetée récemment ; c'est du luxe pour l'usage en cours.
Donc, une micro usb avec la carte adaptateur SD.
Je l'ai utilisée par ailleurs, en FAT 16 : délog de flarm, nouveau firm pour ce vario, ... ca fonctionnait.

Pour le breadboard et l'arduino : oui j'ai cela.
Pour le lecteur sdcard : j'ai un module lecteur de micro sdcard ; celui-la :
http://www.ebay.fr/itm/2PCS-TF-Micro-SD-Card-Module-Mini-SD-Card-Module-Memory-Module-Arduino-ARM-AVR-/311445858353

Je suis pret à faire des tests si ca peut faire avancer le chmilblick
J'ai qqs compétences en informatique, ca pourrait aider.

pour les problèmes de fix gps : pas encore eu le temps de creuser. Mais je dispose d'un autre module GPS, que je pense identique à celui du vario ; je vais pouvoir intervertir l'antenne, pour voir si ca améliore.

j'ai mis de la gaine thermo sur chaque pin de l'écran, mais je vais tout vérifier et certainement souder l'ensemble de la connectique de l'écran. Je referais des tests, j'ai quant même l'impression que le problème est arrivé lors du fix du  GPS alors que le vario bipper était en pleine charge

je referais d'autres vols et d'autres tests

Je ne pense pas que ce type de régulateur corresponde bien à ce que l'on recherche...
C'est un step-up/ step down, c'est à dire qu'il porte la tension à 3,3v, en alimentant au dessus OU au dessous.
Pour nous, il ne faut qu'un step down, puisque via l'USB (5v) ou via la batterie (entre 4,2 et 3,6v), il ne faut que réduite la tension. Le circuit sera plus simple que sur ce modéle.
En restant chez Pololu, ça serait plutôt :
https://www.pololu.com/product/2842

Mais n'importe quel régulateur 3,3v faible bruit faible dropout devrait faire l'affaire, par exemple celui ci, avec le montage proposé dans la datasheet :
http://www.linear.com/product/LT1763 (http://www.linear.com/product/LT1763)


étrange, moi j'ai une 4go (taille réélle du volume 3,7Go), formatée en FAT sous win7, et no pbm, pour la mise à jour de firm ni pour l'écriture de la trace GPS...


C'est clair, je voulais dire temps perdu par rapport au vario, mais clairement pas du temps perdu pour moi, même si j'ai bien galéré ;-) Ça fait longtemps que je me demandais comment flasher un bootloader, ça ouvre la porte des cartes custom, c'est énorme, un grand merci à toi pour tes explications didactiques  :pouce:

@Gargle : je suis preneur de checker ton schéma en cours, tu dessines sous quoi?

Je l'ai fait !
J'ai repositionné le bluetooth comme le proposait Prunkdump.  Cela a impliqué une petite adaptation de la Connectique écran. J'ai pris une nappe IDE que j'ai découpé pour nos besoins. Je l'ai soudé côté écran et j'ai conservé une moitié de dupont côté carte. J'avais le fer chaud alors j'ai demonte le bouton reset. Le bluetooth est emmayote dans de la gaine thermo et soude lui aussi à la place des broches prévues.
Résultat je fixe le gps en 2 mn 30 et la trame rmc est marquée bonne ! Ce qui n'était pas le cas avec le module a sa position initiale malgre l'apparition de la vitesse.Et du coup je recupère l'info sur xctrack du tel.
J'ai ré coupe le bluetooth car j'avais un petit bugg: la vitesse reste à 0 alors que la trace gps est correctement enregistrée.
Il s'est aussi arrêté une fois: tout figé.
NouveAux test demain...

Ah ! Je me disais bien qu'il y en avait qui nous préparait des trucs en cachette  :mrgreen: !

Super boulot et super dextérité au fer à souder !   :bravo:  Je suis pas sur qu'on soit tous capable de faire ça aussi bien ...

De coup j'ai plein de questions. Ca rentre facilement du coup où c'est très juste ? Quand tu dis une "moitié" de dupont ça veux dire quoi ? Penses tu que ça peux passer en gardant le connecteur côté écran ? Parceque d'expérience souder des fils directement dessus est très fragile. Avec l'étain ils deviennent cassants. Et il faudrais pouvoir ouvrir le boîtier avec l'écran fixé sur le plastique supérieur.

On pourrait aussi peut-être ne pas découper l'écran et mettre la broche dans l'autre sens de l'autre côté de l'écran. Qu'en dis tu ?

Pour le bluetooth :

Je rappelle que pour le moment le code du bluetooth ne fonctionne pas vraiment. Il est très instable et fait planter le vario. Je suis en train de travailler sur une nouvelle version. Je pense la finir d'ici la fin de la semaine.

Pour l'instant j'en suis là :
-> J'ai fait en sorte qu'il y ai un trie lors de la réception des trâmes du GPS. Celles qui ne sont pas GGA ou RMC, ou celles dont le checksum n'est pas bon sont rejettées.
-> Dès que les trâme sont validées elle sont automatiquement envoyé sur le bluetooth tel quelle.
-> Entre temps elles sont sauvegardées dans un buffeur pour être interprétée.

Je travaille maintenant sur le fait de pouvoir écrire juste après, dans la continuité, la trame LXNav.

A suivre.

Ben justement, ca rentre facilement parce que j'ai modifié la connectique écran:
Côté écran on pourrait conserver le connecteur puisque vers le haut on n'a pas trop de pb d'épaisseur.
De l'autre côté, par "moitié de dupont" en fait j'ai soudé le câble sur la partie qu'on glisse sur la fiche mâle, et j'ai coupé à raz. Du coup le connecteur fait la moitié moins de hauteur, je peux torde vers le haut et poser dessus le module bluetooth.
Le plus juste c'est là en fait: dans la longueur il faut rentrer la batterie, le bluetooth et l'antenne GPS
Je pense qu'il vaut mieux laisser le connecteur écran sur la partie haute, cela permet d'ouvrir et basculer le couvercle avec l'écran fixé dessus, un peu comme sur la photo.

Salut,

je pense avoir identifier un Bug ou juste un problème sur mon vario, apparu avec la mise à jour sans reset (dernière version du github).

Je m'explique, hier en vol le vario fonctionnait bien, temps que le fix du GPS n'était pas fait.

A midi, j'ai fait plusieurs tests, pour finalement m’apercevoir qu'il semble qu'au moment de l'écrire sur la carte SD le vario plante.
Il fait un espèce de reboot, écran noir puis plus rien sur l'écran mais il continu à beeper. En désactivant la carte SD, plus de problème, affichage de la vitesse...
Mes essais se font avec la version du github en cours. le hard qui a déjà fait des enregistrements mais qui peu avoir un problème et la même SD qui a marché

Quelqu'un peu confirmer le problème

Haha ! Ca y est le Bluetooth marche !!!  :D

J'ai fini ma bibliothèque de gestion du bluetooth. Maintenant il me reste plus qu'à programmer :
 
-> le parseur de trame GGA et RMC
-> le générateur de trame LXNav.

Je vous envoie le code dès que possible !

jpg63 je te confirme ça dès que j'ai remis le code en place. Essaye quand même de reformater ta carte SD.

A+

ok merci prunkdump. de mon coté, Je refais des tests ce soir, je vais reformater la carte SD.
Pour info le fichier est créer au démarrage et j'arrive sans problème à mettre à jour le firmware avec la méthode sans reset

L'affichage de l'heure et de la durée de vol avance

(https://img15.hostingpics.net/pics/95791120170509195419.jpg) (https://www.hostingpics.net/viewer.php?id=95791120170509195419.jpg)
 

Le mien est hors service en ce moment et pas mal redémonté

j'attends un nouveau GPS pour le remonter et vous aider en allant voler (pour le tester  :oops: )

j'ai volé presque 2 heures aujourd'hui au-dessus de Nyons ... du gâchis  :mdr: 

Hello
Test ce matin en voiture et pas de bug constaté.(bluetooth monté mais hors tension/hors code )
Bravo prunkdump ! Le roi du code !

Merci pour ton test GtD73,

ce matin j'ai refais toute l'isolation des pins. Nouvelle gaine thermo, verification et après le premier test, tout à l'air de remarché.

Moi j'ai fait quelques vols avec en config : Pas de GPS et pas de SDCard. Connexion Bluetooth sur tablette avec XCTrack (toujours avec mon bout de code pas top mais fonctionnel)
Ultra conquit, ça marche nickel. J'adore le vario et sa réactivité. La transmission marche au top vers XCTrack, du coup j'ai des valeurs de 'finesses' assez réaliste et je vois la diff quand j’accélère.

J'ai volé +1h30 avec Vzmax à un peu plus de +6m/s (et -4m/s !). J'ai refait en soirée un autre vol de +20min mais le vario m'a laché les 2 dernières minutes. Donc autonomie d'environ 1h50 pour moi. Je pense que même si le GPS était désactivé dans le code il consomme quand même non ?

J'avais un peu peur que le vario soit trop réactif (quand on le bouge à la main) mais en l'air pas du tout. Super agréable.

Haaa ! Ca fait plaisir les bonnes nouvelles !  :D

Le miens n'a j'amais volé dans des conditions comme ça ! C'est d'ailleurs pour ça que j'ai essayé d'aider à la diffusion du code et du hardware. Super content que le comportement du vario t'ai plu !  :ppte:  Logiquement j'ai essayé de favoriser au maximum le "ressenti" de la masse d'air. Ce n'est pas qu'une question de réactivité, il faut que le vario assiste le mieux possible au centrage du thermique.

Et oui le vario consome autant, que le GPS soit utilisé ou non. Je n'ai rien prévu pour le désactiver. Et effectivement à la main on a vite tendance à être brutal. Ca ne correspond pas vraiment au comportement de la masse d'air.

Super Jpg63 et GtD73 que vous aillez pu réparer vos problèmes ! :bravo: Plus qu'à retester en vol vous aussi. Quand la météo voudra bien ... Van Hurlu je pense que t'y arrivera vite dès que t'aura reçu ton matos. T'as l'air de bien voler en plus !

Magnifique Jpg63 ton affichage de l'heure !  :pouce: J'aurais jamais pensé que ça puisse rentrer là ! Ca a de la gueule en tout cas.

Mon avancement sur le blutooth/GPS :

C'est bon, les trâmes du GPS sont filtrées et interprétées ! J'en ai profité pour changer la méthode du recalibrage de l'alti. Je me sert de la valeur de la précision dans la trâme GGA. Lorsqu'elle est inférieure à 2.00 je lance le calibrage.

-> Plus qu'à programmer une bibliothèque qui sort les trâmes LxNav.
-> Et une bibliothèque qui sort des trâme IGC de type "B"  sur la carte SD. (je pensais stocker l'entête dans l'EEPROM pour l'écrire à chaque démarage en changeant juste la date).

Une nouvelle idée :

Je me rends compte que le GPS calcule "l'angle de navigation". Comme il y a un compas dans le vario on pourrais calculer la déviation : direction et force du vent. Je pense que c'est une fonction qui intéresse pas mal de pilotes !

C'est bien ça avance de partout !

bonjour,
je suis toujours ce super projet,
j'avais fais un petit vario tout simple avant de passer à ce projet mais j'ai une question:
vous n'avez jamais de soucis avec les afficheurs 5110? j'en est 3 et j'ai le meme probleme sur les 3, ils finissent rapidement par avoir des faux contacts entre le verre et le shield (voir photo) j'ai démonté le premier, gratté le connecteur, remonté mais le probleme fini toujours par revenir rapidement :-(
il faut que je mette une pression sur l'afficheur pour qu'il marche :-(
vous n'avez pas ce soucis de votre côté?
j'aimerai bien passer à votre projet mais si l'afficheur a ce défaut c'est pénible :-(
(http://195.83.128.55/~fmeuzeret/vario1.jpg) (http://195.83.128.55/~fmeuzeret/vario2.jpg)

et encore bravo pour ce magnifique projet !

Impecc, pour le calibrage.

Pou les trames IGC ; tu as du voir qu'il est possible d'ajouter des extensions aux trames B ; ceci est décrit dans la trame I, qui fait partie de l'entete.
Voir http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html#link_4.1
Une extension qui semble courante (en tout cas, c'est utilisé dans les traces IGC de XCSoar et des FLARMs), et qui correspond à la trame I suivante :
I023638FXA3940SIU
Ca rajoute 5 bytes à la trame B :
le FXA : 'Fix accuracy" (en mètres) sur 3 bytes et le SIU : 'satellites In Use' sur 2 bytes
C'est intéressant, ca permet d'analyser après-coup la quailité de réception GPS



Ah oui ! Ca serait vraiment un gros plus de ce vario, et qui exploite au mieux les différents capteurs dont il est équipé.

Ce sont des valeurs qui peuvent être "lissées" dans le temps ; donc peu sensibles à des sautes d'humeur subites des capteurs.

Super idée l'affichage de la direction et la force du vent

Comme tu es dans le code de la bibliothèque nmea pourrais tu ajouter SVP, un getsatelite et un gettime - récupération du nombre de satellite et de l'heure dans la trame GPS, avec les modifications de la bibliothèque varioscreen que j'ai codé, on aura à l'écran le niveau du signal GPS et l'heure et la durée du vol en alternance toutes le 5s par exemple

oui, je vous rattraperai vite, et en attendant je bricole un autre projet Arduino beaucoup plus simple.

Question de voler, je vais atteindre les 1000 vols et 10 ans de vols dans quelques mois.
Bien voler c'est une question bien plus embarrassante pour mon égo :mrgreen:
Non je ne suis pas un cador, je peine à faire les plafs (manque d’instinct? et/ou de technique?) et du coup je ne vais jamais très loin  :roll: 

Mais je prends toujours autant de plaisir qu'à mes débuts  :vol:  :vol:  :vol:

voila, il reste quelques détails mais on pourra afficher la batterie, le signal GPS et le temps

(https://img4.hostingpics.net/thumbs/mini_57005220170511111109.jpg) (https://www.hostingpics.net/viewer.php?id=57005220170511111109.jpg)

Salut Alphatesteur. De retour parmi nous  ! :D

Bizarre ton problème...  :grat: Normalement quand il y a un faux contact ça fait un écran blanc et pas un écran noir. Tu es sûr de bien alimenter le 3.3V ? Autrement l'écran du 5110 est plutôt de bonne qualité. C'est plutôt la carte support qui n'est pas toujours de bonne facture. Elle n'est peut-être pas assez épaisse ? Les connexion sous l'écran sont elles étâmées ? As-tu vérifié que les broches métalliques sont bien fixée ?

Mon avancement :

Ca y est j'ai fini le code du bluetooth !!!   :D  A vous de tester ce que ça donne avec les logiciels de navigation ! J'envois maintenant les trâmes GPS et les trâmes LxNav.

Attention ! Sauvegardez vous un firmware avec la carte SD si vous voulez vous en servir avant de télécharger le nouveau code. Car dans la dernière version du code je n'ai pas implémenté la carte SD pour le moment.

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

@jpg

Super ton avancement  ! :bravo: Je n'ai pas encore eu le temps de te faire les fonctions pour l'heure et le satellite. Mais je vais te faire ça vite !

A suivre.

Une question sur la convertion trâme RMC -> trâme IGC "b" :

J'ai remarqué qu'il y avait une différence de précision :

-> Le GPS nous sort des trâmes RMC avec une précision de 9 et 10 chiffres
$GPRMC,152930.00,A,4604.71901,N,00624.55493,E,0.288,,110517,,,A*7B

-> Le format IGC ne prends qu'une précision de 7 et 8 chiffres :
B1529304604719N00624555EA0000000478

Savez vous si c'est important ?

Savez vous s'il existe une extension que permet de conserver la précision ?

A+

voila après les photos le code

Je ne pense pas qu'on puisse changer la précision des infos GPS dans les trames IGC.

La précision actuelle est largement suffisante ; très grossièrement, pour la France :
1mn de latitude =~ 1k300 ; 1 mn de longitude =~ 1km900 (ca varie en fonction du lieu, c'est un ordre de grandeur)

Une précision de 7 chiffres en latitude et de 8 chiffres en longitude est d'un millième de minutes.
Ca fait donc une précision de 1m30 en latitude et 1m90 en longitude.

C'est mieux que la précision du GPS ...

Salut !

Nickel le code jpg63  :pouce:  Dès que j'aurais bien fini les fonctions "de bases" je vais m'y coller pour l'intégrer sur le GitHub.

Autrement ça y est ! j'ai fini la sortie sur la SDCard des trâmes IGC !  :D

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

Mais pour l'instant il n'y a pas l'entête ! Il faut que je fasse un petit programme pour la sauvegarder sur l'EEPROM avec les différents paramètres personnalisé que l'on peut spécifier. Pour qu'elle soit recopié au démarrage sur la carte SD avant les trâmes B.

Le temps que je comprenne ce qu'il faut mettre au minimum.

A suivre !

wow, énorme vous êtes au top !

Super boulot.

Dans la trame, il y a entre autres les informations du pilote, de la voile et de l'appli. Il pourrait être intéressant d'avoir en plus des infos IGC, les infos de paramétrage, seuil de monté, descente, zerotage, volume ....

Un petit code pourrait lire un fichier TXT sur la carte SD et l'écrire dans l'eeprom, un peut comme le code de calibration

du coup par une simple manipulation des fichiers sur la carte SD, il deviendrait très simple de modifier le vario sans avoir à compiler   

@prunkdump, concernant le minimum pour les trames IGC :

Tu trouveras des exemples réels à https://github.com/vmath54/xcsoar/tree/master/IGC :
sample_flarm.igc : log d'un flarm
sample_xcsoar.igc : log d'un XCSoar

Le plus simple est la log XCSoar ; c'est celle qui a le moins d'entete ; puis dans le corps, il n'y a que des trames B et F
Les trames F donnent de l'info sur les satellites utilisés :  http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html#link_F
Elles sont obligatoires
xcsoar se content de mettre des trames F vides toutes les 4mn30  (ex : F135435 : c'est l'heure UTC)


Je pense que les trames d'entete minimums sont :

AXXX                    // Manufacter code. Mettre XXX si on n'en a pas
HFDTM100GPSDatum:WGS84  // le "GPS Datum"
I023638FXA3940SIU       // extension des records B. Doit etre après les records H, avant les records B

Une trame d'entete qui serait intéressante : HFDTE  (exemple : HFDTE020517) qui indique la date de log
Problème : elle varie, et doit être avant la trame I. Ca ne marcherait pas avec l'idée de mettre les entetes dans l'EEPROM.

je l'avais publié quelques posts avant, voila l'entête d'un syride nav

AXSR
HFDTE220417                               
HFFXA035
HFPLTPILOTINCHARGE: jpg63
HFCM2CREW2:
HFGTYGLIDERTYPE: not set
HFGIDGLIDERID: 0
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 3.25
HFRHWHARDWAREVERSION: 1.0
HFFTYFRTYPE: Syride, SYS'Nav
HFGPS: UBlox,MAX7Q,56ch,10000m
HFPRSPRESSALTSENSOR: ST,LPS331AP,11000m
HFCIDCOMPETITIONID:
HFCCLCOMPETITIONCLASS: 3BB13301
I023638TAS3940SIU

A RECORD - FR ID NUMBER

A                XXX ABC FLIGHT:1               Nom de l'application


H RECORD - FILEHEADER

HFDTE             160701                     UTC date of flight, here 16th July 2001
HFFXA             035            Typical fix accuracy, here 35 meters. FXA field can also be added to each B record
HFRFW             FIRMWAREVERSION:6.4         Firmware (i.e. software) version of the logger - anything you like
HFRHW             HARDWAREVERSION:3.0   Hardware version of the logger - any text that is appropriate

HFRFWFIRMWAREVERSION  6.4                  Firmware (i.e. software) version of the logger - anything you like
HFRHWHARDWAREVERSION  3.0                  Hardware version of the logger - any text that is appropriate
HFFTYFRTYPE               Calibri,FunkyLogger 77         Flight Recorded Type - any text is ok

HFGPS             Marconi,Superstar,12ch,10000m   Manufacturer of the GPS receiver inside the logger. Do we really care? Any text will work
HFPRSPRESSALTSENSOR       Sensyn,XYZ11,11000m   Manufacturer of the pressure sensor in the logger. Any text.
HFFTY             Calibri,FunkyLogger 77      Flight Recorded Type - any text is ok                              
HFPLTPILOTINCHARGE: Bloggs Bill D                  Free-text name of the pilot
HFCM2CREW2          Smith-Barry John A               Free-text name of the second pilot in a two seater
HFGTYGLIDERTYPE    Schleicher ASH-25               Free-text glider type
HFGIDGLIDERID       N116 EL                        Free-text aircraft registration number or code, e.g. N-number in USA. Or the number on the fin - it doesn't really matter
HFDTM100GPSDATUM    WGS-1984               Which GPS datum is the logger using. Always 100 in my experience but see the original FAI document if you want do something unusual.

Si cela peut aider

Vous me faites rever avec vos codes moi je suis une quiche...Je vais voir si ca existe un bouquin genre arduino pour les nuls...En attendant que ca vole...

L'en tête d'un igc sur Skytraxx est plus courte

AXSX001 SKYTRAXX V1.34 SN:3420841179
HOPLTPILOT:         Name         
HOGTYGLIDERTYPE:        Glider       
HOCIDCOMPETITIONID: 0000
HODTM100GPSDATUM: WGS-84
HOCCLCOMPETITION CLASS: Paraglider (Standard)
HPSITSITE: Unknown
HFDTE070614
B1426364422576N00519991EA0113201251
B1426374422576N00519986EA0113201251
B1426384422576N00519981EA0113301250
B1426394422576N00519976EA0113501251
...
ça fini par
...
LXSX;MC:2.9;MS:-4.1;MSP:44;Dist:16.2
G1643F21AAD150F41F52DC4BD76D50E36

en repensant à mon problème de GPS, je me dis qu'une des causes possible
est un contact avec les soudures dessous
par sécurité je mettrai un bout de plastique d'emballage pour isoler
voir photo

(https://i58.servimg.com/u/f58/12/58/57/57/isolat10.jpg)


sinon pour tester un autre emplacement de la carte BT
la mini-carteSD risque d'être coton à sortir, mais ça rentre en limant un peu la carte
et en dessoudant les broches du connecteurs

(https://i58.servimg.com/u/f58/12/58/57/57/testmo10.jpg)

Vous pouvez vérifier s'il vous plait les trâmes "F" sur les fichiers IGC générés par vos varios ? Parceque effectivement dans la doc cette trâme est marquée comme obligatoire (au moins toutes les 5 minutes). Est-ce que les varios la laisse vide comme XCSoar ?

Oui Vmath54 j'avais prévu de mettre la date dans l'IGC. Elle sera dans l'EEPROM mais elle sera écrasée par le vraie date donnée par le GPS lors de la création du fichier. Merci beaucoup pour les infos ! J'ai plus qu'à comprendre. La doc est très bien faite mais un peu complexe.

@GtD73 : Pas de soucis  :D  tu pourras aussi nous aider avec tes qualités de parapentiste ou en électronique ! L'essentiel c'est que ça te donne envie ! Il faut commencer doucement la programmation Arduino. Le "starter kit" est un peu cher mais très pédagogique. On arrive vite à faire des petits trucs sympas. Autrement tu peux faire comme Van Hurlu : trouve toi un "petit" projet à bricoler.

@Van Hurlu : Je ne pense pas qu'il y ait beaucoup de risque de faux contact sous le GPS. Il n'y a presque pas de cicuit de ce côté. Juste une masse. Par contre si tu veux tu peux limer le bord qui touche les pins de la carte SD. Tu peux limer la partie bleu foncée. En tout cas elles sont belles tes soudures !


 

Je viens de finir la mise à jour du Fritzing

FlyMe et XCTrack : pas de F
Ça marche très bien dans LogFly et sur la CFD (fai approved)

Exemple :

Ensuite que des B et les G de validation fai à la fin.