DIY GnuVario : variomètre opensource - openhardware Arduino

[jpg63]

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 !

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/

[prunkdump]

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

Ca à l'air pas mal du tout ! 

Quelques photos :

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

[Jérémie LeCouvert]

Du beau boulot !!!

Tu les fais faire où ?

[nightrider]

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  

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?   

[Jérémie LeCouvert]

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  

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?    

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

[jpg63]

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

Ca à l'air pas mal du tout ! 

Quelques photos :

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

Très joli

[gargle]

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

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 )

[Van Hurlu]

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

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 )

Pourquoi faire simple quand on peut faire compliquer 


@Gargle   

[Jérémie LeCouvert]

Pourquoi faire simple quand on peut faire compliquer 

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 !

[prunkdump]

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+

[Jérémie LeCouvert]

Si tout est cohérent il devrait être impossible de valider FAI un vario opensource.

Ah ça je n'ai pas dit le contraire !

[Man's]

Pourtant, XCSoar est open source et fournit bien des fichiers valides FAI, non ?

(au fait, super intéressant votre projet ! )

[jpg63]

Je pense que le plus simple serait de faire une demande d'une clef privée et voir si on obtient une reponse favorable

[jpg63]

Pour ceux qui utilisent mon code, voici une nouvelle version intégrant les dernières modifications de Prunkdump

bon vol à tous

[gargle]

Je pense que le plus simple serait de faire une demande d'une clef privée et voir si on obtient une reponse favorable

voila ce que dit la FAI a propos du open source :

Code:

Developer: Some comments on Open source.
If you consider to generate open source project, think about the type of open source license before publishing.
GPL might not be the best choice as it disallow your code to be included within other nice projects when they are not licensed the same way.
There are many other valid open source licenses (for example CDDL) which allow mixed licensing, even closed source parts.
National contests might easy able disallow your Opensource software. In result pilots flight might not scored at WXC as well.

You may ask yourself, what happen if my key to encrypt is public available as Open Source ?
The answer on this is easy. You as a developer, made a wrong decision. GPL or CDDL doesn't mean, you have to publish your own used keys or passwords. You will simply still GPL the code, but simply obfuscate the key itself on the public repository. You may just write a README, how to use and compile the code, which will include the step to create a new private key.

c'est possible, en gardant une branche binaire compilé par un "chef de projet" qui garde les clés, et pour ceux qui veulent modifier, ils peuvent créer une autre clé.

qqun prends la main sur le projet ? prunkdump ou jpg63, vous qui compilez en général
mon mail : raynaudp@gmail.com pour la suite

[jpg63]

Je pense que le plus simple serait de faire une demande d'une clef privée et voir si on obtient une reponse favorable

voila ce que dit la FAI a propos du open source :

Code:

Developer: Some comments on Open source.
If you consider to generate open source project, think about the type of open source license before publishing.
GPL might not be the best choice as it disallow your code to be included within other nice projects when they are not licensed the same way.
There are many other valid open source licenses (for example CDDL) which allow mixed licensing, even closed source parts.
National contests might easy able disallow your Opensource software. In result pilots flight might not scored at WXC as well.

You may ask yourself, what happen if my key to encrypt is public available as Open Source ?
The answer on this is easy. You as a developer, made a wrong decision. GPL or CDDL doesn't mean, you have to publish your own used keys or passwords. You will simply still GPL the code, but simply obfuscate the key itself on the public repository. You may just write a README, how to use and compile the code, which will include the step to create a new private key.

c'est possible, en gardant une branche binaire compilé par un "chef de projet" qui garde les clés, et pour ceux qui veulent modifier, ils peuvent créer une autre clé.

qqun prends la main sur le projet ? prunkdump ou jpg63, vous qui compilez en général
mon mail : raynaudp@gmail.com pour la suite

C'est vraiment super que tu ai déjà travailler sur le sujet, c'est un vrai atout pour notre petit vario qui pourra devenir compatible FAI par contre, Je ne sais pas comment faire pour avoir une partie compiler dans le code avec un arduino mais on va trouver
On doit revoir aussi totalement le système d'alimentation ou de de fin de vol pour pouvoir ajouter le checksum à la fin du fichier IGC

je vois 2 possibilités
       -  la détection automatique de la fin de vol - plus de vitesse, plus de changement d'altitude pendant un certain temps - c'est toujours problématique car  comment différencier un vol face au vent ou tu n'avance pas à plus de 6km/h d'un attero - il nous faudrait une sonde pito et la j'ouvre l'idée d'une super amélioration - l'ajout d'une sonde de vitesse air à notre gnuvario - électroniquement, cela existe pour les modèles réduits après c'est comment fixer le pito - avec une telle sonde la porte est ouverte à de nombreuses amélioration vitesse du vent instantané (vitesse GPS - vitesse air) alarme de sous vitesse, calcul pour l'optimisation du vol, détection de posé
       - la modification de l'arrêt et du démarrage du gnuvario - plus simple dans un premier temps
                l'idée, serait de concevoir un circuit qui permet de retarder la coupure d'alimentation
                                    - si l'interrupteur ou un poussoir ne coupe pas directement l'alimentation mais passe une entrée numérique à 1, l'arduino pourrait détecter que l'on souhaite l’éteindre, il lancerait l'arrêt du vol, l'écriture du checksum du fichier IGC et l'affichage des stats de vol (qui resterait afficher après coupure de l'alimentation - écran E-Ink) puis l'arduino lancerait l'arrêt de l'alimentation des différents composants. Dans ce principe de fonctionnement l'arduino reste toujours alimenté car c'est aussi grâce à lui que l'on rallume le tout - action sur poussoir, détection par l'arduino, allumage des circuit annexe -

inconvénient de l'option 2, la batterie se vide même si on vole pas par contre on peut détecter des commandes sur l'usb - accès à la SD via la liaison série le vario éteint

Tout est possible pour la prochaine version avec le M0 

[gargle]

pour l'inclusion a la compilation, en fait, il suffit de faire un include .H de la clé privée et ne pas le mettre sur le github. Ou mettre le fichier mais vide.
Comme ca, vous 2 (prunkdump et toi) compilez avec la bonne clé, valide pour la FAI, et les autres qui voudraient le compiler doivent faire leur propre demande.
Il faudra juste penser a mettre le binaire compilé sur github en le spécifiant comme validé FAI pour les personnes qui veulent.

Pour la fin du fichier, effectivement, il faut pouvoir écrire après la demande d'extinction ou d’arrêt auto.
Pour la version M0 (ou autre), l'idée est de d'utiliser l'enable du régulateur de tension piloté par un bouton poussoir pour allumer/éteindre et par une patte du microcontroleur qui fait le maintient. Quand tu demandes une extinction, le programme cloture tout et relâche la patte enable du régulateur, qui consomme plus rien ensuite.

Sinon, pour l’arrêt automatique, tu peux utiliser : 30s en dessous de 5km/h et moins de 0.1m/s en plus ou en moins. la vitesse et la différence de hauteur permette d'éviter les fausse détections.

Et juste pour info, j'ai découvert les nucleo de ST qui ont le meme form factor que les arduino nano, mais X fois plus puissant, pour quasi le meme prix . Par contre, pas d’environnement arduino mais ca peut etre ca : https://developer.mbed.org/

[jpg63]

pour l'inclusion a la compilation, en fait, il suffit de faire un include .H de la clé privée et ne pas le mettre sur le github. Ou mettre le fichier mais vide.
Comme ca, vous 2 (prunkdump et toi) compilez avec la bonne clé, valide pour la FAI, et les autres qui voudraient le compiler doivent faire leur propre demande.
Il faudra juste penser a mettre le binaire compilé sur github en le spécifiant comme validé FAI pour les personnes qui veulent.

Pour la fin du fichier, effectivement, il faut pouvoir écrire après la demande d'extinction ou d’arrêt auto.
Pour la version M0 (ou autre), l'idée est de d'utiliser l'enable du régulateur de tension piloté par un bouton poussoir pour allumer/éteindre et par une patte du microcontroleur qui fait le maintient. Quand tu demandes une extinction, le programme cloture tout et relâche la patte enable du régulateur, qui consomme plus rien ensuite.

Sinon, pour l’arrêt automatique, tu peux utiliser : 30s en dessous de 5km/h et moins de 0.1m/s en plus ou en moins. la vitesse et la différence de hauteur permette d'éviter les fausse détections.

Et juste pour info, j'ai découvert les nucleo de ST qui ont le meme form factor que les arduino nano, mais X fois plus puissant, pour quasi le meme prix . Par contre, pas d’environnement arduino mais ca peut etre ca : https://developer.mbed.org/

Il y a vraiment des boards sympa. En fait l'avantage du MKZ Zero ou son équivalent, c'est de pouvoir facilement porter le code existant qui fonctionne déjà

je regarde comment fonctionne la patte Enable super merci

pour le capteur MS5611 j'ai trouvé ce tuto qui devrait nous aider à porter les interruption du I2C

https://www.hackster.io/45374/mkr-fox-1200-movement-trigger-dacbe0?utm_source=Hackster.io+newsletter&utm_campaign=d202c0b11d-EMAIL_CAMPAIGN_2017_07_26&utm_medium=email&utm_term=0_6ff81e3e5b-d202c0b11d-141265338&mc_cid=d202c0b11d&mc_eid=4842b09282

Coté écran E-Ink, je suis en train de modifier la bibliothèque varioscreen mais en parallèle, j'ai contacté le développeur de la bibliothèque GxEPD, qui va la rendre compatible avec le M0+. Gros avantage de cette bibliothèque c'est quelle reprend les bibliothèques d'affichage adafruit est les rends compatible avec de nombreux écran E-Ink. En réécrivant toute la partie affichage, on pourrait rendre très facilement compatible le GnuVario avec tout type d'écran E-ink, LCD, O-Led sans avoir besoin de réécrire 1 ligne. Autre avantage la gestion du graphique et la possibilité d'avoir du texte alpha-numérique (table ascii complète) en plusieurs taille de font. Inconvénient la taille de la bibliothèque. Perso je pense que avec la place disponible, 256ko du M0+, cet inconvénient est très très minime par rapport aux avantages. De plus on garderait la gestion du multi écran et l'architecture de la bibliothèque varioscreen     

[Xiboard]

Hello

Vous vous emportez pas un peu avec la signature FAI ? J'veux dire par là, qui à envie de scorer en FAI avec le GNUVario ? (C'est une vrai question ouverte, hein)
Psk, la CFD ok, mais FAI, je pige pas trop.
Bon, après bien sûr si c'est pas ultra galère et que ça nous demande pas une énergie folle, pourquoi pas.

J'ai tout de même aussi des craintes sur la lourdeur du code pour générer le MD5 encodé. En tout cas avec la V1 ou V2 actuelle, avec le MKRZero peut-être non ?


La détection de l'atterrissage est très complexe, surtout en soaring. J'ai fait un vol de 28km aller/retour tout en soaring à 5-20m/sol dans du 26-34 km/h. Je crois que j'avais mis XCTrack ce jour là, il n'a pas arrêté de dire atteri, décolé, atteri, décolé... En effet des moment j'étais assez scotché et ni vario, ni vitesse ne bougeaient. Ce qui est bien c'est que XCTrack reprends le vol (il doit surement il y a voir un délais entre atteri et décolé et posi GPS). J'avais des petits trous dans la trace mais seulement de qq secondes.

[jpg63]

en arrêtant le vol avec un poussoir - Marche/Arrêt on évite de se torturer l’esprit avec un arrêt de vol automatique qui finira par être une usine à gaz, enfin c'est mon avis

La plupart des varios du commerce on des poussoirs, je pense que c'est en grande partie pour avoir le contrôle de l'arrêt et pouvoir fermer les fichiers

l'idée de la patte Enable me semble bien, j'ai juste une question, si on met à 0 la patte EN cela coupe juste la patte 3.3v ou aussi l'arduino ?

je veux bien un petit schema gargle. Il faut une patte de l'arduino pour détecter l'appuie sur le poussoir ?

[jpg63]

il semblerait que l'on peut mettre le M0 en sommeil

https://forum.arduino.cc/index.php?topic=337289.0

https://github.com/arduino/ArduinoCore-samd/issues/142

avec un poussoir ON/OFF, la pin EN c'est peut être la nouvelle solution d'alimentation de notre future vario. On pourra éventuellement compléter le tour avec un système d'alimentation piloté pour apporter le courant suffisant - on aura que 500mA sur la patte 3.3V


Ps : http://playground.arduino.cc/Learning/ArduinoSleepCode

 

[jpg63]

Enfin j'ai pu voler après 10 jours de mauvais temps

pour analyse, je vous mets  un petit vol

j'avais un sysride nav sur un élévateur et le gnuvario sur l'autre

Les nouveaux réglages me paraissent pas mal, les 2 varios bipaient presque de concert

Quelques fois le syride était en avance mais à d'autre moment c'était le gnuvario. Je n'ai pas trouver les bips trop agressif, mais l'après midi n'était pas fumante, du +4 max instantané   

[vmath54]

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

Premier test cet après-midi ; avec XCSoar, en voiture.
Avec le dernier code du github, en désactivant le GPS, et en choisissant les trames LXNav.

C'est tout bon maintenant. Les trames LXWP0 sont identiques à l'affichage du gnuvario, sur la plage testée : entre -1.5 et +1.5 m/s.
XCSoar affiche des choses cohérentes avec cela.

Merci pour la correction ...

[prunkdump]

Super ! Un grand merci pour le debug  le problème n'était pas si évident à voir. Tu vas bientôt pouvoir emmener le vario en vol avec la tablette

Reste plus qu'a tester avec XCTrack avec les trames LK8000 maintenant. Il y aurait pas un volontaire pour me tester ça ?   

À+

[Xiboard]

J'étais pas dispo mais je pense pouvoir regarder ça ce soir.