keymlinux

Bonjour, La dernière version 2.7 de Firecapture n'est disponible qu'en 64bits Une version windows 32 bits est disponible pour le version 2.6, donc c'est à tester (celé ne coute rien de tester) Téléchargement de la version 32bits disponible sur le site du développeur http://www.firecapture.de Cordialement

Bonjour, Si tu peux observer à domicile, avec présence d'une prise de courant domestique, alors autant ne pas s'embarrasser d'une batterie pour alimenter ta monture, et donc la brancher via un adaptateur (transfo) 12V Si pour observer tu doit être nomade en pleine nature , alors là pas d'autre solution qu'une batterie 12V (sauf à trimbaler un groupe électrogène...) Concernant les PowerTank, ceux "tout fait" du commerce ne m'ont jamais convaincu (cher au regard de la capacité offerte). L'alternative est alors une vraie batterie 12V, soit au plomb (comme une batterie de voiture, mais prévoir plutôt une batterie à décharge lente, comme celle équipant les camping cars) soit une batterie 12V au Lithium (si le poids et l'encombrement sont un facteur important pour toi alors il faut s'orienter vers du Lithium plutôt que du plomb, mais c'est plus cher...) En terme de dimensionnement; Ton alim AZ-EQ6, consommera moins de 2A (2A c'est éventuellement en pointe pour le gros déplacements Goto, en suivi cela sera plutôt entre 0.8A et 1A). Si tu veux tenir une nuit d'observation de 6h il te faudra 12Ah. Avec une batterie au plomb il ne faudra pas décharger la batterie à plus de 50% (au risque de l'endommager et de réduire sa durée de vie), donc il faudra une batterie de 24Ah Avec une batterie Lithium tu pourras tirer 80%, donc une batterie 15Ah devrais suffire. Personnellement j'ai opté pour une batterie au plomb 60Ah (pour pouvoir utiliser 30Ah), pour alimenter tout mon setup sur 6 à 8heures (pas seulement la monture, mais aussi un APN, un raspberry, des résistances chauffantes, un hub usb...) voir bricolage ci dessous Cordialement, Stephane

Bonjour, Globalement la terre tourne sur elle (360°) en 1 jour, donc environ 15° par heure, soit 1° en 4minutes It te faut calculer le champ réel vu avec ton tube et ton oculaire On a besoin de la focale "ft" de ton tube, de la focale "fo" de ton oculaire et du champ apparent "ça" de ton oculaire Le grossissement "gr" c'est ft/fo Le champ réel sera le champ apparent divisé par le grossissement ca/gr Exemple, avec une focale de 1200mm, un oculaire de 20mm de champ apparent de 68° gr: 1200/20 = x60, le champ réel sera de 1.13°, donc le ciel défilera dans le champ en 4minutes et 30 secondes environ Edit: Dans l'exemple, un grossissement de x20 est faible, bien pour le ciel profond, mais pas pour le planétaire Si on grossit un peu plus avec la lune en entier par exemple (champ couvert de 0.5°), alors elle défilera dans le champ en 2minutes. Si on grossit plus sur une partie de la lune, le temps d'observation se réduira, si on ne compense pas le mouvement, qe cela soit via une monture motorisée, ou bien en assurant un suivi manuel Tu peux dans un logiciel comme Stellarium et son plugin "oculaires" modéliser les caractéristiques de ton tube et de tes oculaires pour avoir une idée de la vitesse de défilement Cordialement

Pour calculer on va avoir besoin de la focale de ton tube, et du champ apparent de tes oculaires Par exemple, si ton tube a une focale de 1200mm et tes oculaires ont un champ apparent de 68° Avec l'oculaire de 24mm, le grossissement sera de 1200/24, soit x50, donc le champ réel couvert sera de 68/50=1.36° Avec l'oculaire de 12mm, grossissement de x100, champ réel de 0.68° Cordialement

Bonjour, Si tu constate un décalage par rapport aux cercles gradués, peut être qu'il faut étalonner ceux ci. Sur l'AZ-EQ6 les cercles gradués sont "mobiles" et tiennent grâce à une vis de serrage. Si elle se desserre il peut y avoir "glissement" (le cerclage gradué tourne alors que l'axe de la monture ne tourne pas...) Voir la doc de la monture, chapitre 2.2 Cordialement

Bonjour, Est ce modèle ? https://www.bresser.de/fr/Astronomie/Accessoires/Astrophotographie/BRESSER-Camera-oculaire-MikrOkular-Full-HD.html Si oui ?, dans ce cas tu dois utiliser l'adaptateur 31.7mm (1.25pouces) qui est annoncé fourni avec, et utiliser la camera à la place d'un oculaire sur ton dobson... Pour le reste il est annoncé qu'elle est fournie avec un logiciel dédié pour Windows, qui générera des fichiers videos (AVI) Cordialement, Stephane

Le Quark, de la société Daystar est un filtre H-Alpha utilisant le principe de l'interféromètre de Fabry-Perot (il existe aussi des variante pour d'autres longueur d'ondes du Calcium, Sodium et Magnesium) https://www.daystarfilters.com/Quark.shtml Le but étant d'observer le soleil en ne gardant que la longueur d'onde autour de la raie H-Alpha, pour observer la surface et les protubérances) Pour être efficace ce type de filtre doit être utilisée avec un gros rapport f/d, donc il y aune barlow x4.2 intégrée (d'ou le faible champ couvert, même avec une lunette de courte focale) Les société Lunt et Coronado font aussi des filtre Halpha pour l'observation solaire Attention, ce type de filtres n'a rien a voir avec les filtres H-Alpha pour l'observation/photo du ciel profond, et qui ne sont pas adaptés à recevoir le flux de notre soleil... L'interêt ici est que ce filtre n'est pas disposé à l'ouverture de la lunette (le coût varie de manière exponentielle en fonction du diamètre d'ouverture), mais se positionne à l'arrière e la lunette, comme un oculaire (et on met un oculaire ou une camera en sortie du quark) pour les lunette de diamètre jusqu'a 100mm. Au dessus de ce diametre il faut un filtre ERF à l'ouverture du tube (ERF=Energy Rejection Filter) H-Alpha https://fr.wikipedia.org/wiki/Hα Fabry Perot https://fr.wikipedia.org/wiki/Interféromètre_de_Fabry-Perot Cordialement

Bonjour, Si tu démonte tout et remonte tout et re-câble tout a chaque fois, alors oui, c'est galère, et plus on ajoute de composants (focuser, guidage, etc) plus c'est galère Dans mon cas, je transporte d'un seul bloc le montage suivant: - lunette 80/500 avec focuser électrique - lunette de guidage 60/240 + camera de guidage asi290mm - raspberry+hub usb+disque ssd (qui assure les prises de vue, le guidage et l'astrométrie) - le câblage des divers éléments entre eux reste monté Lors de la séance de prise de vue j'ai juste a connecter la batterie, l'imageur (APN ou ASI178 en fonction des cibles) et la monture (ce que je devrais faire quoi qu'il arrive avec ou sans autoguidage) Bon OK, la calibration du guidage sous Kstars/Ekos doit prendre 2 minutes... Et depuis que j'utilise le plate solving (astrométrie) je ne fais plus de mise en station sur 3 etoiles... Cordialement

Oui, @Aïki, savoir si le ROI était utilisé pour les 2 images ou pour une seule c'est important pour comparer les rayons de courbure, mais dès lors que le but d @-Amenophis- c'est d'agrandir le champ (d'où le réducteur de focale) pour éviter de faire des mosaïques avec trop d'images, il deviens alors important de ne pas limiter le champ avec du ROI, sous peine de devoir multiplier les images pour la mosaïque A mon avis la première chose a faire c'est de supprimer le ROI pour maximiser le champs couvert par la camera Ensuite, concernant l'usage d'un réducteur, il faut garder à l'esprit que le Quark donne des résultats optimum pour une plage de focale donnée, ou plutôt pou un rapport d'ouverture donné, entre f/d 4 et f/d 9 (mais a mon avis plus on est au centre de la plage donnée mieux c'est..., ce n'est pas comme si les fabricants donnaient des specs optimistes... 😉 ) La SW72ED fait 72/420 soit f/d=5.8 . Avec le réducteur x0.85 on passe à f/d=4.95 cela reste dans les specs du Quark, mais personnellement je resterais sur un f/d optimum entre 6 et 7, et la SW72ED sans réducteur s'en approche Cordialement

Bonjour, Pour faire de la résolution astrométrique on a pas besoin de poses longues, mais cela dépend de ce que l'on entend par "long" Habituellement on fait des poses longues (de 30 secondes à 10 minutes) pour l'astrophoto ciel profond, des poses courtes (quelques secondes) pour le guidage, voir très courtes en planétaire ou solaire (quelques millisecondes) Faire de l'astrométrie avec une lunette guide, des poses de 1 à 10 secondes seront suffisantes selon la sensibilité de la camera, cela reste court, mais suffisamment long pour avoir du filé d'étoile qui va contrarier le logiciel d'astrométrie, vu que ton dobson n'est pas motorisé. Si tu veux avoir une idée de l'endroit ou tu pointe, je te conseille plutôt une lunette guide "ouverte", comme une 60/240 f/d=4, accompagné d'une camera ASI290 monochrome pour la sensibilité. La courte focale epermet d'avoir du champ, ce qui augmente la probabilité d'avoir des etoiles brillantes dans le champ, et son ouverture ainsi que la sensibilité de la camera permet de faire baiser le temps de pose pour limiter le filé Sinon, si tu as un APN avec un objectif standard (focale entre 80 et 200 cela serait bien, avec un rapport d'ouverture f/d pas trop gros) , tu peux aussi le monter en parallèle de ton dobson et faire un test d'acquisition sur quelques secondes at tenter une résolution astrométrique. L'idée c'est de faire un test avant d'investir dans du matos... edit: nos réponses se sont croisées, les conseils de @krotdebouksont très bons. Ne pas investir avant d'avoir validé que l'absence de suivi motorisé ne rende la résolution astrométrique impossible Cordialement

Bonjour, Ta camera a 1936x1216 photosites, mais ton acquisition est en 1024x768 (regarde les options FireCapture qui commencent par ROI) --> ROI cela veut dire "Région Of Interest", tu as donc réduit (volontairement ou pas) la surface du capteur utilisée pour l'acquisition (et donc aussi le champ couvert) Pour le reste, je trouves tes photos magnifiques.. 🙂 Cordialement, Stephane

Bonjour, De mon expérience personnelle, on ne peut pas choisir de télécharger ou pas depuis l'APN, Ekos telecharge toujours une image, par contre on peut choisir de conserver ou pas l'image sur la carte SD de l'APN Effectivement le téléchargement c'est long, il semble que cela le soit un peu moins si on telecharge au format FITS et pas NATIVE (sur la carte SD de l'APN il y aura toujours la version NATIVE en fichier CR2 ou CR3, seule la version téléchargée par EKOS sera au format FITS, et c'est un peu plus rapide car Ekos n'a pas besoin de la transformer d native en fit pour l'analyser (pour calculer la FWHM, pour l'afficher dans FITS viewer, etc...), que cela soit dans les onglets "prise d vue" mais aussi pareil dans l'onglet "Focus" et "Astrometrie". De plus la durée de téléchargement c'est en fait la durée de 2 opération cumulée, le transfert entre l'APN et le raspberry d'une part, puis la durée d'écriture sur le raspberry d'autre part. Si sur le raspberry tu écrit les images sur la carte SD (celle du rasp, pas celle de l'APN), alors là aussi c'st une opération longue). Le mieux c'est de connecter un disque externe SSD sur le raspberry et d'en faire la destination des photos capturées (en fait le mieux avec un raspberry c'est de faire en sorte d'avoir le système d'exploitation sur un disque externe, sinon à la longue on tue la carte SD...) Ensuite pour l'empilement avec Siril ou autre tu as le choix d'utiliser les FITS recrées par Ekos et stockées sur la carte SD du raspberry ou bien d'aller chercher les fichiers natifs Canon sur la carte SD de l'APN (ce que je fait) note: la notion de téléchargement "local", "client" ou "both" n'a rien a voir avec le téléchargement depuis l'APN, cela s'applique lorsque tu utilise un "client" INDI gui gère le driver GPhoto sur un autre host que celui ou tourne Ekos...le "local" représente alors le serveur INDI où tourne EKOS, et le client un autre host où ne tourne qu'indi pour gérer un périphérique. Cordialement

Bonjour, Attention, pour ceux qui utilisent Kstars sous MacOs (je sais on est pas très nombreux...), cette dernière version 3.6.0 nécessite désormais MacOS 10.15 (Catalina) pour fonctionner, et non plus MacOS 10.13 (High Sierra), bien que la page de téléchargement annonce toujours une version minimale 10.13 https://edu.kde.org/kstars/#download EDIT: la page de téléchargement a été mise à jour, la version minimale MacOS annoncé est désormais la 10.15 (Catalina) Pour télécharger la dernière version compatible macOS 10.13 et 10.14 c'est la 3.5.9 dispo ici https://www.indilib.org/jdownloads/kstars/kstars-3.5.9.dmg Cordialement

Pour les infos sur ton APN https://fr.wikipedia.org/wiki/Sony_Alpha_300 taille du capteur 23,6 x 15,8 mm nombre de pixel 3872x2592 Ce qui fait une taille de pixel de 6 µm

Bonjour, J'ai un Alkaid 10", et j'ai pu stabiliser un peu la colimation avec des entretoises (imprimées 3D) sur les tubes en alu. L'idée originale n'est pas de moi, elle est de @j65 Les photos Le modèles 3D est disponible ici (vous devrez adapter il est prévu pour un 10" pas un 12") https://www.tinkercad.com/things/ezusH6hWHCN-entretoise-alkaid-v3 Cordialement, Stéphane

Bonjour, Je viens de poster dans les clubs "L'impression 3D en astronomie" et "Astronomie avec Arduino" les éléments nécessaires à la réalisation d'une roue a filtres imprimée en 3D, manuelle ou motorisée Chapitre 1: Les photos du bricolage Voici des photos de la version RF-42 5x1.25 pouces avec motorisation que j'utilise régulièrement (pilotée via Kstars/Ekos/Indi,la roue implémente le protocole des roues Quantum) En version manuelle, avec une petite trappe pour accéder à la roue et la faire tourner Le support moteur En version motorisée, la trappe est remplacée par le support moteur En version motorisée avec le boitier d contrôle (1 port 12V DC pour l'alimentation du moteur, un port USB micro pour le pilotage série) Une vue des différents éléments avant montage de la roue Une vue des elements de la motorisation Chapitre 2: Les modèles 3D Il y a 2 modèles, avec 3 déclinaison en tout 1) Le petit modèle, une seule déclinaison pour 5 filtres 1.25 pouces Le boitier dispose de filetages M42x0.75 m sur chaque face 2) Le grand modèle, avec 2 déclinaisons, soit pour 5 filtre d e3 pouces, soit pour 8 filtres de 1.25 pouces Le boitier dispose de filetages M54x0.75 M sur chaque face Les fichiers pour l'impression 3D des roues ) filtres sont disponibles ici Chacun des 2 modèles peut être actionné manuellement, ou doté d'une motorisation Pour l'impression en 3D des supports moteurs et du boitier de contrôle, c'est ici EDIT: ajout des fichiers STL pour les têtes de vis et boulons, pour manipuler les vis sans outils Tete vis et boulons.zip Important: les têtes de vis sont une création originale de Xavier DUPONT pour le projet SOLEX, les têtes de boulons sont une adaptation personnelle des têtes de vis. Chapitre 3: Motorisation, code de programmation et interface de pilotage Pour la motorisation vous aurez besoin d'un microcontroleur ESP8266 ou ESP32, d'un moteur 28BYJ-48 et de son stepper UNL2003 (le tout devrais vous couter moins de 20 euros). Le code est fourni ici (mis à jour version 1.1.1 le 19/10/2021) La roue est pilotable via le port USB du contrôleur, elle implémenta par défaut le protocole des roues à filtres Quantum --> a ce titre la roue a filtres est pilotable via Kstars/Ekos/Indi en utilisant ce driver INDI Avec un microcontroleur ESP8266 ou ESP32 (en lieu et place d'un Arduino tout simple), la roue a filtre généralement!re son propre réseau Wifi (comme une borne) SSID réseau: : mls-rf password: azerty adresse IP de la roue: 10.42.0.1 joignable en interface web: http://10.42.0.1 En parallèle du mode "borne" la roue peut aussi se connecter à un réseau wifi existant, vous pouvez modifier dans le code les éléments "reseau1", "password1", "reseau2" et "password2", la roue a filtre se connectera à l'un de ces 2 réseaux, au premier qui accepte la connexion, testés dans l'ordre... Voici quelques copies d'écran du pilotage en mode wifi (désolé j'ai l'habitude de programmer en anglais, comme au boulot, même si mon niveau d'anglais est mauvais ...) L'écran principal, on choisi le filtre et on valide (submit), la validation entraine le déclenchement du mouvement pour positionner le filtre choisi (les noms des filtres peut être modifié sur l'écran de config) Ci dessous l'écran de configuration pour nommer les filtres et leur attribuer un décalage (offset), qui sera utilisé par Ekos/Indi pour ajouter la mise au point selon chaque filtre Ci dessous la page de configuration Détail des paramètres: - nombre de filtres: accepte les valeurs de 1 à 9, mais en fait on utilise soit 5 soir 8 filtres - nombre de "pas par minutes" max lors de la rotation du moteur - nombre de "pas par minutes" initial au but de la rotation du moteur - nombre de "pas" pour le facteur d'acceleration (utilisation de la librairie AccelStepper) - nombre de pas pour faire un tour de moteur (habituellement avec un moteur 28BYJ-48 c'est 64) - nombre de dents de l'engrenage sur l'axe moteur (20) - nombre de dents sur le tour de la roue (100 pour le petit modèle, 120 pour le grand modele) Ci dessous la page pour envoyer manuellement des commandes (celles qui sont habituellement envoyées par le port série, pratique pour tester) TRES IMPORTANT: comme la roue a filtre ne dispose pas de mécanisme de "repositionnement automatique", si il y a désynchronisation, avec le roue qui s'arrête sur une position entre 2 filtres, l'ecran de mouvement manuel permet des ajustement en faisant tourner la roue (on choisi le nombre de degrés, en valeur positive ou négative selon le sens que l'on souhaite Et pour finir il y a une page "debug" qui présente les valeurs en cours des différentes variables du firmware Cordialement, Stéphane Edit 19/10/2021: suppression des images en doublon, mise à jour des copies d'écran du pilotage de la roue via son interface web Edit 23/11/2021: modification du schéma de câblage, livraison code microcontroleur v1.2.0 VERSION1.3 du 06/11/2023 Edit 06/11/2023: ajout d'une nouvelle pièce 3D "support haut hall" permettant d'ajouter un capteur a effet haut et livraison code microcontroleur v1.3.0 qui l'exploite Motifs sur le code: - Refonte graphique pour le site web embarqué et ajout d'un mode "nuit" (rouge/noir) - Ajout pilotage via driver Bluetooth Serie (testé OK sur Ekos/Indi) - Ajout pilotage via driver network (tcp port 1234)(testé OK sur Ekos/Indi) - Ajout capteur Hall + recherche automatique de la position du filtre 1 IMPORTANT: si vous avez déjà imprimé la version précédente de la roue et du support moteur vous n'avez pas besoin de tout réimprimer, vous devez seulement imprimer la pièce "support haut hall" (et éventuellement le "capot hall" pour protéger le capteur) Quelques images: Le support du capteur Hall (piece seule, et pièce installée sur la roue avec le capteur) Le support avec le capteur et son capot de protection Le type de capteur est un AZDelivery KF-035 (environ 7 euros les 3 capteurs sur la Zone....) Important: ce capteur dispose d'une LED qui éclaire en rouge, il est important de la masquer pour ne pas produire de lumière indésirable dans la roue à filtre ! Avec un contrôleur ESP8266 ou un ESP32 la roue peut être connectée en Wifi et pilotée via un site HTTP intégré La version 1.3.0 entraine une refonte graphique du site embarqué, voici quelques captures d'écran (le theme Dark est par défaut, mais on peut permuter avec le thème Light à la volée): Le nouveau plan de câblage avec le capteur Hall (dans le code on considère qu'il est connecté sur le port GPIO16, mais c'est configurable) Cordialement, Stéphane

Bonjour, Après mon précédent bricolage pour adapter l'Alkaid sur une monture équatoriale, voir: ...vu qu'en ce moment j'ai un peu de temps de libre (comme nous tous...), je viens vous présenter ici la réalisation d'un système PushTo avec encodeurs et son intégration sur mon Alkaid (mais c'est adaptable sur vos Dobsons...) Ce premier "post" présente surtout le choix des encodeurs et les travaux réalisés pour les fixer sur l'Alkaid (pour rappel un Dobson de type Strock) Un futur post présentera plus en détail la partie électronique (Arduino, module gps, module bluetooth, lecteur de carde SD) et la partie développement logiciel qui l'accompagne... Tout d'abord, pour ceux qui ne savent pas ( mais ils devraient être peu nombreux sur ce forum 🙂 ) - Un Push-To c'est une aide pointage d'objet dans le ciel - Contrairement au Goto il n'y pas pas de moteurs, le pointage reste "manuel" (on pousse le tube avec les bras) - Avec le GoTo vous selectionnez un objet dans une base de données et Go, la monture y dirige le tube - Avec le PushTo vous selectionnez l'objet et le dispositif vous indique dans quelle direction et de combien de degrés vous devez tourner le tube a droite/gauche (Azimuth) et haut/bas (declinaison) - Goto et PusTo ont en commun de nécessiter une mise en station préalable du telescope Pour les montures Goto, la plupart des magasins d'astro et sites web spécialisés en proposent, à tout les prix. Pour les PushTo, il y a des produits commerciaux existants, mais plus rares. Parmi les plus connus: - Nexus DSC d' Astrodevices https://www.astrodevices.com/Products/NexusDSC/index.html - Argo Navis de Wildcard Innovations http://www.wildcard-innovations.com.au - Sky Commander de Sky Engineering http://www.skyeng.com - EZ-PushTo de Romer Optics https://romer-optics-llc.myshopify.com/products/ez-push-to-kit-for-brands-of-dobsonian Il y a aussi des alternatives plus orientées "open source" comme le projet Stellarduino (https://github.com/caseyfw/Stellarduino) sur lequel je me suis appuyé pour le developpement de mon PushTo "perso" Le but du projet: - réaliser un PushTo de A à Z (même si je ne suis pas contre l'idée de réutiliser du code existant pour me simplifier la vie, un bon informaticien restant un informaticien fainéant) - pour la partie réalisation des boitiers et de la fixation sur le Dobson, utilisation d'une imprimante 3D - pour la partie "calculateur" utilisation d'un Arduino, avec ecran LCD, clavier de saisie, encodeurs, et facultativement de module GPS, module bluetooth, module RTC et lecteur de carte SD - tout réaliser avec un budget matériel de 100 euros environ (même si ma principale motivation ce n'est pas le budget, c'est le fun de réaliser sois même...) - les encodeurs et leur fixations, ainsi que le boitier de contrôle doivent êtrs légers, tenir dans un petit sac à dos (avec les oculaires), et le PushTo doit pouvoir être alimenté par une simple pile 9V (pour ne pas avoir à trimbaler une batterie de bagnole 😱) - partager les modèles 3D, les plans et le code informatique avec la communauté pour que chacun puisse réutiliser librement Concernant les encodeurs, mon choix s'est porté sur le modèle AMT 102 de CUI https://www.cuidevices.com/product/resource/amt10.pdf, des encodeurs de faible encombrement ayant une résolution de 2048 pulsations par tour (8192 avec la quadrature). A 25 euros TTC pièce ils représentent la moitié du budget (vu qu'il en faut 2)i acquis chez Mouser (https://www.mouser.fr/ProductDetail/CUI-Devices/AMT102-V?qs=WyjlAZoYn533PQfgnorrMg%3D%3D) La rotation des axes du telescope sera transmisie aux encodeurs avec une démultiplication 1:4 via des poulies et une couroie (poulies 60 et 15 dents, du type GT2 largement utilisées sur les imprimantes 3D donc faciles à trouver pas trop cher dans le commerce, encore moins cher chez ali le rapide...). La démultiplication porte la résolution à 32768 pulsations par tour, mais non, soyons sérieux, nous n'obtiendrons pas une résolution au pointage de 39" d'arc, en effet nous seront limités par les jeux mécaniques, l'orthogonalité des axes AZ et ALT du télescope, la qualité de la mise en station, l'erreur de mesure des encodeurs, etc... Donc on doit réaliser les éléments suivants: - Boitier pour l'encodeur d'Azimut avec ses 2 poulies - Sa fixation au fond du rocker du dobsoni (attention contrainte forte, seulement 20 mmm entr ele fond du rocker et la cade du miroir primaire !) - Boitier pour l'encodeur de Declinaison avec ses 2 poulies - Sa fixation "dans le vide" sur l'axe de rotation (sur un strock cet axe est dans le vide contrairement aux Dobsons traditionnels) Optimisations/Contraintes: - si possible utiliser le même design de boitier pour les 2 encodeurs - je m'interdit de percer quelque trou que ce soit dans l'Alkaid, il faut utiliser les trous présents d'origine ! En plus des pièces imprimées en 3D, les supports utiliserons des tasseaux en bois de 21x21mm - en bois car je ne suis pas outillé pour travailler l'alu ou autre métal (déjà qu'avec le bois j'ai du mal...) - il n'y a pas de contrainte forte sur ces supports, du tasseau de 10x10mm suffirait, on a pas besoin de 21x21mm mais c'est de la recup, c'est ce que j'ai utilisé pour des étagères de placard... Les Modèles 3D (tous modélisés sur Tinkercad, ils y sont en libre accès) La modélisation des boitiers pour les encodeurs: Boitier Encoder La modélisation des pièces pour l'axe AZ Fixation Boitier Encodeur La modelisationi des pièces pour l'axe ALT Support Axe Encoder La modélisation du boitier de contrôle qui va contenir l'arduino et les modules Boitier Push-To Et pour terminer les photos... note: a venir, la partie Arduino, avec le détail des matériels (lcd, GPS, ...) , le schéma de câblage, les sources du code .. Cordialement, Stéphane Le boitier pour l'encodeur et les poulies: La fixation pour l'axe AZ note: le filetage présent ici est une rare partie non réalisée par mes soins mais issue d'une contribution externe La fixation pour l'axe DEC (support du boitier encodeur, fixée au rocker) .La fixation pour l'axe DEC (support de l'axe, qui pivote avec le tube) Et maintenant le montage final sur le Dobson L'encodeur de l'axe AZ au fond du rocket Visible ci dessus, le seul dégât collatérale subit par l'Alkaid, lorsque j'ai enlevé le "scratch" qui gênait pour positionner le boitier encodeur, la peinture est venue avec la colle... Le boitier de contrôle qui contient l'Arduino, l'écran, le clavier...