Aller au contenu

Messages recommandés

Posté (modifié)

Bonjour, je tente un nouveau setup d'autoguidage qui me permettrait de rester au chaud avec mon ordinateur.

L'idée est la suivante :

Ordinateur qui fait fonctionner Kstars et Ekos avec principalement le plate solving, le goto et l'autoguidage <--Wifi--> une vielle Raspberry du fond d'un tirroir qui fait tourner l'indiserver et les drivers d'équipements <--Cables--> les équipements.

 

Le setup est fonctionnel et tout roule SAUF pour l'auroguidage, je n'ai pas eu le temps de le tester en condition réelle au vue de la météo en ce moment, MAIS quand je clique sur le bouton "capture" de l'onglet autoguidage, l'image met entre 5 et 10 secondes (pour une pose d'une seconde) pour arriver dans l'apperçu...

Comme je tente de guider avec un IMX178 de 6,4M pixel, et que je vois que certains guiders sont dans les 1~2 M pixels, est-ce que vous pensez que la différence serait significative ?

 

Je me suis donc mis à parcourir le net pour savoir quelle fréquence de correction de la position est souhaitable lors d'un autoguidage. Et j'ai trouvé tout et son contraire ! Donc je me suis dis que j'allais démarrer une discussion ici pour avoir vos avis sur la question.

 

PS: je sais qu'une Rasp Pi4 avec Ekos, Kstars et VNC résoudrait mon soucis, donc ce n'est pas la question.

Modifié par Oniros
  • Oniros changed the title to Autoguidage, quelle fréquence de correction de la position est souhaitable ?
Posté

Salut, 

 

Il y a 9 heures, Oniros a dit :

, MAIS quand je clique sur le bouton "capture" de l'onglet autoguidage, l'image met entre 5 et 10 secondes (pour une pose d'une seconde) pour arriver dans l'apperçu...

C’est simplement la capture qui met le temps à s’afficher ? 
L’autoguidage se rafraîchit quand même toute les secondes sans prendre en compte le transfert de la capture ? Si oui pas de soucis

 

Pour ce qui est du temps de pose en guidage, ça dépend beaucoup du ciel et du matos, difficile de donner une réponse comme ça. Généralement les bonnes valeurs tournent autour de 2 à 5 sec. A 1 sec on dit parfois que l’on guide sur la turbu, à 5/6 secondes, selon tes valeurs d’échantillonnage, ça risque de filet avant que le guidage ne s’active 

Posté (modifié)

Merci pour ton retour.

Alors si j'ai bien compris le guider interne de kstars tourne sur mon pc et donc il est dépendant du transfert de l'image.

 

Oui c'est ça, pour le guidage j'ai un EQ6-R bien réglée, pour peu que je fasse l'étape de correction de l'alignement polaire, j'ai déjà des graphes de guidage plutôt lisses. Je fais déjà des expositions de 20-30 secondes sans trop agrandir mes étoiles. Donc une fréquence de 1 seconde n'est pas nécessaire, voir délétère même si je commence à essayer de compenser les turbulences comme tu dis. 

Le soucis c'est que même si je fais des expositions de 4-5 sec pour lisser les turbulences et qu'elles mettent 8 sec pour arriver au logiciel qui prend la décision de guider, ça fait que l'ordre arrive à la monture potentiellement pendant la capture suivante ... Je ne sais pas si ça va pas être explosif ça comme boucle :(

PS: j'ai trouvé un astram sur un forum anglais qui a tenté le coup et visiblement le guider interne de Ekos est suffisamment malin pour détecter ça et refuse de guider. Ca ne règle pas mon soucis mais ça me rassure quant au risque de voir ma monture diverger ^^

 

En faisant d'autres recherches j'ai découvert que pas mal de monde faisait tourner juste phd2 sur la raspberry pour avoir un guidage plus réactif. Et une fois phd2 lancé et configuré, il peut être piloté par kstars. Je vais essayer de voir ce que ça donne. 

 

Modifié par Oniros
Posté
Le 28/11/2021 à 22:45, Oniros a dit :

"capture" de l'onglet autoguidage, l'image met entre 5 et 10 secondes (pour une pose d'une seconde) pour arriver dans l'apperçu...

Comme je tente de guider avec un IMX178 de 6,4M pixel, et que je vois que certains guiders sont dans les 1~2 M pixels, est-ce que vous pensez que la différence serait significative

 

normal, c'est en USB2, c'est très lent, mais pas grave

 

même chose avec PHD2

- passe en USB3 si tu peux, c'est 15x plus rapide

- les images suivantes arrivent beaucoup plus vite

- utilise le bin 2 si tu as un peu de focale, ça fait 4x moins de données à transférer

- utilise le fenêtrage si vraiment embêté

Posté (modifié)

Oui c'est vrai qu'USB2 c'est pas le top mais ça m'embête d'acheter un Rasp Pi4 juste pour ça.

 

Le 01/12/2021 à 03:31, olivdeso a dit :

- les images suivantes arrivent beaucoup plus vite

---> Ok ça je vais le vérifier quand le ciel se sera enfin dégagé :D 

 

- utilise le bin 2 si tu as un peu de focale, ça fait 4x moins de données à transférer

---> J'ai une lunette de 840mm de focal avec un capteur qui a des pixels de 4.3µm et pour guider j'utilise un finder de 90mm avec un capteur qui a des pixels de 2.4 µm donc je suis déjà à un rapport de 5 (2.4 x 840) / (4.3 x 90) donc je ne peux pas trop pousser plus. Par contre si je prend un petit réfracteur 80/400 je serais à 1.17 et là je pourrais passer en bin 2 pour redescendre à 2.30 ...

 

- utilise le fenêtrage si vraiment embêté

---> ça c'est un très bonne idée, je n'y avais pas pensé. Pour peu que je trouve une étoile de guidage bien centrée. Comme je guide au chercheur je ne peux pas trop jouer sur la position mais avec une lunette de guidage sur double bague je dois pouvoir jouer sur les vis pour centrer l'étoile et fenêtrer par la suite ?

 

Après dans mon setup, l'intérêt d'utiliser PHD2 c'est qu'il tourne en local sur la rasp contrairement au guider de KStars qui tourne sur mon PC je penses. Donc ça réduirait la latence en enlevant le temps de transit sur le réseau.

 

En tout cas j'ai plein de pistes ! merci beaucoup, j'attends que le brouillard se lève pour tester tout ça.

Modifié par Oniros
Posté

As-tu essayé de tout faire tourner sur le RPI3 ? Kstars ne consomme pas beaucoup de mémoire, même si 2Go, comme sur la TinkerBoard, amène un surplus de confort.

 

Ne serait-ce que pour te convaincre de franchir le pas vers un RPI4 2Go minimum.

 

C'est la configuration que j'utilise en standard. Un RPI4, un boîtier d'alimentation DIY, sur le tube de la ED80, et Kstars-Ekos en chef d'orchestre. Je mets en route et au dodo!

Rejoignez la conversation !

Vous pouvez répondre maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous pour poster avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.