Position de park systématiquement décalée avec EQMOD - HELP

[Lenico75]

Hello,

J'au un gros souci avec mon EQ8 et EQMOD. J'ai une position de park personnalisée pour que le toit de mon observatoire de dézingue pas mon tube lorsqu'il se ferme ou s'ouvre. Depuis quelques temps le tube lorsqu'il se park présente plusieurs degrés de décalage (principalement en AD) par rapport à sa position de park. C'est très ennuyeux car avec mes aimants de sécurité cela empêche du coup la fermeture du toit en mode "Auto". Si la pluie se pointe. C'est la cata !

Le problème se pose avec ou sans encodeurs activés dans EQMOD (Via l'option "enable encoders"). Si je démarre la séance (aucun point de sync), que je pointe un truc et que je fais un plate solve et bien si je lance ensuite mon park alors pas de souci. Si ensuite je relance une cession en ayant au préalable chargé le point de syncro précédent et bien à la fin de la cession je vais avoir ce gros décalage de park. Et après ça  si je dépark et repark dans la foulée alors là elle se met dans la bonne position.

 

Bref...  l'enfer... j'y perd mon latin. A mon avis je suis une quiche pour comprendre les nuances d'EQMOD.  Quelqu'un a t il déjà eu ce genre de galère sur des park personnalisés ?

 

Merci d'avance

Nicolas

[pyrou61]

... j'ignore ton problème, malheureusement, étant en nomade (je recommence tout à zéro à chaque session). Par contre, je n'utilise plus eqmod mais GSServer plus récent, mis à jour et plus de fonctions .. c'est peut-être une solution, mais il faut tester !... bon ciel ! 

[180Vision]

Salut,

J'ai aussi ce souci récurrent avec EQMOD et pas testé avec GSServer encore...

 

Ma position parking est aussi "custom" dans le sens où elle correspond à mes positions "repères gaffer" pour lesquelles mon viseur polaire est en position départ "6 en bas"...

Quand je park/unpark, idem pas de souci.

 

Par contre, si je fais un session NINA avec un ou plusieurs objet, et donc du plate solving plusieurs fois au milieu, la commande park en fin de nuit mets mon setup en décalage par rapport à ce qu'il devrait être !

La solution de contournement que j'ai trouvé est de faire un "solve and sync" dans NINA, avant le park de fin de nuit...et là plus de souci...sauf si les nuages se sont invités lol...

 

BRef, je ferai des essais avec GSServer aussi pour tirer ça au clair des fois que ce soit en effet un "bug" ASCOM.

[Lenico75]

Merci les amis. Le probleme est que le plate solve final qui pourrait contourner le problème doot se faire en automatique (le principe de l'observatoire c'est l'absence d'intervention de ma part). Donc faudrait purger la liste des points de synchronisation et relancer un plate solve ensuite. Mais si la monture se park car les nuages sont arrivés..  ca marchera pas 😞

[180Vision]

Just now, Lenico75 said:

Merci les amis. Le probleme est que le plate solve final qui pourrait contourner le problème doot se faire en automatique (le principe de l'observatoire c'est l'absence d'intervention de ma part). Donc faudrait purger la liste des points de synchronisation et relancer un plate solve ensuite. Mais si la monture se park car les nuages sont arrivés..  ca marchera pas 😞

Moi je n'ai pas la chance (pour le moment) d'un obsevratoire/abri mais je fais tout comme, c'est à dire que je déclenche une séance full-automatisée via NINA...mais en effet, le seul hic, ce sont les nuages et là, il n'y a pas je pense de méthode pour détecter ça

 

Un "Solve and sync" au sein de chaque set d'instructions (en fin) affine le truc...mais bon, pas non plus la panacée...

 

[Lenico75]

Mou je bosse avec SGP. Faudrait que je trouve un moyen de déclencher juste un depark/Park juste à la fin. Juste avant de lancer la commande pour fermer le toit