DIY GnuVario : variomètre opensource - openhardware Arduino

[ptitkiki]

hello,
Je suis en train de finaliser une petite appli PC de simulation du son. (un peu comme celle du xc tracer, en plus minimaliste, et basée sur les variables et la méthode de programmation actuelle du GNUvario.
(dans un second temps, j’essaierai de la brancher sur des vrais enregistrements de trace, si j'en trouve à assez haute fréquence d'enregistrement de la vz)

Pour le calcul de la fréquence du bip, c'est assez claire: une relation entre Vz et 2 variables:

/* 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

par contre, pour la durée du bip, je ne suis pas sur de bien comprendre l'algo...
L'un de vous pourrait-il me le donner, en fonction des différente variables?

Ca doit se passer par la :

/* 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)

et un peu :

/* 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

voir

/*******************************************/
  /* does the position depends on velocity ? */
  /*******************************************/
  if( !haveAlarm &&
      beepType == BEEP_TYPE_CLIMBING ) {
    currentLength *= (beepVelocity * CLIMBING_BEEP_VELOCITY_FILTER_COEFF + CLIMBING_BEEP_VELOCITY_FILTER_BASE);

mais des trucs m'échappent...

merci d'avance !

[ptitkiki]

ptitkiki toutes les infos sur xctracer me seront utiles, n’hésite pas à m'expliquer comment il réagit. Perso par exemple sur mon syride, je suis frustré de ne pouvoir paramétrer, que la fréquence. On s'en rend déjà compte avec les outils de paramétrage en ligne. En l'air je trouve le son du syride un peu agressif, plus agressif qu'un flymaster NAV (que j'ai pu tester), par contre je n'ai jamais volé avec un Xc tracer  

Hello,

en fait, je ne connais du XC tracer que l'appli en ligne, et quelques discussions glanées sur des forum... je ne l'ai même jamais eu en main...
Par contre, l'appli me semble assez clairz sur la manière dont c'est programmé (sauf la gestion des transitions , pour laquelle je ne suis d'ailleurs pas certain que l'appli soit fidéle à ce qui sort en vrai du produit...
Je ne serai pas surpris que dans la vrai vie ça soit moins smooth que sur le simulateur.  Quelqu'un qui en a un pourrait nous dire?

[Van Hurlu]

Grace au testbeeper j'ai pu baisser la progression de la monté dans les tours

C'est loin de la perfection du Tone simulator, mais au moins on n'a plus l'impression qu'il va exploser passé les 2m/s

les valeurs que j'utilise en attendant que vous trouviez une solution plus agréable à l'oreille
dans le fichier librairies/beeper/beeper.h

/* climbing beep sound freq computation : BEEP_FREQ_COEFF * velocity + BEEP_BASE_FREQ */
#define CLIMBING_BEEP_BASE_FREQ 1000.0
#define CLIMBING_BEEP_FREQ_COEFF 40.0  /*ori 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.1   /*ori 0.5 */

  l'alarme de descente commence à -2. Je ne trouve pas ou elle est ? je la préfère à -3
l'alarme de descente n'a aucune progression, c'est le même son de -2 à -10.

[jpg63]

Merci pour tes tests Van Hurlu

la fréquence est calculer comme ça :

    beepFreq = CLIMBING_BEEP_FREQ_COEFF * velocity + CLIMBING_BEEP_BASE_FREQ;

#define CLIMBING_BEEP_FREQ_COEFF 40.0  /*ori 150.0*/

si j'ai bien compris

fréquence du bip = 40 hertz *  vario + 1000 Hertz

currentLength *= (beepVelocity * CLIMBING_BEEP_VELOCITY_FILTER_COEFF + CLIMBING_BEEP_VELOCITY_FILTER_BASE);

pour la durée c'est un peu moins clair

[prunkdump]

Salut !

J'ai eu le temps de regarder un petit peu les simulateurs ! Honnêtement je trouve le coup des tables avec 10 ou 15 valeurs vraiment excessif. Et puis ce n'est pas si facile à régler avec tous ces points sur le graphique    

Juste deux points aux extrémités pour le bip de monté et deux points pour le bit de descente me semblent grandement suffisant. Après il suffit de faire une interpolation linéaire ou logarithmique entre les deux.

Je vous ai calculé les valeurs correspondant au réglage par défaut du XCTracer :

Code:

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

/* length of beep in vertical meters */
#define CLIMBING_BEEP_HIGH_LENGTH 0.5
#define CLIMBING_BEEP_LOW_LENGTH 0.5

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

Principe actuel du bippeur :

Donc effectivement pour la fréquence c'est simple. Si "v" est la vitesse verticale on calcule la fréquence ainsi :

freq = BEEP_FREQ_COEFF * v + BEEP_BASE_FREQ

Pour l'alternance des bips il faut s'imaginer un genre d'échelle verticale. Par exemple avec :

Code:

#define CLIMBING_BEEP_HIGH_LENGTH 0.5
#define CLIMBING_BEEP_LOW_LENGTH 0.5

il faut imaginer une echelle verticale avec des barreaux de 0.5 mètres. Chaque fois que le vario passe devant un barreau de l'échelle il alterne entre "son" et "silence". Ca me permettait de "visualiser" un petit peu l'influence des paramètres. Au départ je pensais que ça serait suffisant. Mais du coup si on en reste là on ne peut pas régler à quelle vitesse l'alternance des bips accelère.

C'est pour ça qu'il y a un aussi un "filtre" sur la vitesse qui marche comme cela :

vitesse filtré =  vitesse * BEEP_VELOCITY_FILTER_COEFF + BEEP_VELOCITY_FILTER_BASE

Donc par exemple avec les paramètres que j'ai donné. A une vitesse de v=2.0m/s.

-> La vitesse est filtré est de vf = 2.0 * 0.51 + 1.62 = 2.64 m/s
-> comme les "barreaux de l'échelle" sont de 0.5m et que l'on monte à 2.64m/s la durée du bip est de :

t = d/v = 0.5/2.64 = 0.19 s

Et donc la durée du cycle est de 0.38 s.

Voilà ! J'espère que je ne vous ait pas trop embrouillé.

Principe futur du bippeur ?
 
Mais il va falloir que je reprogramme la bibliothèque "beeper" de toute façon alors autant repartir sur quelque chose de plus simple. On pourrait par exemple :

Avoir deux ensembles de courbes (linéaires dans un premier temps)
1) un pour le bip de monté
2) un pour le bip de dégeulante

Pour le bip de monté l'utilisateur choisit :
-> la fréquence du bip à 0m/s et à 10m/s
-> la durée du cycle à 0m/s et à 10m/s
-> le pourcentage de bip sur le cycle à 0m/s et à 10m/s

Pour le bip de degeulante l'utilisateur choisit :
-> la fréquence du bip à 0m/s et à -10m/s

Si certain sont motivé pour faire le simulateur    Mais peut être que ça serait possible de modifier celui de XCSoar pour qu'il n'y ai que 4 points.

A+

edit : VanHurlu pour régler le seuil de dégueulante c'est dans VarioSettings.h avec le paramètre "#define VARIOMETER_SINKING_THRESHOLD -2.0"

[Van Hurlu]

edit : VanHurlu pour régler le seuil de dégueulante c'est dans VarioSettings.h avec le paramètre "#define VARIOMETER_SINKING_THRESHOLD -2.0"

.
  merci
quand il sera progressif je le remettrai à 2.5

[jpg63]

Je trouve que l'on pourrait gérer quelques valeurs intermédiaires pour permettre des réactions différentes pour les vitesses verticales basses, moyennes et hautes

on pourrait avoir des zones avec une courbe linéaire et 2 valeurs Frequences et durée

en fonction du vz on regarde entre quelles valeurs on se trouve, on calcule le coefficient directeur b l'ordonnée à l'origine pour la zone

exemple

   {-10.00, 200, 100, 100},
   {-3.00 , 280, 100, 100},
   {- 0.51 , 300, 500, 100},
   {- 0.50 , 200, 800, 5  },
   {   0.9 , 400, 600, 10 },
   {  0.10 , 400, 600, 50 },
   { 1.16 , 550, 552, 52 },
   { 2.67 , 763, 483, 55 },
   { 4.24 , 985, 412, 58 },
   { 6.00 ,1234, 322, 62 },
   { 8.00 ,1517, 241, 66 },
   {10.00 ,1800, 150, 70 }

si on a +1.5
on prends pour la fréquence une courbe linéaire de 550 à 763   avec un vz qui varie de 1.16 à 2.67     avec  freq = a * vz + b   

on fait la même chose pour la durée

le simulateur est déjà réalisé et le calcul reste simple
 

[ptitkiki]

hello,

merci prunkdump pour les explications  

Je suis assez d'accord qu'avoir plein de points est surement overkill.

Et même avec moins de points, on peut utiliser le simulateur du XCtracer, il suffit de ne gérer que les extrémités et distribuer linéairement entre les deux.
La seul condition, est de paramétrer les points sur 3 variables : frequence / durée / duty cycle.

Perso, je pense qu'il vaudrai mieux travailler sur les transitions (faire une sorte de blend progressif entre 2 frequences consécutive, et/ou éventuellement regarder les chirps)

je vais quand même finir pour le fun mon simulateur, avec l'algo actuel et le nouveau proposé par baptiste. On pourra comparer. J’enverrai ça ce soir si tout va bien.

[prunkdump]

Salut !

Je me suis amusé et j'ai fait un simulateur aussi  .

Oui c'est vite fait en une heure    juste pour montrer ce que pourrait être une version simplifiée. Si vous voulez le tester il suffit de télécharger Geogebra ici :

Windows :
https://download.geogebra.org/package/win-port
Mac :
https://download.geogebra.org/package/mac
Linux :
https://download.geogebra.org/package/linux-port

Et vous ouvrez le fichier en pièce jointe.

Je ferais quand j'aurais un peu de temps une version qui affiche les valeurs pour le vario.

A+

[ptitkiki]

baptiste : globalement, c'est clair, juste un truc :

 Dans ton exemple, tu parles de:
#define CLIMBING_BEEP_HIGH_LENGTH 0.5
#define CLIMBING_BEEP_LOW_LENGTH 0.5

mais pas de:
#define CLIMBING_BEEP_LENGTH (CLIMBING_BEEP_HIGH_LENGTH + CLIMBING_BEEP_LOW_LENGTH)

et ensuite tu écris:

t = d/v = 0.5/2.64 = 0.19 s

du coup, je ne sais pas si tu fait référence à high length ou low length, ni si à un moment tu utilise la somme des deux? (beep lenght)

pour être sur, tu peux redonner stp l'exemple avec
#define CLIMBING_BEEP_HIGH_LENGTH 0.5
#define CLIMBING_BEEP_LOW_LENGTH 0.25 ?

merci d'avance !

[ptitkiki]

wow, t'es trop rapide !

merde, moi qui pensais enfin pouvoir faire un truc pour la communauté, tu m'as grillé, et multi OS en plus  !
bon, je ne regrette pas, j'ai encore appris pas mal de truc dans l’opération. Je vais terminer le mien quand même

[ptitkiki]

voici une petite video du draft de mon simulateur (basé sur le fonctionnement actuel du beeper).

C'est moins visuel car pas encore les courbes, mais ça permet de tester facilement l'effet de chacune des variables. (d'ailleurs, je confirme qu'il y en a surement trop pour l'instant...)
je vais faire un second onglet avec la config "futur beeper"

http://vimeo.com/223367277

[nightrider]

Merci JPG63 et Baptiste, 
Effectivement le fichier ne se créait pas pour 2 raisons: premièrement a cause du problème lorsque le boitier est fermé en serrant les vis a fond, et ensuite a cause des conditions de début d'enregistrement.
Du coup j'ai essayé de recompiler tout ca pour avoir un fichier IGC avec un entête propre avec mes infos car celui que j'avais chargé avec le FIRM.hex 631 direct de JPG63, ne contenait que des données GPS.
Reste encore un soucis de date car logfly l'interprétait comme un vol de l'an 2000... curieux non? J'avais cru lire que ce pb etait corrigé.
Bravo encore pour le projet et une grand MERCI pour le support! Vous etes au top les gars!

[jpg63]

super nightrider,

je te confirme les derniers codes, corrigent le problème normalement

essai de récupérer les derniers sources sur le github et remplace les fichiers d'origines par mes dernières sources en version 63.1, sauf le variosetting.h qui contient tes paramètres et ré essais


Pour la gestion du son, je me demande si il ne serait pas intéressant d'avoir un son différent, donc une pente, pour les dégueulantes, car il est fort pratique de connaitre si on est à -2, -4 ou -6/-8
à -2m/s on descend plus vite que le taux de chute moyen (-1.5m/s) donc il ne faut pas trop rester dans la zone
à -4m/s on est certainement dans la partie descendante du thermique, il doit être devant, ça va remonter, un petit coup d'accélérateur
à -6/-8m/s la on est certainement coincé par l'effet bagnard, il va falloir contourner rapidement la zone et tout pousser à font sinon c'est le  posé assuré     

[Van Hurlu]

Je vous ai calculé les valeurs correspondant au réglage par défaut du XCTracer :

Code:

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

/* length of beep in vertical meters */
#define CLIMBING_BEEP_HIGH_LENGTH 0.5
#define CLIMBING_BEEP_LOW_LENGTH 0.5

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

  testé et approuvé ... c'est mieux que mes valeurs au pif  

Pour la gestion du son, je me demande si il ne serait pas intéressant d'avoir un son différent, donc une pente, pour les dégueulantes, car il est fort pratique de connaitre si on est à -2, -4 ou -6/-8

Prunkdump nous a annoncé que c'était prévu

[nightrider]

Bon y'a visiblement (encore) un truc qui m'échappe dans la procédure de compilation du variosettings car le FIRM.HEX n'intègre pas mes données personnelles... le fichier IGC généré n'a pas d'entête.
Voici ma procédure pas à pas en partant du principe que l'arborescence est conforme a Github et les fichiers spécifiques de jpg63 remplacent ceux de Baptiste (l'écran du Vario affiche bien la version 6301 après la mise sous tension et affiche qu'un écran avec certaines données qui s'alternent):

1) modifier le fichier VarioSettings.h avec un editeur de texte et saisir ses données personnelles (nom pilote, etc...)
2) ouvrir le fichier SetvarioParameters.ino et vérifier/compiler le code (Ctrl+R)
3) ouvrir le fichier Variometer.ino et vérifier/compiler le code (Ctrl+R) et exporter les binaires compilés (Ctrl+Alt+S)
5) renommer le fichier variometer.ino.eightanaloginputs.hex en FIRM.HEX
6) copier le fichier FIRM.HEX sur la carte SD
7) Mettre a jour le firmware du vario et l'allumant écran face au sol, attendre les 3 bips et le retourner en attendant le redémarrage

Qu'est-ce que je rate???

Super idée un son différent par type de dégeulente surtout pour l'effet bagnard

[Van Hurlu]

Qu'est-ce que je rate???

1) modifier le fichier VarioSettings.h avec un editeur de texte et saisir ses données personnelles (nom pilote, etc...) + les nouvelles valeurs pour le vario (voir mon post ci-dessus)
2) ouvrir le fichier SetvarioParameters.ino et exporter les binaires compilés (Ctrl+Alt+S)
   renommer le fichier SetvarioParameters.ino.eightanaloginputs.hex en FIRM.HEX
   copier le fichier FIRM.HEX sur la carte SD
   Mettre a jour le firmware du vario et l'allumant écran face au sol, attendre les 3 bips et le retourner en attendant le redémarrage

3) ouvrir le fichier Variometer.ino et vérifier/compiler le code (Ctrl+R) et exporter les binaires compilés (Ctrl+Alt+S)
5) renommer le fichier variometer.ino.eightanaloginputs.hex en FIRM.HEX
6) copier le fichier FIRM.HEX sur la carte SD
7) Mettre a jour le firmware du vario et l'allumant écran face au sol, attendre les 3 bips et le retourner en attendant le redémarrage



Dans l'étape 2, tu oublies qq étapes.
J'ai moi aussi bien galéré à comprendre. Ce qui est évident pour certains ne l'est pas pour tous  

cette manip, c'est pour rentrer  (nom vario, nom pilote, nom aile)
tu ne fais ça qu'une fois
après tu peut faire les maj de ton firm ces infos restent

[nightrider]

   MERCI! ca c'est la procédure pour les nulles que j'attendais... a integrer dans un fichier FAQ pour les nulles   

[Van Hurlu]

Pour le signal des étapes d'enregistrement :

Pour moi ça serait plus logique clignotant d'abord et fixe ensuite. Non ?

J'ai enfin compris d'ou vient ma logique
quand on filme il y a toujours un point rouge clignotant qui nous dit qu'on enregistre.

Ce qu'a fait JPG est excellent 

Par contre ??? mon enregistrement démarre automatiquement maintenant ?
pourtant j'ai bien
#define VARIOMETER_RECORD_WHEN_FLIGHT_START

[jpg63]

Pour le signal des étapes d'enregistrement :

Pour moi ça serait plus logique clignotant d'abord et fixe ensuite. Non ?

J'ai enfin compris d'ou vient ma logique
quand on filme il y a toujours un point rouge clignotant qui nous dit qu'on enregistre.

Ce qu'a fait JPG est excellent 

Par contre ??? mon enregistrement démarre automatiquement maintenant ?
pourtant j'ai bien
#define VARIOMETER_RECORD_WHEN_FLIGHT_START

c'est bizarre, avec le #define l'enregistrement devrait commencer avec   une vitesse de 8km/h dans mon cas sinon 10Km/h et un vario > à + ou - 0.5

        /* check flight start condition */
        if( (millis() > FLIGHT_START_MIN_TIMESTAMP)
#if defined( VARIOMETER_RECORD_WHEN_FLIGHT_START )       
          && (kalmanvert.getVelocity() < FLIGHT_START_VARIO_LOW_THRESHOLD || kalmanvert.getVelocity() > FLIGHT_START_VARIO_HIGH_THRESHOLD) &&
            (nmeaParser.getSpeed() > FLIGHT_START_MIN_SPEED)
#endif   //defined(VARIOMETER_RECORD_WHEN_FLIGHT_START)           

#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 8.0

[Van Hurlu]

@JPG
   tutto va bene
J’ai refait un test à l'instant, l'enregistrement ne démarre plus tout seul, il faut que je coure dans l'escalier.

il ne manque plus que la MTO

[prunkdump]

Ouai la météo c'est pas ça en se moment ... 

Super Ptikiki le simulateur ! Les transitions lors des changements de fréquences sont vraiment fluides ! Le mien est beaucoup plus "sale" ...  Apparement tu as tout compris sur l'algorithme de génération des bips. Plus qu'à faire les deux courbes !

Je vous met en pièce jointe un simulateur qui donne les paramètres du vario en fonction des deux courbes. Il faudrait que tu adaptes un truc du genre dans ton programme. Pour ceux qui veulent tester il faut télécharger Geogebra ici :

https://download.geogebra.org/package/win-port
https://download.geogebra.org/package/mac
https://download.geogebra.org/package/linux-port

Correctif sur le fonctionnement du bipper :

En faisant le simulateur je me suis rendu compte que la variation de la durée des cycles n'est pas une fonction linéaire dans le GnuVario mais une fonction inverse.

Donc l'allure des courbes est différente du XCTracer (cf: le simulateur)

Mais (sans me vanter  ) je trouve ça mieux car du coup les longueurs de cycle varient plus vite sur les faibles ascendances et moins vite sur les grosses.

Ptikiki n'hésite pas si tu veux les formules des courbes !

[jpg63]

j'ai fais écouté à ma compagne ton simulateur Prunkdump et celui de xc tracer

je vous livre son sentiment

elle trouve le son du simulateur xc tracer est moins stressant et plus pertinent

je pense que la durée devrait respecter une pente normale - vz faible, durée du son faible et silence long
pour la fréquence, sur le xc tracer on dirait que le son est plus feutré, moins stressant pourtant on a la même fréquence, je ne sais pas pourquoi

Avec les simulateurs on va trouver un super son, faire des essais  c'est vraiment bien

[prunkdump]

Salut Jpg63 !

Sympa que tu ai pu tester ! Mais sur mon simulateur il ne faut pas faire attention à la "qualité" du son. Il est générée avec une sinusoïde qui ne correspond pas à ce que est envoyé au buzzer au vario.

Sur geogebra on n'a pas de contrôle réel sur le "ton" du son. Et d'ailleurs je ne suis pas sur que le son du simulateur du XCTracer ressemble à selui du vario réel.

Il faut juste écouter la fréquence du son et la longueur de la boucle. Sur le XCTracer la variation de cette longueur de boucle est linéaire et je trouve que du coup il faut vraiment des gros thermiques pour que ça accélère.

D'ailleurs sur l'ancienne version du simulateur la courbe était en trois segments qui ressemble justement à la fonction inverse. Il y a aussi l'avantage que la fonction inverse tend vers 0 et pas une fonction linéaire.

Le simulateur c'était surtout pour pouvoir trouver un réglage de base du vario et essayer de chercher avec Ptikiki comment modifier les paramètres des courbes.

[jpg63]

Salut Jpg63 !

Sympa que tu ai pu tester ! Mais sur mon simulateur il ne faut pas faire attention à la "qualité" du son. Il est générée avec une sinusoïde qui ne correspond pas à ce que est envoyé au buzzer au vario.

Sur geogebra on n'a pas de contrôle réel sur le "ton" du son. Et d'ailleurs je ne suis pas sur que le son du simulateur du XCTracer ressemble à selui du vario réel.

Il faut juste écouter la fréquence du son et la longueur de la boucle. Sur le XCTracer la variation de cette longueur de boucle est linéaire et je trouve que du coup il faut vraiment des gros thermiques pour que ça accélère.

D'ailleurs sur l'ancienne version du simulateur la courbe était en trois segments qui ressemble justement à la fonction inverse. Il y a aussi l'avantage que la fonction inverse tend vers 0 et pas une fonction linéaire.

Le simulateur c'était surtout pour pouvoir trouver un réglage de base du vario et essayer de chercher avec Ptikiki comment modifier les paramètres des courbes.

OK

on peut faire des vrais tests de son avec mon bout de code, on peut mettre les valeurs du simulateur dans le code du gnuvario ? les courbes du simulateur correspondent au code de la librairie beeper ? Est-il facile d'avoir une courbe non inverse de la durée dans beeper.cpp ou faut-il tout réécrire ? pour tester et voir la différence