ca yest ma v2 est monté 
par contre on lit la trace gps avec quel logiciel 
DIY GnuVario : variomètre opensource - openhardware Arduino
salut, tu peux convertir la trace NMEA fichier.txt en IGC avec GPSBABEL et l’importer dans LogFly, dans xcglobe ou même dans doarama
http://www.gpsvisualizer.com/gpsbabel/?lang=fr
yes merci cool
ouf ca y est j’ai recu le mien! en effet il était dans la boite aux lettres du voisin 
Je me mets au montage la semaine prochaine
Salut à tous !
Bon courage encore à ce qui m’ont contacté et qui n’ont pas encore commencé où fini de monter leur vario !
Super guillaume1 pout ton montage. Tu vas pouvoir travailler avec nous. Merci jpg63 pour le test du code 
Au moins un truc de résolu ! Il est possible maintenant de régler le volume du vario :D. Attends peut-être un peu pour modifier la bibliothèque nmea (Cf. ci-dessous). Merci pour ta video Xiboard ! Effectivement pour le moment le bluetooth doit être amélioré :? Selon la vitesse de la carte SD il fait bugger le vario. J’explique ci-dessous d’où vient le problème. Tu n’as pas converti ton voisin au passage finlard Si ça se trouve il est bon en électronique 
Alors plus sérieusement :
Pour les trames du bluetooth/carte SD :
Il semble que le mélange actuel NMEA/Openvario ne soit pas une bonne idée. Il n’est ni pratique pour le fichier de trace (logfly, doarama ne le prennent pas) ni pour la communication bluetooth (Ca ne marche pas avec XCSoard ou XCTrack). Je pense qu’il n’y a pas le choix il faut changer de design…
Mais bonne nouvelle j’ai étudié le format IGC :
http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html
et les trames “IGC->B” sont très proche des trames “NMEA->RMC”. Du coup il pourrait finalement ne pas être si difficile de sortir du format IGC du vario. Du coup cela règlerait le problème des traces sur la carte SD qui serait compatibles avec la majorité des logiciels.
Mais XCSoard et XCtrack supportent-ils la communication au format IGC ?
Je comprends pas tout mais il semble que IGC supporte également des trames permettant d’envoyer la variation d’altitude. Est-ce que les experts peuvent étudier la chose ?
Pour le bug du vario avec le bluetooth :
Le problème de stabilité du vario avec le bluetooth vient du fait que la boucle principale fonctionne ainsi :
-> Elle lis les capteurs de pression et d’acceleration et met à jour Kalman
-> Elle regarde si le GPS envoie des données :
-> Si oui :
----> elle lis les données du GPS
----> elle les interprète
----> elle les écrits sur la carte SD
----> elle les envoi en bluetooth
Ainsi comme le GPS envoi toutes les 2 secondes une grosse quantité de données. Lorsque le GPS n’envois rien le vario n’a presque rien à faire. Lorsque le GPS se met à envoyer il a tout d’un coup plein de travail. El il doit le finir avant de recommencer à lire les capteurs ! Et si en plus la carte SD est un peu lente…
Il faut que j’arrive à répartir les calculs du vario de façon plus régulière.
Autre chose. Le vario envoie plein d’info inutiles. Comme toutes les trames GPGSA et GPGSV.
A étudier
Je pense que aucune appli ne gère la réception d’IGC. Mais oui les IGC c’est très simple et proche du NMEA.
J’ai fait une demande à la team de XCTrack pour qu’il me propose un protocole qu’il prennent en charge (XCTracker, GPSBip, BlueFly, …). Moi j’ai cherché est j’ai pas réussi à trouver. Je sais que le protocole BlueFly est pris en compte par XCTrack et XCSoar. Mais j’arrive pas à le trouver. Il me semble que XCTracker et GPSBip étaient opensource mais pas trouvé ?
La vidéo que je t’ai envoyé, la carte SD était désactivée.
J’ai analysé le code mais je pige pas. hormis que effectivement se soit un problème de timing. Mais la lenteur de la carte SD ne doit pas rentrer en compte puisque je la désactive.
Je vais tenté de faire un essais en envoyant un “paquet” court par bluetooth pour voir s’il bug de la même manière.
prunkdump pas de soucis, je vais attendre un peu avant de développer l’affichage de l’heure et de la durée du vol.
pour IGC, j’ai regardé la même source que toi, pour comprendre un peu ce que renfermé ces fichiers
Voici un bout de fichier tiré d’un syride nav
AXSR
HFDTE220417
HFFXA035
HFPLTPILOTINCHARGE: jpg63
HFCM2CREW2:
HFGTYGLIDERTYPE: not set
HFGIDGLIDERID: 0
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 3.25
HFRHWHARDWAREVERSION: 1.0
HFFTYFRTYPE: Syride, SYS’Nav
HFGPS: UBlox,MAX7Q,56ch,10000m
HFPRSPRESSALTSENSOR: ST,LPS331AP,11000m
HFCIDCOMPETITIONID:
HFCCLCOMPETITIONCLASS: 3BB13301
I023638TAS3940SIU
B1415534537980N00306970EA007050082101709
B1415544537980N00306970EA007060082101909
B1415554537980N00306974EA007060082102009
B1415564537980N00306978EA007060082101909
…
G84A0EE5A3659F8099431432FDFE192CC09DAD7A77ADC8617334BA3B655E382EC
GBB88922E3E593FD42F3BA05D6C45A570C62573BA551819BB5B0B2F96B02180C4
GFC9430969F4EACB47C17F77916C7B4078703342A140FCD17AFE6FFEB6022D8B2
G5BBB6FDFA3E906F5DF0E8CEACFE73CB8217BB06F5BDD9B6D537838003598D13F
on voit que tout le début c’est juste du blabla et à la fin c’est une sorte de checksum. Le plus important c’est les enregistrements B qui restent très simple mais complet heure, position, alti baro et alti gps - le reste est gérer par logfly et autre (stat )
Pourrait-tu nous préciser à quoi servent chaque variable et si il en existe d’autre pour régler le vario, je vais faire quelques tests en vols des que possible
VARIOSCREEN_CONTRAST 60 Contrast de l’écran
VARIOMETER_BEEP_VOLUME 6 volume du beeper
VARIOMETER_SINKING_THRESHOLD -2.0
VARIOMETER_CLIMBING_THRESHOLD 0.2
VARIOMETER_NEAR_CLIMBING_SENSITIVITY 0.5
VARIOMETER_ENABLE_NEAR_CLIMBING_ALARM
VARIOMETER_ENABLE_NEAR_CLIMBING_BEEP
/* mean filter duration = filter size * 2 seconds */
VARIOMETER_SPEED_FILTER_SIZE 5
FLIGHT_START_MIN_TIMESTAMP 15000
FLIGHT_START_VARIO_LOW_THRESHOLD (-0.5)
FLIGHT_START_VARIO_HIGH_THRESHOLD 0.5
FLIGHT_START_MIN_SPEED 10.0
Ouai ! La fin (ou d’ailleurs aussi pendant sur les gros enregistrements) c’est la signature pour certifier le fichier pour la FAI. Il faut être constructeur autorisé pour permettre ça, un bordel, faut oublier pour nous. (si j’ai bien tout compris)
@PrunkDump :
C’est quoi le moyen le plus simple pour faire le checksum ? pour un essai juste.
Salut. Comme ça rapidement le temps de faire un truc mieux :
Sinking -> seuil d’alarme de degueulante
Climbing -> seuil d’alarme d’ascendance
Near climbing -> distance du seuil d’ascendance à partir duquel le bip de zerotage s’enclenche
Near Climbing alarm -> trois bip lorsque l’on rentre dans la zone de zerorage, un bip grave lorsqu’on en sort
Near climbing beep -> beep de zerotage (! Active uniquement si le vol est détecté )
Speed filter size -> lissage de la vitesse pour le calcul de la finesse . Plus c’est long plus c’est lissé mais moins c’est réactif
Après c’est les réglages du détecteur de vol
Min timestamp -> temps minimal après allumage (ici 15 sec)
Low/high -> seuil d’ascendance ou degueulante
Min speed -> vitesse minimale
Hello,
pour faire de l’IGC, c’est simple, il suffit de suivre ce doc :
http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/ (DSL, en anglais …)
pour le valider FAI, c’est un peu plus casse pied :
Il faut faire genre un MD5 sur quasi tous les champs, et ensuite crypter le résultat du MD5 par un algo genre sha256, et ca deviendra la ligne G
Pour encrypter, il faut une clé privée et une clé publique. La FAI oblige a garder la clé privée d’encryptage secrete (pas compatible avec de l’open source …)
Ensuite, ils demandent de faire un programme en ligne de commande qui dit si le fichier a été modifié ou pas. Cela leur servira sur leur serveur a valider le fichier.
Si on ne crypte pas le fichier, le GPX suffit amplement car c’est reconnu par la FFVL. (Sinon, on trouve des convertisseurs qui encryptent le GPX a la volée pour le rendre valide FAI)
Si vous avez des questions, j’ai déjà validé FAI un vario
Salut,
Concernant l’enregistrement sur sdcard :
je crois que ca ne devrait pas se faire au rythme des infos GPS, mais toutes les n secondes (3, voire 5) pour limiter la taille de la trace, eet surtout ne pas pénaliser le fonctionnement du reste.
Concernant les trames NMEA utiles a transmettre en bluetooth :
je pense en effet qu’il faut élaguer les trames actuellement générées par le vario (si ce sont les mêmes trames que celles enregistrées sur la sdcard).
A coup sur : on peut abandonner les trames GPVTG (direction et vitesse), GPGSA (précision et satellites actifs), GPGLL (latitude, longitude, heure), GPGSV (satellites en vue)
Les trames essentielles sont :
GPRMC et GPGGA : elle délivrent des infos GPS :
GPRMC : c’est le minimum syndical.
heure UTC, info de fix GPS, latitude / longitude GPS, vitesse sol (en noeuds), azimut de déplacement (en degrés - pas renseigné ici), …
GPGGA : heure du système GPS, et les infos GPS. redondant par rapport à la trame précédente, mais très utilisée
Après, il faut pouvoir envoyer au moins les infos de vario et d’altitude barométrique, ou de pression ; c’est la plus-value de ce vario pour un système de navigation extérieur.
Il y a les trames openvario ($POV) ; décrite à http://www.openvario.org/doku.php?id=projects:series_00:software:nmea
Le vario actuel ne semble envoyer que des trames de type “$POV,E” ; donc l’info de vario. Si on choisi d’utiliser les trames openvario, il faudrait au moins ajouter l’info de pression atmosphérique
J’ai regardé les trames envoyées par le simulateur de vol condor, qui sont interprétées par les logiciels de navigation aérienne :
GPRMC, GPGGA, et LXWP0
A noter également que la trame LXWP0 est aussi utilisée par XCtracer pour XCSoar : http://www.windeckfalken.de/51-diverses/diverses/228-xcsoar-en
Ca semble une valeur sure.
description d’une trame LXWP0 :
0 loger_stored (Y/N)
1 IAS (kph) IAS : Indicated Air Speed (vitesse indiquée, avec les erreurs)
2 baroaltitude (m)
3 vario (m/s)
4-8 unknown
9 heading of plane
10 windcourse (deg)
11 windspeed (kph)
A savoir pour XCSoar :
si on déclare un driver spécifique, il sait interpreter en plus un certain nombre de trames standard ; au moins les trames GPRMC, GPGGA
On choisi le driver dans le menu “config - Périph”
Ca propose un nombre important de drivers, dont openvario (trames POV) et LXNAV (trames LXWP0)
Conclusion :
- il faut les trames GPRMC et GPGGA
- si on choisi d’ajouter la trame POV openvario, ca serait bien d’avoir en plus de l’info de vario celle de pression atmosphérique
- sinon, il faut remplacer les trames PVO par des trames LXWP0
Tout cela est théorique : je n’ai pas fait de tests …
Merci beaucoup pour ces précisions, Prunkdump
pour les variables
Climbing -> seuil d’alarme d’ascendance
Near climbing -> distance du seuil d’ascendance à partir duquel le bip de zerotage s’enclenche
une petite précision pour que je comprenne bien
si j’ai Climbing = 0.2
et Near climbing = 0.5
le zérotage bip de 0 à +0.5 ?
et le bips de monté démarre à partit de 0.2 ?
Si je veux que les bips de montés débutent à +0.5 et le zérotage entre 0 et +0.5 tu peux me dire quelles valeurs doit-on mettre ? pour que je comprenne bien
Attention logfly et xcglobe n’accepte que l’igc
je vais tester un igc sans la validation sur logfly et xcglobe pour voir si ils acceptent le fichier
Merci beaucoup vmath54 ! Effectivement ta proposition semble la plus “universelle”.
Pourtant Xiboard semblait dire que s’il mettait le driver openvario dans XCSoar, il ne reconnaissait plus les trames NMEA. Il faudrait être sur avant de se lancer dans le développement. Dommage que je n’ai rien pour tester.
“Near climbing sensibility” est la sensibilité du détecteur de zérotage.
Avec climbing = 0.2 et sensitivity = 0.5 le zerotage commence à 0.2-0.5=-0.3 et le bip commence à 0.5.
Donc dans ton cas tu met climbing = 0.5 et sensitivity = 0.5
Je peux faire des essais.
Peut-être que le protocole “Condor Soaring Simulator” permet de lire en même temps trames GPRMC, GPGGA, et LXWP0 ?
C’est ça vmath54 ?
hello,
Rentré de vacances hier, le kit du vario m’attendait dans la boite avec impatience depuis plus une semaine…
Monté dans la soirée : nickel, super impressionné par l’optimisation de la conception de Prunkdump c’est vraiment bluffant, tu es trop fort . (et merci pour le pre-machage de boulot…)
Infos dans ce fil trés utiles en complément du tuto (n’en déplaise à Pseudo !).
en particulier:
Aprés ça, tout fonctionne bien, testé au sol dans plusieurs modes (avec et sans accel, avec sans écran etc.)
1er fix un peu long, mais les suivants semblent plus rapides.
Mon seul point d’inquiétude concerne l’antenne du GPS, qui est masquée non seulement par le module BT (en en a causé plus haut) mais aussi par l’écran, ce que je n’avais pas compris, et qui est plus dur à changer…
Ca risque de poser des pbms un peu aléatoires dans certaines conditions, à tester.
J’ai aussi quelques doutes sur l’autonomie, vue la taille de la batterie, et avec toutes ces fonctions, on verra bien.
Concernant le reset non accessible, j’ai fait une petite mod qui marche impec : j’ai routé la pin “rst” de l’arduino vers une pin Data non utilisée sur le port µUSB.
J’ai sacrifié une prise mâle pour faire un shunt externe entre gnd et la pin cablée.
Il suffit de brancher la prise momentanément pour faire un reset, c’est trés pratique. (cf fil jaune et prise shunté ci dessous):
https://img4.hostingpics.net/pics/811389IMG20170502232731HDR.jpg
il va aussi falloir que je test la procédure de calibration, car avec accel, j’ai un offset selon l’orientation.
Une question Prunkdump : en l’absence d’eprom, ou seront stockées les coefficients mis à jour aprés calibration? dans un fichier sur la carte SD? quid des modes “//define HaveSD”?
merci d’avance !
A+
salut ptikiki
j’en rajoute une couche, super boulot, du travail de pro, c’est un plaisir à monter et à regarder. Merci
Totalement d’accord
je crois avoir lu que ce GPS, récupère et stocke les positions des satellites, il est peut être possible de lui injecter des données pour accélérer le Fix
http://aprs.facile.free.fr/APRS%20FACILE%20gps%20gratuit.php#.WQlU5_nyjIW
je pense qu’après le 1er fix il trouve directement les satellites. Je pense aussi que si tu ne l’utilise pas de quelques jours, le fix au rallumage va être long, à confirmer
je pense qu’on pourra avoir une idée, dès que la modif de la mesure et de l’affichage de la tension sera en place - je travaille dessus
Super idée, si on opte pas pour la mise à jour sans reset (modif du bootloader), je monte ton idée, car j’aimerai bien fermer définitivement mon vario
Pareil
Pour le BlueFlyVario, j’ai trouvé cette page http://blueflyvario.blogspot.fr/2013/11/
[quote]outputMode (default = 0) - Sets the output mode. The available output modes are:
0 - The standard BlueFlyVario output mode. This sends raw pressure measurements in the form:
"PRS XXXXX\n": XXXXX is the raw (unfiltered)pressure measurement in hexadecimal pascals.
1 - The LK8EX1 output mode for use with LK8000. This sends pressure and vario data in the form:
"$LK8EX1,pressure,altitude,vario,temperature,battery,*checksum\r\n": pressure is sent as a decimal integer number of pascals, altitude is not sent (99999 is sent instead), vario is the decimal integer vertical climb rate in cm/s, temperature is in degrees Celsius (1 decimal place), and battery is the battery voltage of the on-board battery (2 decimal places).
2 - The LXWP0 output mode for use with a range of apps:
"$LXWP0,loger_stored (Y/N), IAS (kph), baroaltitude (m), vario (m/s),,,,,,heading of plane,windcourse (deg),windspeed (kph)*CS": The BlueFlyVario only has a partial implementation of this sentence. It only outputs the baroaltitude and vario (all other fields are blank). Note that baroaltidude is determined from filtered pressure using the outputQNH setting.
3 - The FlyNet protocol:
"_PRS XXXXX\n": In this case XXXXX is output as the filtered pressure stream. The filtering parameters used are those from the other hardware settings.
[/quote]
Si cela peut vous aider…
Voici la procédure de qualibration de l’acceléromètre.
Dites moi si vous voyez bien les sous-titres ?
http://www.youtube.com/watch?v=fc0vIsZJvsw
Attention de bien prendre la dernière version de “calibration_nointeractive” !
https://github.com/prunkdump/arduino-variometer
Merci Gej pour ces infos ! En gros le blueflyvario supporte tous les formats de sorties possibles ! :shock: Mais je ne sais pas comment il mélange les trames GPS. Malheureusement ce n’est pas détaillé sur cette page :
http://blueflyvario.blogspot.fr/2016/04/blueflyvariottlgpsv11-released.html
Mais c’est bien compatible avec XCSoar…
Nickel la proc de calibration ! Oui, c’est ok les sous-titres.
Moi je teste ce soir une version du code modifié sans sd et sans gps pour juste envoyer Pression, Alti, Vario via les trames LK8EX1 via Bluetooth (toutes les 0.5s).
Je fait un retour. Si ça déconne pas je le laisse comme ça, couplé à XCTrack, je suis en principe en stage cross la semaine prochaine vers StHill & Co.
Le BlueFly Vario, le GPSBip et XCTracker, tu choisi le protocole il me semble mais oui ils sont tous compatibles de quelques protocoles.
J’avais vu l’info sur type de output du bluefly, je suis étonné que le standard c’est d’envoyer le raw pressure non filtrée.