DIY GnuVario : variomètre opensource - openhardware Arduino

Salut à tous :coucou:

Content de te retrouver Vmath54 :trinq: Je savais bien que tu étais encore dans les parages ! Jpg63 est toujours très interessé pour te faire ta sonde de vitesse :wink:

Pour la nouvelle bibliothèque ToneAC (Low Power) :

C’est bon j’ai publié la nouvelle bibliothèque toneAC qui utilise trois phases pour diminuer la consommation :

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

Si vous voulez tester directement, je vous ais mis deux firmwares pour les deux versions du vario (V1(vert) ou V2(orange)). Ptitkiki si tu as un petit moment pour mesurer la différence de consommation ça serai très intéressant ! :wink:

@Olitask :

En fait avec le mode LxNav les trâmes que tu dois voir sont des trâmes “$LXWP0”. Regardes dans les logs.

C’est peut-être normal que le vario bippe quand tu le soulèves mais pas la tablette. Car les infos du vario sont envoyés à la tablette que toutes les deux secondes. L’idée c’est de garder le vario pour le “son” et XCSoar pour l’affichage. Et dans ce cas un rafraîchissement toutes les 2 secondes est suffisant.

Mais c’est en projet d’augmenter la fréquence des trâmes vario :smiley:

A+

super, pour la sonde de vitesse :dent:

Et tu as raison, je me suis planté ; c’est bien les trames LXWP0 qu’on doit avoir, en plus des trames GPRMC et GPGGA

J’avais fait un essai avec les trames LK8000, et je n’étais pas revenu en arrière :expressionless:

Je ne comprends pas l’intérêt de maintenir en // les deux versions
avec les deux versions de gnuvario, ça fait 4 versions de code

La version de JPG63 est ma préférée pour l’organisation de l’affichage
Dommage qu’on n’arrive pas à convaincre Prunkdump de se rallier à cette présentation
:coucou:

Ha mince ! je voulais pas passer pour un tétu :smiley:

En fait le problème c’est surtout qu’on est très juste au niveau de la mémoire pour les versions du GnuVario avec Atmega328P ( la v1 et la v2).

Et comme Jpg63 a plein d’idées :stuck_out_tongue: et qu’il veut vite expérimenter. Il rajoute de nombreuses fonctionnalités au code de base au détriment malheureusement de la mémoire. Mais mon objectif est bien d’intégrer toutes les améliorations de jpg63 dans la version “master”. Mais il faut que je prenne le temps de bien relire le code et de l’optimiser au maximum et de m’assurer qu’il est bien portable (en cas de changement de microcontrolleur).

Pour la gestion de l’écran. A l’avenir tout le monde pourra mettre les infos qu’il veut, à l’endroit où il veut, et en créant ou pas autant de “pages” qu’il veut.

Mais je voudrais absolument garder de la place pour deux fonctionnalités :
-> L’affichage de la vitesse du vent.
-> La possibilité de contrôler le vario en “tappant” dessus.
-> l’affichage du compas (moins primordial).

Pas d’inquiétude dans tous les cas. Les “correctifs” sont intégrés de toutes façon à la version de jpg63. Il suffit de la retélécharger ici :

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

En choisissant la branche “jpg63-version” et en conservant son “VarioSetting.h” à chaque fois.

Voilà ! Mais c’est vrai que je suis un peu psychorigide par moment :mrgreen:

A+

psychorigide ou pas, tu as toute mon admiration pour ton travail
https://imgfast.net/users/2512/45/46/19/smiles/7323.gif

tout pareil :+1: :+1:

Sinon je viens d’essayer le dernier firmware ( LPtoneAC ) et bien le son est moins agressif ( c’est + agréable ) et j’ai a nouveau les trames GPS+vario+baro dans XCsoar ( les mystères de l’informatique :grat: ). Concernant le démarrage sans carte SD c’est status quo, il me faut enlever la carte pour démarrer le vario. Est ce que ce firmware embarque les modificatifs sur sur le port SPI dont tu ( Prunkdump) parlais hier (post de 19h30) ( j’ai pas pris le temps de le tester) ?

Olivier

Merci.

Alors Olivier je pense qu’en fait ton problème ne viens pas du SPI. Ni de la carte SD en fait :smiley: Si si … :wink:

C’est que la carte arduino démarre avant le baromètre. Ca arrive selon les condensateurs utilisés dans les alimentations. Du coup :
-> Quand tu met la carte SD le vario est content de suite et passe à l’initialisation du baromètre. Qui plante… parcequ’il n’est pas encore suffisamment alimenté.
-> Quand tu met pas la carte SD, le vario prend un petit moment pour vérifier qu’elle n’est vraiment pas là. Du coup ça laisse le temps au baromètre d’être bien alimenté et du coup ça marche.

On pourrais donc mettre un délai à l’allumage du vario. Mais c’est dommage.

J’ai fais plutôt un essai avec un petit bout de code qui teste si le baromètre a bien démarré.

Dis moi si ça marche avec ce nouveau firmware (pour vario V2).

A+

Je reviens d’une balade à vélo, le vario enregistre bien sur la SD. Je viens de tester ce dernier firmware et la il n’y a plus de son ni d’image. Il n’y a plus non plus les 3 bip pour recharger un firmware :affraid:
Je suppose qu’il va me falloir passer par la case FTDI ? ( pas de problème avec le gps sur le port série ? )

Edit : resolu en court-circuitant le reset

Olivier

Vraiment désolé Olivier ! :oops:

Faut que j’arrêtes de faire débugger mes codes par les autres :smiley:

Bon en attendant tu peux faire la méthode du delay().
-> Tu prends le code de jpg63 ou le mien.
-> Tu met un “delay(1000);” juste au début de la fonction setup.
Comme ça ton vario mettra une seconde de plus à démarrer mais tu n’auras plus le problème de la carte SD je pense.

En attendant je vais chercher pourquoi le code que je t’ai envoyé ne marche pas…

A+

Salut

Ne vous inquiétez pas, on passe toujours par des versions Beta avant d’aboutir à un code optimisé et sans bug. Il faut voir ma version comme une version Beta et celle de Prumkdump comme la version finale.
Effectivement comme le précise Prumkdump, j’intègre l’ensemble des optimisations de la version master et Prumkdump optimise et intègre mes options. Avec le temps on finira par avoir un code master identique à la version jpg63 mais optimisé. Vous avez le choix. En fait on a que 2 codes, car entre les 2 versions à base de promini ne diffère que par l’inversion des pins de l’écran pour le reste tout est identique

Je viens de publier une version 63.4 qui ajoute la nouvelle gestion du SPI et du son en 3 niveaux. Si vous aimez ma version n’hésitez pas a la récupérer sur la nouvelle branche du github que viens de nous créer Prumkdump

Vous trouverez aussi une branche jpg63-M0 version, je publierai très bientôt la première version pour M0, il me reste l’intégration de l’alimentation et un gros bug à résoudre sur la gestion du dmp (mpu9250)

Bravo à vous deux : prunkdump et jpg63

Cette explication était utile ; je me demandais aussi pourquoi maintenir 2 versions légèrement différentes.

Et je n’avais pas vu que la version jgp63 était une branche du même dépot git.

C’est beaucoup plus clair maintenant, et félicitations pour le taf.

J’ai essayé les 2 versions disponibles sur github. Je rencontre des warning lors de la compilation du code dans les 2 cas. Il faut bien supprimer les librairies installées par IDE et mettre celles du projet ?
Ne s’agissant que de warnings, un code est quand même généré. Pas de soucis pour mettre à jour le vario. J’ai remis le code de Baptiste en pensant retrouver le comportement observé à la mise en route initiale, ce qui n’ai pas le cas: bips montée de sonorité différente, et surtout plus d’affiche des infos GPS , l’heure réelle est remplacée par 02:00:00. Je constate le même problème avec la version jpg63, peut-être est-ce dû au erreur de compilation ?

Salut François !

Tu compiles pas pour la bonne board ! C’est (dans outils) :
-> Arduino Pro ou Pro mini
-> atmega328P, 3.3v, 8Mhz

Pour les warnings tu peux nous les copier-coller ici si tu veux :wink:

Ça y est en plus on peut commencer a bien revoler :twisted: !!! Va falloir tester tout ça :wink:

[quote=“francoish,post:1132,topic:62718”]
Si il n’y a pas de réception satellite l’heure est 00:00:00 +2h de décalage horaire d’été

@Prunky
au fait quand on va passer à l’heure d’hiver, il faudra changer le code ? ou ça se passe tout seul ??

Salut VanHurlu :coucou:

Ouai comme le GPS ne change pas d’heure le vario non plus…

Mais ca serai très facile à programmer vu qu’on récupère la date au début du programme :slight_smile:

Ce qu’il me gène plus c’est que c’est vraiment spécifique à certains pays. Certain ne vont pas comprendre à quoi ça sert :?

Mais je vais quand même jetter un œil par curiosité :smiley:

À+

sur tous les vario-gps que j’ai eu il y a une fonction décalage UTC.
Donc ne t’inquiète pas, les pilotes sont habitués à cette fonction.
Sauf ceux qui volent uniquement sur le méridien de Greenwich bien sur :roll:

En fait je voulais dire : la modification automatique de l’heure en fonction de la date. Pour les pays qui ont heure d’été et heure d’hivers.

Ça tu l’as sur tes vario-GPS ?

Il me semble que sur mon Skytraxx le changement heure d’été et heure d’hiver est automatique ?
Sur le Reversal il me semble que non ? (ça date un peu)
Je ne suis plus sur de rien, si qq un peut confirmer.

Je mêle mon grain de sel car je suis passionnément votre développement. Logfly me prenant mon temps libre, je n’ai malheureusement pas le temps de m’investir dans ce projet mais ça me démange…

Ce que veut dire VHdB ( :coucou: au passage) c’est que la plupart des GPS ont une fonction permettant de paramètrer le décalage en cours. Plus deux heures ou plus une heure en France. Mais c’est à l’utilisateur de donner le bon décalage. Le soft du GPS va simplement se servir de ce paramètre pour calculer son affichage. Si vous décidez de le faire, ne pas oublier de prévoir un double pour le décalage car il y a des régions du monde où le décalage comprendra une demi heure (je ne sais plus trop où). Si l’utilisation d’un single est préférable, demander le décalage en minutes.

Dans tous les cas, l’heure doit être enregistrée en UTC dans le fichier IGC.

Le calcul automatique du décalage plus l’offset été/hiver en fonction du lieu me parait difficilement envisageable avec le soft du GPS. Je le fais dans Logfly, cela prends pas mal de lignes et implique d’embarquer un fichier contenant les zones géographiques. A ma connaissance, aucun GPS ne le propose.

:coucou: Giloutho

Yes, ma mémoire commence à dérailler
effectivement, je n’ai pas de problème pour mes traces, car Logfly le fait tout seul
et chaque année je recale l’heure du GPS, car je me rends compte que l’heure affichée en vol n’est plus bonne.

En général il me faut 2 à 3 vols pour que je m’en rende compte :bu: