Ah ça je n’ai pas dit le contraire !
DIY GnuVario : variomètre opensource - openhardware Arduino
Pourtant, XCSoar est open source et fournit bien des fichiers valides FAI, non ?
(au fait, super intéressant votre projet ! 
)
Je pense que le plus simple serait de faire une demande d’une clef privée et voir si on obtient une reponse favorable
Pour ceux qui utilisent mon code, voici une nouvelle version intégrant les dernières modifications de Prunkdump
bon vol à tous
voila ce que dit la FAI a propos du open source :
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
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
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
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.
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 ?
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
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é
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 …
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 ? 
À+
J’étais pas dispo mais je pense pouvoir regarder ça ce soir. 
J’ai essayé XCtrack avec le dernier FIRM de JPG
qui normalement a intégré tes modifs
toujours un décalage sur l’altitude ??? du coup j’ai pas fait de trace
remarques :
tant que le 3 barres ne sont pas atteinte la vitesse sol varie beaucoup sur le gnu et XCtrack affiche exactement la même valeur avec 1/100sec de décallage
voir la photo
Le bug découvert n’est pas corrigé dans mon code ? j’ai peu être fait une erreur, ou c’est un autre problème. Tu as la même chose avec le code présent sur le github ? Tiens moi au courant, je reprendrais mon code si j’ai oublier quelque chose
Pareil avec le code sur Github
[quote]Reste plus qu’a tester avec XCTrack avec les trames LK8000 maintenant.
[/quote]
par contre ça j’ai pas vu, c’est ou ?
Moi aucun de tous ces code ne fonctionne ! En regardant les trames transmises au mieux j’ai eu des “…”
Je vais voir pour repartir du code et compiler.
Si tu as un smartphone ou une tablette android ; T’as essayé de voir avec “bluetooth viewer” si tu recois des infos depuis bluetooth ?