Variomètre maison à base d'Arduino

#21

Salut,
j’avais un peu regarder les modules GPS mais en effet la mémoire du nano ne me laissait déjà plus trop de possibilité d’évolution.

Cela demandera surement pas mal de travail en plus car il faudrait surement utiliser un écran plus grand, ajouter des paramètres au menu et surtout développer les fonctionnalités propres au GPS.

Adafruit vend un module GPS qui semble intéressant. Voir ce petit tuto sur comment l’utiliser.
Par contre cela rajoute facilement 50€ au prix du projet donc fait carrément doubler son prix… ce qui n’est pas trop dans la philosophie du projet d’avoir un produit aussi coûteux qu’un du marché :prof:

Je n’avais pas vu qu’on pouvait intégrer directement les vidéos, alors je me permets de la remettre… :ppte:

https://www.youtube.com/v/KeNAhEgbHnc

#22

Bonjour,

Un énorme merci à Sinseman pour d’une part ce travail de qualité et d’autre part le partage avec la communauté.
Tout ça prends du temps et je t’en remercie. :pouce: :pouce:

Je viens de finir le mien sans aucun soucis ! Il me reste l’intégration dans un boitier à faire et se sera parfait.
Le BMP085 a été remplacé par le BMP180 (“It follows the BMP085 and brings many improvements, like the smaller size and the expansion of digital interfaces.”) j’ai utilisé la dernière biblio adafruit pour le BMP. Je ne sais pas s’il ça change vraiment qq chose mais le BMP085 n’est plus dispo.

J’ai fait une petite modif dans le code car pour moi la luminosité était inversée.
A propos du code, ça fait plaisir de voir du code si bien écrit je trouve. C’est très agréable à parcourir et j’y ai même appris quelques trucs.

Pour le prix : 17€ (sans boitier et accu) via dealextreme (20 jours pour la livraison)
Les items pour ceux intéressés :
-SKU 274695
-SKU 149493
-SKU 281598
-SKU 275658
-SKU 331485
-SKU 81877
-SKU 145860

Voilà, encore merci et je ferai une petite photo pour l’intégration si j’arrive à faire un truc pas trop dégeux.

:trinq: karma+

#23

Wow merci pour tout ça ! En tant que geek repenti j’ai très très envie d’essayer…

#24

Salut à tous, content que le projet vous plaise !

Cool Xiboard hâte de voir ce que ça donne pour toi :slight_smile:

Sinon petite question sur ton matos : Le Codeur Dode Commutateur / EC11 (SKU 275658) possède bien un bouton poussoir ? Ou tu as dû en intégrer un à ta sauce ?

Et aussi, dans mon cas je rencontre quelques soucis avec l’écran du 5110. Parfois il ne s’allume pas bien je suis obligé de lui “taper” un peu dessus pour que ça fonctionne, comme s’il y avait un faux contact. Rencontres-tu aussi ce problème ? Ça vient peut-être du matos que j’avais acheter sur Ebay qui semble perfectible.

Autre point aussi, l’indicateur de batterie n’est pas fiable. Il faudrait que je le commente dans le code pour ne pas induire en erreur avant d’avoir trouver une solution. Si tu as une idée à ce sujet n’hésite pas à m’en faire part !

#25

Oui le codeur doit être le même que le tiens : Droite / Gauche / Push
(C’est génial d’ailleurs comme truc, bien plus intuitif que les 4 cross+Selec intégré des foi aux écrans)

J’ai tout acheté en double (spare chinois au cas où). Un de mes deux écrans affichait des lignes noires horizontales/verticalles. En fait il n’était pas bien clipsé (la partie métallique) mais à priori il est opé maintenant. (Dans le doute j’ai utilisé l’autre)

Je me suis posé la question aussi pour l’indicateur de batterie. J’ai regardé le code en diag sur cette fonction et j’ai pas trop suivi le calcul. Bon j’ai un accu de 1700 mAh donc de quoi tenir je pense !! Mais je regarderai un peu si j’ai une idée.

Je voulais aussi changer 2/3 truc dans le code :
Un bip au démarrage pour voir que le truc est allumé.
Et un bip à chaque changement du volume pour entendre la différence (comme sur les téléphones).

Une petite question pour l’intégration : ça te conviens le bouton sur la face avant ? J’avais envie de le mettre dessus comme sur une radio, tu vois ?

#26

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.

#27

J’avais bien repéré cette fonction en effet :wink:

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 ?

#28

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.

#29

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…

#30

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.

#31

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.

http://www.ibt-power.com/Battery_packs/Li_Ion/Li_Ion_DiscGph.JPG

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

#32

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. :shock:

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

Du coup ça marche impec. :prof:
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. :coucou:

#33

Salut

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

Jc

#34

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.

#35

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

#36

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.

#37

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 ?

#38

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é !

#39

:bravo:

#40

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!!!