DIY GnuVario : variomètre opensource - openhardware Arduino

On pourrait peut être avoir les 2 possibilités

Module BT - si ça marche avec un filtre à chaque fois on pourrait peut être intégré la résistance et la capa sur le pcb et n’avoir que 2 fils

Et

Usb, en mettant un micro usb sur le pcb et en utilisant un module de charge sans usb

On pourrait aussi utiliser le connecteur pour lire directement la carte SD :dent:

Si on pouvait supprimer les fils soudés de la batterie en utilisant les petits connecteurs jst (le petit connecteur rouge que j’utilise comme interrupteur) et 2 pins soudées sur le pcb, ce serait plus pratique, je ne me souviens plus le nombre de fois que j’ai ressoudé la batterie avec en plus le risque de cours circuit

La connectique de l’écran est un point noir, l’ouverture répété du boitier conduit à des faux contacts qui se termine par des soudures en directe, l’idée est très bien mais les cosses sont un peu longue et du coup gène pour fermer ou pour glisser la batterie

peut être que l’on pourrait utiliser une connectique B6B-XH-A ou JST XHP (les petits connecteurs blanc des carte mère de PC) pour relier la nappe au PCB, coté écran c’est parfait

Je doute que si tu te mets une tablette sur un cockpit tu mettes encore ton gps dans l’élévateur :roll:
c’est plus facile d’avoir tous tes instruments sur un scratch qui se colle sur ton cockpit
Tu ne regarderas plus le gps, mais la tablette ou tu auras plus d’info

Là encore une analyse de la valeur serait intéressante :roll:
Quelle est l’intérêt d’avoir encore une carte SD amovible, si on a une liaison USB ??
Ne peut-on pas mettre juste un composant de mémoire ? Excusez mon ignorance si ce n’est pas possible.
Plus besoin de fente pour rentrer et sortir la carte (montage plus facile) plus de pièces mécaniques qui bougent (lecteur de carte) => moins de possibilités de panne

Dans mon idée, le gnuvario doit rester quelque chose de simple, à comprendre et à fabriquer.

De tous les écrans possibles pour utiliser le gnuvario comme gps externe pour une tablette et un soft de compète,
celui qui me semble le plus chouette est la Kobomini (pas cher et parfaitement lisible).
Cette Kobomini n’a pas de Bluetooth, du coup la connexion USB est indispensable.
Le seul inconvénient de cette Kobo c’est qu’on ne peut pas faire tourner XCtrack, seulement XCsoar
Mais je ne connais pas de tablette Androïd avec une aussi bonne lecture en plein soleil que les Kobo.

Je ne veux pas faire mon emmerdeur, si le BT est dans la boite et qu’il peut se désactiver pour gagner en conso et en parasite sur l’antenne gps, cela me conviendra
… à condition d’avoir une liaison usb :mrgreen:

Je suis très satisfait de mon gnuvario tel qu’il fonctionne actuellement.
Je trouve que le problème essentiel aujourd’hui est de gagner en autonomie
Soit en mettant une batterie plus grosse, soit en limitant la conso, soit en faisant les 2 à la fois.

J’ai oublié de vous rapporter une bizarrerie que j’ai constatée.
en utilisant mon téléphone sous XCTrack connecté en BT
j’ai constaté que l’altitude affichée par XCtrack est supérieure (50m environ) à la valeur affichée sur le gnuvario ???
Si quelqu’un trouve une explication ???
Je précise que en vol, mon Skytraxx donne une valeur proche du gnuvario (à peine qq mètres d’écart)

:trinq:

Personnellement j’aime la possibilité d’avoir une carte SD amovible, même si j’apprécierais en parallèle d’avoir un accès en USB, car à partir du moment ou on aura une meilleur autonomie, il sera bien pratique de récupérer les vols avec la carte SD sans devoir démonter le vario des élévateurs - Il est même très facile de rechargé le GnuVario avec une rallonge et le sac de portage ouvert - tirer un câble usb jusqu’au PC c’est pas pratique si on passe sur un composant mémoire

Tu trouveras en annexe ma dernière trace avec le GNUVARIO dans lequel je me suis pris du +4 en dernière partie de vol… j’espère que c’est suffisant pour tes tests.
Par contre j’ai une question. J’ai un gros écart entre l’alti-barometrique et GPS… Comment étalonner le baromètre? est-ce qu’un Synchro est censé se faire avec le GPS a l’allumage une fois les données GPS acquises?
Autre question: j’ai essayé d’étalonner le GNUVARIO avec le fichier FIRM.HEX issue de Calibration.ino de Prunkdunk mais il ne se passe rien… J’entends les 3 bis confirmant le chargement du fichier mais après écran vide et rien. Par contre quand je remets la version 631 de jp63, elle se charge bien et j’ai bien les nouveaux sons…
J’ai encore du rater un truc mais quoi? :bang:

Je reste super content du projet et du résultat et fait de la pub autour de moi … du coup on risque d’avoir d’autres commandes :ppte:

@ Ptikiki

si tu veux des traces GPS
je te propose de récupérer les traces de Maurer ou de Gasp d’hier à la X-Alps

tu a des passage avec des très fort vario et du soaring dans du tout petit en fin d’aprem

et puis c’est des traces comme nous on en fera jamais :mrgreen:

ici : http://3dxalps.xyz/

nouveau problème de mon coté, l’écran n’affiche plus rien… Il bip bien mais l’écran me semble HS… J’ai revérifié 4 fois les connexions mais rien n’y fait.

Essai de déconnecter l’écran de son support - 4 fixations à pousser - nettoie la partie caoutchouc et les connectiques - refixe bien l’ecran
tu as testé les connexions à ohm mètre ?

je vais essayer la technique nettoyage. J’ai plus de pile dans mon ohm mètre, je vérifierai dans une semaine (je prend le train)

Une explication possible :
L’info transmise en BT contient à la fois les coordonnées GPS et la pression atmosphérique.
Je ne connais pas XCtrack ; est-ce qu’il n’appliquerait pas une correction liée au QNH ou à une altitude de départ à saisir ?

Par exemple, sous XCSoar, pour l’infobox “Altitude” : on peut choisir “Auto”, “GPS” ou “Baro”.

  • GPS : c’est l’altitude GPS qui s’affiche
  • Baro : c’est l’altitude calculée depuis la pression atmosphérique qui est utilisée. Il faut alors saisir le QNH pour que XCSoar puisse en déduire l’altitude
  • Auto : XCSoar choisi automatiquement entre “GPS” ou “Baro” : “Baro” si cette info est fournie ; “GPS” sinon
    si on branche XCSoar sur le GnuVario, c’est l’altitude “Baro” qui est choisie

:pouce: ça doit être la bonne explication

https://vimeo.com/224813606

On voit sur la vidéo que le son émis n’est pas très propre.

Nous attaquons le Buzzer en +3.3V/-3.3V en PWM

Je me demandais si en attaquant le buzzer en 0/+6.6V ou 0/+5V avec un filtre audio nous n’aurons pas de meilleur résultat.

https://www.allaboutcircuits.com/technical-articles/low-pass-filter-a-pwm-signal-into-an-analog-voltage/

http://makezine.com/projects/make-35/advanced-arduino-sound-synthesis/

Quant pensez-vous ?

Quelqu’un saurait étudier un petit montage pour faire un test, je ne suis pas un expert en électronique, je crois qu’en réalisant quelques tests, j’ai fumer mes 2 derniers buzzer

Nan, pas la bonne
j’ai regardé un peu plus XCTrack
ce que j’affiche c’est l’altitude GPS, j’affiche aussi l’altitude Baro
sur le gnuvario elle est stable et dans la marge d’erreur de la réalité
sur le XCTrack elle varie beaucoup et met très longtemps a se stabiliser ???

L’altitude Baro est à 0 m puisque XCTrack n’arrive pas à lire les données Baro du gnuv
est ce normale ? on envoie les infos par BT ?? ou ce n’est pas encore réalisé ???

Pour l’instant XCTrack ne me convainc pas vraiment
l’altitude, le vario, la vitesse … bougent sans arrêt alors que je suis fixe ???
et que les valeurs sur le gnuv sont bonnes.

:grat:


http://nsa38.casimages.com/img/2017/07/09/17070904594955937.jpg

Pas con d’insérer un filtre avant l’ampli !
Un signal carré est une addition de signal sinusoide ça devrait changer le son .
J’rssaierai mais suis en vacances. …pas avant 15 jours :frowning:

:fume:

Mes essais sous XCSoar sont encore plus décevant.
l’altitude gps se cale bien (varie beaucoup quand même)
mais le vario de XCsoar se met à hurler (- 5 m/s) et la vitesse donne n’importe quoi ??

Quelqu’un a fait des essais concluants ?

Salut tout le monde !

Je fais parti des premiers intervenants de ce fil mais malheureusement mon vario (sous Arduino Nano) n’a jamais dépassé le stade du protoboard…

J’avais dans l’idée de faire une V2 qui gère le GPS mais je vois que c’est déjà fait :slight_smile:

Pour info, voilà ce que j’avais prévu dans la V2 :

  • écran eInk (meilleure lisibilité en pleine lumière et plus faible consommation que le Nokia 5110),
  • Teensy au lieu de l’Arduino Nano :
    • RTC intégré (avec pile + crystal)
    • Carte SD Mass storage (enregistrement et déchargement de statistiques/traces par USB)
  • Tracking GPS

Du coup, étant donné que j’ai peur de ne jamais trouver le courage de graver un PCB pour ma première version je suis également intéressé par ton/votre kit ! (je n’ai pas trop compris qui de “PrunkDump” ou “JPG63” a réalisé quoi :-P)

Que pensez-vous des améliorations que j’avais imaginé ? J’ai peur que l’Arduino devienne très vite un facteur limitant, je me demande d’ailleurs comment vous avez casé tout ça dans le code en restant sur un framework Arduino !

PS : Désolé “prunkdump”, je me rends que je t’avais posé des questions en septembre dernier et que je ne suis jamais venu lire la réponse… Entre temps, un mariage a eu lieu et un gnome va bientôt venir au monde donc je dois reconnaître que je ne me suis pas beaucoup consacré au parapente dernièrement :stuck_out_tongue:

Salut,

Tout revient à Prunkdump, personnellement je n’ai fais que quelques améliorations sur le code et l’électronique

Ecran EInk oui mais il faut en trouver un de la même taille et compatible arduino sans compter le prix
Oui l’arduino pro mini est un peu juste, mais changer de microcontroleur demande beaucoup de changement (librairie) donc pour l’instant Prunkdump pense que l’on peut encore optimiser le code pour que tout rentre et je lui fais confiance

  • Carte SD Mass storage (enregistrement et déchargement de statistiques/traces par USB) - tu connais une carte module qui le fait ? On a le stockage sur carte SD, il manque le raccordement à l’USB
    GPS on a donc RTC inutile

Un nouveau kit est à l’étude, c’est un énorme boulot pour PrunkDump

A bientôt parmi nous avec un futur kit

Pour l’écran, il y a ce genre de choses par exemple : http://www.dx.com/fr/p/waveshare-1-54-e-ink-display-module-for-arduino-nucleo-pi-466359
Mais certes à 16 € alors que l’écran de 5110 est tombé à moins de 3 €…

Pour le SD Mass Storage, le Teensy semble le faire justement avec un firmware custom : https://github.com/damonearp/teensy-3.2-msd

Pour le RTC, c’est vrai que c’est inutile avec le GPS et c’est optionnel sur le Teensy justement.

Le passage au Teensy demande effectivement une réécriture du code mais rien de bien compliqué dès lors qu’on sait programmer ce genre d’appareil. Il est bien plus évolutif en terme de cadence processeur et de mémoire surtout !

Le seul point noir à l’heure actuel serait le fait qu’il existe beaucoup de librairies Arduino qu’il faudra alors réécrire mais il existe des soft d’émulation qui permettent de profiter de l’espace mémoire en conservant une bonne compatibilité :
https://www.pjrc.com/teensy/teensyduino.html
https://www.pjrc.com/teensy/td_libs.html

Jérémie LeCouvert

L’écran EInk j’adore si il y a des librairies arduino, c’est à étudier - même taille, même encombrement - 2 fois plus de résolution et un contraste inégalé avec en prime une exclusivité - seul à la connaissance la tablette Syride, utilise cette technologie - 16€ c’est très raisonnable

Le Teensy à l’air d’être une bonne alternative à l’évolution, mais aux fils des posts, je crois avoir compris que ce micro-contrôleur était propriétaire et que le portage du source et le développement futur était loin d’être simple. Si on peut porter le code je suis plutôt pour. Le projet est à Prunkdump ce sera à lui de le faire évoluer comme il lui semble le mieux. Accès à la SD en natif, plus de mémoire, plus rapide c’est :pouce:

:pouce: top classe ! et carrément raisonnable le prix pour le confort que ça apporte.

“En raison des avantages comme une consommation d’énergie ultra basse, un large angle de vision, un excellent effet sous la lumière du soleil, …”