DIY GnuVario : variomètre opensource - openhardware Arduino

Le test est intéressant, mais je doute que ton problème vienne des nuages
hier sous la pluie avec un ciel très chargé, j’ai eu un Fix en moins d’une minute.

j’ai bien le fix avec 200 ou 300, c’est la carte sd, une mauvaise soudure certainement, mais je ne la trouve pas et à chaque fois que je démonte, il y a un autre bout qui se dessoude. C’est trop petit :bang: pour mes yeux

Attention le Fix du GPS n’est pas la même chose que la précision. Même par beau temps on peut faire très vite le Fix avec pleins de satellites et avoir la malchance qu’ils soient mal positionné (par exemple tous presque au même endroit). On peut alors avoir le Fix très rapidement avec une mauvaise précision. Avec le mauvais temps on capte moins de satellites et donc c’est d’autant plus de chance d’avoir une mauvaise précision.

J’ai mis la valeur de 200 au pif. Je sais que 100 c’est la meilleure précision possible mais je n’ai aucune idée si 200 c’est une “trop” bonne précision ou pas. Pour info cette valeur est la valeur de “Horizontal dilution of position” dans les trâmes GGA multiplié par 100.

C’est pour ça que je voulais ajouter un symbole lorsque l’enregistrement commence. Car le GPS peut faire le Fix sans avoir une précision suffisante et s’est diificile de savoir pourquoi on a pas de fichier sur la carte SD (manque de précision, bug sur la carte SD).

@jpg Il n’y a pas réellement de pin qui n’est utilisé que pour l’écriture sur la carte SD :
-> Il y a la pin 12(MOSI) qui est beaucoup plus utilisée lors de l’écriture mais elle est aussi utilisé lors de la lecture.
-> Attention par contre il faut include <SPI.h> avant <VarioSettings.h>. Vérifie que tu l’as bien fait partout dans ton code.

Mais il me semble de Vmath54 avait bien un problème uniquement sur l’écriture qui faisait carrément planter le vario. Alors il y a peut-être quelque chose qui m’échappe encore.

Ensuite lorsque j’ai créé le bootloader de carte SD j’ai effectivement réécrit le code de la bibliothèque LightFat16. J’ai peut-être fait quelque chose qui améliore la stabilité du code :grat: Mais pour l’instant à part les temps de timeout qui sont différents je ne vois pas une réelle différence entre les deux librairies.

Vmath54 a fait des essais avec la dernière bibliothèque “SD” :

https://github.com/greiman/SdFat

Il y n’avait plus de soucis. Donc il doit bien y avoir une différence quelque part. Mais je ne l’ai pas touvé pour l’instant. Et c’est difficile à débugger parceque moi tout marche avec ma vieille carte SD.

Difficile donc jpg63 de te dire si ton problème viens réellement des soudures. Si vraiement la mise à jour des firmware fonctionne à tout les coup je ne pense pas que ça soit ça. Il faudrait que tu testes avec une autre carte SD pour voir si ça change quelque chose.

Attention si tu refais les soudure ajoute toujours un petit peu d’étain pour remettre du flux.

A+

Dans mon dernier code, il y a un bip au fix gps et 2 quant le vario démarre le vol - en plus on a le décompte du temps de vol. Je suis sur que le décompte débute quant la mise à jour de l’altitude est faite, mais après pour l’écriture je ne sais pas si il y a un test particulier.

J’ai une vielle sdcard 2Go, je vais essayer avec une autre, car je ne m’explique pas pourquoi ça fonctionne a certain moment - il faudra peut être voir la bibliothèque, je vais tester celle de Vmath54 car je ne m’explique pas que la lecture et l’écriture fonctionne dans certain cas, l’électronique ça marche ou pas enfin presque :grat:

@Prunkdump

[quote]J’ai oublié de te dire Whistler ! Ca y est la bibliothèque nmea envois les deux altitudes (barométrique et GPS). C’était une fonctionnalité dont tu avais besoin.
[/quote]
Salut prunkdump, merci encore pour la fonction, j’ai pas trop rebossé sur le vario ces derniers temps et je vois que l’avancement est énorme.
Je vais essayer de reprendre du temps de tester les fonctions pour faire un max de retour.

Et si jamais j’utilise aussi un autre GPS: https://fr.aliexpress.com/store/product/PA6H-MediaTek-new-generation-GPS-Chipset-MT3339/605000_1910861544.html
il plus compact, envoie des trames avec une fréquence de 1Hz. Niveau fonctionnement je n’ai aucun soucis, fix < 30s

le PA6H est celui prévu pour la version CMS du vario :wink:
il marche du tonnerre et fixe en general en moins de 30sec en ext.

Pour les problèmes de sdcard :

J’ai eu de gros problème en utilisant des sdcard récentes : 16Go et 32go samsung EVO+ ; pourtant partitionnées comme prévu :
une seule partition principale de 1Go, formatée en fat16.
Le vario plantait complètement un peu après le fix GPS, donc au moment ou il devait écrire sur la sdcard ; alors que la lecture fonctionnait, je pouvais bien charger le firmware.

C’est réglé maintenant, depuis qu’un copain m’a refilé une très vielle sdcard de 4 Go qu’il n’utilisait plus.

Dans les essais que j’avais fait, avec un autre lecteur de sdcard, sur une breadbord :

  • je n’avais aucun problème d’écriture de fichiers avec la lib SD “de référence” : https://www.arduino.cc/en/Reference/SD

  • avec la lib LightFat16 :
    . j’ai d’abord fait de mauvaises conclusions, car je n’avais pas compris que l’écriture dans le fichier ne se faisait que lorsqu’il y avait 255 octets dans le buffer

    . ensuite, j’ai constaté de très nombreux problèmes lors de l’initialisation de la sdcard : l’appel de la fonction LightFat16 “file.init()” échouait vraiement très souvent.

Par contre, si j’avais auparavant utilisé la sdcard avec la lib SD “de référence”, sans arreter électriquement l’arduino utilisé pour ces tests, la fonction “file.init()” ne retournait plus d’erreur.

Je n’ai pas creusé, par manque de temps …

Merci beaucoup :lol:
Va falloir que je peaufine ma manipulation du fer à souder …

Coté carte sd, j’ai testé avec 2 cartes 2Go type 2 et 1 carte 8Go type 4 formatée à 1Go. Le dernier code ne créé aucun fichier, je laisse tourner le vario après démarrage du vol pendant plusieurs minutes mais aucun ficher.

j’ai testé le lecteur et la carte sd avec un petit code et les bibliothèques SPI et SD. j’ai un fichier à chaque fois, et des valeurs de A2 (mesure de tension)

L’électronique parait ok mais il semble que les bibliothèques SD du projet bug à l’écriture - mon problème de carte SD est apparu que recensement mais j’ai toujours eu un fonctionnement un peu aléatoire, peu être un problème de vitesse d’écriture

Je suis toujours sous le dernier Firm de JPG
hier j’ai voulu vérifier si une trace s’écrivait sur ma carte SD
Le vario a fait le fix très facilement
par contre pour faire démarrer l’écriture ça a été difficile
même en démarrant en voiture ça ne suffit pas, il a démarré qq km plus tard quand j’ai pris une petite descente.
Il me semble que les critères de démarrage soient un peu sévères

(@) Prunkdump
Idée de fonctionnalité qui rendrait le GNUgpsvario unique :
- prévoir un rétro éclairage de l’écran pour le vol de nuit
https://imgfast.net/users/2512/45/46/19/smiles/305570657.gif

j’ai compilé le code avec le démarrage direct, car effectivement sinon il faut une vitesse de plus de 10Km/h et un vario au moins à +0.5 ou -0.5

De mon coté j’ai bien le démarrage du compteur de vol, qui indique le le calibrage de l’altitude s’est fait et que l’écriture commence, mais j’ai pas de fichier. Avec la librairie sd standard et un petit code qui écrit 100 valeurs de la tension de la batterie. Je n’ai jamais constaté de problème avec le test. 2 choses font la différence - la bibliothèque et le fait que le fichier est fermé à la fin du test. La fermeture ne posait pas de problème, donc quelques chose dans la fonction d’init bloque

pour ton problème tu peux essayer de modifier les paramètres du fichier de config

/* Flight start detection conditions : /
/
-> Minimum time after poweron in milliseconds /
/
-> Minimum vertical velocity in m/s (low/high threshold) /
/
-> Minimum ground speed in km/h */
#define FLIGHT_START_MIN_TIMESTAMP 15000
#define FLIGHT_START_VARIO_LOW_THRESHOLD (-0.5)
#define FLIGHT_START_VARIO_HIGH_THRESHOLD 0.5
#define FLIGHT_START_MIN_SPEED 7

Si je me trompe pas le rétroéclairage n’est pas raccordé électroniquement à l’écran, il faudrait le prévoir et programmer une commande ou mettre un capteur de lumière

@Van Hurlu :

J’avais de gros problèmes de fix GPS ; de l’ordre de 3 à 5 mn, même sans avoir soudé le module bluetooth.

J’ai sorti l’antenne GPS comme toi, ça change tout ! en 30s, le fix est fait.

Juste testé sur le rebord de fenêtre, à cause de météo. Mais ca marche très bien avec le vario posé sur le dos écran vers le haut, donc avec l’antenne qui regarde à l’horizontale.

Ce n’est pas très élégant, mais ca semble efficace.

:pouce: Ce qui compte le plus pour un proto, c’est que ça fonctionne.
Le design on verra après.

Et puis dans sa version définitive avec le projet de Gargle on aura encore plus de place pour revoir l’agrégation

PS: Tu as été un peu généreux en découpe. Mets un bout de scotch au cas ou tu traverse un nuage :roll:

Salut ! :coucou:

En travaillant sur l’écran j’ai trouvé un point qui pourrait faire gagner beaucoup en autonômie :D.

Jusqu’à présent les valeurs affichées à l’écran était actualisée au maximum à chaque tour de boucle. Du coup l’arduino communique avec l’écran en permanence. Si vous regardez la carte Arduino on voit une led qui mouline constament (elle sert pour l’écran et la carte SD).

J’ai changé le code pour que l’affichage soit actualisé uniquement si le chiffre change. Ca libère déjà pas mal l’écran. La diode s’éteint maintenant pendant des périodes non négligeables.

Je vais même pousser un peu plus la chose :wink: Je voudrais éviter que l’affichage “clignote” lorque l’on s’approche d’un 0.5 pour un entier :

Par exemple si l’altitude est proche de 1024.5 le vario affiche
-> 1024 si on est à peine en dessous
-> 1025 si on est à peine au dessus
Donc si on reste proche de 1024.5 le chiffre change en permanence et c’est pas très lisible.

Il faudrait une marge plus large que l’arrondi sur laquelle on ne change pas la valeur.

Je devrais pouvoir envoyer ça dans le journée. Avec au minimum le niveau de GPS et le niveau de batterie de Jpg63. Pour le temps de vol il faut d’abord que je vois si on peut optimiser le code.

Autrement j’ai fini la bibliothèque qui permet de gérer plusieurs “pages” à l’écran. On pourra donc par exemple afficher le temps de vol toutes les 10 secondes pendant 2 secondes sur une page séparée.

A+

Prunkdump,

pour le problème de la carte sd, j’ai essayé un reformatage en 16 ou 32k pas de différence.
Avec un code minimum, la bibliothèque ligthfat16 fonctionne, j’arrive à créer à chaque fois un fichier

je cherche ou est le soucis dans le code du variometer - soit un bug, soit un confit avec l’écran qui se rafraîchie trop. Ton nouveau code va peut être résoudre le soucis :slight_smile:

Salut.

Dans le vario il y a un gros delay entre file.init() et file.begin(). Vérifies que ce n’est pas ça le problème.

il me semble que le problème vienne de la fontion begin de la library lightfat16 et plus particulièrement de la détection de la FAT16

/* ckeck block 0 /
data = this->blockSet(0, 0);
if( data[FAT16_ID_POS + 3] == ‘1’ && data[FAT16_ID_POS + 4] == ‘6’ ) { //Check “FAT16”
partitionStartBlock = 0;
} else {
/
read MBR to get the first partition and check again */
partitionStartBlock = (uint32_t)&data[MBR_FIRST_PART_POS + MBR_PART_LBA_POS];
data = this->blockSet(partitionStartBlock, 0);
if( data[FAT16_ID_POS + 3] != ‘1’ || data[FAT16_ID_POS + 4] != ‘6’ ) { //Check “FAT16”
return -1; //no partition found
}
}

dans mon cas il ne détecte pas de partition, du coup il n’enregistre rien

Ca y est ! :smiley: J’ai enfin commencé à intégrer le code de Jpg63 :oops:

Mais il n’y a pas encore le temps de vol. Ca va venir :?

Donc pour l’instant en nouveauté :
-> Possibilité de paramétrer plusieurs “pages” avec des infos différentes.
-> Optimisation de l’écran (moins d’accès aux pixels).
-> Optimisation de l’affichage (valeurs stabilisées).
-> Affichage du niveau de batterie.
-> Affichage du niveau de réception GPS.

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

Je me met sur le temps de vol.

@Jpg63

Comment a tu fais pour faire bugger la bibliothèque. Tu avais dis qu’avec un code simple avec LightFat16 ça marchait à chaque fois. Qu’est ce que tu as changé pour que ça se remette à bugger ?

La bibliothèque bug dans le projet variometer.ino, avec tout écran, … Avec un code simple juste des bips et la sd pas de soucis, c’est une interaction dans le code complet qui pose problème, ce soir je teste le déplacement de l’init de la carte sd juste avant la fonction begin. On verra

Super prunkdump ; merci à toi, à Jpg63, Van Hurlu et les autres.

Ca fonctionne pour moi, sauf l’affichage de la batterie (photo de l’essai ce soir, sur le rebord de la fenetre).

J’ai soudé les 2 résistances du pont diviseur hier soir, comme sur la photo de Jpg63, et je n’ai pas controlé alors le résultat ; je suppose que j’ai fais une gougoune, je vais vérifier dès que j’ai un moment.

Depuis que j’ai sorti l’antenne GPS du boitier, le fix est vraiment très rapide.

J’ai fait pour la première fois un essai bluetooth en statique (pas soudé avant à cause du problème de réception GPS ; essai avec le vario posé sur la fenetre) ; ça marche, xcsoar récupère les infos gps, de pression et de vario.

Par contre, j’ai fait des essais aujourd’hui (avant la mise à jour) en voiture, avec une sdcard dedans.
Le vario fonctionne correctement en terme d’indication de vario et de vitesse ; mais aucun enregistrement sur la carte.

J’aimerais faire des essais en planeur, avec le vario en lien bluetooth avec xcsoar ; pas le plus facile, car ce sont des planeurs club, et je ne peux pas fixer le vario avec du velcro.
Peut-être demain …
Je me demande que que va afficher le vario pour la vitesse lorsque la vitesse dépasse les 100 km/h ; j’ai l’impression que l’affichage est limité à 2 digits.