Eridan31

Joli travail. Pour le paramètre "déclinaison", il serait intéressant de demander confirmation de la valeur lors de la confirmation "Start shooting". Je pense qu'entre deux cibles, peu de personnes penseront à modifier ce paramètre. Ou alors mettre ce paramètre dans la catégorie "INTERVALOMETER".

Dommage. Pour ma part pas le temps de programmer en ce moment. Pour réduire la complexité du projet, il faudrait retirer le menu interactif : - Soit en remplaçant l'écran et les boutons par une interaction console : on écrit des messages et on lit des valeurs saisies. Fonctionne en mode simulateur, puis sur smartphone en bluetooth. - Soit en gardant l'écran LCD et les boutons, mais en remplaçant les menus interactifs par une séquence de valeurs à saisir au démarrage du programme : - Ligne 1 LCD = nom du paramètre à définir - Ligne 2 LCD = valeur actuellement définie, avec les boutons + et - qui modifie la valeur courante Les valeurs sont mémorisées dans l'EEPROM. Pour modifier des paramètres, on appuie sur le bouton reset de l'arduino et/ou sur un bouton déporté prévu à cet effet. Bref fait une pause si c'est prise de tête

Dur dur... La gestion de l'interface LCD est sûrement plus complexe que le reste du projet. Courage

Excellent l'outil TinkerCAD. Je ne connaissais pas. J'ai pu jouer avec les boutons et voir le bon numéro s'afficher dans la console 😛 Je vois aussi que tu as commencé à mettre les différents affichages sur le LCD. Un post qui pourrait t'intéresser : CDLC a développé un programme assez complet avec une interface un peu comme toi. J'aime bien son diagramme qui schématise la navigation des les menus. Pratique pour clarifier ses idées et pour illustrer le manuel utilisateur.

Celui-ci ? Ok j'insiste pas Jette quand même un œil à https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=fr&gl=US si tu connais pas. Le programme Arduino peut envoyer des lignes de texte qui seront affichées dans la console. Et depuis le téléphone on peut aussi envoyer du texte vers la Arduino, par exemple avec le clavier pour saisir des valeurs numériques (ex: distance focale) ou via des boutons prédéfinis envoyant des noms de commandes reconnues par ton programme (ex: "CMD_MENU1", "CMD_OK", etc.). Dans l'appli on peut créer jusqu'à 30 boutons pour lesquels on choisit le nom affiché et le texte associé envoyé via le Bluetooth. On peut même exporter/importer la config des boutons pour partager avec les autres utilisateurs. PS : je trouve pas d'appli équivalente avec les boutons prédéfinis pour iOS...

Bonjour Fred_76 et tous les contributeurs, Le projet bouge bien, très intéressant à suivre. Quelques remarques/questions : 1. Quels sont les arguments qui t'on fait choisir des relais plutôt qu'une puce "optocoupleur 4 voies" ? Il me semble que les relais reviennent plus cher, sont plus volumineux, consomment plus de courant et sont moins précis/réactifs pour donner des impulsions ST-4. 2. L'idée d'utiliser un terminal Bluetooth sur smartphone via une console telle que l'appli "Serial Bluetooth Terminal" me plait bien. Un module HC05 revient moins cher et s'intègre plus facilement qu'un écran et des boutons. On peut enfermer le dispositif dans une boîte, à l'abri de l'humidité et courts-circuits. 3. Quel serait le rôle de la carte SD que tu mentionnes ? Il y a si peu de place que ça dans l'Arduino pour stocker le programme ? Les paramètres de configuration tels que "focale de l'instrument", "échantillonnage", etc. pourraient être stockés dans l'EEPROM ? 4. Le système sera-t-il compatible Arduino Nano (pas seulement Uno) ?

Ca prend forme ! 👍

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.

La façon de "relier les étoiles" peut être "interprété" de différentes façons. Le plus important ce sont la position des étoiles et leurs magnitudes. Vu sous Stellarium des "cultures" occidentales "H.A. Rey" et "O. Hlad"

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 ?) ? Je n'en ai pas trouvé non plus. L'image vient du forum cloudynights que j'ai cité.

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

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 :

On gagne effectivement un peu en netteté pour N=12. Mais c'est déjà impressionnant avec seulement 6 images. Il serait intéressant de voir une image brute à titre de comparaison.

Merci à toi, c'est magnifique !

Les dégâts sont importants, je compatis... Comment est-ce possible ? Via le port d'alim du hub ou via un des ports USB ?