hoxca

1) le png de sortie ne passe pas en taille sur postimg ! et j'ai aujourd'hui un 403 lorsque je tente d'accéder a l'image source non resamplée par postimg... bref je n'ai pas compris cette nouvelle interface. 2) la calibration est faite en astrométrie, mais j'ai un peu retouché les niveaux niveau avec un masque d'étoiles de toute façon la couleur des étoiles est merdique. fredo je pourrais te passer la brute d'intégration...

J'indiquai mon image non comme référence mais pour avoir une idée de ce qu'il faut rechercher. Et pour faire corps avec la remarque de rachid +4 pts de bleue (tu as déjà les éléments sur la neb) Un peu de contraste pour sortir un peu le nuage sombre... Et oui, il faudra alors certainement traiter un peu de bruit.

Je suis comme don quichotte, je me bagarre comme un diable avec le train optique de ma FSQ avec le temps maussade, je n'ai pas pu itérer comme je le souhaitais. La 071 Pro s'en sors plutôt bien à -10° en gain 0, même les pauses de 180 secs sont peu être un peu longue (je crame un peu); la dynamique m'a permis d'aller rechercher des truc dans l'histogramme... Il m'a fallu largement baisser les valeurs de la STF. respectivement -7.5 en shadow clipping et 0.12 en target background ! Bon j'ose à peine poster car rien n'est comme je le souhaite... Plus ça rate et plus ça à de chance de réussir ! La prochaine fois, je commence par simplifier le train ! (je vire le filtre infrarouge et aussi le CAA) Voici donc tout de même le petit traitement:

Hello alan, j'aime particulièrement le premier filé avec juju qui arrive comme un gros boulet ! cela rajoute à la dynamique de l'image. bravo !

Que t'arrive t il fredo. Tu tire dans le violet et imho le localtruc ou le HDR est trop prononcé sur Iris. Je trouve personnellement la version de jojo plus douce et mieux équilibrée même si Iris et les grosse étoiles manque clairement de saturation. Jojo il faut travailler les masques

Oui, belle image jojo. Je suis complètement aligné avec rachid, il y a normalement des extensions sur cocoon qui devrait ressortir voir ici de quoi nous parlons ici: https://www.astrobin.com/full/314429/0/ Il doit rester des choses à aller chercher dans le signal.

A la demande de Fredo, je partage la méthode pour l'installation de module PCL dans PI. La question originale de fredo porte sur l'installation du module PCL Subframe Selector (avancé) https://pixinsight.com/forum/index.php?topic=11780.0 Pour ce faire, il faut avoir une version compilée de la librairie pour l'OS de destination (Windows, Linux ou OSX). Ensuite il faut ajouter le module avec le menu: Process > Modules > Install modules On browse ensuite le repertoire ou se trouve ton module compilé et on fait l'ajout du module ! \o/ C’est installé ! Il existe alors un nouveau process dans: Process > ImageInspection > SubframeSelector dans le même menu que Blink et Statistic Bon hack !

Je suis passé par la !

\o/

hello fredo, L'histoire de la bascule de hostingpics j'ai bien compris. et pour ce qui est du besoin de rapatriement des images, il s'agit de ma première réaction sur la ML. Ma question est plus spécifique: Bruno indique ceci: "la récupération des urls de hostingpics est assez galère car noyé dans le champ post_text dans la base de données avec des caractères spéciaux" Je demande un exemple de champ post_text avec une image hostingpics et pour ce qui est des caractères spéciaux j'imagine que c'est de l'URL_Encode qui fait le boulôt... sinon un checksum cela se calcul et cela s'update. Mais bon, il ne faut pas compter sur moi pour faire des scripts curl en php. Don't feed the :troll:

Hello, Je ne suis pas certain de comprendre la problématique. Un petit exemple du champ en sortie de bdd m'aiderai a saisir. On parle d'un url_encode c'est cela ?

Bon, \o/ j'ai des mesures ! J'ai fait comme on me l'a indiquer dans la datasheet du TSL237. Nous y voila; Je lui ai soudé au plus près un condensateur de 100nF et je l'ai mis sur la breadboard avec une patte au VCC, une au Ground et la sortie sur la pin digital 5 de l'Atmega328. Elle est toute petite la bestiole, et il m'a fallu le souder le condo au microscope... Vacherie de composant de surface ! Pas facile a tenir J'ai été chercher la librairie FreqCounter dont l'objet est de compter le nombre de fronts montant sur une période donnée. Et dans le code on commence par convertir cette mesure de pulse en une fréquence. // Get frequency from the TSL237 sensor double getfreq(short period) { double frequency = 0; long pulses = 1L; FreqCounter::f_comp = 0; // Cal Value / Calibrate with professional Freq Counter FreqCounter::start(period); // Gate Time while (FreqCounter::f_ready == 0) pulses = FreqCounter::f_freq; delay(20); frequency = (pulses * 1000) / period; return frequency; } Comme pour la mesure le calcul de la luminosité, j'ai passé les résultats dans la librairie statistique. La mesure est un peu plus longue, puisqu'il faut acquérir le nombre d'échantillons attendu. Cependant, je suis assez satisfait du résultat car les frequences mesurer sont correctes par rapport au mesure de frequences réalisées avec l'oscilloscope. J'ai une erreur de l'ordre de */- 0.08 Hz Du coup, j'ai fait quelques mesures et collecté les résultats sur la ligne de debug avec le port série. Les 2 premières mesures sont effectués dans le noir complet du labo, (J'ai caché la led rouge du FTDI232). Seul la lumière extérieur passe par la fenêtre. La 3éme mesure est réalisée alors que l'écran du mac s'est rallumée dans la pièce à la valeur d'intensité minimale et avec un flux à 1200K Pour la 4ème mesure j'ai rallumé un petite lampe de bureau. Il est clair que la fréquence monte très très vite, avec une petite lumière on a déjà presque 33 kHz ! Cela vous donne une idée de la précision de la bête TSL237. On remarque aussi, qu'en basse lumière la photorésistance n'a absolument pas détecter le rallumage de l'ecran du mac. On est toujours à 0.002 lux. En revanche, la petite lampe de bureau à bien remonté le nombre de lux à 11.64. Je suis entre 120 et 150 lorsque j'allume l'halogène. Pour ce qui du calcul de l'irradiance et du sqm, je me suis basé sur des calculs déjà existant. La fréquence retournée est toujours en hertz. Je n'opère la conversion en kHz que si nécessaire et seulement pour l'affichage. frequency = getTSL237(12,period); irradiance = frequency / 2.3e3; sqm = log10((irradiance / 6.83) / 108000) / - 0.4; Bon, de loin cela à l'air de fonctionner ! Au passage le LCD affiche donc la banner SQM avant la mesure. Si on appuis sur le bouton jaune, tout s'éteint et on mesure pendant quelques secondes avant d'afficher sur deux lignes: Les LUX et la valeur SQM. Il faut maintenant souder le bordel sur une plaque d'essai et encapsuler le tout dans une petite boite. J'ai aussi un peu de nettoyage dans le code à faire, mais c'est classique j'en ai mis un peu partout

Bonjour Axel, En fait, la précision de la mesure n'est pas très importante, On veux juste une évaluation globale. Il s'agit de savoir dans quel environnement on se trouve afin de pouvoir régler la période de référence pour la mesure de fréquence sur le TLS237. En gros, je viens de coder un truc du genre: si lux < 1 alors crépuscule astronomique => période de mesure 2 secondes si lux < 3.4 alors crépuscule civil => période de mesure 1 secondes si lux < 20 alors lieu public ombre => période de mesure 0.5 secondes si lux > 20 alors il fait jour => période de mesure 0.1 secondes L'idée étant de compter les fronts montant d'un signal périodique carré et d'en déduire la fréquence de lecture sur le TSL237. avec cette librairie: Frequency Counter Library Pour référence, voici le tableau de la page lux de wikipédia J'ai fait quelques tests sur le TLS237 hier soir. Dans l'obscurité à la lumière de mon écran le TSL237 à 20cm, l'oscilloscope indiquait une fréquence de 4 Hz. A la lumière, dans le bureau on passe vite la barrière du kHz...

Poursuite du projet avec l'implantation d'une photorésistance (ou LDR) sur la plateforme. L'idée est de savoir détecter si il fait nuit et d'avoir une évaluation du flux lumineux dans lequel baigne le capteur. Pour ce faire, j'ai choisi un composant très standard le photoresistor GL5528, dont vous trouverez ici la datasheet: GL55-SeriesPhotoresistor.pdf Le principe de fonctionnement est très simple. Le composant agit comme une résistance variable en fonction du flux lumineux l'impactant. Lorsqu'il est dans l'obscurité totale sa resistance est > 1MΩ Pour l'utilisé avec notre microcontroleur, on implémente un très simple diviseur de tension Dans notre cas R2 est une résistance fixe reliée à la masse et à la pin A0 de notre microcontroleur et le GL5528 est relier à la pin A0 du microcontroleur et a VCC soit dans notre cas 5V. Le code du micorcontroleur fait la conversion de la valeur analogique lue sur la pin A0 (valeur entre 0 et 1023) pour obtenir le voltage au borne du LDR float measured=analogRead(LDRpin); // take a single reading measured = 5 - (measured * 5.0 / 1023.0); // convert to a voltage La valeur du voltage est affiché sur l'afficheur en Volt. Une fois ce voltage obtenu, le code effectue un conversion pour obtenir la valeur en lux. (j'ai fini par choisir une resistance de 47KΩ pour R2 afin d'avoir une plus grande sensibilité en faible lumière) double getlux(float LDRvoltage) { float LDRohms = 47000 / ((5/LDRvoltage) - 1); double lux = (double)32017200 / (double)(pow(LDRohms, 1.5832)); return lux; } Cependant j'ai remarqué que le capteur est très capricieux et peu renvoyer un nombre aléatoire de mesure erronées (outliers) Comme nous sommes des astrophotographes, nous savons très bien traiter ce genre de problèmes statistique dans nos mesures. J'ai donc ajouter un code pour calculer l'écart type de chaque mesure sur un échatillon de 25 mesures et j'expulse les valeurs aberrantes donc le σ > 1.65; avant d'en sortir une moyenne Voila ce que cela donne en lumière dans le labo Ce soir la lune était présente et j'ai mis le capteur sous son regard doux ! (avec 2 valeurs différentes de R2 10kΩ et 47KΩ) J'ai obtenu les échantillons suivants sur une sortie debug en port série. Moon 10k Moon 47k On note: cCount le nombre d'échantillons, oCount le nombre d'echantillon retenu, SD l'écart type dans les valeurs retenues pour la moyenne et la valeur en lux qui en découle ligne suivante Il me semble que la résistance de 47K va l'emporter car elle est plus juste en basse lumière. Certes le capteur va saturer plus vite en journée, mais cela à peu d'importance pour notre usage

Oui alban, tu as tout à fait raison. Je commence à voir venir les étapes du projet qui sont les suivantes. Je ne suis pas électronicien, si je fais des erreurs grossières dites le moi [glow=red]Phase 1:[/glow] Le device est destiné à un usage dans les mains d'un utilisateur: * Proto I/1: 1) Un proto qui marche avec un LDR et un TSL237, c'est alimenté avec une pile 9v, l'affichage s'effectue après la mesure sur un LCD 1a) Le LDR permets d'avoir une évaluation du nb de lux qui touche le capteur (ce ne sera pas précis, mais si le nb de lux est > 5, il est inutile de faire une mesure avec le TSL237) 1b) On sait lire la fréquence du TSL237 et la convertir en irradiance µW/cm^2 et mag/arcsec^2 * Proto I/2: 2) Dans la même configuration que précédemment, on peux ajouter le MLX90614 pour avoir une idée de la couverture nuageuse * proto I/3: 3) Toujours sur la même plateforme, on rends le truc communiquant et on implémente un protocole de communication ici, toujours pas besoin de passer sur du LPWAN, j'imagine que l'on sera sur un ESP8266 / ESP32. Si on sait remonter les valeurs par le réseau, on peux abandonner le LCD ! * proto I/4: 4) Doit on détecter la ? Ajouter les mesures de température et de pression. * proto I/5: 5) Programmation d'un driver ascom ! * proto I/6: 6) On passe a l'impression du PCB pour la version manuelle [glow=red]Phase 2:[/glow] L'idée est de transformer la plateforme pour la rendre autonome... C'est encore loin, mais on peut toujours commencer à rêver ! * proto II/1: Pour cela il va falloir revoir totalement alimentation ! II/1a) Mettre en place un timer basse consommation pour le reveil de la bête. J'imagine un truc a base de TPL5110 II/1b) On bascule sur un batterie LIPO en 3,7 et on boost à 5V * Proto II/2: Ce serait bien que le device se recharge avec un petit panneau solaire. cela nécessite aussi un module de recharge avec une protection de la batterie contre les surcharges et la décharge profonde... La j'ai beaucoup de travail (j'y connais vraiment rien !) * Proto II/3: On se lance dans la communication LPWAN histoire de remonter les valeurs de l'objet sur un centralisateur.

Toute à fait. Il y aura un bouton on / off pour la version personnelle du SQM. Cela dit, il ne faut pas oublier ma petite phrase anodine du 9 decembre 2017: "un module communiquant à basse consommation qui pourrait rester dormir dehors..." L'intérêt étant de systématiser la mesure en différents points du territoire ! Je n'en suis pas la, mais dans cette optique, je commence aussi à collecter quelques informations sur les LPWAN ou "Low-Power Wide-Area Network". eg: Lora ou Sigfox.

Bonne année a tous ! Comme annoncé, j'ai étalé le matos sur un table pour ma semaine de vacances. Au départ, pour ce projet, je comptais me baser sur une pale copie chinoise de la plateforme arduino. Le problème de ce truc, c'est qu'il consomme plus de 50mA à vide, en continu et sans rien faire !!! Si c'est valable pour un prototype, cela risque d'être rapidement incompatible avec les futures évolutions de mon projet... Je me suis donc lancé pour quelques recherche sur les modes de veille profondes de l'ATMEGA328PU, et je suis parti from scratch de ce microcontrôleur. Le truc s'alimente en 5V, il m'a donc fallu trouver un composant capable de stabiliser une tension en 5V sans dissiper plein d'énergie en chauffant les oiseaux (exit le LM317 !). Je suis tombé sur ce LDO assez efficace le TC1262 en 5V, Je l'utilise comme base pour l'alimentation du microcontrôleur. TC1262.pdf Pour la plateforme, j'ai sorti le schéma classique de l'arduino sur breadboard et j'ai gravé le bootloader dans le nouveau MCU. A partir de la, j'ai cablé de quoi brancher un FTDI 232 pour pouvoir reprogrammer facilement l'atmega. Du coup, j'ai le schéma suivant: Une fois le mode veille profonde implémenté, j'ai enfin une consommation plus raisonnable de 4,81mA en mode veille. Une simple pression sur un bouton, permets de sortir l'engin de la veille pour effectuer une tâche... Et réveille et à vide, je consomme moins de 20mA (l'amélioration est donc notable) Je vous pose ici, une photo de la plateforme qui avance à nouveau un peu. Et promis je vous parle des mesures du TSL237 et de son compagnon LDR GL55 prochainement...

Ah, voila une remarque qui indique une incompréhension que je dois lever ! Le filtre à infrarouge est prévu pour le TSL237. Evidemment il n'y aura pas de filtre sur le MLX90614 car c'est justement son domaine d'action ! Mais oui, en cas de nuage, la différence devrait être encore plus notable. J'embarque tout le matériel pour un départ en bretagne ce soir. Donc, je vais avoir quelques heures à passer dans le nouveau laboratoire. Au passage, j'ai fait l'acquisition d'une alimentation stabilisé en courant constant Si j'ai le courage je vous ferais quelques screenshoot des courbes à l'oscillo, mais dans un premier temps ce sera sans nuages... Bonnes fêtes à tous

arf, c'est tout le pb de l'electronique par 100x cela vaut 10 centimes, à l'unité c'est 5 euro ! Cependant la photo n'est pas contractuelle. et je n'ai toujours rien reçu. => j'imagine que cela viens à pied par la chine

Au passage j'ai aussi commandé quelques petits filtres ircut à destination du TSL237 pour supprimer les bandes dans l'infrarouge, car les mesures en serait certainement faussées... Filtre ircut En bref, j'avance.

Bon, dans les reflexions du jour. Pour pouvoir faire des mesures si l'appareil est censé rester dehors, il va falloir aussi détecter si il y a de la couverture nuageuse. En règle générale les capteurs utilisés pour ce genre de détection fonctionnent avec une mesure de la température du ciel au zenith en infrarouge et compare ce résultat à la température ambiante. Le gradient de température au zenith étant beaucoup plus important lorsque le ciel est clair de tout nuage. (c'est aussi ce qui explique que la buée se forme plus facilement sur les optiques lorsque les instruments pointent au zenith) On a dans la famille des MLX90614 ce qui est utile dans le domaine. Le truc triste c'est que plus la FOV est étroite et plus le capteur est cher ! En bref, c'est un peu plus de 20 euros pour un composant à 4 pattes je parle de la version ACC ! Voici la datasheet MLX90614-Datasheet.pdf Bref c'est en commande pour un 5V en ACC

je voulais dire capteur couleur... J'imagine bien qu'il n'y a pas que 30 sec de petits photons

très très beau pour un one shot Décidément le A7S a de la ressource.

Effectivement fredo. J'avais clairement posé la question de savoir si nous avions de quoi mesurer l'épaisseur du ciel Et comme personne ne dispose d'un unihedron dans notre entourage je me suis lancé dans cette réflexion/construction. Dans un premier temps, le prototype serait pour valider un fonctionnement en nomade. Je sais qu'Il existe déjà des modèles en DIY, mais j'ai un truc derrière la tête; et je voudrais essayer de baisser au maximum le coût de fabrication. Car j'ai dans l'idée un module communiquant à basse consommation qui pourrait rester dormir dehors... J'ai donc commencer à chasser le milliampères dans mes soirées Stay tuned !

Hello there, Juste pour information, a propos de notre discussion sur le SQM Unihedron... J'ai reçu hier ma commande du composant principal. En attendant, toute mise en oeuvre je vous mets une photo sous la loupe du composant en package surface mount car c'est rikiki J'en ai pris 5 ! Pour les plus curieux, j'ajoute la datasheet en attachement. TSL237 Datasheet Je sais que cela va vous laisser sur votre faim, mais je ne pouvais pas attendre de partager cela avec vous ! Je vous en dis plus, dès que l'oscilloscope me raconte des choses plus intéressantes. A bientôt HoxCa TSL237_Datasheet.pdf