Sniffeur de thermique Arduino et codage

[Sagarmatha]

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]

  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]

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

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