mala05

Oui deux pignons de 40 dents sur l'EM-200 Pascal. Soit 480/40=12 secondes par dent avec une période de rotation moteur de 8 min. Sur l'EM-10 c'est deux pignons de 36 et 45 dents ce qui donne une démultiplication supplémentaire de 1.25x et amène la vis sans fin à 10 min de période de rotation.

Je n'ai pas de réponse à t'apporter n'ayant pas d'AZ-EQ5 mais le sujet m'intéresse aussi. C'est apparement devenu la grande mode des courroies sur les montures récentes et j'avoue que je reste un peu dubitatif concernant la tenue des réglages et le vieillissement dans le temps . Et sinon pour culture, les taka aussi ont ce genre d'erreur du fait du changement de dents des deux engrenages liant le moteur à la vis sans fin. J'ai mesuré une EM-200 récemment et cette erreur tournait autour de +- 0.7" d'amplitude avec une périodicité de 12s...

Merci Pascal. La caméra est reliée au Raspberry (ici un PI 3 monté dans le boitier blanc). Dans un premier temps je pense faire en sorte que le PI serve de serveur de prise de vue uniquement. Les images seront analysées par mon PC portable en wifi. Cela devrait faciliter les devs car bon Raspbian c'est bien gentil pour bidouiller mais loin d'être au top en terme d'éditeur de code et d'outils de déboggage. A terme l'idée ultime serait de pouvoir prémacher les données (analyse de la taille et de la disposition des étoiles) sur le PI et d'envoyer les infos via liaison série vers l'Arduino Due de ma raquette de commande pour affichage schématique. Ainsi l'EM-10 resterait 100% autonome sans PC et c'est ce que je souhaite conserver à tout prix avec ma petite nomade.

Repassage à la peinture pour une seconde couche suite au test de la veille. Là ça devrait être au poil... Et voici une mise en situation de l'intégration pour mon futur viseur polaire numérique maison...

Première lumière avec M42 pour tester le mini objectif CS 25mm F/1.2. Assez bluffant pour 7€!!! Je suis très agréablement surpris. L’adaptateur fait très bien le job. Par contre en faible flux, j’ai l’impression que la lumière de la led rouge à proximité du capteur arrive légèrement à passer (tâche blanchâtre en bord d’image à gauche) à travers le coffrage malgré la peinture noire. Je vais devoir repasser une seconde couche voire carrément peindre la led pour être tranquille.

Merci Jijil. C'est un choix esthétique pour être raccord avec les autres impressions 3D qui équipent déjà ma monture et le tube optique...

Maintenant que j'ai motorisé la MAP de mon CN212 j'ai l'impression de régresser quand je passe sur le u250. Je pense m'y coller un de ces quatre mais j'ai encore pas mal à faire sur l'EM-10 avant.

Je présume qu'ils se sont basés sur ce genre de document pour les calculs de compensation en élévation... http://adsbit.harvard.edu/cgi-bin/nph-iarticle_query?1996PASP..108.1051S&defaultprint=YES&filetype=.pdf

Pour ceux que cet écran RA8875 intéresse, j'ai publié sur mon github une version améliorée du code d'adafruit... https://github.com/MarScaper/Adafruit_RA8875 Le tactile a été revu avec une fifo circulaire afin de réaliser une moyenne glissante pour limiter le bruit.

Utopix03, 11m de focale cela ne veut pas dire grand chose. -de plus l'info a été indiquée par Pascal après mon message. - C'est l'échantillonnage visé qui importe réellement. Je reste réservé quant-à l'obtention d'un bon suivi en DVSF (Direct Visse Sans Fin et non Direct Drive si j'ai bonne mémoire de nos échanges avec Pascal) avec un moteur PAP (Nanotec ST5709S1208, 400 pas par tour comme celui de la manip de DBlatte en 2016? ) sans étage de démultiplication.

Attention aux raccourcis trop rapides. L'utilisation de drivers en mode upas réduit très considérablement les vibrations mais de là à dire qu'ils les supprimes totalement c'est aller un peu vite en besogne. Il y a aussi les engrenages de démultiplications qui peuvent générer des vibrations mécaniques. A cela s'ajoute que l'usage du Goto force les constructeurs à faire le grand écart entre précision et vitesse. Il n'est donc pas rare que l'électronique puisse passer à la volée de upas pour le suivi à du fullstep biphasé pour un couple maximum en goto.

Quelques news du projet. Je démarre la nouvelle raquette de commande. Après différents essais d'écrans, je pense avoir trouvé mon bonheur avec un TFT 4,3’’ de 480x272 pixels. Couplé à un Arduino Due (le plus puissant Arduino actuel équipé d'une puce ARM 32bits à 84Mhz) j'ai là une bonne marge de manoeuvre pour développer le "cerveau" de la monture. Mon idée est de réaliser une raquette de commande qui ressemble un peu à une console de jeux portable en format paysage. Après la Nintendo Switch voici donc la naissance de l’Astro Switch... La puce GPS de l’ancien prototype va être réimplantée dans la raquette... Un aperçu de l’adaptation de l’abaque numérique de l’EM-10 calé sur les données de la puce GPS (lumière bleue à l’intérieur du boitier)... Je pense y ajouter à terme un mini pad pour faciliter la navigation en complément du tactile. La raquette communiquera par liaison série avec la carte MKS de la monture sur la base du protocole LX200GPS (avec sans doute quelques addendum spécifiques à mes besoins). A suivre...

Non Xavier. Le corps plus petit de l'EM10 ne lui permet pas d'accueillir le viseur polaire de l'EM200. Il y a certes le côté bidouille qui me plait. A cela s'ajoute qu'un RPI Zéro avec sa caméra devrait pouvoir s'intégrer complètement dans la monture. Ici un aperçu... donc en plus, pas de pièce rapportée pour la manip. Cela devrait être très discret.

Système très efficace mais inutile avec une EM200. Le viseur polaire de l'EM200 demande moins d'une minute pour mise en station au poil... Perso, j'envisage de me bricoler un viseur polaire numérique pour mon em10 à terme avec un Raspberry Pi + camera PI et objectif de 25mm. Cela permettrait de libérer l'axe polaire pour mettre des moteurs plus puissant. D'autant que le viseur polaire de l'EM10 nécessite un abaque et les gravures s'arrêtent en 2015.

Non pas le moins du monde. Moins l'autoguidage est sollicité et mieux c'est. Surtout qu'ici il est question de montures supportant des charges lourdes donc bien souvent avec des focales importantes et l'échantillonnage qui va avec. Pas mal de marques intègrent des systèmes PEC avec pré-calibration en usine sur leurs montures haut de gamme.

FroggySeven, une monture équatoriale est bien plus simple à corriger au niveau suivi pour faire de l'imagerie longue pose. Avec une monture azimutale on se retrouve a devoir corriger trois axes combinés (azimut, élévation et rotation). Un système PEC par exemple est relativement facile à mettre au point sur une monture équatoriale puisqu'on va avoir besoin d'enregistrer et de corriger seulement l'ascension droite. Avec une monture azimutale c'est une autre paire de manches...

Merci les gars! Superfulgur, chez moi avec écran calibré cela passe au poils. Idem sur iPad avec un rendu très proche de la réalité comme j'aime. Certaines zones sont un peu cramées comme Tycho et Aristarque mais je n'ai pas voulu faire joujou avec des masques. Cela vaudrait peut-être la peine de retoucher avant tirage.

Histoire de se dérouiller un peu, un quartier de Lune fait ce weekend... Mosaïque de 8 clichés. 5D Mk III - CN 212 Takahashi à F/12,4 - Réducteur F/9.9 - EM-10 MKS 400 Iso - 8 x 900 images - 1/200s en vidéo Raw. Zoom vidéo Magic Lantern 3x. Lien vers la full: >>>> ici <<<<

Balade Lunaire de ce weekend. Un plaisir avec la nouvelle électronique... Et la mosaïque issue de la séance... Mosaïque de 8 clichés. 5D Mk III - CN 212 Takahashi à F/12,4 - Réducteur F/9.9 - EM-10 MKS 400 Iso - 8 x 900 images - 1/200s en vidéo Raw. Zoom vidéo Magic Lantern 3x. Lien vers la full: >>>> ici <<<< J'ai commencé à coder le support du protocole LX200GPS. Il me tarde de pouvoir automatiser la prise de vue des mosaïques en pilotant de concert la monture et l'APN.

Je me rappelle que j'avais acheté mon Mewlon 250 il y a une quinzaine d'année à une personne sur Metz qui possédait également un Epsilon 250. Je serais pas étonné que ce soit lui vu la rareté de la bête. A défaut de pouvoir te donner son adresse, je dois pouvoir te retrouver son nom sur la facture du Mewlon. Envoie mon un MP en cas si tu le retrouve pas. Je regarderais dans mes archives.

Très joli shoot polo! Ma préférence va vers les deux dernières versions proposées par ValereL et ms où je retrouve la perception de la vision à l'oculaire. Voici une proposition tirée du tif brute de ValereL pour jouer avec vous. Filtre passe haut on ne peut plus basic sous Aperçu avec 4 itérations. Ajustement de la balance et des seuils. Cela mériterait peut être un poil de débruitage sur les basses fréquences du globe et des anneaux.

Voici un billet issu de mon blog qui pourra intéresser les arduineurs qui bidouillent avec les timers... Lors de l’écriture de la librairie RunLoop pour Arduino, j’avais constaté à l’époque un décalage sur les timers hardware entre la période demandée par le programme et la périodicité réellement constatée en sortie avec l’analyseur logique. Le problème c’est que toutes les librairies testées avaient le même décalage que moi: un peu plus de 3us!!! Cela peut paraitre ridicule vu de loin mais pour des fréquences dépassant le KHz, l’erreur est de plus en plus problématique si l’on a besoin de précision. Hors en astronomie, pour le pilotage des moteurs pas à pas, la précision est de rigueur. A l’époque, j’avais donc intégré ce décalage dans RunLoop en l’estimant de manière empirique autour des 3,3us. Et voilà qu’aujourd’hui, je viens de tomber sur l’excellentissime blog de Bill Grundmann! Si vous lisez l’anglais, c’est par ici que cela se passe: The overhead of Arduino Interrupts Pour résumer: il a étudié le phénomène à l’oscilloscope et décortiqué le code assembleur de la librairie Arduino. Et effectivement, la levée d’interruption entraine un surcout de 55 cycles! Soit 55*0,0625 = 3,4375us précisément!!! Hors faute de le savoir, les librairies qu’on trouve sur le net n’en tiennent pas compte. Et bim! J’ai donc le plaisir de vous annoncer que je viens d’en profiter pour affiner encore un peu plus le code de RunLoop et de le publier sur mon github. Un test à 20Khz, montre maintenant une périodicité quasi parfaite à +-40ns près d’après l’analyseur logique (hors avec ses 12MS/s max on est dans la limite de précision d’échantillonnage donc même pas sûr que la variation résiduelle soit réelle). Note: en toute logique, le phénomène constaté n’est présent que pour des timers hardware levant une interruption au niveau logiciel. Je ne pense pas qu’un usage en PWM soit concerné. Veni, vidi, vici et big up à Bill!

Activité du moment, mettre au point un algo de prédiction pour le goto...

Ephemeris m'avait demandé un bon mois de codage assidu à l'époque en me basant sur l'ouvrage de Jean Meus. A ma connaissance c'est l'une des seules si ce n'est la seule librairie C++ compatible avec les architectures 8bits qu'on trouve sur Arduino. J'avais été contraint d'optimiser certains thermes de la théorie VSOP87 pour que ça rentre en 32bits (la dynamique max pour l'encodage d'un nombre décimal sur Arduino). Les méthodes vraiment intéressantes dans l'immédiat pour toi c'est: /*! Set location on earth (used for horizontal coordinates conversion). */ static void setLocationOnEarth(FLOAT floatingLatitude, FLOAT floatingLongitude); /*! Convert equatorial coordinates to horizontal coordinates. Location on Earth must be initialized first. */ static HorizontalCoordinates equatorialToHorizontalCoordinatesAtDateAndTime(EquatorialCoordinates eqCoordinates, unsigned int day, unsigned int month, unsigned int year, unsigned int hours, unsigned int minutes, unsigned int seconds); /*! Convert horizontal coordinates to equatorial coordinates. Location on Earth must be initialized first. */ static EquatorialCoordinates horizontalToEquatorialCoordinatesAtDateAndTime(HorizontalCoordinates hCoordinates, unsigned int day, unsigned int month, unsigned int year, unsigned int hours, unsigned int minutes, unsigned int seconds); Je t'envoie mon mail en message privé. J'essaierai de te donner des pistes. C'est clair qu'en Alt/Az tu dois à la fois assurer le suivi sur deux axes et à cela s'ajoute la rotation de champ. Donc tu as déjà 3 timers hardware de monopolisés et dont les modulations de vitesse doivent être synchronisées en fonction des coordonnées AD/Dec. Jette un oeil aussi sur ma librairie RunLoop: >>>> voir ici <<<< Elle permet notament de jongler facilement avec les timers sans devoir installer 36 librairies. Et si ce n'est déjà fait. Equipe toi d'une analyseur logique comme celui-ci. Coder le pilotage de drivers sans voir ce qu'il se passe réellement en sortie c'est comme faire de la cuisine sans jamais mettre les doigts pour goûter... Lol

Merci les gars. brizhell, ce n'est pas prévu en ce qui me concerne même si techniquement ce serait assez facile à faire vu que j'ai déjà codé toute la partie conversion Equa/Azim dans la librairie Ephemeris. D'ailleurs certains utilisent déjà ma librairie sur leur Dobson pour l'aide au pointage en Alt/Az. Je pense notamment au Dobson maison de Bram van Zoelen: >>>> voir ici <<<<