DBlatte

Bonjour à tous, Je cherche une solution pour automatiser un rattrapage de la mise au point qui se dégrade en cours de nuit (sur une lunette). Cette mise au point est motorisée avec un système maison qui me rend de bons services, mais pendant la nuit, ça bouge (température et/ou décalage mécanique du PO à mesure que l'instrument change d'orientation). J'ai commencé à écrire un programme pour analyser les images prises et en déduire des corrections, mais je bloque sur la "stratégie" de mise au point. Je me demande donc comment fonctionnent les systèmes du marché : - On fait une mise au point après chaque changement de filtre et ensuite on ne corrige qu'en fonction de la température ? - On fait une pause de 3 minutes toutes les n heures pour réajuster ? Ou alors seulement quand on détecte que les images se dégradent ? - Ou bien offrent-ils la possibilité de corriger au fil de l'eau par ajustements très légers ? (mais ça me semble compliqué de faire la mise au point sans interrompre la séquence de prise de vue principale). - ... ? Merci d'avance pour les éléments que vous pourrez me fournir. Ma configuration est la suivante : - lunette taka FC-100DF, - caméra ASI183MM + roue à filtre, - guidage par PHD2, - prise de vue avec Sharpcap 4 (vive le séquenceur !)(vive le plate solving ça change la vie). Christophe

En effet en regardant mieux sur la raquette, je vois que l'on peut afficher les versions de firmware et il y a séparément la version du firmware du Hand Controler lui-même et la version pour la partie Moteur. En allant sur le site de skywatcher je vois que la partie mateur n'a pas bougé depuis plusieurs années pour ma monture (AZ-EQ5). Merci pour les infos et bonne soirée (je n'ose pas dire bon ciel vu cette !!! de météo).

Bonjour, Je me pose cette question : lors d'une mise à jour de firmware, est-ce seulement le code de la raquette qui est mis à jour, ou bien également celui des cartes qui sont intégrées à la monture ? Merci d'avance, Christophe

Mon post ! Un peu de respect svp C'est le hasard qu'il remonte ce post, et que je le voie passer. J'en profite pour mettre à jour : après 3 ans passés ensemble, je trouve que cette AZ-EQ5 au final marche assez bien. En bricolant la tension de la courroie j'ai fini par trouver un réglage qui adoucit un peu. Ca plus un apprentissage du paramétrage de PHD2, et en général le résultat est correct et plutôt fiable fiable.

Merci pour vos réponses ! J'avais fait un test en ajoutant un contrepoids de 3.5kg sur un des instruments dont je dispose déjà, ça marchait bien, mais le poids restait très centré, pas représentatif d'un Newton je pense. Le MakNewt est long aussi et lourd, ça ne sera pas plus facile. Je vais réflêchir encore un peu mais probablement ce sera un 150/750, ça marchera très bien et dans la durée je verrai s'il semble que la monture peut tenir davantage. Encore merci, ce genre de choix cornéliens, à y réfléchir tout seul on tourne vite en rond.

Bonjour à tous, Je fais actuellement de la photo, essentiellement en CP, sur une AZ-EQ5 avec une lunette Orion 80ED et un MAK127. Ces instruments sont léger et compacts, avec de l'autoguidage, j'obtiens des résultats corrects sur des poses de 5 minutes avec un échantillonnage d'environ 2''/pixel, avec des étoiles rondes et peu de déchet. J'envisage de passer à un Newton de 150 ou 200mm, à FD4 ou FD5, pour gagner en diamètre en restant sur des focales assez courtes. 150 ou 200 ? Un 150/750 pèse en général 5kg, fait environ 70cm de long, je suis assez convaincu qu'il tiendra bien sur l'AZ-EQ5, aux problèmes d'équilibrage près. Par contre, un 200/800 ou 200/900, de 7 à 8 kg et 10 à 15 cm plus long, j'ai peur que ce soit un peu trop (mais c'est tentant). Si l'un d'entre vous a un retour d'expérience sur ce type de configuration ... Et, question subsidiaire : ma caméra est une ASI183, le capteur fait 13x9mm, avec ce type de tube, la coma risque t-elle d'être très gênante ? Merci d'avance !

En éclairant sur le mien, il n'y a pas d'écrou, juste 1 mm du bout de la vis qui dépasse. Et pour la queue d'aronde, c'est pareil. J'ai donc démonté et tout s'est bien passé. Merci à tous les deux pour votre aide !

Merci ! J'aimerais que la fixation de la queue d'aronde soit faite de la même façon.

Bonjour, Quelqu'un a t-il déjà dévissé sur un MAK127 Skywatcher récent (2018) la queue d'aronde et le support du chercheur ? Je crains de voir tomber des écrous dans le tube et ensuite grosse galère. Merci d'avance pour vos retours d'expérience ! Meilleurs cieux, Christophe

Pour éloigner le rocher de 2 000 tonnes de la surface de l'astéroïde, le problème ne sera pas de vaincre le poids du rocher dans le champ de gravité de l'astéroïde, puisque ce poids serait (si j'en crois les posts précédents) d'environ 10 Newtons (soit de l'odre de celui d'un objet d'1 kg à la surface de la Terre). Pour déplacer le rocher il faut lui donner de l'energie cinétique. L'energie cinetique d'un rocher de 2 000 000 de kg à une vitesse de 1 metre par seconde par exemple, est la même quel que soit le champ de gravitation, elle n'est pas diminuée par la faible pesanteur, c'est 1/2 mv², soit 1 000 000 de Joules. C'est beaucoup. La mise en mouvement du rocher, à supposer qu'il ne soit pas trop accroché à l'astéroïde, sera comme de mettre en mouvement un gros bateau à quai : c'est possible avec la force limitée d'un être humain, mais il faut pousser assez longtemps avant d'obtenir un résultat sensible. Cela nécessite aussi un bon point d'appui. Un simple coup de pied ne permettra pas de transmettre assez d'energie pour observer un déplacement. Si on suppose qu'un astronaute athlétique exerce une force de 1000N sur le rocher (soit de quoi tenir 100 kg à la surface de la Terre, donc un bel effort déjà) l'accélération du rocher sera d'environ 0,00005 m.s-2 (somme des forces = masse x acceleration). S'il tient cet effort pendant 100 secondes, le rocher de 2000 tonnes aura acquis la vitesse fabuleuse de 0,005 m/s (5 millimètres par seconde). Je suis prêt pour repasser le bac ? Corrigez moi si je me suis trompé...

@fredo38 : J'ai une ATIK16 qui utilise à peu près le même capteur (ICX429ALL - même taille et nombre de pixels, un peu plus sensible je crois). J'attire ton attention sur le fait que c'est un capteur entrelacé. L'image est lue en deux temps (lignes paires, puis lignes impaires). Sur l'ATIK 16, la lecture de l'image est assez longue (6 secondes pour la totalité de l'image, peut-être lié au fait qu'elle est en USB1, ou peut-être aussi une limitation du capteur). Du fait de ce long temps de lecture, la moitié du capteur qui attend que l'autre soit lue continue a recevoir de la lumière. Ce n'est pas trop gênant en ciel profond sur des pauses longues (> 60s, et plus si possible), mais sur des pauses courtes cela peut générer des lignes moches et assez difficiles à éliminer (j'ai essayé de mettre un exemple sur M33 en PJ). Sur l'ATIK16, il y a une case à cocher pour atténuer ce phénomène, mais c'est pas très efficace. J'ai vu quelques images de Starshoot G3 sur astrobin qui me laissent penser que le problème existe aussi avec cette caméra. Dans IRIS, je n'ai pas trouvé de quoi éliminer spécifiquement cela, je ne sais pas si d'autres softs en sont capables. Sinon, pour le côté positif : la taille du capteur, un peu frustrante au début, convient en fait à de nombreux objets si on considère ta lunette de 770mm de focale - et en plus les traitements vont vite car pas trop de pixels. Et les pixels pas carrés ne sont finalement pas une gène. christophe

@fredo38 : 752 x 582, c'est une ATIK 16 ? Colmic, c'est donc très clair : sur l'image issue d'un capteur couleur, les valeurs RVB de chaque pixel sont issues du photosite concerné et de ses voisins, et pas du tout une mesure stricte de valeurs RVB sur le photosite lui-même (sauf pour un des canaux). Le capteur a donc bien la même structure dans les deux cas (à la matrice de bayer et au traitement d'information près). ... et je me rends compte que j'avais lu cette explication sur d'autres pages du forum - (mais sans la comprendre). Et hop, un problème de résolu, encore merci !

Répéter la question ? C'est possible. D'ailleurs, pour une meilleure compréhension de tous, reformulons : on sait bien que c'est essentiel de reformuler. La question, c'est, pour un même capteur, en considérant ses versions monochrome vs RGB, de savoir si tant plus qu'il y a moins de la couleur, tant moins qu'il y a plus de sous-pixel. Ou pas. C'est-y plus clair ? Christophe

Bonjour à tous, Je me pose une question depuis assez longtemps sur la différences entre les capteurs couleur et monochrome, et je n'arrive pas à trouver la réponse ni sur le forum ni en lisant les datasheet des capteurs. Un ICX285, par exemple, a des pixels de 6.45 µ de côté, que ce soit en couleur (ICX285AL) ou en monochrome (ICX285AQ). Les deux versions du capteur ont le même nombre de pixels actif (1360 x 1024). Pour la version couleur, je lis que chaque pixel (au sens RGB, donc du carré de 6,45 µ de côté) est donc décomposé en 4 sous-pixels, avec matrice de bayer par dessus. Le capteur couleur comporterait donc 4 fois plus de photosites rééls que la version monochrome ? Cela me semble aberrant, parce que dans ce cas j'ai l'impression que techniquement les deux versions du capteur n'ont plus grand chose en commun. L'autre possibilité à laquelle je peux penser : que le capteur monochrome possède lui aussi 4 fois plus de photosites rééls que sa résolution affichée, ce qui le rend techniquement plus proche, de la version couleur. Mais cela me semble également bizarre (4 fois plus de photosites et pas le moyen d'en profiter ? ce serait trop triste). Je m'interroge donc : où est la vérité qui est peut-être ailleurs ? Merci d'avance à ceux qui pourront m'éclairer ... Christophe

En fait j'ai aussi utilisé Guitaretuna mais il ne reconnait pas la note !