Aller au contenu

Messages recommandés

Posté

 

Bonjour à tous,

 

J'ai en projet de faire un module basé sur Arduino qui réalise 2 fonctions intervalomètre et dithering entre les poses.

Il est destiné à être installé sur une monture ayant une entrée ST4. Pas d'ordinateur, pas de grosse batterie, juste un écran LCD, quelques boutons et 3 câbles pour brancher le tout (alim, APN et monture).

 

Alors je vois certains qui me diront : pourquoi seulement ça et pas d'autoguidage ?

 

La réponse est que : je veux du simple. On pose la monture, on fait la mise en station, on cadre et on shoote. Pas de prise de tête avec une caméra d'autoguidage, la recherche d'étoiles guide et les ajustements d'autoguidage & co. Par contre le dithering est absolument nécessaire pour faire des photos potables.

 

La solution doit prendre en compte le dithering en AD uniquement vu que les montures auxquelles il est destiné n’ont pas de motorisation en DEC.

 

Il ne me reste qu'à bricoler le tout !

 

Mais si d'autres ont déjà fait ce type de montage, histoire de ne pas réinventer le fil à couper le beurre, c'est l'occasion d'en parler ici 😉

 

Les paramètres à prendre en considération sont :

 

Optique et acquisition

- ouverture de l'optique

- focale de l'optique (en mm)

- taille des photosites du capteur (en µm)

 

Monture

- facteur de sur/sous vitesse ST4 (généralement 0,5 mais ça peut être paramétré différemment selon les montures et le choix sur la raquette, par exemple 0.25, 0.75, 1.00 *)

- nombre de pixels de dithering

 

Avec ces paramètres on peut calculer :

- la durée maximale de dithering (cf. détails dans mes réponses plus bas)

 

Le protocole ST4 fonctionne en tout ou rien. Donc si on donne l'ordre d'aller plus vite en AD, la monture va simplement tourner plus ou moins vite (de 1x ou 0x la vitesse sidérale généralement, mais certaines montures permettent d'avoir un contrôle sur cette vitesse depuis la raquette) jusqu'à ce qu'on arrête de donner l'ordre. On peut donc juste contrôler la durée du dithering.

 

Ensuite on saisi les paramètres de la prise de vue

- délai avant de lancer la séquence (en s)

- nombre de poses

- durée d'une pose (en s)

- attente entre la fin du dithering et la pose suivante (en s), ça permet de laisser le temps à la monture de se stabiliser

- nombre de poses entre deux dithering

- temps d'attente après la levée du miroir avant de prendre la photo (dans le cas où on a activé l'option sur son boitier)

 

Toutes les valeurs devront être stockées pour ne pas avoir à les ressaisir à chaque fois.

 

Développements ultérieurs possibles :

- dithering en AD+DEC => cela dit, comme le Dithermeter est surtout destiné aux petites montures ultraportables qui ne suivent qu'en AD, ce n'est pas du tout la priorité.

- enchaîner des séries avec des temps de pose différents => mais ça risque de compliquer inutilement l'interface... pas prioritaire non plus

- capteur de proximité pour n'allumer l'écran LCD que lorsqu'on est à côté du boitier, histoire d'économiser les batteries => j'ai reçu le capteur VL53L0X, la carte mère a déjà les trous prévus pour le brancher, yapuka programmer et tester, cela dit cette puce microscopique impose un driver énorme pour l'Arduino et prend beaucoup de place en mémoire...

 

Voilà !

 

A+

 

Fred

 

  • J'aime 2
  • Fred_76 changed the title to Dithering et Intervalomètre Autonome en Arduino
Posté

Bonjour,

 

L'idée est bonne et je pense qu'elle sera utile à quelques personnes.

Il doit probablement exister des débuts de solutions, mais je n'ai pas trouvé après une rapide recherche.

 

J'ai réalisé le montage électronique présenté dans ton lien "arduino-st4" avec un "TLP620-4(F)" (dispo sur RS) : je te confirme que ça fonctionne bien.

J'ai modifié ma raquette pour ajouter un port ST-4 à l'aide de ce lien : https://stargazerslounge.com/topic/180630-eq5-dual-axis-st-4-guideport-mod/

 

J'ai plus tard rajouté un "SFH615A-2" selon le même principe pour déclencher des prises via la prise intervallomètre de mon APN.

J'ai préféré mettre un optocoupleur plutôt qu'un transistor. J'avais peur de générer du bruit avec le partage de masse. Mais je pense que l'APN intègre déjà un optocoupleur en interne.

 

Je travaille en Python sur Raspberry (GPIO en 3.3V). Je n'ai pas implémenté de dithering. Je fais principalement une sorte de "Push-To rapide puis Go-To lent" avec plate-solving sur EQ-5 sans GoTo, via une console SSH sur mon Smartphone.

 

Peut-être devrais-tu contacter @Dav78 qui avait évoqué l'idée il y a pas mal de temps :

 

Posté

Merci

 

Donc si j'ai bien compris, le protocole ST4 est des plus basiques :

 

PORT AUTOGUIDAGE ST4

Le port d’autoguidage est un connecteur RJ12. Vu de face sur la monture  (détrompeur du RJ12 femelle en haut) et en partant

de la droite voici la fonction de chaque broche :

1. Non utilisé (mais parfois représente la broche d'alimentation pour certaines montures)

2. Masse 0V

3. AD+

4. DEC+

5. DEC-

6. AD-

 

Sur certaines montures, il y a inversion 3<>6 et 4<>5 mais ça ne change pas le principe du dithering (on s'en fout que ça aille dans un sens ou l'autre).

 

La commande est activée quand il y a contact entre l'un des 4 ports 3/4/5/6 avec la masse 2.

 

Wiring

 

Par contre, quand on voit DEC+ (ou AD+), à quel incrément de vitesse cela correspond, est-ce que ça dépend de la monture ou bien est-ce une valeur identique (en deg/min ou en x vitesse sidérale) pour toutes les montures ?

 

Posté

Je valide ta description du ST-4. Il s'agit bien de mettre à la masse un ou plusieurs des pins AD+ -/DEC+ -.

L'ordre des pins peut être différent d'une marque à une autre : https://www.cloudynights.com/topic/592439-cable-connections-for-autoguiding/?p=8365272

 

Il y a 3 heures, Fred_76 a dit :

Par contre, quand on voit DEC+ (ou AD+), à quel incrément de vitesse cela correspond, est-ce que ça dépend de la monture ou bien est-ce une valeur identique (en deg/min ou en x vitesse sidérale) pour toutes les montures ?

Il se peut que je dise des bêtises car je n'ai pas une monture avec ST-4 d'origine mais j'ai bricolé comme ceci https://stargazerslounge.com/topic/180630-eq5-dual-axis-st-4-guideport-mod/

 

Dans mon cas, les impulsions données sur le port ST-4 actionnent les moteurs à la vitesse sélectionnée sur la raquette.

Je peux la régler sur 2x, 4x ou 8x la vitesse sidérale.

J'ai fait les mesures et calculs : la vitesse de déplacement est la même en AD et en DEC, à savoir :

Vitesse 2x = 0,0083333... degrés/seconde

Vitesse 4x = 0,0166666... degrés/seconde

Vitesse 8x = 0,0333333... degrés/seconde

 

Ce réglage de vitesse doit être un paramètre d'entrée du programme. Attention, en RA+ il faut ajouter +1 (et enlever 1 en RA-) car la monture se déplace déjà à vitesse sidérale x1.

Ici la raquette est réglée sur vitesse 8x :

GitHub - kevinferrare/arduino-st4: A PC-Telescope interface built around an  arduino

image.png

PS : pour ton application, il te sera particulièrement utile de prendre en compte le "backlash" de la motorisation chaque fois que tu changeras de sens de déplacement pour un axe donné.

Un paramètre de configuration peut être utile. Sur ma monture je l'ai grossièrement estimée à 0.8 seconde d'impulsion en vitesse 8x.

Posté
Le 14/05/2021 à 19:32, Eridan31 a dit :

PS : pour ton application, il te sera particulièrement utile de prendre en compte le "backlash" de la motorisation chaque fois que tu changeras de sens de déplacement pour un axe donné.

Un paramètre de configuration peut être utile. Sur ma monture je l'ai grossièrement estimée à 0.8 seconde d'impulsion en vitesse 8x.

 

Oui, c'est certain. Mais ce n'est pas super simple à implémenter car ça dépend beaucoup de l'équilibrage de la monture et des défauts des engrenages et VSF (notamment un voilage : le jeu va varier avec le temps pendant la même séance de poses). C'est pour ça que PHD2, par exemple, commence par une calibration et qu'il faut la refaire à chaque fois qu'on modifie le cadrage.

 

Une façon de faire grossière mais qui n'a pas besoin de calibration serait d'analyser l'évolution de l'intensité de courant qui part dans la monture. Quand ça tourne dans le vide à cause du jeu, ça ne consomme rien ou pas grand chose, et quand le jeu est rattrapé, il devrait y avoir une augmentation rapide non négligeable de l'intensité. Ça devrait permettre de voir à peu près quand le jeu est rattrapé et quand la monture se remet à bouger. C'est juste une intuition, je n'ai rien pour tester.

 

En pratique il faudrait donc que le boitier de pilotage se trouve en série entre l'alimentation et la monture pour mesurer cette variation d'intensité.

 

Sinon quelle différence y-a-t-il entre les 4 schémas de la bande centrale dans le câblage que tu as indiqué : ce sont les 4 mêmes....

image.png.7c5b5fe81ae6dd1cdd617589e37b1359.png

 

On voit dans les schémas qu'il y a 2 combinaisons à prendre en compte :

1) soit la borne 6 est "non connectée" et la 5 est la "masse"  (SBIG et Takahashi)

2) soit la borne 1 est "non connectée" et la 2 est la "masse" (toutes les autres marques)

Si on se trompe d'ordre, on risque de court-circuiter quelque chose. Mais à ma connaissance, SBIG ne fait pas de monture, et ceux qui ont une monture Takahashi ont les moyens de se passer de ce montage bricolé sur le port ST4. Inutile donc de se préoccuper de ce détail. On retiendra la combinaison 2.

 

Ensuite on a des variations sur l'ordre +/- en partant de la "masse" :

A ) RA- DEC- DEC+ RA+ (Takahashi, Meade, Atik, Astrotrac)

B ) RA+ DEC+ DEC- RA- (toutes les autres marques)

 

Mais dans notre cas, peu importe le signe +/-, donc inutile de se préoccuper des deux combinaisons. Le résultat pour le dithering sera le même.

 

Pour que le boitier se comporte quand même le plus souvent de la façon la plus logique, le mieux est donc de retenir la config 2B (et de ne pas se soucier de la 2A) :

image.png.4a4558d6581632186b434630b6d6fb74.png

 

 

 

 

Posté

A propos du backlash ce n'est en effet pas aussi simple comme tu le fais remarquer...

L'idée de mesurer du courant est bonne mais ça complique la fabrication du système.

Peut-être faut-il simplement limiter le nombre de changement de sens de rotations et commencer par un grand décalage à chaque changement.

 

As-tu des infos sur les méthodes de dithering "classiques" (les motifs déplacement, spirale ?) ?

 

Il y a 1 heure, Fred_76 a dit :

Sinon quelle différence y-a-t-il entre les 4 schémas de la bande centrale dans le câblage que tu as indiqué : ce sont les 4 mêmes....

Je n'en ai pas trouvé non plus. L'image vient du forum cloudynights que j'ai cité.

Posté
Il y a 11 heures, Fred_76 a dit :

La commande est activée quand il y a contact entre l'un des 4 ports 3/4/5/6 avec la masse 2.

 

Wiring

 

Par contre, quand on voit DEC+ (ou AD+), à quel incrément de vitesse cela correspond, est-ce que ça dépend de la monture ou bien est-ce une valeur identique (en deg/min ou en x vitesse sidérale) pour toutes les montures ?

 

Oui c'est le bon montage

 

les résistances me paraissent trop faible, ça va faire beaucoup de courant pour le GPIO du arduino : 37mA pour un Arduino 5V alors que le absolute max du port est 40mA c'est trop pour un fonctionnement permanent surtout si il y a plusieurs ports allumés en même temps.

Bref je ne mettrais pas plus de 20mA de courant grand max, ce qui permet largement d'alimenter n'importe quel opto même basique.

Les optos basiques on un transfer de  courant de 50% en général  donc 10mA en sortie.

 

Perso je prendrais plutôt un opto avec un meilleur transfer de courant  et viserais  un courant de 5 à 10mA et donc des résistances plus élevées.

Et comme on ne sait pas trop quel courant tirer coté monture ( typiquement une pull up de 4.7K à 10k au 3.3V à 5V mais pas à l'abris d'autre chose) -> je mettrais un opto photo darlington qui à un très bon curent transfert ratio.

 

Bref je viserais 5mA en sortie, c'est largement suffisant pour tirrer n'importe quelle pull up raisonnable cotée monture (1KOhms à 5V ça me parait vraiment le max qui puisse être implémenté). Donc en entrée un courant de 5mA avec un opto à transfert de courant 100% ou si l'opto ne fait que 50% de transfert, à ce moment, 10mA dans la led de l'opto c'est largement suffisant

 

Avec le TLP 521-4 du schéma, le transfert de courant est de 50% minimum à 5mA en entrée. Et un peu plus à 10mA. -> Donc je règlerais le courant de la led de l'opto à 10mA soit une résistance de 370 Ohms (prendre 360 ou 330 Ohms) pour Arduino 5V et 200 Ohms pour un Arduino 3,3V (prendre 180 Ohms)

 

Aussi je mettrais des diodes TVS unidirectionnelles 16V en sortie pour protéger contre les ESD et autre (diode montée en inverse entre chaque sortie et la masse)

Sinon le schéma de principe est globalement correct.

 

La vitesse du ST4 dépend complètement de la configuration de la monture, il n'y a pas de règle unique pour toutes les montures :

Sur les EQ6 c'est x0.5 la vitesse sidérale en AD soit 7,5 arcsec/sec en gros  et en DEC c'est la même vitesse en ST4. On peut changer cette vitesse par la raquette (à x0.25 ou autre). Elle est indépendante de la vitesse sidérale et de la vitesse de déplacement sélectionnée pour les flèches de la raquette elle vient s'ajouter à elle. ça fera donc x0.5"/sec vers l'est et x1.5" /sec vers l'ouest

 

Sur les Vixen à raquette DD3, c'est différent : la raquette est beaucoup plus basique. Là le ST4 commande exactement la vitesse sélectionnée pour les flèches de la raquette, comme si on appuyait sur le bouton : x1.5 donne en fait une vitesse de guidage de x0.5 donc comme sur l'EQ6 x0.5 à l'est et x1.5 à l'est. La position x2 donne une vitesse de guidage de x1 donc x2 vers l'ouest et x0 donc arrêtée vers l'est

 

Dans tous les cas les moteurs sont allumés tant que la commande est mise à la masse. Il n'y a pas de données sur le ST4, pas de protocole, juste une fermeture de contacts secs

C'est très basique, exactement comme un interrupteur qu'on ferme (à la masse) pour allumer le moteur.

 

Bref si tu veux faire du dithering, il faudrait calculer une durée d'impulsion en fonction de l'échantillonnage et de la vitesse de guidage. Il faut que ça soit paramétrable. Sans compter qu'en DEC il y a aussi le backlash à prendre en compte.

 

Edit : @Fred_76si necessaire, je peux faire un petit circuit imprimé avec les composants qui vont bien. Tu peux me contacter  si besoin

 

Posté
Il y a 17 heures, olivdeso a dit :

Edit : @Fred_76si necessaire, je peux faire un petit circuit imprimé avec les composants qui vont bien. Tu peux me contacter  si besoin


Merci ! Pour le moment j’en suis encore à dégrossir le sujet. 
 

NB J’ai trouvé ce câble qui permet une alimentation bien pêchue via ST4. Ça va pulser avec ça 😜

image.jpeg

Posté

Voici l'algorithme du dithering. Il y en a d'autres, mais celui ci devrait suffire.

 

On note :

- Tmax la durée maximale de dithering, par exemple 2 s

- n est l'indice de la nième photo

- R(n) est un nombre réel aléatoire compris entre 0 et 1, calculé pour la nième photo

- d(n) est la durée du dithering pour la nième photo, on pose d(0) = 0 s

- t(n) est une durée intermédiaire pour la nième photo

- abs(x) signifie la valeur absolue de x

 

Au nième pas :

 

a) t(n)=[2*R(n)-1]*Tmax

b) si abs[t(n)+t(n-1)]>Tmax alors d(n)=-t(n) sinon d(n)=t(n)

c) t(n)=t(n-1)+d(n)

et on recommence à a) pour les photos suivantes.

 

Avec cette méthode on est certain que d(n) oscille entre les valeurs -Tmax et +Tmax et que les ditherings cumulés d(0)+d(1)+d(2)+...+d(n) restent eux aussi toujours contenus entre -Tmax et +Tmax. Le cadrage est conservé à +/-Tmax près. Chaque valeur comprise entre -Tmax et +Tmax est équiprobable (à condition que le générateur de nombres aléatoires R(n) suive une distribution uniforme, ce qui est normalement le cas), garantie pour que le dithering fonctionne bien.

 

Si on se contentait de faire brutalement :

a) d(n)=R(n)*Tmax

 

On aurait un cumul d(0)+d(1)+...+d(n) qui oscillerait très largement au delà de +/-Tmax, ce qui n'est pas bon du tout pour conserver le cadrage.

 

On le voit très bien sur ce graphe qui donne la dérive cumulée des opérations de dithering, en bleu avec la méthode brute, en orange avec la méthode ajustée, sur 4000 itérations. Pourtant le dithering à chaque itération est toujours compris entre -Tmax et +Tmax, mais selon la méthode choisie, la dérive cumulée reste contrôlée (orange), ou non (bleu) même après peu de tirages :

 

image.thumb.png.1bf242e3c7343a24becc42ea1fe5e5b8.png

 

 

 

Posté

Intéressant, je m'attendais pas à ce que la méthode "aléatoire brute" diverge autant.

L'histogramme des valeurs de la courbe orange est-il homogène ?

 

Le dithering produit-il généralement des micro-vibrations de l'instrument en fin de déplacement ?

Si oui, un paramètre définissant la durée d'une pause avant déclenchement de l'APN peut-être intéressant.

Posté
il y a une heure, Eridan31 a dit :

L'histogramme des valeurs de la courbe orange est-il homogène ?

Oui, on a bien une distribution uniforme.

 

il y a une heure, Eridan31 a dit :

 

Le dithering produit-il généralement des micro-vibrations de l'instrument en fin de déplacement ?

Pas nécessairement avec toutes les montures. En RA, il ne doit pas y avoir trop de vibrations, mais en DEC, ça peut secouer à cause du backlash.

 

il y a une heure, Eridan31 a dit :

Si oui, un paramètre définissant la durée d'une pause avant déclenchement de l'APN peut-être intéressant.

Oui il faut impérativement proposer un délai personnalisable après la fin du dithering.

 

Normalement pour le dithering en RA on ne renverse jamais le suivi. Donc le backlash n'est pas un problème. La séquence sera donc :

- fin de la pose photo

- lancement du dithering pendant un certain temps

- temps d'attente personnalisé

- reprise de la séquence photo

 

En déclinaison il faut jouer avec le backlash :

- fin de la pose photo

- lancement de la compensation de backlash (temps à personnaliser)

- lancement du dithering

- temps d'attente personnalisé

- reprise de la séquence photo

  • J'aime 1
Posté

Je pense que le dithering en DEC va rendre les choses bien plus compliquées.

 

Un dithering un peu plus agressif en RA sera tout aussi efficace et bien plus simple à implémenter. En plus, la plupart des petites montures (Star Adventurer, Astrotrac, Vixen Polaris, EQ1...) pour lesquelles ce système est prévu n'ont que le suivi en RA, pas en DEC.

 

Je vais me concentrer sur le dithering en RA uniquement dans un premier temps.

  • J'aime 1
Posté

Voici une façon de calculer la valeur Tmax, durée maximale de dithering, en fonction du nb de pixels de dithering qu'on souhaite avoir et des caractéristiques du système d'acquisition.

 

On saisi les variables :

  • Np = dithering "crête à creux" max en pixels (soit une amplitude Ap=Np/2)
  • f = focale (en mm) il s'agit de la focale RÉELLE et pas de celle artificielle obtenue avec le facteur de recadrage (crop factor)
  • p = taille des pixels (en µm)
  • sf = décalage ST4 de la vitesse sidérale *
  • dec = déclinaison de la cible

 

* Le décalage sf varie selon les montures. Généralement il est de 0,5. On peut sur certaines raquettes le modifier, par exemple à 0,25 0,75...

Ainsi si la vitesse sidérale est de 1 et que sf = 0,5, quand on fait une avance RA+ via ST4, la vitesse de suivi est modifiée à 1+0,5= 1,5 et inversement en RA- elle devient 1-0,5=0,5.

Pour éviter tout risque de backlash, il faut absolument utiliser sf < 1.

 

Par définition on a aussi :

  • Vs = vitesse sidérale = 15.04108 arcsec/s

 

On va commencer par calculer l’échantillonnage d'acquisition. La formule est bien connue :

  •  e = 206,3 x p / f (en arcsec/px)

Maintenant on calcule de combien se déplace la cible visée en arcsec par seconde pour le décalage sf ST4 :

  • de = sf x Vs x cos(dec) (en arcsec/s)

On sait maintenant de combien de pixels se déplace une étoile en + ou en - pour le décalage ST4 :

  • dpx = de/e
                = sf x Vs x cos(dec) x f / (206 x p)  (en px/s)

 

Finalement, le temps maximal du dithering recherché, Tmax se calcule par :

  • Tmax = Ap / dpx = Np / (2 x dpx)
  • Tmax  = 13,71 x ( Np x p ) / [ 2 x sf x f x cos(dec) ] (en s)

 

Exemples

 

A ) On veut un dithering max de 10 pixels, avec un Canon 6D (p=6.54 µm) et f=200 mm de focale, le décalage ST4 est de 0,5, l'objet ciblé est à 0° de déclinaison (par exemple Orion) :

  • Tmax = 13,71 x (10 x 6.54) / (2 x cos(0°) x 0,5 x 200) = 4,5 s

 

B ) On veut un dithering max de 15 pixels, avec un Canon 500D (p=4,68 µm) et f=500 mm de focale, décalage ST4 de 0,75, l'objet ciblé est M31 à 40° environ de déclinaison :

  • Tmax = 13,71 x (15 x 4.68) / (2 x cos(40°) x 0,75 x 500) = 1,7 s

 

 

  • J'aime 1
Posté

Comment déterminer le modificateur de la vitesse sidérale ?

 

Quand la monture fonctionne, elle tourne à la vitesse sidérale. C'est la "Vitesse 1" (1 fois la vitesse sidérale).

 

Quand on lance la commande RA+ ou RA- via le port ST4, la monture reçoit l'ordre de tourner plus ou moins vite. Mais c'est elle qui sait à quelle vitesse aller, pas le protocole ST4.

De combien va-t-elle aller plus ou moins vite ? Et bien ça dépend !

 

Sur certaines montures, quand on veut aller plus vite, on appuie sur un bouton avec une flèche où est (parfois) noté x2. Et pour aller plus lentement, on appuie sur un bouton noté 0. Dans ce cas, l'incrément de vitesse est de 1 :

  • RA+ : 1+1 = 2x la vitesse sidérale => on retrouve le x2
  • RA- : 1-1 = 0 x la vitesse sidérale => on retrouve le 0

Sur d'autres montures on peut choisir cet incrément, soit depuis la raquette soit depuis un ordinateur. Cet incrément est souvent appelé "vitesse de guidage" ou "vitesse d'autoguidage" ou parfois "vitesse ST4".

Attention, sur cette raquette, l'incrément est de 0.5 quand l'interrupteur est sur 0.5x, mais il est de 1 quand l'interrupteur est sur x2 et de 15 quand il est sur x16 :

image.png.14f5d8ad5e25476e1c489b49e6ed4bac.png

 

Dans la documentation des raquettes Syncan on lit les incréments 0.125, 0.25, 0.5, 0.75 et 1 :

image.png.a8e6166ec1330178e705aa849643045e.png

Ca veut dire que si on choisit par exemple x0.25, quand on lance les commandes ST4 :

  • RA+ : 1+0.25 = 1.25 x la vitesse sidérale
  • RA- : 1-0.25 = 0.75 x la vitesse sidérale

Quand rien n'est précisé  il faut chercher dans la documentation, ou sur internet, ou mesurer l'incrément, ou poser la question sur Webastro. Souvent l'incrément est de 1 ou de 0.5. Il ne faut jamais choisir d'incrément supérieur à 1.

 

Certaines raquettes n'ont pas de port ST4. Il faut en ajouter un. Rassurez vous, c'est vraiment simple. Il existe plein de tutoriels en fonction de la raquette à modifier :

 

  • J'aime 1
Posté
il y a une heure, Eridan31 a dit :

Ca prend forme ! 👍


Mouais, maintenant que la théorie est là il faut mettre les mains dans le cambouis !!!

Posté

Attention, avec un dithering en RA uniquement on est quasi-certain d'avoir une trame. Car la dérive en DEC ne sera pas aléatoire et probablement très faible à courte focale si la MES est bonne (ce qu'elle a intérêt à être)

  • J'aime 1
Posté
Il y a 8 heures, Pulsar59 a dit :

Attention, avec un dithering en RA uniquement

 

Je sais que ce n’est pas la panacée, mais c’est déjà beaucoup mieux que rien.

 

Les petites montures nomades, genre Star Adventurer, Astrotrac, EQ1, Vixen Polaris, etc ne guident qu’en RA. Il est donc impossible de faire du dithering en DEC avec elles. Ce projet concerne surtout ces petites montures.

 

Note aussi qu’en faisant un dithering très agressif en RA, c’est à dire 10-15 pixels (au lieu de 2-4 avec les grosses montures), on a de bons résultats avec une trame largement atténuée. C’est ce que j’ai constaté avec la Star Adventurer Mini qui permet nativement le dithering en RA.

Posté
il y a 2 minutes, Alhajoth a dit :

dithering avec des capteurs mobiles

 

Qu'appelles tu "capteur mobile" ???

Posté

Je ne vois pas comment piloter le déplacement interne du capteur, pour changer sa position d'une photo à l'autre. Il faut voir si c'est possible dans les SDK des fabricants, mais j'en doute.

 

Si c'était possible, on pourrait effectivement faire du dithering de cette façon. Ce sera cependant une solution qui ne fonctionnera qu'avec un appareil photo, et qui risque de ne pas être pérenne d'une version de firmware à l'autre (il suffit de voir comment Sony change tout à chaque firmware pour être découragé de développer des applis avec leurs appareils !!!). 

 

 

 

Posté
Il y a 2 heures, Fred_76 a dit :

Je ne vois pas comment piloter le déplacement interne du capteur, pour changer sa position d'une photo à l'autre. Il faut voir si c'est possible dans les SDK des fabricants, mais j'en doute.

 

Idem. C'est pour ça que dans ma question initiale, j'utilisais le mot théoriquement. :)

Je me demande quelle est l'amplitude de mouvements (en nombres de photosites) de ces capteurs.

Posté
Il y a 2 heures, Alhajoth a dit :

amplitude de mouvements (en nombres de photosites) de ces capteurs

Je te laisse chercher, c'est un peu hors sujet dans ce fil de discussion...

Posté (modifié)
Il y a 4 heures, Alhajoth a dit :

 

Idem. C'est pour ça que dans ma question initiale, j'utilisais le mot théoriquement. :)

Je me demande quelle est l'amplitude de mouvements (en nombres de photosites) de ces capteurs.

 

Un pentax avec astrotracer est capable de faire un suivi astro de 3 minutes avec une focale de 28mm, ça te donne une indication du déplacement possible.

Ordre de grandeur je dirais une 10aine de pixels.

Modifié par Hans Gruber
  • J'aime 1
Posté

Je commence la prog Arduino. Pour le moment juste de la simulation. Je commanderai les pièces quand ça marchera correctement.

 

J'ai tenté le coup avec TinkerCAD mais il ne prend pas en charge le bus I2C (et plein d'autres composants) pour piloter efficacement un écran LCD 16x02 et un petit clavier 6 touches...

Heureusement Wokwi Arduino le fait. C'est un peu moins convivial, mais ça semble fonctionner.

  • J'aime 1
Posté
Il y a 4 heures, Hans Gruber a dit :

Ordre de grandeur je dirais une 10aine de pixels.

 

Le Pentax K-1 Mark I ou II a des pixels de 4.86 µm. Avec 28 mm de focale, ça donne un échantillonnage de 206x4.86/28=32.76"/px.

Sur le plan équatorial, les étoiles se déplacent de 15.04"/s donc pour 3 minutes de temps de pose ça fait un déplacement de 3x60x15=2707" ou encore 2707/32.76=83 pixels sur le capteur, environ (soit 4.86x83=environ 0,4 mm).

 

 

 

 

Posté

Un ordre de grandeur est typiquement à une puissance de 10 près, donc j'étais encore dans la fourchette ;)

Tu peux jeter un œil au TTGO T-display, qui a l'avantage de fournir une carte plus petite, bien plus puissante, avec wifi et bluetooth, un écran TFT et 2 boutons déjà intégrés, des CAN 12 bits, le tout pour un prix contenu.

Posté
il y a 20 minutes, Hans Gruber a dit :

TTGO T-display

 

Merci pour l'idée. Mais je pense rester sur un Arduino... il y a bien plus de ressources et d'exemples de développement. La TTGO semble surdimensionnée pour l'usage que je compte faire. L'idée d'avoir la possibilité de contrôler le truc en Wifi ou Bluetooth m'avait effleuré l'esprit, mais il faudrait alors faire une app pour Android + iOS et c'est trop galère (surtout iOS à moins de jailbreaker l'iPhone ce que je ne veux pas).

Rejoignez la conversation !

Vous pouvez répondre maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous pour poster avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.