Sniffeur de thermique Arduino et codage

[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