Computer-Uhr synchronisieren mit USB-GPS-Maus?

willi schrieb:
> Hintergrund ist, ich möchte mit digitalen Übertragungsverfahren im
> Amateurfunk experimentieren.

Falls du damit sowas wie FT8 meinst: dafür kannst du die Computeruhr 
sogar mit der Hand genau genug stellen, ±0,5 s genügt locker. Wenn der 
Computer am Internet hängt, ist ein NTP-Server dafür das Mittel der 
Wahl.

Den NTPD gäbe es auch für Windows, und IIRC kann der auch via GPS Maus 
die Zeit einlesen.

Allerdings ist es auch dann i.d.R. einfacher die Internet Zeitserver zu 
benutzen.

willi schrieb:
> Wenn ±0,5 s genügt, warum installieren sich die Leute dann
> Zusatzprogramme wie oben verlinkt?

Das musst du die "vielen Leute" fragen, nicht mich.

Wenn ich mir die Beschreibung des Programms so ansehe, dann scheint mir 
das aus einer Zeit zu stammen, als Windows eben noch kein NTP mit 
Bordmitteln gesprochen hat.

Wenn du für FT8 schon eine ungefähre Zeit im Computer eingestellt hast, 
kannst du auch einfach den Empfänger anwerfen und ein paar Stationen 
mithören. Die üblichen Programme zeigen dir die Zeitdifferenz der 
jeweiligen Aussendung zu deiner eigenen an. Wenn diese sich im Mittel 
stark von 0 weg bewegen, dann kannst du deine Uhr ein Stück so 
nachjustieren, dass der Mittelwert der Differenzen nahe 0 wird. Das ist 
jetzt nicht ganz so bequem wie NTP, dafür funktioniert es völlig ohne 
Internet oder DCF-77-Uhr.

willi schrieb:
> Hallo,
> wie genau ist die Synchronisation der Computer-Uhr mit Hilfe einer
> USB-GPS-Maus und mit welcher Software kann man das am einfachsten
> machen? Ist das genauer als mittels Zeitserver über Internet wie z.B.
> mit dieser Software: https://www.timesynctool.com/

USB ist doof. Besser ist eine ECHTE serielle Schnittstelle und ein 
Empfänger, der ein PPS-Signal ausgibt (Pulse Per Second). Bei USB hast 
Du unkontrollierbare Latenzen drin.

Hintergrund:
GPS-Empfanger geben ihre Daten meist über NMEA0183 aus. Das ist ein 
ASCII-Datenstrom, der verschiedene Telegramme enthält. Eines dieser 
Telegramme ist das ZDA-Telegramm:
$GPZDA,172809.456,12,07,1996,00,00*45
Da ist es also 17:28:09 am 12.07.1996.
Das kommt seriell mit 4800 oder 9600 bps.

Da der String ja schon zur Übertragung einige ms braucht, ist allein 
dadurch schon ein gewisser Offset drin, der je nachdem, was sonst noch 
alles an Telegrammen übertragen wird, schwanken kann.
Hier kommt jetzt das PPS-Signal ins Spiel. Das kommt entweder an DTR 
oder RTS des COM-Ports oder an einen GPIO-Pin, und darüber wird dann ein 
Interrupt ausgelöst. Das PPS-Signal markiert exakt den Beginn einer 
neuen Sekunde, und damit vergrößert man die Genauigkeit von einigen 10 
oder 100ms auf us.

Der Linux-Kernel hat extra einen PPS-Treiber. Du brauchst also eine 
Linux-Maschine (kann auch ein Pi oder Beaglebone oder Odroid oder so 
sein, braucht einen UART, der direkt am Prozessor oder LPC/PCIe-Bus 
hängt), den GPS Daemon (https://gpsd.gitlab.io/gpsd/), die Standard NTP 
Referenz-Implementation von David L Mills und eben einen GPS-Empfänger 
mit UART und PPS-Ausgang. Der NTPd spricht nicht direkt mit dem 
Empfänger, sondern über den Referenztreiber 28 
(http://doc.ntp.org/4.2.8/drivers/driver28.html) per Shared Memory mit 
dem GPSd, der den Empfänger ansteuert.

Diese Maschine kann dann die exakte Zeit per LAN an alle weiteren Geräte 
weitergeben. Das ist auch im Bereich 10^-5...10^-6s genau.

Windows hat einen eingebauten SNTP-Client (also vereinfachte 
Implementation, nicht so genau), und von Meinberg bekommst Du die 
Referenzimplementation des vollständigen Clients und Servers als Windows 
Binary.
https://www.meinberg.de/german/sw/ntp.htm#ntp_stable

Wenn Du aus irgendwelchen Gründen keine Linux-Maschine aufgesetzt 
bekommst (zu dumm, keine Zeit,...), verkaufen Dir Meinberg, Hopf und 
Gude gerne kommerzielle Lösungen im 10^3 Euro Bereich, die nichts 
anderes machen.

fchk

PS: Hier ein Artikel, wie es mit einem Pi geht.
https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
Ich empfehle heutzutage einen Pi 4, weil da der Ethernet-Port nicht am 
USB hängt, sondern direkt am Prozessor, was der Latenz zugute kommt. Ist 
ja alles richtig bezahlbar.

Frank K. schrieb:
> USB ist doof.

Für seinen Anwendungsfall aber locker um mehr als zwei Größenordnungen 
genauer als notwendig.

Wer sagt dir denn nun, dass die dort gemachte Behauptung überhaupt 
korrekt ist?

Wenn schon, müsstest du dein lokales NTP danach befragen.

xyz schrieb:
> Geht damit noch FT8 und ähnliches?

Hast du denn einfach mal WSJT oder dergleichen angeworfen und geschaut, 
was dort als Abweichung so steht? Anbei mal ein Beispiel, siehe die 
blau umrandete Spalte. Es ist auch deutlich zu sehen, dass EA1IEQ mit 
2,1 s der Ausreißer ist (aber auch der wird noch decodiert).

Unter Windows 10 kann man im Registryzweig

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W32Time\Config

das Synchronisationsverhalten verändern.

Mit dem Schlüssel Updateinterval kann man die Synchronisationsabstände 
verändern.

Dieser steht standardmäßig auf 360000
Ich hab es mal auf 1440 runtergesetzt.
So wird alle 24 Std. Synchronisiert.

Im Zweig Parameters kann der NTP Server geändert werden.

Mit dem Schlüssel NtpServer wird dieser festgelegt.
Ich hab dort ptbtime1.ptb.de eingetragen.

Michael M. schrieb:
> Mit dem Schlüssel Updateinterval kann man die Synchronisationsabstände
> verändern.

Das heißt, die aktualisieren die Zeit nur in diesen Abständen hart? Das 
wäre ja alles andere als state of the art – weil man dabei Sprünge in 
der Zeit bekommt, aber Zeit normalerweise stetig sein sollte.

Ja die Uhr wird dann alle 24std Synchronisiert.
Ich weiß nicht, ob man den Zeitpunkt noch festlegen kann, wann das 
erfolgen soll.
Wenn der Rechner eh immer an bleibt dann würde ich wie auch bei DCF77 um 
3 Uhr Synchronisieren.

Manfred schrieb:
> Damit bestimmt der Zeitdienst die Intervalle dynamisch, wenn er die Zeit
> für gut hält, werden die Intervalle größer.

Das wäre ja ungefähr das, was ntpd auch machen würde.

>Das heißt, die aktualisieren die Zeit nur in diesen Abständen hart? Das
wäre ja alles andere als state of the art – weil man dabei Sprünge in
der Zeit bekommt, aber Zeit normalerweise stetig sein sollte.

Bevor's vergessen geht. Windows ist nicht als Echtzeitmaschine gedacht, 
und auch nicht als solche implementiert worden. Normalerweise benoetigen 
nur externe Prozesse Echtzeit.
Wenn du eine kontinuierliche Zeit willst, lass die Synchronisierung.

Wenn du exakte Zeit und gleichzeitig synchrone Zeit willst, wird das auf 
spezieille Hardware rauslaufen.

Das werden nur sehr wenige Leute wirklich brauchen. Wenn du zB 
Radioteleskope synchronisieren willst.

Pandur S. schrieb:
> Windows ist nicht als Echtzeitmaschine gedacht, und auch nicht als
> solche implementiert worden.

Ja und? Deshalb müssen sie eine Zeitsynchronisation benutzen, wie man 
sie Ende des letzten Jahrtausends bereits als unpassend erkannt hat?

Wenn NTP noch nicht erfunden worden wäre, könnte man die Argumentation 
verstehen. So jedoch nicht.

xyz schrieb:
> Ergebnis nach https://time.is/
> Deine Uhr geht 1,5 Sekunden nach.

Danke für den Tipp mit time.is; hier Linux Mint zum Vergleich:
Your time is exact!The difference from Time.is was -0.008 seconds 
(±0.032 seconds).

Wie die allerdings meinen, die Latenz bis zu meinem Rechner rausrechnen 
zu können ist mir schleierhaft.

Gerhard Z. schrieb:
> Wie die allerdings meinen, die Latenz bis zu meinem Rechner rausrechnen
> zu können ist mir schleierhaft.

Das ist halt einer der Aspekte, die man im NTP-Protokoll berücksichtigt 
hat. Je geringer der Jitter der Übertragungszeit, um so besser lässt 
sich die Latenz heraus mitteln.

Pandur S. schrieb:

> Bevor's vergessen geht. Windows ist nicht als Echtzeitmaschine gedacht,
> und auch nicht als solche implementiert worden. Normalerweise benoetigen
> nur externe Prozesse Echtzeit.
> Wenn du eine kontinuierliche Zeit willst, lass die Synchronisierung.
>
> Wenn du exakte Zeit und gleichzeitig synchrone Zeit willst, wird das auf
> spezieille Hardware rauslaufen.

Nö. Die NTP-Referenzimplementation von David L Mills gibts auch für 
Windows - man muss sie nur benutzen.

fchk

Gerhard Z. schrieb:
> Danke für den Tipp mit time.is

Die meinen, meine Uhr wäre auf 0,2 s genau.

Die PTB meint, sie wäre auf 1 … 2 ms genau (mit einer Ungenauigkeit von 
±12 ms).

Wem sollte man mehr trauen? ;-)

willi schrieb:
> Hier habe ich ein Video dazu gefunden.
> https://www.youtube.com/watch?v=3pfIlV2KCGY
> Wie genau die Synchronisation mittels GPS ist, weiß ich allerdings
> nicht.

GPS ist sehr genau. Über einen USB-UART hast Du jedoch prinzipbedingt 
nur eine Genauigkeit im Bereich von zehntel oder vielleicht hundertstel 
Sekunden. Wenn Du es genau so machst, wie ich in meinem ersten Posting 
beschrieben habe, kommst Du auf Mikrosekunden runter.

fchk

Frank K. schrieb:
> Wenn Du es genau so machst, wie ich in meinem ersten Posting beschrieben
> habe, kommst Du auf Mikrosekunden runter.

Nur dass für seinen Anwendungsfall (FT8 & Co.) eine Genauigkeit von 100 
ms locker genügt.

Markus schrieb:
> willi schrieb:
>> Hier habe ich ein Video dazu gefunden.
>> https://www.youtube.com/watch?v=3pfIlV2KCGY
>> Wie genau die Synchronisation mittels GPS ist, weiß ich allerdings
>> nicht.

Frank K. schrieb:
> Wenn Du es genau so machst, wie ich in meinem ersten Posting
> beschrieben habe, kommst Du auf Mikrosekunden runter.

Wobei der PPS aus dem GPS-Chip nochmal ein bis zwei Zehnerpotenzen 
genauer ist. u-blox7 und u-blox8 sind beide mit ±30ns spezifiziert.

> Gibts irgendwo ein Vergleich, welcher GPS-Chip was taugt? Ist der
> u-blox7 nicht veraltet?

Naja, es gibt ein neueres Modell, das ist schneller und braucht mehr 
Strom. Der einzige Vorteil für die Synchronisation:

1

Sensitivity            u-blox7   u-blox8

2

Tracking & Navigation –161 dBm  -164 dBm

3

Reacquisition         –159 dBm  -158 dBm

4

Cold Start            –147 dBm  -146 dBm

5

Hot Start             –155 dBm  -155 dBm

aber dann das:

1

Modul-Anschlüsse   Stiftleiste  Lötpads unten drunter

Radio Erwin schrieb:
> Seltsam ist auch, dass das Teil angeblich aus der Schweiz kommt

Das Original kommt zweifelsfrei aus der Schweiz, woher sonst, es geht ja 
um Uhren.

Das ist ja ein ganz anderes Thema, ich dachte, hier geht's eher um 
Empfänger, die gerade nicht bewegt werden. Außerdem: was will ich mit 
anderen Herstellern wenn ich im u-blox Online-Shop kaufen kann?

Markus schrieb:
> Bauform B. schrieb:
>> Außerdem: was will ich mit
>> anderen Herstellern wenn ich im u-blox Online-Shop kaufen kann?
>
> Hier im Thread gehts um Anwendungen für private Endanwender nicht um
> Privilegien irgendwelcher Unternehmer

Ja, entschuldigen Sie bitte die Formulierung.
In Wirklichkeit war es so: ich als Bastler habe einen GPS-Empfänger 
zwecks Synchronisation gesucht und ein u-blox7 aus dem Online Shop war 
das Ergebnis. Außer den Komplettgeräten von Garmin habe ich nichts 
halbwegs brauchbares entdeckt. Ja, kleine Platinen für's Steckbrett, 
aber da waren dann auch u-blox Empfänger drauf.

Markus schrieb:
>> Das ist ja ein ganz anderes Thema
>
> Eher nicht. Das ist doch für jede Anwendung relevant.

Nein, für die des TE nicht.

Für seine Anwendung genügt die Synchronisation per Hand mit einer 
Armbanduhr, die genau geht.

willi schrieb:

> Nein, Synchronisation per Hand ist für mich keine Option, selbst wenn
> eine Genauigkeit von 2 Sekunden bei guten HF-Bedingungen ausreichend
> sein sollte. Das Ziel ist natürlich auch, grenzwertige
> Digital-Verbindungen zu arbeiten.

Du hast das Prinzip von FT-8 noch nicht verstanden.

Die HF-Bedingungen interessieren dabei gar nicht.

> Und warum sollte ich meine menschliche
> Reaktionszeit auch noch als Fehlervariable einbringen?

Ich habe das ja auch nicht als empfohlene Variante deklarieren wollen, 
aber irgendwelches Gefummel im Mikrosekundenbereich kannst du dir 
zumindest so lange sparen, solange Dinge wie FT-8 dein Anwendungsfeld 
sind. Da stören ein paar Millisekunden Delay über USB (und mehr isses 
nicht) wirklich überhaupt nicht.

> Schade, dass hier selbst Moderatoren versuchen den Thread durch Getrolle
> zu zerstören.

Schade, dass du sinnvoll gemeinte Ratschläge, den Aufwand mal nicht zu 
übertreiben, gleich als "Getrolle" bezeichnest.

Falls dein Ziel eine auf Millisekunden (oder bessser) genaue 
Computerzeit ist, dann kannst du natürlich dahingehend noch weiteren 
Aufwand treiben. Viele Vorschläge wurden gemacht.

Falls dein Ziel wirklich nur, wie eingangs von dir genannt, ein paar 
digitale Funkmodi sind, dann nimm den USB-GPS-Modul und eins der 
genannten Programme. Damit wirst du auch in der kompletten 
internetfreien Pampa noch glücklich, solange du auch nur einen einzigen 
GPS-Satelliten empfangen kannst. Mehr braucht's für die Uhrzeit nämlich 
nicht. (Drei braucht es für eine 2D-Position, mehr als das für eine 
3D-Position, wobei die Höhe im Allgemeinen weniger genau wird als die 
lateralen Koordinaten.)

willi schrieb:

> Frank K. schrieb:
>> Hier kommt jetzt das PPS-Signal ins Spiel.
>
> Was ist das? Wärest du so nett, das allgemeinverständlich zu erklären?
> Sonst versteht dein Text nur jemand, der es ohnehin schon weiß.

Hab ich doch eigentlich schon:
"Das PPS-Signal markiert exakt den Beginn einer neuen Sekunde, und damit 
vergrößert man die Genauigkeit von einigen 10 oder 100ms auf us."

Exakt wenn die neue Sekunde beginnt, geht das Signal hoch, und kurz 
darauf wieder runter. PPS steht für "Pulse Per Second", also 
Sekundenpuls. Damit und nur damit weißt Du bei einem GPS-Modul mit dem 
üblichen NMEA-0183 (das kannst Du bei Wikipedia eingeben) Datenformat, 
wann die nächste Sekunde beginnt.

Jetzt klar?

fchk