Batbihirulau

Membre
  • Compteur de contenus

    58
  • Inscription

  • Dernière visite

  • Last Connexion

    Soon available - 50159

Messages posté(e)s par Batbihirulau


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


  2. Il y a 10 heures, Flopin a dit :

    cet offset, on le mesure comment ?

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

     


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

    • Merci 1

  4. 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 30/09/2023 à 10:52, Flopin a dit :

    calage entre PPS et NMEA

    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

    Le 30/09/2023 à 10:52, Flopin a dit :

    Ce timer2 c'est uniquement pour régler l'offset final de l'acquisition par une camera

    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

     

    Le 30/09/2023 à 10:52, Flopin a dit :

    Comment tu configures meinberg

    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

    • J'aime 1

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

     

    • J'aime 1

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

    20230904_103840-LR.jpg.089e680cf86ab391d023c698a5cb50e5.jpg

     

    et à l'interieur:

    20230904_103914-LR.jpg.bfc275119c57020c94f63bd92dfb31c1.jpg

     

    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:

     

    64f605fc597a1_Meinberg-Capturedcran2023-09-02155858.png.4d38f225b75a8ab79e42338abc85821a.png

     

    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.

    Locked.png.d4674fe3d9958516e1a6a430ca30b585.png

     

    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)

    2023-08-05_offset.png.d6e83e865699c7525c50641edf6b7b02.png

     

    Distribution de l’offset sur ce lapse de temps/

    2023-08-05_Histo.png.2e65c26d2be680b1131254fc053f9e4f.png

     

    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.

    2023-09-04_offset.png.f0c2fd70a161574e0caac4032094f99f.png

    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:

    2023-09-01_offset-Discord.png.cda8dba9bbe4ac4fa592a194a423b075.png

     

    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.

    • J'aime 5
    • J'adore 2
    • Merci 1

  7. 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:
    image.png.ffd49b3f13652052c45d2dd8165894f0.png

    juste en jouant avec les 2 boutons image.png.a4fcacf97864b84f3b7db83e29fc93d4.png

     

    image.png

    image.png

    • Merci 2

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


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


  10. Hello,

     

    Il y a 11 heures, transitmk1 a dit :

    je vais abandonné ce truc

    Attends un peu avant d'abandonner!!!:/

     

    Il y a 11 heures, transitmk1 a dit :

    ils me marque osc preprocessing,aucune explication la dessus ,donc je pense que ça doit etre la meme chose que le preprocessing couleur

    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.


  11. il y a 52 minutes, COM423 a dit :

    option StarLess activable dans Siril

    Starnet n'est plus "intégrable" du fait du changement de licence, il me semble.

     

    il y a 52 minutes, COM423 a dit :

    applicable aux image FITS de base d'une série

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

    Il te faudrait Starnet-iser les images du type "r_blabla.fits"  de Siril

    • Merci 1

  12. Il y a 19 heures, COM423 a dit :

    Malheureusement, les outils starnet ne sont interfaçables ni avec Siril, ni avec Gimp et je suis donc obligé de faire sans...

    Je ne sais pas ce que tu entends par "interfaçables", mais pour ce qui est de Starnet++, il est parfaitement clair que le fichier d'entrée doit etre en TIFF/16b, et le fichier de sortie sera dans le meme format.

     

    Partant de là, Siril sait trés bien gérer ce format d'image.

    Ensuite, il devient intéressant de bénéficier du 32bit natif pour la précision des calculs offerts par Siril et son PixelMath.

     

    Il est évident que ces "transformations" ne peuvent pas se faire depuis Starnet++.

    Par contre, en utilisant les ressources d'ici, il est tout à fait possible de créer un script en python qui remplit parfaitement ce rôle "d'interface".

    L'idée est de n'avoir à gérer que des fichiers FITS/32...

    • Merci 1