Discret68

J'ai fait un premier essai consistant à débrancher la caméra en laissant le RPI en service. Après reconnexion de la caméra sur un autre port USB, le logiciel Allsky reprend bien l'édition des images. Pour le deuxième essai, j'ai arrêté le RPI, puis coupé l'alimentation. La caméra a été placée sur un autre port USB et redémarrage de l'ensemble. Tout fonctionne sans problème et on voit bien le changement de port USB : Je pense effectivement que les différentes mises à jour qui ont été effectuées depuis l'apparition du problème initial ont dû certainement corriger quelque chose. Je vais aller démonter l'ASI120MM qui est dans la allsky pour voir comment le système réagit. Et je verrai bien si un flashage est nécessaire. De toute façon, il était prévu de remplacer la 120 par la 224. Après plus de 6 ans dans la allsky avec un capteur qui monte à plus de 55° à certains moments, je finis par avoir de nombreux pixels chauds avec des pause de 30s. Mais force est de constater que l'électronique (y compris le capteur) de cette caméra tient bien le choc dans le temps. Je ne pensais pas que cette caméra tiendrait aussi longtemps.

Bonjour à tous Cela fait quelques années que j'utilise une caméra allsky en exploitant le logiciel de Thomas Jacquin à l'aide d'une ASI120MM connecté sur un Raspberry Pi. Jusqu'à présent, aucun soucis de fonctionnement. Vu que ça faisait au moins 3 ou 4 ans que je n'avais pas réalisé de mise à jour, je me suis lancé dans une mise à jour global, à la fois du système d'exploitation et du logiciel Allsky de Thomas Jacquin. A l'issue des mises à jour, j'ai relancé le système et ..... plus rien. Aucune image sur le moniteur du RPI. Même pas l'écran de démarrage. Pensant que cela pouvait provenir d'un mauvais déroulement de la mise à jour des logiciels, j'ai ré-installé l'ensemble (système et logiciel Allsky) sur une nouvelle carte mémoire. Toujours rien. Pas de finalisation du boot au démarrage. Je ne liste pas dans le détails tous les essais que j'ai réalisé, mais j'en ai fait un paquet ; changement d'alimentation (jusqu'à 6A disponibles), des cordons, de la caméra (j'ai mis une ASI224MC), ...., rien de probant. Pas de finalisation du démarrage du RPI et de fait, pas de bureau accessible. Jusqu’au moment où l'idée m'est venue de ne pas laisser la caméra connectée au RPI lors du démarrage. Et là, le RPI démarre sans problème ! Si je connecte ensuite la caméra, la allsky fonctionne. En fait, c'est le fait d'avoir la caméra connectée au démarrage du RPI qui bloque le boot. Et si je redémarre le RPI avec la caméra connectée, retour à la case départ, pas de démarrage du RPI. J'ai contacté Thomas Jacquin afin de lui soumettre le problème, mais qui n'a pas d'idée précise sur la problématique et son origine et pas plus sur la correction à apporter. Et là, tout d'un coup, je me sens bien seul Quelqu'un aurait-il déjà rencontré cette problématique et (ou) aurait la géniale médication à apporter pour que je retrouve un fonctionnement "normal" de ma allsky ? Merci à vous JP

Romano aurait-il trouvé la femme idéale .... pour un passionné d’astronomie bien sûr N’empêche que lorsque je lui ai commandé un secondaire plan de 100mm de petit coté, il a insisté pour que je lui paye après réception du colis. Je ne connais pas grand monde qui accepte aujourd’hui d’être payé après livraison.

Beau travail. Sauf erreur de ma part, tu n’as pas publié le schéma de l’électronique. Mais c’est peut-être volontaire. L’emploi des cms n’est pas trop délicat à mettre en œuvre ? Ça doit nécessiter des outils particuliers, notamment pour le soudage.

je ne savais même pas qu'il était possible de flasher le firmware d’une caméra Voila ce que j'obtiens actuellement avec la console. Vu que c'est la 224MC qui est connecté, j'ai modifié la commande : Que peut on déduire de ces données ? A jour ou pas à jour ? Sur le site ZWO, je n'ai pas trouvé grand chose comme article concernant le "flashage" d'une caméra, si ce n'est une archive "Camera Firmware Upgrade Tool" qui semble destinée à cette action. On y trouve bien des fichiers pour les ASI120, 130 et 034, mais rien pour la 224. Et aucune info concernant les références de firmware à jour. Je rappelle qu'au départ, la 224MC ne fonctionnait pas et que tout d'un coup (1 mois après la ré-installation complète), tout est rentré dans l'ordre sans que je ne fasse quoi que ce soit !

Si, mais je ne vois aucun menu ou sous-menu permettant d'intervenir sur le boot.

Salut gordini Je n'ai pas trouvé le moyen de changer l'ordre de boot dans la config du RPI, à l'instar de ce qu'on fait sur un PC. Information que je n'avais pas communiqué est que j'ai une clé USB en permanence sur le RPI, qui me permet de stocker des infos sur la clé plutôt que sur la carte SD. Et avec la clé USB en permanence sur le RPI, ce dernier démarrait sans problème, à condition de déconnecter la caméra. Donc, à priori, pas un problème de boot sur clé. Néanmoins, suite à ta remarque, j'ai regardé sur le net comment modifier le boot du RPI, notamment avec un système sur clé USB. Il faut modifier le fichier "config.txt" qui est sur la carte SD pour y ajouter une ligne permettant de démarrer sur la clé USB. J'ai parcouru le fichier, histoire de voir si une ligne pouvait poser problème, nada, rien de particulier. En fait ce problème s'est posé il y a 2 mois, et pendant 15 jours, j'ai fait des tonnes d'essais qui se sont révélés infructueux, et puis j'ai mis la problématique de coté, en me disant qu'il faudrait bien que je corrige le problème un jour. Débrancher/rebrancher la caméra aux (très rares) redémarrages du RPI, c'est pas une vie Aujourd'hui, j'ai décidé d'essayer de résoudre le problème via le forum, mais sans tester au préalable la configuration démarrage RPI avec caméra connectée. Eh bien, figures toi que maintenant, ça fonctionne ! J'ai fait une dizaine de redémarrage et de séquence arrêt/coupure alimentation/démarrage, et tout fonctionne !! J'avoue ne pas pouvoir expliquer ce qui s'est produit. Est-ce que de nouvelles mises à jour du système ont été de nature à corriger le problème ? Avec l'informatique, on est loin d'un monde "carré".

C'est une monture alt-az. Si je considère que ce type de monture représente l'avenir, aujourd'hui, il est difficile de faire de la photographie longue pose à cause de la rotation de champ. Il faut utiliser un rotateur suffisamment précis qui permet de faire de la dé-rotation en continu. Il en existe plusieurs modèles mais je n'en connais qu'un seul qui soit piloté réellement en tant que dé-rotateur. Il s'agit de l'ARCO de PrimaluceLab, mais à condition d'utiliser leur logiciel d'acquisition PLAY, qui en est plutôt à son début de développement. La rotation de champ étant variable selon la portion de ciel visé, il faut en permanence corriger la vitesse de rotation du dé-rotateur. Hors, à part PLAY, aucun logiciel d'acquisition (NINA, SGP, ...) à ma connaissance ne gère ce genre d'équipement. Mais je ne sais pas tout Par contre, en pose courte, pas de gros problème. Dans ce cas, c'est le logiciel de traitement qui va recaler (effectuer la dé-rotation) l'ensemble des images par astrométrie. Pour réduire l'angle de rotation global, on peut utiliser un rotateur pour recaler l'angle de l'image toutes les X poses. Un autre point qui me semble néanmoins délicat à gérer dans ce mode de fonctionnement est la présence des aigrettes liées aux branches de l'araignée du secondaire d'un télescope qui montrent une rotation sur chaque image. Je ne sais pas trop ce que ça peut engendrer sur l'image finale. Il est clair qu'avec une lunette, la question ne se pose pas.

Tu veux assurer une protection durant les phases d’acquisition ou lorsque le matériel est en repli ? Dans le premier cas, c’est en général pour lutter contre le dépôt de buée. Donc, résistance chauffante pilotée comme le dit Sauveur par une détermination du point de rosée et la mise en service d’une résistance chauffante au niveau de l’objectif. Il existe des systèmes tout prêts dans le commerce ou en montant un système soit même à base d’un micro-contrôleur. Dans mon cas, j’utilise un Raspberry pi avec des capteurs BME280. Je peux sélectionner le tube à protéger ; newton ou lunette. Un Arduino ou ESP86 peut très bien convenir également. Dans le deuxième cas, le mieux est un obturateur, motorisé si tu es en pilotage à distance. L’obturateur peut également embarquer un panneau électroluminescent pour réaliser les flats. Exemple du montage réalisé pour la lulu de 80 en remote avec un obturateur sans écran électroluminescent et un masque de bahtinov, motivé par l'utilisation d'un APN Sony A7S non piloté par ASCOM et donc, focalisation en pilotage manuelle à distance. La version pour le newton présentée en fin de vidéo est également en place : Il est également important de bien laisser circuler l’air pour assurer un bon renouvellement afin d’éviter de taquiner le point de rosée lors des baisses de la température intérieure.

Ayant fait des essais avec une température variant de -5 à -20°, je n'ai pas vu de différence fondamentale. Comme dit plus haut, -10° est un bon compromis avec les Cmos d'aujourd'hui, ce qui permet de refroidir le capteur aussi bien pour des prises du vue en hiver et en été tout en gardant les mêmes séries de darks, bias ou dakflats.

La valeur du back-focus est un point de départ pour la configuration du train optique. Au delà de la valeur théorique, c'est en regardant tes images que tu pourras confirmer la bonne distance, en ajoutant les épaisseurs de cales jusqu'au moment où la coma aura disparu des étoiles en bordures d'image. Pour mémoire, voici un moyen pour déterminer la correction du back-focus à apporter en fonction de la déformation des étoiles : Concernant les rondelles de calage, tu en trouveras en lots de différentes épaisseurs et de diamètres, en plastique ou en métal. Exemple : https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-t2/lot-de-rondelles-m48-de-0,1-0,15-0,2-0,3-0,5-1-1,5-2mm-artesky_detail Il faut bien évidemment choisir le diamètre des rondelles en fonction du diamètre de ton correcteur. JP

Tout dépend du budget disponible ! Dans cette gamme d'exigences, il y a la GM3000 de chez 10Micron. Ces montures sont d'une efficacité redoutable (j'ai une GM2000) avec des encodeurs qui évitent tout système annexe d'autoguidage et dont le pointage est ultra précis. Avec une focale de 1200, des poses de 20mn n'amenaient pas de déformation des étoiles. La qualité globale est en rapport avec le tarif de la monture.

Il n'y a quasiment aucun gain à descendre à cette température. -10°C est suffisant avec cette génération de caméra. Et il y aura également moins de risque de dépôt de rosée dans le boitier. De quel kit parles-tu ? As tu essayé de régénérer les pastilles de dessicant ? Le mode opératoire : https://astronomy-imaging-camera.com/manuals/How_to_clean_ASI_camera_and_redry_the_desiccants_EN_V1.2.pdf

Il n’est pas normal d’avoir de la condensation directement sur le capteur. Cela signifie que tu un taux d’hygrométrie important dans le boîtier de la caméra. A ce stade, il faut régénérer les pastilles de dessicant qui sont dans la caméra. Néanmoins, es tu sûr que la buée n’était pas plutôt sur la face extérieure du hublot ? Quel modèle de caméra as-tu ? Et à quelle température était régulé le capteur ?

Salut Stéphane Super vidéo ! Tu pourrais nous en dire un peu plus sur les conditions de prises de cette vidéo ? Je suppose que ta vidéo est un assemblage de plusieurs images prises à intervalle régulier. Chaque image de base de la vidéo est-elle un cumul de plusieurs images ou ce ne sont que des images unitaires ? Quel laps de temps as-tu entre 2 images sur la vidéo ? D'autant que les étoiles sont parfaitement rondes. Merci à toi JP

J'avais regardé ce logiciel, mais de très loin, en attendant de pouvoir "creuser" le sujet. Mais comme certains ont testé le produit, j'en profite pour poser mes questions de neuneu : Est-ce que ça fonctionne également avec un newton ou uniquement avec des optiques type RC ou SCT ? Est-ce que ce logiciel permet de faire la distinction entre collimation du primaire et celle du secondaire ? La dé-focalisation doit elle être importante pour obtenir des résultats représentatifs ?

Les rênes ont dû avoir chaud aux fesses. joyeuses fêtes à tous

J'ai déjà réfléchi au système, mais je n'en vois pas trop l'intérêt dans le sens où ; si on est à coté du tube, il est facile de tourner les vis de collimation du secondaire, même avec des petits bras. Alors que pour les vis du primaire, si le tube est long, difficile d'avoir simultanément l’œil coté focuser et la main sur les vis de collimation du primaire. Dans mon cas, je voudrais aussi tester la MAP par déplacement du primaire pour supprimer le focuser coté PO. Pour motoriser le secondaire, je vois 2 solutions : soit arriver à miniaturiser la motorisation du secondaire pour qu'elle reste dans l'ombre du miroir et dans ce cas, elle peut être placé au centre de l'araignée, soit j'imagine une cage secondaire indépendante sur laquelle est fixée une araignée standard. Cette cage secondaire est raccordée au tube du télescope par 3 montages avec vis rotatives pour permettre la collimation. Un plan passant par 3 points, ces 3 montages permettent d'orienter le miroir sans générer de contrainte sur les fixations. Pour imager mes propos, il suffit de regarder une chaise à 3 pieds et une chaise à 4 pieds, celle à 4 pieds est rarement stable. Pour disposer 4 systèmes de réglages (1 pour chaque branche d'araignée ) pour garder un tube d'un seul tenant, il faut réfléchir au programme qui permet de conserver l'alignement des 4 points pour conserver un plan. Une solution peut consister à inverser la rotation du moteur de la branche opposée par rapport au moteur de la branche qu'on règle. Les 2 branches perpendiculaires constituent une sorte d'axe de rotation. Principe à appliquer pour chacun des 4 moteurs. On obtient ainsi 2 axes de rotation pour collimater le secondaire. Ce système pourrait avoir un intérêt pour pouvoir faire de la collimation en remote. Par contre, je ne sais pas quel serait la méthode qui permettrait de régler la collimation du train optique complet tout en faisant le distinguo entre primaire et secondaire. Certains logiciels permettent de vérifier la collimation (ex : CCD Inspector) mais pas de distinction de l'analyse sur l'origine du défaut ; primaire ou secondaire.

Bonjour à tous Aujourd’hui, je vous présente une modification que je viens d’effectuer sur mon newton de 300 en f/d 4 ; la motorisation du barillet primaire. J’imagine que cette intervention pourra être qualifiée de « parfaitement inutile » par certains et « intéressante » pour d’autres. Bon …. on verra bien ! En dehors de l’astronomie, je suis également passionné par la conception des systèmes mécaniques (j’ai une formation dans ce domaine), par l’usinage de pièces (j’ai un tour et une fraiseuse qui me permettent d’usiner les pièces dont j’ai besoin), l’électronique et le développement informatique. Cela me permet donc d’exploiter ces passions au service de l’astronomie. la boucle est bouclée. Il y a 2 raisons pour lesquelles je me suis lancé dans cette modification, qui au passage n’est ni la première, ni la dernière effectuée sur ce télescope. Une autre modification beaucoup plus conséquente (et un peu hasardeuse il faut le dire) est en train de se réaliser. Mais je n’en dit pas plus pour le moment. La première raison est que lorsqu’on veut collimater un newton et notamment lorsqu’on s’attaque au primaire, si le tube est long (ou qu’on a des petits bras), il n’est pas possible d’avoir à la fois l’œil sur le porte-oculaire et une main en train de tourner les vis de collimation du primaire. Soit il faut être deux, soit en étant seul, naviguer entre le PO et le barillet primaire tout en étant très méthodique pour tourner la bonne vis dans le bon sens. Et forcément, ça prend un certain temps. Mais, ça reste tout à fait possible puisque la grande majorité des astrams le font ainsi. La deuxième raison répond à une idée que j’avais depuis un certain temps : pourquoi ne pas se servir du barillet primaire pour réaliser la mise au point ? Cette approche est d’autant intéressante en astrophotographie car une fois que le train optique est calé (backfocus, MAP cohérente, …) la correction de MAP lors d’une séquence photo est relativement faible. Il n’y a que les dilatations thermiques à compenser, et quand on a un tube carbone, on s’approche du zéro. Alors dans ce cas, pourquoi ne pas déplacer le primaire ? Cela permet de supprimer le focuser et implicitement de permettre de rigidifier le montage du train optique coté secondaire. Si le barillet primaire est suffisamment rigide, pas de problème à priori. Et ce n’est pas le faible déplacement du primaire qui va influencer l’équilibrage avant/arrière du tube ou modifier le vignettage au niveau du capteur. Venons en à la présentation de la modification, ou plutôt des modifications : Au départ, mon newton est un ONTC 1212 de chez TS (300mm en f/4) avec un tube en carbone. Le barillet primaire (parties fixe et mobile) est constitué d’une structure en profilés d’aluminium usinés qui présente une rigidité certaine. Le barillet est pourvu de vis tirantes et poussantes de manière à pouvoir effectuer la collimation. Le tube est en outre pourvu de 4 séries de trous qui permettent de positionner le barillet primaire à une distance différente du miroir secondaire. L’objectif est en fait de pouvoir agir sur la distance entre secondaire et PO pour permettre d’y installer un train optique dont l’encombrement est plus ou moins long et permettre d’obtenir le bon focus. Comme on peut le constater sur l’image, l’arrière du télescope tel que livré est à l’air libre. Aucune obturation, ni ventilation ne sont présentes d’origine. La première modification a consisté à mettre une plaque usinée en aluminium portant un ventilateur. Il est important d’avoir une plaque qui obture (au moins grossièrement) la partie arrière de telle manière que le flux d’air généré par le ventilateur circule bien autour du miroir primaire, sinon, l’air n’est brassé qu’au niveau du ventilateur et le primaire n’est pas correctement balayé par le flux d’air. J’ai utilisé une des séries de trous disponibles sur le tube pour fixer cette plaque. Il y a environ 50mm entre la plaque et la partie fixe du barillet primaire. Pour la mise en place de la motorisation, j’ai commencé par faire le modèle 3D de la partie mécanique à partir des éléments existants. Comme je souhaitais pouvoir faire de la focalisation en automatique, le choix de la motorisation s’est orientée naturellement vers des moteurs pas à pas, avec bien sûr l’électronique et l’informatique associée. Pour la collimation sur place, il faut également disposer d’une raquette permettant d’agir sur les 3 moteurs et ce, dans les 2 sens de rotation. Si j’en étais resté à de la collimation « simple », j’aurais opté pour des moto-réducteurs à courant continu, qui ne requiert aucune électronique. C’est d’ailleurs cette solution qui est à privilégier avec un équipement exploité en nomade, et surtout pour un dobson de grandes dimensions qui fait généralement l’objet d’un démontage/montage systématique. Et collimater seul un gros dobson, j’imagine que ça doit être un peu coton. Je me suis servi de la plaque support de ventilateur pour y placer les moteurs pas à pas. Cette plaque a de fait été vissée directement à la partie fixe du barillet, ce qui a permis de positionner des transmissions courtes et de rigidifier l’ensemble du système. En conséquence, le ventilateur a dû être positionné en face extérieure de la plaque. La transmission de la rotation est effectuée à l’aide de poulies et courroies crantées qui évitent tout jeu (backlash comme on dit couramment en anglais) durant la rotation des moteurs. Dans ce type de montage, il est nécessaire de prévoir un système coulissant pour permettre de régler la tension de chaque courroie crantée. Chaque moteur est monté sur une plaque de réglage et des lumières usinées dans la grande plaque support permettent de faire coulisser chaque bloc moteur et ainsi de régler la tension des courroies : Au passage, il n’y a plus de vis poussantes et tirantes sur le système. Il n’y a qu’un système vis/écrou. Il n’y a pas de risque de jeu au niveau du système car des ressorts de compression vient repousser la partie mobile du barillet. Il est néanmoins nécessaire de s’assurer que l’effort minimal exercé par les ressorts soit supérieur au poids maximal de la partie mobile du barillet, c’est à dire, lorsque le tube vise le zénith. J’ai pesé l’ensemble de la partie mobile du barillet, y compris le miroir et les fixations. Sachant qu’il y a 3 vis de collimation, la charge unitaire par ressort est de fait divisée par 3. La position de compression mini des ressorts a été calée à 2 fois la charge maxi, ce qui donne la garantie qu’à aucun moment, du jeu ne peut être présent dans le système vis/écrou. Il est donc inutile de bloquer le barillet primaire après réglage. Compte-tenu de ce réglage, la course maxi du système est de 6,5mm, ce qui est largement suffisant pour effectuer de la collimation et de la focalisation. Le couple des moteurs pas à pas et la réduction par poulies crantées est suffisant y compris jusqu’à obtenir cette course de 6,5mm lorsque les ressort sont écrasés au maximum et donnent leur effort maximal. Des tests de déplacement du barillet avec mesure au comparateur ont montré la bonne reproductibilité des positions. La partie fixe du barillet primaire. On voit le boitier qui contient l'Arduino et les 3 drivers de moteur pas à pas : Pour réduire le coefficient de frottement entre poulie en aluminium et vis de collimation en inox, j’ai usiné les poulies de manière à insérer à force des « noyaux » en laiton. C’est une fois inséré que les noyaux ont été usinés. le but étant d’avoir la précision d’usinage maximum. Des butées à billes ont également été insérées sous les poulies : Coté pilotage des moteurs, le choix s’est porté sur un Arduino Nano avec 3 drivers de moteurs pas à pas. Les drivers dont des DRV8825, mais je vais les remplacer par des TMC2208 qui offrent un fonctionnement beaucoup plus silencieux des moteurs pas à pas. Ces derniers sont des Nema17. Vu qu’il est possible de piloter les moteurs en micro-pas (de 1/1 à 1/32), la résolution de l’ensemble est ajustable entre 1,875 microns par pas à 0,0585 microns par pas. La CFZ du newton étant de 35,2 microns, j’ai largement le choix de la résolution. Le fait d’ajouter cette motorisation à l’arrière du télescope augmente le poids des équipements. Mais dans mon cas, j’avais un contrepoids fixés à l’arrière du télescope et le système m’a permis de retirer ce contrepoids devenu inutile. Des fins de course on été installés sur les 3 branches mobiles du barillet. L’objectif est de pouvoir ré-initialiser si besoin la position des moteurs. Le retour à zéro peut se faire soit sur la base d’un seul fin de course, c’est le cas pour de la focalisation, soit elle peut s’effectuer indépendamment pour chacun des moteurs si on est plus sûr de rien. Néanmoins, dans ce cas, la collimation est de fait perdue, donc à utiliser dans un cas extrême ! L’ensemble barillet a ainsi été remonté avec le miroir primaire et son baffle de chanfrein qui permet également à l’air qui circule autour du miroir d’être rabattu vers la face supérieure du primaire. Vue latérale du système avant remontage : L'ensemble a été ré-installé dans le tube du newton. On aperçoit 2 poignées de manœuvre car introduire sur un bon 150mm la totalité du barillet équipé du miroir (c’est lourd) dans le tube alors que le jeu diamétral est réduit au minimum, ce n’est pas évident. Avec les poignées, c’est nettement plus facile. On voit également le connecteur USB pour piloter le système à distance, le connecteur de la raquette et l'inverseur qui permet de choisir le mode de pilotage (raquette ou distant) : Pour protéger les organes de transmission, des capots viennent se fixer sur la plaque support : Coté électronique, le schéma est assez simple : J’ai néanmoins réalisé un circuit imprimé double face (conçu par moi et usiné sur ma fraiseuse CNC) pour supporter l’ensemble des composants et faciliter le dépannage au cas ou : Le programme que j’ai développé pour l’Arduino permet soit d’utiliser une raquette à boutons, soit de piloter l’ensemble via un programme sur ordi distant. Pour la collimation sur place, j’ai fabriqué une petite raquette, équipée de 6 poussoirs principaux qui permettent d’intervenir sur les 3 moteurs et ce dans chacun des sens de rotation, de 2 poussoirs permettent de réaliser de la focalisation (les 3 moteurs tournent simultanément) et d'un inverseur qui permet d’avoir 2 vitesses de rotation des moteurs : Pour le pilotage à distance, le programme a été développé en VB.net. Ce programme permet la focalisation avec les commandes habituelles : Connexion au focuser, boutons avec un nombre de pas fixes dans les 2 sens, choix des micropas, GOTO, position max, retour en position Home (activation du fin de course d’un des 3 moteurs), calage de la position à zéro au choix et pas forcément lorsque le focuser est mécaniquement en position zéro. En plus du choix des micropas, il est également possible de faire varier la vitesse à l’aide d’un curseur. Le bouton ré-initialisation des moteurs permet de les faire revenir individuellement en position zéro : Un bouton « Collimation » permet de faire apparaitre la partie pilotage de la collimation, bien que se soit pas forcément très utile puisqu’il faut normalement intervenir également au niveau du secondaire pour avoir une bonne collimation. Mais on peut imaginer que si seul le primaire se dérègle, dans ce cas, on peut faire de la collimation à distance, soit en défocalisant une étoile, soit en utilisant un programme d’analyse des étoiles qui permet de déterminer l’écart de collimation (CCD Inspector par exemple) : Dans ce cas, on peut faire varier le nombre de pas de déplacement des moteurs à l’aide d’un curseur (de 1 à 20 pas de déplacement). 2 boutons par moteur permettent de faire varier l’inclinaison du barillet primaire. En conclusion, je dirais que le système m'a donné un peu de fil à retordre, surtout coté logiciel, mais pour avoir testé le système en place, je peux dire que ça fonctionne correctement et que ça offre un certain confort pour réaliser la collimation. Comme je disais un peu plus haut, on peut s'inspirer de ce système, notamment pour les dobsons de grandes dimensions, mais en utilisant des moto-réducteurs à courant continu dont on peut faire varier la vitesse de rotation aisément par simple variation de la tension d'alimentation. C'est me semble t'il plus facile à mettre en œuvre que des systèmes de tringlerie qui montent jusqu'à la cage secondaire. Maintenant, il ne me manque que le développement d’un driver ASCOM pour pouvoir tester la focalisation via logiciel d’acquisition photo. Mais pour l’instant, n’ayant développé aucun driver, il faut que je m’approprie la méthode. Bon ciel à vous JP PS: je ne sais pas pourquoi, mais j'ai beau supprimer l'image ci-dessous, elle ré-apparait en permanence.

Belle série. Et finalement, tu identifies une amélioration au niveau des images avec ton masque de chanfrein ?

J'essaie aussi de diversifier mes cartes, mais bon, si certaines fonctionnent sans problème, pour d'autres, c'est moins évident : La carte la plus à droite est justement une ESP32 sur laquelle est raccordé un écran de 320x200 que je n'arrive pas à faire fonctionner pour le moment

J'ai réceptionné l'encodeur que j'avais commandé sur Ali.. à 400 pas par tour. La preuve que je suis ouvert à des solutions alternatives Bon, je trouve qu'un encodeur, c'est quand même assez volumineux. Mais bon, avec un boitier qui colle à la peau de l'encodeur (impression 3D ?), on peut probablement éviter la boîte à chaussures J'ai testé cet encodeur avec un Arduino Nano par le biais des 2 pins interrupt. Pour le moment, je me suis contenté du moniteur série pour visualiser l'évolution du nombre de pas. J'ai réduit le code à pratiquement sa plus simple expression car je constatais qu'en tournant rapidement l'axe de l'encodeur (1 tour en 1 à 2 sec) , des pas se perdaient. Je pouvais quasiment perdre 1 pas sur 2. En réduisant le code, peu de pas se perdent . Peut-être qu'avec un moteur PAP derrière, on y verrait que du feu ! Ou alors que le Nano n'est pas suffisamment puissant pour traiter un train d'impulsions trop rapprochées. Manifestement oui. Par contre, je n'ai bien compris cette histoire de "Device hub focuser" avec Nina ! Je suppose qu'il faut un Arduino avec un programme spécifique ?

Il y a quelques années, j’avais discuté avec Stéphane Ferrafiat qui pratiquait le suivi du transit d’exoplanètes. Il m’avait expliqué la méthode pour les acquisitions. Il y avait notamment un site professionnel qui listait les exoplanètes identifiées avec les dates prévisionnelles de transit. Il était également possible de déverser les acquisitions sur ce site pour prise en compte par les pros. Je n’arrive malheureusement pas à retrouver ses coordonnées. Peut-être que quelqu'un pourra les communiquer.

Belle image avec plein de bulles de matière visibles.

Que veux tu dire par PLS ? Position Latérale de Sécurité ??? Perso, je n'ai pas de câble chauffant au niveau des rails de mon abri. J'ai ajouté cette option dans mon petit soft à la demande d'un astram qui voulait gérer sa allsky et qui me posait la question concernant le chauffage des rails. Mes rails étant des profils oméga (rails de portail), je n'ai jamais eu de vrais soucis pour déplacer le toit. Vu qu'il y a tout ce qu'il faut avec le RPI, les capteurs et la carte relais (c'est aussi pour cette raison que je préconise une carte comportant plus de relais que ce qui est nécessaire pour la allsky car on peut piloter d'autres choses) pour les résistances de la allsky, il me suffisait de rajouter quelques lignes dans le programme pour commander un relais supplémentaire, mais uniquement sur la condition température extérieure basse. Néanmoins, il utilisait du cordon chauffant qu'il avait trouvé en magasin de bricolage (à enrouler autour des tuyauteries d'eau). Sur le net, il suffit de chercher avec "cordon chauffant", "câble antigel" et tu trouves de nombreuses solutions. Le challenge est de trouver une longueur approchante de la longueur des rails.