gehelem

... et un machin pour faire le goto, avec un catalogue qui va bien (pompé chez @vinvin et @lock042 , merci beaucoup !)

ça y est, j'ai codé les trucs pour charger/sauvegarder des configurations ( = ensemble de modules+profiles) ... ça m'a l'air de fonctionner ...

J'ai plus d'idée de trucs à faire. Jm'ennuie.

bon, je pense que la situation est rétablie attention donc : ostserver-daily était le seul qui contenait des trucs jsuqu'à présent , et avec la branche stable d'indi maintenant c'est changé : il pointe sur la branche nightly d'indi Donc à vous ô valeureux beta testeurs qui seraient déjà passés par ici et qui voudraient recommencer : je vous conseille amicalement et fermement de basculer sur mon ppa ostserver (tout court, pas le daily) Et désormais les builds se font bien pour armhf sur mon daily, youpi ! Je vais regarder si la pulpe se secoue bien dedans.

Amis bidouilleurs attention : Je suis en train de faire quelques manœuvres sur mon launchpad pour avoir des builds armhf sans bouger le petit doigt, mais en les compilant directement avec les nightlies d'indi J'ai pris les options suivantes : - L'archive ostserver (tout court) est construite avec indi-stable - L'archive ostserver-daily est construite avec indi-nightly Je n'ai pas encore différencié ma source à moi, ce sera le même code ostserver/ostmodules qui sera compilé dans les deux. A terme, il faudra sans doute que je dirige vers un truc "release" de mon coté, ou je sais pas quoi mais qqch du genre. Je pense que je vais galérer un peu à faire ça (c'est déjà en train de péter), mais ça m'intéresse bien d'avoir des builds pour mon RPI3 sans lever le petit doigt Les manœuvres sont en cours, donc faites gaffe prenez un café avant si vous êtes d'humeur beta testeuse. N'allez pas me gâcher votre dimanche à installer des merdes sans réfléchir un peu avant : Danger. G.

2023-03-18 18-46-09.mkv

Me voilà avec un petit séquenceur tout simple, qui m'a l'air de marcher

Hop, 6 coches en plus qui devraient me permettre de tester en vrai Accessoirement, en choisissant les bonnes j'arrive à guider partout - ça va bien m'aider

Ahhhh, en effet c'est vicieux Possible d'ailleurs que ce soit aussi à l'origine de mon problème ... Il va falloir que je teste en vrai pour vérifier, et probablement que j'ajoute les mêmes coches d'inversion (au moins pour faciliter l'analyse) Merci !!

Merci pour tes encouragements ! Tu peux être plus précis sur ce qu'il fait de mal ? Là moi c'est même pas le retournement qui pose problème, c'est "juste" le coté où ça regarde Calibration+guidage Est => OK Calibration+guidage Ouest => KO Il faudrait que j'essaie ceci Calibration Est + guidage Ouest et inversement J'y cours Je me dis qu'en utilisant la propriété "pier side" de la monture je devrais arriver à piger puis corriger ... Calibration à l'Est + guidage à l'Ouest = la correction en RA se fait à l'envers, du coup : Calibration à l'ouest + guidage à l'ouest : Calibration à l'ouest ++ guidage à l'est : ==> je pense qu'en ajoutant un "-" qq part dans la phase de guidage en fonction du "pier-side" je devrais arriver à corriger dans le bon sens mais je ne comprends pas le fond du problème 🙂

Je me suis rendu compte que les builds armhf sont dispos sur les nightlies !! Du coup hop, sur le pi3 Et compil ost dessus, vu que j'ai bazardé mon ppa armhf... Et donc, depuis le téléphone...

bon, héhé, finalement 🙂

Bon alors celle là elle déchire : J'avais laissé le truc en l'état sans me rappeler que ça marchait déjà un peu. En gros c'est le drift plot (mais en pixels) lors d'un guidage Et le résultat ressemble vraiment beaucoup à ce que me sors Ekos, dans à peu près les mêmes conditions de simulation : > on s'approche d'un test grandeur nature, il serait temps Je vais essayer de mettre en place le graphe temporel et les stats (le fameux RMS), ça va moins rigoler mais juste besoin de temps. Mais le seul vrai problème ... ça ne fait du guidage qu'à l'Est Si je pointe à l'Ouest ça part en sucette 🙂 Bref, on avance G.

Tests concluants sur ma VM, j'en ai profité pour ajouter qq bricoles : - ajout des fichiers nécessairess pour créer un deamon (service) - un script d'install pour ostserver / indiwebmanager / indi / service ost / qq index astronmetrie (à améliorer pour rendre le user dynamique, là j'ai mis "ost" en dur) Ma allsky et mon CCD inspector sont en train de cuire sur le Launchpad on testera tout ça demain En attendant, premières vraies images en indi 2 :

bon, le pour et le contre ont été pesés et la décision a été prise : On passe à Indi 2 Je vais galérer à suivre les lascars de Kstars, mais il aurait de toutes façon fallu y passer. Et accessoirement autant couper tout de suite des usages voués à l'abandon (les mentions "deprecated" ça fait pas sérieux quand on compile, je trouve) Donc j'ai essayé, je ne peux pas dire que ça a été facile mais j'y suis arrivé. La façon dont c'est codé me semble plus moderne, mais je manque vraiment d'expérience pour juger. Bref : Le build d'ostserver est en cours sur mon launchpad, j'ai besoin de savoir si ça fonctionne jusque là-bas. Je testerai demain avec ma juge de paix préférée : une VM tout fraiche. Le temps de l'écrire, le jeu de builds est ok, il faut juste attendre qu'il soit publié (et du coup dodo) (autre Inconvénient transitoire : j'ai coupé mon truc en armhf perso pour le moment) Je migrerai les modules ensuite, c'est sans doute là que je vais avoir le plus d'adaptations à faire. M'enfin ça ne devrait pas pisser trop loin, juste les méthodes de signaux des propriétés indi à modifier il n'y en a plus qu'une pour tous les types de propriétés, au lieu d'une sur chaque type : "updateProperty" En lieu et place de newNumber / newText / newSwitch / ... C'est pas mal en fait. G.

Trop facile d'accuser les autres. La nature humaine est ainsi faite. Bien entendu le problème était derrière le clavier. Quelle andouille. Mais remonter jusqu'à la "dernière version qui marche" avec git c'est super pratique, du coup une fois que j'ai trouvé la modif qui pète la correction a été vite trouvée. C'est publié sur mon ppa, donc amis testeurs...

bonjour à tous j'ai hésité un peu avant de lancer ce sujet ici, à savoir comment j'allais faire etc etc ... Pendant ce temps tout le monde continue à bien dormir sur le fil qui va bien sur l'ASIAIR. Alors mettons les choses tout de suite au clair : Oui ZWO fait du très bon matériel, Oui l'ASIAIR est un formidable appareil, et en plus très abordable, Oui la réactivité, l'écoute et les fonctionnalités sont au rendez vous. (voir le "fil qui va bien" sans aucune ironie) Aucune ambiguïté sur tout ça. Il y a d'abord eu la première version, basée sur un Raspberry Pi tout simple et un boîtier standard rebadgé. Succès moyen mais réel Puis la version Pro, jackpot, succès phénoménal pour un marché de niche comme ça. Boîtier superbe, bel investissement coté hardware avec l'adjonction d'une carte sur le RPi(4) pour distribuer des alims. Enfin la version "plus" annoncée, fébrilité du côté des fanboys (pardon les gars, c'est bienveillant mais ça me fait vraiment marrer juste pour une antenne wifi) Dedans toujours un RPi mais version "compute module" avec un disque eMMc (nous y reviendrons peut-être plus tard) Bref, succès incontestable. A quoi ce succès est-il dû ? Avoir su positionner un produit adapté à l'attente des utilisateurs au bon moment et au bon prix, c'est aussi bête que ça. Au bon prix comment ? En partie en investissement de développement et études, c'est incontestable. Leur Appli sur smartphone est un vrai bijou. Mais en partie aussi en utilisant des composants et des plateformes logicielles déjà existantes, et en ajoutant ce qui leur manquait. Ici je parle bien évidement de la plateforme Indi, mais aussi de plein d'autres car la liste est assez longue (PHD2, Gphoto, astrometry, cfitsio, ...) Lâchons le mot : ce sont des composants opensource. ça signifie quoi ? Prenons l'exemple d'indi (le noyau) Ce sont actuellement 158 contributeurs qui ont bâti Indi avec leurs petites et grandes contributions, et avec leur temps libre et leurs expertises respectives. Gratuitement ou presque. Ils demandent tous par l'intermédiaire de la licence avec laquelle ils travaillent (LGPL2.1) une certaine reconnaissance. Reconnaissance qui se résume à ceci : lorsque vous vendez un truc avec indi dedans, dites-le et mettez une copie de la licence dans votre truc. ça varie un peu selon les librairies (publication du code modifié ou pas par exemple), mais toutes réclament cette reconnaissance (LGPL2.1 / GPL / BSD3 / ...) Et que fait ZWO ? Rien. Nada. C'est évoqué de temps en temps sur leur forum, mais aucune mention officielle, pérenne, assumée . Je m'en suis donc inquiété sur la page de présentation de leur nouveau joujou l'ASIAIR+ Vous avez vu ? Gentil, délicat, posé. Cette question est restée en attente d'approbation quelques jours, puis elle a disparu. J'ai donc à nouveau pris ma plume pour insister un peu sur leur forum https://bbs.astronomy-imaging-camera.com/d/13240-asiair-and-opensource-software-licences Quelques participations d'autre types qui comme moi aimeraient bien avoir une réponse. Mais strictement rien venant de ZWO. Du coup, agacé, je suis allé pleurer chez maman. https://indilib.org/forum/development/10380-asiair-and-opensource-software-licences.html Et c'est là où ça devient navrant. Nada, rien non plus. Manifestement même "la communauté" s'en fout (en tout cas ça en a les apparences). Wait and see, ici aussi. Bref, tout ça pour dire quoi, me direz vous. Juste une chose : Chers utilisateurs du merveilleux ASIAIR qui est allé dans mon panier une bonne centaine de fois sans aller jusqu'au paiement, Chers utilisateurs (bis) : Lorsque vous faites joujou avec cette merveille, ayez une petite pensée pour les centaines (probablement les milliers) de contributeurs anonymes et désintéressés qui y ont participé sans même recevoir un merci de la part de ZWO. Post-postum : Si vous m'apportez la preuve que ces fameuses licences sont publiées et assumées par ZWO je ferai amende honorable en demandant la suppression de ce fil, ce serait la moindre de choses. Amicalement Gilles.

Bonjour mesdames, bonjour mesdemoiselles, bonjour messieurs. Je m'explique. C'est d'abord une marotte qui me fait gamberger et c'est sans doute la raison la plus importante. C'est ensuite une réflexion toute personnelle -aussi- basée sur ma propre pratique bizarre de l'astrophoto Voilà, en gros je trouve complètement superflu de laisser tourner un planétarium ou autre truc orchestrateur (SGP...) et tout ce qui tourne autour pendant toute une session alors qu'il ne sert qu'à deux moments : - la mise en place et l'ajustement des paramètres (mise en station, focus, pointage ...) - la surveillance On va dire que 95% du temps on a une interface graphique qui bouffe des ressources et de la batterie pour rien. (aucune idée de la réelle empreinte que ça a, m'enfin quand même...) Kstars/Ekos et leurs acolytes sont des outils superbes, mais il faut bien se résoudre à avouer que sur un petit Raspberry ça bagotte quand même de temps en temps. Et au prix de la nuit potable, ça commence à faire ch..r. DONC: ça fait quelques semaines que je farfouille un peu partout, et que mon cerveau bout. Il y a les solutions commerciales, type AsiAir ça fait vraiment envie, mais ça manque de fun ces trucs qui marchent tout de suite, là. Ensuite nous avons deux candidats que je trouve exceptionnels - Mobindi de @pludov - AstroPhotoPlus https://astrophotoplus.gulinux.net/ Je fais joujou avec les deux, j'adore. Un seul reproche : Les deux sous traitent la partie autoguidage à un PHD2 qui tourne en cachette Adieu la notion de headless Et puis coté architecture, je pense que ce type de choix augmente le risque de plantage en ajoutant des intermédiaires. Et de fait : je n'ai jamais pu les utiliser en vrai, j'ai toujours eu un truc qui fouarre. Attention, hein, critiquons le bonhome (moi) qui veut bien bidouiller mais pas trop se donner de mal avec ses gros doigts. Autre reproche pour AstroPhotoPlus : pas d'autofocus Rédhibitoire pour moi. Moi je veux appuyer sur un bouton. Bref. Je compte consigner ici mes petites tergiversations, et en particuleir celle qui me travaille depuis aussi depuis semaines. Ma petite contribution à moi. Encore très tôt, et rien de partageable, mais allons-y : Il existe un driver indi nommé "Agent Imager". ça a été la révélation pour moi, ça rentre vraiment pil poil dans ce que je voudrais. Que fait-il ? C'est un driver indi bidon, qui "snoop" un CCD et une roue à filtres On lui programme des séquences, et hop roule ma poule : Tout se passe coté driver, plus besoin de laisser allumé quoi que ce soi, sans fioriture. Et pourquoi il me plait encore plus ? Parce que c'est du C++, et rien d'autre : J'ai essayé de comprendre le fonctionnement de Mobindi et AstrophotoPlus : Python, NodeJS, C'est merveilleux, mais laaaaaargement trop loin de mes compétences en tambouille. Donc en C++ je ne dis pas que je m'y connais, mais au moins que ça discrimine un peu le truc pour mes neurones de 47 piges. Et j'y suis allé de mes petits essais, je commence à piger comment ça marche. L'idée serait d'y aller petit à petit : un agent focuser en premier : ça permettrait de l'utiliser sur Astrophotoplus en palliatif (je suis dessus là 🙂 ) ensuite tout le reste : - agent alignement - agent guideur - etc.. Autant l'alignement et le focus je pense que c'est facilement jouable, autant le guideur ça va être coton. PHD2 est déjà loin devant, mais il est extrêmement difficile de repiquer le code. Bref, c'est le début d'un fil que j’espère au long cours, n'hésitez pas à participer. Gilles.

Salut à tous ça faisait un moment que ça cogitait bien fort, et plusieurs solutions ont été testées. En particulier avec Siril, qui a été mis de coté au profit d'un truc complètement en python. Donc je vous présente "ALS" Astro Live Stacker (ça me faisait marrer comme nom, genre qui se prend au sérieux) C'est quoi ? C'est une application qui permet de surveiller un dossier dans lequel on enregistre des images. A l'arrivée d'une nouvelle image, celle ci est additionnée (stackée) avec le résultat précédent. Deux méthodes sont possibles : - la somme toute bête - la moyenne Pour qui ? Là maintenant, c'est pour les curieux. ça marchouille mais c'est encore plein de truc à faire Nous n'avons pas essayé sur windows, aventuriers de Microsoft, à vos claviers. Linuxiens, ça devrait être plus facile pour vous. Adeptes du VA : surveillez, les gars, ça va vous plaire mais va falloir taper des trucs bizarres. Comment ? Tout est sur mon github https://github.com/gehelem/als Il faut installer quelques modules python : - pyqt5 (GUI) - watchdog (new file checking) - numpy - astropy (to save and read fit file) - tqdm (for %) - astroalign (frame alignement) - cv2 ( TIFF saving and debayering) Puis quelques linuxeries : sudo apt update sudo apt install python3-opencv python3-pip git pip3 install astropy numpy tqdm watchdog pyqt5 astroalign cd ~ git clone https://github.com/gehelem/als.git cd ./als mkdir scan mkdir wrk Pour lancer le machin ça se passe dans un terminal aussi : python3 ~/als/als.py Sur ALS vous spécifiez quel est le "dossier à scanner" puis appuyez sur play Ensuite lancez vos prises de vue pour qu'elles s'enregistrent en fits dans le "dossier à scanner" Le stack se fait au fil de l'eau, et ALS vous affiche l'image. Le résultat est stocké dans le dossier "wrk", en TIFF et en FITS Attention le contenu est supprimé à chaque appui sur "play" A venir Pour les soirées en public : ajout d'un service web pour partager le résultat en live Soustraction d'un dark effectué préalablement Performance Sur nos machines, le débit arrive à suivre à quelques images par seconde. A voir ce que ça donne sur un ARM, nous n'avons pas encore essayé. Ce que ça ne fait pas ça ne prend pas les images, qui peuvent venir de n'importe quoi du moment que c'est des fits Les stack restent volontairement simples -pas de suppression des pixels chauds/frois -pas de normalisation -pas de flat -pas d'offset -c'est pas Siril faut pas rêver 🙂 Format Uniquement des fits. S'ils sont en couleur, ils sont dématricés à la volée On fera peut-être l'effort de traiter les RAW issues des DSLR Last but not least : Grace à qui ? @dragonlost Sans lui, j'y serais encore. J'ai mis plusieurs mois à arriver à des choses qu'il a mis 5 minutes et 30 lignes de code pour tout faire. Sébastien : T'es vraiment mon champion, sans toi je ramerais toujours (à noter que j'ai découvert le python et ses joyeusetés il y a peu, quelle prise de tête !) Gilles + Sébastien

Salut, Je me lance dans un petit bricolage, que bien entendu je ne peux m'empêcher d'exposer ici rapport à ma tendance exhibitionniste. Un servo et un écran électroluminescent 10x10 Je vais essayer, on verra bien, je reposterai la progression. https://youtu.be/5A2bPua31yQ ======================================================================= = Mise à jour récapitulative pour les copains qui ne veulent pas se fader tous les posts = ======================================================================= On va essayer de se lancer dans les explications, que je mettrai à jour au fur et à mesure des questions et avancées importantes. Note préliminaire Je l'écris une fois pour toutes : je ne fais pas de pub pour tel ou tel commerçant, je donne juste des infos plus précises à titre d'exemple. Et si vous vous trompez, ne venez pas me tirer les oreilles : je revendique avec véhémence le droit de me tromper aussi. D'ailleurs tiens, je ferai même exprès de me tromper pour vous obliger à réfléchir plutôt que de cliquer bêtement sur "order" Principe général Je veux que ça reste simple, au moins au niveau électronique. Mécaniquement, chacun verra selon ses possibilités (impression 3D, menuiserie, trombones et shamallow, ...) En gros, il faut un servo, et un arduino qui sont la base de tout le reste. Le servo nécéssite un peu de courant : pour éviter d'avoir à gérer une alimentation externe, on va passer par un Hub USB alimenté. La partie éclairage doit être dimmable, c'est à dire que le dispositif doit pouvoir être commandé en intensité. Choix du servo Tous les servos de modélisme sont des bons candidats : Le gros avantage c'est que leur protocole de commande est universel Il faut tenir compte de deux choses : le débattement que le servo permet : la plupart fait 180°, il en existe de 270° ou 360°. A vous de voir ce qui convient à votre besoin la charge qu'il supporte : si l'écran est léger, pas besoin d'alourdir le nez du télescope avec un servo trop lourd qui ne servira à rien, à l'inverse un servo sous dimensionné aura du mal à faire bouger l'écran Je ne mets pas de référence, il y a tellement de modèles, le choix est immense. (et il ne sert à rien de mettre plus de 10€ là dedans par les temps qui courent) Choix de l'arduino La question n'est pas anodine. Ici aussi on devrait pouvoir dire que n'importe quel arduino "classique" fera l'affaire. C'est le cas, mais en pratique ça peut parfois poser quelques problèmes. Je recommande (ça n'engage que moi) les arduinos basés sur un Atmega32u4 Pourquoi ? Ce microcontrôleur intègre nativement la couche de communication USB, il n'y a donc pas de tambouille sur l'arduino pour qu'il supporte l'USB. A l'inverse des arduinos basés sur l'atmega328 (Arduino Uno) ou Atmega2560 (Arduino Mega,) sur lesquels une puce supplémentaire est ajoutée pour transformer les instructions qui arrivent par l'USB en instructions RS232. Cette puce n'est pas toujours la même d'un fabriquant à l'autre (les plus courantes : FTDI, CH340) Ce qui pose problème, c'est une facécie concepteurs de l'Arduino : lorsque la communication série est initiée, la puce supplémentaire demande un Reset de l'Arduino. ça n'a l'air de rien, mais c'est une vraie vacherie, on en reparlera (ceci dit il y a sans doute une raison bien précise, hein...) Donc, mon conseil : Le plus petit des arduinos basés sur un Atmega32u4 = Arduino pro micro ou Arduino pro mini La dénomination est un peu variable, assurez-vous juste d'en prendre un qui contienne cet Atmega32u4 Actuellement, 6€ sur eBay : lien Bon maintenant si vous avez un stock d'arduino uno/nano et compagnie, ça ne vous met pas hors de course. On fera un topo spécial là dessus. Eclairage - version led Je ne suis pas fan des bandeaux à led qu'on commence à trouver un peu partout, mais je ne demande qu'à être convaincu du contraire. Moi, je fais dans le classique : On trouve partout des lots de leds blanches, qu'on peut monter comme on veut 4€ les 100 (oui oui) sur eBay : lien Eclairage - version panneau electroluminescent -- à compléter, vu que en fait c'est peut-être pas très simple à dimmer ces affaires -- Branchement du servo sur l'arduino Pour fonctionner comme suit, l'arduino doit être branché avec un HUB USB alimenté. Tous les servos se servent de trois fils. Une masse (fil noir) = le - Un VCC (fil rouge) = le + Un signal (orange, blanc, ou autre que noir ou rouge) Pour le branchement, je vous propose donc ce qui suit : Fil noir - la masse sur "GND" en haut à droite Fil rouge - VCC sur "RAW en haut à droite Fil blanc/orange/autre - Signal sur le pin 9 en bas à gauche (Ce dernier peut être différent, dans ce cas il faut modifier le programme qu'on charge dans l'arduino) Branchement de l'éclairage sur l'arduino Le controle de l'éclairage doit se faire par une sortie "PWM" de l'arduino. ça signifie que cette sortie ne foncionne pas juste en tout-ou-rien, elle permet de restituer une tension qu'on peut faire varier par programmation. On choisit le pin 6 (A7) du schéma ci-dessus. Attention Cette sortie ne peut pas raisonnablement délivrer plus de 20mA Donc ça suffit pour une simple led pour les tests, mais il ne faut pas s'imaginer de commander en direct une guirlande de noël avec. C'est juste un signal de commande qui sort à cet endroit, on s'en sert pour piloter notre éclairage (voir plus bas) Electronique de commande de la variation de l'éclairage -- à compléter -- Programmation de l'arduino Je ne documente pas la façon de programmer un arduino, c'est bien documenté de partout. Je mets juste les sources du seul fichier nécéssaire En attendant que les modifications soient validées par l'auteur original : https://github.com/gehelem/ArduinoLightbox/blob/master/LEDLightBoxAlnitak.ino Topo spécial arduino uno/nano -- à compléter --

bonjour, actuellement j'ai ceci : et pour augmenter mon WAF, je projette d'y mettre ceci à la place : (enseigne de bricolage quelconque, version pour enfants) C'est juste pour protéger l'instrument et pouvoir dégainer/rengainer plus rapidement les soirs de semaine qui correspondent à cet état d'esprit : Mardi, 23h, levage de tête, "zut, si j'avais su j'aurais sorti le matos", plus d'énergie, dodo. Donc je me disais que ces petites maisons ma faciliteraient la vie avant : tout est prêt, plus qu'à ouvrir le toit et appuyer sur "On", Et après : "Off" et fermeture du toit . Pas envie/besoin de visuel, rien que pour le remote. (j'y mettrais bien un couche isolante à l'intérieur) En gros, un truc comme ça : https://stargazerslounge.com/topic/198091-a-remote-unmanned-pico-observatory/ Du coup la question : Niveau encombrement c'est au chausse pied. Y a-t-il des combines pour savoir exactement de quel volume j'ai besoin ? Cette question a déjà été couverte ici, mais la plupart du temps c'est la méthode empirique. Au jugé c'est facile à estimer, mais comme j'ai plusieurs optiques et que je veux vraiment que ce soit minimal, je me demandais s'il n'existe pas un petit logiciel ou une astuce élégante et raffinée Merci d'avance pour vos conseils Gilles.

salut à tous, je récapitule : Nous avons donc l'ED72 qui ira sur la NEQ5 avec son AstroEQ. Puis l'ED80 qui campe depuis un moment sur son EQ6. Parfait, mais le C11, hein ? Comment je fais pour ne pas passer pour un pinpin aux RAP ? Et bin je me dégotte une CI-700 d'occaz. C'est quasi fait. Voilà. (mais vu que d'ici là de toutes façons je n'aurai toujours pas réussi une seule photo, je passerai pour un pinpin, donc...) Vous connaissez cette monture ? On trouve peu de retours dessus, c'est une G11 qui aurait eu moins de succès... En face il y a quelques remontées antédiluviennes, mais rien de récent : Le silence lié à la convoitise, certainement. Vous la connaissez ? Z'en pensez quoi ? Je vais y coller des vrais moteurs, façon AstroEQ (ou OneStep on verra) Merci de vos retours Gilles.

C'est Noël, j'ai 45 ans, et ma tendre épouse a encore tapé dans le mille. Je me suis couché à 3h du matin, bien obligé de m'arrêter au paquet numéro 9 sur 12 car les pièces me tombaient des doigts. Et avec le pull de Papy pour faire la Lune : ça m'a donné envie d'ouvrir un fil sur les trucs en Légo qui causent de l'espace... Pas besoin de présenter :

Bonsoir à tous, ça fait 15/20 ans que j'ai ce montage dans la tête. Je ne sais pas du tout où ça va me mener, mais j'ai enfin passé le cap de la réalisation cet après midi. Je me suis bien amusé cet après midi, le cœur battant, et cette ritournelle dans le crane : "ha mais si ça marche, si ça marche !!!...." De quoi s'agit-il ? En fait, c'est un montage qui s'inspire de l'interféromètre de Michelson. L'un des renvois coudés est fixe, l'autre est mobile sur le Crayford. Bien entendu, la vision est faite sur le coté, hein, c'est un télescope pour regarder dans les coins. L'idée, c'est que ce montage permet d'insérer une différence de marche sur l'onde selon qu'elle passe dans l'un ou dans l'autre. L'image qui se forme au foyer du télescope a donc deux composantes, dont l'une est déphasée par rapport à l'autre en fonction de la position du Crayford. Et selon ce déphasage, et bien paf, interférence constructive ou destructive, etc, etc... (comme dans un Michelson avec une lame séparatrice et un miroir mobile). Ce que je voudrais obtenir dans un premier temps, c'est constater que si j'observe un lampadaire au loin, je peux voir la variation de luminosité en fonction du déplacement du Crayford. Ensuite, "si jamais ça marche", il faudra s'attaquer à Monsieur Fourier. Faire des séries d'images du lampadaire ou des étoiles (héhé), avec un déplacement contrôlé, et avoir en quelque sorte un "film interférogramme". Il ne reste qu'à calculer la transformée de Fourrier d'une zone pour avoir le spectre. Délire ? J'en sais rien, on verra bien. L'aspect théorique m'intrigue. Pendant mes années d'étude, je pense que j'aurais été en mesure de faire tous les petits calculs qui vont bien pour savoir si je déraille. Mais j'ai beaucoup perdu, et rechercher ces trucs sur Google ne suffit pas, il faut un investissement intellectuel. Après une semaine de boulot, ma tête dit "non, je préfère couper du bois" Les cagades auxquelles je m'attends : - l'alignement de tous les axes va être coton. En premier lieu, il faudra aligner le déplacement du crayford en parallèle de l'axe optique. Puis ajuster le miroir fixe pour qu'il pointe au même endroit. J'ai prévu tout ça, mais Sera-ce assez précis ? mystère.. - Flexibilité du montage. normalement, un Michelson, c'est sur un banc optique. Sans commentaire. là c'est du medium 19mm - traitement informatique. une moooontagne. - impacts de la turbulence, faudrait pas confondre les fluctuations d'intensité liées à la turbulence avec des interférences... J'y ai pensé, il me faudrait un troisième canal de référence, peut-être avec un troisième miroir. Au fait, "FTTI" = Fourrier Transform Telescope Interferometer on s'amuse comme on peut. Gilles.

bonjour à tous, j'avais dans mes tiroirs depuis longtemps ces petites choses : Que je destinais à monter sur cette vieille chose : (vous avez vu la poussière ?) J'ai gambergé dessus toutes mes vacances. Rentré il y a peu, j'en pouvais plus je me suis lancé. Je ne suis pas le premier à la monter, et sans doute pas non plus le dernier, mais je voulais partager ça avec vous. Il s'agit donc d'une interface EQMOD DIY faite sur la base d'un Arduino Mega2560. Tout est parfaitement décrit sur le site de son géniteur, Thomas Carpenter, ici : https://www.astroeq.co.uk/tutorials.php Il y a même un forum, j'en aurai sans doute besoin, on verra. C'est un peu l'équivalent du PicAstro : je n'ai pas creusé, je ne connais pas les différences. J'ai choisi celle-là parce que le fait de prendre un Arduino comme base rend le travail beauuuuuuucoup plus facile. Je vous tiendrai au courant de l'avancement, pour cet après midi on s'est attaché à l’électronique. Quelques soudures à la portée de tout le monde, et hop : Que dire : c'est vraiment très simple à monter, j'ai commandé les PCB en chine je ne sais plus où (il m'en reste 2, PM si ça vous intéresse). Je n'ai pas mis : - la prise ST4 qui ne me servira sans doute jamais - la diode de protection, c'est mal mais j'en avais pas. => En 2 petites heures, me voilà avec une carte branchée en USB aux deux moteurs d'origine de la vénérable EQ5, mais qui causent désormais en EQMOD. Bien entendu, j'ai testé ça sous Indi (équivalent de Ascom sous linux) ça marche comme une fleur. La petite difficulté qui viendra sera sans doute de piger comment on ajuste le courant sur les drivers. Prochaine étape, celle que j'aime pas, adapter les moteurs pas à pas plus puissants (voir photo ci-dessus) avec les courroies et tout ça sur la monture. Keep in touch Gilles.