DIY GnuVario : variomètre opensource - openhardware Arduino

#1021

:soleil: :soleil: :soleil: bon travail prunk :pouce:

le test : allumage sur ma terrasse et immobile
Altitude de référence mesurée à partir d’une borne 372 m
3 barres au GPS du gnuv
l’alti du gnuv est stable et indique 375 m
l’alti gps XCTrack varie doucement entre 371 et 380 m
l’alti baro de XCTrack est stable et indique 326 m

:bravo: et bien sûr la grosse nouveauté est que si on lève brusquement le gnuv le XCtrack bip (avec une demie seconde retard)
idem si on le descend

Mon problème maintenant est lié aux paramétrages de XCTrack
je ne comprends pas comment on règle la détection du décollage.
il est trop sensible et XCTrack me demande sans arrêt de valider des atterrissages

J’ai aussi un problème avec l’interface de XCTrack
quand on visualise l’écran avec la carte le zoom est trop fort, si je dézoome, je reste dans la fonction zoom, je ne peux plus changer d’écran ? Comment sortir de cette fonction Zoom ??? j’ai tout essayé.

Si qq à une idée ?

maintenant il faut faire un test en vol (pas avant lundi)

@prunk : sur tes FIRM suivants, pourrais-tu baisser un peu le son ? merci d’avance

#1022

Salut, de retour de vacances. Une semaine sans parapente et internet :cry: , c’est plus de temps pour se reposer, se balader et développer. J’ai profité de quelques matinées de libre pour continuer le portage sur M0

En m’inspirant du projet de Hari,

https://github.com/har-in-air/ESP8266_MPU9250_MS5611_VARIO

et en reprenant les sources du gnuvario

voici ce que j’ai pour l’instant porté sur Arduino zero :

  • baromètre -MS5611
  • accéléromètre et gyroscope - Mpu9250
  • carte Sd - enregistrement en IGC

j’ai ajouté

  • Fichier de config Texte - chargement au début du programme
  • Possibilité d’arrêter le vario après 20min d’inactivité
  • détection des poussoir de navigation
  • Calibration des gyro et accéléromètres
  • Interface de communication PC - arduino par l’USB (en cours de finalisation)

Ce qui reste à faire :
coté logiciel 2 bibliothèques posent problème, toneAC qui gère le pwm en mode push-pull (2 pattes de l’arduino), pour l’instant j’ai intégré la bibliothèque Tone, mais il va falloir certainement tout réécrire ToneAC. La bibliothèque SerialNMEA elle aussi pose problème, elle utilise une gestion des interruptions et des commandes non supporté par le M0, elle gère le dialogue avec le GPS et le BT. 2 gros morceaux à régler pour que le code soit complètement porté

Il faudra ensuite tester tout ça et plus nous seront à sortir nos platines d’essai et plus vite nous détecterons des problèmes avant de penser à une intégration hardware.

Coté matériel il y a aussi du travail, il va falloir réfléchir au système d’alimentation et de power ON/OFF le mieux adapté, régler les problèmes de filtre sur la partie audio et réfléchir à des possibles améliorations comme le passage sur un GPS Neo8 avec une petite antenne ou l’ajout d’une sonde de pression partiel (que je vois bien déportée avec une communication Bluetooth)

je vous mets les librairie et le code, tout vos retours feront avancer notre projet

#1023

et voila la suite

j’ai oublié de précisé que l’écran I-Ink n’est pas encore porté sur M0+, mais le développeur de la bibliothèque GxEPD, a déjà rendu sa bibliothèque compatible avec plusieurs micro-contrôleurs (récemment pour la famille des arduino Uno, pro-mini et autre) et prévoit de le faire pour le M0 à ma demande, cela ne devrait pas tarder je l’espère

#1024

j’ai trouvé la réponse à ma question grâce à un tuto en italien à 7:25

https://youtu.be/RBbOwAetulQ

j’étais assez enthousiaste au sujet de XCtrack, pour sa simplicité, son interface et son fonctionnement sous Androïd
maintenant que j’ai découvert à quel point c’est mal documenté et “in-progress” je suis plus méfiant
http://xctrack.org/

#1025

Parfait les tests VanHurlu :pouce:

Bon c’est super que XCTrack marche avec la trâme LK8000 ! Il faut juste maintenant que je fasse en sorte d’envoyer plus de trâmes vario afin que ça soit plus réactif sur la tablette. Pour l’instant on envoi juste une trâme toutes les 2 secondes. C’est suffisant pour le GPS mais pas pour le vario.

Et il faut aussi que je fasse la modif de Vmath54 pour éviter les envois inutiles sans le fix.

A suivre !

Autrement les nouveaux kits sont presque près. Une petite semaine encore.

#1026

je comprends mieux le décalage du son du vario

#1027

Salut à tous !

Je me suis fait discret mais je vole toujours avec le gnuvario. Le dernier épisode a été de ressouder la prise usb que j’avais arraché. Je voulais brancher une batterie externe pour un vol annoncé long et ca a mal tourné. Bref c’est réparé mais j’ai bien cru que je n’y arriverai pas, j’envisageais de m’en remonter un !

Sur les dernières traces que j’ai, je vois que la fonction auto start semble démarrer longtemps avant le début du vol. Et le stop se fait toujours à l’arrêt du vario. Du coup, j’arrive à récupérer mes vols avec logfly, mais les durées de vol ne sont pas bonnes.

Entre-temps j’ai finit de réparer ma kobo (écran cassé), j’ai installé xcsoar sur une carte sd plus grande, j’ai plus qu’à relier les deux ensemble…
Ce qui m’emmène à ma question: c’est quoi le bon protocole ???

J’avoue que j’ai du mal à raccrocher le wagon depuis les essais de modifications du son.

Est ce que la versions du github prend en compte toutes les modifs de jp63 ?

Si il y a une nouvelle version je veux bien être “béta” testeur :smiley:

#1028

Salut, pour l’arrêt c’est normal, il n’y a aucune détection de fin de vol, il faut éteindre le gnuvario au posé. Pour le démarrage il y a 2 options possibles, directement après le fix du gps ou après la détection du début du vol (vitesse > à 8km/h et vario au moins 0.5 en plus ou en moins), la variable est dans le fichier variosetting.h . Demain je mettrais à jours mon code avec les dernières modifs diffusées sur github, je mettrais 2 fichiers HEX avec et sans BT et le vol commencera à la détection du décollage

#1029

voila mon code avec toutes les dernières modifications présentes sur le github

version avec ou sans Bluetooth à renommer en FIRM.HEX

bon vol

#1030

Salut GtD73 !

On savais bien que tu étais toujours dans le coin :wink: T’as raison le plus important c’est de voler ! Même pour le développement du vario :smiley: On manque toujours de tests et de retour en conditions réelles. Avec les 10 kits suivant on pourra sûrement améliorer ce point.

Pour la prise USB je crois que s’était arrivé aussi à VMath54. Peux être que j’ai fais les trous dans le boîtier trop justes. Du coup si ça force sur le circuit imprimé ça force aussi sur l’USB. Le problème c’est que je n’ai trouvé aucune autre plaque de charge sur eBay.

Pour la connexion avec XCSoar la configuration par défaut devrait convenir ( avec bluetooth ). Le vario envoi des trames LXNav qui sont bien interprétées par XCSoar. Après pour la configuration du logiciel, je n’y connais rien. Il faut demander à VMath54 :wink:

Bon vols !

#1031

Je confirme que la conf par défaut est l’envoi de trames LXNAV, qui conviennent parfaitement à XCSoar.

Ensuite, pour la partie connexion Bluetooth (BT) entre gnuV et XCSoar :

  1. Appairer en bluetooth (BT) le gnuV et la tablette / smartphone
    A faire la première fois. Les fois suivantes, ca se fera tout seul
    Ce que j’ai fait :
    . Démarrer la tablette sans le BT
    . Démarrer le gnuV ; attendre une minute
    . activer le BT sur la tablette. Ca va afficher les éventuels périphériques déja appairés en BT, et en appareil disponible, un appareil nommé “HC-06”.
    Cliquer sur HC-06 ; entrer comme password “1234”

Et voila. La tablette est appairée avec le gnuV en BT. Elle le sera les prochaines fois automatiquement, sans avoir à recommencer la manip

  1. XCSoar. Déclarer le “device” externe
    Config - Périph
    . Par défaut, le périphérique A est positionné sur “GPS intégré et senseurs”, et ce périphérique est en état “Position GPS” (ou “Indisponible” si le GPS n’est pas activé sur la tablette).
    Le mettre en état “Désactivé” en cliquant sur le bouton “Désactiver”

. Par défaut, les autre périphériques (B, C, D, E, F) ne sont pas affectés. Ils sont marqués “Désactivée”.
. Choisir le périphérique B, et cliquer sur le bouton “Editer”
. Port : choisir le port “HC-06”, qui correspond à la connexion BT avec le gnuV
. Pilote : choisir LXNAV, puis valider
Le périphérique s’affiche alors comme “B: LXNAV sur Bluetooth HC-06” ; Il passe en état “Position GPS” si le fix GPS a été fait, ou “Connecté” sinon. Si la connexion BT n’est pas bonne, l’état est “Bluetooth désactivé” ou “Non connecté”
Si on veut vérifier le bon fonctionnement : cliquer sur le bouton “Controle” ; on peut voir alors les trames NMEA transmises. Il doit y avoir des trames GPGGA, GPRMC et GP8EX1. Cliquer sur “Fermer”.
Si le fix GPS a été fait, les trames GPGGA et GPRMC comportent les coordonnées GPS et d’autres infos ; sinon, elles sont quasi vides.

Ensuite, on peut utiliser XCSoar comme d’hab. Il utilisera le GPS et les infos barométriques et de vario du gnuV.

Au fait, @prunkdump : le vario se présente comme nom de périphérique BT “HC-06” ; on ne pourrait pas choisir un autre nom, comme gnuVario ou autre ?

A +

#1032

Et ben en tout cas vous êtes toujours aussi réactif !

Je vais déjà faire la maj avec les .hex de jp63, merci beaucoup !
Après j’irai jetter un oeil au setting quand même.

Et pour la dernière phase avec xcsoar, déjà merci beaucoup pour les infos de config, je vais essayer de m’en inspirer.
Mais ma config est un peu différente, la kobo glo n’a pas de bt…Ce n’est pas très grave, je vais faire comme si je rajoutais le blueflyvario:
http://blueflyvario.blogspot.fr/2015/08/more-bluefly-and-xcsoar-integration.html (c’est peut être pas exactement la bonne page mais j’ai fait vite, c’est quelque part par là )
Pour ce, il me faudra…brancher fil à fil…en débranchant le module BT. Un peu dommage, après mes grandes recherches sur le filtre…Mais là j’ai encore un doute sur la compatibilité du niveau d’E/S du port série kobo/gnu.

Bref, j’espère bien voler encore avant que tout cela soit fonctionnel !!

#1033

Tu peux aussi raccorder un module BT Master (HC-05, …) à ta kobo, soit en le soudant sur le port série interne, soit en raccordant ce module à la prise micro-USB, en mode USB-OTG

Ca te permet de faire communiquer le gnuV avec le XCSoar sur la kobo.

J’ai pas fait, mais on trouve des choses dessus sur le net.
Par exemple :
https://forum.xcsoar.org/viewtopic.php?f=3&t=2502
https://forum.xcsoar.org/viewtopic.php?f=3&t=2751
https://forum.xcsoar.org/viewtopic.php?p=5357#p5357
https://forum.xcsoar.org/viewtopic.php?p=5357#p5385

Pour la partie USB_OTG, 2 vidéos :
https://www.youtube.com/watch?v=tQJNUTSrulo
https://www.youtube.com/watch?v=Qb2P3zqjoyQ

#1034

Salut,

voici le schema préliminaire pour notre nouvelle version avec M0


https://img11.hostingpics.net/pics/356571variometerM0.jpg

toutes vos suggestions, et vos idées sont les bienvenue

#1035

Les résistances de pull up/Down ne sont pas intégrées au micro p ?

#1036

non pas sur l’arduino MKRZero, les résistances sur SDA et SCL apparaissent sur le schema mais elles ne sont pas présente. C’est différent sur l’adafruit. Elles vont certainement être ajoutées mais pour l’instant sans les résistances mes tests ne marchés pas

Pour les résistances pull up il y en a sur une partie des entrées/sorties. Par contre je ne sais pas pour les pull down, il faut que je regarde

#1037

D’abord, merci pour l’extension du projet, avec un micro controleur moins limité que le gnuV initial, surtout en mémoire.

On devrait pouvoir utiliser plus facilement des librairies standards, et ne plus avoir à grappiller des octets par ci ou par la.

Quelques remarques :

  • une bricole : le jumper bluetooth est-il nécessaire ?
    Je suppose que c’est pour limiter la conso de courant.
    Sur un smartphone, on peut désactiver l’utilisation du bluetooth par soft ; on ne peut pas le faire avec le matériel utilisé par le gnuV ?

  • les nouveaux switchs : ca me réjouis. Ils sont raccordés à des entrées du mkzero, ca va permettre d’interagir avec le gnuV ; même pour des choses non prévues au départ.

  • j’avais compris du projet gnuV3 qu’il y aurait une sonde de pression différentielle ; ceci pour mesurer la vitesse air. Ca permettrait pas mal d’applications.
    Je ne vois pas dans le schéma ; je me trompe, ou c’est abandonné ?

#1038

Non je n’ai pas oublié la sonde de pression partiel, c’est volontaire qu’elle n’apparaisse pas sur le gnuvario.
Je m’explique, je pense mais c’est peut être une erreur qu’il sera très compliqué d’avoir une position optimale du tube pitot si le gnuvario est placé sur les élévateurs, je pense aussi la même chose si il est sur un cockpit.
Mon idée c’est d’avoir la sonde déportée, qui communique en BT avec le Gnuvario

Je pense utiliser une board ESP32 ou une ESP 12 à quelques euros, une batterie, et la sonde

par exemple :

http://www.ebay.fr/itm/ESP32-Development-Board-Module-WiFi-2-4GHz-Bluetooth-Dual-Mode-Flash-Memoire-/362071189849?hash=item544d1fe959:g:OjwAAOSwjn9Zktxq

http://arduino.blaisepascal.fr/index.php/2016/02/16/capteur-de-pression-differentiel/

https://drotek.com/shop/fr/home/793-capteur-de-vitesse.html

en déportant la sonde on pourrait placé le tube pitot le long de la sellette dans le flux d’air

#1039

hello,

j’ai un peu décroché a cause des congés et du manque de dispo.
Après avoir regardé le schema pour du M0, voila qques remarques :

  • L9110 difficile voire impossible à appro en quantité autre qu’en chine … je partirais sur un vrai ampli audio
  • le jumper pour le BT : si c’est en CMS, met une resistance 0 ohms, sinon faire dans le pcb 2 pastilles cote à cote et reliés par 1mm de piste. Si tu veux pas, un coup de cutter pour les séparer, et si tu veux rajouter, une goutte d’étain dessus.
  • pull up en 10k (comme ca tu as moins de composants différents)
  • power option 1, faudra en permanence le bouton actif (genre slider) et ne permettra pas de l’éteindre de façon soft --> peu d’intérêt
  • power option 2, tu chargera jamais la batterie au max (0.6V de la diode) et tu ne pourra pas charger et utiliser en meme temps (power bank) --> moyen
  • power option 3, il manque une centrale nucléaire pour faire un peu plus compliqué :wink:
  • auto power, ca semble pas mal, tu peux meme remplacer le mosfet par l’inter directement.

ca fera une bonne base de travail
karma+

#1040

salut merci pour vos conseils et vos idées.

c’est une bonne idée d’utiliser les même résistances, simplification, simplification, c’est la même chose pour le power, une idée de punkdump, qui va simplifier le circuit,

on enlève le poussoir du reset (un poussoir + une résistance) et on ajoute un inter qui coupe l’alimentation totale (utilisable pour faire des économies de batterie et comme reboot en cas de plantage)
on utilise un bouton pour le power via une interruption du M0 (mise en veille du M0 et sortie de la veille). On utilise un régulateur contrôlé pour l’alimentation des cartes sauf l’écran (double avantage, on a du 3.3v propre et on peut couper alimentation des cartes à volonté) - principe on appuie sur le poussoir, l’arduino détecte un changement et déclenche une interruption, on reset l’arduino logiciellement - dans la partie setup on active le régulateur (patte EN) ce qui alimente les cartes. Si l’arduino est en marche et que l’on appuie sur le poussoir plus de 2 sec on passe la patte EN du régulateur à zéro, les cartes ne sont plus alimentées, on ferme le fichier IGC, on affiche les stats sur l’écran et on passe l’arduino en veille

https://www.adafruit.com/product/2745

https://www.pololu.com/product/2106


https://img11.hostingpics.net/pics/451265variometerM0.jpg