Batbihirulau

C'est même indispensable en effet. Perso, je le fais avec les 2 boutoins poussoirs. La variation est quasi continue. En effet, dans ce cas, c'est un peu plus difficile à utiliser. 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. Ah. La granularité temporelle des timestamps de FC est de 10ms justement (Confirmé par Torsten). Il y a une limitation en java visiblement. Fred

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

parce que tu fais des poses trop longues non, c'est du soft.

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.

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

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

Salut, Je n'ai pas de solution à apporter, mais éventuellement une suggestion de piste: Firecapture peut utiliser des scripts, ce qui permettrait de personnaliser son comportement. Il faudrait voir quelles instructions sont scriptables. Est ce que ce ne serait pas utilisable dans ce cas? (mais je n'ai pas essayé, il y a peut etre des connaisseurs) Fred

Bravo, Excellent!!!!

Voici le résultat d’une bidouille estivale que je voulais réaliser depuis un moment. Comme ca me semble marcher plutôt bien, je partage. L'idée de départ était de réaliser un dongle USB permettant de synchroniser l’horloge du PC avec un signal 1PPS sans aucun accés au reseau (offline) pour une utilisation en nomade. La précision devait également être suffisante pour permettre une utilisation sur des occultations. Précision suffisante, c’est un peu vague, disons <1ms. Autre critère important, ce dongle se devait d’être simple à réaliser mais aussi à mettre en œuvre, et pour un cout moindre. Comment ça se présente? et à l'interieur: C’est un peu de la microchirurgie, mais l’intégration/miniaturisation est aussi mon kiff, et ce n’est pas la première fois (contrôleur résistance chauffante ultra nomade, dongle GPS pour raquette Synscan). Pour faire qqch de propre et surtout arriver à une version finale, j'ai lancé qqs PCB, ce qui évitera le coté “filaire-3D” qui n’est pas compatible avec la reproductibilité. Comment ça marche? Partie hardware: Je pense que c’est la partie la plus simple, il n’y a pas grand chose mais chaque référence est importante. -un module GPS intégrant un module de chez U-Blox (NEO-6M) et une antenne patch (utilisé sur les drones). Ce module GPS devait avoir une sortie 1PPS (et pas juste une led) -un module driver USB gérant le contrôle de flux: ici un TinyLily Mini USB Adapter (mais qui semble difficile à trouver maintenant) équipé d'un FT231XS (moins populaire que le 232 mais aussi moins en “tension” sur les appros ces derniers temps…) -un boitier miniature (merci Ali) -le cable USB -le PCB qui va bien (en cours) cout hardware << 30€ (à la louche)!!! Partie soft: On utilise le client/seveur de Meinberg dont le rôle est de comparer/asservir l’horloge du PC à un serveur externe. Le but ici est de l'utiliser offline pour asservir l'horloge du PC au pulse 1PPS du module GPS. Ce 1PPS ne transporte aucune information (de localisation), mais marque chaque seconde avec une précision inférieure à la microseconde (mais on n'ira pas jusqu'à là...). Dans cette application, 2 soft, fournis par Meinberg, seront utilisés: *le client/serveur (NTP package with IPv6 support for Windows XP and newer pour Windows, mais peut etre installé sur d'autres plateformes) Pour les puristes, le package NTP peut etre recompilé depuis les sources (en bas de https://www.ntp.org/downloads/) *NTP Time Server Monitor (ne tourne que sous Windows), https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm C'est une couche graphique bien pratique qui permet d’avoir une vue globale de la config et du fonctionnement. Mais dans une fenêtre de terminal, en faisant ntpq -p , on obtient la meme chose. Un autre outil bien pratique, c'est le plotter de log: * NTPplotter (https://www.satsignal.eu/software/NTPplotter.zip) Juste pour tracer à posteriori les log obtenus. Jusqu'à la, il n'y a rien d'exceptionnel, l’installation et la configuration de ces softs sont connus et documentés (http://www.satsignal.eu/ntp/setup.html). Ca se corse lorsqu'on veut synchroniser en utilisant le 1PPS pour s’affranchir d’un accès réseau. Ce signal (logique) va etre appliqué sur la broche DCD du driver USB de façon à synchroniser la trame GPS avec ce 1PPS. Malheureusement, les drivers de chip USB standards ne gèrent pas tous ce type de synchro (on oublie le CH340). C’était simple sur les anciens PC en RS232, mais en USB on n’a plus accès aux signaux de contrôle de flux. D'ou l'idée d'utiliser une dll particulière développée par des gens ferus de serveurs NTP, et reprise par Meinberg. La procédure d'installation est décrite là ( https://support.ntp.org/Support/InstallingNTP#Section_4.6.1. bas de page) et est relativement simple: elle consiste à créer 2 nouvelles variable d'environnement, pour avoir l'image du screenshot suivant: Maintenant que tout est installé, il reste une configuration à réaliser. C'est un peu long (le temps que tout se stabilise à chaque fois), mais c'est nécessaire (c’est pour compenser certains délais additionnels introduit par votre PC). Le but est de calibrer une constante (timer2 dans le fichier de config) par tâtonnement. Oui, sa valeur est dépendante de la machine utilisée tout simplement. Comment utiliser? -Une fois que le PC est démarré, brancher le dongle -Attendre qu’au moins 4 satellites soient acquis et que le 1PPS soit généré (la LED 1PPS doit clignoter). Ca dure 4-5min. -Lancer alors Meinberg Monitor en mode admin -Vérifier que la synchro est faite et c’est tout. Les resultats: Une fois tout ça réalisé, l'horloge du PC est synchronisée au 1PPS du module GPS. Voici la vue du monitoring. La synchro est indiquée par le “o” dans la colonne à gauche de la colonne Remote. Les résultats vont dépendre de chaque PC et surtout de l’occupation CPU. Pour un laptop (celui qui me servira aux acquisitions d’occultations): Stabilité sur le long terme (8 heures environ) Distribution de l’offset sur ce lapse de temps/ Ce resultat montre une dispersion de l'offset (qui est la difference temporelle entre l'horloge du PC est le 1PPS) bien inférieure à 100µs. Pour ce qui est du temps d’établissement (verrouillage de la PLL), voici une vue typique du régime transitoire de stabilisation. Le système est verrouillé en quelques minutes. Recommandations: Si on veut réaliser une synchro efficace il faut impérativement arrêter les taches en arrière plan susceptibles d'occuper le CPU périodiquement (discord est très gourmand, Firefox aussi). La prevue, voici une courbe d’offset perturbée par Discor et Frefox: Pour finir, ce dongle a été installé et utilsé sur W10 et W11 avec succès. L'implémentation sur Linux (par exemple) doit etre possible, mais comme je n'y connais rien... Alors si un linuxien est tenté, ca pourrait etre interressant. Voilà, ce petit module permet de synchroniser, pour une somme modique, le PC avec un signal de référence (1PPS) avec un précision intéressante, bien inférieure à 1ms, ce qui devrait être suffisant pour le timing d’occultations.

Tu peux t'inspirer de ce qui est raconté là: https://robrobinette.com/pi_GPS_PPS_Time_Server.htm#GPS_NMEA_Offset_Tuning Le timer1 n'est pas utile en fait sur mon appli. En gros, une fois que tu as calculé la valeur de timer2 et que ca donne un bon resultat (en terme d'offset), tu désactives les serveurs distants (ceux du pool) et tu ne gardes que le GPS + PPS. Et là, le système est autonome. Enfin, offline La trame NMEA n'est pas trés utile, et son contenu encore moins (l'heure, la position, etc). Ou plutot, tout ce qui nous interresse, c'est le decalage entre son début et le pulse PPS (meme si cette valeur n'est pas trés précise).

Ah bien!!! Mais du coup, tu dis: tu pourrais en dire plus? ca peut intéresser d'autres personnes. Pour la courbe de stats, ca a l'air bien, mais en scrollant sur le graph (ou avec les +-) tu vas dilater la courbe, car là ça manque un peu de détail. A+

Salut, D'aprés ce que tu montres: -le fichier ntp.conf que tu montres ne corresond pas à l'onglet "NTPconfig file" -la syncro semble se faire sur les trames GPS (serveur 20) -le PPS n'est pas pris en compte du tout. D'aprés ta config tu devrait avoir aussi le serveur 127.127.22.6 (kPPS) dans la liste (regarde l'image dans le post d'origine) Un moyen de vérifier ou on en est est d'utiliser l'onglet "Statisic" pour regarder la courbe d'évolution entre le (temps source synchro) vs (temps du PC). Mais avant, il faut que dise à Meinberg d'écrire ce log. Il faut juste que tu rajoute les lignes: ########################################################### #Section insert by NTP Time Server Monitor enable stats statsdir "C:\NTP\etc\" statistics loopstats en fin de fichier (tu changes le repertoire si besoin). Dans "Statistic" donc, tu n'aura plus qu'à choisir le fichier que tu veux voir. A+ Fred

Salut, J'avais pas vu ton post plus tôt... Je n'ai fait qu'une présentation rapide, sans entrer volontairement dans les détails pour ne pas avoir un message trop long (et que plus personne ne lis jusqu'au bout). le "calage" ne se fait pas entre PPS et NMEA car la trame NMEA n'est absolument pas synchronne. Elle ne fait qu'encapsuler des data. On vient "caler" le 1PPS avec l'horloge du PC. Ce signal 1PPS, qui est donc issu du recepteur GPS doit être passé d'une façon particulière au PC. L'USB ne comportant qu'une paire différentielle (couche hard), il faut ruser. D'ou l'idée: 1-de synchroniser au niveau du chip la trame avec le 1PPS (valdation par la pin DCD) 2-utilisation de la dll qui va bien pour synchroniser le tout au niveau du PC Non non, rien à voir, on n'en n'est pas là. Dans la doc, ce sont les fudge factor (tout en vas de la page https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html) C'est un offset pour indiquer grossierement le décalage la trame NMEA (elle est pas synchrone). Et c'est cet ofset qui dépend de la machine C'est un peu long car il faut laisser le système se stabiliser (env 15min) entre chaque modif de valeur. Il faut y aller par tâtonne Ca se passe dans le fichier text de config. Tu definis un serveur associé au numéro de port COM. L'adresse du serveur devra etre du type 127.127.22.COM (le 22 et important) pour le 1PPS et 127.127.20.COM pour la trame NMEA. Regarde dans la liste de cette page: https://www.eecis.udel.edu/~mills/ntp/html/refclock.html Dans mon cas ca donne qqch comme ça (j'utilise donc le port COM3) # Add GPS clock server 127.127.20.3 minpoll 4 maxpoll 4 mode 16 prefer fudge 127.127.20.3 refid gGPS time2 0.1275 # Add PPS driver server 127.127.22.3 minpoll 4 maxpoll 4 fudge 127.127.22.3 time1 0.004 refid kPPS Il faut etre sur que le 1PPS est bien pris en compte. Si c'est OK, oui, le verrouillage se fait en qqs minutes. Je n'étais pas parti pour faire un tuto, c'est pour ça que j'ai fait des raccourcis dans la presentation initiale. Fred

@S.Chapeland merci pour ce retour. Alors pour répondre à tes questions: oui, j'ai tâché de comparer avec une autre base de temps. Tout simplement en filmant (pdt 10s, avec des poses de 1ms) la LED PPS d'un autre module GPS. Cette LED est censée s'allumer au top de chaque seconde. En regardant les images du .ser réalisé (dans Siril), on voit 2 choses: -PC non synchronisé (avec le dongle), les Top-seconde-PPS sont horodatés à xx.234s, puis 40min aprés, à xx.660s. Il y a un souci de dérive de l'horloge interne du PC -PC synchronisé, les Top-seconde-PPS sont horodatés à xx.005s, puis 40min aprés, à xx.003s. C'est déjà plus stable et surtout proche du PPS Pour ce qui est d'un occultation, et comme le projet vient de voir le jour, je n'ai pas encore eu l'occas de passer à l'ombre d'une étoile avec... Ceci dit, cela ne changera rien à la courbe de lumiere. Mais la comparaison pourra etre faite avec d'autres observateurs (et donc d'autres systèmes de synchro). Fred

Absolument @Vincent-FA. Ca ne fait pas tout, mais c'est une étape dans l'optimisation de la chaine d'acquisition.

Je crois (et j'en suis sur en fait) que les couleurs de la grille ne sont pas parametrables. Est ce qu'en ayant cette grille rouge mais sur un fond vert pourrait arranger les choses? En peu comme ça: juste en jouant avec les 2 boutons

Hello, Les composant C3 et C55 que tu montres sont des condensateurs au tantal. Ils sont réputés pour avoir des durées de vies "assez moyennes" mais aussi pour etre trés fragiles (en rapport avec la tension qui leur est appliquée). Si en plus ils prennent une inversion... Bref, en cas de défaillance, ils ont tendance à se mettre en court circuit. Du coup, les changer aurait du sens, mais tu n'es pas à l'abri qu'un autre composant soit mal en poing. Pour la valeur, ce n'est pas forcément critique, 10µF est un bon compromis. Les 25V (cf CN) donnent une bonne marge de sécurité. C'est bien. Pour les composants notés "FB", ce sont juste des ferrite bead (perles de ferrite) qui servent au filtrage (anti parasite) des differentes lignes qui entrent par le connecteur. La aussi, rien de critique. Fred

Hello, Pour le dithering, peut importe je dirais. En imagerie, il a pour but de réduire la trame aprés stack. Là, c'est chaque brute qui va être analysée. AJ ou Siril? Le premier a été dev pour la photometrie, du coup, il est trés puissant mais pas trop intuitif. Siril fait trés bien les courbes de lumières -en photometrie manuelle (tu choisis tes étoiles de comp à la main) -en semi auto (avec l'aide de NINA si tu utilises) Tout ca est décrit là: https://siril.readthedocs.io/fr/latest/photometry/lightcurves.html -en full auto, dans une version "actuellement dans le four", tu pourras recupérer les étoiles de comparaisons (en fonction de leur mag et BV) et lancer une courbe de lumière. Ca, c'est la version de dev que chacun peut tester...

Siril, qui fait aussi de la photométrie , peut ajuster automatiquement les diametres des cercles en fonction de l'étalement des étoiles. A voir ce que ca peut donner avec des étoiles défocalisées comme ici;

Il y a bien le keyword "DATE" mais c'est pas le standard. Avec quel logiciel images tu? Tu pourrais mettre une brute, un .fits, en PJ, stp? Ca m'interresse Mais tes images d'origine, sont elle bien en fit, fits ou tiff, d'ailleurs?

Hello, Attends un peu avant d'abandonner!!! Les scripts en français ont été supprimés (question d'homogeneité). Tu ne devrais plus les avoir (avec la 1.2.0B2) à moins qu'ils ne datent d'une version antérieure de Siril. Celui à utiliser serait le "osc preprocessing". MAIS!!! Tu dis qu'en sortie de l'Asiair, tu as directement les masters. OK, pourquoi pas. Dans ce cas, le script "tel quel" n'est pas sensé le savoir, il a été fait pour prendre en compte les images brutes et les DOF et générer les masters. Le mieux que tu aurais à faire serait de suivre pas a pas le tuto de traitement manuel (sachant que tu as deja les masters DOF). https://siril.org/fr/tutorials/tuto-manual/ Pour faire très simple: -conversion de tes lights -pré traitement avec tes master-DOF -alignement -empilement Essaye, ça n'est pas sorcier.

Hello, Lorsque tu fais le plate solve il faut dé-selectionner "Retourner l'image si nécessaire". Et aprés, tu devrais aussi mettre a jour ta version de Siril: la version courante est la 1.0.6 Fred

Pour suivre...

Il y a beaucoup de choses là, sur l'utilité des offset: https://siril.org/fr/tutorials/synthetic-biases/

Starnet n'est plus "intégrable" du fait du changement de licence, il me semble. Passer indivuellement toutes les brutes à la moulinette "starnet" est faisable, mais chronophage... Mais tout a fait faisable avec le script adéquate ... et du temps CPU Il te faudrait Starnet-iser les images du type "r_blabla.fits" de Siril