DIY GnuVario : variomètre opensource - openhardware Arduino

#941

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

#942

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 …

#943

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.

#944

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.

#945

:coucou:

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

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

#946

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…

#947

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.

#948

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 ?

#949

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.

#950

Salut à tous :coucou:

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

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

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 ! :grat: 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 :shock: A moins que ce soit juste pour vérifier que la trâce n’est pas corrompue :grat:

Pour le passage au Cortex M0

Super Jpg63 pour tout ce travail ! :pouce: Ah ouai le MKZero supporte déjà le chargement des firmware par la carte SD !? :shock: 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 !

#951

pour la mise à jour via la SD

https://www.hackster.io/Arduino_Genuino/sd-sketch-update-534404?ref=part&ref_id=33247&offset=0

je vais regarder pour la bibliothèque varioscreen, il faudra malgrès tout, l’adapter à la résolution, doubler je pense tout l’affichage pour rester lisible
la bibliothèque waveshare est remplie de delais de 1,5sec, je pense que tout ça peut être améliorer, mais l’écran fonctionne avec le M0, c’est une très bonne chose

pour le son, je vais tester cette option

https://www.arduino.cc/en/Tutorial/I2SSimpleTone
https://learn.adafruit.com/adafruit-max98357-i2s-class-d-mono-amp
https://github.com/adafruit/Adafruit_ZeroI2S/blob/master/examples/tone_generator/tone_generator.ino

j’ai déjà commander le MAX98357A

pour la tension de la batterie

https://create.arduino.cc/projecthub/Arduino_Genuino/mkrzero-read-battery-voltage-4853ac

pour info

https://learn.adafruit.com/adafruit-feather-m0-basic-proto/adapting-sketches-to-m0

et une idée pour couper l’alimentation
https://www.adafruit.com/search?q=p-channel&b=1
https://makerself.wordpress.com/2014/12/23/power-circuit-redesigned/

#952

Ca y est ! Les PCBs du nouveau kit sont arrivés :smiley:

Ca à l’air pas mal du tout ! :jump:

Quelques photos :

https://photos.app.goo.gl/lkszv2tHbp0Gvues2

#953

Du beau boulot !!!

Tu les fais faire où ?

#954

J’ai trouvé ça sur le sujet http://www.gliding.ch/images/news/lx20/fichiers_igc.htm) et particulièrement les points 3.1 et 3.2
Si j’ai bien compris le premier contrôle est l’identification de l’appareil, genre numéro de série du GnuVario et le deuxième vérifie l’intégrité des données. Cette vérification doit être faite par l’appareil qui génère ces données et non par celui qui les recoit…
Est-ce que vous avez une idée de comment cela peut se coder? :grat:

#955

Un document plus récent : http://www.fai.org/gnss-recording-devices/igc-approved-flight-recorders

Ca n’est pas si simple, il faut faire approuver l’appareil par le président de la GFAC (GNSS Flight recorder Approval Committee) pour obtenir un numéro de fabriquant autorisé.

#956

Très joli

#957

C’est bien ca, il faut prendre contact avec la FAI (il y a un forum pour ca), et demander une inscription de nouveau fabricant, avec un code d’identification unique.
Ensuite, il faut générer une clé privée et une clé publique. La privée doit rester secrete. Elle sera archivée et dispo au moins de monde possible (peu compatible avec du boulot GPL). L’idée est de faire une librairie compilée pour la “camoufler”.
En parallèle, il faut fournir a la FAI un programme en ligne de commande qui tester l’IGC et vérifie que qu’il a pas été modifié, ainsi que des fichiers IGC fait a partir du vario.
Eux vont tester que un fichier valide passe les tests, et un fichier modifié ne les passe pas. Ensuite, ils valident et les IGC sont désormais reconnus par la FAI.

La clé d’encodage est une chaîne qui commence par la lettre G dans l’IGC
pour l’obtenir, il faut faire un MD5 du fichier IGC en excluant certaines parties de l’entête. Ensuite, ce MD5 doit être encrypté en utilisant la clé publique avec un protocole sécurisé genre SHA256.

tout est expliqué dans le document, et si vous avez des questions plus précises, demandez moi directement, j’ai déjà fait ca :wink: )

#958

Pourquoi faire simple quand on peut faire compliquer :canape:

@Gargle :trinq: karma+

#959

En réalité c’est assez simple et c’est surtout nécessaire. Etant donné que les résultats de compétition sont entièrement basés sur des traces GPS, il est bien entendu nécessaire de s’assurer qu’il est impossible de les modifier manuellement !

#960

Salut !

Ouai pour moi il reste un truc pas clair … :?

  1. Si on obtient une clef privée pour le GnuVario et qu’on la cache dans une bibliothèque qui permet de faire le hashage des trâces IGC. Cette bibliothèque permet quand même à n’importe qui d’encoder son fichier IGC avec la clef privé par l’intermédiaire de la bibliothèque. Et notamment de motifier le fichier IGC avant. Du coup je vois pas l’intérêt.

  2. Si certain sites de conversion de trâce optiennent des clefs privées, et qu’à partir de trâces sans hashage ils convertissent le fichier en un fichier signé, cela permet à n’importe qui d’obtenir un fichier signé avec une fausse trâce.

Si tout est cohérent il devrait être impossible de valider FAI un vario opensource. Je crois même que sur les vario validé il doit y avoir un systême qui détruit la clef privé en cas d’ouverture du boîtier non ?

A+