DIY GnuVario : variomètre opensource - openhardware Arduino

((@)) Prunkdump
Pour avancer sur “le chant du GNUVario”
il y a qq temps tu m’avais écris ceci

[quote]-> Si la fréquence du bip monte trop vite, on peut changer : CLIMBING_BEEP_BASE_FREQ et CLIMBING_BEEP_FREQ_COEFF
-> Si l’alternance des bips monte trop vite, on peut changer : CLIMBING_BEEP_VELOCITY_FILTER_BASE, CLIMBING_BEEP_VELOCITY_FILTER_COEFF
-> On peut ajuster les fréquences des bips, leur longueurs etc …
[/quote]
Pas facile d’y aller au pif : en + ou en moins ??? De quel pourcentage ??? 10% de la valeur ???
Ce serait plus facile pour toi qui sais à quoi correspondent ces valeurs

je cherche à ralentir la progression de la fréquence des bips
et à ralentir la progression de la fréquence du son des bips

Tu changerais quoi à ces valeurs ?

[quote]/**************************/
/
beep general parameters /
/
**************************/
#define BEEP_DEFAULT_VOLUME 3

/* default threshold */
#define BEEP_VELOCITY_DEFAULT_SINKING_THRESHOLD (-2.0)
#define BEEP_VELOCITY_DEFAULT_CLIMBING_THRESHOLD 2.0
#define BEEP_VELOCITY_DEFAULT_NEAR_CLIMBING_SENSITIVITY 0.5

/* avoid changing beep freq too often */
#define BEEP_VELOCITY_SENSITIVITY 0.1

/********************/
/
THE CLIMBING BEEP /
/
*******************/
/
length of beep in vertical meters */
#define CLIMBING_BEEP_HIGH_LENGTH 0.16
#define CLIMBING_BEEP_LOW_LENGTH 0.04
#define CLIMBING_BEEP_LENGTH (CLIMBING_BEEP_HIGH_LENGTH + CLIMBING_BEEP_LOW_LENGTH)

/* climbing beep sound freq computation : BEEP_FREQ_COEFF * velocity + BEEP_BASE_FREQ */
#define CLIMBING_BEEP_BASE_FREQ 1000.0
#define CLIMBING_BEEP_FREQ_COEFF 150.0

/* climbing beep velocity filter /
/
filteredVelocity = beepVelocity * BEEP_VELOCITY_FILTER_COEFF + BEEP_VELOCITY_FILTER_BASE */
#define CLIMBING_BEEP_VELOCITY_FILTER_BASE 0.1
#define CLIMBING_BEEP_VELOCITY_FILTER_COEFF 0.5

//
/* THE SINKING BEEP */
/
/
#define SINKING_BEEP_BASE_FREQ 100.0

//
/* THE GLIDING BEEP */
/
/
#define GLIDING_BEEP_HIGH_LENGTH 0.10
#define GLIDING_BEEP_LOW_LENGTH 1.40
#define GLIDING_BEEP_LENGTH (GLIDING_BEEP_HIGH_LENGTH + GLIDING_BEEP_LOW_LENGTH)

//
/
THE CLIMBING ALARM /
/
/
#define CLIMBING_ALARM_HIGH_LENGTH 0.10
#define CLIMBING_ALARM_LOW_LENGTH 0.30
#define CLIMBING_ALARM_LENGTH (CLIMBING_ALARM_HIGH_LENGTH + CLIMBING_ALARM_LOW_LENGTH)

#define CLIMBING_ALARM_FREQ 1000.0

/********************/
/
THE SINKING ALARM /
/
********************/
#define SINKING_ALARM_LENGTH 0.7

#define SINKING_ALARM_FREQ 100.0
[/quote]
Si quelqu’un sait faire une simulation pour voir ce que ça donne ? comme sur le Tone Simulator de XC traceur.
Moi la seule manière que je connais, c’est d’aller voler avec … pas facile pour tester pleins de valeurs.

Je vais être obligé d’aller voler encore plus souvent et d’emporter un pc portable au déco

J’aimerais mais j’ai un boulot et une compagne :ppte:

J’outil est super mais il n’ai pas linéaire, je ne vois pas comment on pourrait simuler nos beeps, je pense qu’il faudra plutôt que l’on écrive un bout de code test qui simule une monté et une descente. L’envoi de fausse mesure à la librairie beeper, je vais regarder ce que je peux faire

yes j’avais bien compris, ce n’était qu’un exemple
si tu arrive à simuler en fonction du Vz
ce sera facile de comparer le résultat par rapport au Tone Simulator
Quand on aura un truc presque pareil (à une vache près) on sera déjà nettement mieux
:bisous:

Si je fais une rampe de 0 à +10 par pas de 0.1 et de 0 à -8 ça peut convenir ?

:pouce:
si tu pense te rapprocher du modèle de XC traceur

je vais regarder mais je ne pense pas - il faut voir avec Prunkdump pour confirmer, car je n’ai pas encore bien regardé le code mais les 2 systèmes me semble pas vraiment compatible. Ce que je vais essayer de faire c’est envoyer des valeurs du vario sans passer par les capteurs pour que le vario bip -

Cela va ressembler à ça : https://www.syride.com/fr/variosetup - sur le vario tu aura la valeur du vario affichée et le son

ça sera mieux il me semble :trinq:
la progression est déjà moins rapide

Je parlais du code pour tester, car pour ce qui est de la réaction du son c’est lié à la bibliothèque

Par contre j’ai un peu mieux regardé l’outil :

https://www.xctracer.com/en/user-manual/33/?oid=1874&lang=en
http://www.windeckfalken.de/special/xctracer/handson/main.html

Si je comprends bien ce sont 3 valeurs et une courbe linéaire ou logarithmique qui définissent le son

La fréquence, la période et le volume. Entre 2 points par exemple
0.5 550 550 50
1.0 595 500 50

entre +0.5 et +1m/s on va avoir 50% du volume mais si on avait eu

0.5 550 550 50
1.0 595 500 60 le volume entre 0.5 et 1 aurait augmenté linéairement de 50% à 60%

pour la fréquence elle va passer linéairement de 550 hz à 595hz
et pour la période, cycle ou durée on passera de 550 à 500ms

le beep sera de plus en plus aiguë et de moins en moins long

cela donne un vario super sympa au niveau son même si on décidait arduino oblige de rester sur une table fixe de 10 ou 15 valeurs

Prunkdump qu’en pense tu ? La bibliothèque beeper peut-elle être modifiée pour permettre ce type de fonctionnement ?

Pas besoin de faire varier le volume, tu vas économiser des valeurs

le volume ne me parait pas le plus compliqué, c’est la durée. Pour le reste je pense que la bibliothèque beeper avec quelques calculs en plus devrait pas poser de problème.

Chez syride ils n’ont pas de possibilité de faire varier la durée, on voit une net différence au niveau son, le modéle XC Tracer est nettement plus agréable à l’oreille

Merci Baptiste!
Bon le problème venait de la carte SD… La partition était “foireuse” (lisible en lecture seulement sous OSX mais inscriptible sous linux… bref le petchi! :grrr: )
J’ai pu tester avec tout les FIRM et ça semble operationel aujourd’hui (écran avec version 631 et création de fichier GPX sur la carte… :trinq: Reste a tester en vol pour voir mes traces… C’est dommage car ce WE je l’ai pris lors d’un stage Cross donc en utilisation du vario seulement.
Mon retour:
les écrans sont clairs et bien lisibles, l’autonomie est effectivement insuffisante pour une utilisation en cross. la batterie a rendue l’âme au bout de 1h15, j’avais une batterie externe USB mais un conseil pour un upgrade serait le bienvenu.
Au niveau du son du vario, le volume est parfait a mon gout (ni trop fort, ni trop faible). Par contre parfois le son me laissait penser que je montais (bip bip aigu) alors que le vario indiquait du -0.2 a -0.5…
Dans les suggestions d’infos complémentaires, la distance parcourue serait appreciable en plus du temps de vol qui est deja super avec l’heure en alternée.
Et en plus de la vitesse, est-ce qu’on pourrait donner le CAP sous un format a determiner :ange: ?
Merci

Une piste pour tester plein de choses, et près de la réalité : pouvoir rejouer le fichier trace d’un vol (.igc).
Je n’ai aucune idée de la complexité que ca représente …

Hello,

Jpg63, la troisiéme valeur sur le XC tracer (50 dans ton exemple), ça n’est pas le volume, mais le duty-cycle, c’est a dire le ratio temps ON / temps OFF lors d’un bip.
100% = bip continu sur toute la durée du second chiffre. 50% = bip la moitiée de la durée / off l’autre moitié

Actuellement, ce que tu décris est déjà le fonctionnement du gnuvario (bip linéairement plus aigu et plus court en fonction du taux de montée).

Ce qui rend le son plus sympa sur le simulateur, c’est (je pense…) la gestion des transitions lors du changement de bips, qui sont moins brutales.
Il me semble avoir lu sur le forum PJRC (fabricant de la teensy) que Koni de Xctracer avait un peu galéré avec ça, faudra que je retrouve les discussions.

Également, pour avoir un son plus agréable, il faut jouer des “chirps” (ou swept frequency) plutot que des bip à fréquence constante. (pour un seul et même “bip”, on module trés légèrement la fréquence entre le debut et la fin).

Voila, je connais la théorie mais pour coder ça, j’en suis incapable :tomate:

Par contre je prépare une application PC pour faciliter le changement des paramètres, et recompiler sans avoir a rentrer dans le code ni passer par l’IDE arduino.
Ca devrait permettre aussi une simulation minimaliste du son. (comme sur l’outils au dessus mais en moins détaillé).
(windows only dans un premier temps malheureusement, sorry !)

Merci pour l’explication, j’ai analysé la réduction du bip par une réduction du volume alors que c’est une réduction de la durée du bip

[

En fait je me suis mal exprimer, effectivement notre petit vario a une variation linéaire mais sur une zone de 0 à +10m/s alors que le simulateur a des variations linéaires entre 2 valeurs (+0.5 - +1.0)

Je pense que tu as raison le plus gros plus vient d’une petite modulation, à voir comment elle est réalisée

voila un tester de son pour essayer divers paramètres

Avec le code c’est mieux

Salut à tous !

Je voulais juste m’excuser pour les messages qui me sont adressés auquels je n’ai pas pu encore répondre :trinq:

Je suis toujours un peu dans la merde à rattrapper mes conneries au Taff :? Mais je pense avoir fini d’ici un ou deux jours et je relirai les messages précédents.

Il me tarde de recommencer à bosser avec vous ! Amusez vous bien :ppte:

OK, je regarde ton testeur

Question :
je ne voie pas la tendance sur 10s
j’ai l’affichage de Prunk.
Rappelle-moi comment on passe sur le tien ? merci

Pour Mon code tu sauvegarde ton variosetting.h, tu copie mes sources à la place des officielles variometer.ino, varioscreen.h, varioscreen.cpp (tu décompresses le zip à la racine, tout les fichiers se placeront au bon endroit) et tu compare mon variosetting.havec le tiens pour remettre tes paramètres

Tu peux aussi utiliser la version portable que j’ai publié, la tout est expliqué et simple car c’est presque tout automatique.

Par contre attention le dernier code testbeeper.ino, ne fait que un test à vide, tu mets le testbeeper.ino dans un répertoire du même nom et tu compile. le FIRM.HEX affiche le vario et bip. Le vario débute à -9.9m/s et va jusqu’à +9.9m/s en ajoutant +0.1m/s toutes les 0.5sec. Ce code te permettra de tester des paramètres sans voler.

Pour la tendance elle est sur 6 sec et le code correspond à la version 63.1 quelques posts plus haut

bon vol

:pouce: perfect
je te tiens au jus de mes expériences