astrolivier

C'est ce que je dis au premier message. Le soucis c'est qu'entre les nuits d'hiver et d'été ce ne sont pas les mêmes conditions dans ma Normandie trop puissant pour l'un et pas assez pour l'autre. Et quand on oublie de modifier la puissance ca turbule sévère devant le scope ^^. Honnetement, prix de revient ici de seulement quelques euros si on a déjà les resistances chauffantes!!

UPDATE 1: Bonjour à tous, Pas très satisfait dont se passaient les choses avec la version précédente j'ai préféré supprimer les deux firmwares. J'ai retravaillé les codes et je suis parti sur un nouveau format. Initialement je voulais que le code final intègre un autotune lors du premier démarrage. Cela fonctionnait mais je n'ai pas réellement trouvé convainquant les valeurs des PID calculées. Je suis donc parti sur une nouvelle librairie et une nouvelle philosophie que je vais exposé ci dessous. NOTICE D'INSTRUCTION POUR L'UTILISATION DES CODES Pour commencer, il convient que le matériel, et donc les 3 sondes de températures, soient dans un équilibre thermique uniforme. Pour mes essais j'ai donc placé l'ensemble de mon matériel dans une pièce durant plusieurs heures. Etape 0: recherche des adresses I2C des sondes de températures: Via le firmware fourni au post 1, il faut brancher tour à tour les différentes sondes de température et reporter les adresses trouvées. On attribuera à chaque sonde (et donc adresse) sa destination finale. Etape 1: Calibration des sondes: Connectez les sondes sur l'arduino et televersez le programme "CalibrationRC". Vous devrez renseigner dans le fichier config.h les différentes adresses des sondes, exemple pour moi: Mettez les valeurs de correction à 0. Choissisez maintenant une résolution de mesure de la température ici: Pour ma part je suis parti avec une resolution de 0,125°C soit une valeur 11. Televersez le code et ouvrez le moniteur série. Il y a fort à parier que les valeurs affichées ne soient pas les mêmes pour les différentes sondes. A ce moment plusieurs raisonnement possibles: Soit vous avez un thermomètre étalonné que vous utilisez comme référence soit vous choisissez une des sondes comme référence. N'ayant pas de thermomètre ultra précis je suis parti sur la deuxième solution. De toute façon ici le système ne sert pas à mesurer la température réelle mais bien de voir une variation de la température. Donc pas de soucis ici tant que les sondes sont calibrées entre elles. Par exemple, dans mon cas perso: Avant correction: Après correction: Voilà maintenant nos sondes sont calibrées et indiquent donc toutes la même température. Etape 2: Auto Tune des coefficient PID: L'une des étapes les plus délicate de ce projet est bien la determination de ces fameux coefficients. Ce sont en effet ces paramètres qui vont faire que la régulation du chauffage soit la plus efficace possible. Charger le programme AutotunePIDRC et aller dans le fichier config.h. Comme pour le précédent fichier, modifier les valeurs des adresses des sondes. Regler aussi la valeur de la résolution précédement choisie. Pour que l'auto tune soit le plus efficace dans la recherche de ces paramètres il faut régler 2 choses de plus dans le code: - D'une part le temps d'un tour de PID. C'est le délai entre deux tours de calcul des coefficients. Si le délai est trop court, sur des telescope où les temps de réaction sont très lents, le programme ne verra pas de fluctuation. A l'inverse, avec un delai trop long, le programme ne detectera pas les variations minines. Cette valeur est à paramètrer ici: Dans l'exemple j'ai mis 30 secondes. Le meilleur moyen de savoir quelle valeur mettre, lancer un auto tune avec une valeur par défaut de 1s. lancer un chrono. Les températures vont s'afficher toutes les secondes dans le moniteur série. Arrêtez le chorno dès lors que vous observez une variation positive de la température. Mettez cette valeur à la place du 1 (ou 30 sur l'image). Avant de relancer un auto tune avec cette nouvelle valeur il faudra attendre de nouveau que le système se restabilise en température. Televersez un code basique (par exemple un simple blink dans les exemples) pour désactiver les sorties des resistances chauffantes. - D'autre part, une autre valeur moins importante est à régler. Il s'agit du delta de température positif que vous souhaitez atteindre pour calculer les coefficients du PID. En effet, on va simuler la réaction du système en lui demande d'atteindre une certaine température. Dans le fichier config.h il s'agit de ce paramètre: Dans l'exemple j'ai mis une température de 5°. Concretement, cela implique les choses suivantes une fois que le code est televersé et le moniteur série ouvert: l'autotune va mettre une puissance de 100% sur la sortie jusqu'à atteindre la consigne, ici une température de l'air + 5°. Une fois la consigne atteinte la sortie passe à 0% jusqu'à ce que la température passe sous la consigne et recommence ainsi de suite. Après un certains nombre de cycles, les coefficients determinés par le programme s'affichent sur le moniteur série. Si vous avez activez un "GUIDE" comme moi, alors les PID sont effectués en parallèles. Notez ces coefficients pour la dernière étape, la plus simple Attention: le delta choisi ne doit pas être trop grand. En effet, par exemple 5°C ici, il faut que le système de chauffe puisse arriver à suffisament chauffer pour que la consigne soit atteinte. Si la puissance de chauffe n'est pas suffisante le système ne pourra pas atteindre la consigne et l'auto tune sera forcément faux. Une valeur de 3°C pour commencer semble être la plus part du temps un bon compromis. A vous de voir si vous avez la puissance suffisante! Etape 3: Execution du programme final Ouvez le fichier RCAutoPID et aller dans le fichier config.h Une fois de plus il vous faudra changer les adresses des sondes de températures et indiquer la resolution des mesures choisie à l'étape 1. Il faut aussi modifier les valeurs suivantes: A la place de 1 seconde mettez ici la valeur du chrono trouvée à l'étape 2 ou une valeur inférieure. renseignez les divers coefficients des Kp Ki et Kd trouvés à l'étape 2 pour le telescope et le guide si vous l'avez utilisé. ne pas tenir compte de mes valeurs qui sont issus d'une simulation. Etape 3 bis: Simulation du programme final Pour tester le bon fonctionnement vous pouvez tricher en modifiant le code. Normalement, le but final sera de faire en sorte que la température du système soit toujours celle de l'air ambiante. Pour simuler nous pouvons faire croire au système que le telescope est plus "froid" que l'air ambiant et cela aura pour conséquence de délencher la résistance chauffante. Exemple pour le telescope :Pour ce faire modifier la ligne 89 du porgamme de en où 3 a été arbitrairement choisi ici mais vous pouvez reprendre la valeur défini à l'étape 2. Televersez le code et vous verrez la puissance de sortie augmenter. Si tout va bien, les températures devraient restées aux alentours de la consigne ici température air + 3°C, par exemple: Ici on voit bien la consigne de 3°C de plus que l'air ambiant, une puissance de 0% car la consigne est atteinte. Une tolérence de 2 * la résolution du capteur est ajoutée afin de ne pas chauffer inutilement, soit ici on ne chauffe que si la température telescope estt inférieure à 18,625°C (18.875°C - 2*0,125°C). Si on voit que la température est maitrisée alors c'est que les coefficients trouvés avec l'autotune sont les bons. On a plus qu'à modifier le programme pour enlever ces 3°C qu'on a simuler et televerser le code final. Et voilà, c'est fini. Je joins en plus des différents programme un fichier zip contenant les librairies nécessaires au bon fonctionnement des codes. Il faut extraire ces librairies dans "Documents/arduino/libraries" et lancer seulement après l'IDE arduino. N'hésitez pas en cas de besoin. Olivier AutotunePIDRC.zip calibrationRC.zip libraries_RCPID.zip RCAutoPID.zip

UPDATE 1 du 19/11/2014: Voir message #2 pour toutes les infos. Olivier Bonjour à tous, habitant en Normandie, nous avons eu quelques jours de soleil récemment qui ont donné envie de sortir le matos! Tout allé bien jusqu'à ce que..... la buée montre le bout de son nez. J'avais bien vu que l'air allait être très humide, j'avais donc anticipé en pointant les Pléiades, pas trop haut sur l'horizon... Munie de son par buée, j'ai dû finalement me résoudre à tout ranger au bout d'une heure... grrrr!! déjà que les belles nuits sont rares... cela augmente considérablement la frustration. J'avais par le passé fabriqué un petit système de chauffage automatique qui depuis est devenu quelque peu obselète, mais qui avait le mérite de n'être pas cher du tout. Les solutions modernes coutants relativement cheres, et c'est peu dire, ont de plus un inconvénient majeur: ces solutions supposent que vous soyez à coté de l'instrument assez souvent pour augmenter / diminuer manuellement la puissance de chauffe. Et si le matériel est trempé, il en va de même pour le bonhomme (ou la femme ^^) à coté!! J'ai dans un tiroir quelques arduino nano, des petites sondes DS18B20, des MOSFETS et quelques petites autres bricoles. Je me décide à me lancer dans une nouvelle réalisation de chauffage, mon cahier des charges est le suivant: - utilisation en poste fixe (donc pas de travail de recherches quand à la limitation de la consommation de courant) - utilisation des composants à ma dispo: sondes de température, mosfet type NPN, led, fils, arduino nano - le système devra pouvoir chauffer 2 instruments indépendament l'un de l'autre (j'ai une lulu principale + une lulu guide) - système complètement automatique, sans intervention humaine donc C'est surtout sur ce dernier point que va porter ce post. La réalisation électrique est rudimentaire: Cela consiste simplement à utiliser une source en 12V dont la variation de puissance se fera en modulant la sortie d'un arduino qui controlera un MOSFET. Ne Pas tenir compte des références pour les 2 MOSFETS 'c'est pour l'exemple. coté composants les sondes de températures doivent être assez petites afin d'être "fixées" directement sur le barrilet de mon triplet (dans mon cas). J'ai des petites DS18B20 parfaites pour cela. Pour le MOSFET un modèle pilotable en 5V fera parfaitement l'affaire. Enfin 2 led indiqueront l'état du fonctionnement de chaque sortie. La led variera progressivement en fonction de la puissance de chauffe. Si une sonde est defectueuse (ou non connectée) alors la led clignotera toutes les secondes. Enfin, le coeur du système, le code! Avant tout chose je dois expliquer mon raisonement sur un point: j'ai volontairement ecarté le fait d'utiliser comme valeur la température de rosée. Je suis parti du principe que si l'élément chauffé avait la même température que la température ambiante locale, alors il n'y aurai pas de buée mais il n'y aurai pas non plus de turbulances visibles sur le système (du moins pas plus que si je devais chauffer au hasard par rapport à une solution toute faite). Cela dit le code est flexible et permet de très facilement ajouter cela si quelqu'un le souhaite. Pour rendre le système complètement automatique nous pouvons envisager 2 scénarios: 1) soit on décide arbitrairement de choisir des valeurs seuils qui enclencheront un seuil de puissance. Par exemple, 1 degrés sous la température ambiante déclenche 25% de puissance, 2° en dessous 50% etc.. 2) soit on décide de partir sur un système plus joli et plus efficace à partir d'une régulation en utilisant un PID Je suis parti sur ce deuxième point. Le premier point à l'avantage d'être très facile à mettre en oeuvre (quelques lignes de code tout au plus) mais le deuxième à clairement un meilleur avantage quand à la régulation!!! en effet, sans rentrer dans les détails, un système PID est un système prédictif qui permet de ne pas chauffer trop mais anticipe la baisse et envoie les justes corrections à apporter pour maintenir la bonne température. Comme expliquer plus haut, le but est donc qu'en cas de chute de température de l'élément à chauffer, la puissance sera augmentée pour eviter une future baisse, cela determiné par les valeurs déjà acquises ou en cours d'acquisition. Le problème, et oui toujours!!, c'est que pour qu'un système de ce type soit efficace il faut lui fournir 3 coefficients dont peut de gens auront envie de la mettre en oeuvre ( moi y compris ). C'est la que l'arduino entre en jeu: des gens biens ( et intelligents) ont crée des bibliothèques permettant de calculer automatiquement ces coefficients. Ah le bonheur. J'ai donc implémenter toute cette logique afin d'avoir un système réellement automatique et autonome!! concretement, que fait le programme: Lors de la première initialisation (Voir procédure plus loin), le programme va lancer un "auto tune" afin de calculer les bons coefficients (un peu comme sur les imprimantes 3D qui utilise ce système sur leur hot end). Une fois fini les coefficients sont stockés dans l'eeprom et seront ensuite utilisés comme base pour la régulation. C'est le point fort!! ca le fait pour vous , une fois fois pour toute. Une fois lancé, le programme prends des mesures toutes les 10 secondes (valeur que l'on peut changer dans le fichier de configuration config.h). Ces valeurs vont agrémenter le PID qui calculera la nouvelle puissance à appliquer. Bien entendu le déclenchement du chauffage ne se fera que si l'élément chauffé voit sa valeur passer sous la température de l'air ambiante. Initule de chauffer pour rien non plus Programme: Attention, il faut installer les librairies suivantes: - "DallasTemperature" et "PID_v1_bc" depuis l'IDE, - "PID_AutoTune_v0" depuis le github: https://github.com/br3ttb/Arduino-PID-AutoTune-Library/tree/master Lors de l'ouverture du fichier arduino, tous les paramètres modifiables sont dans le fichier "config.h" Il faudra y apporter les corrections suivantes: Modifier les adresses des sondes de températures sont uniques. Je joins un scanner d'adresse que vous pouvez utiliser pour connaitre les votres. Si vous ne disposez pas de deux instruments comme moi (lunette principale + lunette guide) vous pouvez commenter la ligne" #define GUIDE " qui ne gardera donc que la partie telescope. L'affichage des températures sera visible dans le moniteur série. Il est important de mettre à 0 les valeurs des corrections des sondes dans le config.h: à l'achat celles ci pourraient ne pas indiquer la même valeur de température. Il suffit de les mettre dans un endroit à la même température et de relever les écarts et de modifier les coefficients de correction afin qu'elles donnent toutes les mêmes valeurs ----------------------------------------------------------------------------------------Procédure Auto tune:-------------------------------------------------------------- Pour obtenir un auto-tuning efficace et des coefficients PID bien adaptés au système de chauffage pour l'élément à chauffer, voici quelques recommandations spécifiques : - Stabiliser la Température Ambiante Avant l’Auto-Tune : Pour minimiser les interférences dues à des fluctuations extérieures, assurez vous que le système est dans un environnement stable. Les variations de température ambiante affecteront moins l’auto-tune si vous le lancez dans des conditions proches de celles où ton télescope sera utilisé la plupart du temps (par exemple, une nuit sans changement brutal de température). - Initialiser le Système à une Température d’Équilibre : L’auto-tune sera plus précis si le télescope commence à une température proche de celle de l’air. Cela garantit que le chauffage soit principalement responsable des variations de température, sans effets perturbateurs dus à des changements rapides de température naturelle ou au refroidissement initial. - Éviter les Courants d'Air et les Sources de Chauffage Parasites : Un courant d'air froid ou une source de chaleur peut créer des perturbations thermiques parasites. Place le système dans une zone abritée, sans flux d'air direct, pour éviter que le PID ajuste mal ses paramètres. - Ajuster le Paramètre LookbackSec : Actuellement, aTune.SetLookbackSec(10); impose une fenêtre d’observation de 10 secondes, ce qui pourrait être trop court pour un système lent comme pour certain (fonction du diamètre, épaisseur ...). Essayez une valeur plus longue, par exemple 30 secondes ou même 60 secondes, pour permettre à l’auto-tune de mieux capter la réponse du télescope, surtout si la chauffe et le refroidissement sont lents. - Optimiser le OutputStep (puissance d’impulsion) : L’auto-tune utilise SetOutputStep(50); pour chaque impulsion, équivalent à une puissance de 50 unités PWM (soit 20 % de la puissance totale de 255). Si les variations de température sont lentes, augmenter ce paramètre, par exemple à 70 ou 80, pourrait accélérer le processus en provoquant des oscillations plus marquées, mais attention à ne pas surchauffer. - Éviter d’Interrompre l’Auto-Tune : L’auto-tune prend un certain temps, mais il est essentiel de le laisser aller jusqu’au bout pour obtenir des valeurs précises. Interrompre l'auto-tune ou forcer un recalcul pourrait conduire à des valeurs PID imprécises, ce qui réduirait l’efficacité du système par la suite. ----------------------------------------------------------------------------------------FIN Procédure Auto tune:-------------------------------------------------------- Voilà les grosses lignes. J'espère qu'il pourra servir à d'autres passionnés bien embétés par la buée!! Je fournis aussi un petit programme simpliste de chauffage basé sur des seuils (que j'avais initialement conçu avant de passer à la régulation par PID) scenario 1 plus haut! - le programme simpliciste se nomme RC_automatique - le scanner pour les sondes: scanner_1_wire - le programme avec régulation PID: AutotuneRC. N'hésitez pas si vous avez des questions ou besoin d'aide. Olivier scanner_1_wire.zip

Personnellement, au vu de la courbe et des valeurs du "current dark" je ne m'embeterais à refaire les darks si la température varie tant que le temps de pose reste le même.... m'enfin c'est mon avis

Non! le fait de faire beucoup d'image fait baisser le bruit final de l'image. Le bruit diminie avec la racine carré du nombre d'images L'image master résultant de l'empilement de ces images ne sera que meilleure.

Pour ma part il n’y a qu’un seul fichier crée, le meme meme nom que le ino mais en .bin, le 1er sur la photo Et oui, j’ai oublié de le dire, il faut dans mes firmwares remettre ses ssid et password ainsi que l’ip et passerelle par defaut! dsl

Je regarderai a l’occasion. ma version est une 1.8.19 mais en effet c’est cette version qui a le mieux fonctionné pour moi. ps: j’ai dit une betise de tete mais c’est bien un « .bin » le fichier. de 800ko environ ps2: essais ce tuto: https://tingene.com/blog/index.php?article47/bin-binary-files-sketch-arduino-ide

Je dois partir, mais avant de balancer cette version, si tu veux voir si tout fonctionne, tu peux ajouter des Serial.println dans la partie du MLX. Si ton ESP32 est raccordé avec un câble au port série tu pourrais y afficher toutes les valeurs intermédiaire et des valeurs de corrections etc.... cela pourrait permettre de voir où cela pose problème. Désolé je peux pas faire mieux pour le moment. Olivier PS: vérifie aussi si sur la page web tu as bien les bonnes valeurs de K affichées, sait on jamais!! les valeurs affichées sont celles dans la flash et sont celles uilisées dans le calcul!

@jduffas Tu peux essayer cette version: J'ai modifié le code afin que la température ambiante utilisée dans le calcul ne prenne pas la valeur du MLX90614 ( qui est exposé au soleil) mais plus le BME280 qui lui devrait normalement être à l'ombre.... esp32AstroV4.0.3finale.zip

Re @jduffas, en effet dans le tableau il manquait un EXP dans la formule. Je remets le tableau à jour. A la première ligne tu y verras tes valeurs. En revanche la fomule de l'ESP32 elle est bonne. Ici tu trouveras la conversation ChatGPT comme tu l'as fait: https://chatgpt.com/share/96da44a5-70ad-4237-940b-20cd2dc0e78e tu verras que le resultat du tableau et lui sont cohérent. Avec une température ambiante de 40°C et une température de ciel brute de 3,71°C tu obtiens une correction de 15,38°C Donc en effet la températuer résultante corrigée serait de 3,71 - 15,38 = -11,76°C. Si par contre tu as une valeur plus basse c'est qu'il y a autre chose 😕 à voir quoi! Pour mettre à jour par OTA c'est très facile: 1) tu modifies le firmware avec l'IDE arduino et tu sauvegardes, 2) dans l'IDE tu fais "croquis" puis "exporter les binaires compilés" L'IDE va alors compiler le code. 3) Dans le repertoire où il y a le fichier ino tu va avoir un nouveau fichier en ".bin" 4) dans la page web OTA de l'ESP32 tu charges ce fichier, 5) c'est fini! Olivier Calculateur coefficients METEO V1.01.xls

Et bien justement il n'en utilise pas!! c'est purement du soft. En gros, tu connectes à NINA n'importe quelle source météo dans l'onglet ObservingConditions. ca peut être ton AAG, ma statioj ESP32 ou une clé API d'une page web etc... Une fois les données lisibles par NINA, l'autre driver ne fait que récupérer les données que tu souhaites utiliser dans ton safety. Supposons que dans les données météo tu ai les éléments suivants: - temp ciel, temp amb, nuages, pluie, vent, luminosite. tu peux alors choisir tout ou seulement les parametres que tu souhaites utiliser dans le safety, par exemple uniquement temp ciel, vent et pluie. Pour chacune des conditions gardées tu devras simplement renseigner les limites admissibles par des fonctions logique =, > , >=, < et <=. Par exemple si tu décides de dire, non safe si vent >= 3 m/s (oui dans NINA le vent est en m/s!) Des que l'une des conditions choisis n'est pas satisfaite alors on passe en mode Unsafe. La force de ce driver c'est de simplement récupérér une donnée (choisie!!) de la page météo de NINA et que tu y affectes le seuil. Comme tu choisis la / les variable(s) à suivre c'est fantastique!! Pour les 49° d'inclinaison c'est surement juste. Je n'ai jamais mis la station dehors pour le moment. Je te fais confiance sur le sujet donc J'ai fais une petite modification du code si tu veux: j'ai ajouté une variable seuil_chauffage dans le bme280.cpp: Dans les fonctions du BME80 j'ai ajouté le code permattant de savoir si le chauffage est nécessaire: Et dans la boucle principal, j'ai défini à 60 secondes le délai de lecture. Si NeedChauffage est vrai alors on chauffe: J'ai défini le PIN de chauffage sur la PIN arbitraire 12 en haut du code principal. On peut ne pas utiliser la fonction de chauffage si on commente la ligne #define CHAUFFAGE, car pour les gens comme sur un tout petit panneau solaire, la batterie va faire glace Néamoins, le chauffage ne s'allumera que si l'ESP32 n'est pas en mode "sleep" afin de conserver l'energie au maxium!! Attention quand même pour les lecteurs : il ne faut surtout pas brancher une resistances de "puissance" pour le chauffage directement sur le PIN de l'ESP32, il ne va pas du tout apprécier. Le PIN devra plutôt alimenté soit un MOSFET ou un petit relai (avec sa diode de roue libre) pilotable en 3,3v qui permettra l'utilisation soit d'un 5v ou d'un 12V. A vos risques et périls si vous ne savez pas utiliser ce genre de composants. le code de l'ESP32: esp32AstroV4.0.1finale.zip Olivier

Bonjour @Discret68, le detecteur dont tu parles a été baptisé détécteur de gouttes dans la dernière version. J'ai en stock une version 4.0.1 qui était destinée à un autre jean Pierre ^^. La version 4.0.0 fourni au driver ascom la quantité de pluie en mm/heure. Le probème vient du fait qu'avec NINA il est impossible d'avoir à la fois la quantité de pluie et l'information de la présence de gouttes sur ce capteur. Dans la version 4.0.1 j'ai transformé la variable "pluie" afin que si des gouttes d'eau sont présentes sur le capteur alors la variable remontée vers ASCOM est 1mm/heure, quelque soit la quantité d'eau mesurée par le pluviomètre, ce qui obligera la watchdog a fermer l'observatoire. En revanche sur la page web la donnée du pluviomètre est bien mise à jour. C'est un peu problèmatique de ne pouvoir gerer qu'un seul capteur car ce qu'on on recherche avant tout est une redondance des systèmes de sécurité. Bref je peux donner la version 4.0.1 pour ascom. Concernant le safetymonitor j'utilise celui décrit sur la plage ascom elle même qu irenvoi ici: https://www.dehilster.info/astronomy/ascom_environment_safetymonitor.php J'avais initialement ajouter quelques lignes de codes pour gerer un safety monitor (d'ailleurs dans le json renvoyer par les commandes il existe toujours la valeur Safe qui gere cela) et créer un petit driver fourni à la page 1 de ce topic. Cependant, la facilité d'utilisation et surtout la souplesse de celui developpé au dessus n'a strictement rien à voir!! c'est ultra puissant et je préconise largement son utilisation! Il s'occupe de récuperer les valeurs souhaitées depuis le driver météo et en fonction des "limites" que vous fixez dans le driver, il gerera la partie safety, et c'est excellent!! Enfin, pour la partie capteur de gouttes, je n'ai pas prévu pour le moment d'utiliser un système de chauffage même si en soit le code n'est pas compliqué à developper. Le problème réside surtout dans la façon que chacun a besoin de gérer cela. Dans mon cas personnel je n'ai pas encore assez developpé la partie hardware, qui pour le moment a les trippes à l'air ^^, mais je serai surement obligé d'y reflechir puisque dans ma Normandie il n'est pas rare (non j'ai pas envie de dire tout le temps ) que l'humidité soit omniprésente lors de belles soirées (sisi il y en a ). D'ailleurs, concernant la partie conception, ma météo sera montée avec un petit panneau solaire. Etant à 49° de latitude j'inclinerai le panneau ainsi que le boitier contenant le le TSL et le MLX à cet inclinaison vers le SUD. Du fait de cette pente assez raide je verrais si le besoin d'un chauffage se fera sentir. De plus, et c'est propre à mon installation, je ne ferai pas de remote éloigné, seulement depuis le jardin, donc je ne recherche pas une solution à une eventuelle utilisation à distance autonome. Si bien que s'il y a risque de nuages, je ne lancerai pas de session. Tout cela pour moi est une simple sécurité du moment où j'irai me coucher. Mais à mon sens le plus important des capteurs ici est le MLX90614. S'il est correctement exploité, alors il detectera la présence de nuages bien avant l'arrivé de la pluie. Et le capteur de gouttes, si humidité il y a, ne devra pas refermer l'abri, car sinon chez moi il le fermera très / trop souvent ^^. Pour le ré chauffage du capteur de gouttes on peut récuperer a valeur de l"humidité ambiante ainsi que la température ambiante, et determiner avec deux valeurs la température du point de roséeet si c'est nécessaire de chauffer! Ca resterait un peu empirique mais ca devrait fonctionner. Reste encore à savoir quelle puissance mettre pour réchauffer juste ce qu'il faut... N'hésite pas au besoin. Olivier

Alors en faite pas tant que ca mon flip flat est realisé avec un panneau led circulaire provenant d'un plafonnier et reste assez lours malgré tout, je dirais failement 300gr. Les 30kg annoncé sont dépendant de la tension d'alimentation. De plus les 30 kg sont à 1cm. Dès qu'on séloigne un peu la force diminue drastiquement. A 2cm on a plus que 15kg, a 10 cm 3 kg etc!! Le mien a un axe centrale environ à 15cm, soit plus que 2kg de couple!!

Bonjour à tous, il y a de ça quelques années j'avais participé aux poste sur la création d'un système de type Flip Flat avec @gehelem notament (sous un autre pseudo à l'époque car je me suis fais pirater grrr) qui consistait à utiliser le driver ascom de Alnitak pour piloter une solution avec un arduino. Ce système fonctionnait bien et j'en étais très satisfait. Mais le temps ayant eu raison de mon système, j'ai voulu moderniser mon matos. J'ai par ailleurs fait une station météo qui se trouve sur un autre post. Le but ici n'est clairement pas de réinventer quelque chose qui marche, mais juste de faire un peu "mieux que l'ancien" Et quand je vois les prix pratiqués par les revendeurs pour une chose pareille je suis effaré!! Si cette solution qui marche peut vous faire économiser quelques "sous" que vous pourrez injecter dans autre chose de moins "DIY" alors j'en serai le premier ravi. Comme je disais la base du code est la même que celle fourni par @Lumotori dans les derniers postes de la version précédente. Je l'ai juste remanieé afin de le découper en plusieurs fichiers cpp et h pour que l'intégration de mon code soit plus facile. Mes ajouts sont les suivants: - Utilisation d'un ESP32 en lieu et place d'un arduino nano, - utilisation du SPIFFS au lieu de l'EEPROM pour enregistrer l'état du Flip Flat, - création d'une interface web pour piloter la flip flat: C'est le plus de cette page, on peut directement y gérer les valeurs de références du servo sans avoir besoin de recompiler, à la manière d'un "RB Focus Excalibur". Cela permet de parametrer très facilement les positions de fermeture et d'ouverture du Flip Flat. On peut aussi allumer la "led" et faire varier la luminosité, cela sans avoir besoin de passer par le driver ASCOM. Un aperçu de l'état du cover et de la led sont présents. Pour la partie cover, à l'initialisation il se peut que la page affiche "MOVING". C'est lié au code. Après un 1er déplacement la valeur devrait être la bonne. - Possibilité de mettre à jour la version du firmware de l'ESP32 par OTA -> plus besoin de connexion filaire entre l'ESP32 et le PC pour mettre à jour, on envoie le fichier directement depuis la page web. Un aperçu de la page: Pour la partie firmware: Toutes les variables liées à l'utilisation du FLIP FLAT sont stockées dans le fichier "constants.cpp". Toutes les variables liées au WIFI sont stockées dans le fichier "variablesWIFI.cpp". Vous pourrez ici définir votre SSID et votre mot de passe wifi. Vous pourrez aussi choisir l'adresse IP fixe de votre ESP32 afin que ce soit plus facile pour accéder à la partie web. Je n'ai pas développé de partie bluetooth car c'était l'un ou l'autre. En général je me connecte depuis mon PC d'où la raison de ce choix. Pour la partie conception: vous pouvez demander ici mes fichiers pour une lunette de 80mm. Sur les photos je n'avais pas encore installé la partie FLAT. Il y a aussi tout plein de belles choses sur le 1er TOPIC. Toute solution imprimée, usinée etc sera bien meilleure marché que l'achat Le fichier: Firmware ESP32 version 3.0.2: ESP32FlipFlatV3.0.2.zip Pour ASCOM, dans NINA choisir directemen Alnitak Flip Flat même si vous n'utiliser pas la partie FLAT! Olivier

Bonjour à tous, en faisant une recherche sur le fofo je me suis rendu compte que j'avais surement mal placé mon topic sur un programme "en cours". Il aura surement plus sa place ici, cependant, afin de ne pas créer de pertubations je vais simplement mettre un lien vers ce poste: Je l'avais initialement placé dans le sous forum Logiciel. hmmmm Bref, pour ceux que cela intéressent il s'agit d'un projet de station météo permettant la gestion d'un abris astro. Bonne journée à vous tous. Olivier

Oui, avec une température sol de 30,66 °C et les coefficients de base, pour une valeur de Ts brute à 6,5°C on aurait une Tsky de -3,74°C donc pour être "dégagé" il faut -8°C donc le programme devrait afficher une couverture nuageuse de 54% environ.

Pour faire assez simple, par un jour de très beau du matin au soir, sans nuages, le ciel idéal donc ^^, si on relève les températures ambiantes et du ciel toutes les 30 minutes admettons, on peut tracer les courbes sur excel. la courbe de température ambiante devrait avoir une forme de cloche puisque le matin la température est "fraiche" puis va monter au cours de la journée jusqu'à un maximum, puis redescendre. Une deuxième courbe montrant les température du ciel avant corrections. Il faut alors tracer une troisième courbe, qui elle reprend chaque température de ciel mesurée à laquelle on aura appliquée la correction en fonction des K1 à K7. Cette nouvelle courbe devra alors être modifiée en faisant varier les coeffcients dans le but qu'elle soit la plus plate possible -> On stipule donc qu'au cours de la journée, quelques soit la température ambiante, la température du ciel elle est stable et toujours la même!! J'espère avoir été clair PS: Je te joins un petit calculateur. Tu peux t'entrainer pour voir les effets. J'ai volontairement laissé les noms de ceux utilisés par AAG afin de plus de clarté si tu reprends leur guide ici: https://lunaticoastro.com/aagcw/TechInfo/SkyTemperatureModel.pdf Les valeurs de températures ambiantes sont les miennes en Normandie prévues pour demain.... bien loin ce celles du Sud Les températures du ciel mesurées elles sont imaginaires. Mais cela permet de bien comprendre De base, quand tu l'ouvres tu verras qu'avec les coefficients dorigine on a: - la courbe de la température ambiante Ta est bien une "cloche". - la courbe de la température du ciel mesurée Ts est aussi une "cloche" - la courbe de la température du ciel corrigée Tsky est aussi une "cloche". Le but est de faire varier les coefficient K1 à K7 pour que cette courbe Tsky deviennent plate: Si tu met par exemple: K1 à 90, tu verras alors que la courbe deviens quasi plate avec une valeur de -43°C environ. En fonction des vraies valeurs mesurées il faudrait surement retoucher d'autres paramètres mais en gros tu peux retenir ceci: K1 va enormément impactée la forme de la courbe, K2 va faire monter ou descendre cette courbe le long de l'axe des température, K3 a K5 sont pour des corrections ou la température ambiante dépasse les 30°C. Dans le modèle actuelle K6 etK7 ne sont pas pris en compte, un peu dur à mettre en place pour le moment!! N'hésites pas au besoin. Olivier Calculateur coefficients METEO.xls

Bon, donc on peut dire que le driver meteo est hors de cause, ce qui je ne le cache pas m’arrange pour la température a -2°C, il ne faut pas oublier que les valeurs des coeff k1 a k7 doivent être « retravaillées » avec votre ciel! Et ces coeff changent avec la saison! pour la procédure vous pouvez aller voir le site de Lunatico et de l’aag cloudwatcher.

Bonjour, Je n'ai jamais eu ce cas au paravant, que ce soit moi ou l'autre astram pour qui j'ai developpé cette fin de projet. Je ne peux malheureusement pas trop vous dire pourquoi. Etes vous sur une version béta de NINA? Pour la couverture nuageuse j'avoue aussi ne jamais avoir eu de soucis. Les paramètres de ciel clair ou non sont définis en dur dans le firmware de l'esp32 dans la section MLX90614.cpp: Donc s'il fait moins de -8°C alors c'est 100% dégagé, s'il fait plus de 0°C alors 100% couvert et entre les deux c'est une simple valeur mappée de 0 à 100%. Si on lit les 75% de NINA alors la température devrait être de -2°C. Le truc c'est qu'avec une température de -227°C la couverture nuageuse devrait être à 0% et même en mettant des dizaines supplémentaires on ne devrait pas avoir ce résultat. Je pense donc qu'il n'y a pas de corrélation entre les 2 malheureusement... un bug dont j'ignore la cause. Ce serait quand même très surprenant qu'un driver de monture fasse planter un driver observingcnditions. Si c'est le cas le problème vient forcément de NINA. Je peux cependant vous proposer une chose: Avez vous installé les outils développeurs ascom? sur un de mes PC je n'avais aucune valeur dans NINA. Après avoir installé les outils developpeurs tout à fonctionné.... allez comprendre!! Vous pourriez aussi essayé un autre soft comme SGP en version gratuite pendant 30jrs, vous pourrez comparer 😕 Redite moi, votre retour m'interesse. Olivier PS: quand vous avez NINA qui affiche ces valeurs abérrantes, que dises les valeurs si vous ouvez la page web ou si vous faite la requete ip-ESP32/ascom dans sur un navigateur?

merci pour le fichier. J'ai freecad mais je prefere fusion. Je convertirais le fichier

C'est une bien belle réalisation ca. Je suis en cours d'impression de la mienne. Je n'aurais pas forcément laissé le TSL en plein soleil de cette façon mais à priori pas de risque de surchauffe ^^. Vous auriez un fichier que je pourrais utiliser dans fusion 360? Le BME est dans les coupelles? je suis parti de la conception de ce modele: https://www.thingiverse.com/thing:1067700

Alors c'est une question a débat Mon boitier n'est pas terminé, pour le moment c'est une opération à coeur ouvert. Dans l'idée; mon boitier étanche renfermera le TSL2591 et une mince vitre sera posé devant celui ci. Coté MLX90614 le modèle que j'au acheté est un modèle étanche de base. Je compte simplement percer le boitier au bon diamètre et y mettre de la colle chaude et du joint silicone pour rendre le trou étanche, le capteur ne craignant rien. Pour t'inspirer tu peux regarder à quoi ressemble le boitier AAGCloudwatcher ici :https://skymeca.com/aag-cloudwatcher/57-aag-cloudwatcher.html Je me suis beaucoup inspiré de leur produit Olivier

j'ai édité mon message précédent avec quelques petits calculs. Pour info, les 90% chez moi en normandie sont mêmes sous estimés

Merci pour votre retour. Le mode Modem sleep coupe l'antenne wifi ainsi que le bluetooth. Une fonction dans l'ESP32 vérifie qu'aucune requêtes n'est reçu durant 5 min. Une fois ce délai passé l'ESP32 rentre en mode modem sleep. Dans la gestion du mode l'antenne wifi est desavtivé mais est régulièrement rallumée pour vérifier si des requêtes ont été reçues. Il s'agit là d'un mode propre à l 'ESP32. Sans être totalement coupé, tout comme un courant hashé, la consommation sera bien moindre que si c'était toujours activé. Un autre mode "Deep sleep" couperait intégralement l'ESP32 mais pour le réveiller il faudrait utiliser une source extérieur tel un bouton, donc nettement moins pratique. Je vous invite à lire la page ici qui présente les différents modes https://letmeknow.fr/fr/blog/142-tutoriel-les-sleep-modes-de-lesp32 Pour estimer le gain d'économie d'énergie, considérons un scénario courant où l'ESP32 passe 90% de son temps en veille et 10% en transmission de données. Mode Normal: Transmission de données (10% du temps): 200 mA Veille active (90% du temps): 80 mA Consommation moyenne: 0.1 * 200 mA + 0.9 * 80 mA = 98 mA Mode Modem Sleep: Transmission de données (10% du temps): 200 mA Modem Sleep (90% du temps): 5 mA Consommation moyenne: 0.1 * 200 mA + 0.9 * 5 mA = 24.5 mA soit une économie d'environ 75%. Egalement, le fait que les capteurs ne lancent pas de mesures lors de ce "sommeil" fait grandement économiser de la batterie. Olivier

PS: clarification: Quand je dis que l'utilisation de l'anémo et du pluvio sont nécessaires, je sous entends que je ne peux pas les retirer du code de l'ESP32 (avec un #ifdef pluvio par exemple), car la chaine de caractères utilisée par NINA attends cette valeur. Donc on peut utiliser le driver sans ajouter l'anémo et le pluvio, juste que les les valeurs dans NINA et sur le web serveur resteront à 0. On peut aussi forcer la mise à 0 dans le code pour ces deux valeurs dans la génération du JSON en mettant 0 au lieu des variables pluie et vent. Le seul capteur obligatoire pour que l'ESP32 fonctionne est le BME280. Olivier ok. J'avoue n'avoir jamais procédé ainsi. l'installateur provenant des modules ascom developper je préfere ma méthode en passant toujours par celui de windows.