graphique de correction PHD Guiding

[serge V]

Bonjour à tous,

Une petite question : Dans le graphique de courbe de correction de PHD Guiding , à quoi correspondent les lignes en abscisse ? (des secondes des pixels ?combien ?)

Sont elles dépendantes de l’échantillonnage de la lunette guide et de la camera ?

Ou du Min motion en pixels ?

Mon setup de guidage chercheur 60mm focal 225mm i-nova PLA-M pixels de 5,6 micron (kit pierrot astro)

Ben oui je m’en pose des questions

 

Si vous avez des réponses merci à vous

Cordialement

 

Serge

 

une image du test d'auto guidage d'hier soir en ville et entre les nuages

taka sky 90 + réducteur em 10 usd atik314L+

pauses de 5mn total 1h25

clique sur image pour agrandir

 

[Kaidan]

Pixels, 1 division = 1 pixel, il faut donc multiplier par l'échantillonage du système de guidage pour une valeur en seconde d'arc.

[serge V]

Super merci Kaidan

[patrice68500]

bonjour à tous,

J'ai aussi une petite interrogation concernant les graphiques de PHD.

Nous avons 2 graph: RA/Dec et dx/dy.

Je pensait en lisant le fichier d'aide que RA/Dec correspondait aux mouvements de l'étoile en RA et Dec (une sorte d'erreur péridique résiduelle avec le guidage en fonction) et dx/dy aux ordres envoyés à la monture.

En fait il semblerait que ce soit l'inverse!

donc pour régler les paramètres de phd, il faut affichez le graphique dx/dy (dx correspondant au décalage de d'étoile en dec et dy au décalage en RA) et tenter d'obtenir la courbe la plus plate possible en jouant sur les paramètres.

si quelqu'un peut confirmer à quoi correspondent ces graph ça m'aiderait beaucoup.

Merci à vous.

Patrice.

[teddelyon]

Salut, le sujet m'intéresse bien...

 

J'aimerai savoir comment vous faites pour afficher des graphs sous phd ? C'est à partir des fichiers log et d'un logiciel tiers ?

[ursus]

Salut, le sujet m'intéresse bien...

 

J'aimerai savoir comment vous faites pour afficher des graphs sous phd ? C'est à partir des fichiers log et d'un logiciel tiers ?

 

tools/enable graph

[Kaidan]

dx/dy correspond à la distance en pixels entre la position actuelle de l'étoile et la position précédente. RA/Dec correspond à la même distance projetée sur les axes RA/Dec en fonction de l'orientation de la CCD (le theta est déterminé lors de la calibration). C. Stark devrait nous mettre une cible pour voir la forme des impacts ... ça serait plus parlant que les courbes ... j'ai déjà réussi à avoir des courbes quasi-plates et des étoiles pas rondes car toutes les corrections ne se faisant que dans un sens ... en regardant dans un logiciel tiers d'analyse de logs, les étoiles avaient exactement la même forme que les impacts.

[teddelyon]

tools/enable graph

 

Merci Ursus, je ne connaissais pas cette(ces) fonction(s), qui n'existaient pas, il me semble, sous l'ancienne version de phd (celle fournie avec la cam) et effectivement je les découvre sur la dernière version que j'ai téléchargée récemment (suite changement pc) !

 

Peux-tu m'en dire un peu plus s'il te plaît ? Par exemple, je vois qu'on peux agir sur les différents paramètres à partir de la fenêtre "graph", ces changements s'opèrent-ils en temps réel ou est-il nécessaire de relancer une calibration à chaque fois ?

 

Qu'en est-il de la fonction "enable star profile" ? Rapport avec la MAP ?

 

Merci d'avance et désolé pour toutes ces questions Je me suis un peu "greffé"

[Tiflo]

Le changement des paramètres sur la fenêtre du graphique sont en temps réel, pas besoin de recalibrer.

Pour le reste il y a ...

[ursus]

les modifs se font en temps réel. Pas besoin de refaire une calibration.

 

La calibration permet à PhD de savoir de combien se déplace le télescope lorsqu'il envoie un ordre à la monture. Elle lui permet aussi de savoir le jeu.

 

Les paramètres que tu as sur le graphe permettent de jouer sur la qualité du suivi en direct.

 

Enable star profil doit servir à vérifier que le profil n'est ni saturé ni trop plat.

[Tiflo]

Le seul truc à régler, c'est de tenter d'avoir le "OSC Index" proche de 0,3-0,5. Pour ce faire il faut jouer sur les deux paramètres RA Hysteresis et RA Aggressiveness

 

Pour augmenter l'OSC Index : il faut augmenter RA Aggressiveness et/ou baisser RA Hysteresis

Pour le diminuer c'est l'inverse

Modifié 2 décembre 2012 par Tiflo

[teddelyon]

lLes paramètres que tu as sur le graphe permettent de jouer sur la qualité du suivi en direct.

 

Génial !!! Merci, c'est la réponse que j’espérai !!! J'ai hâte d'essayer ça quand... la neige se sera arrêter de tomber

 

Enable star profil doit servir à vérifier que le profil n'est ni saturé ni trop plat.

 

Ah ok.

 

Le seul truc à régler, c'est de tenter d'avoir le "OSC Index" proche de 0,3-0,5. Pour ce faire il faut jouer sur les deux paramètres RA Hysteresis et RA Aggressiveness

 

Pour augmenter l'OSC Index : il faut augmenter RA Aggressiveness et/ou baisser RA Hysteresis

Pour le diminuer c'est l'inverse

 

Les valeurs que tu donnes sont valables pour tous les setup ? Je ne connaissais pas encore le terme OSC Index ??? C'est une valeur permettant d'apprécier la qualité du rattrapage ? Désolé...pas taper...

[Tiflo]

Oui c'est valable pour tous les setups.

L'OSC (oscillation) Index est juste là pour dire si tu sur- ou sous- corriges ton autoguidage.

 

Le second paramètre est noté "RMS", c'est grosso-modo l'erreur moyenne de ton guidage exprimée en pixels. Si tu veux la valeur en seconde d'arc (qui est la seule unité pertinente, exprimer ça en pixel est totalement inutile ...), il faudra la multiplier par ton échantillonnage ( = 206 * taille des pixels de guidage / focale de guidage)

[teddelyon]

Oui c'est valable pour tous les setups.

L'OSC (oscillation) Index est juste là pour dire si tu sur- ou sous- corriges ton autoguidage.

 

Le second paramètre est noté "RMS", c'est grosso-modo l'erreur moyenne de ton guidage exprimée en pixels. Si tu veux la valeur en seconde d'arc (qui est la seule unité pertinente, exprimer ça en pixel est totalement inutile ...), il faudra la multiplier par ton échantillonnage ( = 206 * taille des pixels de guidage / focale de guidage)

 

Super, c'est très clair ! Merci beaucoup.

[Fred_76]

Bonjour

 

Ceux qui savent programmer pourront participer aux évolution de PHD Guiding, en apportant par exemple :

- l'ajout de l'échantillonnage pour avoir une courbe en arc.sec et non en pixels

- avoir la cible comme dans GuideMaster

 

... et bien d'autres choses.

 

http://code.google.com/p/open-phd-guiding/

 

A+

 

Fred

[patrice68500]

dx/dy correspond à la distance en pixels entre la position actuelle de l'étoile et la position précédente. RA/Dec correspond à la même distance projetée sur les axes RA/Dec en fonction de l'orientation de la CCD

je ne comprend plus rien à ces graph. Si l'un correspond au décalage sur le capteur (en pixel) et l'autre au même décallage sur les axes RA et Dec, les deux graphs devrait correspondre, peut être inversé éventuellement.

sur mon essai, je n'avait aucune correspondance entre le graph ra/dec et le graph dx/dy. en coupant le rattrapage en dec, la courbe dec du graph est devenue rectiligne alors que la courbe dx du deuxième graph est partie vers le haut (j'avais pas fait de mise en station volontairement pour tester le guidage sur les deux axes). ce qui m'a ammené à la conclusion que le graph ra/dec correspondait au ordres envoyés à la monture et le graph dx/dy au décallage en pixel sur le capteur.

Donc je ne comprend plus rien.

[Kaidan]

En fait, le code retourne 0 si le guidage en déclinaison est désactivé pour la valeur Dec : ce qui est logique de toute façon, si l'autoguidage est Dec n'est pas fonctionnel, il est probable que la calibration n'a pas été faite non plus et donc que le theta de l'angle entre dx/dy et la Dec ne soit pas connu. dx/dy continue à évoluer puisque tous les deux participes au guidage en Ad du moment que theta n'est pas multiple de Pi/2.