mala05

Membre
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    573

  • Inscription

  • Dernière visite

  • Last Connexion

    Soon available - 49925

Messages posté(e)s par mala05

  1. Posté(e)

    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... ;)

  2. Posté(e) · Modifié par mala05

    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. :x

  4. Posté(e) · Modifié par mala05

    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.

     

    d28b6479.jpg

     

    d28b6475.jpg

     

    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.

  6. Posté(e)

    Voici une réalisation qui pourra sans doute intéresser d’autres hackers. Il s’agit d’un adaptateur d’objectif CS pour modifier une caméra IR de Raspberry grand angle de ce type...
    https://fr.aliexpress.com/item/Raspberry-Pi-Camera-better-than-the-original-one-HD-5-megapixel-OV5647-sensor-adjustable-focus-for/32683743922.html?spm=a2g0s.9042311.0.0.8a956c37Ta1GXg

    L’intérêt? Et bien les capteurs avec monture CS sont plus chers. Une fois l’adaptateur réalisé, on peut par exemple utiliser cet objectif 25mm F/1.2 à moins de 7€ frais de port inclus...
    1/3 "25mm CCTV Objectif vue 70 m 11 degrés F1.2 IR Fixe Iris CS Mont pour CCD de Sécurité caméra

     

    d28b6411.jpg

     

    L’objectif ce visse directement sur l’adaptateur...

    d28b6409.jpg

     

    L’adaptateur est équipé d’un coffrage du capteur pour l’isoler au mieux des lumières parasites (j’ai ensuite peint l’intérieur en noir mat bien évidement)...

    d28b6422.jpg

     

    On peut réutiliser les deux vis de l’objectif d’origine pour fixer le capteur et solidariser le pied de test...

    cs-mount-back.jpg

     

    Le passage de la nappe peut être placé en haut comme ici (le capteur est tête en bas) ou bien en bas (la nappe se glisse alors par le pied)...

    cs-mount-front.jpg

     

    L’ensemble a été pensé pour une impression zéro support...

    cs-mount-simplyfy-3d.jpg

     

    Voili, voilou. Je réfléchi tranquillement à réaliser un viseur polaire numérique intégré à l’EM-10 avec un Raspberry PI Zéro et le tout à moindre frais (<50€). 

    Le modèle 3D est dispo sur mon compte thingiverse...
    https://www.thingiverse.com/thing:3277107

     

    • J'aime 1

  7. Posté(e)

    Le 21/06/2018 à 13:40, christian viladrich a dit :

    D'ailleurs si un génie de l'électronique/informatique avait une idée pour remplacer le moteur d'origine par un moteur pas à pas piloté par ASCOM, il serait grandement remercié :)

    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.

  8. Posté(e) · Modifié par mala05

    Il y a 10 heures, aubriot a dit :

     

    quelqu'un a t'il un lien sur l'influence des éléments "metéos" sur une monture équatoriale ? .

    j'ai la MBox d'astromi.ch et je voudrais connaitre le fonctionnement et les corrections apportées .

     

    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

  10. Posté(e)

    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.

  11. Posté(e)

    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.

  12. Posté(e)

    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... ;)

    45133532_1920219131424506_24194444432213

     

    45208529_1920220201424399_38657770123165

     

    45097334_1920220318091054_56666348007068

     

    La puce GPS de l’ancien prototype va être réimplantée dans la raquette...

    46091030_1937438619702557_88681778935832

     

    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)...

    45901935_1937438953035857_13428450915799

     

    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...

    • J'aime 4
    • Merci 1

  13. Posté(e) · Modifié par mala05

    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...

    rpi-zero.jpg.7cc12a3ba568bdce958c12947a39fc1f.jpg

    donc en plus, pas de pièce rapportée pour la manip. Cela devrait être très discret.

    • Merci 1

  14. Posté(e)

    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.

  15. Posté(e)

    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.

    • Merci 1

  16. Posté(e)

    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...

    • J'aime 1
    • Merci 1

  17. Posté(e)

    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.

    • Merci 1

  19. Posté(e)

    Balade Lunaire de ce weekend. Un plaisir avec la nouvelle électronique... :)

     

    Et la mosaïque issue de la séance... :)

    lune-30-09-18-cn212-red10-ml3x-w1024.jpg

    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.

    • J'aime 1

  20. Posté(e)

    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.

  21. Posté(e) · Modifié par mala05

    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.

    Sat_212054_pipp_g4_ap85.jpg.3369214ae95544f8418f7c9c54aa84ed.jpg

    • J'aime 2
    • J'adore 1

  22. Posté(e) · Modifié par mala05

    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. 

    runloop.jpg

    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).

    50us-20khz.jpg

    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! :)

    • Merci 2

  24. Posté(e) · Modifié par mala05

    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

  25. Posté(e)

    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 <<<<