Si la machine doit / peut analyser les variations de t° de l’ordre de 0.1° ou 0.2°, voir même simplement 0.5° pour prévenir de l’imminence ou de la probabilité d’un thermique, en fonction de son placement ne va-t-elle pas passer son temps biper parce quelle passe de l’ombre de la voile au soleil, d’en plein vent à l’abri du pilote, etc… :grat:
En fait prendre en considération des mesures qui sont parfaitement justes, mais a un endroit très précis (au cm près) alors que pour porter un parapente, la bulle devrait faire plusieurs centaines de m3 ? :vrac:
Je m’en étais bricolé à mes débuts, à base de MSP430F2012 (un des rares micros abordables avec un ADC) et d’une résistance NTC récupérée sur une vieille batterie montée en pont de wheatstone sur l’adc. Pas de baro, à l´époque c’était hors budget (plus de 100€ de mémoire, alors qu’aujourd’hui on en trouve à 1€!). Ce n’était pas super précis, mais ca marchait, et la conso était plus que basse - je suis tombé sur mon gadget ce printemps, et la pile bouton a toujours du jus plus de dix ans plus tard !
Le coup de passer du soleil à l’ombre (et inversément) le fait biper, oui. Du coup c’est pas top quand tu enroules… la seule indication pratique que j’avais, c’était en soaring le long du relief - quand ca bipait, il fallait tourner de 90 degres pour trouver le thermique, c’etait relativement fiable. Avec le temps, je sentais les différences de température sur les jambes et le visage, alors j’ai arreté de m’en servir… mais c’était marrant à faire. L’idée, je l’avais trouvée dans les visiteurs du ciel.
Ca devrait être facile et pas cher à faire de nos jours avec par exemple un arduino pas cher (genre attiny85), une thermistance et un buzzer. Le coup du baro peut ajouter un plus, à voir.
Je pense pas pour le parapente l’envergure est a mon avis trop faible et comment retourner l’info droite ou gauche au pilote sans trop le polluer de stimuli
la sensibilité est plutôt de 0,03 °C mais j’ai prévu un système de filtrage ajustable par le pilote. de 0,06 à 0,16 °C à agrandir si nécessaire
(effectivement en mettant la sonde au soleil elle me donnait des faux positifs) J’ai donc prévu de mettre la sonde de température dans un canal complètement opaque (probablement deux chicanes) et blanc avec l’ouverture dans le sens du flux d’air du parapente. il me semble qu’on évitera les faux positifs avec ça.
Pour les mesures parfaitement justes: une moyenne est prise sur 250 millisecondes (ça représente une distance de 2,5 m pour un parapente qui avance à 10 m/s) il faut prendre aussi en compte l’inertie de la sonde de température (que je ne connais pas).
Une question à propos de mettre les sondes dans les bouts d’ailes.
Vu qu’elles sont très sensible, est-ce que le simple fait de tourner ne va pas fausser les sondes par la différence du refroidissement éolien de l’oreille freinée versus oreille extérieur au virage ?
bonne question, :grat: mais si on y réfléchis, près d’un thermique, si on tourne du bon côté la plume externe au virage qui était plus froide va se réchauffer plus vite en se rapprochant. (confirmant donc la bonne direction) et si on s’en éloigne la plume externe au virage se refroidira plus vite (confirmant que tu t’es planté de sens)
Sinon dans de l’air stable thermiquement, loin d’un thermique le bout de plume externe au virage ne refroidira pas plus que l’air ambiant et ne devrait pas créer de faux signal.
Mais comme dit plus haut je vois pas vraiment pour l’instant la valeur ajoutée pour un parapente d’avoir deux sondes et surtout comment le représenter auditivement
Justement, puisqu’il y a un écran pourquoi en faire un instrument sonore ?
A l’écran, une flèche pour indiquer la direction la plus chaude, plus où moins épaisse/grosse/foncée pour indiquer si la différence de température est importante… Non ?
Effectivement, pour l’instant je n’ai qu’une seule sonde de température donc je vais d’abord terminer la version mono, valider la théorie avec la pratique. Et puis pourquoi pas une version stéréo l’année prochaine ou un thermomètre ultra précis pour mes grands crus dans la cave.
personnellement je regarde peu mes instruments en vol et je préfère donc un signal auditif plutôt que visuel, il y a une possibilité avec deux leds aussi de part et d’autre du cockpit qui même si on ne le regarde pas sera visible.
Avec un arduino le problème est de gérer la mémoire RAM et le temps d’écriture sur une interface graphique, un interface graphique bouffe énormément des deux et je ne veux pas avoir un temps de réaction supérieur à 250 millisecondes. J’approche très fort avec le programme d’interfaçage de la limite de la mémoire RAM de l’arduino et je pense dépasser un peu le temps de 250 millisecondes pour une boucle.
J’avais prévu pour l’écran d’afficher une coupe transversale de l’atmosphère et par altitude d’indiquer avec des bandes de couleurs la qualité de la masse d’air, inversion(s), stabilité, instabilité, je suis limité à 4 niveaux de gris et aussi les valeurs de varios rencontrés.
D’ailleurs si quelqu’un veut m’aider à diminuer la RAM bouffée, et le temps de calcul d’une boucle je suis preneur
Toujours intéressant d’apprendre des choses comme ça.
Alors on peut garder en tête l’option leds. Car entre un vario (qui fait aussi zéroteur) et un sniffeur, ça risque de vraiment surcharger l’ambiance sonore…
j’ai regardé que rapidement le code et ça demande d’y passer un peu de temps pour analyser finement. Ca mériterai de découper un peu mieux ton code pour séparer la la partie lecture, la partie logique et la partie affichage afin de gagner en visibilité et maintenabilité. Mais on est dans un projet DIY faut pas trop en demander j’en ai conscience (ce n’est pas un reproche, je suis moi même adepte du “quick and dirty” pour des protos dans ce genre).
Pour le temps de calcul, tu est limité par le temps d’acquisition de ta sonde de température. Il me semble avoir vu dans le datasheet un temps d’acquisition de 250ms pour la plus haute résolution. Dans ces conditions tu ne pourra pas optimiser grand chose sans diminuer la résolution de la sonde de température (ce qui serait, au premier abord, plutôt une mauvaise idée).
Après pour la RAM, il faut voir ce qui consomme. Car ce ne doit pas être tes quelques relevés de température qui vont bouffer toute la RAM (ou alors t’y es allé fort sur la non optimisation du code :-p), mais plus le module d’affichage qui, s’il est trop complexe et trop lourd, peut te consommer une grande partie de la RAM (ou un autre module, encore une fois j’ai regardé que très rapidement le code).
J’essaie d’y regarder dès que j’arrive à me trouver un peu de temps libre.
on pourrait imaginer un vibreur à mettre sur la planchette de la sellette, dans les gants, dans le casque, sur la poitrine ou ailleurs (les pervers passez votre chemin) permettant de communiquer certaines informations (vario, sniffeur, G trop forts, …) afin de gagner en calme sonore. On pourrait même imaginer un dans chaque gant pour indiquer un sens.
Oui j’avais codé pour moi et au départ pas pensé à partager le programme, donc je peux comprendre qu’il est juste compréhensible par moi. De plus je suis un brèle en codage :canape:
pour le MCP9808 J’avais lû aussi pour les 250 millis. (je soupçonne que ce soit pour avoir une température absolue exacte à 0.0625°C. Ce qui nous intéresse ce sont les variations de valeurs, pas qu’il fasse exactement 5.0625° mais plutôt ce qu’on a gagné) dans le programme je lui demande de me sortir une valeur de la résistance précise à 0.0625 °C que je lisse par 5 mesures.
J’avais donc fait un test sur 40 loops et cela me prenait 7.36 secondes donc environ 190 millis par loop pour tout le programme sonde de pression et buzzer compris. on en est donc loin (sans l’interface graphique). Au départ j’avais essayé le codage avec la librairie dédiée pour le MCP9808 mais je me suis aperçu que ça ne marchait pas, donc au lieu d’utiliser la librairie dédiée je la commande directement sans librairie via le programme. Je crois que j’ai gagné quelques millisecondes en évitant la traduction des commandes
Pour la RAM c’est clairement l’interface graphique, j’ai commencé à avoir de temps à autres des données erratiques après avoir rajouté le module, donc je soupçonne qu’il y a un peu de “stack overflow”, probablement liées au valeurs “char” il existe un macro pour libérer de la mémoire SRAM et laisser ces “char” dans la mémoire programme. je suis à 85% de la RAM
« The Temperature register is read-only, used to access the ambient temperature data. This register is double- buffered and it is updated every tCONV.«
Tu peux donc lire le registre de température quand tu veux mais il ne sera mis à jour que tous les tCONV aka 250ms.
Y’a un truc bizarre avec ce que tu me dis (5 mesures pour lisser en moins de 250ms, pour moi le capteur doit renvoyer des valeurs identiques)
Haa ça j’avais pas vu. Du coup pas besoin de faire 5 passages. J’obtenais des données différentes mais essentiellement les mêmes températures. Mais comme je teste dans mon bureau je ne m’attendais pas à des variations Significatives ( Probablement que l’horloge de la sonde n’est pas synchro avec le temps de loop de l’arduino) 0,06degres c’est déjà pas mal. Je regarderai ce soir
je n’utilise pas d’adruino mais en c une chaine doit être contenu un tableau plus grand que ce qu’il va contenir car il lui faut un caractère de fin de chaine ‘\0’
de plus la déclaration du tableau ne fait pas l’initialisation.
si on se base sur l’exemple que tu as joint essaye en remplaçant
char dataH[5];
float h = 56.00;
dtostrf(h,5,2,dataH);
par
char dataH[6]={’\0’};
float h = 56.00;
dtostrf(h,5,2,dataH);
Je vais essayer, j’avais bien lu que le char devait se terminer par une valeur à 0 et avait utilisé sans succès la fonction roundf() pour éliminer les décimales superflues
Je ne savais pas comment forcer je vois ici qu’avec ={’\0’} ce sera fait. Je te tiens au courant
Si la machine doit / peut analyser les variations de t° de l’ordre de 0.1° ou 0.2°, voir même simplement 0.5° pour prévenir de l’imminence ou de la probabilité d’un thermique, en fonction de son placement ne va-t-elle pas passer son temps biper parce quelle passe de l’ombre de la voile au soleil, d’en plein vent à l’abri du pilote, etc… :grat:
ou sur l’intrados
(ce n’est pas un reproche, je suis moi même adepte du “quick and dirty” pour des protos dans ce genre).
nickel ça marche