Discret68

C'est bon car pour 1 tour de molette avec 12mm de course, le moteur fait 4000 pas, soit une résolution de 12/4000 = 3 microns par pas. Tu es bien en deçà des 12 microns recommandés ! Donc, pas de soucis à priori. Le moteur est un 48 pas, car vu qu'il fait 4000 pas/tour avec une réduction de 83,33333, ça fait 4000/83,3333 = 48 ! Il faut également que tu prennes de quoi fixer le moteur ainsi qu'un accouplement élastique au diamètre de l'axe de ton focuser. Et si nécessaire, une alimentation 12V. On verra après pour les réglages de NINA.

Appelles plutôt le Vatican Blague à part, le type de moteur PAP dépend de ton focuser actuel. Pour que la focalisation automatique puisse se faire (avec NINA ou autre logiciel), il faut respecter certaines conditions, notamment la résolution du moteur PAP. Selon ton instrument, il se peut (c'est probable) qu'il faille un moteur PAP avec une réduction. Pour faire "assez simple", il faut déterminer ce qu'on appelle la CFZ( Critical Focus Zone) qui se calcule en prenant la formule simplifiée suivante : rapport f/d de ton tube au carré que multiplie 2,4. Cette CFZ est donnée en microns. Exemple : un tube dont le rapport F/d est de 5 présente une CFZ de 52 x 2,4 soit 60 microns. Pour faire une MAP auto, une première condition est d'avoir une résolution de la motorisation/réduction te permettant de l'ordre du cinquième de la CFZ, soit 60/5 soit 12 microns. En conséquence, il faut arriver à ce qu'1 pas moteur déplace ton train optique au plus d'environ 12 microns. Si le déplacement est inférieur, aucun soucis. A titre de comparaison, mon focuser a une résolution de 0,053 microns par pas. C'est très précis, mais ça sert pas à grand chose si ce n'est à prendre du temps pour tout déplacement. Il faut également connaitre la valeur de déplacement de ton focuser. Pour 1 tour de molette, quel est le déplacement du focuser. Après, on peut déterminer le type de moteur à utiliser afin d'obtenir le meilleur fonctionnement possible. Un moteur pas à pas standard a généralement une résolution de 200 pas par tour. Il est possible de faire tourner un moteur PAP en utilisant des micro-pas, ce qui permet d'augmenter la résolution. en utilisant un moteur PAP en 16ème de pas, on obtient une résolution de 3200 pas par tour, mais ça peut ne pas être suffisant. Il existe également des moteurs PAP à résolution moindre mais équipés d'uu réducteur. Par exemple, un focusCube V2 de chez Pegasus présente 5760 pas par tour. Soit dit en passant, le boitier de PA auquel tu ajoutes tous les accessoires présente un tarif qui s'approche d'un FocusCube V2 (288€). A réfléchir ! Si tu nous décris ton système, on pourra mieux te conseiller.

Ben voilà, on y voit un peu plus clair ! Dans la notice de ce boitier, on peut lire ceci : De cette phrase, on peut donc en déduire qu'il est possible d'utiliser ce type de boitier avec un moteur à courant continu et avec NINA. Par contre, à mon avis, avec un moteur CC, ce système ne peut pas être fiable. Avec un moteur pas à pas, on peut savoir en permanence à quelle position se trouve le moteur, pour peu qu'il n'y ai pas de saut de pas (exemple : lorsque le couple demandé supérieur au couple possible du moteur). Dans le pilotage d'un moteur PAP, on envoie généralement un nombre d'impulsion pour avoir une rotation. A un nombre d'impulsion donné correspond une rotation donnée. Tant qu'on respecte les caractéristiques du moteur, on est sûr à plus de 99% de la reproductibilité de la position. Pour se prémunir des éventuels sauts de pas, certains moteurs PAP embarque un codeur qui permet de confirmer la bonne rotation voulue. Avec un moteur CC, la vitesse dépend de la tension d'alimentation. La moindre variation de tension se traduit par une variation de vitesse et au bout d'un laps de temps, le nombre de tours réalisés n'est pas le même et la position différente. la vitesse de rotation est également influencée par la variation de couple que le moteur doit fournir. Selon la portion du ciel visée, le poids du train optique va engendrer un effort variable et donc un couple variable. C'est un peu la problématique générale des moteurs CC On peut définir une pseudo-résolution du moteur CC par logiciel, mais cela ne me parait pas fiable. Dans la pratique, pour l'utilisation d'un moteur CC associé au besoin d'une précision de position, on utilise un codeur ou un générateur d'impulsion en bout d'arbre. Compter les impulsions permet de piloter le moteur d'une manière fiable. C'est une boucle de retour. Bref, j'aurais tendance à déconseiller l'utilisation d'un moteur CC avec ce type de boitier pour faire de la MAP auto avec un logiciel. A contrario, ce type de motorisation est tout à fait utilisable sans problème en visuel puisque c'est l’œil qui assure la boucle de retour. A mon sens, si tu ne veux pas être embêté, prend plutôt un moteur PAP pour avoir un système fiable. Tu peux appeler Pierro-Astro pour en avoir le cœur net.

C'est clair comme du jus de chique ta réponse ! C'est quoi un moteur normal vu de chez toi ? Comme si il existait des moteurs anormaux !!

Qu'entends tu par "simuler un moteur PAP" ? Dans quel but ? Ce boitier est justement fait pour connecter un moteur CC ou PAP afin de faire de la focalisation pilotée par un logiciel (NINA ou autre).

OK. Faudra que je me jette à l'eau. La programmation sur Arduino ne me pose pas de réel problème. Il faut juste que je comprenne le mode de construction du driver. Il y a de l'aide en ligne, ça devrait le faire 😉

Par hasard, tu n'aurais pas développé un driver ASCOM ? Car c'est la prochaine étape en ce qui me concerne. Je peux piloter le rotateur à distance, mais l'intérêt ultime est de pouvoir l'utiliser avec NINA en positionnement par astrométrie. Pour le rotateur 2", vu qu'il y a juste un porte-filtre et une ASI2600, le corps et le couvercle seront en impression 3D. Pour le 3", le train optique étant relativement lourd (correcteur 3", RAF, et ASI2400MC), il faut une mécanique rigide.

Non, aucun port n'apparait à aucun moment dans l'IDE Arduino. De toute façon, à la relecture de la documentation, on trouve cette info (traduite) "Même si Trinket a un connecteur USB, il n'a pas de capacité "console série", vous ne pouvez donc pas utiliser série pour envoyer et recevoir des données vers/depuis un ordinateur ! Il n'apparaîtra pas en tant que PORT dans le menu de configuration" En conséquence, cette carte ne peut être utilisée pour un pilotage des actions par un PC. Je pense qu'on peut y charger un programme (quand on y arrive) qui doit être autonome et sans retour vers un ordi. Exit de la course ! J'ai vu effectivement, je vais en commander un exemplaire pour tester. Vu toutes les particularités des différentes cartes, ça risque d'être un long périple pour trouver un remplaçant de taille réduite de l'Arduino Nano. J'en ai trouvé, mais pas dont les dimensions sont réduites par rapport à l'Arduino Nano. Dans l'expectative, j'ai légèrement augmenté la taille du boitier du rotateur 2" de manière à loger l'Arduino Nano. Pour le 3", vu que l'ensemble est pratiquement terminé, il va falloir que je patiente pour trouver une carte plus petite ou que je ruse. J'ai toujours la possibilité de mettre un petit boitier externe pour y loger l'Arduino Nano, mais si je peux éviter, j'aimerais autant. Juste pour le fun, une petite photo de la partie mécanique du rotateur 3" (anodisation à venir) à 2 roulement à billes, sans et avec le capot imprimé 3D : Et la partie mécanique (fixe et tournante) du rotateur 2" qui utilise un roulement unique à double rangée de rouleaux croisés, réputé sans jeu :

Je pense que c'est ça qui ne va pas pour le moment. Sur le guide d'installation ( https://learn.adafruit.com/introducing-trinket/starting-the-bootloader ), les liens fournis mènent à pas grand chose de téléchargeable. Et je ne sais pas où aller pour charger ce fameux bootloader pour une carte avec USB. J'ai trouvé de nombreux sites qui décrivent la façon de faire quand on a juste le circuit intégré, mais pour une carte avec puce soudée, je cherche encore .....

OK pour faire fonctionner un ATtiny en autonome, mais pour le faire dialoguer avec un PC en permanence, il faut bien un interface USB ! Et là, je ne vois pas ce qui est nécessaire.

Bon, ben y’a plus qu’à😉

Salut Manu. Ce module ne transite pas par un port COM, il est géré directement par l'USB en tant qu'interface USB et pas comme un port COM comme pour les autres modules. Dans ce tuto sur l'utilisation de ce module ( https://learn.adafruit.com/introducing-trinket/setting-up-with-arduino-ide ), il est bien précisé qu'il n'y a pas utilisation de port COM. Je sélectionne la carte Adafruit Trinket (ATtiny85 @ 8MHz)et le programmeur USBtinyISP, mais j'ai mon message d'erreur. Dans le sélecteur de carte, il n'y a effectivement aucun port COM listé. Dans le gestionnaire de périphériques de Windows, on le trouve bien dans la liste des périphériques, mais pas dans les ports COM :

Bonjour à tous les bricoleurs sur Arduino. Dans le cadre de la conception/fabrication de rotateurs (2" et 3") pilotés par un Arduino, vu que pour piloter un unique moteur pas à pas via un driver (DRV8825 ou TMC2208), 3 sorties numériques sont nécessaires (Enable, Step et Dir), un Arduino, même Nano présente une profusion de sorties parfaitement inutiles pour un unique moteur PAP. L'utilisation en mode micro-pas pilotés n'est pas indispensable. la sélection peut se faire une fois pour toute au niveau du driver en fonction de la vitesse de rotation souhaitée. De plus, même si l'Arduino Nano est de petite taille, il est encore un peu grand par rapport au volume disponible. Certes, je peux augmenter la taille du système, mais si je peux faire avec plus petit, j'aimerais autant. J'ai commencé par tester le programme de pilotage de mes rotateurs sur un Arduino Nano. Pour le moment, je pilote la rotation du système via un programme développé en VB.net. A termes, j'envisage également de basculer sur un driver ASCOM que je dois développer, après apprentissage de la chose ! Bref, la programmation fonctionne et le premier des 2 rotateurs construit..... tourne quand on lui demande. J'ai fait quelques recherches sur le Net pour trouver plus petit que l'Arduino Nano et qui soit compatible avec l'IDE Arduino. L'objectif étant de pouvoir déverser mon programme Arduino dans un module plus petit en limitant le nombre de modifications du programme. J'ai trouvé la carte Beetle RP2040 DFR0959 ( https://www.gotronic.fr/art-carte-beetle-rp2040-dfr0959-35875.htm ) qui propose 8 E/S. L'installation des drivers a été effectuée sans problème. La connexion et le téléversement du programme se réalisent sans soucis. Je pilote le driver et le rotateur tourne comme il se doit. Le seul point noir auquel je n'avais pas fait attention est que ce module ne contient pas d'EEPROM. Vu que je stocke la position du rotateur lors de la déconnexion du système pour la retrouver à la connexion suivante, dans ce cas, aucune position n'est mémorisée. On oublie donc ce module pour le moment ! J'ai pris un autre module, le Trinket 5V ADA1501 ( https://www.gotronic.fr/art-module-trinket-5v-ada1501-21898.htm ) qui est compatible IDE Arduino (sur le papier), qui comporte une EEPROM qui me permettrait de stocker mes données hors tension. De plus, il occupe la moitié de surface d'un Arduino Nano. J'ai suivi la procédure d'installation et pour le moment, impossible de téléverser le moindre octet ! J'ai un message d'erreur qui me dit "A programmer is required to upload". J'ai essayé plusieurs programmeurs dont l'USBtinyISP, mais rien n'y fait. Sur ce module, il y a 2 choses qui m'intriguent au niveau de l'installation. C'est le fait qu'il n'y ai pas de numéro de port COM, mais ça, c'est normal, et également une histoire de bootloader que je pense ne pas avoir compris. Si quelqu'un a déjà mis en œuvre ce module pour m'aider à le faire fonctionner, je lui en serai reconnaissant. JP

Je ne vais pas pouvoir t'aider pour le moment, mais comme j'ai également besoin de développer un driver ASCOM pour 2 rotateurs et 1 focuser pilotés par Arduino, je vais lancer l'installation des outils et voir ce que ça donne ! On verra si ça se passe mieux (ou pas) chez moi.

Que veux tu dire par "en me battant avec le plate solve" ? De quoi est constitué ton équipement (monture, tube, caméra, ...) ?

Par rapport au tableau donné sur le site Astap, j'ai fait quelques essais cette nuit en astrométrie avec une caméra doté d'un "petit" capteur, alias la Neptune C-II. J'ai monté la caméra (sans barlow) sur mon newton de 300 à 1200 de focale. Cette caméra ayant une résolution de 2712 x 1538 et des photosites de 2,9 microns, l'échantillonnage résultant est de 0,5", et le champ couvert de 0,38° x 0,21°. D'après le tableau, le temps de pose "typique" doit être d'environ 50 sec. C'est la base de données H18 qui est installée. J'ai réglé le gain de la caméra à 300 et le temps de pose à 4 sec. Les essais ont été réalisés en différents points de la voute céleste. Avec ASTAP, la résolution s'effectue très rapidement (de l'ordre de 2 sec) dans 100% des cas, il y a juste un message d'alerte (jaune) qui précise que l'image est trop petite. Mais la résolution est effective et juste. J'ai également testé Platesolve 2. Idem, réussite 100% et aucun message d'alerte. La résolution s'effectue également en 2 sec. J'attends une barlow variable 2x à 3x. Je renouvellerai les tests pour essayer de trouver les limites. @pyrou61 : Tu devrais peut-être essayer avec Platesolve 2 avec ta config pour voir si la résolution s'effectue, au cas où ce soit plus probant.

J’ai l’impression que le diamètre intérieur de ta bague est lisse. Une pratique courante est de réaliser un filetage de manière à créer un bafflage pour éviter les reflets. Pas de cote particulière à respecter, c’est juste pour éliminer la paroi lisse. Il existe également une peinture qui est présentée comme la plus noire au monde : la musou black : https://blackblack1.com/

A titre d'exemple, tu peux parcourir la page de mon site où il y a encore le premier schéma de pilotage de l'abri, à base d'un IPX : http://astrowick.fr/index.php/observatoire/informatisation Tu devrais trouver des réponses à tes questions. Les contacteurs magnétiques sont généralement des ILS (interrupteur à lames souples). Ils fournissent un contact dit "sec", comme un bouton poussoir. Un IPX comportant des entrées digitales, il suffit de raccorder un des 2 fils de l'ILS à la masse du système et le 2ème à l'entrée digitale. Les capteurs qu'on utilise par exemple dans les systèmes d'alarme vont très bien. Exemple : https://www.amazon.fr/Capteurs-SÉCuritÉ-Domestique-Interrupteur-MagnÉTique/dp/B084ZLL55Q/ref=sr_1_6?__mk_fr_FR=ÅMÅŽÕÑ&crid=1YLWSZPM3JNPF&keywords=capteur+ils&qid=1667232072&qu=eyJxc2MiOiIyLjEyIiwicXNhIjoiMi4wOSIsInFzcCI6IjEuMDUifQ%3D%3D&sprefix=capteur+ils%2Caps%2C253&sr=8-6 On trouve ces capteurs avec des contacts qui peuvent être NO (Normalement Ouvert - Le contact s'établit lorsque l'aimant est devant), NF (Normalement Fermé - le contact est permanent et s'ouvre lorsque l'aimant est devant). Certains capteurs ont les 2 contacts, comme ça, il est possible de changer le mode de fonctionnement selon le besoin. Pour l'IPX V4, tu peux télécharger la notice pour te rendre compte de toutes les possibilités disponibles : https://www.gce-electronics.com/fr/carte-relais-ethernet-module-rail-din/1483-domotique-ethernet-webserver-ipx800-v4-3760309690001.html La doc se trouve dans l'onglet "DOCUMENTS JOINTS". Les entrées analogiques sont pratiques également. Par exemple, il est possible d'avoir un suivi des différentes tensions dans l'abri. A titre d'exemple, pour un copain qui a une coupole souple qui s'ouvre comme une Clamshell, j'avais fixé un potentiomètre sur l'axe de rotation qui délivrait une tension variable en fonction de l'angle d'ouverture. Moyennant une conversion tension/angle, il était possible de suivre l'ouverture et d'arrêter l'ouverture à un angle désiré. L'IPX est vraiment un super boitier de pilotage, pas bon marché, mais vu tout ce qu'il est possible de faire avec, c'est un très bon produit.

Pour la pluie, effectivement, ce n'est pas bon. Mais avec le (par exemple) CloudWatcher Lunatico, tu peux définir les conditions sur 3 à 4 critères (luminosité, nuages,pluie et vent si tu as le capteur externe) que tu considères comme étant bonnes ou pas pour activer le matériel. A partir de là, tu peux largement anticiper le repli des équipements avant la pluie 😎

Argument complémentaire qui milite pour l'installation d'un mini-PC plutôt qu'un portable. Un écran portable a une résolution maxi qui est limitée par la taille de l'écran. Avec un mini PC piloté à distance, il est possible de choisir une résolution plus importante, voire comme je l'ai fait de se créer une résolution adaptée à l'écran de l'ordi de pilotage. Pour ce faire, on connecte un "dummy" (HDMI ou displayport selon la sortie vidéo) sur le connecteur de sortie vidéo du mini PC. Il est ainsi possible de créer une résolution pouvant aller jusqu'au 4K. Il est nécessaire qu'aucun écran ne soit raccordé au mini PC. Le dummy est en fait un leurre. Sur mon iMac 27" qui présente une résolution de 2560 x 1440, j'affiche les écrans de mes mini PC avec une résolution de 2520 x 1320, ce qui permet d'y visualiser beaucoup plus de chose que ce qu'un écran de portable permet d'afficher. Lorsqu'on est sur place, il est tout a fait possible de brancher un écran standard qui permet de visualiser ce qu'on fait. La résolution bascule automatiquement à la résolution par défaut de l'écran. Un dummy coûte environ une dizaine d'euros.

Selon ce qu'on cherche à voir avec l'OCAL (primaire, secondaire, ...) , il faut modifier la luminosité, le contraste et la mise au point. On ne peut manifestement pas tout régler avec un unique réglage des paramètres que j'évoque.

C'est ce que j'avais à l'origine, avec un boitier de 8 relais supplémentaires (X880). Ça fonctionne effectivement très bien et j'en ai été très satisfait. Un des intérêts de ce système est que les relais conservent leur position en cas de coupure de courant. Ainsi, lorsque la tension revient, pas de risque de voir des actions intempestives au niveau du setup. L'intérêt de l'IPX est qu'on peut le piloter (activer/désactiver les relais) via des scripts VBS. Il est ainsi possible de lancer des actions automatiquement durant certaines phases de la séquence d'acquisition. Nina permet de lancer des scripts à n'importe quel moment de la séquence. Par exemple, il est tout à fait possible d'allumer automatiquement un panneau flat en fin de séquence pour lancer une série de flats, puis d'éteindre le panneau flat. En phase finale, on peut couper automatiquement les différentes alimentations. Bien qu'inutilisés actuellement, je conserve mes 2 modules IPX qui seront remis assurément en service le jour où je partirai sur un remote longue distance. Vu que Valdetahiti compte installer son setup dans un "hébergement collectif", la protection vis-à-vis des dégradations de la météo est gérée par l'hébergeur. Pour ce qui est de la validation de la position park de la monture, il est en de même dans un collectif. Je pense que la fermeture du toit est indépendante de la position des setup. je vois mal le système attendre que tous les setup soient en position park pour fermer le toit. Il y en a toujours un qui n'aura pas replié son setup. J'imagine que le setup doit être calé en hauteur sur son pilier de manière à ce que le toit puisse se fermer lorsque le setup présente la hauteur la plus importante. D'un autre coté, ça augmente l'angle mini de visée au dessus de l'horizon. A contrario, en individuel, c'est absolument indispensable. Il faut une protection indépendante du pilotage du setup. Je pourrais interroger informatiquement ma monture pour avoir la confirmation qu'elle est bien en position park, mais je voulais un système de protection totalement indépendant. De mon coté, j'utilise un capteur fixe dans l'abri avec un réflecteur (système utilisé pour les portails) qui est positionné sur la queue d'aronde du télescope de telle manière qu'il n'y ai qu'une seule position où l'alignement capteur/réflecteur est assuré. Tout mouvement du toit est impossible. J'ai juste ajouté un bouton poussoir sur le coffret dans l'abri pour by-passer le capteur de position de manière à pouvoir manœuvrer le toit même si le tube n'est pas en position park. Mais vu que c'est un poussoir, je suis obligatoirement à coté et je vois ce qui se passe. Le bouton poussoir, contrairement à interrupteur, n'engendre pas le risque d'oublier de le remettre dans la bonne position. Tout à fait. Il n'y a rien de pire que de trouver à piloter un setup en remote et en aveugle.

Petites précisions complémentaires : certains équipements sont sous tension en permanence. Les relais par lesquels leur alimentation transite ne servent qu’à couper la tension pendant une courte durée de manière à permettre un redémarrage. Dans le coffret de gestion de l’abri, il y a encore un petit mini-PC qui me permet de tracer les courbes liées aux conditions météo (je me débrouille mieux en VBS.net qu’en python sur RPI) ainsi que la gestion du cloudwatcher. Toutes ces infos sont envoyés en permanence sur le serveur qui héberge mon site internet. Les différents micros (le PC acquisition, le PC météo, le RPI qui gère la allsky et les capteurs de température / hygrométrie / pression atmo et le RPI qui gère les résistances de désembuage des setup) sont pilotés à l’aide de RealVNC à partir de mn iMac. Comme quoi, on arrive à faire cohabiter des mondes différents 😀

Salut Mon abri est entièrement exploité en remote depuis la maison. Avant de présenter succinctement mon installation, quelques éléments concernant les questions que tu te poses. Concernant l'onduleur, l'alimentation fournie n'est-elle pas déjà sur onduleur. C'est le cas pour de nombreux sites. le fournisseur met en place ce type d'alimentation pour protéger l'ensemble des setup. Pour la mise en service du PC, tu as effectivement le WOL, mais ce n'est pas toujours facile à mettre en œuvre. Il faut voir si le bios de l'ordi permet de le faire. Sur certains PC (tour et mini PC, il y a parfois un connecteur sur la carte qui permet la mise en route et le reset en mettant 2 pins en contact. les contacts d'un relais permettent d'établir la connexion entre les 2 pins. On peut aussi se connecter en parallèle du bouton poussoir de mise en route. On établit le contact entre les 2 fils et l'ordi démarre. En cas de reset nécessaire parce que le menu Windows ne fonctionne pas, il suffit de maintenir le contact durant plusieurs secondes. Concernant mon abri en remote, mon schéma actuel pourrait être considéré comme une usine à gaz, mais je fais tout un tas de chose suite au retour d'expérience de mon premier schéma. Il est clair que si tu es dans un abri groupé, il y a un certain nombre de fonctions que tu n'as pas à assurer. Mon schéma actuel : La partie à gauche du trait vertical en pointillés concerne la gestion de l'abri, gestion que tu n'as pas à priori à assurer, sauf peut-être quelques fonctions (les alimentations de tes équipements, le panneau flat, ..) La partie de droite se trouve physiquement fixée sur le newton, l'objectif est de gérer tous les équipements d'acquisitions. Rapidement : il y a un mini PC (globalement préférable à mon sens à un portable) sur lequel sont connectés directement tous les accessoires astro. Pas de hub et des fils qui sont courts. Une box avec un RPI (JPBox1) et une petite carte relais me permet de gérer les résistances de désembuage des différents setup. Une box contenant une carte à 8 relais se charge de l'alimentation des différents setup (caméras, focuser, ventilateur, ...) ainsi que la manœuvre des obturateurs. Un hub Ethernet permet de distribuer la connexion car tous les différentes box et ordi sont pilotés en Ethernet. Cette approche est bien sûr à adapter en fonction des constituants du (ou des) setup(s).

Oui, mais il faut le taraud spécifique et les hélicoïls ! C'est très pratique quand on est un pro, mais au stade amateur, rares sont ceux qui en dispose. On voit sur la photo que la tige filetée ne sort pas beaucoup de la partie mobile de la queue d'aronde. Très peu de filets du bouton en alu subissent la contrainte et avec un serrage "musclé", associé à la faible résistance de l'alu, les filets lâchent.