NINA - PHD2,le guidage en DEC part en vrille...

[Phil49]

histoire que ton aventure puisse servir à d'autres, tu parles de quel paramètre? C'était quoi la solution: cocher ou décocher quoi?

Bonsoir Laurent,

Avec plaisir, c'est le moins que je puisse faire !

Pour toute personne qui utilise GSserver avec NINA, au contraire de ce qu'il faut faire avec Eqmod (pourtant GSServer est une surcouche de ce dernier !), il faut IM PE RATI VE MENT cocher cette case :

image.png

Comme dit, hier soir je n'ai plus été impacté par la dérive brutale en DEC !

Il me faudra une autre soirée pour valider que c'est bien le cas, mais la plupart des documents et tutos (dont le site de GSserver !) que j'ai vus ou lus pointaient tous sur ce paramètre dès lors qu'il y avait une dérive telle que celle que j'avais !

Cela ne veut pas dire que cela sera systématiquement le cas, peut-être y a t'il es montures qui réagiront différemment, mais la Skywatcher AZ EQ6 GT c'st le cas, et Cuiv The Lazy Geek faisait sa démo qui remonte à deux ou trois ans avec une EQM 35ou une NEQ6 je crois !

Cette vidéo à environ 7mn55 se :




Philippe

[bemo47]

ce qu'il faut faire avec Eqmod (pourtant GSServer est une surcouche de ce dernier !)

Heuu, non, non, GSSERVER remplace EQMOD, les deux sont des drivers ASCOM pour ta monture, mais c'est soit l'un, soit l'autre.

Merci pour la case à cocher, ça peut aider effectivement.

Finalement, c'est donc tout bon, on va commencer à voir de belles images alors !!!

[Phil49]

Heuu, non, non, GSSERVER remplace EQMOD, les deux sont des drivers ASCOM pour ta monture, mais c'est soit l'un, soit l'autre.

Par contre autre chose qui pourra aider ceux qui font cohabiter PHD2 et GSServer !

J'ai acheté un autre câble Eqmod car celui que j'avais, de Pégasus était très long et en bande, j'ai donc acheté une autre marque fabriquée en Angleterre, plus courte et section ronde, et j'ai un peu galéré !

Chaque câble prend une paire de ports COM qui peut-être différente, et quand j'ai eu changé de câble, GSServer démarrait systématiquement avec une erreur Axis mount !

J'ai cherché sur les forums et par rebond je suis tombé sur cette question de port COM à vérifier et de fait, dans mon cas, il était passé du port COM3 au 4 et même en le sélectionnant, cela n'est pas tout de suite rentré dans l'ordre.

Il a fallu faire pas mal de manips, redémarrer, etc. et enfin c'est rentré dans l'ordre.

A un moment j'ai même cru que je n'arriverai pas à refaire marcher GSServer et j'ai voulu réaffecter Eqmod dans NINA !
Eh bien il n'a jamais voulu rien savoir !
Il redémarrait systématiquement GSServer !

C'est pour cela que je ne suis pas vraiment certain du fonctionnement étanche de l'un et de l'autre...

Si GSServer tourne tout seul sans Eqmod effectivement alors, mais vu que j'ai les deux pas pu vérifier.

Dernière chose : le câble Pegasus était capable de fonctionner en ps9600 et et 115 600, l'autre câble non !
C'est pour cela que j'ai un peu galéré aussi !
Finalement j'ai donc dû redescendre à 9600 bauds, ce qui est suffisant pour le moment compte tenu du faible volume de data mais si un jour il venait à grimper (ce qui n'est pas à l'ordre du jour) il me faudrait repasser à une autre marque ou le Pegasus...

Pour les images, oui, c'est mon vœu le plus cher maintenant !

Philippe

[lordzurp]

les ports COM, ça change tout le temps c'est "normal" (ou plutôt connu ...)
t'as jamais joué avec des arduino, ça se voit !

pour le débit, 2 choses :
* pour quelle raison magique ça pourrait demander un jour + de débit ?
* la vitesse affichée dans windows dépend de la puce intégrée au cable, qui fait la conversion usb<->série, mais au bout c'est à l'électronique de ta monture que tu parles, il y a peu de chance qu'elle accepte une valeur différente du 9600 standard (tu as réussi à dialoguer à 115 600 ??)

c'est le métier qui rentre, comme on dit

en tout cas, content que tu avances vers une solution fonctionnelle

[Phil49]

les ports COM, ça change tout le temps c'est "normal" (ou plutôt connu ...)
t'as jamais joué avec des arduino, ça se voit !

Hello,

Non mais pas mal sur Pi4, mais je n'ai jamais été confronté à ce comportement, il faut dire que c'était surtout pour de l'audio et de la vidéo...

pour le débit, 2 choses :
* pour quelle raison magique ça pourrait demander un jour + de débit ?
* la vitesse affichée dans windows dépend de la puce intégrée au cable, qui fait la conversion usb<->série, mais au bout c'est à l'électronique de ta monture que tu parles, il y a peu de chance qu'elle accepte une valeur différente du 9600 standard (tu as réussi à dialoguer à 115 200 ??)

Bah je ne suis pas aussi spécialisé que toi, mais deux choses.

La première, dans le monde de la boite rouge du diable, va mettre 9 600 bauds en eqmod, tu vas voir tu m'en reparleras !

Deuxième chose, pour de nombreuses applis notamment Stellarmate, Ekos, eqmod nécessite de passer en 115 200 bauds.

INDI notamment fonctionne avec ce taux.

Maintenant, peut-être que les 9 600 bauds ne seront jamais dépassés dans la réalité et que pour d'obscures raisons logicielles il faille sélectionner 115 200, mais mon réflexe "pavlovien" de 115 200 ne vient pas de nulle part !

Peut-être également que l'AZ EQ6 est un cas à part...

Philippe

[soulearth]

Héhé. Vous avez tout les deux raison. 9600 bauds, c'est la vitesse "historique", celle qu'on retrouvait un peu partout sur les connexions séries.

Et 115 200 alors ? Ben il existe aussi! En général on le trouve plutôt sur des connexions série/console mais qui utilisent un câble USB. La connexion série pouvant se faire avec n'importe quel bout de câble conducteur, certain on eu l'idée de remplacer notre vieux câble série par un truc un peu plus "sérieux" genre un câble USB. Câble USB qui a tout de même un blindage un peu moins pourri. Ce qui permet d'augmenter la vitesse. Pour autant il est utilisé comme un bout de câble sans aucun lien avec le protocole USB

Je sais ça brouille les pistes. Je m'enquiquine avec ça assez régulièrement...

[Lavinch31]

Pour toute personne qui utilise GSserver avec NINA, au contraire de ce qu'il faut faire avec Eqmod (pourtant GSServer est une surcouche de ce dernier !), il faut IM PE RATI VE MENT cocher cette case

GSS,NINA ou EQMOD n'ont rien a voir avec ce réglage. Ce réglage sert uniquement si ta monture ne sait pas dire à PHD2 de quel côté du pied se situe le tube et ton AZ EQ6 sait très bien donner cette info a PHD2

image.png

Par contre tu as peut etre activé cette info en amont ( dans GSS ou NINA ) et tu viens finalement donner un contre ordre en cochant cette info également dans PHD2. Regarde côté GSS ou NINA si tu n'as pas également activé cette inversion de la sortie DEC après meridian flip.

[Phil49]

Par contre tu as peut etre activé cette info en amont ( dans GSS ou NINA ) et tu viens finalement donner un contre ordre en cochant cette info également dans PHD2. Regarde côté GSS ou NINA si tu n'as pas également activé cette inversion de la sortie DEC après meridian flip.

Bonjour,

Alors j'ai regardé mes captures écrans car je suis au boulot et effectivement voici ce que j'ai actuellement dans NINA dans deux sections différentes pour gérer ces aspects :

Télescope :

NINA Teelscope section.jpg

Et dans la section Meridian flip :

NINA meridian flip section.jpg

Je n'ai pas trouvé d'infos liées à cela sur GSServer, mais je commence juste à l'utiliser, si quelqu'un peut confirmer ?

Donc, si nous n'avons que les informations de NINA, la question est : quels choix pour gérer les deux scenarii : images sans et avec meridian flip !?

Philippe

[bemo47]

Tu as de l'info de Rob Morgan lui même ici, le créateur de GSS https://vimeo.com/401401922 ou l'ensemble de ses vidéos ici https://greenswamp.org/?page_id=790

Globalement, le "use side of pier" de NINA doit être à ON je pense car NINA va aller chercher cette info auprès de GSS qui la fournit au lieu de l'estimer lui même. Chez moi il était à OFF.... et le flip se passait bien, mais ça ne me semble pas logique qu'il soit à OFF, mais vu que je ne travaille pas avec GSS, je revérifierai ça.
Après tout est affaire de limites et dans GSS et dans NINA, mais je crois qu'on les avait revues lors de la séance discord donc elles doivent être bonnes, sachant que c'est en général NINA qui va décider quand faire le flip, entre 2 poses, la limite dans GSS doit être supérieure et agir uniquement comme sécurité, pour arrêter le tracking par exemple, si jamais NINA n'avait pas lancé le flip à temps.
Et il n'y a pas d'option side of pier à choisir dans GSS car il fournit l'info par défaut aux softs qui lui demande à ce que je comprends.
Voir aussi le forum de GSS ici https://gss.groups.io/g/main/topics
Et la doc ici https://greenswamp.org/?page_id=1185

[Phil49]

Tu as de l'info de Rob Morgan lui même ici, le créateur de GSS ou l'ensemble de ses vidéos ici https://greenswamp.org/?page_id=790

Merci, mais je les ai déjà toutes visualisées, j'ai d'ailleurs bien été obligé pour comprendre d'où venait mon souci !

C'est d'ailleurs là que j'ai récupéré le lien de la vidéo de Cuiv The Lazy geek si tu as fais attention dans un de mes précédents posts !

J'ai ensuite lu une bonne partie de la doc en ligne et trouvé d'ailleurs d'autres points qu'il faudra que je creuse plus tard.

Mais où c'est un peu compliqué, c'est de bien maîtriser l'interaction "tripartite" entre NINA, PHD2 et GSSertver et les valeurs à positionner pour que cela soit cohérent !

N'oubliez pas les gars que je débute avec NINA et surtout GSSserver !

Je n'ai que deux pauvres petites soirées courtes au compteur...

Mais je ne demande qu'à apprendre !

Pour le forum, je vais creuser aussi, pas encore eu le temps de voir ce qui se disait, je le reconnais !

Philippe

[Phil49]

Bonjour à tous,

Bon, j'ai été poster sur le forum de GSServer et j'ai exposé ma situation.

Robert Morgan (le développeur je crois) m'a confirmé que sur NINA, PHD2 et GSServer mes paramétrages étaient cohérents.

Surtout, il me confirme que le fait de cocher dans PHD2 l'option "Inverser la sortie DEC après le retournement de méridien" est bien la bonne pratique (dans mon cas, au moins).

Philippe

[Lavinch31]

Dans ce cas c'est que la monture ne rafraîchie pas l'info side of pier après le meridan flip . ( tu pourras le vérifier dans les log phd à l'occasion).. rien d'anormal en soit cela dépend des montures.

[Phil49]

Dans ce cas c'est que la monture ne rafraîchie pas l'info side of pier après le meridan flip . ( tu pourras le vérifier dans les log phd à l'occasion).. rien d'anormal en soit cela dépend des montures.

.. ce qui ne veut pas dire que ta remarque n'est pas pertinente !

On voit bien aussi en bas de GSServer dans la barre d'état qu'il sait récupérer la valeur !

Ce n'est pas mon installation GSServer, mais une image trouvée sur le Net pour illustrer mon propos :

image.png

A voir en effet pour PHD2...

Philippe

[clouzot]

Dans ce cas c'est que la monture ne rafraîchie pas l'info side of pier après le meridan flip . ( tu pourras le vérifier dans les log phd à l'occasion).. rien d'anormal en soit cela dépend des montures.

.. ce qui ne veut pas dire que ta remarque n'est pas pertinente !

On voit bien aussi en bas de GSServer dans la barre d'état qu'il sait récupérer la valeur !

Ce n'est pas mon installation GSServer, mais une image trouvée sur le Net pour illustrer mon propos :

Mais... personne ne dit que GSS ne savait pas récupérer cette donnée de Side of Pier. C'est bien le cas. Mais encore faut-il que l'électronique de la monture sache la donner correctement. C'est ce que dira le log PHD2, justement.

[Phil49]

Mais... personne ne dit que GSS ne savait pas récupérer cette donnée de Side of Pier. C'est bien le cas. Mais encore faut-il que l'électronique de la monture sache la donner correctement. C'est ce que dira le log PHD2, justement.

En fait le fichier de PHD2 avait été généré le 18 Juin dernier quand j'ai fait ma dernière observation !

Je l'avais mis avec les photos !

Voici le lien :

-

Pas eu le temps de l'analyser je viens de reprendre le boulot !

Philippe