néb diff Une belle M42 au Strock...

CDLC · 9 janvier 2016

Bonjour à tous,

14 + 53 photos de 6s au Strock non autoguidé sur table équatoriale.

Canon EOS 450d défiltré partiel. Filtre PL Orion, Correcteur de Coma RCC Baader. Photos prises depuis la Métropole Lilloise (avec toujours mes 3 projecteurs de 250w en face de moi!).

14 photos le 7 janvier 2015 (ciel très clair, mais énormément de vent),

53 photos le 8 janvier 2015 (ciel clair, un peu moins de vent - quelques passages nuageux),

Jetstreams à 41m/s et seeing de 1.42" à 1.64" selon météoblue pour les 2 nuits.

Bref, conditions pas idéales, mais s'il était encore nécessaire pour prouver qu'il est possible de faire des photos du ciel profond en ville, qui plus est, avec un Strock...

J'avoue que je suis plutôt satisfait du résultat.

Vos remarques et commentaires sont les bienvenus.

Christophe

alexthecoolman · 9 janvier 2016

Comme quoi la photo au dobson c'est possible

Et avec un 450d, imagine avec un appareil dernière génération

benjamindenantes · 9 janvier 2016

C'est clairement un excellent résultat vu les conditions de prise de vue et le matos utilisé.

Bravo et lâche rein pour tenter d'augmenter tes temps de pose unitaire.

kmille16 · 9 janvier 2016

+ avec Benjamindenantes!!

Comme quoi l coutume tien toujours!! "ce n'est pas le matos qui fait l'astrophotogaraphe!!"

Quoi que ??!! au vue de tes resultats

tu aurais une photos des conditions de prise de vues??

CDLC · 11 janvier 2016

Bonjour et merci à tous les 3 pour vos commentaires.

Oui certes je prévois clairement de pouvoir allonger les temps de pose. Mais les fortes bourrasques de vent rendaient la chose strictement impossible. Avec 6s, je pouvais espérer passer entre les bourrasques... parfois...

Mon objectif final est 30s, soyons honnêtes, il paraît difficile de faire plus tellement le Strock est sensible à la moindre bourrasque de vent... (puisqu'il n'est pas maintenu en son centre de gravité, mais sa base).

Effectivement les conditions étaient dantesques, et le vent n'était pas le seul élément perturbateur : j'ai arraché des fils sur la télécommande de la table EQ, et j'ai dû donner du fer à souder par 3 fois! Heureusement que j'étais à la maison!

Sans compter les faux contacts avec les logements des piles ou les piles qui menacent de se décharger... J'ai du coup commandé un powertank 5v pour recharger les iPhones et iPads (c'est un 22400mAh... J'aurai de quoi tenir!).

kmille, je te posterai une photo des conditions pour te faire une idée...

Merci encore pour vos encouragements... Certains semblent blasés de voir des M42 partout (tellement classique!)... J'ai eu finalement peu de commentaires, relativement aux efforts déployés pour une telle photo...

Modifié 11 janvier 2016 par CDLC

OrionRider · 11 janvier 2016

Si tu arrives à obtenir des étoiles rondes sur des poses de 30sec ça ouvre des portes car avec un Sony A7S on peut envisager beaucoup d'autres cibles que M42.

Bravo! On suit tes aventures avec attention.

benjamindenantes · 11 janvier 2016

Si tu arrives à obtenir des étoiles rondes sur des poses de 30sec ça ouvre des portes car avec un Sony A7S on peut envisager beaucoup d'autres cibles que M42.

Bravo! On suit tes aventures avec attention.

C'est une piste a creuser en effet. J'envisage de plus en plus cette solution...

Dob de 250 ou 300 sur table équatoriale et poses de 30S à l'A7S...

Avec un F/D de 4,5 par exemple, je suis persuadé que les résultats seraient bluffants.

Faut juste que la table équato fasse bien son job.

CDLC · 11 janvier 2016

C'est une piste a creuser en effet. J'envisage de plus en plus cette solution...

Dob de 250 ou 300 sur table équatoriale et poses de 30S à l'A7S...

Avec un F/D de 4,5 par exemple, je suis persuadé que les résultats seraient bluffants.

Faut juste que la table équato fasse bien son job.

Clairement, la dérive en DEC est un problème rapidement surmontable avec une mise en station selon, la méthode "DARV". Elle est très facile à mettre en oeuvre si ta motorisation est pilotée par un logiciel (arduino par exemple).

Part contre, le réglage de la vitesse en AD est un enfer. J'ai l'impression que la vitesse doit être adaptée selon la position dans la course de la table! Pourtant je suis normalement propre en vitesse (moteur pas à pas) et en position du centre de gravité!

Je poursuis les essais et mise au point, mais c'est ici la plus grande limite.

Enuite, l'autoguidage permet 2 choses:

1- corriger un peu les erreurs de vitesse et donc reponctualiser les étoiles. Ne pas en attendre non plus un miracle.

2- corriger les éventuelles dérives, et éviter de se retrouver avec une telle dérive globale au fur et à mesure des poses qui fera que le recouvrement des poses ne correspondront qu'à 50% du capteur... C'est surtout là que se passera le gain.

Christophe

benjamindenantes · 11 janvier 2016

Aucun intérêt pour moi si la table ne tient pas 30s sans autoguidage...

Grâce à l'A7S, j'ai abandonné l'autoguidage avec mon équato car des pose de 30s sont très largement suffisantes.

Maintenant, si je dois retourner à l'autoguidage avec un table équato, c'est pas la peine.

Je dispose d'un picastro et d'un astroeq pour piloter la chose. C'est totalement paramètrable en vitesse et pilotable depuis cdc et ascom.

Etrange ton soucis de vitesse... Tu as fais une courbe d'ep pour savoir d'ou viennent tes sources de dérive? (autre que celle en dec liée à la MES)

CDLC · 11 janvier 2016

Aucun intérêt pour moi si la table ne tient pas 30s sans autoguidage...
Grâce à l'A7S, j'ai abandonné l'autoguidage avec mon équato car des pose de 30s sont très largement suffisantes.

Maintenant, si je dois retourner à l'autoguidage avec un table équato, c'est pas la peine.

Je dispose d'un picastro et d'un astroeq pour piloter la chose. C'est totalement paramètrable en vitesse et pilotable depuis cdc et ascom.

Etrange ton soucis de vitesse... Tu as fais une courbe d'ep pour savoir d'ou viennent tes sources de dérive? (autre que celle en dec liée à la MES)

J'étudie la chose:

J'ai un potentiomètre pour dire à l'Arduino à quelle vitesse piloter le moteur.

Quand je clique sur un premier bouton, il lance un compteur (somme des vitesses commandées / nombre de comptages, 10x par seconde).

Je suis mon étoile guide à fort grossissement, et quand je retombe dessus après 1 à 2mn, je clique sur un second bouton. La vitesse moyenne appliquée au moteur est alors calculée et appliquée (le potentiomètre ne sert alors plus). La vitesse moyenne est alors affichée à l'écran.

Au fur et à mesure de l'utilisation de ma table, je vais donc noter les vitesses moyennes que je trouve, et voir si il y a des écarts ou non. Bref, essayer de comprendre.

J'ai commandé sur internet un Arduino Mega qui offre plus d'E/S. A terme, je vais utiliser un écran LCD tactile... Je devrais alors pouvoir afficher des infos plus précises.

Je pense également asservir la vitesse AD en fonction des commandes ST4, et de fait, avoir un affichage "réel" de la vitesse AD à l'écran. ce sera donc le meilleur moyen de voir si il y a variation ou non.

Je ne puis en dire plus, car je n'en sais pas plus pour l'instant.

Ps : Je précise que l'alignement en Azimut de la table était nickel (par DARV 125s), mais pas réglé en hauteur/latitude. Ceci explique potentiellement cela également. Ne crions pas défaite trop tôt!

Christophe

OrionRider · 11 janvier 2016

Dob de 250 ou 300 sur table équatoriale et poses de 30S à l'A7S...

Les tables TomO le permettent, mais c'est cher. http://www.equatorialplatforms.com/

Un 300 f/4 léger passe sur une EQ6 pour des poses de 30 sec.

Peut-être même que ça marcherait avec un Dob GoTo, si la motorisation est de bonne qualité (Picastro en micropas et courroies). En 30sec il ne doit pas y avoir tant de rotation de champ que ça. :confused:

En plus, une légère rotation de champ se corrige facilement dans PS avec un calque en mode 'assombrir'. Tant que l'objet est au centre, c'est bon.

Cyrilounet · 11 janvier 2016

Comme d'habitude, je suis bluffé parce que tu arrives à faire avec ton strock.

C'est qu'avec 6s on peut en faire des choses. Pour rappel, avec ce tps là et le même matériel, tu as pu décrocher les piliers (M16) : http://www.webastro.net/forum/showthread.php?t=130514

Bon ce n'était pas le même ciel mais tout de même !

C'est sûr que tu peux avoir mieux avec un APN ultra sensible mais je vois que tu es concentré sur l'atténuation des erreurs de suivi pour augmenter ton temps de pose unitaire. C'est mieux de commencer par ça je pense !

CDLC · 11 janvier 2016

Les tables TomO le permettent, mais c'est cher. http://www.equatorialplatforms.com/

Un 300 f/4 léger passe sur une EQ6 pour des poses de 30 sec.

Peut-être même que ça marcherait avec un Dob GoTo, si la motorisation est de bonne qualité (Picastro en micropas et courroies). En 30sec il ne doit pas y avoir tant de rotation de champ que ça.

En plus, une légère rotation de champ se corrige facilement dans PS avec un calque en mode 'assombrir'. Tant que l'objet est au centre, c'est bon.

Comme je l'ai expliqué, le mécanisme en autoguidage "DEC" de Tom'O ne fonctionne pas, sauf pour 20% de la voûte céleste... donc oui çà fonctionne en AD, mais clairement pas en DEC. A oublier!

benjamindenantes · 11 janvier 2016

Comme je l'ai expliqué, le mécanisme en autoguidage "DEC" de Tom'O ne fonctionne pas, sauf pour 20% de la voûte céleste... donc oui çà fonctionne en AD, mais clairement pas en DEC. A oublier!

Je comprends pas en quoi l'axe dec est obligatoire pour poser quelques secondes... Si la mise en station est bien faite, il y a très peu de dérive et donc pas besoin de corriger en dec. non?

Avec mon équato, je préférais justement passer un peu de temps a faire une MES nickel, ce qui permettait de pas avoir a autoguider en dec sur 2 à 3 minutes de pose. Pour tenir 30s même si la focale est plus élevée, une MES correcte doit être suffisante.

OrionRider · 11 janvier 2016

le mécanisme en autoguidage "DEC" de Tom'O ne fonctionne pas, sauf pour 20% de la voûte céleste

Faudra m'expliquer comment il fait alors pour obtenir ces images. Elles ne sont pas toutes dans 20% de la voûte céleste... :confused:

http://www.utopia-photography.ch/universe/c/01/p08.html

http://www.utopia-photography.ch/universe/c/01/p07.html

http://www.utopia-photography.ch/universe/c/01/p09.html

http://www.utopia-photography.ch/universe/c/01/p02.html

Il y a des poses de 15 minutes (!), impossible de faire ça à cet échantillonnage si le guidage en DEC ne marche pas. :rolleyes:

Modifié 11 janvier 2016 par OrionRider

CDLC · 11 janvier 2016

Je comprends pas en quoi l'axe dec est obligatoire pour poser quelques secondes... Si la mise en station est bien faite, il y a très peu de dérive et donc pas besoin de corriger en dec. non?

Avec mon équato, je préférais justement passer un peu de temps a faire une MES nickel, ce qui permettait de pas avoir a autoguider en dec sur 2 à 3 minutes de pose. Pour tenir 30s même si la focale est plus élevée, une MES correcte doit être suffisante.

La dérive en DEC, si MES bien faite est effectivement minime sur 30s, mais l'autoguidage la verra et tentera une correction... voire, perdra l'étoile à moyen terme. Donc oui, je pense que l'autoguidage en DEC reste nécessaire. Sauf à pouvoir vraiment le désactiver et laisser PHD2 suivre l'étoile en DEC sans corriger, mais est-ce faisable?

CDLC · 11 janvier 2016

Faudra m'expliquer comment il fait alors pour obtenir ces images. Elles ne sont pas toutes dans 20% de la voûte céleste...

http://www.utopia-photography.ch/universe/c/01/p08.html

http://www.utopia-photography.ch/universe/c/01/p07.html

http://www.utopia-photography.ch/universe/c/01/p09.html

http://www.utopia-photography.ch/universe/c/01/p02.html

Il y a des poses de 15 minutes (!), impossible de faire ça à cet échantillonnage si le guidage en DEC ne marche pas.

Quand je dis "20%" de la voûte, je m'explique : ton AD ne doit pas être à plus de 15° (1h) de la médiane de la table, sinon, tes axes AD/"DEC" ne sont plus orthogonaux.

Ceci-dit, j'aimerais bien voir sa table en fonctionnement...

Christophe

benjamindenantes · 11 janvier 2016

La dérive en DEC, si MES bien faite est effectivement minime sur 30s, mais l'autoguidage la verra et tentera une correction... voire, perdra l'étoile à moyen terme. Donc oui, je pense que l'autoguidage en DEC reste nécessaire. Sauf à pouvoir vraiment le désactiver et laisser PHD2 suivre l'étoile en DEC sans corriger, mais est-ce faisable?

L'idée en ce qui me concerne c'est de pas autoguider du tout!

Avec une focale et un échantillonage raisonable, c'est pas du tout utopique.

Quand en fin de soirée on a 300 poses de 30s , on peut se permettre d'en perdre un certain pourcentage.

J'admire ton projet mais je trouve que tu ne te facilite pas les choses avec un scope qui me parait très long et avec une électronique "maison".

Ce serait pas beaucoup plus simple avec un scope plus trappu et une motorisation dédiée genre picastro ou astro eq?

Bien entendu tu fais avec ce dont tu dispose, je dis ça pour ceux qui s'intéressent a cette technique.

Modifié 11 janvier 2016 par benjamindenantes

CDLC · 11 janvier 2016

L'idée en ce qui me concerne c'est de pas autoguider du tout!
Avec une focale et un échantillonage raisonable, c'est pas du tout utopique.

Quand en fin de soirée on a 300 poses de 30s , on peut se permettre d'en perdre un certain pourcentage.

J'admire ton projet mais je trouve que tu ne te facilite pas les choses avec un scope qui me parait très long et avec une électronique "maison".

Ce serait pas beaucoup plus simple avec un scope plus trappu et une motorisation dédiée genre picastro ou astro eq?

Bien entendu tu fais avec ce dont tu dispose, je dis ça pour ceux qui s'intéressent a cette technique.

Je fais selon mon cahier des charges, et c'est la pire configuration! Un Strock!

Mais si j'y arrive, il est évident que ce sera applicable pour des télescopes plus trapus.

Pour la motorisation : la mise en place d'une motorisation à base d'Arduino est vraiment facile, la difficulté est juste de déterminer la vitesse...

Pour les 30s sans autoguidage, ce sera vraiment très chaud... il faut vraiment une motorisation et une MES absolument impeccables... Mais bon, est-ce impossible? On verra bien à l'usage.

Christophe

OrionRider · 11 janvier 2016

sinon, tes axes AD/"DEC" ne sont plus orthogonaux.

Ce n'est pas un drame non plus si une correction en DEC cause un minuscule mouvement en AD puisque cet axe est aussi corrigé en temps réel par l'autoguidage.

CDLC · 11 janvier 2016

Ce n'est pas un drame non plus si une correction en DEC cause un minuscule mouvement en AD puisque cet axe est aussi corrigé en temps réel par l'autoguidage.

Quand c'est minime, c'est acceptable, on est d'accord. Mais il y a des zones du ciel où les 2 axes se confondent ou s'opposent, et là, t'es mort!

L'axe de rotation de la correction "DEC" est en réalité "Est-Ouest" du lieu.

L'axe de rotation de la corrextion "AD" est l'axe de rotation de la terre.

Conséquence, si tu vise à mi-chemin entre le Pôle Nord céleste et l'Ouest (ou l'Est), tes axes se confondent, puisqu'ils sont une portion de circonférence de 2 cercles et que tu es exactement à la médiane des centres de tes 2 cercles..

J'ai fait l'essai avec mon ancienne table. Je te garantis que çà ne marche pas!

Christophe

CDLC · 13 janvier 2016

Petite question:

Maintenant que j'ai une fonction DARV pour permettre une mise en station propre, je suis en mesure de réduire très significativement tout risque de dérive "importante" en DEC (sur 30s j'entends).

Il me reste le réglage de la vitesse en AD.

Je peux connecter l'arduino en USB et recevoir les commandes ST4 par USB (https://github.com/kevinferrare/arduino-st4).

Mais j'ai juste une question:

Est-il possible de dire à PHD de ne faire aucun autoguidage en DEC, et de déplacer le réticule de suivi si nécessaire, tout en faisant un autoguidage en AD qui lui, est nécessaire?

D'avance merci

Christophe

alexthecoolman · 13 janvier 2016

une piste : tu as la star adventure qui permet un autoguidage en AD et n'a rien DEC donc il doit y avoir moyen. ouvre peu être un fils de discutions spécifique tu auras plus de publique.

OrionRider · 13 janvier 2016

Est-il possible de dire à PHD de ne faire aucun autoguidage en DEC

Bien sûr, dans PHD2 les options sont 'auto', 'nord', 'sud' et 'aucun'.

Tu peux rattraper l'erreur en DEC de temps en temps à la main. En principe, l'erreur DEC se fait toujours dans le même sens ('nord' ou 'sud'), selon l'erreur de mise en station.

Avec une EQ, je constate que la dérive s'annule puis s'inverse à l'approche du méridien. Pour une table équato, je n'ai aucune idée.

David_LEGRANGER · 14 janvier 2016

Bravo Christophe pour cette belle image de m42 avec un dobson sur table equatoriale

David

CDLC · 15 janvier 2016

Merci David,

Orion, Alex, Benjamin,

Les prochains essais sont en préparation. J'ai reçu une nouvelle carte Arduino, des afficheurs et des moteurs pas à pas. Je viens donc de terminer une nouvelle télécommande qui devrait me permettre de poursuivre les investigations.

De plus, elle sera connectée par USB au PC pour recevoir les consignes d'autoguidage, moyen le plus fiable d'observer en temps réel si j'ai une variation de la vitesse de suivi en fonction de la position dans la course de la table.

La suite au prochain épisode.

nonodu28 · 16 janvier 2016

Wouaw, je vois que ton investissement n'a pas été vain.

Beau travail, ça promet pour la suite!

CDLC · 18 janvier 2016

Part contre, le réglage de la vitesse en AD est un enfer. J'ai l'impression que la vitesse doit être adaptée selon la position dans la course de la table! Pourtant je suis normalement propre en vitesse (moteur pas à pas) et en position du centre de gravité!
Je poursuis les essais et mise au point, mais c'est ici la plus grande limite.

Après essais hier soir et relecture de code de la librairie de commande du moteur pas à pas, je viens de comprendre le bug:

La librairie se cale au microsecondes... mais n'attend pas si un step doit être fait ou pas, résultat, on peut avoir un peu de latence...

Le problème est qu'elle calcule l'instant du pas suivant à partir de l'instant T2 du pas actuel et non l'instant T1 auquel le pas actuel aurait dû avoir lieu...

La latence s'additionne donc "pseudo aléatoirement" à chaque pas... Rendant la fréquence double... pas double!

A fréquence commandée double, pas de vitesse commandée réellement double... Nous avons vérifié à l'oscilloscope!

La suite au prochain épisode...

Christophe

Modifié 29 janvier 2016 par CDLC

CDLC · 29 janvier 2016

+ avec Benjamindenantes!!

Comme quoi l coutume tien toujours!! "ce n'est pas le matos qui fait l'astrophotogaraphe!!"

Quoi que ??!! au vue de tes resultats

tu aurais une photos des conditions de prise de vues??

Bonjour kmille,

Voici pour te donner une idée:

Le Strock T200 prêt en mode "sans autoguidage".

Le site d'observation... Le Sud-Ouest est en face, le Sud à gauche... Et surtout : 3 projecteurs de 250W sur l'immeuble d'en face!

La table EQ:

Quelques écrans de la télécommande...

La validation à l'oscilloscope de la vitesse "x2"...

Christophe

Cyrilounet · 30 janvier 2016

Quel bel oscillo !

ça me rappelle mes projets de fac Pourquoi j'ai pas fait des choses comme ça ? Les sujets des projets étaient imposés et pas vraiment exaltant... enfin bref ! Beau boulot !

Petite question comme ça : que signifie les infos sur l'afficheur ? est-ce qu'elles ont une réelle signification (si oui laquelle) ou est-ce que tu as juste spécifié (comme ça pour tester l'afficheur) quels segments allumer quand tu actionnes un des 4 boutons ?

Connexion

néb diff Une belle M42 au Strock...

Messages recommandés

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante