DIY GnuVario : variomètre opensource - openhardware Arduino

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

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 :frowning: 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 811) <-> (bloc B de 811) <-> (bloc C de 8*11)

  1. 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 811)
(bloc B de 8
11)
(bloc C de 8*11)

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

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

/* check if you have new data */
boolean ms5611_dataReady(void);

/* then compute compensated temperature, pressure and alti values */
void ms5611_updateData(void);

/* and finally get computed values */
double ms5611_getTemperature();
double ms5611_getPressure();
double ms5611_getAltitude();

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

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.


#ifdef HAVE_BLUETOOTH
  if(millis() - lastSendBluetooth > 100){
    //$LK8EX1,pressure(Pa),altitude(m),vario(cm/s),temperature(°C),battery(volt or %+1000),*checksum
    //sprintf(paquetBluetooth,"LK8EX1,%lu,%i,%i,%i,999",(unsigned long)(ms5611_getPressure()*100),(int)kalmanvert.getPosition(),(int)(kalmanvert.getVelocity()*100),(int)ms5611_getTemperature());

    //$LXWP0,loger_stored (Y/N), IAS (kph), baroaltitude (m), vario (m/s),,,,,,heading of plane,windcourse (deg),windspeed (kph)*CS
    //sprintf(paquetBluetooth,"LXWP0,Y,0,%i,%i,,,,,,0,0,0",(int)kalmanvert.getPosition(),kalmanvert.getVelocity());

    //Serial.print(F("$"));
    //Serial.print(paquetBluetooth);
    //Serial.print(F("*"));
    for(int i=0;i<strlen(paquetBluetooth);i++){
      CheckSum ^= paquetBluetooth[i];
    }
    //if (CheckSum<0x10) {Serial.print("0");} 
    //Serial.println(CheckSum, HEX);

    //PRS XXXXX\n
    Serial.print(F("PRS "));
    Serial.println((unsigned long)(ms5611_getPressure()*100), HEX);

    lastSendBluetooth = millis();   
  }
#endif //HAVE_BLUETOOTH

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.