DIY GnuVario : variomètre opensource - openhardware Arduino

[gargle]

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

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

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.

[Xiboard]

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 

[vmath54]

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 ?

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 ?

[Xiboard]

[...]

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

[...]

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)

[Xiboard]

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.

[vmath54]

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

[prunkdump]

Salut à tous ! 

Moi aussi j'ai bossé !   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 !

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.

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.

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.

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 Ya plein de choses qu'on pourra faire.

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 ?

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+

[Xiboard]

-> Chargez le code avec la SDCard et le bouton reset (pour la dernière fois   )
-> Remontez le boîtier.

Du coup il faut prendre celui compilé avec le bootloader ? ou sans ?

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.

Oui, je suis conscient que c'était un code dégeux ! Mais ça marche !

[prunkdump]

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 ! 

[Xiboard]

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

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.

[vmath54]

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 ?

[GtD73]

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 ! 
Mais je crois avoir lu que quelqu'un bossait sur un vario pour planeur, alors peut-être que là ce sera plus important.

  
Test en vol demain, il paraitrait qu'on a une petite ouverture avant un week end pourri.
  

Encore merci à prunkdump, et à tous les autres aussi !
 

[vmath54]

Moi aussi j'ai bossé !  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.

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

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.

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

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 ?

[ptitkiki]

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

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.

[Xiboard]

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 ?


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 ?

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

[jpg63]

Salut à tous,

La mesure de la batterie est dans la boite



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][/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

[prunkdump]

Bravo GtD73 pour le montage ! Et bin dis donc ya des rapides du fer a souder    Je vais vous faire monter des varios à la chaine

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. 

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

[prunkdump]

Magnifique jpg63 !! 

Je me disais bien que tu allais nous sortir un truc super bien fini !

Au moins mon code n'est pas complètement illisible  Tu as réussi à bien réutiliser les fonctions de la bibliothèque varioscreen. En plus ça rentre nickel sur l'écran !    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 !

[jpg63]

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

[ptitkiki]

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+

[Xiboard]

Il semble que le vario de Xiboard fixe bien avec le bluetooth. Et pourtant il habite pas sur une autre planète .

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

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.

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

[vmath54]

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 

[Van Hurlu]

... vous allez trop vite pour moi 

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 

[ptitkiki]

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.

[GtD73]

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