DIY GnuVario : variomètre opensource - openhardware Arduino

[gargle]

Hello,

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

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

[vmath54]

Salut,

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

Concernant les trames NMEA utiles a transmettre en bluetooth :

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

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

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

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

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

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

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


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

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

Ca semble une valeur sure.


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


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

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

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

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

[jpg63]

Merci beaucoup pour ces précisions, Prunkdump

pour les variables

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

une petite précision pour que je comprenne bien

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

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

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

Attention logfly et xcglobe n'accepte que l'igc

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

[prunkdump]

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

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

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

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

@jpg63

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

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

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

[Xiboard]

Je peux faire des essais.

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

[ptitkiki]

hello,

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

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

tu changes dans ms5611.h
#define MS5611_INTERRUPT_COMPARE 69
Par :
#define MS5611_INTERRUPT_COMPARE 71

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

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

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



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

A+

[jpg63]

salut ptikiki

hello,

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

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

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

tu changes dans ms5611.h
#define MS5611_INTERRUPT_COMPARE 69
Par :
#define MS5611_INTERRUPT_COMPARE 71

Totalement d'accord

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

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

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

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

 J'ai aussi quelques doutes sur l'autonomie, vue la taille de la batterie, et avec toutes ces fonctions, on verra bien.

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

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

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

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

A+

Pareil

[Gej]

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

outputMode (default = 0) - Sets the output mode. The available output modes are:

    0 - The standard BlueFlyVario output mode. This sends raw pressure measurements in the form:
        "PRS XXXXX\n": XXXXX is the raw (unfiltered)pressure measurement in hexadecimal pascals.
    1 - The LK8EX1 output mode for use with LK8000. This sends pressure and vario data in the form:
        "$LK8EX1,pressure,altitude,vario,temperature,battery,*checksum\r\n": pressure is sent as a decimal integer number of pascals, altitude is not sent (99999 is sent instead), vario is the decimal integer vertical climb rate in cm/s, temperature is in degrees Celsius (1 decimal place), and battery is the battery voltage of the on-board battery (2 decimal places).
    2 - The LXWP0 output mode for use with a range of apps:
        "$LXWP0,loger_stored (Y/N), IAS (kph), baroaltitude (m), vario (m/s),,,,,,heading of plane,windcourse (deg),windspeed (kph)*CS": The BlueFlyVario only has a partial implementation of this sentence. It only outputs the baroaltitude and vario (all other fields are blank). Note that baroaltidude is determined from filtered pressure using the outputQNH setting.
    3 - The FlyNet protocol:
        "_PRS XXXXX\n": In this case XXXXX is output as the filtered pressure stream. The filtering parameters used are those from the other hardware settings.

Si cela peut vous aider...

[prunkdump]

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

Dites moi si vous voyez bien les sous-titres ?

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

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

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

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

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

Mais c'est bien compatible avec XCSoar...

[Xiboard]

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

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

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

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

[prunkdump]

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

Content que le montage t'ai plu !

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

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

Il faut réfléchir encore.

[jpg63]

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 

[ptitkiki]

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  )

[guillaume1]

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

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

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

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

[prunkdump]

Ouai c'est pas évident ....  

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

1111111111
1000000001
1011001101
1011001101
1011001101
1000000001
1000000001
1111111111

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

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

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

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

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

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

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

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

Pour ton idée de charge de la batterie :

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

[prunkdump]

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

[jpg63]

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

[Xiboard]

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.

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 !

[ptitkiki]

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

[Xiboard]

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 !

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

[prunkdump]

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

Un dans le ms5611 :

-> dans libraries/ms5611.h

Code:

/* 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 

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

[Xiboard]

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

[vmath54]

[...]
je voulais juste indiquer que les enregistrement NMEA n'étaient pas bien convertis par GPSBABEL et que du coup les altitude barométrique n’était pas dans le fichier IGC.

Entièrement d'accord, je vais faire qq essais. Mais ça m'étonne pas NMEA c'est du pur GPS. J'ai pas bien regardé mais Prunk à rajouter des trames OpenVario ($POV, n'est ce pas ?). On a l'alti baro et valeur vario dedans c'est ça ?

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

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

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

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

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

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

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

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.

[vmath54]

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

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.

[Xiboard]

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

GPS et SDCard désactivés.

Code:

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