Batbihirulau 34 Posté(e) 24 mai (modifié) Il y a quelques temps, je m'étais attelé à un projet relatif au timing précis des occultations en nomade (cad sans réseaux 4/5G, basse consommation et sans alim spécifique). La première étape, était de s'occuper de la mise à l'heure de l'horloge du PC, ou plutôt de son asservissement à une horloge précise. Cette horloge précise n'est rien d'autre que le pulse 1PPS généré par beaucoup de modules GPS. Cette étape d’asservissement fonctionnait plutôt bien (avec une précision bien inférieure à la ms) et avait déjà été décrite là. Pour aller plus loin, l'idée était d'utiliser quasiment le meme hardware (un peu plus evolué quand même) pour générer un pulse optique à partir du 1PPS. L'idée est connue et utilisée depuis longtemps, http://nocturno.fr/ost/optique.html il s'agit juste d'un harware différent. Ce pulse optique est ensuite projeté sur le capteur de la camera pour que le film (.ser) puisse montrer l'étoile occultée ainsi que la pseudo étoile clignotante au rythme de 1 pulse/s. Voila pour le principe, une image en dira bien plus. Tout est dispo en open source là: https://gitlab.com/FRed_Shift/optopps -la boite noire contient le module GPS et un bout de circuit identique au poste précédent. -l'alimentation se fait donc pas l'USB -l'usb justement est rythmé par le 1PPS (DCD)pour synchroniser l'horloge du PC. Cette liaison n'est pas obligatoire, mais reste trés utile pour la stabilité des timestamps. Le module pourrait trés bien n'etre alimenté que par un petit power pack (c'est le cas sur la photo). -Une sortie sur fibre optique (9/125 FC/APC) permet de déporter le module sans risque de perte de signal ni d'ajout de délai. -le pulse optique est appliqué à un oculaire modifié (connecteur FC, lentille de collimation du faisceau optique pour avoir une étoile ponctuelle sur le capteur) -l'intensité du pulse (et donc la "magnitude" de cette pseudo étoile) sera à régler pour éviter toute saturation. Comme d'habitude en fait. -cet oculaire est placé sur un diviseur optique monté à l'envers (j'ai juste retourné le prisme sur mon exemplaire) Au final, une belle étoile clignotante apparait sur le capteur. Sa position est facilement modifiable en tournant l'oculaire (merci le defaut d'alignement et la coupe APC) ou en jouant sur le réglage du DO. Voila un gros plan de cette étoile. PPS.webm Au final on a sur le même .ser: -une étoile occultée avec une ou des étoiles de comparaison -une etoile clignotante dont l'allumage se fait à chaque seconde avec une précision bien meilleurs que ce qu'il nous faut. On doit donc pouvoir s'affranchir de connaitre les differents temps de latances de la chaine d'acquisition (camera, firmware, software d'aquisition, OS, etc) pour au final sortir une courbe de lumière synchronisée au 1PPS. La prochaine étape serait donc de: -Calculer, grace à l'étoile clignotante, la position exacte du changement de seconde (inspiré de https://proam-gemini.fr/wp-content/uploads/2022/07/I-LeCam_MesureDelaiAcquisition.pdf) -Comparer cette valeur avec celle donnée par les timestamps du film .ser -En deduire un offset à appliquer Ca, c'est la partie logicielle... Vu les conditions météo récentes et la probabilité d'avoir une occultation potable, je n'ai pu tester ça sur une occultation ... synthéthique (en violet, l'étoile occultée par le passage d'un bout de kapton, en vert l'étoile PPS) Vivement un coin de ciel clair Fred Modifié 24 mai par Batbihirulau 1 Partager ce message Lien à poster Partager sur d’autres sites
jfleouf 3 526 Posté(e) 24 mai Chouette projet. Merci du partage. Si je peux me permettre une remarque, on peut aussi faire ça avec un système qui produit un flash de lumière (inondant tout le champ de vision) , plutôt qu'un flash localisé (qui nécessite un montage un peu plus complexe pour que le flash ne soit pas tout flou. En général avec ce genre de système on se contente d'envoyer une impulsion lumineuse ~30 secondes avant et ~30 secondes après le début/fin de l'occultation. L’idée étant que la dérive de l'horloge sur ~1 minute est négligeable. Les logiciels PyMovie et PyOTE (de l'IOTA) permettent de traiter ce genre de signal. PyMOVIE peut détecter le flash de lumière et PyOTE utiliser cette information pour recaler le timing. Si tu fais ca pour le fun, continue. Mais sinon tu as déjà tout ce qu'il faut niveau logiciel avec PyOTE. Note aussi que placer le flash sur la même ligne horizontale que l’étoile occultée peut être avantageux pour les cameras en rolling shutter. JF Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 25 mai Oui, bien sur, on peut utiliser ce procedé. Ici, ce que je voulais faire est essayer l'aller un peu plus loin. Générer le pulse sous forme d'un "flash localisé" permet de le traiter plus tard exactement comme une étoile standard en photométrie. En 60s, il peut se passer beaucoup de choses je trouve. Ici, on se restreint à un laps de temps de 1s. Est ce que l'horloge est "en roue libre"? Ou est elle asservie à une référence? Et laquelle? Mais est ce que la durée est vraiment importante? J'ai preferé m'attacher à maitriser la distribution de cette horloge pour en réduire les variations. Au niveau logiciel, je suis plutôt coté Siril qui sait trés bien faire de la photometrie d'ouverture. Du coup, si tu fouille dans le repo de Siril, il existe une branche particulière, et toute fraiche, qui permet de gérer tout ça. 1- analyse de l'étoile clignotante pour determiner l'offset et la déviation standard 2-analyse de l'étoile occultée on tenant compte de la valeur d'offset Exemple: occultation.mp4 Pour ce qui est de la hauteur de cette étoile clignotante dans l'image, en effet, il y a cette contrainte, mais qui n'en ai pas une en fait puisqu'il est trés simple de la déplacer à volontée. Je n'en ai pas parlé dans la présentation pour ne pas rentrer dans ces considérations. C'est la différence entre une cam rolling shutter et global shutter, ce qui a été décrit dans le lien que j'ai donné précédemment) (https://proam-gemini.fr/wp-content/uploads/2022/07/I-LeCam_MesureDelaiAcquisition.pdf). Fred 1 Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 26 mai Cette nuit j'avais une occultation de prévu mais les nuages sont arrivé.. J'utilise <<grâce à toi>> NTP Meinberg , j'ai réussi à configurer le pps avec le monitor. Au lieu d'utiliser un flash dans le champ du capteur j'utilse le logiciel GENIKA trigger pps qui génère un fichier horaire DCD GPS timing file 26-05-2024_time_12-15-21.stp Je peux voir qu'il y a un delai d'environ 3ms avec DCD tracker. je n'utilise pas la partie NMEA de GENIKA (DCD tracker) J'ai un suivi en dent de scie zoom Bon Dimanche Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 26 mai (modifié) précision, l'offset time1 est réglé avec la caméra qui film le flash pps. Modifié 27 mai par Saci- Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 27 mai Tu avais deja parlé de cette methode. Les cam qui montent réellement à 1000fps ne sont pas légion. L'horodatage incrusté par SC n'est pas satisfaisant sur des poses plus longues. Pour Genika, je l'utilise aussi. Mais il faut choisir entre Meinberge et Genika pour l'occupation du port. La solution "pulse optique" permet d'intégrer toutes les informations nécessaires dans le .ser, sans fichier de log additionnel et en faisant abstraction du logiciel d'acquisition utilisé. Bonne semaine Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 27 mai Il y a 2 heures, Batbihirulau a dit : La solution "pulse optique" permet d'intégrer toutes les informations nécessaires dans le .ser, sans fichier de log additionnel et en faisant abstraction du logiciel d'acquisition utilisé. comment ça se passe avec des étoiles faibles (exposition 0.5s) parfois le flash est absent dans le ser Il y a 2 heures, Batbihirulau a dit : Pour Genika, je l'utilise aussi. Mais il faut choisir entre Meinberge et Genika pour l'occupation du port. J'utilise deux GPS en cas ou.. Il y a 2 heures, Batbihirulau a dit : Les cam qui montent réellement à 1000fps ne sont pas légion. Oui il faut fenêtrer 180X140 (SharpCap), c'est une asi462 je vais la changer pour une 432.. (pour les occultations dans SODIS je n'ai pas vu une seule correction au delà de la dizaine milliseconde le plus souvent c'est à deux chiffres après la virgule..) bonne semaine aussi je te remercie encore Partager ce message Lien à poster Partager sur d’autres sites
alx 114 Posté(e) 27 mai Je rebondis sur ce sujet de datation d'occultation afin de comparer avec mon expérience personnelle. Si on dispose d'une caméra qui à son propre horodatage, ou qui peut transmettre une synchro (PPS) au PC d'acquisition, il n' y a, en principe, pas de problème. Dans le second cas, on peut vérifier facilement (c'est bien montré ci-dessus) qu'un PC sous Windows peut dater en absolu un événement INTERNE (via PPS ou protocole NTP) avec une précision de l'ordre de la granularité temporelle de l'OS (de l'ordre de la milliseconde sur les PCs modernes). Avec le logiciel Meinberg ou même simplement l'API Windows. La difficulté vient (et c'est mon cas) quand la caméra utilisée n'a pas d'horodatage. C'est bien illustré dans la présentation référencée plus haut dans ce fil. L'inconnue est l'intervalle de temps entre la date (le début) de la pose optique (ce qu'on veut connaître) et le signal de fin d'acquisition en mémoire du PC via l'USB (ce que peut seulement mesurer l'OS). Cet intervalle peut être estimé à partir du débit USB (5 Gbits) et de la taille de l'image (par exemple 10 millions de pixels en 16 bits) , soit quelques dizaines de millisecondes. Auquel il faut ajouter le temps passé dans les électroniques USB côté caméra (''buffering'') et côté PC. Je n'ai pas trouvé de moyen d'en faire une mesure précise. Je croyais en avoir trouvé un en filmant l'écran du PC d'acquisition avec son horodatage interne, mais tout ce que j'ai mesuré c'est le temps de rafraichissement de l'écran (60 Hz) Tout ce qu'on peut dire, c'est que la régularité des temps d'acquisition (compte-tenu de la régularité très probable de l'horloge de ma caméra) semble indiquer que cet intervalle est à peu près constant, et devrait donc pouvoir être mesuré une fois pour toute (à paramètres d'acquisition donnés). Si quelqu'un a une idée. Alx. Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 27 mai il y a 5 minutes, alx a dit : Je croyais en avoir trouvé un en filmant l'écran du PC d'acquisition avec son horodatage interne, mais tout ce que j'ai mesuré c'est le temps de rafraichissement de l'écran (60 Hz) Sur ton SER l'horodatage est écrit en bas à droite, au début j'ai fait cette erreur aussi en filmant l'écran(heure).. Partager ce message Lien à poster Partager sur d’autres sites
alx 114 Posté(e) 27 mai il y a 42 minutes, Saci- a dit : Sur ton SER l'horodatage est écrit en bas à droite, au début j'ai fait cette erreur aussi en filmant l'écran(heure).. Attention, ce qui est écrit dans le fichier SER n'est pas généré par la caméra (au moins pas par les miennes (ZWO) qui n'ont pas cette capacité). C'est généré par le programme d'acquisition en soustrayant de la date d'acquisition de l'image la durée estimée du transfert. Pour SharpCap, cela m'a été confirmé par Robin Glover, à qui j'ai posé la question. Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 27 mai il y a 13 minutes, alx a dit : Attention, ce qui est écrit dans le fichier SER n'est pas généré par la caméra (au moins pas par les miennes (ZWO) qui n'ont pas cette capacité). C'est généré par le programme d'acquisition en soustrayant de la date d'acquisition de l'image la durée estimée du transfert. Justement le plus important est le réglage de l'offset, il se règle une fois le transfert etc.. terminé c'est à dire sur l'enregistrement final ainsi tu t'affranchis de toutes les latences.. C'est pour cela que j'ai un offset avec GENIKA le temps de latence reçu de l'impulsion gps à l'enregistrement du câble au fichier(stp) dure environ 3ms. Ce que je voulais dire l'horodatage à l'écran chez moi est l'horodatage du pc(en bas à droite du ser) je n'ai pas de camera gps. Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 27 mai il y a une heure, alx a dit : Si quelqu'un a une idée. J'en aurais bien une. Mesurer tous ces differents temps de latence devient inextricable et trop dépendnat du materiel (cam, PC) et des soft. Ce qui fait que les differents timestamps que l'on peut "calculer" (par le PC ou autre firmware) se retrouvent entachés d'erreurs. Le seul timestamp, extérieur à tout setup, et auquel on peut faire confiance est ce fameux PPS. En insérant directement ce PPS dans un .ser, sous forme d'un pulse optique donc) permet de recaler chaque frame comprise entre 2 pulses. La seule contrainte est de savoir à quelle seconde appartient un pulse. Autrement dit, il faut que l'horloge du PC soit précise à 500ms prés... ce qui ne pose pas trop de souci. Pur ce qui est de la longueur du pulse, j'utilise 400ms, ce qui donne suffisament de lattitude par rapport aux temps de poses utilisables. Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 27 mai il y a 40 minutes, Batbihirulau a dit : Pur ce qui est de la longueur du pulse, j'utilise 400ms, ce qui donne suffisament de lattitude par rapport aux temps de poses utilisables. OK j'ai vu, quand je maîtriserai PYOTE je ferai cette manip que j'ai déjà faite avec le flash à l'intérieur du télescope mais l'impulsion dure 100ms parfois absente dans le ser mais bien vu cette technique à condition que l'impulsion reste identique puisqu'il faudra rajouter un composant pour allonger le temps du flash, I don't no.. Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 27 mai il y a 12 minutes, Saci- a dit : 100ms parfois absente dans le ser parce que tu fais des poses trop longues il y a 13 minutes, Saci- a dit : faudra rajouter un composant non, c'est du soft. Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 27 mai il y a 40 minutes, Batbihirulau a dit : non, c'est du soft. j'ai essayé de voir pour configurer la puce avec ucenter je ne trouve pas cette manip.. Partager ce message Lien à poster Partager sur d’autres sites
jfleouf 3 526 Posté(e) 28 mai Le 5/27/2024 à 04:20, Saci- a dit : comment ça se passe avec des étoiles faibles (exposition 0.5s) parfois le flash est absent dans le ser Alors, avec mon flasher, j'utilise en général des pulses de 1 seconde. Le plus important c'est de ne pas saturer le capteur pendant le pulse. Le logiciel PyOTE peut recaler très précisément l'horodatage. Si l’étoile cible nécessite des pauses de 0.5 seconde, je ferais des pulses de plusieurs secondes (genre 3 ou 4) pour m'assurer d'avoir au moins quelques frames avec la LED allumée pendant 100% de la frame. PyOTE va calculer la fraction du signal sur la première frame avec le signal de la LED, et en déduire le temps exact (par exemple, si cette frame est à 5000 ADU alors que les suivantes -en plein dans le pulse- sont à 10000 ADU, il va en déduire que la LED était allumée pendant 50% de la durée de la première frame. C'est pour ça qu'il est important de pouvoir moduler l’intensité de la LED pour éviter de saturer le capteur sur les pauses longues (et avoir suffisamment de signal sur les pauses courtes). Le système de "Aart's flasher" permet de la durée et l’intensité (en plus du timing, bien sur) des pulses pour chaque occultation. Le 5/25/2024 à 08:44, Batbihirulau a dit : En 60s, il peut se passer beaucoup de choses je trouve. Ici, on se restreint à un laps de temps de 1s. Oui, c’était un point qui m’inquiétait aussi au début. Et puis j'ai fait des tests + vérifié sur quelques dizaines d'occultations et je n'ai jamais constaté de problème. Autrement dit, si le premier flash me dit que mon horloge a 10ms de retard, je retrouve exactement ces 10ms au deuxième flash (en général une minute plus tard, mais ça peut être plus pour les occultations avec une grosse incertitude de temps). J'utilise un système banal (Mini PC sous Linux + ASI533MM + Firecapture). Encore une fois, c'est chouette de développer un nouveau système, même si il existe déjà quelque chose qui fonctionne très bien. Pour ma part, je vais rester sur mon système car j'utilise un hyperstar, donc pas trop envie d'ajouter une pièce qui va augmenter l'obstruction. JF 1 Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 28 mai il y a 25 minutes, jfleouf a dit : pouvoir moduler l’intensité de la LED pour éviter de saturer le capteur sur les pauses longues C'est même indispensable en effet. Perso, je le fais avec les 2 boutoins poussoirs. La variation est quasi continue. il y a 26 minutes, jfleouf a dit : car j'utilise un hyperstar, En effet, dans ce cas, c'est un peu plus difficile à utiliser. il y a 27 minutes, jfleouf a dit : même si il existe déjà quelque chose qui fonctionne très bien absolument. Mais encore une fois, mon but est juste d'aller un peu plus loin dans les perf et de le partager. Au final, chacun pourra utiliser (ou pas) le système qui lui convient, rien de plus. il y a 29 minutes, jfleouf a dit : + Firecapture Ah. La granularité temporelle des timestamps de FC est de 10ms justement (Confirmé par Torsten). Il y a une limitation en java visiblement. Fred 1 Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 15 juin (modifié) Le 24/05/2024 à 20:49, jfleouf a dit : Si je peux me permettre une remarque, on peut aussi faire ça avec un système qui produit un flash de lumière (inondant tout le champ de vision) , plutôt qu'un flash localisé (qui nécessite un montage un peu plus complexe pour que le flash ne soit pas tout flou. j'ai essayé le clignotant avec une fibre optique devant le capteur de la caméra mais vu sa minuscule taille(asi462) la fibre prend beaucoup de place, du coup l'idée d'inonder le champ avec la led/pps devant le télescope serai beaucoup plus simple même mieux pour les camera en rolling shutter qui commence par lire les lignes du bas (vers le haut) sur tout la plage du capteur. J'ai vu aussi pour régler la durée du flash/gps à ma guise avec Ucenter, j'ai deux modèles gps/clignotants: A-<< la led s'éteint quand la seconde commence.>> ici durée de l'extinction est réglé à 100ms. B-<< la led s'allume quand la seconde commence>> je me demande si PyOTE ou Pymovie fera cette différence.. ici on voit bien l'effet rolling shutter expo 10ms ici modèle GPS A offset image[0.009 à 0.101] fibre optique devant le capteur: expo 20ms modèle GPS A ici essai en plein jour d'où cette lumière résiduel si je met la fibre optique dans un coin (soit en haut ou en bas) elle ne sera pas detectée convenablement.. mais parfait en global shutter. Bon c'est pas évident avec un petit capteur, j'hésite fortement pour mettre un place un point lumineux dans un coin même avec un diviseur optique en rolling shutter. Que feriez-vous ?? karim Modifié 16 juin par Saci- Partager ce message Lien à poster Partager sur d’autres sites
jfleouf 3 526 Posté(e) 16 juin (modifié) Il y a 16 heures, Saci- a dit : je me demande si PyOTE ou Pymovie fera cette différence.. Par défaut, PyOTE a besoin d'un flash qui commence au début de la seconde, mais on doit pouvoir bidouiller. A ta place, je ne me prendrais pas la tête et je ferais un système qui s'allume pour une seconde en inondant le champ. Avec ça au moins tu es certain de la compatibilité avec PyOTE. JF EDIT : petite précision, l'allumage n'a pas besoin de se faire au début de la seconde en fait. Ce qu'il faut c'est connaitre l'heure exacte du début du flash. PyOTE calcule la position exacte en comparant l'intensité de la première image qui contient du signal de flash avec les images suivantes qui sont à 100% dans le flash. C'est pour ça qu'il faut que le flash soit (1) plus long que le temps d'exposition et (2) pas trop fort pour ne pas saturer le capteur. Dans tous les cas, ce que PyOTE veut c'est un signal qui augmente à un moment donné. Pas sur qu'on puisse utiliser un signal qui baisse. C'est pour ça que je déconseille la solution d'éteindre la LED à un moment précis. Modifié 16 juin par jfleouf précisions 1 Partager ce message Lien à poster Partager sur d’autres sites
Batbihirulau 34 Posté(e) 16 juin Les modèles de GPS ne sont pas tous compatibles avec l'appli Ublox. Ce qui fait que tous les paramètres ne sont pas nécessairement accessibles. Aprés, pour le "sens" du pulse, il ne faut pas confondre le PPS et le DCD si il est dispo: ils auront des comportements complémentaires. Ce que tu montres est bon. Le seul truc, c'est qu'il faut collimater pour avoir une etoile ponctuelle. C'est pour ça que tu as une gosse tache sur ta video. En sortie de fibre, tu auras un point de qqs micron (ca depend de la fibre) mais le flux lumineux sera conique. Il faut donc le rendre ponctuel en le collimatant, avec une lentille basique d'un vieil oculaire chinois par exemple. Le systeme qui consiste à inonder le champ est parfaitement géré par PyOTE. (Peut etre qu'une presentation ou un tuto ou des resultats ou des bidouilles seraient interressants et bienvenus) Mais du coup, ce n'est plus le sujet de ce fil en fait. Fred Partager ce message Lien à poster Partager sur d’autres sites
Saci- 981 Posté(e) 16 juin (modifié) Il y a 19 heures, jfleouf a dit : petite précision, l'allumage n'a pas besoin de se faire au début de la seconde en fait. Ce qu'il faut c'est connaitre l'heure exacte du début du flash. merci, j'ai trouvé le bon réglage(ici) elle s'allume au commencement de la seconde pour une durée d'une seconde puis s'éteint pour une durée d'une seconde et ainsi de suite.. selon l'étoile occulté on verra Il y a 5 heures, Batbihirulau a dit : Les modèles de GPS ne sont pas tous compatibles avec l'appli Ublox. Ce qui fait que tous les paramètres ne sont pas nécessairement accessibles. Oui mais la durée du flash normalement c'est ok.. à bientôt karim Modifié 16 juin par Saci- 1 Partager ce message Lien à poster Partager sur d’autres sites
