DIY GnuVario : variomètre opensource - openhardware Arduino

#281

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,01F
$LXWPO,Y,0,1607,1.00,0,0,01A
$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

#282

Salut à tous ! :coucou:

Moi aussi j’ai bossé ! :smiley: 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 :wink: )
-> 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 :smiley: 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+

#283

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 !

#284

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:

#285

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.

#286

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 ?

#287

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:

#288

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 ?

#289

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.

#290

  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” ??

#291

Salut à tous,

La mesure de la batterie est dans la boite


https://img4.hostingpics.net/pics/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

#292

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 :smiley:

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 :wink: .

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.


[u]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.

#293

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 !

#294

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

#295

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+

#296

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

#297

Concernant les trames LXWP0 et XCSoar : la nuit porte conseil :wink:

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:

#298

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:

#299

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.

#300

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 !