Messages recommandés

Bonjour la Team!

 

Je cherche à améliorer ma précision temporel pour une datation la plus précise possible lors de mes prises de vues.

j'exclu les serveurs ntp accessibles depuis internet (précisions et connexion internet).

Je me suis donc tourné vers un récepteur gps en Usb qui sont a priori bien plus fiables.

Maintenant, comment synchroniser l'heure de mon module gps et de l'heure de mon PC?

J'ai cherché sur le web, mais rien trouvé mis a part le logiciel Dimension 4,mais ne sais pas comment le configurer avec mon module gps.

Prism intègre cette fonctionnalité, mais y a t'il une alternative?

 

Merci de vos infos.

 

Manu

 

 

Modifié par manu33

Partager ce message


Lien à poster
Partager sur d’autres sites

Facilement 100ms de différence réelle sont réalisables via une synchronisation internet par ADSL, sur Linux et sur windows récent.

As-tu besoin de mieux et de combien.

 

Stabilité de l'horloge d'un PC basique : 30ppm (XO) à 1ppm soit de 2.63s/j à 88ms. Pour un PC de qualité (horloge TCXO, serveur) c'est plutôt 10ms / jour.

Sur des délai court : on descend à 0.02ppm sur une période d'une seconde.

 

XO : 25ppm, c'est un quartz libre.

 

article-2019february-how-to-select-fig5.image.png.9bcb06728bcae1f5bce49cc6d0c60d67.png

https://www.rfglobalnet.com/doc/xo-clock-oscillators-0001

image.png.f8c3a0b8dd17297329b6ec7ec39373c7.png

exemple : https://doumai.pagesperso-orange.fr/16F628/Oscillateur_32kHz/Oscillateur_32k.htm

 

TCXO et sources fiables :

les TCXO sont des quartz avec une électronique de compensation adaptée à un modèle de cristal connu.

Vu la modernité des cartes mères, certaines sont probablement TCXO mais je vais creuser.

https://pratique-rfcircuits.monsite-orange.fr/page-5c25f4b71dbcd.html

En intégré : 18,5€ HT

article-2019february-how-to-select-fig6.  image.png.d4c93b446a12325839c24af3ae62a059.png

option de qualité : contrôle du vieillissement du cristal et bonne régulation de voltage => Dallas DS3231 / Connor Winfield séries T ou TV pour les telecoms ex. T602-025.0M

DS3231 est connue sous forme de module Arduino : 2ppm (dérive de 20ms / jour ) entre 0 et 40°C

 

les OCXO sont des quartz sous étuve chauffée (O pour oven, C pour compensated) et régulée (une à 2 parois) : c'est plus gros et ça consomme plus

article-2019february-how-to-select-fig7. image.png.ae740660451fe3d454a798057df07349.png

https://www.meinbergglobal.com/english/specs/gpsopt.htm

image.png.6d058c62fa7e8c60156faac2277b8126.png

Exemple : Connor Winfield OH4 séries, OH4610LF-025.0M, 56€ HT.

l 13mm x L 20mm x h 16.5mm

Modifié par lyl
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Les 100ms sont acceptable pour de l'occultation d'astéroïdes (je penses),mais surtout en l'absence de réseau internet comment fais tu avec les serveurs de temps? sachant que les mises a jour en ligne se font périodiquement sur des tranches habituelles de 20 a 30 minutes (paramétrables), les dérives temporelles sur 20 a 30 minutes doivent déjà être conséquentes?

 

Manu

Partager ce message


Lien à poster
Partager sur d’autres sites

Partage de connexion depuis ton mobile ? Est-tu vraiment complètement hors réseau ? Même en montagne aujourd'hui on a de la 3G/4G.

 

Marc

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 4 heures, manu33 a dit :

surtout en l'absence de réseau internet comment fais tu avec les serveurs de temps? sachant que les mises a jour en ligne se font périodiquement sur des tranches habituelles de 20 a 30 minutes (paramétrables), les dérives temporelles sur 20 a 30 minutes doivent déjà être conséquentes?

L'intérêt du ntp est non seulement de te mettre à l'heure mais surtout de corriger la dérive de l'horloge interne de ton PC, c'est l'intérêt de mettre cela en place.

Avec un système de temps sous windows moderne W32Time ou Linux (ntpd et maintenant chronyd)

 

Pour Windows : 

https://learn.microsoft.com/fr-fr/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings

Un serveur de référence (il faut s'enregistrer par mail sinon on risque de vous bloquer)

https://syrte.obspm.fr/spip/services/ref-temps/article/diffusion-de-l-heure-par-internet-ntp-network-time-protocol

 

Le principe est de calculer la dérive sur une période assez longue et d'enregistrer la différence de fréquence de ton quartz dans un fichier, le programme autocorrige la vitesse de ton horloge avec une granularité par "tic" (le plus petit écart de temps possible chaque fois que c'est nécessaire.

Il calcule quand et fait faire un petit bond en avant ou en arrière régulièrement.

 

Ce n'est pas simplement le mettre à l'heure mais aussi garantir que tu puisses être autonome en mode déconnecté sur une longue durée. (jours)

C'est moins efficace qu'un quartz à PLL programmée mais presque efficace qu'une montre à quartz une fois calibré.

La plupart des ordis maintenant utilisent un système horloge TCXO, quartz compensé avec une capacité. ( fréquence 10ms/jour de 86400s ou 0.1ppm )

 

Citation

À la différence d'un mouvement mécanique, le mouvement à quartz ne dérive pratiquement pas : de l'ordre de 0,1 ppm (parties par million), soit 0,3 seconde par mois, là où la dérive d'un mouvement mécanique varie généralement entre 10 secondes par jour et 6 secondes par mois

 

En déconnecté (l'ordinateur doit rester en service pour que la correction se maintienne), on peut espérer 30ms / jour pour la dérive et une centaine de ms pour le temps absolu

 

Sur une boucle réseau informatique fermée de serveur on obtient un horodatage absolu précis ~10ms.

Sur un réseau bureautique/internet, ~100ms c'est facile avec des PC standards

 

Ma référence : 

https://www.groupeadsn.fr/

https://siaf.hypotheses.org/125

 

Modifié par lyl
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 6 heures, manu33 a dit :

Les 100ms sont acceptable pour de l'occultation d'astéroïdes

Non il faut 10ms ou mieux.

 

Si tu es un peu bricoleur il y a une solution à base de raspberry et gps : http://www.nocturno.fr/timeserver/timeserverstrate1.html

Le raspberry prend la référence de temps dans le signal gps et fait office de serveur ftp par exemple en utilisant chrony.

Nous sommes quelques observateurs d'occultations a en avoir fabriqué un, ça fonctionne très bien, avec ça tu atteins la ms voir un peu mieux.

 

Lionel

  • J'aime 3

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 2 heures, teko38 a dit :

 

La time box, l'idéal, mais un peu cher pour moi !!!

ton logiciel a l'air super intéressant, par contre pour connaitre sa précision, il faudrait pouvoir comparer, mais pourquoi pas !

Prism intègre bien une interface pour récupérer le temps d'un module gps!

 

Merci de ton message :)

 

 

Modifié par manu33

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, astroluma a dit :

Non il faut 10ms ou mieux.

 

Si tu es un peu bricoleur il y a une solution à base de raspberry et gps : http://www.nocturno.fr/timeserver/timeserverstrate1.html

Le raspberry prend la référence de temps dans le signal gps et fait office de serveur ftp par exemple en utilisant chrony.

Nous sommes quelques observateurs d'occultations a en avoir fabriqué un, ça fonctionne très bien, avec ça tu atteins la ms voir un peu mieux.

 

Lionel

 

Bonjour Lionel,

 

Merci de ta précision :)

Pour le timing, j'avais lu cet article :

http://astrosurf.com/sogorb/articles/asm96_occultations_2018.pdf

 

J'avais également identifier cette possibilité avec un Rasp.

j'ai trouvé ce lien en cherchant avec Chrony : https://www.framboise314.fr/lheure-gps-sur-votre-raspberry-pi/

 

Merci :)

 

Manu

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 10 heures, astroluma a dit :

serveur ftp par exemple en utilisant chrony.

Nous sommes quelques observateurs d'occultations a en avoir fabriqué un, ça fonctionne très bien, avec ça tu atteins la ms voir un peu mieux.

Sur quel type de connexion entre les machines ?

 

De mon expérience, un lien ADSL à bon ping (20-30ms) permet une précision de 100ms après convergence

En dessous, il faut assurer que la latence soit limitée entre 20 et 30% du jitter (dispersion statistique) désiré, idéalement 10% sinon la convergence statistique est difficile. (plusieurs heures)

Même une connexion par câble éthernet 100Mbit/s croisé c'est illusoire pour la milliseconde. Par contre 10ms on tient la précision.

 

Avec un câble catégorie 5e et du Gbit/s, ça passe. on est sur base de temps à 100Mhz au lieu de 31Mhz en 100Mbit/s et le code reste pauvre, 5 moments, il faut quelques périodes, on atteint vite les 10% rien que par le transit.

 

Explication :

1) La partie physique PHY et MAC (media access coding & control)

Pour le Gbit, on est à 5us de temps de propagation pour 100m, c'est tout petit mais on voit que certains paquets vont dépasser ce temps : il faut que le paquet d'horodatage passe.

64 octets = 0.5us.

1518 octets ~=12us.

https://perso.liris.cnrs.fr/alain.mille/enseignements/emiage/emiage - ModuleC214/MB/214_3_3.htm#Le Path Delay Value en 100 Base T

 

On est à 1/50eme, potentiellement ça passe, la latence dans le câble et les équipements électroniques est petite.

 

* En 100 Mbit/s, on est à 1/5ms, c'est la taille de paquet qui est lente, pas la transmission : on tape déjà dans la limite des 20-30% de jitter sans compter le traitement informatique dans le système d'exploitation.

 

2) La partie informatique

Il faut former le paquet à transmettre sur le déclenchement de la PPS qui arrive de l'antenne GPS, sur une solution type pilote bas niveau c'est par une interruption rapide prioritaire.

Ensuite curieusement, on passe par le remplissage du buffer de la carte réseau, le paquet ethernet transite déjà une fois du cpu vers un périphérique (première latence à une vitesse pas beaucoup plus élevée que ce que le périphérique va mettre à transmettre)

2eme latence : la transmission

3eme latence dans la carte réseau distante.

Ceci explique la limite à 30% de ping de carte à carte, globalement on multiplie cette base par trois (en fait plutôt x2 quand la carte réseau est bien conçue).

 

Maintenant, si on compte les temps CPU, on voit qu'il faut se mettre en mode temps réel pour le pilote, parfait pour un raspberry, moins sur windows malgré la haute fréquence d'horloge des CPUs des PCs.

Sur un Raspberry Pi 800Mhz, j'ai vu des benchs "siege" dont un à 1300 hits/s sur un apache 2.2 en 2019. On est proche du fonctionnement demandé.

 

Ça reste juste pour de la milliseconde mais j'y crois.

 

Sur PC : W32Time version 2016 (dans windows 10 aussi) a corrigé pas mal de bêtises qui ont fait la mauvaise réputation de windows pour la synchro horaire. Microsoft a enfin lâché l'affaire pour passer à une reprise de la norme NTP.

Mais rien ne vous empêche d'installer un produit en mode noyau, ma confiance en microsoft là-dessus n'est pas meilleure que vous :P.

 

Mon expérience en entreprise. (j'y suis depuis fin 2020)

Nous fonctionnons en carte intégrée° sur les serveurs, seule les multiples antennes GPS sont externalisées sur trois sites distants de 660km environ (dont un est double). Le produit est du Lantime de chez Meinberg, qui est aussi, connu dans ses pires bêtises du début mais c'était dans les années 2000. C'est du sérieux maintenant.

La solution a été créée "from scratch" et fonctionne depuis 2003, et nous avons fêté 20 millions de contrats horodatées eIDAS cette année soit des millions de transactions horaires intermédiaires.

 

https://www.meinberg-usa.com/products/pci-and-pcie-slot-cards.htm

image.png.9b0e3c08a47568072cccd973fcdafcb9.png

 

°Faut pas rêver, ça ressemble furieusement à la solution citée par astroluma, c'est juste l'enrobage pro, le support et la redondance pour assurer du 4h max de coupure de service par an. (panne et maintenance)

Bon, on a quand même des doubles attachements fibre optique (entre les serveurs) mais le comble c'est que ça ralentit un peu en comparaison des câbles direct sur un réseau si peu encombré en mode silo.

Pour vous faire sourire (je n'étais pas là à l'époque), la dernière perturbation sérieuse date des éruptions solaire autour de Sept 2017 si je me souviens.

 

Ce soir là j'étais à Annecy et j'ai vu une aurore boréale en France (il y a un post Astrosurf sur le sujet), ciel rose au zénith, et des rideaux de vert, du violet quand je suis montée au Semnoz pour profiter du spectacle (très tênu certes) : la quatrième dimension et quelques gens qui s'attendaient à la fin du monde, d'autres qui sortait du bar l'Horloge en pensant qu'ils avaient trop bu mais aussi 80% de la population qui ne lève jamais la tête et qui finira con sur son appartenance à l'échelle cosmique.

Sur cette période de Septembre Octobre, il y a eu de nombreux incidents électroniques au Canada et nord des USAs. La magnétosphère terrestre (notre bouclier magnétique) a été arraché à 70%. Un flare de plus et c'était le black-out mondial. Les particules émises sont arrivées une dizaine d'heures plus tard, nous, européens, étions protégés et avons profités du spectacle.

Pour les amateurs d'histoire : https://youtu.be/LLO9WxVO9s8

 

Modifié par lyl

Partager ce message


Lien à poster
Partager sur d’autres sites

Le plus simple c'est effectivement NTP avec partage de connection internet.

Tu télécharge le soft Meinberg NTP est c'est réglé...tu seras facilement à < 20ms

Partager ce message


Lien à poster
Partager sur d’autres sites

Je viens d'essayer Meinberg avec mon gps pps,

Meinberg a un "retard" entre guillemet, je suppose que c'est mon ordi win11 I7.. de 11 à 13ms par rapport à la led du gps/pps

Le mieux c'est d'utiliser NMEATime2, de régler l'offset avec une caméra rapide usb3 pointé sur la LED.

6366a3209bb57_NTPGPSppsb.jpg.8ade709e6ffc21a5e9f3de8f5eea6939.jpg

Modifié par Saci-

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 11 minutes, lyl a dit :

Sans déc. ça ne sert à rien de mettre des pairs level 3 si tu prends une référence GPS : tu fais juste diverger l'algorithme.

je n'utilise pas ce soft étant itinérant, mais si tu as un tuto pour les paramètres avec un gps/pps et Meinberg .

le 21 Novembre j'ai une occultation depuis chez moi...ça serait sympa d'essayer avec.

merci

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 05/11/2022 à 19:33, Saci- a dit :

Meinberg

Je n'utilise pas Meinberg, j'ai donné la documentation pour l'adaptation ntp de Microsoft :  W32TIme (W10 minimum) dans mes premiers posts.

Pas besoin de surcouche avec un produit noyau natif qui peut faire le boulot.

 

https://learn.microsoft.com/fr-fr/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings

 

 

ma configuration en 3 minutes après relance du service

 

Citation

w32tm /config /manualpeerlist:"ntp.obspm.fr" /syncfromflags:manual /update
net stop w32time
net start w32time

puis

Citation

 

C:\WINDOWS\system32>w32tm.exe /query /status
Indicateur de dérive : 3(Non synchronisé)
Couche : 0 (Non spécifié)
Précision : -23 (119.209ns par battement)
Délai de racine : 0.0181334s
Dispersion de racine : 9.0364456s
ID de référence : 0x00000000 (Non spécifié)
Heure de la dernière synchronisation réussie : 05/11/2022 21:02:08
Source : ntp.obspm.fr
Intervalle d’interrogation : 10 (1024s)


C:\WINDOWS\system32>w32tm.exe /query /status
Indicateur de dérive : 0(Aucun avertissement)
Couche : 3 (Référence secondaire, synchronisée par (S)NTP)
Précision : -23 (119.209ns par battement)
Délai de racine : 0.0172329s
Dispersion de racine : 7.7971323s
ID de référence : 0x91EECB0A (IP de la source :  145.238.203.10)
Heure de la dernière synchronisation réussie : 05/11/2022 21:02:25
Source : ntp.obspm.fr
Intervalle d’interrogation : 10 (1024s)

 

Dans quelques heures, je devrais être à 50-100 ms

Pour l'instant c'est pas mal du tout en 7 minutes mais il faut laisser l'algorithme calculer la dérive de l'horloge interne du PC.

Objectif atteint : < 20ms

Citation

C:\WINDOWS\system32>w32tm  /stripchart /computer:ntp.obspm.fr
Suivi de ntp.obspm.fr [145.238.203.10:123].
L’heure actuelle est 05/11/2022 21:07:04.
21:07:04, d:+00.0179743s o:+00.0067495s  [                           *                           ]
21:07:06, d:+00.0186845s o:+00.0067216s  [                           *                           ]
21:07:08, d:+00.0184983s o:+00.0068125s  [                           *                           ]
21:07:10, d:+00.0182220s o:+00.0069865s  [                           *                           ]
21:07:12, d:+00.0179311s o:+00.0070569s  [                           *                           ]
21:07:14, d:+00.0182544s o:+00.0070263s  [                           *                           ]
21:07:16, d:+00.0178749s o:+00.0071476s  [                           *                           ]
21:07:18, d:+00.0181505s o:+00.0068541s  [                           *                           ]
21:07:20, d:+00.0183744s o:+00.0072244s  [                           *                           ]
21:07:22, d:+00.0180561s o:+00.0071374s  [                           *                           ]
21:07:25, d:+00.0177928s o:+00.0072516s  [                           *                           ]
21:07:27, d:+00.0186234s o:+00.0072116s  [                           *                           ]
21:07:29, d:+00.0179220s o:+00.0077250s  [                           *                           ]

-------------

1/2h plus tard : dérive de 35ms, on est toujours près de la marge de 3* le Path Delay Value du moyen de transmission.

Citation

C:\WINDOWS\system32>w32tm  /stripchart /computer:ntp.obspm.fr
Suivi de ntp.obspm.fr [145.238.203.10:123].
L’heure actuelle est 05/11/2022 21:36:37.
21:36:37, d:+00.0178572s o:+00.0339986s  [                           *                           ]
21:36:39, d:+00.0181891s o:+00.0341533s  [                           *                           ]
21:36:41, d:+00.0183924s o:+00.0344824s  [                           *                           ]
21:36:44, d:+00.0180092s o:+00.0342090s  [                           *                           ]
21:36:46, d:+00.0178210s o:+00.0341335s  [                           *                           ]
21:36:48, d:+00.0180093s o:+00.0343788s  [                           *                           ]
21:36:50, d:+00.0183847s o:+00.0343153s  [                           *                           ]
21:36:52, d:+00.0183673s o:+00.0344651s  [                           *                           ]
21:36:54, d:+00.0180779s o:+00.0340963s  [                           *                           ]

21:36:56, d:+00.0177430s o:+00.0343822s  [                           *                           ]

Le prochain de train de synchro est prévu à t0 + n*1024s (toutes les 17minutes)

Ce n'est pas en 1/2h que le paramétrage se stabilise.

--------------

1h, les paramètres sont remplis dans la registry windows, ça dérive moins : ~200us / 30s (7ppm) contre 1ms / 25s (40ppm) au début de la synchro.

Dans l'algorithme, il va, je pense, se passer un petit saut pour régler l'offset quand on arrivera vers 1ppm

Citation

 

21:56:13, d:+00.0182625s o:+00.0484766s  [                           *                           ]
21:56:15, d:+00.0181039s o:+00.0488147s  [                           *                           ]
21:56:17, d:+00.0176224s o:+00.0490077s  [                           *                           ]

 


C:\WINDOWS\system32>w32tm  /stripchart /computer:ntp.obspm.fr
Suivi de ntp.obspm.fr [145.238.203.10:123].
L’heure actuelle est 05/11/2022 21:57:04.
21:57:04, d:+00.0174701s o:+00.0491809s  [                           *                           ]
21:57:06, d:+00.0180992s o:+00.0493835s  [                           *                           ]
21:57:08, d:+00.0178406s o:+00.0492424s  [                           *                           ]
21:57:10, d:+00.0178433s o:+00.0491977s  [                           *                           ]
21:57:12, d:+00.0180524s o:+00.0493426s  [                           *                           ]
21:57:14, d:+00.0181650s o:+00.0491585s  [                           *                           ]
21:57:16, d:+00.0183205s o:+00.0493185s  [                           *                           ]
21:57:18, d:+00.0183698s o:+00.0490006s  [                           *                           ]
21:57:20, d:+00.0182053s o:+00.0495224s  [                           *                           ]
21:57:22, d:+00.0183912s o:+00.0491463s  [                           *                           ]
21:57:24, d:+00.0186520s o:+00.0496294s  [                           *                           ]
21:57:26, d:+00.0178701s o:+00.0495763s  [                           *                           ]
21:57:28, d:+00.0180006s o:+00.0494914s  [                           *                           ]
21:57:30, d:+00.0188286s o:+00.0492289s  [                           *                           ]
21:57:32, d:+00.0177433s o:+00.0494944s  [                           *                           ]
21:57:34, d:+00.0182691s o:+00.0493956s  [                           *                           ]

 


---------

 

Paramétrages finaux : il y a une valeur large sur un paramétrage par défaut qui est à 5 secondes.

 

largephaseoffset à 3-10 fois le délai PDV (ou ping), ici le ping est ~18ms => 54 à 180ms

 

Pour moi en ADSL vers l'observatoire de Meudon, je peux espérer 100ms.

 

=> w32tm /config /manualpeerlist:"ntp.obspm.fr" /syncfromflags:manual /largephaseoffset:100 /update

 

Sur le GPS en câble croisé : tu peux mettre bien moins comme expliqué au-dessus : 1 ou 2 ms.

 

w32tm /config /manualpeerlist:"<ip du GPS> ntp.obspm.fr" /syncfromflags:manual /largephaseoffset:1 /update

 

l'ip du GPS est celle simulée par l'équipement. En externe (câble croisé) ou en carte interne (par le driver via la pile TCP)

et voilà une configuration simple contrôlée avec Meudon en secondaire.

 

Ensuite quand la synchro est faite sur une longue période, tu peux déconnecter le GPS et partir en autonome avec la dérive d'une horloge TXCO à 10ms / jour.

Je ne conseille pas de triturer les minpoll et maxpoll à 6 (64s), ça ne sert qu'à synchroniser rapidement l'offset sans faire le boulot d'ajustement de fréquence. C'est du cache misère.

 

Avec une source  <= 1ms /j et un ordi à 10ms / j (horloge TCXO XO, j'ai ouvert la bête ) il faut environ 2 à 3 dixième de jour ou 2h30 - 4h pour que le coefficient d'ajustement de fréquence soit bien calculé.

Modifié par lyl
  • Merci 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 3 heures, Saci- a dit :

 de régler l'offset avec une caméra rapide usb3 pointé sur la LED.

 

C'est une solution économique? et pourquoi ton logiciel connaîtrait mieux l'instant d'arrivé de l'image que celle d'un PPS sur une entrée quelconque (fil d'un port série ou // par exemple).

 

Sérieusement n'importe quel processeur peut dater un évènement (par exempla le PPS rdu GPS elié à une ligne d'interruption) entre 5 et 10 micro seconde presque tout le temps et en 20 à 40 microsecondes (selon les processeurs) absolument tout le temps. Pour que cette capacité devienne accessible, le truc s'appellent un OS temps réel (acronyme anglais RTOS). Cela existe sous formes d'extensions de linux (Xenomai) et de Windows (RTX peut être d'autres).

 

Avec un PC si il y a de vrais ports série ou parallèle, ils ont des entrées qui peuvent déclencher une interruption. Sinon, ce PC n'est pas fait pour çà.

 

 

Modifié par crub

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 37 minutes, crub a dit :

et pourquoi ton logiciel connaîtrait mieux l'instant d'arrivé de l'image que celle d'un PPS sur une entrée quelconque (fil d'un port série ou // par exemple).

CE logiciel ne connait rien du tout c'est toi qui règle l'offset du pc via une caméra et SharpCap.

6366e0180dbb3_GPSPPSNMEATime2.jpg.c26b75a937720c037ed1ed81d49b374a.jpg

ici une comparaison avec le gps/pps et une antenne dcf77

GPS pps VS DCF77.lc

Modifié par Saci-

Partager ce message


Lien à poster
Partager sur d’autres sites

Les chamailleries ne servent à rien, on est là pour proposer des réglages qui fonctionnent.

Il est 23h14 soit ~2h15 après que j'ai lancé ma configuration

Je suis à 135ms de dispersion statistique sur de l'ADSL.

Encore un peu de patience (mais là c'est dodo) et l'objectif de 100ms de dispersion sur le temps réel avec une confiance très élevée sera atteint.
 

Citation

 

C:\WINDOWS\system32>w32tm.exe /query /status /verbose
Indicateur de dérive : 0(Aucun avertissement)
Couche : 3 (Référence secondaire, synchronisée par (S)NTP)
Précision : -23 (119.209ns par battement)
Délai de racine : 0.0184363s
Dispersion de racine : 0.1350701s
ID de référence : 0x91EECB0A (IP de la source :  145.238.203.10)
Heure de la dernière synchronisation réussie : 05/11/2022 23:01:53
Source : ntp.obspm.fr
Intervalle d’interrogation : 11 (2048s)

Décalage de phase : 0.0596518s
Fréquence d’horloge : 0.0156249s
Ordinateur d’état : 2 (Synchroniser)
Indicateur de source de temps : 0 (Aucun)
Rôle de serveur : 0 (Aucun)
Erreur lors de la dernière synchronisation : 0 (La commande s’est terminée correctement.)
Durée écoulée depuis l’heure de la dernière synchronisation réussie : 680.1942512s


C:\WINDOWS\system32>w32tm  /stripchart /computer:ntp.obspm.fr
Suivi de ntp.obspm.fr [145.238.203.10:123].
L’heure actuelle est 05/11/2022 23:13:32.
23:13:32, d:+00.0178938s o:+00.0761706s  [                           *                           ]
23:13:34, d:+00.0179820s o:+00.0761214s  [                           *                           ]
23:13:36, d:+00.0173586s o:+00.0764032s  [                           *                           ]

 

 

 

et enfin rendre le service actif à chaque démarrage, j'ai constaté qu'il est en manuel

https://learn.microsoft.com/fr-fr/windows-server/administration/windows-commands/sc-config

 

C:\WINDOWS\system32>sc.exe config W32Time start=delayed-auto
[SC] ChangeServiceConfig réussite(s)

 

Note : ne pas démarrer le service quand windows est en pleine charge lors du démarrage, le faire à la fin quand tous les services principaux ont été lancés.

Le service ntp lance des paquets de synchronisation à son lancement. Si le système est chargé, ceci a tendance à créer de mauvais ajouts aux statistiques et à fausser les deux variables de corrections (offset & fréquence)

Modifié par lyl

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 2 minutes, lyl a dit :

on est là pour proposer des réglages qui fonctionnent.

tout à fait

en tout cas ce qui compte c'est l'horodatage précis lors d'une occultation..

Partager ce message


Lien à poster
Partager sur d’autres sites

pour confirmation, aujourd'hui relance du PC à 11h30 : 107ms de l'heure théorique à T+2h de la reprise de synchro 

J'ai un ping moins bon qu'hier : 22ms

 

Citation

C:\WINDOWS\system32>w32tm /query /status
Indicateur de dérive : 0(Aucun avertissement)
Couche : 3 (Référence secondaire, synchronisée par (S)NTP)
Précision : -23 (119.209ns par battement)
Délai de racine : 0.0222615s
Dispersion de racine : 0.1071138s
ID de référence : 0x91EECB0A (IP de la source :  145.238.203.10)
Heure de la dernière synchronisation réussie : 06/11/2022 13:12:46
Source : ntp.obspm.fr
Intervalle d’interrogation : 11 (2048s)

 

A la relance il s'est produit une correction d'offset mais le service a gardé la correction de fréquence du crystal, on converge plus rapidement.

Je conseille quand même de laisser le PC connecté sur le net une vingtaine de minutes pour récupérer 2 échantillons de la part de vos serveur de temps préféré.

 

Pour la configuration avec GPS connecté, je dirais que quelques minutes suffisent, il s'agit juste de recaler l'offset avec le GPS au lancement du PC.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour et merci pour vos contributions :)

 

Serait il possible de synthétiser les différentes méthodes et manipulations à effectuer  que ce soit en méthode soft ou hard?

 

 

Edit : je viens de télécharger le Logiciel : NMEATime2, lien de Daniel @teko38 (merci Daniel ;)) , il m'a reconnu mon antenne GPS immédiatement , il s'agit dune antenne GPS à base de chipset u-blox 8, 

Le soft est censé ajuster automatiquement l'heure du pc avec l'antenne GPS, maintenant, comment vérifier sa précision?

il s'agit d'une version d'essai, mais licence possible pour 20.48$.

 

 

Merci encore de vos retours !

 

Manu.

 

 

 

 

Modifié par manu33

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 5 heures, manu33 a dit :

Le soft est censé ajuster automatiquement l'heure du pc avec l'antenne GPS, maintenant, comment vérifier sa précision?

Tu as toute l'explication dans mes posts pour l'outil natif et gratuit de windows.

Il n'y a que deux commandes à passer mais il faut lire la documentation de ton GPS.

Modifié par lyl

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 4 heures, lyl a dit :

Il n'y a que deux commandes à passer mais il faut lire la documentation de ton GPS.

Si tu peux faire un tuto pas à pas ça nous arrangeaient,  de plus comment trouver le port com du gps dans l'invit de commande ?

 

Il y a 9 heures, manu33 a dit :

Le soft est censé ajuster automatiquement l'heure du pc avec l'antenne GPS, maintenant, comment vérifier sa précision?

Tu cliques sur tool dans NMEATime2----> Set time différence offset-----> Apply Calibration Value ---> OK .. aussi il faut te connecter mais ça reste imprécis si je le compare avec la led/pps(100ms)

Si tu veux une grande précision à la milliseconde prés il te faut un gps avec une led qui envoie les pulses par seconde puis tu règles toi-même l'offset, pour ça il te faut SharpCap(horodatage, turbo, etc) un pc usb3(1000fps/s en fen^trant) et une caméra ub3..

ici quelques explications et liens en bas de page dans mes tests:

 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 10 minutes, Saci- a dit :

Si tu peux faire un tuto pas à pas ça nous arrangeaient,  de plus comment trouver le port com du gps dans l'invit de commande ?

Non je ne peux pas sans la doc du GPS

Partager ce message


Lien à poster
Partager sur d’autres sites

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant



  • Contenu similaire

    • Par COM423
      Bonsoir,
       
      Le mois dernier, je vous avais proposé le compte-rendu d'une observation en mode rapide de M40, juste avant que le ciel ne se voile totalement, dans des conditions non optimales mais que je considérais alors comme suffisantes pour tirer le portrait d'un banal couple d'étoile, cette 40ème entreé du célèbre catalogue ne résumant en fait à 2 étoiles !
      Sauf qu'en traitant les images, j'ai trouvé dans le champ :
      de belles galaxies qui méritaient largement un peu plus de poses, et une étrange nébulosité rouge dans le coin supérieur gauche de l'image  
      Toute cette première partie est relatée dans ce post :
       
      Cela faisait donc de bonnes raisos pour y retourner, et j'ai craqué dès la première nuit de cette lunaison de février
       
      Le mystère de la nébulosité est levé, il s'agit juste de reflets :

      soit :
      liés à 70 Uma (V=5.5) présente dans le champ, soit, plus vraisemblablement, à Megrez alias Delta Uma de V=3.3 située à 01°06' de 70 Uma...  
      Avec l'ajout de poses supplémentaires, le gain sur les trois belles galaxies du champ est appréciable :
       
      * De gauche à droite : NGC 4284 et NGC 4290 et UGC 7534 dans le cadre de droite :

       
      je ne l'avais pas remarqué sur le compositage avec les seules images du mois de janvier, mais le champ contient aussi une grande concentration de petites galaxies faibles juste au-dessus de l'étoile HD 107949 :

      On les retrouve sur la carte Simbad :

       
      çà ressemble à un cluster de galaxies, mais je n'ai pas trouvé de nomenclature associée.
      ==> si quelqu'un a des infos, je suis donc preneur !
       
      Voici le résultat du compositage des deux sessions d'images, ramené à un échantillonnage de 2"/pixel plus en adéquation avec le FWHM de l'image, c'est du bio sans réduction d'étoiles ou réelle atténuation du bruit, j'ai juste adouci la transition pour les bouts inférieur et supérieurs de l'image finale qui comporte moins de poses que la zone de recouvrement centrale(*) :
      (*): à cause la possible nébulosité sur le haut de l'image, la cession de février a été cadrée plus vers le haut que celle de janvier
       
      ( Clic droit puis Ouvrir dans un Nouvel Onglet/Nouvelle Fenêtre pour voir l'image à 100% )

      Newton SW 200/800 avec correcteur de coma, caméra ASI 294-MCpro + IR-cut,  Nord à peu près en Bas
      Monture AZ-EQ6 - ASIAir - poses guidées avec dithering
      Sur deux nuits les 13/14 janvier puis 03/04 février 2024
      53 poses de 02 min à -15°C, Temps d'intégration de 01 h 46 min
       
      Traitement Siril-1.2.0, Finition avec Gimp 2.10.28
      Échantillonnage ramené à 2"/pixel
       
      Un visiteur est venu se balader en ce matin du 4 février au-dessus de 70 Uma :

      Il est connu, il s'agit de (36273) 2000 AM68, il était de V=17,4.
       
      Et voilà, au départ je n'aurais jamais pensé consacrer tant de temps à M40, mais j'ai finalement pris un grand plaisir à imager cet objet et espère vous l'avoir fait partager
      Très bon week-end à toutes et tous.
    • Par COM423
      Bonsoir,
       
      Je vous propose ce soir une petite conjonction assez photogénique entre la comète à sursauts, 29P/Schwassmann-Wachmann 1, et la galaxie spirale NGC 2595, plus quelques galaxies plus faibles :
       
      ( Clic droit puis Ouvrir dans un Nouvel Onglet/Nouvelle Fenêtre pour voir l'image à 100% )

      Newton SW 200/800 avec correcteur de coma, caméra ASI 294-MCpro + IR-cut,  Nord à peu près en Bas
      Monture AZ-EQ6 - ASIAir - poses guidées avec dithering
       
      Nuit du 15 au 16 janvier 2024, de 00h15 à 03h00 utc
       
      71 poses de 2min à -15°C, Temps d'intégration de 02 h22 min
       
      Traitement Siril-1.2.0, Finition avec Gimp 2.10.28
      Échantillonnage ramené à 2"/pixel
       
       
      29P/SW1 présente une très large chevelure résultant des sursauts à répétition du mois de décembre où elle fut particulièrement active, et elle a d'ailleurs eu un nouveau sursaut de 2 magnitudes le soir mème (!) :

      © Richard MILES, BAA : https://britastro.org/section_information_/comet-section-overview/mission-29p-2/latest-lightcurve-plot-of-29p
       
      Elle s'étend sur 5.3' de diamètre avec une coma interne plus marquée de 1.3' de diamètre.
      On devine aussi une petite et faibe extension de 30" vers PA=43° :

       
      Voici le résultat des mesures photométriques :
      magnitude totale, m1 = 11.5 (rayon d'ouverture de 5') magnitude nucléaire : m2 = 16.3 (rayon d'ouverture de 6")  
      La zone s'avère également riche en astéroîdes de passage, j'i annoté la trace laissée par quatre d'entre eux particulièrement bien visible
       
      Bonne soirée et très bon ciel à vous
       
    • Par jfleouf
      Salut à tous,
       
      Depuis quelques temps je me suis remis à fond dans les observations d'occultation d'étoiles par des astéroïdes et je crois bien être tombé sur une chouette observation. Le 14 Janvier vers 6h UTC, l'astéroïde (10424) Gaillard (magnitude 18) occultait l’étoile UCAC4 558-046959 (magnitude 12.96)  et ma maison se situait dans la zone de 7km de large. Un événement à priori anodin, mais qui peut permettre d'affiner l'astrométrie de l'astéroïde ainsi que ses dimensions. OccultWatcher me donnait 76% de probabilité d'observer une occultation (les imprécisions dans l'astrométrie des astéroïdes fait qu'on a une marge d'imprécision plus ou moins grande dans la prédiction de leur position et ces occultations servent entre-autres à affiner ceci) avec une durée max de 0.7 secondes (le diamètre estimé de cet astéroïde est de 6.5 km et il se baladait à la vitesse de 0.64" par minute).
       
      Grosse surprise pendant l'enregistrement : je vois l'étoile disparaître deux fois, avec une réapparition d'une fraction de secondes entre les deux. Voici la courbe de lumière tirée de l'analyse du fichier .ser avec PyMovie. C'est fait avec une ASI533MM sur un C11 F/1.9 (échantillonnage = 1.44" par pixel). Shutter speed = 90ms et gain à 95% (oui, je sais, c'est bourrin)
       
      (Juste un petit bout de la courbe, centré sur la double occultation)

       
      Il y a deux explications possibles pour ce genre de courbe : (1) l'étoile cible est une binaire serrée ou (2) l'astéroïde est binaire. Je me suis fait une analyse assez détaillée pour conclure que ça ne peut pas être une étoile binarie. Le détail est ici (en anglais, sorry...): https://jfgout.github.io/occultations/gaillard-20240114.html
       
      En gros, si c'était une étoile binaire on devrait toujours voir le signal d'une des deux composantes. Et là, la chute de signal est bien plus importante que la division par deux attendue dans le pire des cas (= un système binaire avec 2 étoiles de même magnitude).
       
      Bref, je pense bien avoir observé une occultation par un astéroïde binaire  
       
      A noter que cet astéroïde est nommé pour Boris Gaillard, un astronome amateur qui avait bossé sur le programme informatique de détection d’astéroïdes utilisé par les découvreurs (http://www.minorplanetcenter.net/db_search/show_object?object_id=10424). Découvreurs qui ne sont autres que les membres du projet ODAS (OCA-DLR Asteroid Survey  https://fr.wikipedia.org/wiki/OCA-DLR_Asteroid_Survey). Une affaire bien française donc.
       
      Ça serait sympa de faire passer l'info à Boris Gaillard. Je ne le connais pas, mais une petite recherche sur google me fait penser que certains ici doivent le connaitre, notamment @Laurent51. Donc si vous connaissez Boris Gaillard, merci de lui faire suivre cette info  
       
      Je vais aussi envoyer un petit mail à Alain @maury pour lui signaler cette observation, vu qu'il me semble que c'est lui le découvreur/nomeur de cet astéroïde.
       
      Bonus: le GIF de la double occultation :
       

       
      Et l'image de repérage pour ceux qui ont du mal :
       

       
      JF
       
       
    • Par COM423
      Bonjour,
       
      Je vous propose aujourd'hui un long compositage sur ... l'amas DoDz 1 dans le Bélier et quelques tâchouilles de fond de ciel
       
      Au départ, j'avais espoir de capturer la comète périodique 39P/Oterma donnée à la mag 21.1 (le 05 janvier dernier), passée au périhélie le 10 juillet 2023 puis au périgée 5 mois plus tard.
       
      Pas facile à cette magnitude mais je pensais le challenge atteignable, pour paraphraser @exaxe17, moi aussi :
      "j'aime bien tenter des trucs! sur un malentendu cela pourrais passer un jour!"
       
      39P était alors observable pendant près de 5h et, en plus, elle se déplaçait très lentement (0.02"/min) ce qui facilitait grandement l'analyse de l'image compositée sur elle !
       
      Malheureusement, elle ne ressort pas malgré le long temps d'exposition, je suis donc déçu et, en même temps, content d'avoir tenté le coup quand même histoire de n'avoir aucun regret !
       
      A défaut de comète, le compositage montre les traînées de deux astéroïdes de mag 18 à 18.5, et donc en vedette l'amas DoDz 1 (groupe d'étoiles à gauche de l'astéroîde Seine)
       
      ( Clic droit puis Ouvrir dans un Nouvel Onglet/Nouvelle Fenêtre pour voir l'image à 100% )

      Newton SW 200/800 avec correcteur de coma, caméra ASI 294-MCpro + IR-cut,  Nord à peu près en Bas
      Monture AZ-EQ6 - ASIAir - poses guidées avec dithering
       
      Nuit du 11 au 12 janvier 2024, de 17h29 à 22h32 utc
       
      141 poses de 2min à -15°C, Temps d'intégration de 04 h42 min
       
      Traitement Siril-1.2.0, Finition avec Gimp 2.10.28
      Échantillonnage ramené à 2"/pixel
       
      39P/Oterma se trouve dans le cadre dessiné au milieu de l'image.
      La magnitude limite du compositage est vers V=20,6, çà s'est donc joué de peu, sans doute à cause de la forte humidité de la nuit
       
      Si on regarde de près, il y a un vague signal à la position attendue :

      mesuré à V=21,6 mais c'est tellement dans le bruit de fond qu'il est totalement impossible de valider une telle détection...
       
      A moins de 10° de là, brillait fièrement le coupable principal de cet échec : la planète Jupiter comme pour me narguer
       
      En effet, si elle est devenue aussi faible c'est parce que le 12 avril 1963, la comète est passée à 0.095 ua de Jupiter à peine, ce qui a eu pour conséquences :
      d'augmenter la distance périhélique de 3.39 à 5.47 ua, et la période orbitale de 7,9 à 19,4 ans  
      Avant cet évenement, c'était une comète nettement plus accessible !
      Quand elle fut découverte en 1943, elle était de magnitude 15,  sa période était alors  de 8 ans seulement. Elle fut d'ailleurs observée aux deux passages suivants, en 1950 puis 1958.  
      Mais la comète n'a pas été retrouvée lors de son passage suivant, en 1983, et finalement imagée lors de celui d'après, en 2002, mais à la magnitude 22 !
       
      Pour ce passage, elle a été observée dès la fin 2019, mais totalement hors de portée de nos instruments amateurs, à la magnitude 24
       
      Ce début d'année représentait vraiment la meilleure opportunité, pour ce passage, mais c'était un poisson trop gros un astre trop faible pour mon T20cm 
       

       
      Je l'avais déjà tentée en septembre 2021, sur 3 nuits consécutives, mais sans résultat probant...
       
      On ne gagne pas à tous les cas, il faut savoir l'accepter en attendant de gagner au loto pour monter en diamètre
       
      Très bon week-end à toutes et tous
    • Par FranckiM06
      Bonjour à tous,
      Alors par chance hier j'ai eu le ciel découvert durant toute la nuit (chose qui n'était pas prévu du tout par météoblue) alors j'en ai profité pour continuer mon avancement de mon futur panorama . 
      Pour cette nébuleuse sombre IC 2087, j'ai pu faire 105 x 180s avec la petite FS60 et la 2600MC + le filtre UV/IR/L. Et ce matin en faisant le traitement, j'ai découvert (grace à Stéphane) COM423 que c'était en fait l'astéroide 389 industria qui passait par là . Il fût découvert en 1894 par Auguste Charlois. 
       

  • Évènements à venir