Sniffeur de thermique Arduino et codage

[Captain Obvious]

Bon comme il fait moche pour l'instant je me suis lancé dans un projet Arduino.

J'ai envie de ressusciter un vieil appareil qui avait fait un gros flop dans les années 80. 
https://web.archive.org/web/20030801174905/http://www.krigelec.com:80/sniffeur/sniffeur.htm

En gros l'appareil détecte les microvariation de température et bipe quand l'air se réchauffe, et alerte le pilote de l'approche d'un thermique.
L'appareil en question était assez controversé car la lecture auditive était assez déroutante apparemment.
(ça bipait a l'approche d'un thermique et dégueulait si on s'en éloignait) l'avantage de cet appareil était de pouvoir localiser les zones intéressantes au niveau thermique avant même que le vario ne bipe
Je me suis dit qu'avec un arduino il y avait moyen de programmer un truc plus simple a comprendre.

En gros à l'époque l'appareil avait deux défauts majeurs:

- Le premier dans une grosse dégeulante il avait tendance à biper car l'appareil ne compensait pas l'augmentation de température avec la perte d'altitude.
- Le deuxième il n’enregistrait pas la température de l'air avant l'approche du thermique, du coup il était continuellement en instantané, ça se réchauffe ça bipe ça se refroidit ça dégueule. Hors dans un vario classique c'est différent tant que on est dans du positif ça bipe (Je veux donc que le système enregistre la dernière valeur de température stable et le définisse comme le point 0 dés qu'une variation suffisamment importante est détectée, toute variation après sera calculée en différence par rapport au point 0 et sera définie comme ex +0.1 °C +0.2°C +0,1°C 0°C -0,1°C au lieu de +0,1°C +0,1°C -0,1°C -0,1°C qui est beaucoup moins compréhensible (vous me suivez toujours  )

La liste du matériel commandé :

Un Nano V3.0
https://www.amazon.fr/tinxi%C2%AE-ATmega328P-Contr%C3%B4leur-Compatible-Arduino/dp/B01FRZVUNS/ref=sr_1_7?ie=UTF8&qid=1513066798&sr=8-7&keywords=arduino+nano
Une sonde de température haute précision
https://www.amazon.fr/Adafruit-MCP9808-Breakout-temp%C3%A9rature-pr%C3%A9cision/dp/B00OKCQX96/ref=sr_1_1?ie=UTF8&qid=1513067065&sr=8-1&keywords=adafruit+mcp9808
Une sonde de pression atmosphérique haute précision
https://www.amazon.fr/gp/product/B072M7RRYV/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
un potentiometre (pour ajuster la sensibilité de l'appareil
https://www.amazon.fr/potentiom%C3%A8tres-kwmobile-Arduino-Raspberry-projets/dp/B01MYB7DHB/ref=sr_1_4?s=electronics&ie=UTF8&qid=1513067334&sr=1-4&keywords=potentiometre+arduino
un ecran e-ink qui trainait chez moi
https://www.amazon.fr/gp/product/B071LGVVL1/ref=oh_aui_detailpage_o00_s01?ie=UTF8&psc=1

J'ai déja codé la grosse partie (un peu spaghetti ), je vous balancerai le code et les schémas plus tard.

Tout est sur un breadboard pour l'instant, pas encore eu le temps de plancher sur le design du boitier et l'alimentation.
Si ça vous intéresse et que vous savez coder un peu, votre avis m'intéresse


Attention il est fort probable que tout compte fait cet appareil n'apporte rien au vol et reste toujours une daube dans ce cas là je le recyclerai pour monitorer ma cave à vin   

[fat]

intéressant ton projet

si tu déposes le tout sur un github ce serait pratique

bonne continuation

[Captain Obvious]

si tu déposes le tout sur un github ce serait pratique

Oui pourquoi pas

[Parapente Samoens]

La partie matériel et sa programation reste pour moi du chinois mais je suis très intéréssé par la mesure en temps réel de la masse d'air.

Le sniffeur originel n'était pas exploitable en vol, les infos ne correspondaient pas sans que l'on sache vraiment si le problème venait du matériel (manque de filtrage, de précision ou d'inertie ?) ou du modèle aérologique (correspondance entre la variation de température et l'ascendance).

En statique au décollage c'était assez amusant d'entendre le sniffeur sonner juste avant de sentir la rafale thermique. Il y avait donc un fond de vérité dans cette idée.

Il serait intéressant de lancer une petite étude préalable de la correspondance entre la variation de la température et la présence d'ascendance. En enregistrant les valeurs de la sonde et du vario en temps réel on pourrait valider ou non le principe et les valeurs de filtrage à appliquer.

Amuse toi bien !

[Captain Obvious]

Le sniffeur originel n'était pas exploitable en vol, les infos ne correspondaient pas sans que l'on sache vraiment si le problème venait du matériel (manque de filtrage, de précision ou d'inertie ?) ou du modèle aérologique (correspondance entre la variation de température et l'ascendance).

En statique au décollage c'était assez amusant d'entendre le sniffeur sonner juste avant de sentir la rafale thermique. Il y avait donc un fond de vérité dans cette idée.

Oui c'est ce que j'ai lu, il ne compensait pas la température avec l'augmentation ou perte d'altitude et il bipait en fonction des variation de températures. C'est un peu comme si ton vario bipait en fonction des variation des vitesses verticales. ca bipe quand tu passe de 0.9 à 1 m/s mais pas quand tu reste dans du 1m/s (si tu me suis) avec un arduino c'est plus facile à programmer.

[BelgiumGuy]

L'idée paraît vraiment intéressante et il semble bien que le vario puisse résoudre une grande partie des problèmes de la première version.  Vraiment intéressé de voir ce que çà peut donner.

[toonio]

Je suis d'accord avec Patrick, avant de coder quoi que ce soit niveau logique, il serait intéressant (sinon indispensable) d'avoir des enregistrements bruts et synchronisés de la sonde de température et de la sonde de pression pour pouvoir les analyser et en déduire déjà si il y a quelque chose à en tirer (corrélation ET causalité). En gros construire un modèle théorique avant de sauter directement à la pratique.
Intéressant comme projet

[fat]

Je suis d'accord avec Patrick, avant de coder quoi que ce soit niveau logique, il serait intéressant (sinon indispensable) d'avoir des enregistrements bruts et synchronisés de la sonde de température et de la sonde de pression pour pouvoir les analyser et en déduire déjà si il y a quelque chose à en tirer (corrélation ET causalité). En gros construire un modèle théorique avant de sauter directement à la pratique.
Intéressant comme projet

oué mais pour faire les mesures il faut bien assembler qq composants et faire un mini bout de code elles n'arrivent pas toutes seules dans ton excel les mesures :-p

[toonio]

Tout à fait, juste pour dire qu'un breadboard et un code minime suffisent aux préliminaires (mais j'y connais rien en élec, je suis du coté du code)

[Captain Obvious]

Je suis d'accord avec Patrick, avant de coder quoi que ce soit niveau logique, il serait intéressant (sinon indispensable) d'avoir des enregistrements bruts et synchronisés de la sonde de température et de la sonde de pression pour pouvoir les analyser et en déduire déjà si il y a quelque chose à en tirer (corrélation ET causalité). En gros construire un modèle théorique avant de sauter directement à la pratique.
Intéressant comme projet

Il y a déjà des données de disponibles, j'avais lu dans un livre (je peux pas citer des sources) que pour qu'un thermique décolle du sol il faut au moins une différence de 1,5 degré. J'ai aussi lu que la masse d'air du thermique et de l'air ambiant était très peu miscible. Donc on peut en déduire qu'en air instable et a une distance raisonnable d'une inversion lorsqu'on évolue dans un thermique il a une température différente de ses alentours. Je pense pas qu'une analyse préalable soit nécessaire pour accepter ce postulat là.
Par contre le thermique en lui même a une inertie et lors de l'approche de l'inversion il va s'écraser et pousser dessus, cet appareil sera alors moins pertinent mais on s'en fout parce qu’on est au plaf   l'intéret de l'appareil c'est d'indiquer qu'on approche d'un thermique, il l'est beaucoup moins une fois qu'on est installé dedans parce que le vario prendra le pas pour le centrage.

Des données théoriques existent et sont trouvables un peu partout sur le net:
le rapport entre la pression et la température de l'air en adiabatique sèche (en gros +- 0.09411616 °C / mBar ou 9,8 °C/km) ça varie en fonction de l'altitude mais pas tant que ça aux altitudes auxquelles on évolue entre 1000 et 700 mBar.
On pourra rajouter une sonde d'humidité pour l'adiabatique humide (mais je vois pas trop l'intéret d'enrouler dans un nuage)

[Captain Obvious]

voilà le github
https://github.com/coldeg/Thermal-Sniffer
comme je suis un noob la dedans j'ai peut-être pas tous les éléments n'hésitez pas à me demander plus de trucs.
et désolé pour le code je suis encore débutant

[Parapente Samoens]

Les problèmes avec le modèle original (j'en ai un qui marche encore  ), venait effectivement de la non compensation mais on parlait aussi de données parasitées par des 'abeilles' (bullettes d'air chaud) autour du thermiques. Réalité ou légende de bar ?

Dans ce cas il faudrait prévoir un système de filtrage pour compenser les variations parasites.

[sansou]

Salut Captain Obvious,

J'adorerais avoir ta polyvalence hardware/Software, hélas je code comme un goret, et comme je suis allergique à l'électronique, la messe est dite.

Comme dit plus haut, le fait que l'air chaud et l'air froid soient d'autant moins miscibles que le gradient de température augmente fait que j'ai quelques doutes sur l'intérêt du binz.

Par contre, un truc me trotte dans la tête depuis 2 ans, la strioscopie, une voie pleine de promesses me semble t'il... Je me trompe peut être, ce ne serait pas la 1ère fois.

Je poste non pas pour te casser les pattes sur ce projet, qui je l'espère te fera kiffer et que je suivrai, mais pour semer une graine dans une tête qui semble équipée pour la faire pousser.

[fabrice]

S'il y a un gros gradient de températures, alors cela doit être des boulets qui montent!
Cela peut être un outil pour étudier les thermiques. En l'absence de déclenchement, attendre là où c'est le + chaud est certainement la bonne stratégie à avoir.

[sansou]

Pas con.
Moins que mon rêve de voir un jour une techno nous montrer les thermiques en vidéo en tous cas.
- Parce qu'avec la strioscopie c'est impossible en l'état de la techno.
- Parce que ça ferait perdre en partie l'intérêt de la discipline.

[fat]

- Parce que ça ferait perdre en partie l'intérêt de la discipline.

oui mais je suis certain que ça ouvrirait la porte à de nouveaux challenges !
et puis c'est comme la vario, y'en a qui ne peuvent plus voler avec et préfèrent voler "au naturel" alors que d'autres sont incapables de voler sans.

bref on s'éloigne du sujet, mais effectivement les lunettes avec HUD intégré qui matérialise le thermique ce serait fumant

[Captain Obvious]

Comme dit plus haut, le fait que l'air chaud et l'air froid soient d'autant moins miscibles que le gradient de température augmente fait que j'ai quelques doutes sur l'intérêt du binz.

mais vous savez aussi qu'un thermique c'est pas descendre à -1m/s et se retrouver 100 millisecondes après dans du +3m/s on rentre doucement dedans et puis après il faut le centrer.
ce qui est intéressant c'est les abords, on peux détecter avec l'appareil une variation de 0,03 degré là ou le thermique n'est pas encore en train de monter. l'intéret c'est dans le faible, rester dans une zone plus chaude, détecter si on est dans du dynamique plutôt que du thermique, une dégeulante (pas dynamique), trouver la sortie d'un bagnard, ....

[sansou]

Si tu parviens à faire fonctionner l'outils, les essais apporteront les réponses.
Si ça se trouve tout le monde en voudra un sur son cockpit dans 5 ans...
Si ça peut t'aider en fin de projet, je peux te faire le boitier (num et impression 3D), rien de plus vu mon incompétence en dev et electro.

[Captain Obvious]

Voilà ce que j'ai prévu dans le programme pour l'instant.

- Il enregistre à chaque cycle la pression à +- 10 cm de résolution et la température à 0.03°C près.
je fais 5 mesures de chaques pour lisser les données.  Chaque cycle complet dure environ 250 milisecondes sauf lorsqu'il écrit sur l'écran une fois tout les 20 cycles 250 milisecondes de plus
-à chaque cycle il compare la température précédente avec la température actuelle et corrige si différence de pression la différence de température  (-0.0098 °C/m, pour être exact je corrige la température avec les mBar pas l'altitude, donnée que j'ai pas avec une sonde de pression)
-à chaque cycle il compare cette différence de température avec le seuil de sensibilité qui est ajustable.

- Si le seuil de sensibilité est dépassé il enregistre la dernière température comme valeur de référence (un peu comme si il étalonnait l'appareil à 0 m/s) et l'appareil va biper en fonction du delta de température comme un vario classique (je cherche un spectre sonore différent du vario pour éviter la confusion)
- si plus de variation significatives pendant 20 cycles le module sonore s'arrête


Il reste à faire compenser la température de référence avec l'altitude.
Il reste à définir si il est intéressant de faire biper l'appareil une fois établi et en vario positif dans un thermique et si oui a combien de m/s on s’arrête
Il reste a définir ce qui serait intéressant d'afficher sur l'écran
Il reste à définir si ça marche dans la pratique 

[dgtall]

Est ce qu'il pourrait y avoir un intérêt à mettre ce dispositif sur chacun des bout d'aile ?
Il me semble que c'est dans "les visiteurs du ciel" qu'il y avait un chapitre dessus.

[Gillesf]

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

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 ? 

[brandi]

he, he alors il faudrait un essaim de drone equipé de sonde  relié en peer to peer autour du pilote.

[Zebu]

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.

 
 

[Captain Obvious]

Est ce qu'il pourrait y avoir un intérêt à mettre ce dispositif sur chacun des bout d'aile ?

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

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

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 ? 

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).

[en Cure ;-)]

après tu mets le détecteur déporté sous la sellette comme ça toujours a l'ombre ou sur l'intrados

[Captain Obvious]

voila déjà à quoi ça ressemble pour l'instant

[Charognard]

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 ?

[Captain Obvious]

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

[Triple Seven France]

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 ?

[Captain Obvious]

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

[Triple Seven France]

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.

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

[fat]

D'ailleurs si quelqu'un veut m'aider à diminuer la RAM bouffée, et le temps de calcul d'une boucle je suis preneur

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.

[fat]

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

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.

Désolé pour le HS, une idée en passant

[Captain Obvious]

(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).

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 

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

[fat]

« 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)

[Captain Obvious]

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

[Captain Obvious]

Ca y est j'ai terminé la partie hardware, c'est un peu brut de décoffrage pour l'instant, mais ça fera l'affaire pour le prototype et tests en vols.

j'aurai par contre besoin de lumières de quelqu'un qui s'y connait pour transformer un float en char pour l'affichage.
J'ai des problèmes de buffer avec la fonction dtostrf() identique a celui-ci. https://stackoverflow.com/questions/44604893/arduino-strange-behaviour-dtostrf

edit: je sais que la soudure c'est pas mon fort et que ça en fera tiquer plus d'un 

[brandi]

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);

[Captain Obvious]

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

[Captain Obvious]

  nickel ça marche

[Mme POB]

A mon avis, ce genre d'appareil ne peut pas être assez sensible pour indiquer à distance où il y a un thermique.
Une fois dedans, on l'enroule.
Je serais davantage orientée vers un appareil optique mesurant l'indice de réfraction de l'air dans un angle de directions assez ouvert, à partir d'un capteur qui afficherait le résultat en fausses couleurs, ou sous forme d'un graphique, sur l'écran d'une tablette munie d'un logiciel approprié.
Il me semble moins compliqué d'amplifier avec une simple tablette des signaux optiques d'amplitudes nécessairement très voisines plutôt que des zones de températures variées sujettes aux turbulences de convection.
L'idée est d'imiter l'oeil des rapaces.

L'inconvénient majeur d'un tel appareil, s'il venait à être mis au point, serait d'attirer des tas de pimpins dans des thermiques qu'ils auraient sinon du mal à trouver, l'encombrement qui en résulterait serait mauvais pour la sécurité.
Nous sommes un certain nombre qui aimons bien voler sans vario, ce qui affine la sensibilité à la masse d'air. Et quand le vario se met en drapeau, cela ne nous gêne pas plus que ça.

Etre dépendant d'un appareil peut avoir des effets pervers, rappelons-nous le vol AF447 avec des "pilotes" qui, ayant perdu les informations de vitesse des sondes Pitot givrées, mirent l'avion en décrochage jusqu'à l'impact dans l'Atlantique.
Ils avaient toujours les informations d'altitude et le GPS et ils entendaient l'alerte décrochage mais ils restèrent scotchés sur les sondes.
S'ils avaient piloté, ils auraient sauvé l'appareil, les passagers et eux-mêmes.
 

[fat]

Code:

  float freq = 142.500;
  char buf[9];

  dtostrf(freq, 8, 4, buf);  // convert frequency to string with 4 digits precision, 8 char long max (buf length = 8 + 1 = 9)

  Serial.print(String("Scanning frequency ") + String(buf) + String(" kHz ..."));

effectivement c'est bien l'histoire de l'octet '\0' en fin de chaîne de caractères en C (et consorts)

Pas certain que l'usage d'object String() à concaténer dans le Serial.print soit vraiment optimisé, mais bon, là, on chipote

[Captain Obvious]

Code:

  float freq = 142.500;
  char buf[9];

  dtostrf(freq, 8, 4, buf);  // convert frequency to string with 4 digits precision, 8 char long max (buf length = 8 + 1 = 9)

  Serial.print(String("Scanning frequency ") + String(buf) + String(" kHz ..."));

effectivement c'est bien l'histoire de l'octet '\0' en fin de chaîne de caractères en C (et consorts)

oui et tout mon désarroi était dans le fait que dans le moniteur série le serial.print() me donnait des données correctes mais pas l'écran eink 
c'est réglé maintenant. 

[Captain Obvious]

A mon avis, ce genre d'appareil ne peut pas être assez sensible pour indiquer à distance où il y a un thermique.
Une fois dedans, on l'enroule.

Sachant d'après ce que j'ai lu qu'il y a en moyenne entre 2  et 3 degrés de différence entre le noyau d'un thermique et la masse d'air, un capteur qui mesure à 0,06 degré près devrait faire l'affaire.
je suis d'accord avec toi une fois dans le thermique l'appareil sera moins pertinent. J'ai prévu d'ailleurs qu'il se désactive en vario positif pendant plus de X secondes pour pas saturer le pilote d'infos.
L'intéret c'est l'abord du thermique, l'air est réchauffé mais ne monte pas forcément significativement pour le distinguer d'une zone turbulente, de plus dans du petit on peut décider de se mettre en attente dans une zone favorable.
L'autre intéret c'est de pouvoir faire un sondage de la masse d'air et de le représenter graphiquement par altitude avec les couches stables, neutres et instables et notre position par rapport à celles-ci

Je serais davantage orientée vers un appareil optique mesurant l'indice de réfraction de l'air dans un angle de directions assez ouvert, à partir d'un capteur qui afficherait le résultat en fausses couleurs, ou sous forme d'un graphique, sur l'écran d'une tablette munie d'un logiciel approprié.
Il me semble moins compliqué d'amplifier avec une simple tablette des signaux optiques d'amplitudes nécessairement très voisines plutôt que des zones de températures variées sujettes aux turbulences de convection.
L'idée est d'imiter l'oeil des rapaces.

je vois pas en quoi des microvariations de réfraction de l'air seraient différentes de microvariations de température. N'oublie pas non plus que pour les visualiser il te faudrait une source de lumière cohérente en amont. http://www.ian.org/Schlieren/SchlierenDiagram.png https://www.youtube.com/watch?v=4tgOyU34D44

L'inconvénient majeur d'un tel appareil, s'il venait à être mis au point, serait d'attirer des tas de pimpins dans des thermiques qu'ils auraient sinon du mal à trouver, l'encombrement qui en résulterait serait mauvais pour la sécurité.

Bah chez nous, si il y a un gars qui enroule on voit aussi les pimpins se remeuter.  mmmh je devrais d'ailleurs breuveter ce concept (un détecteur de parapente qui monte dans le voisinage) Mais t'inquiètes je compte pas faire une grande production. c'était surtout pour le plaisir de faire un truc cet hiver.

Etre dépendant d'un appareil peut avoir des effets pervers, rappelons-nous le vol AF447 avec des "pilotes" qui, ayant perdu les informations de vitesse des sondes Pitot givrées, mirent l'avion en décrochage jusqu'à l'impact dans l'Atlantique.
Ils avaient toujours les informations d'altitude et le GPS et ils entendaient l'alerte décrochage mais ils restèrent scotchés sur les sondes.
S'ils avaient piloté, ils auraient sauvé l'appareil, les passagers et eux-mêmes.
 

oui mais la tu psychote    c'est pas parce que mon vario tombe en rade que je vais mettre ma voile en décrochage hein 

[Captain Obvious]

Petit Update,
Le printemps est là , et j'arrive à la fin du programme

J'ai rangé le code, créé des fonctions call pour plus de lisibilité, ( j'ai pas redéposé sur github par contre)

Il me reste encore à coder : (juste une condition qui inscrit la valeur avec les bonnes coordonnées sur l'écran)
- L'affichage de la stabilité de la masse d'air en adiabatique sèche en fonction de l'altitude (neutre 9.8°/km, stabilité <9.8°/km, instabilité >9.8°/km)
- L'affichage de la moyenne du vario en fonction de l'altitude (fonction timer qui calcule le temps en secondes pour monter de 250 m "je pars du principe qu'une fois dans le thermique on ne le perd pas")
- affichage de la température tout les 250 m (pour savoir si on a vraiment eu froid ou si c'est pour épater les pilotes qui n'ont pas pu monter au plaf)
-j'hésite à rajouter le gradient de température moyen entre le cœur du thermique et l'extérieur rencontré par altitude (ça permettrait de corréler ce gradient avec le vario moyen)

donc max 4 variables char à rajouter il me reste 256 octets dans la mémoire (ça devrait le faire)
L'avantage de l'eink c'est qu'une valeur inscrite ne change pas à moins de réécrire dessus, ça me permet d'afficher une seule et même variable avec des coordonnées différentes.

j'ai mis en PJ l'affichage sans le gradient

[Dasdy]

Super projet !!! Je pense que pour gagner en vitesse, il serait pas mal d'utiliser deux arduino. Un pour les mesures de pression, température et un autre pour gérer le Buzer et l'affichage. Tu fais communiquer les deux arduino l'un en maitre l'autre en esclave.

J'ai eu le même problème à l'époque pour je voulais me fabriquer mon alti-vario à base d'arduino.

[Captain Obvious]

Super projet !!! Je pense que pour gagner en vitesse, il serait pas mal d'utiliser deux arduino. Un pour les mesures de pression, température et un autre pour gérer le Buzer et l'affichage. Tu fais communiquer les deux arduino l'un en maitre l'autre en esclave.

J'ai eu le même problème à l'époque pour je voulais me fabriquer mon alti-vario à base d'arduino.

Pas bête je vais y réfléchir,

Par contre le buzzer sera alors sur l'esclave, parce que l'affichage prend du temps processeur et je ne veux aucun délai entre la détection d'une variation de température et l'output sonore.
L'affichage est ce qui bouffe le plus de ressources, RAM et processeur