keymlinux

Bien vu, je suis un boulet...., c'est corrigé 😅

Bonjour, Histoire de faire dans l'originalité, je viens ici vous montrer ma dernière capture, la Nébuleuse de la Rosette, effectuée dans la nuit du 11 au 12 janvier (première véritable opportunité météo depuis plus d'un mois en région parisienne...) Cette soirée fut l'occasion d'utiliser pour la première fois une camera astro refroidie, en remplacement de mon APN non défiltré, et de passer d'un guidage avec lunette guide à l'utilisation d'un diviseur optique. Oui beaucoup de changement, avec le risque de rencontrer des problèmes et de gaspiller une si rare opportunité météo... Conditions: : ciel sans nuages, température ambiante -3°, au sud de l'Ile de France Détail du matériel: - télescope: SW Equinox 80/500 - réducteur: TRF-2008 x0.8 - camera: Player One Poseidon-C - monture: SW AZ-EQ6 - guidage: OAG + ASI290mm - filtre: UV/IR cut Baader Capture via Kstars/Ekos/Indi sur Raspberry (Nafabox) Traitement: Siril et Gimp Les images: - Lights: 120x120s gain 125 offset 25 temp -10°C - DOF: 50/50/30 Les problèmes rencontrés, à résoudre pour la prochaine fois.. - j'ai mal réglé le diviseur optique, le prisme empiétait un peu sur le capteur, l'ombre générée à bien été traitée par les flats, mais je pense que c'est aussi la source des aigrettes verticales bizarres sur certains étoiles (j'utilise une lunette, donc il ne devrait pas y avoir d'aigrettes) - le backfocus de mon réducteur correcteur n'est pas bon, donc étoiles déformées dans les coins (je dois ajoute run filtre UV/IR cut avec cette camera, et je n'en ai pas tenu compte pour la distance correcteur/capteur - les 120 prises de vues ont été séparées en 4 lots de 30 images (je vérifie la MAP avant chaque lot), 2 lots fait avant le passage au méridien, 2 lots après le passage au mérifdien: pour le 3eme lot, juste après le retournement du méridien, impossible de passer l'étape de calibration du guidage. Au final 90 images prises avec guidage, 30 sans guidage Selon la formule consacrée, vos avis et critiques sont les bienvenus Image réduite à 6000x4000 pixels et compression jpeg pour poster sur le forum Pour les détails du traitement: Stack des Lights avec DOFs, et option drizzle Post-traitement Siril: - Extraction du gradient (Correction : Subtraction) - Photométrie - Transformation asinh : (stretch= 250.0, bp=0.00020) - GHS pivot : 0.010, montant : 19.12, local : 0.00 [0.00 0.60] - GHS LINEAR BP : 0.02 - GHS pivot : 0.244, montant : 7.98, local : -0.83 [0.01 0.50] - SCNR (type=neutre moyen, qté=1.00, préserve=true) - Rehaussement de la saturation (quantité=0.20) Post-traitement Gimp + plugin PyGapM27 - Make Dark Sky (iteration 3, opacité 15) EDIT: version avec réduction d'étoile Réflexion faite, je trouve que mon image a des étoiles trop prononcées. La camera est plus sensible que l'APN que j'utilisais jusqu'a présent, au lieu de poses de 120secondes j'aurai du me limiter à des poses de 60secondes. Je me suis donc lancé dans une réduction d'étoile, une première ici aussi. En terme de post-traitement Siril: - Extraction du gradient - Photométrie - Traitement étoiles: dé-saturation - Traitement étoiles: suppression des étoiles starnet - Réduction du bruit sur le fond de ciel "starless" - Traitement étoiles: recomposition avec étirement séparé starless/starmask - Retrait du bruit vert Cordialement, Stéphane

Au lieu de cibler NGC2237 il faut cibler NGC2244 qui est l'amas ouvert dans la Rosette, là ton cadrage sera OK J'ai fait la même cible dans la soirée du 11/01 et j'ai eu le même problème de décentrage du cadrage, bien que n'utilisant pas le même matos que toi (Player One POSEIDON-C à capteur pus grand et rectangulaire, et astrométrie via Kstars/Ekos/Indi sur un raspberry). En ciblant NGC2237 j'avais un décentrage, avec NGC2244 c'était OK Ci dessous le cadrage dur NGC2237 (ou sur NGC2238 cadrage identique), elle est "décentré", et ton image et la mienne ont le même "centre", une zone de poussière faisant des filament noirs En cadrant sur NGC2244 (cadrage identique en visant NGC 2239) là j'obtiens le cadrage voulu nb: ces images sont des brutes avec une preview "histogramme" sous Siril, la zone sombre en bas c'est l'ombre du diviseur optique qui était réglé un peu bas (à corriger pour les prochaines fois...) Cordialement, Stéphane

Bonjour, La distribution Astroberry est actuellement disponible seulement en 32bits, donc cela te bloque sur la dernière version de Kstars/Ekos/Indi 32bits et t'empêcherais d'utiliser les dernières evolutions du logiciel Kstars (dont les dernières versions ne sont disponibles qu'en 64bits) Il est fort probable que la distribution Astroberry 32bits ne démarrera pas sur un PI5, le support du PI5 ne sera intégré qu'au distributions linux récentes (et donc en 64bits) Et le plus important: l'architecture 64bits c'est surtout ce qui permet de ne pas se limiter à 4GB de mémoire mais de pouvoir utiliser efficacement 8GB La question ne se posera pas en ces termes, tu ne pourra pas démarrer une distribution 32bits Astroberry sur un PI5... Par contre sur la question de fond qui est de savoir si un PI4 est suffisant pour notre usage ou si un PI5 est nécessaire ou au contraire surdimmensionné: - en usage capture ciel profond, un pi 4 est suffisant (j'utilise un pi4 pour faire de la capture ciel profond, avec guidage et astrométrie, pas de problème d'usage cpu constaté sur un PI4) - si on veut faire de la capture planétaire, un PI5 permettrait de monter le nombre de fps nécessaire à la capture planétaire en video (pour info firecapture existe en version compilé pour raspberry 64bits) - si on veut utiliser le raspberry pour faire le traitement (siril/gimp) alors le passage au PI5 s'impose, même si il faut garder à l'esprit que cela restera lent, ce qui fera la différence cela sera surtout d'avoir 8GB de mémoire et pas seulement 4GB (le 8GB de mémoire est aussi disponible sur PI4), mais ce qui est important c'est de ne pas stocker les photos sur la carte SD mais d'utiliser un disque externe SSD (et le mieux c'est d'avoir l'OS aussi sur un SSD externe) Concernant l'acquisition d'une photo de l'APN, il faut effectivement près d'une dizaine de secondes (en plus du temps de pose) pour obtenir l'image, mais le point limitant ici c'est le port USB2 de l'APN qui limite le débit (en tout cas c'est le facteur limitant que je constate avec mon APN Canon 80D, mon raspberry PI4 utilisant un disque SSD en USB3 ce n'est pas l'écriture sur disque qui limite). Ceux qui ont une camera astro équipée d'un port USB3 (ce qui est courant) ou un APN avec un port USB3 (ce qui est rare) n'ont pas ce problème Cordialement

Bonjour, Pour une longue vue "terrestre" où l'on souhaite redresser l'image, on peut le faire avec un prisme (en fait plusieurs) comme dans les jumelles à prisme, mais on peut aussi intercaler une lentille entre l'objectif et l'oculaire. Voir le site de Serge Bertorello (ne pas hésiter à parcourir les autres pages du site, c'est une mine d'information) http://serge.bertorello.free.fr/optique/instrum/longuevue.html Cordialement

Bonjour, Quelques formules utiles... soit D, le diamètre du télescope, ici 200mm soit F, la distance focale du télescope, ici 1200mm soit f (en minuscule), la distance focale de l'oculaire (tu as déjà un 25mm et un 10mm) le rapport F/D, 6 pour ton telescope. C'est surtout utile de le connaitre pour l'astrophoto, mais même en visuel, cela implique: - plus de rapport F/D est petit, plus la mise au point est sensible (la zone de netteté est réduite) - plus le rapport F/D est petit, plus l'image sera déformée sur les bords (coma), et plus il faudra des oculaires de qualité Le grossissement c'est F/f - donc G = 48x pour l'oculaire de 25mm avec ton télescope - et G = 120x pour l'oculaire de 10mm et ton télescope Pour calculer le champ de vision réel, on divise le champ apparent par le grossissement Pour les oculaire de 25 et 10mm le champ apparent est inconnu (probablement 52° ou 68° cela dépend de leur formule optique) Pour la gamme d'oculaire ES 82° et bien c'est 82° - avec l'oculaire de 8mm préconisé par @22Ney44, grossissement de 150x donc champ réel de 82/150= 0.54° - avec l'oculaire de 8mm + barlow, grossissement de 300x, donc champ de vision de 82/300 = 0.27° Pour info, la taille apparente de la lune est de 0.5° environ Avec une barlow x2 tu double le grossissement, donc tu divise par 2 le champ couvert, c'est pas plus compliqué edit: grillé par @Le Gnou qui a été plus rapide à répondre...😉 Cordialement

Bonjour, Je viens de poster dans les clubs "L'impression 3D en astronomie" et "Astronomie avec Arduino" les éléments nécessaires à la réalisation d'une roue a filtres imprimée en 3D, manuelle ou motorisée Chapitre 1: Les photos du bricolage Voici des photos de la version RF-42 5x1.25 pouces avec motorisation que j'utilise régulièrement (pilotée via Kstars/Ekos/Indi,la roue implémente le protocole des roues Quantum) En version manuelle, avec une petite trappe pour accéder à la roue et la faire tourner Le support moteur En version motorisée, la trappe est remplacée par le support moteur En version motorisée avec le boitier d contrôle (1 port 12V DC pour l'alimentation du moteur, un port USB micro pour le pilotage série) Une vue des différents éléments avant montage de la roue Une vue des elements de la motorisation Chapitre 2: Les modèles 3D Il y a 2 modèles, avec 3 déclinaison en tout 1) Le petit modèle, une seule déclinaison pour 5 filtres 1.25 pouces Le boitier dispose de filetages M42x0.75 m sur chaque face 2) Le grand modèle, avec 2 déclinaisons, soit pour 5 filtre d e3 pouces, soit pour 8 filtres de 1.25 pouces Le boitier dispose de filetages M54x0.75 M sur chaque face Les fichiers pour l'impression 3D des roues ) filtres sont disponibles ici Chacun des 2 modèles peut être actionné manuellement, ou doté d'une motorisation Pour l'impression en 3D des supports moteurs et du boitier de contrôle, c'est ici EDIT: ajout des fichiers STL pour les têtes de vis et boulons, pour manipuler les vis sans outils Tete vis et boulons.zip Important: les têtes de vis sont une création originale de Xavier DUPONT pour le projet SOLEX, les têtes de boulons sont une adaptation personnelle des têtes de vis. Chapitre 3: Motorisation, code de programmation et interface de pilotage Pour la motorisation vous aurez besoin d'un microcontroleur ESP8266 ou ESP32, d'un moteur 28BYJ-48 et de son stepper UNL2003 (le tout devrais vous couter moins de 20 euros). Le code est fourni ici (mis à jour version 1.1.1 le 19/10/2021) La roue est pilotable via le port USB du contrôleur, elle implémenta par défaut le protocole des roues à filtres Quantum --> a ce titre la roue a filtres est pilotable via Kstars/Ekos/Indi en utilisant ce driver INDI Avec un microcontroleur ESP8266 ou ESP32 (en lieu et place d'un Arduino tout simple), la roue a filtre généralement!re son propre réseau Wifi (comme une borne) SSID réseau: : mls-rf password: azerty adresse IP de la roue: 10.42.0.1 joignable en interface web: http://10.42.0.1 En parallèle du mode "borne" la roue peut aussi se connecter à un réseau wifi existant, vous pouvez modifier dans le code les éléments "reseau1", "password1", "reseau2" et "password2", la roue a filtre se connectera à l'un de ces 2 réseaux, au premier qui accepte la connexion, testés dans l'ordre... Voici quelques copies d'écran du pilotage en mode wifi (désolé j'ai l'habitude de programmer en anglais, comme au boulot, même si mon niveau d'anglais est mauvais ...) L'écran principal, on choisi le filtre et on valide (submit), la validation entraine le déclenchement du mouvement pour positionner le filtre choisi (les noms des filtres peut être modifié sur l'écran de config) Ci dessous l'écran de configuration pour nommer les filtres et leur attribuer un décalage (offset), qui sera utilisé par Ekos/Indi pour ajouter la mise au point selon chaque filtre Ci dessous la page de configuration Détail des paramètres: - nombre de filtres: accepte les valeurs de 1 à 9, mais en fait on utilise soit 5 soir 8 filtres - nombre de "pas par minutes" max lors de la rotation du moteur - nombre de "pas par minutes" initial au but de la rotation du moteur - nombre de "pas" pour le facteur d'acceleration (utilisation de la librairie AccelStepper) - nombre de pas pour faire un tour de moteur (habituellement avec un moteur 28BYJ-48 c'est 64) - nombre de dents de l'engrenage sur l'axe moteur (20) - nombre de dents sur le tour de la roue (100 pour le petit modèle, 120 pour le grand modele) Ci dessous la page pour envoyer manuellement des commandes (celles qui sont habituellement envoyées par le port série, pratique pour tester) TRES IMPORTANT: comme la roue a filtre ne dispose pas de mécanisme de "repositionnement automatique", si il y a désynchronisation, avec le roue qui s'arrête sur une position entre 2 filtres, l'ecran de mouvement manuel permet des ajustement en faisant tourner la roue (on choisi le nombre de degrés, en valeur positive ou négative selon le sens que l'on souhaite Et pour finir il y a une page "debug" qui présente les valeurs en cours des différentes variables du firmware Cordialement, Stéphane Edit 19/10/2021: suppression des images en doublon, mise à jour des copies d'écran du pilotage de la roue via son interface web Edit 23/11/2021: modification du schéma de câblage, livraison code microcontroleur v1.2.0 VERSION1.3 du 06/11/2023 Edit 06/11/2023: ajout d'une nouvelle pièce 3D "support haut hall" permettant d'ajouter un capteur a effet haut et livraison code microcontroleur v1.3.0 qui l'exploite Motifs sur le code: - Refonte graphique pour le site web embarqué et ajout d'un mode "nuit" (rouge/noir) - Ajout pilotage via driver Bluetooth Serie (testé OK sur Ekos/Indi) - Ajout pilotage via driver network (tcp port 1234)(testé OK sur Ekos/Indi) - Ajout capteur Hall + recherche automatique de la position du filtre 1 IMPORTANT: si vous avez déjà imprimé la version précédente de la roue et du support moteur vous n'avez pas besoin de tout réimprimer, vous devez seulement imprimer la pièce "support haut hall" (et éventuellement le "capot hall" pour protéger le capteur) Quelques images: Le support du capteur Hall (piece seule, et pièce installée sur la roue avec le capteur) Le support avec le capteur et son capot de protection Le type de capteur est un AZDelivery KF-035 (environ 7 euros les 3 capteurs sur la Zone....) Important: ce capteur dispose d'une LED qui éclaire en rouge, il est important de la masquer pour ne pas produire de lumière indésirable dans la roue à filtre ! Avec un contrôleur ESP8266 ou un ESP32 la roue peut être connectée en Wifi et pilotée via un site HTTP intégré La version 1.3.0 entraine une refonte graphique du site embarqué, voici quelques captures d'écran (le theme Dark est par défaut, mais on peut permuter avec le thème Light à la volée): Le nouveau plan de câblage avec le capteur Hall (dans le code on considère qu'il est connecté sur le port GPIO16, mais c'est configurable) Cordialement, Stéphane