Discret68

J'ai lu le post, mais pas forcément l'intégralité des commentaires. C'est d'ailleurs par rapport à ce que tu as écrit en début de discussion que je pose ma question car à ce moment, tu faisais bien référence au HOO sur une base caméra couleur, mais pas sur du SHO. En relisant le poste depuis la fin vers le début, j'ai effectivement trouvé ta réponse en début de page 8 sur la construction du SHO 👍 OK, je ferai attention. Et par rapport à l'autre voie qui est de pré-traiter séparément les 2 séries d'images faites avec les filtres correspondant et en faisant une extraction RVB sur chaque pour composer les différentes couches SHO, qu'en penses tu ? Cette solution me paraissant optimale (à priori) pour utiliser la totalité des pixels disponibles .

Suite à divers questionnements d'astrams désirant motoriser le toit de leur abri, j'avais mis ces explications justement pour expliquer comment dimensionner une motorisation pour toit roulant. Entre ceux qui veulent installer un moteur de 3kw et ceux qui pensent qu'un moteur de jouet peut aller, il est bon à mon sens, d'apporter une méthode simple qui peut éviter les déconvenues 😚

Pour la bonne et simple raison que ça ne faisait pas partie de la question posée. De plus, Gérard ayant fait clairement le choix du moteur à utiliser et de son mode de pilotage, inutile de revenir sur la détermination de la motorisation puisque c'est acté. Et comme toutes les questions que j'ai posé n'ont amené aucune réponse, inutile pour moi de poursuivre sur ce sujet pour lequel effectivement, je n'ai absolument pas répondu à la question initiale.

Tu aurais pu mettre directement le lien pour la méthode que j'avais présenté : http://astrowick.fr/index.php/observatoire/motorisation-toit 😜 Il faut juste un renvoi supplémentaire par rapport à la rotation de la coupole.

Bon, Gérard, tu peux constater qu'on a bossé sur ton sujet avec Ney 😎

L’encodeur absolu, c’est bien car il n’y a pas d’équivoque pour la position dans laquelle il se trouve. la problématique se situe au niveau de son positionnement dans la coupole. Cette dernière ne dispose pas d’un axe central comme une monture. On ne peut pas fixer l’encodeur directement à la coupole. Il faudrait le positionner en périphérie, mais il y a la nécessité de faire une réduction pour obtenir une rotation d’encodeur pour une rotation de coupole. Pas simple. Lorsque je parlais de codeur simple, je pensais à un capteur photoélectrique avec un disque à trous qui permet d’encoyer des impulsions selon la rotation.. Par exemple, ce système mais avec un disque possédant moins de trous : https://fr.aliexpress.com/item/32841368348.html Si on part sur une coupole de 2,50m de diamètre, cela nous fait une périphérie de 7,85m. Vu que le moteur à Gérard a un pignon de 9 dents pour chaine de 1/2 », la chaine qui serait fixer en périphérie de la coupole aurait 785/1,27 soit 618 maillons. Sur la base du pignon de 9 dents, il faut 618/9 soit 69 tours de pignon pour une rotation complète de la coupole. Si on prend un disque avec 6 trous, cela nous donne 414 impulsions pour un tour de coupole soit une résolution de 0,87° par pas. La Terre faisant 1° toutes les 4 mn, il faut faire tourner le moteur de 1/6 de tour toute les 4 minutes. Vu que la vitesse de rotation est de 309tr/mn soit 5,15 tours par seconde à la tension nominale, il faut le faire tourner pendant 1/5,15/6 soit 0,03 secondes. Impossible avec un moteur tournant à cette vitesse, sachant qu’il faut attendre l’impulsion pour arrêter le moteur. A minima, il faut faire chuter la vitesse de rotation pour pouvoir disposer d’un minimum de temps pour faire tourner le moteur et gérer son arrêt. Je ne sais pas jusqu’à combien on peut descendre en vitesse de rotation en diminuant la tension d’alimentation. Avec une alimentation en PWM, il se pourrait qu’on puisse descendre assez bas. Mais est-ce que ça sera suffisant, je n’en sais rien. J’aurais donc tendance à dire que ce moteur n’est pas vraiment adapté pour la coupole.

Pétard !!!! Je sais le faire sur un ordi via les drivers ASCOM, mais si Gérard veut un système autonome avec l'arduino, c'est râpé ! je ne le pense pas car même si on envoie des impulsions via un pont en H au moteur, on ne maitrise pas la vitesse. Le moteur peut tourner trop ou pas assez vite, et au bout d'un moment, Gérard risque de faire des darks 🤕. Ce n'est pas la même chose (plus facile) que d'envoyer des impulsions sur un moteur pas à pas. En tout cas, moi je ne sais pas comment faire. Je réfléchis à voix haute car une autre solution existe et est totalement autonome. Je m'appuie sur le fonctionnement de la motorisation des fourches MEADE (j'ai un RCX400 10"). Sur les 2 axes, c'est un moteur à courant continu qui est utilisé (eh oui !). A priori, ce n'est pas précis du tout ! Sauf qu'en bout de chaque moteur, il y a un codeur qui permet de mesurer précisément l'angle de rotation. L'alimentation du moteur est régulée en fonction de l'analyse des impulsions venant du codeur. Donc, pour la coupole, on peut imaginer un codeur simple (et pas cher, placé au niveau du pignon du réducteur) qui permet d'envoyer des impulsions sur une entrée de l'arduino ou un encodeur qui permet par exemple de définir 16 positions pour un tour de pignon. En fonction du comptage des impulsions ou de la mesure de position angulaire du pignon, on peut calculer la position de la coupole par rapport à une position park et réguler la vitesse du moteur ou l'angle de rotation en mode suivi. Il faut bien sûr connaitre la réduction du système de transmission complet pour étalonner la boucle d'asservissement.

Ca peut ne pas être nécessaire. Si le cimier a une ouverture suffisamment large, la coupole peut opérer une rotation d’un angle donné tous les X temps qui dépend de la différence de largeur du cimier par rapport au diamètre du télescope. Cette solution permet d’éviter l’asservissement direct en vitesse de la coupole. Quelque soit la solution retenue, il faut arriver à synchroniser (en permanence ou périodiquement) la rotation de la coupole. C’est un peu le problème avec un moteur à courant continu dont on ne maîtrise pas avec précision la vitesse de rotation. Récupérer les coordonnées de pointage de la monture.n’est pas trop difficile, puis une conversion des coordonnées en altaz pour récupérer l’azimut, c’est facile. Le problème à mon sens est de récupérer la valeur de l’azimut du cimier pour synchroniser le tout. Bref, j’aurais plutôt tendance à proposer une motorisation à base de moteur pas à pas avec une transmission ad’hoc et un driver qui peut cette fois ci se piloter avec précision par un arduino. Et là, oui, rotation continue. Question complémentaire pour Gérard : Souhaites tu que l'arduino soit totalement autonome pour piloter la coupole ou peut-on ( ou doit on) imaginer que l'arduino est lui même piloté par un programme sur ordi ?

Salut Gérard. Hormis la mise en route et l’arrêt du moteur, veux tu également pouvoir modifier la vitesse par l’Arduino ? Dit d’une autre façon, admettrais tu de régler la vitesse par potentiomètre et enclencher/arrêter le moteur et son sens de rotation par Arduino ? En regardant les caractéristiques du moteur, si j’ai bien compris, la vitesse de rotation du moteur en sortie de réducteur est de 309 tr/mn (3000/9,7). C’est bien cela ? Quel est le diamètre de la coupole ? Concernant la variation de vitesse, quelle plage souhaites tu ( min et Max) pour le moteur ou pour la coupole ? Vu que c’est un pignon pour chaîne en sortie de moteur, une chaîne est fixée sur la coupole ? Ou alors, il va y avoir un autre système de transmission ?

Tu as raison, mais je voulais y aller par petites étapes 😃 Ça rentre dans ce que j'appelais vignettage mécanique en début de discussion, sachant qu'une bague M42 fait 37 ou 38mm de diamètre intérieur, on "mesure" bien l'impact de ce diamètre par rapport à la diagonale du capteur FF. Les flats dont je présentais l'analyse CCDi avaient été réalisés avec des bagues M48 (diamètre intérieur 43mm). Le vignettage mécanique est de fait un peu réduit, mais quand même présent. Mais à la base, c'est surtout la physionomie de la perte de lumière sur les bords longs du capteur qui m'interpelle, d'autant que ce n'est probablement pas dû au montage des bagues car on pourrait visualiser ce problème d'une manière concentrique sur le flat.

Ah oui !! Bon, de loin, c'était vraiment dur de voir ce que c'est. Pour tes flats, l'analyse CCDi montre la même courbe que précédemment : Il y a toujours les bords longs qui ont un drôle d'aspect. Je te propose un nouveau petit test complémentaire. Tu prends ton boitier seul (sans accessoire monté, pas de bague T ni le reste). Tu prends une photo d'une zone blanche (feuille de papier, plafond, ...) en ne saturant pas l'image. Comme ça, on pourra voir si cette problématique est du coté APN ou coté accessoires astro.

La difficulté à mon sens est que le collage tienne dans le temps. Avec les variations de température et d'hygrométrie, pratiquement tout ce que je colle .... finit par se décoller avec le temps. Je fais surtout allusion aux pattes de fixation avec adhésif pour y fixer les câbles. Quel que soit le modèle et la provenance, ça finit par se décoller rapidement. Au début je passais chaque fil sur le chant d'une branche d'araignée et je l'avais fixé par une bande de scotch noir sur toute la longueur de chaque branche et ça tenait pas mal. 2 branches sont finalement équipées. Pour les profilés en H (noir ou blanc), on en trouve dans certains magasin de bricolage. Des modèles de plus petites sections sont utilisés en modélisme sous la marque Evergreen. La solution à retenir peut aussi dépendre de l'épaisseur des branches d'araignée.

Bonjour à tous Je me pose quelques questions concernant le fonctionnement des scripts « Couleur_Extraction_Ha » et « Couleur_Extraction_HaOIII » dans Siril. Ces 2 scripts sont notamment utilisés pour la construction d’images HOO à partir d’une image couleur. Avant de poser mes questions, voici ce que j’ai compris du fonctionnement de ces scripts, ce qui a tendance à confirmer ce que je pensais notamment de l’extraction de couches sur des images prises avec des filtres multibandes. Dans ces 2 scripts, il y a une phase de pré-traitement des brutes que je laisse volontairement de coté pour ne m’intéresser qu’à la phase primordiale ; l’extraction proprement dite des couches Ha et de l’OIII. Ces 2 scripts font appel aux commandes globales « seqextract_Ha pp_brute » et « seqextract_HaOIII pp_brute ». En consultant la documentation Siril, ces 2 commandes s’appuient sur les commandes « extract_Ha » et « extract HAOIII » A la lecture de leur définition et sur la base du positionnement de ces 2 gaz sur le spectre des couleurs , je comprend que l’extraction s’effectue sur la base du pixel rouge de la matrice de bayer pour le Ha et sur une extraction des 3 autres pixels (le bleu + les 2 verts) pour l’OIII. Pour cette dernière extraction, une moyenne des 3 couleurs est effectuée. Je ne vois effectivement aucun autre moyen informatique permettant de discriminer les couleurs en fonction de la longueur d’onde des différents gaz. Ces 2 scripts fonctionnent bien sur la base de l’utilisation (par exemple) de filtres IDAS NB1 et NB2. Si on souhaite réaliser des images HOO, on peut s’arrêter à cette étape. Jusque là, ais-je une vision correcte des choses ? Par contre, pour construire une image (pseudo) SHO, il faut récupérer la couche du soufre. En complément d’un filtre NB1, j’ai monté un NB3 dans ma RAF. Ce filtre permet d’extraire le OIII et le SII. Vu que la longueur d’onde du SII est très proche de celle du Ha, j’en déduis que l’utilisation du script « Couleur_Extraction_HaOIII » peut s’appliquer au NB3 pour en extraire l’OIII et le SII. En fait, ce script pourrait également se nommer « Couleur_Extraction_SIIOIII » pour un filtre NB3. Les 3 gaz étant séparés, il devient manifestement possible de créer une image SHO. Dans une deuxième réflexion, je me dis que si les scripts font de l’extraction de couleurs RVB, pourquoi ne pas partir d’images pré-traitées sur la base respective des filtres NB1 et NB3 pour faire une extraction RVB sur chaque image. J’associe ensuite les différentes couches des 2 filtres en fonction de la longueur d’onde des gaz pour obtenir les 3 couches qui vont être affectées aux RVB pour obtenir du SHO. Bien évidement, il faut ré-aligner les différentes couches en provenance des différents filtres et ajuster les niveaux. L’avantage à première vue de cette méthode est de récupérer la totalité des pixels des images des 2 filtres : le Ha provient des pixels rouges du NB1, le OIII des pixels verts et bleus des NB1 et NB3 et le SII des pixels rouge du NB3. Est-ce que ce scénario tient la route ? Il y a peut-être des effets « pervers » auxquels je ne pense pas. Merci à vous JP

Chez moi non plus, je ne vois pas de trame sur l'image téléchargée de 139Mo et j'ai balayé l'image complète à l'échelle 1. C'est vrai qu'en grand, cette image est superbe ! Il y a plein de "petites" choses à découvrir. Ce doit être la conversion en JPG qui met le brin !

Une solution que j’ai adopté sur mon newton est d’isoler électriquement 2 branches d’araignée afin d’y faire passer la tension d’alimentation de la résistance chauffante du secondaire. De cette façon, aucun câble ne passe dans le champs. Autre solution, utiliser 2 conducteurs simples (fil isolé) de faible diamètre, car l’intensité qui passe est faible, qu’on maintient au niveau d’une branche d’araignée à l’aide d’un profilé en plastique en forme de H. On trouve ces profilés dans certains magasins de bricolage. On coupe le profilé à la longueur de la branche d'araignée, on l’encastre sur la branche d’araignée et on passe les 2 fils dans la 2ème gorge. Pour la section des fils, si on part sur une résistance de 5W sous 12V, ça fait une intensité de moins de 0,5A. Une section de fil de 0,2mm2 est suffisante. Rien n’empêche de prendre un peu plus gros pour que ça serre dans la gorge pour assurer le maintien des fils.

L’image est belle avec un bon rendu des couleurs, mais il y a une trame verticale qui est légère mais visible, notamment au niveau des zones lumineuses.

Dans cette guerre de religion qui n’en est pas une, si vous aviez testé Astro Pixel Processor, vous ne seriez pas en train de vous « déchirer » entre Siril et PI pour le pré traitement Surtout pour l’extraction du gradient que je trouve le plus performant des 3 logiciels. Bon, aller, soyez rassuré, j’utilise aussi Siril et PI 👍

@julienESP n'étant pas moi-même un cador dans le traitement des images, je vais en profiter pour tester tes "directives" sur mes images 🤕

Merci de nous prévenir, j'ai réactivé l'antivirus sur mon ordi, des fois que tes messages soient contaminés 😃 Perso, je pense que c'est suffisant. Entre 1/2 et 3/4, ça va le faire ! On peut penser que ton miroir secondaire n'est pas correctement centré par rapport au PO. Il y a en fait 2 centres à prendre en compte au niveau du miroir secondaire. Le centre géométrique, qui correspond au centre mesuré du grand axe et du petit axe du miroir et il y a le centre optique, qui est décalé par rapport au centre géométrique d'une cote qui dépend du rapport f/d du télescope : http://serge.bertorello.free.fr/calculs/posplan.html Dans ton cas, il doit être de 5mm. Si le secondaire n'est pas optiquement correctement centré, tu peux avoir un décalage de la plage de luminosité des flats .... et des brutes ! Un défaut de collimation ou une présence de tilt peuvent également générer un défaut de centrage de la plage de lumière. Ce qui me gêne plus sur l'image de l'analyse CCDi, c'est la forme du vignettage sur les bords longs du capteur. La courbe de luminosité est complètement perturbée et perd sa concentricité. Je ne vois pas d'où cela peut provenir, d'autant que tu n'as pas de filtre. Ça pourrait être le cas avec un filtre "clippé" dans le boitier de l'APN, mais tu n'as pas de filtre ! Et on retrouve bien cet assombrissement sur tes brutes. Vu que cette zone est bien parallèle au bord du capteur, je pense que c'est au niveau du boitier qu'il faut chercher le coupable. Par acquis de conscience, tu pourrais tourner ton APN d'un angle quelconque (sauf 180° !) pour voir si ce défaut évolue. Mais vu "l'excellence" du parallélisme actuel, ça serait vraiment étonnant que ça bouge. Sur la photo de ton tube (un peu petite pour voir précisément le montage), je vois quelque chose de cylindrique juste en dessous de l'APN. Qu'est ce ? Pourrais tu mettre une photo du train optique (du PO à l'APN) assez grande de manière à bien voir le montage ? En tout cas, ton image de M31 a quand même gagné en qualité 👍

Pour compléter le choix plus adapté d'un capteur de plus petit format (APS-C pour une 2600), voici une comparaison du vignettage entre capteur FF et APS-C derrière un correcteur 2" : Pour le capteur FF, la perte de luminosité est de 68% dans les angles, valeur très proche de celle qu'on mesure sur tes flats réels. Par contre, pour le capteur APS-C, la perte tombe à 18%. Valeur beaucoup plus facile à corriger. Le cercle pleine lumière (dans une configuration correcteur 2") est de 22mm (2 x fois l'offset - la distance par rapport au centre du capteur). Mais avec la taille du capteur FF, la pente est longue et rude ! Soit dit en passant, cet exemple n'a pas pour but de te faire acheter un autre capteur, mais juste pour te montrer à quel point, un capteur FF n'est pas évident à gérer sur un newton avec correcteur 2". Comme joker0247, j'avais monté l'A7S, mais sur mon newton avec correcteur 2", c'était pareil qu'avec l'ASI2400 d'aujourd'hui, un bon 50% de perte dans les angles. Pour cette raison, j'ai passé toute la partie train optique en 3", ça va beaucoup mieux. Mais dans ton cas, ce n'est surement pas la bonne solution car cela te couterait beaucoup plus cher que le télescope lui-même.

J'ai fait une petite analyse de tes flats. Comme ont constaté les copains, tes flats sont sous exposés. Avec PI, je trouve une moyenne à environ 11000 ADU alors que tu devrais être dans les 40-45000 ADU. J'ai également passé un de tes flats à l moulinette CCD Inspector pour visualiser le vignettage : Tu montes à un bon 60% de perte de lumière dans les 4 angles 😫 En regardant tes flats en taille "normale", je les trouve très propres. Contrairement à certains qui rangent leur APN dans le sac de leur aspirateur, je n'ai pas mis en évidence de poussière sur tes flats, ce qui est une très bonne chose. Sachant que les flats ont pour objectif de prendre en compte le vignettage et la présence de poussières (c'est pour cette dernière raison qu'on dit qu'il faut faire les flats en fin de séance, avant démontage), mais dans ton cas, vu l'absence de poussière, tu peux tranquillement remonter ton APN sur le télescope et refaire une série de flats aux bonnes valeurs d'ADU. Dans tous les cas, je pense que refaire les flats ne peut qu'aller dans le bon sens.

Tu n’es certes pas le seul à monter un capteur FF sans en appréhender à priori les problèmes induits. Il y a déjà eu malgré tout des discussions sur cette problématique mais effectivement pas identifiée comme étant la cause d’un problème rencontré. Déjà, tu as un choix, mais passer en 3 pouces nécessite de changer beaucoup de pièces sur ton télescope ; miroir secondaire, porte-oculaire, correcteur. Il est plus pertinent de cropper partiellement tes images. Une autre solution à réfléchir, c’est de prendre une caméra astro avec un capteur de taille adaptée. Une ASI2600MC ou 533MC. Le refroidisseur intégré te facilitera également la gestion des darks et bias.

Il se peut que je trompe, mais il me semble que contrairement aux darks et aux bias, la valeur iso peut être différente pour les flats. L’objectif étant de déterminer une « courbe » de variation de luminosité pour corriger les images, vu le niveau ADU attendu des flats, le bruit au niveau du signal du capteur est négligeable.

A titre de comparaison, à l'aide du logiciel Vignettage, voila l'impact d'un correcteur 3" sur mon newton de 300 f/d4 avec un capteur plein format (ASI2400MC). La perte de luminosité calculée est de 18% dans les angles : J'ai vérifié mes flats à l'aide de CCD Inspector, le vignettage mesuré est encore plus important 🤔 Toujours avec vignettage, en mettant un correcteur 2", la perte de luminosité atteint 50% dans les angles : C'est juste pour montrer que capteur FF et correcteur 2" ne font pas forcément très bon ménage 🤕 Mais au fond, rien n'empêche de faire des images avec.

Pour info, j’ai commandé une Neptune-C II directement chez Player One le 21, elle arrivée ce matin, soit 5 jours de délais. Pas de soucis !