Variomètre maison à base d'Arduino

[Sinseman]

Oui pour l'écran j'ai aussi l'impression que c'est la partie métallique autour qui pose soucis.
Côté batterie il ne serait pas impossible que se soit plus l’électronique qui fait défaut plutôt que le code. En effet je ne suis pas un pro en câblage, et j'ai peut être omis de relier quelque chose à la masse ou autre...

Sinon tu fais bien de poser la question pour l'emplacement du codeur. Après avoir fait quelques vols avec ce vario, et le mettant sur le pod de mon parachute de secours, je me suis retrouvé plusieurs fois en vol à avoir des appuis de ma ventrale sur le bouton. Ce qui a donc pour effet de soit retourner au menu, soit lors d'un appui long de remettre à zéro la plage de stat en cours... Pô cool...
Donc oui peut être mettre le codeur sur un côté pour éviter ce genre de situation, ou alors fixer le vario sur les élévateurs.

Concernant l'ajout de bips fais toi plaisir. Ça ne devrait nécessiter que quelques lignes de code. Tu peux t'inspirer de la fonction playConfirmMelody() pour ça.

[Xiboard]

J'avais bien repéré cette fonction en effet

Je ferrais quelques essais pour la batterie. Je vais regarder ça de plus près.
Comment as tu déterminé la résistance de 100 kO sur l'accu ?

[Sinseman]

J'avoue que pour la résistance de 100Kohm je l'ai mise un peu au pif pour réduire l'intensité à l'entrée A0.

Mais dans l'absolue il faudrait surement faire un pont diviseur de tension comme ici.

[Xiboard]

Ahah justement, si tu regarde le dernier commentaire c'est moi !

Il n'y a aucune intensité. Donc pas de résistance nécessaire. On peux câbler direct la batterie sur l'A0. Pas besoin de pont div : on dépassera pas les 5V.
Je vais tester ça ce soir, je n'ai justement pas encore finalisé la connexion batterie/inter etc...

[Xiboard]

Et dans ton code tu place le 100% pour 3.7V : c'est à vérifier. Je pense que c'est plus, non ?
En tout cas c'est 4.1 pendant la charge. (Bon, on peux considérer que l'on a pas à utiliser le vario pendant la charge...)

A voir aussi pour rajouter une alerte sonore lorsque la batterie est faible et désactiver le rétroéclairage.
En espérant que tout ça passe dans le nano.

[Sinseman]

Cool, bah c'est peut-être ça le souci, la résistance 100Kohm.

Sinon en effet quand ça charge la tension doit monter à plus de 3.7V il faudrait faire des tests. Ça dépend surement de chaque batterie. Pour ma part j'avais pris une plage entre 3.3V (batterie à 1%) et 3.7V (batterie à 100%) dans la fonction readVccPercent() mais vu que je n'avais jamais eu un résultat fiable j'ai pas trop creusé si c'était OK.

Tout ce que je sais c'est qu'une batterie lithium-ion se décharge brutalement en fin de charge donc difficile de trouver la plage adéquate.



Limite il faudrait pour chaque type de batterie faire des tests et tracer avec un outils comme Processing sa courbe de décharge.

Et n'hésite pas à faire des demandes de "pull" sur GitHub si tu ajoutes quelques fonctionnalités sympa 

[Xiboard]

J'ai trouvé le pb de la batterie :

Je ne sais l'expliquer mais :
uint8_t percent = round((average_vcc - 3100) * 100 / (4100 - 3100));

ne marche pas ! Ce calcul n'est pas faux, en tout cas il me semble mais ça marche pas.

J'ai remplacé par :
uint8_t percent = map(average_vcc,3000,4100,0,100);

Du coup ça marche impec. 
A ajuster avec les valeurs voulus.
En tout cas pour moi avec mes valeurs de mon accu. (Je le charge avec un chargeur modélisme qui me donne pas mal d'infos)

Après effectivement la loi voltage/% n'est pas proportionnelle en temps. Donc on pourrait compliquer l'évaluation du % avec un formule à déterminer à partir de ton graph par exemple !

J'ai encore jamais mis les mains dans github mais whynot.

[JC - MARSEILLE PARAPENTE]

Salut

Je ne comprends rien a vos formules mais c est génial ce que vous faites !!

Jc

[stepson]

Je ne sais l'expliquer mais :
uint8_t percent = round((average_vcc - 3100) * 100 / (4100 - 3100));

ne marche pas ! Ce calcul n'est pas faux, en tout cas il me semble mais ça marche pas.

uint8_t percent = round(((average_vcc - 3100) * 100) / (4100 - 3100));

un problème de priorité des opérations. tel qu'écrit en dessus, je crois de mémoire (à vérifier) qu'il fait d'abord 100/(4100-3100) et du coup tu as (a-3100)*0,1 qui ne vas pas te donner la même chose que ((a-3100)*100)/1000 selon quand la conversion en entier se fait.

[thanjuzo]

un problème de priorité des opérations. tel qu'écrit en dessus, je crois de mémoire (à vérifier) qu'il fait d'abord 100/(4100-3100) et du coup tu as (a-3100)*0,1 qui ne vas pas te donner la même chose que ((a-3100)*100)/1000 selon quand la conversion en entier se fait.

Les parenthèses ne servent à rien, en somme ?

[stepson]

un problème de priorité des opérations. tel qu'écrit en dessus, je crois de mémoire (à vérifier) qu'il fait d'abord 100/(4100-3100) et du coup tu as (a-3100)*0,1 qui ne vas pas te donner la même chose que ((a-3100)*100)/1000 selon quand la conversion en entier se fait.

Les parenthèses ne servent à rien, en somme ?

si si tu les rajoute comme je l'ai suggéré pour forcer l'ordre des opérations, mais sur le code initial elles n'y sont pas... je me suis déjà fait piéger sur un vieux projet sur un truc comme ca. ca y ressemble fortement.

[Xiboard]

Je pensais à ça aussi et j'ai rajouter aussi des parenthèses sans succès bref map ça marche bien, c'est fait pour non ?

[Sinseman]

Yes en effet map c'est fait pour !
J'avais rencontré le même problème je me souviens et en mettant des parenthèses pour forcer les priorités ça ne donnait toujours rien.
Surement une limitation mémoire du matériel qui nous dépasse...

Bien joué !

[stepson]

 

[carambar]

Salut Sinseman, super boulot!!!
Tu t'es basés sur un code existant ou bien tu as tout réécrit toi même? Ayant voulu utiliser le même le même capteur de pression, je me suis très vite heurté au caractère très bruité du BMP180... Tu as utilisé quoi comme algorithme pour le filtrer ?
Enfin, tu peux te passer des trois résistances de Pull up sur D2, D3 et D12. Elles sont présentes en interne dans l'atmel. Il te suffit de les activer ainsi:
        // Configuration des broches 12, 3,2 en tant qu'entrees numeriques.
        pinMode(12,INPUT);
        pinMode(3,INPUT);
        pinMode(2,INPUT);
        // Activation du "internal pull-up" des broches 12,3,2.
        digitalWrite(12,HIGH);
        digitalWrite(3,HIGH);
        digitalWrite(2,HIGH);
Bon vol!!!!

[marcus]

Je ne sais l'expliquer mais :
uint8_t percent = round((average_vcc - 3100) * 100 / (4100 - 3100));

ne marche pas ! Ce calcul n'est pas faux, en tout cas il me semble mais ça marche pas.

Le type de donnée de la variable 'percent' est uint8_t, c'est à dire un entier non signé 8 bits. Par conséquent, il ne peut représenter que des valeurs entières entre 0 et 255.
Je ne connais pas le comportement exact du compilateur utilisé, mais si toute l'expression est calculée avec des entiers 8 bits, ça ne peut pas marcher.
En déclarant les variables en uint32_t je pense que le calcul devrait être correct.

[Xiboard]

@carambar

Oui c'est vrai ce que tu dit mais si je dit pas de bêtises la librairie 'Encoder' utilise les interruptions. Du coup je ne suis pas sur que cette méthode fonctionne. A moins de personnaliser le code de la librairie, et encore.
Par contre ça aurai pu être fait pour le push mais bon pour ce que coûte aussi 3 résistances et la sureté de ne pas avoir à gérer ça dans le code.

@marcus

Je pense aussi que ça viens du comportement du compilateur avec cet entier.
Mais sinon 'map' ça marche, non ?  ça permet d'éviter de mettre une variable en 32bits pour rien et au vu de l'occupation mémoire, c'est toujours ça de pris.
 

[Jérémie LeCouvert]

@marcus

Je pense aussi que ça viens du comportement du compilateur avec cet entier.
Mais sinon 'map' ça marche, non ?  ça permet d'éviter de mettre une variable en 32bits pour rien et au vu de l'occupation mémoire, c'est toujours ça de pris.

Je pense que vous ne prenez pas le problème dans le bon sens. Ça n'est pas la variable qui va recevoir le résultat final qu'il faut modifier mais les opérandes du calcul. Je ne connais pas (pas encore) le langage de l'Arduino mais dans les langages habituels il faut forcer le compilateur à passer provisoirement par des réels même si les variables utilisées comme opérandes sont des entiers. En général ça se fait en écrivant ".0" après un entier.

Ça donnerait donc ça :
uint8_t percent = round((average_vcc - 3100) / 10.0);

[Sinseman]

@carambar

N'ayant jamais fais d'Arduino au début j'ai cherché un projet de variomètre déjà en place et je me suis inspiré de celui-là.
Ça fonctionnait pour faire un simple bip mais vu que je voulais ajouter une interface graphique + des options + l'enregistrement des stats, il restait du chemin à faire.
Ce que j'ai entrepris petit à petit mais je me suis vite heurté à la limitation de ram de l'Arduino nano.

Pour la gestion du menu j'ai utilisé la librairie MenuBackend que j'ai dû un peu transformer et optimiser pour stocker les chaines de caractères en mémoire flash.
Le reste des librairies je les ai prise telles qu'elles.

Question filtrage du capteur de pression, sur le code du projet d'origine le codeur fait une moyenne des X dernière valeurs... Pas terrible car cela prend beaucoup de place en ram, espace qui nous est très précieux...
Du coup j'ai dû changer de méthode de filtrage (qui porte surement un nom que j'ignore) et j'ai fais comme cela :

A chaque interrogation du capteur je pondère sa réponse d'un certain pourcentage et j'ajoute son résultat à la valeur précédente du capteur, lui aussi pondéré d'un pourcentage de tel sorte que la somme des deux pourcentage soit égale à 100%.

Exemple : vario_ancienne_valeur = vario_ancienne_valeur * 0.8 + vario_lu * 0.2;

En gros ici la nouvelle réponse du capteur n'a que 20% de poids par rapport à l'ancienne valeur.
Cela à pour effet de lisser la réponse du capteur, mais en contrepartie de la retarder. Mais comme l'Arduino effectue une multitude d'interrogations par seconde, le temps de latence reste court, et le résultat beaucoup moins bruité. Le jeu consistant à équilibrer les pourcentages en faveur de l'ancien ou du nouveau résultat.

Cette méthode permet aussi de n'utiliser que deux variables flottantes dans notre code au lieu de X variables avec la méthode des moyennes et donc de soulager la ram, ce qui était aussi le but recherché.

Après dans l'ensemble oui j'ai écris moi même le sketch, mais en m'appuyant sur la documentation et les exemples immenses qu'on trouve sur Internet, et aussi grâce à l'aide d'un ami passionné d'Arduino qui m'a bien appris comment fonctionnait cette bestiole (les interruptions, les différents type de mémoire, ...)

Concernant les résistance en effet je pense que la réponse de @Xiboard est la bonne  

Et puis pour le reste la fonction map fonctionne à merveille, mais on pourrait également faire des test en ajoutant le .0 juste pour voir. Merci @Jérémie LeCouvert et @marcus

[Jérémie LeCouvert]

Ahah justement, si tu regarde le dernier commentaire c'est moi !

Il n'y a aucune intensité. Donc pas de résistance nécessaire. On peux câbler direct la batterie sur l'A0. Pas besoin de pont div : on dépassera pas les 5V.
Je vais tester ça ce soir, je n'ai justement pas encore finalisé la connexion batterie/inter etc...

Je n'ai pas encore eu le temps de bien étudier l'état de l'art concernant le branchement d'un buzzer piezo sur un microcontrôleur mais j'ai l'impression qu'il existe un risque non négligeable ! Non pas dans le courant demandé à l'Arduino lors de l'excitation du buzzer mais dans la tension générée par le buzzer lui-même lorsqu'il est "excité manuellement". Si on laisse tomber le vario par terre par exemple, cela va créer une onde qui va exciter le buzzer qui va lui-même ensuite retransmettre une tension très importante (bien au delà des 5V) à l'Arduino comme le ferait un microphone avec un risque de griller le micro-contrôleur.

Cf. ce post par exemple :
http://electronics.stackexchange.com/questions/58582/using-a-microcomputer-in-the-drive-circuit-of-a-piezo-buzzer

[Jérémie LeCouvert]

Je viens de voir que tu utilises la librairie 'ToneAC' (à l'origine je me demandais pourquoi tu n'avais pas branché une patte du buzzer à la masse) dont le créateur préconise le branchement tel que tu l'as fait. Je lui poserai la question par mail pour avoir son avis sur les "back EMF".

https://code.google.com/p/arduino-tone-ac/

[Sinseman]

Oui, j'avais utilisé cette librairie car elle permettait une meilleure restitution sonore et de faire varier le volume.

[Jérémie LeCouvert]

Oui, j'avais utilisé cette librairie car elle permettait une meilleure restitution sonore et de faire varier le volume.

La réponse du créateur de ToneAC sur le sujet :

A piezo can work just about as well as a microphone as it can a speaker.  So, a shock like dropping or tapping it can generate a large pulse current that will back-feed to the microprocessor.  While the voltage is high, the current is probably very low.  So even then, it's not very likely.  However, it's always good to provide some level of protection.

But, installing a diode is not the solution to this.  It's better to install a resistor to limit the back voltage.  With toneAC I suggest using a 100 Ohm resistor, which will limit the current and prevent a problem.  It's even more important NOT to use a diode with toneAC as the alternating current will nullify many of toneAC's advantages.

In any case, use about a 100 Ohm resistor inline with one of the pins when using a piezo buzzer.

[Xiboard]

Salut à tous,

Je viens de tester mon montage, non pas en parapente mais sur un moto-planeur de modélisme (1m80 d'envegure)
Mais malheureusement mon montage déconne complet :
ça bip dans tout les sens et ça même au sol au moindre mouvement, je comprenait rien...
chez moi dans la maison ça marchait bien.

Alors en faisant quelques test il semble que la cause soit la température. Dès que le soleil tapait sur le BMP180, la temp grimpe super vite. Et comme la temp est utilisée pour le calcul de l'altitude : ça bip à donf. (La temp passe facilement de 28°C à 36°C quand le soleil tape sur le composant)

Donc à voir si dans un boitier ça s’atténue... mais je doute avec un boitier noir...
Je vais peut être faire des test en lissant la mesure de temp comme t'as fait pour le vcc et l'alti.

Ou alors c'est mon module BMP qui à une couille, j'ai tout le matos en double, je pourrait test.

Une dernière chose, pour moi, il manque un moyen de stopper manuellement la fin du chrono et donc de la mesure. Bon c'est lié au fait que ça déconnait et que je n'arrivait plus à arrêter le chrono autre que reset.

A+

[ptitkiki]

Ces capteurs sont hyper sensibles à la lumière, ainsi qu'au perturbations liés au flux d'air au contact direct. Essai avec un boitier et un bout de mousse sur la surface du capteur, ça devrait aider.

Bon courage.