DIY GnuVario : variomètre opensource - openhardware Arduino

#741

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)
  4. renommer le fichier variometer.ino.eightanaloginputs.hex en FIRM.HEX
  5. copier le fichier FIRM.HEX sur la carte SD
  6. 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

#742

[quote]Qu’est-ce que je rate???
[/quote]

  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)

  4. renommer le fichier variometer.ino.eightanaloginputs.hex en FIRM.HEX

  5. copier le fichier FIRM.HEX sur la carte SD

  6. 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 :mrgreen:

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

#743

:vol: MERCI! ca c’est la procédure pour les nulles que j’attendais… a integrer dans un fichier FAQ pour les nulles ROTFL

#744

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 :pouce:

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

#745

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

#746

@JPG
:pouce: 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

#747

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 :oops: ) 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 !

#748

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

#749

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.

#750

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

#751

Oui exactement ! Le meilleur test pour voir le rendu du son sur le GnuVario c’est ton prog :pouce:

Effectivement on peut mettre les valeurs de mon simulateur dans le GnuVario directement et les courbes correspondent à la version actuelle du code. Cela fonctionnera donc pour la fréquence, la durée des boucles et le pourcentage “duty”. Mais pas pour le “timbre” du son.

Pour améliorer le “timbre” il faut travailler sur la bibliothèque toneAC qui génère le son ou sur l’électronique.

Malheureusement il n’est pas possible de changer le code facilement pour avoir une variation des durées de boucle linéaire… :? Mais quand les simulateurs fonctionnerons bien on pourra essayer de comparer sur simulateur. A la base Geogebra c’est juste pour faire des Maths :smiley:

A+

#752

karma+ J’avais fait il y un moment quelques essais dans ce sens (bi-ton et autre) à mon avis ça doit être super sympa si on le gère.
Et ça donnerai une “signature” sonore différente

Sinon d’accord sur le fait que un tableau de 10-15 valeurs c’est overkill. A mon avis 5-6 valeurs seraient pas mal.
Je trouve assez sympa d’avoir au moins une double pente (ou un log) lors de la montée dans les tours.

#753

Je suis assez d’accord avec Xiboard, 5 ou 6 valeurs pour avoir plusieurs pentes ce serait vraiment pas mal

Effectivement le plus gros travail va être d’améliorer le timbre en commençant par gratter la bibliothèque toneAC

coté électronique on pourrait regarder pour un vrai circuit audio mais je suis pas certain que cela change vraiment la qualité audio. C’est plutôt le buzzer qu’il faudrait peu être changer

http://www.ti.com/product/TPA6211A1

#754

Je peut essayer de modifier mon simulateur pour jouer le son directement sur le vario, et non en émulant sur la carte son. (avec une liaison série entre l’apli PC et le vario)
Ca serait l’ideal : combinaison de son réaliste et d’ergonomie dans la simulation. (visu courbes, curseur etc.)

Par contre, Il faudra pour l’instant passer par les pins RX/TX et un convertisseur serie-usb externe, car malheureusement la micro n’a pas d’usb intégrée.

Et J’aurai surement besoin d’un coup de main pour le code coté arduino, même si ça ne parait pas trés compliqué.
Je tenterai dés que j’ai un peu de temps, je vous tiendrai au jus…

#755

En essayant d’imaginer le plus simple/efficace
Il faut au moins 3 plages de variation :

  • variation du volume
  • variation de la fréquence des bips
  • variation de la tonalité du bip

https://i11.servimg.com/u/f11/12/58/57/57/chantd10.jpg

à la place d’une courbe log, on peut aussi mettre des variations linéaires entre 5 points

https://i11.servimg.com/u/f11/12/58/57/57/chantd11.jpg

La partie -VZ peut être du même genre, sans la variation de volume et avec moins de points pour la courbe

Pour la qualité du son, il faut trouver autre chose que notre buzzer, c’est sur :mrgreen:

#756

Hello,

Merci pour les courbes.

Je pense que la variation de volume est superflue. Tout ou rien c’est OK, avec un contrôle global du volume comme actuellement.

Et la variation de fréquence (intervalle) en fonction inverse plutôt que linéaire.

Amha…

#757

la variation de volume est là pour la partie zérotage

#758

:+1: pour ta proposition Van Hurlu

Par contre je pense que pour le volume, on peut plutôt envisager une zone de zérotage - dès que l’on active le zérotage on gère la zone différemment - son et volume différent - si on n’active pas le zérotage on suit la courbe de vol

#759

concernant la qualité audio, je confirme qu’il suffit d’un bête ampli.
Par contre, le buzzer doit être absolument remplacé par un vrai haut parleur et le PWM se transforme en son mélodieux :slight_smile:
Il est meme possible de faire de la polyphonie en mixant plusieurs PWM :wink:

#760

Pour le HP on pourrait peu être essayer ce genre la

http://www.ebay.fr/itm/Mini-speaker-mini-haut-parleur-type-2030-20x30x5mm-1Watt-8Ohm-IOT-Arduino-ARM-PI-/282252863863?hash=item41b794e977:g:xFgAAOSw9N1V2Bhe