DIY GnuVario : variomètre opensource - openhardware Arduino

[finlard]

Ensuite si tout marche bien tu peux tester ce firmware.

Il intercale de la communication avec l'écran au milieu de la communication de la carte SD. L'écran doit afficher des choses.

Encore une fois :

-> si le vario fait 1 bip grave : la carte n'a pas pu être initialisé
-> si le vario fait 2 bips graves : le fichier n'a pas pu être créé
-> si le vario fait 3 bips aigues : tout c'est bien passé pour le code

Si maintenant ça ne marche plus c'est le problème que décrivait Jpg63. On t'expliquera ce qu'il faut vérifier sur le circuit.

Bon courage.

j'ai testé tout d'abord l'écriture de la carte SD seule et ça marche (3 bips et un fichier). Par contre, avec l'écran intercallé ça ne marche plus (2 bips graves), que l'écran soit installé ou non. Du coup ça doit être le problème de Jpg63 mais je retrouve pas le post en question...

[jpg63]

Ton problème est lié à un cour-circuit sur la patte qui commande l'activation de l'écran ou de la SD. Il faut éviter de serrer le capot du boitier. Vérifie capot ouvert tu ne dois plus avoir le problème

Mets des vis longues et laisse un peu de place, pour éviter compresser les cartes. Pour l'instant je n'ai pas mieux

[finlard]

je ne suis plus dans le boitier depuis belle lurette

J'ai essayé de soulever la carte SD pour qu'elle ne soit plus en contact avec le circuit (j'ai un espace complet sous la carte) et ça ne change pas le pb. Je vais déssouder la carte SD, tout bien nettoyer en dessous, et la ressouder pour voir si ça règle le pb. Vous auriez un conseil pour déssouder? Je n'ai jamais eu l'occasion de pratiquer

[jpg63]

je ne suis plus dans le boitier depuis belle lurette

J'ai essayé de soulever la carte SD pour qu'elle ne soit plus en contact avec le circuit (j'ai un espace complet sous la carte) et ça ne change pas le pb. Je vais déssouder la carte SD, tout bien nettoyer en dessous, et la ressouder pour voir si ça règle le pb. Vous auriez un conseil pour déssouder? Je n'ai jamais eu l'occasion de pratiquer

On est plusieurs à avoir le problème, la solution du post plus haut a marché, mais le problème persiste, si tu trouve d'ou vient le problème, nous pourrons l'éviter pour les futurs kits. Il me semble que le problème vient de la patte CS qui passe à la masse. Bon courrage

[finlard]

bon je capitule... après moulte effort j'ai réussi à enlever le lecteur SD (quelle misère à déssouder!). J'ai ensuite voulu rechauffer toutes mes soudures limées et là catastrophe j'ai fait des ponts partout. Aprèse avoir fait un mieux (et m'etre brule trois fois;) ) j'ai voulu ressouder le lecteur mais impossible, trop abimé. Bref c'est de pire en pire et je crois pas que ce soit récupérable en l'état. Je pense que je vais attendre la version 2!

[Van Hurlu]

Pour dessouder, comme je n'ai pas de pompe ou de matériel sophistiqué comme certains 

j'utilise la méthode du "choc" 
au-dessus d'une table
tu prends la carte dans la main gauche, le fer dans la main droite,
tu chauffe bien fort
tu cognes ton poignet gauche sur la table (rapide et fort)
tu pourras déboucher tes œillets et enlever tes surplus de soudure

J'ai presque tout démonté et tout remonté à l'époque ou j'avais plein de problèmes ... j'avais le poignet qui commençait à devenir bleu 

on ne dirait pas, mais c'est du solide ces petits machins pleins de trucs et de bidules

[finlard]

j'en suis venu à la même technique . J'ai bien une pompe à déssouser mais pas du tout efficace ce truc.

Je viens de ressouer le lecteur SD avec des fils en ultime tentative mais toujours rien.

[vmath54]

Voici les firmwares pour ceux qui veulent bien tester XCSoar et XCtrack

Essais fait sur XCSoar, avec driver LXNAV. J'ai affiché dans XCSoar, entre autres, les infobox correspondant au vario, l'alti GPS, l'alti baro
J'ai paramétré XCSoar pour qu'il écrive en log les trames NMEA recues.
Essais fait dans une voiture

low_freq_gps :
--------------
XCSOar indique qu'il reçoit Position GPS, Baro, vario
Le vario affiché par XCSoar est aléatoire. Il ne correspond pas vraiment aux infos affichées par le gnuVario :
Lorsque la valeur varie entre -0.8 et -0.9 sur le gnuVario, le vario varie en général entre -0.1 et +0.1 sur XCSoar.
Lorque la valeur est plus élevée (> 1m/s, ou < 1m/s), c'est plus juste. Il y a juste parfois un affichage furtif à 0.1 (par exemple), alors que ca semble constant à 1.4 (par exemple) sur le gnuVario.

alti GPS : varie de qqs m par rapport à l'alti donnée par le gnuVario. La différence n'est pas constante : parfois presque pas (2m), parfois bien plus (15m). Je trouve cette variation de diff étrange.
alti baro : J'avais réglé le QNH du moment (1012). Il y avait une diff d'environ 16m avec la valeur alti vario. Pour annuler la diff, j'ai du rentrer un QNH de 1014

high_freq :
----------
XCSoar indique qu'il reçoit Baro, vario
Même constat que précédent pour l'affichage vario sur XCSoar. Donc, erratique.
Si je règle le QNH à 1013 sur XCSoar, L'alti baro affichée est identique (à 2m près) à l'alti affichée sur le gnuVario ; c'est cohérent.

Je joins les trames NMEA que XCSoar a recues (en tout cas, ce qu'il a logué). Il y a 4565 lignes, soit environ 15mn.
J'ai changé les virgules en point-virgule pour lire directement sous excel.
Ca correspond à un trajet aller/retour départ de mon domicile ; avec du plat relatif au début, une montée, une petite descente, puis demi-tour.

Ces trames correspondent, je pense, à ce que XCSoar m'a affiché : la plupart du temps, entre -0.1 et + 0.1. ET des périodes à +1.x et -1.x.
Alors que le gnuVario m'affichait autre chose, surtout dans les tranches -0.1 et +0.1.


choses remarquables  :
par exemple,
  lignes 2062 et 2063 : on passe de -1.08 à -0.092 ; donc en 1/5eme de secondes. L'altitude transmise n'a pas changé : 236.7m
  lignes 2110 à 2140 : on est dans une descente continue. On passe subitement d'un vario à -1,xx vers un vario à -0.09X (ligne 2124), alors que l'altitude continue de baisser assez régulièrement ; j'ai du mal à comprendre.


Conclusion (sur de tout petit essais) :
---------------------------------------
- la partie GPS et alti baro semblent cohérents
- les infos vario transmises en NMEA semblent douteuses

Chaque appli a ça façon de calculer, interpréter les valeurs qu'elle reçoit. C'est difficile de piger.
XCSoar : reçois vario et alti du GNUVario (exemple 53m et 0,1m/s) > il affiche une alti Baro de 38m et le Vario n'affiche jamais la même valeur que sur le GNU. Il doit faire un mix avec le GPS je pense ou un filtre.

J'ai par contre pas pu tester avec l'envoie des NMEA. Mon GNU n'a pas fait le fix je crois et en plus j'ai le GPS sur la tablette.
Les trames GPGGA et GPRMC apparaissent bien dans le debug de XCSoar. Cependant il n'a jamais réussi à interpréter ces valeurs. Peut être le fix doit être fait pour que ça marche.

Si tout n'est pas clair, dites moi, il est tard :/

PS : les confs :
XCSoar :
- LXNAV sur Bluetooth HC-06 > Connecté, Baro, Vario
J'ai essayé sans succes (Pas de données) Generic, BleFly Vario, FlyNet Vario, NMEA, OpenVario. Du coup je doute que l'on puisse avoir LXNAV et NMEA en même temps.

FlyMe :
-"BlueFly, Flynet, Other BT" affiche (LXWP0) (Connexion très très rapide et sans faille au Bluetooth)

Oui, je crois le fix doit être fait pour disposer de trames GPGGA et GPRMC correctes et complètes
Je crois avoir vu des trames GPGGA et GPRMC sans infos GPS lorsque le fix n'était pas fait ; je ne suis pas certain à 100% de cela, mais j'avais vu passer des trames bizarres avant le fix.

Sinon, je me comprends pas trop ce que tu appelles les trames NMEA ; toutes les trames transmises par le gnuVario sont des trames NMEA.
Pour ma part, avec XCSoar, l'utilisation du driver LXNAV permet de récupérer les infos GPS (trames GPGGA et GPRMC) et baro-vario (trames LXWP0)

[jpg63]

Ca serait bien de mesurer l'intensité maximale que tire le vario, l'intensité maximale que l'on peut obtenir du module de charge et l'intensité maximale que l'on peut tirer de la batterie ! Quelqu'un saurait-il faire ça ? Ou expliquer le montage à réaliser ?

Pour mesurer l'intensité, je pense que le plus simple c'est un petit capteur de courant

http://www.ewallpk.com/home/1142-max471-voltage-current-volt-amp-test-sensor-module-for-arduino.html

il y en a plein, le max741 fonctionne de 3v à 40v, à voir pour les autres modules
après on mesure la tension sur une entrée et avec une petite règle de 3 on en déduit le courant.

https://pdfserv.maximintegrated.com/en/ds/MAX471-MAX472.pdf

[ptitkiki]

Si personne ne l'a fait d'ici la, je pourrai faire des mesures précises début août, j'ai le matos au boulot.
Keep in touch...

[jpg63]

Si personne ne l'a fait d'ici la, je pourrai faire des mesures précises début août, j'ai le matos au boulot.
Keep in touch...

Il serait intéressant d'enregistrer simultanément la tension et le courant, et faire des mesures au repos et en fonctionnement - GPS, buzzer, BT,...

[prunkdump]

Salut à tous !

Bon ça y est je me suis enfin décidé à mettre un peu à jour la doc sur le GitHub  J'ai détaillé le README avec la nouvelle procédure et j'ai mis un schéma de montage (fait avec KiCad). Ca parait plus compliqué que ceux fait avec Fritzing mais c'est tout à fait lisible quand même.

@Finlard : Si tu veux un coup de main pour ta réparation tu peux me contacter directement par mail. Ca permettra d'échanger plus rapidement. Au pire tu pourra me renvoyer le circuit que j'y jette un oeil. Je suis sur que ce n'est pas très grâve. Mais ce n'est pas toujours évident de trouver le problème.

Un grand merci VMath54 et Xiboard pour vos retours !    Sans ça je ne pourrais jamais débugger le bluetooth. Vous semblez constater des choses similaires. A savoir une altitude baro relativement cohérente mais un vario qui affiche des résultats étranges. Xiboard vois tu une différence entre la version "high_freq" et ta version perso au niveau du résultat sur XCSoar ?

Je crois malheureusement qu'il va falloir se plonger dans le code de XCSoar ou alors les contacter pour comprendre comment leur logiciel fonctionne.

Je vais sous peu vous faire une version avec les trâmes LK8000 à la place de LXNav. Il semble de toute façon que ce soit obligatoire pour faire fonctionner XCTrack.

Je vais chercher avec vous pour la mesure de l'intensité.

A suivre !

[Xiboard]

A mon avis, on va pas échapper à LXNav ou LK8000 au choix au moment de la compilation.

Quand tu aura fait la version LK8000 je serai curieux de voir ce que ça va donner avec les trames GPGGA et GPRMC.

Je pense que XCSoar recalcule et filtre la valeur vario à partir de la valeur de l'alti. Et comme la valeur de l'alti est moins précise (combien de chiffres après la virgule ?) on a des 'saut'. C'est un peu dommage si c'est ça mais bon.

En fait je me reposait la question de l’intérêt d'avoir une valeur précise et réactive de la valeur du vario pour une appli : Calcul de la finesse, aide au centrage des thermiques (XCTrack et FlyMe indiquent sur une petite carte là où on a pris le dernier gros vario, il en déduit où peut être le thermique avec la dérive du vent calculé et l'altitude. Des fois ça marche étonnamment bien, surtout en plaine dans du petit)

Prunkdump : non pas constaté de diff majeure entre la highspeed et ma version. Ça doit sensiblement tourner à la même fréquence. En tout cas 5Hz je pense c'est bien. Je te dirai avec XCTrack.

[vmath54]

Salut à tous !

Bon ça y est je me suis enfin décidé à mettre un peu à jour la doc sur le GitHub  J'ai détaillé le README avec la nouvelle procédure et j'ai mis un schéma de montage (fait avec KiCad). Ca parait plus compliqué que ceux fait avec Fritzing mais c'est tout à fait lisible quand même.

Super ! Merci beaucoup.

Un grand merci VMath54 et Xiboard pour vos retours !    Sans ça je ne pourrais jamais débugger le bluetooth. Vous semblez constater des choses similaires. A savoir une altitude baro relativement cohérente mais un vario qui affiche des résultats étranges. Xiboard vois tu une différence entre la version "high_freq" et ta version perso au niveau du résultat sur XCSoar ?

Je crois malheureusement qu'il va falloir se plonger dans le code de XCSoar ou alors les contacter pour comprendre comment leur logiciel fonctionne.

Je crains que le problème soit du coté gnuVario (c'est bien comme cela qu'il faut le nommer ?).
J'ai refais un essai hier avec le firm high_freq ; il envoie 5 trames LXWP0 par secondes ; donc juste les infos baro, et de vario.

Ce coup ci, j'ai mis XCSoar en mode "debug" pour la partie NMEA recue ; pour les connaisseurs, c'est dans "Config - Periph" ; on n'active que "LXNAV sur bluetooth", et on sélectionne cette entrée.
On clique ensuite sur le bouton "Controle", et on voit les trames NMEA recues.

Je suis certain maintenant qu'il y a un décalage d'une décimale entre le vario affiché par le gnuVario, et les trames NMEA "LXWP0" transmises ; ceci entre -1m/s et + 1m/s.

Quand je vois sur le gnuVario un "+0.3" ou un "-0.5", la trame affichée dans la fenetre de debug de XCSoar (donc je suppose celle transmise) est de l'ordre de "0.03x" ou "-0.05x"
Après, une fois que l'on a dépassé le +1 ou le -1, l'info de vario semble cohérente.

Je vous joins le dernier fichier d'enregistrement NMEA de XCSoar ; brut ce coup ci.
Vous verrez des transitions de "0.09" à "1.x" régulièrement. Pareil en négatif.
Et je ne pense pas que l'on voie des infos de l'ordre de "O.3" ou "-0.5".


Par ailleurs, sur la partie BT :

actuellement, je crois que l'envoi de l'info BT se fait en même temps que l'enregistrement d'une trame IGC sur la SDcard.

Je pense que ce n'est pas une bonne chose, et qu'il faut dissocier.
  - IGC
    C'est qq chose qu'on consulte à postériori, pour une compét ou autre. L'intervalle entre 2 enregistrements n'a pas besoin d'être très court.
La valeur par défaut pour un FLARM (appareil anti-collusion imposé sur les planeurs en France, et qui sert pour la compet) est de 4 secondes. Pour XCSoar, c'est 5 secondes.

  - BT
    La, on envoie de l'info à une appli de navigation aérienne. Il faut être le plus rapide possible.

   

[jpg63]

Je pense que ce n'est pas une bonne chose, et qu'il faut dissocier.
  - IGC
    C'est qq chose qu'on consulte à postériori, pour une compét ou autre. L'intervalle entre 2 enregistrements n'a pas besoin d'être très court.
La valeur par défaut pour un FLARM (appareil anti-collusion imposé sur les planeurs en France, et qui sert pour la compet) est de 4 secondes. Pour XCSoar, c'est 5 secondes.
 

je suis pas tout à fait d'accord, beaucoup de vario enregistre toutes les 1sec, je pense que c'est une bonne valeur pour apprécier et revoir une trace après un vol  ou pour voir ton altitude max, vario max ....

[vmath54]

A mon avis, on va pas échapper à LXNav ou LK8000 au choix au moment de la compilation.

Quand tu aura fait la version LK8000 je serai curieux de voir ce que ça va donner avec les trames GPGGA et GPRMC.
...

Quels problèmes as-tu avec les trames GPGGA et GPRMC et le driver LXNAV sous XCSoar ?
Pour moi, ça fonctionne bien.

Es-tu certain que le fix du vario était fait au moment de l'essai ?
J'ai constaté que le gnuVario émettait des trames GPGGA et GPRMC sans coordonnées GPS tant que le fix n'était pas fait ; ce n'est pas cela le problème que tu as rencontré ?
Je crois que le fait d'émettre les trames GPGGA et GPRMC même sans les coordonnées GPS fait dire à XCSoar qu'il a des infos GPS (quand on consulte le 'device').

[vmath54]

en complément du post précédent :
Il serait préférable de ne pas émettre de trames GPGGA et GPRMC si elles ne sont pas porteuses de coordonnées GPS ...

[Xiboard]

A mon avis, on va pas échapper à LXNav ou LK8000 au choix au moment de la compilation.

Quand tu aura fait la version LK8000 je serai curieux de voir ce que ça va donner avec les trames GPGGA et GPRMC.
...

Quels problèmes as-tu avec les trames GPGGA et GPRMC et le driver LXNAV sous XCSoar ?
Pour moi, ça fonctionne bien.

Es-tu certain que le fix du vario était fait au moment de l'essai ?
J'ai constaté que le gnuVario émettait des trames GPGGA et GPRMC sans coordonnées GPS tant que le fix n'était pas fait ; ce n'est pas cela le problème que tu as rencontré ?
Je crois que le fait d'émettre les trames GPGGA et GPRMC même sans les coordonnées GPS fait dire à XCSoar qu'il a des infos GPS (quand on consulte le 'device').

Hello,

J'ai aucun pb, je dit juste que ça marche pas avec XCTrack et que je n'utilise pas XCSoar car il ne réponds pas à mes attentes (et je me demande vraiment qu'il l'utilise, j'ai encore vu personne autour de moi sauf 2 potes sur Kobo qui n'ont pas le choix et qui comprennent rien et ne l'utilisent pas du coup)

Sur le BT, je suis dans la même idée, limite plus radicale :
- Trames GPS > on en fait de l'IGC sur le SD pour de redondance de trace ou du vol rando light
- Trames BT > juste la donnée vario à haute fréquence.

En option envoyer aussi en BT la donnée GPS pour ceux qui n'utilisent pas une tablette ou smartphone avec GPS.
En option choix de trame BT en LK8000 ou LKNav.

C'est juste mon idée, faudrait voir si ça convient à tout le monde.

[vmath54]

...
J'ai refais un essai hier avec le firm high_freq ; il envoie 5 trames LXWP0 par secondes ; donc juste les infos baro, et de vario.

Ce coup ci, j'ai mis XCSoar en mode "debug" pour la partie NMEA recue ; pour les connaisseurs, c'est dans "Config - Periph" ; on n'active que "LXNAV sur bluetooth", et on sélectionne cette entrée.
On clique ensuite sur le bouton "Controle", et on voit les trames NMEA recues.

Je suis certain maintenant qu'il y a un décalage d'une décimale entre le vario affiché par le gnuVario, et les trames NMEA "LXWP0" transmises ; ceci entre -1m/s et + 1m/s.

Quand je vois sur le gnuVario un "+0.3" ou un "-0.5", la trame affichée dans la fenetre de debug de XCSoar (donc je suppose celle transmise) est de l'ordre de "0.03x" ou "-0.05x"
Après, une fois que l'on a dépassé le +1 ou le -1, l'info de vario semble cohérente.   

Je voulais creuser la chose, mais je n'ai pas eu le temps, et je vais m'absenter plusieurs jours.

Si quelqu'un veut faire le test, sans XCSoar :
Il existe une appli android gratos : Bluetooth Viewer Lite.
Elle permet de visualiser les trames bluetooth reçues ; c'est pratique pour débuguer du bluetooth.

[mike57]

J'ai aucun pb, je dit juste que ça marche pas avec XCTrack et que je n'utilise pas XCSoar car il ne réponds pas à mes attentes (et je me demande vraiment qu'il l'utilise, j'ai encore vu personne autour de moi sauf 2 potes sur Kobo qui n'ont pas le choix et qui comprennent rien et ne l'utilisent pas du coup)

 

Tu as essayé TopHat ? Plus facile en vol pour changer de page,surtout avec des gants.

http://www.tophatsoaring.org/Kobo.html

[nightrider]

Hello l'equipe,
Est-ce que vous savez pourquoi mes fichiers IGC du GnuVario ne sont pas compatibles avec XContest?
Il semble qu'il ne passe pas le validateur interne du site, les vols sont enregistrés, les traces sont correctes mais ne donnent aucun points...

[Xiboard]

Hello l'equipe,
Est-ce que vous savez pourquoi mes fichiers IGC du GnuVario ne sont pas compatibles avec XContest?
Il semble qu'il ne passe pas le validateur interne du site, les vols sont enregistrés, les traces sont correctes mais ne donnent aucun points...

C'est peut-être car il ne sont pas "signé FAI". C'est pas évident à faire. On en a parlé un moment dans le sujet.

[Van Hurlu]

Hello l'equipe,
Est-ce que vous savez pourquoi mes fichiers IGC du GnuVario ne sont pas compatibles avec XContest?
Il semble qu'il ne passe pas le validateur interne du site, les vols sont enregistrés, les traces sont correctes mais ne donnent aucun points...

C'est peut-être car il ne sont pas "signé FAI". C'est pas évident à faire. On en a parlé un moment dans le sujet.

j'avais essayé de faire valider une trace par Cargol, sans succès.
il faudrait vérifier ce point aussi.
on doit pouvoir contacter les dev de Cargol et leur demander d'inclure la signature du gnuvario ?

[jpg63]

Les fichiers IGC du Gnuvario ne sont pas signés, car comme on coupe l'alimentation on ne peut pas ajouter le checksum FAI à la fin. Je crois me souvenir, qu'avec gps visualisez
http://www.gpsvisualizer.com/gpsbabel/?lang=fr il est possible d'avoir la signature en convertissant le fichier IGC en IGC ou en passant par 2 conversions successives, je ne me souviens plus bien

Concernant l'évolution de notre petit vario, je suis en train de tester :

- un Arduino MKR Zero
          - pour l'instant la carte SD est ok, j'ai écrit une bibliothèque pour lire un fichier de config en TXT, bien pratique pour changer un paramètre sans compiler. La microSD gere
            la  fat32 plus besoin de formater en 2Go

          - Le MKR Zero peut être mise à jour depuis la carte SD sans rien ajouter à par une ligne au début du code - il cherche un fichier particulier et se met à jour

          - j'ai constater 2 petits soucis qu'il faudra gérer
                     - la microSD est pénible à élever comme toute les microSDs, il sera indispensable d'avoir un accès via l'USB
                     - le module de charge et d'alimentation intégré ne permet plus d'avoir un interrupteur entre le module de charge et l'arduino, il faudra mettre en place un système
                       d'interrupteur numérique pour couper l'alimentation des composants (j'attends une batterie avec un connecteur JST pour confirmation). De plus le courant
                       maximum de sortie sur le VCC est de 600mAH, sur la patte BAT (à confirmer) mais c'est pareil.

- L'écran 1.54' E-Ink

cet écran a un énorme potentiel, il est légèrement plus large que le nokia 5110. Il a une résolution de 200x200 ce qui permet beaucoup plus de possibilité d'affichage. Il y a juste un petit problème, le produit de chez Waveshare est ressent, la bibliothèque date du mois d'avril, elle est assez pauvre mais surtout totalement buggé.  Pas mal de boulot en perspective mais cela en vaux la chandelle. Sinon je regarde du coté d'une autre bibliothèque GxEPD

Si des volontaires sont motivés pour tester d'autres composants sur le M0 - gps, MS5611, ...., et m'aider à porter notre GnuVario sur M0, on serait pas trop de 3 ou 4 pour que le projet avance, sachant qu'en parallèle, il y a le nouveau kit qui va arriver et le BT a débbuger. 

[prunkdump]

Salut à tous 

Bon j'avance doucement mais sûrement. C'est l'été Même si le temps c'est pas trop ça 

Nouvelle version sur le GitHub :

J'ai mis à jour le code :
-> correction du bug dans la bibliothèque "Digit". Effectivement VMath54 avait raison    Il y avait bien un bug sur l'affichage des nombres de type "0,***"  avec une précision supérieure à 2. Le 0.52 devenait 0.052. J'ai corrigé le bug et les trâmes LXWP0 devraient être correctes maintenant.
-> Ajout du choix de type de trâme LXNav/LK8000 : dans VarioSettings on peut maintenant choisir entre les trâmes LXNav et LK8000. Il y donc donc une nouvelle bibliothèque "LK8Sentence".
-> Optimisation des librairies "Digit" et "GPSSentences" : J'ai optimisé ces deux libraires pour gagner un peu de place.

Reste plus qu'à tester

Debuggage du bluetooth :

Pour ceux qui sont motivé. Je vous joint les trois firmware "high_freq", "low_freq" et "low_freq_gps" maintenant basé sur les trâmes LK8000. J'espère que ça va passer avec XCTrack car j'envois toujours l'altitude et non la pression. Mais à priori c'est autorisé par les trâmes LK8EX1. Reste à savoir si XCTrack le supporte.

Pour les autres logiciel c'est à voir. Merci Mike57 pour l'info !

Pour la signature des trâces :

J'y comprends rien à cette histoire de signature ! Normalement les constructeurs doivent posséder des clefs privées qui permettent de signer leur trâces. Cela permet d'être sur que la trâce est bien une trâce "réelle" et de savoir par qui elle a été enregistrée. Mais si certain site signent leur trâce au moment de la convertion et que ces trâces sont accepté par les validateurs alors là je ne voit vraiement pas l'interêt de signer  A moins que ce soit juste pour vérifier que la trâce n'est pas corrompue 

 
Pour le passage au Cortex M0

Super Jpg63 pour tout ce travail !  Ah ouai le MKZero supporte déjà le chargement des firmware par la carte SD !? C'est super ça ! Tu pourrais nous envoyer le lien vers la doc ?

Pour l'écran je pense qu'il est possible d'adapter directement la bibliothèque varioscreen. Il suffit de changer les commandes et la procédure d'initialisation.

A suivre !