Hallo zusammen
ich möchte meinen PC zu einem Zeitserver umfunktionieren.
Ich habe vor einiger Zeit einen GPSDO gebaut, der spuckt über RS232 die
NMEA Daten aus ($GPRMC) sowie das 1PPS Signal.
Damit möchte ich auf meinem PC nun chrony füttern, damit die Uhr nach
GPS korrigiert wird.
Ich habe auf meinem PC Fedora 35 installiert. Die GPS-Daten kommen über
/dev/ttyS0 rein.
Ich habe mir mal gpsd installiert und lasse den laufen.
Anscheinend kommen auch richtige Daten rein, denn mit gpsmon kann ich
was sehen:
Nun stehe ich völlig auf dem Schlauch, was ich machen muss. Ich habe
buchstäblich jedes Ergebnis in Google durchgearbeitet, und man findet
dieses Thema vor allem in Bezug zu Raspberry Pi (ich möchte das später
auf einem Raspi auch gern laufen lassen, aber man kriegt im Moment keine
und wollte daher mit meinem PC üben).
Ziel sollte eigentlich sein, dass die NMEA Daten richtig empfangen und
der 1PPS Puls richtig ausgewertet wird, sodass man die dann an Chrony
füttern kann. Aber das funktioniert nicht.
Ich habe in der chrony.conf das drin
oszi40 schrieb:> https://chrony.tuxfamily.org/faq.html
das kannte ich schon. Danke trotzdem.....
oszi40 schrieb:> Warum möchtest Du unbedingt GPS benutzen, wenn es NTP gibt? Reicht die> Genauigkeit nicht? Hier im Forum sind einige Diskussionen zu finden.
Das soll ein Stratum 1 Zeitserver werden.
oszi40 schrieb:> Warum möchtest Du unbedingt GPS benutzen, wenn es NTP gibt?
GPS verwendet man dafür üblicherweise, wenn man sich auf den deutlich
mehr als 70% der Erdoberfläche befindet, wo es keine Netzwerksteckdose
gibt.
Ich meine mich zu erinnern, dass Timestamp und 1 PPS nicht von der
selben Uhr stammen dürfen. Was auch Sinn macht. Aber ich kann mich auch
irren, ist schon was her...
Ergo70 schrieb:> Ich meine mich zu erinnern, dass Timestamp und 1 PPS nicht von der> selben Uhr stammen dürfen. Was auch Sinn macht.
Warum macht das Sinn?
Die dürfen selbstverständlich vom selben GPS kommen. Nur natürlich über
verschiedene Kabelwege. Das NMEA über RX/TX vom RS232, das PPS
üblicherweise über die DCD-Leitung der selben RS232-Schnittstelle.
@TO schau Dir mal die SHM-IDs an. Damit gab es bei mir ein Problem. Da
waren die falschen IDs hinterlegt oder so. Als ich die angepasst hatte
ging es dann. Hab die genauen Details aber nicht mehr im Kopf.
Ergo70 schrieb:> Ich meine mich zu erinnern, dass Timestamp und 1 PPS nicht von der> selben Uhr stammen dürfen. Was auch Sinn macht.
Zu dieser deiner Aussage besteht doch noch etwas Erklärungsbedarf.
Das 1PPS-Signal gibt die genauen Zeitpunkte für die Sekunden und in den
seriellen Daten steht die Uhrzeitangabe dazu.
Ehrlich gesagt, würde ich das Thema nur mit spitzen Fingern anfassen und
diese Zeit gründlichst auf Plausibilität prüfen. Eine falsche Zeit kann
viel Ärger zur Folge haben. Leider hatte ich dieses Theater bei DCF77
durch Störungen schon mal.
oszi40 schrieb:> Ehrlich gesagt, würde ich das Thema nur mit spitzen Fingern anfassen und> diese Zeit gründlichst auf Plausibilität prüfen.
Das ist ziemlich einfach: Du trägst im chrony/ntpd zusätzlich zum
gps/pps noch ein paar bekannt gute NTP-Dienste ein. Dann bekommst Du die
Offsets zu denen direkt angezeigt. Das dann einfach 2 Wochen lang
kontinuierlich laufen lassen, alle paar Minuten die Werte loggen und die
Werte über die Zeit vergleichen.
Hallo zusammen
Gerd E. schrieb:> @TO schau Dir mal die SHM-IDs an. Damit gab es bei mir ein Problem. Da> waren die falschen IDs hinterlegt oder so. Als ich die angepasst hatte> ging es dann. Hab die genauen Details aber nicht mehr im Kopf.
guter Tip, danke. Ich habe mir die angeschaut. Die IDs sind korrekt.
ABER ich habe gesehen, dass SHM(0) und SHM(0) als owner "root" haben,
und die Permissions sind "600". Dummerweise läuft chronyd unter dem User
"chrony". Ich glaube, dass dies das Problem sein könnte, denn so kann
chrony auf den shared memory nicht zugreifen. Macht das Sinn?
wie repariert man das? das scheint mir eine systemd Problem zu sein.
Gerd E. schrieb:> Das ist ziemlich einfach: Du trägst im chrony/ntpd zusätzlich zum> gps/pps noch ein paar bekannt gute NTP-Dienste ein. Dann bekommst Du die> Offsets zu denen direkt angezeigt. Das dann einfach 2 Wochen lang> kontinuierlich laufen lassen, alle paar Minuten die Werte loggen und die> Werte über die Zeit vergleichen.
genau so würde ich das auch machen.
Tobias P. schrieb:> Das soll ein Stratum 1 Zeitserver werden.
Das sind mir immer die liebsten. Da lässt du deinen ntpd einen Satz
Server aus dem Pool nehmen, alle sind so Stratum 2 oder 3 und sich super
einig, was denn die aktuelle Zeit ist, nur einer nicht. Und das ist dann
ein Stratum 1 - Selbstbastelserver mit REFID ".GPS."
Falls du vorhast deinen Server irgendwie in einen Pool einzubringen:
Bitte Belüg dich selber und andere nicht über die Genauigkeit deines
PPS-Signals.
Ja, die NTP-Doku von vor 30 Jahren sagt, dass ein NTP-Server am
GPS-Receiver Stratum 1 sein sollte. Diese Einstufung ist m.M.n obsolet,
spätestens seitdem die PTB ihre ptbtime-server betreibt.
Hi Ernst,
das ist deine Meinung. Andere sehen das anders. Das 1PPS Signal ist sehr
akkurat. Lese dich mal ein wie GPS funktioniert.
Mit ntpd habe ich es zum Laufen bekommen, die Abweichung von meinem
.GPS. zum pool.ntp.org war im Mikrosekundenbereich.
Ich möchte aber chrony benutzen wenns geht.
@ Tobias P.
> Mit ntpd habe ich es zum Laufen bekommen, die Abweichung von meinem> .GPS. zum pool.ntp.org war im Mikrosekundenbereich.
Bei meinen letzten Test zu einem Meinberg GPS Dingens war das schon im
Bereich von Millisekunden :-)
Gerd E. schrieb:> Warum macht das Sinn?> Die dürfen selbstverständlich vom selben GPS kommen. Nur natürlich über> verschiedene Kabelwege.
Na ja, weil ich wohl davon ausgegangen bin, dass man so eine ungenauere
Uhr mit einem präziseren 1PPS Signal diszipliniert. Wie gesagt, ist
schon was her.
Tobias P. schrieb:> ABER ich habe gesehen, dass SHM(0) und SHM(0) als owner "root" haben,> und die Permissions sind "600". Dummerweise läuft chronyd unter dem User> "chrony". Ich glaube, dass dies das Problem sein könnte, denn so kann> chrony auf den shared memory nicht zugreifen. Macht das Sinn?> wie repariert man das? das scheint mir eine systemd Problem zu sein.
Ja, das ist auf jeden Fall ein Grund warum es nicht gehen kann. Ich
vermute der chronyd muss als root starten, sich die Zugriffsrechte
sichern und kann dann auf den chrony-Benutzer zurückschalten.
Ruf mal ntpshmmon auf. Was siehst Du da für Einträge?
Hast Du das howto durchgearbeitet:
https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html
Da sind einige Punkte beschrieben
Εrnst B. schrieb:> Ja, die NTP-Doku von vor 30 Jahren sagt, dass ein NTP-Server am> GPS-Receiver Stratum 1 sein sollte. Diese Einstufung ist m.M.n obsolet,
das ist doch ein Mißverständnis? Sollte es nicht umgekehrt heißen: ein
NTP-Server hat überhaupt nur eine Chance auf Stratum 1, wenn er an einem
GPS-Receiver mit PPS hängt. Und dann fehlt ihm wahrscheinlich noch ein
passender Oszillator für die Rechneruhr. Und die auf dem Flachdach
angeschraubte Antenne.
Tobias P. schrieb:> Mit ntpd habe ich es zum Laufen bekommen, die Abweichung von meinem> .GPS. zum pool.ntp.org war im Mikrosekundenbereich.> Ich möchte aber chrony benutzen wenns geht.
das ist mal ein spannender Vergleich. Oder warum macht man sowas?
Bauform B. schrieb:> das ist doch ein Mißverständnis? Sollte es nicht umgekehrt heißen: ein> NTP-Server hat überhaupt nur eine Chance auf Stratum 1, wenn er an einem> GPS-Receiver mit PPS hängt. Und dann fehlt ihm wahrscheinlich noch ein> passender Oszillator für die Rechneruhr. Und die auf dem Flachdach> angeschraubte Antenne.
NTP steuert die Rechneruhr und zieht die dem PPS nach. Dadurch wird die
Zeit schon recht genau, aber man kann das im Endeffekt sowieso nicht so
genau nutzen weil bei der Zeitabfrage übers Netzwerk dann wieder eine
zusätzliche Ungenauigkeit dazu kommt.
Bei dem vorliegenden GPSDO ist es aber sowieso so, dass der 1PPS, der an
den PC geleitet wird, NICHT aus dem GPS kommt, sondern von einem OCXO
abgeleitet ist. Eine PLL regelt den OCXO so nach, dass der lokal
generierte 1PPS mit demjenigen von GPS übereinstimmt (plus minus Jitter
natürlich). Damit hat der lokale 1PPS praktisch keinen Jitter und ist
nahezu perfekt an der GPS Zeit ausgerichtet.
Die Antenne ist im Normalfall auf dem Dach, aber zu Debugzwecken musste
ich im Moment die Hardware in der Nähe haben, weshalb ich in der Tat
keinen guten Antennenstandort habe (Fensterbrett). Trotzdem scheint eine
erstaunlich gute Genauigkeit möglich zu sein. Der PPS vom GPS-Modul
baumelt um circa 40ns in beide Richtungen um "meinen" 1PPS herum. DAC
Spannung ist über Stunden nahezu konstant, d.h. wackelt nur um ein paar
counts.
Bauform B. schrieb:> Oder warum macht man sowas?
warum nicht? Andere spielen Fussball. Oder bauen Modelleisenbahnen.
Beides genauso nutzlos, aber für denjenigen der es macht, in dem Moment
offenbar spannend. ;-)
Tobias P. schrieb:> baumelt um circa 40ns in beide Richtungen
Dann teste GPS jetzt mal in Finnland!
"Behörde warnt vor Störungen
In einer Anordnung an Cockpitpersonal (Englisch: Notam) warnte deshalb
die finnische Verkehrsbehörde Traficom vor Störungen des GPS-Signals in
der Region der Städte Mikkeli, Jyväskylä und Kuopio. «Ich kann mich
nicht erinnern, dass es in letzter Zeit solche Vorfälle gegeben hat»,
sagte Jari Pöntinen, Direktor für Luftfahrt bei Traficom, der Zeitung
Helsingin Sanomat. Die Warnung gilt für Flughöhen bis zu 20.000 Fuß,
also bis 6100 Meter." Quelle
https://www.aerotelegraph.com/an-russlands-grenze-fiel-im-cockpit-ploetzlich-das-gps-signal-aus
Deswegen würde ich niiie ungeprüfte Zeitdaten in mein System lassen. Aus
Ärger mit kaputtem Impulsdiagramm (war DCF77) habe ich schon gelernt.
Was ist eigentlich mit den anderen GPS-Systemen? Hat die zufällig jetzt
einer geprüft/verglichen ob sie funktionieren? NAVSTAR GPS, GLONASS,
Galileo, Beidou?
oszi40 schrieb:> Tobias P. schrieb:>> baumelt um circa 40ns in beide Richtungen>> Dann teste GPS jetzt mal in Finnland!> "Behörde warnt vor Störungen> In einer Anordnung an Cockpitpersonal (Englisch: Notam) warnte deshalb> die finnische Verkehrsbehörde Traficom vor Störungen des GPS-Signals in> der Region der Städte Mikkeli, Jyväskylä und Kuopio. «Ich kann mich> nicht erinnern, dass es in letzter Zeit solche Vorfälle gegeben hat»,> sagte Jari Pöntinen, Direktor für Luftfahrt bei Traficom, der Zeitung> Helsingin Sanomat. Die Warnung gilt für Flughöhen bis zu 20.000 Fuß,> also bis 6100 Meter." Quelle> https://www.aerotelegraph.com/an-russlands-grenze-fiel-im-cockpit-ploetzlich-das-gps-signal-aus> Deswegen würde ich niiie ungeprüfte Zeitdaten in mein System lassen. Aus> Ärger mit kaputtem Impulsdiagramm (war DCF77) habe ich schon gelernt.>> Was ist eigentlich mit den anderen GPS-Systemen? Hat die zufällig jetzt> einer geprüft/verglichen ob sie funktionieren? NAVSTAR GPS, GLONASS,> Galileo, Beidou?
und was machen jetzt die Kalibrierlabore in Finnland?
GLONASS und GALILEO kann man beide auch verwenden.
Mein GPSDO benutzt alle 3. Nach länglichen Tests habe ich so
herausgefunden, dass das die stabilsten Sekundenpulse gibt. Im Moment
trackt er 35 Sats.
Tobias P. schrieb:> Die Antenne ist im Normalfall auf dem Dach, aber zu Debugzwecken musste> ich im Moment die Hardware in der Nähe haben, weshalb ich in der Tat> keinen guten Antennenstandort habe (Fensterbrett).
Es gibt doch irgend ein Bit, was meldet, ob die Zeit "gut" ist. Das sehe
ich mit meiner älteren GPS-Maus (Sony Chipsatz) nur, wenn der Empfänger
draußen freie Sicht hat. Auf der Fensterbank innen ist auch die Position
alles andere als toll.
Privat bin ich zu keiner Anwendug gekommen, habe das nur ein paar Wochen
bespielt, nachdem ich beruflich damit zu tun bekam.
Sehr nett: https://in-the-sky.org/satmap_radar.php
Da kann man recht gut gucken, wieviele SAT vom Fenster aus überhaupt
sichtbar sein können.
oszi40 schrieb:> Deswegen würde ich niiie ungeprüfte Zeitdaten in mein System lassen. Aus> Ärger mit kaputtem Impulsdiagramm (war DCF77) habe ich schon gelernt.
Wenn man DCF selbst decodiert, wirkt eine mathematische
Plausibilitätsprüfung Wunder, drei Minuten auf n+1 gucken. Im Windows
Zeitdienst gibt es Parameter (per Registry-Klempnerei), wie weit
Korrekturen von der Istzeit abweichen dürfen, um glaubhaft zu
erscheinen. Beides gemeinsam sollte grobe Fehler ziemlich sicher
ausschließen.
-------
Spaß am Rande: Ein Kunde rief mich wegen Problemen an, wo mir meine
Erfahrung sagte, dass seine GPS-Referenz ausgefallen sein müsste. Er
musste dann zum Technikraum und mir ein paar LEDs vorlesen, Treffer. Zum
Glück war der pfiffig "Wir haben Dachdecker auf dem Haus, ich gehe mal
gucken". Eine Weile später rief er wieder an, alles gut - die Dachdecker
haben ein ordentliche Abdeckung für die Antenne gebaut, um die Technik
zu schützen" :-)
Manfred schrieb:> Wenn man DCF selbst decodiert, wirkt eine mathematische> Plausibilitätsprüfung Wunder, drei Minuten auf n+1 gucken.
Der Tipp ist gut. Trotzdem würde ich noch prüfen ob die Stunden <24
sind, da mein gestörtes Impulstelegramm völlig sinnlose Werte wie
§§:AA:72 lieferte.
oszi40 schrieb:> Manfred schrieb:>> Wenn man DCF selbst decodiert, wirkt eine mathematische>> Plausibilitätsprüfung Wunder, drei Minuten auf n+1 gucken.> Der Tipp ist gut.
Aber nicht wirklich neu?
> Trotzdem würde ich noch prüfen ob die Stunden <24 sind,
... und die anderen jeweils 0..59!
> da mein gestörtes Impulstelegramm völlig sinnlose Werte wie> §§:AA:72 lieferte.
Solch groben Unfug habe ich gesehen, als ich versucht habe, mit dem
UKW-Empfänger RDA5807M eine Uhrzeit per RDS zu ermitteln.
Wertest Du vom DCF die drei Parity-Bits aus? Die taugen wenig, weil sie
Doppelfehler (zwei Bit gekippt) nicht zeigen, aber es kostet nichts, die
trotzdem mitzunehmen, wenn ein µC decodiert.
Wie sieht die Zielumgebung aus? Ich habe es erlebt, dass ein
Windows-Server seine Uhr nicht gestellt hat, weil es ein Sprung über
mehrere Tage gewesen wäre. Heißt also, dem System beizubringen, dass
Zeitkorrekturen größer xx unzulässig sind.
Als Plausibilitätsprüfung würde ich vor allem auf einen dauerhaften
Vergleich des eigenen GPS- oder DCF77-Empfängers mit externen
NTP-Servern setzen und hier nur einen maximalen Offset erlauben.
NTP gibt es seit einiger Zeit auch kryptografisch abgesichert als NTS.
Die Möglichkeiten eines Angreifers das zu verfälschen sind da sehr stark
eingeschränkt. Das, kombiniert mit dem lokalen GPS oder DCF77, macht
selbst einen gezielten Angriff mit größerem Ressourcenaufwand extrem
schwer durchzuführen.
Gerd E. schrieb:> Als Plausibilitätsprüfung würde ich vor allem auf einen dauerhaften> Vergleich des eigenen GPS- oder DCF77-Empfängers mit externen> NTP-Servern setzen und hier nur einen maximalen Offset erlauben.
Falscher Ansatz. Wenn ich NTP habe, muß ich nicht mit DCF oder GPS
basteln. Ziel muß sein, unabhängig von NTP eine korrekte Zeit zu
bekommen.
Beim DCF77 kommt noch die Laufzeit hinzu, am PTB-Standort Braunschweig
kommt das Signal ziemlich genau eine Millisekunde verspätet an.
Wenn man sich mal bei http://www.satsignal.net/ umsieht: Dave hat
protokolliert, dass die Uhren schon auf Leerlauf oder Last eines Servers
mit ein paar ms Versatz reagieren. Egal, was man treibt, besser 10ms
wird man kaum realisiert bekommen.
Sein NTP Monitor hat schon lange keine Updates mehr benötigt, aber ist
noch immer erste Wahl, die Uhren in einem Netzwerk zu überwachen.
http://www.satsignal.eu/software/net.htm
Manfred schrieb:> Gerd E. schrieb:>> Als Plausibilitätsprüfung würde ich vor allem auf einen dauerhaften>> Vergleich des eigenen GPS- oder DCF77-Empfängers mit externen>> NTP-Servern setzen und hier nur einen maximalen Offset erlauben.>> Falscher Ansatz. Wenn ich NTP habe, muß ich nicht mit DCF oder GPS> basteln. Ziel muß sein, unabhängig von NTP eine korrekte Zeit zu> bekommen.
So pauschal würde ich das nicht sehen, es kommt aufs Ziel an:
Wenn nicht Internetunabhängigkeit das Ziel ist, sondern Genauigkeit und
Jitterarmut, dann ist ein lokaler GPS-disziplinierter OCXO deutlich
besser als NTP.
Nur hat man dann da eben das Problem von lokalen Störungen oder
Fehlkonfigurationen und die kann man eben u.a. über das oben genannte
Verfahren zur Plausibilitätsprüfung erkennen.
Gerd E. schrieb:> Nur hat man dann da eben das Problem von lokalen Störungen oder> Fehlkonfigurationen und die kann man eben u.a. über das oben genannte> Verfahren zur Plausibilitätsprüfung erkennen.
Bei Fehlkonfigurationen durch falsche Zeitzone usw. sollte evtl. ein
Admin schuldig sein. Bei Umstellung von Sommer- auf Winterzeit usw. wird
die Sache interessanter. Es werden ja gelegentlich auch
Korrektursekunden eingefügt. Das alles sollte bei einer automatischen
Plausibilitätsprüfung bedacht werden.
oszi40 schrieb:> Bei Fehlkonfigurationen durch falsche Zeitzone usw. sollte evtl. ein> Admin schuldig sein.
Nicht einmal der, das kann der Benutzer ja selber (verkehrt) machen.
> Bei Umstellung von Sommer- auf Winterzeit usw. wird> die Sache interessanter.
Warum? Das ist doch bei der Zeitzone gratis mit dabei.
> Es werden ja gelegentlich auch Korrektursekunden eingefügt.
Das ist dann schon interessanter. Einmal, weil es nicht immer klar ist,
ob die Schaltsekunden in den NMEA-Sätzen drin sind oder nicht. Zweitens,
weil man bei der lokalen Uhr ja auch die Wahl hat, ob die Schaltsekunden
berücksichtigt werden oder nicht (zoneinfo/posix vs. zoneinfo/right).
Für die Plausibilität sollte man GPS-Zeit mit lokaler Uhr ohne
Schaltsekunden vergleichen. Da stecken die wenigsten Fehlerquellen drin.
Und die Uhr muss nach der ersten Inbetriebnahme nie wieder gestellt
werden. Genau genommen darf sie nie wieder gestellt werden. Nur dann
hat man eine Referenz, auf die man sich verlassen kann.
Man kann noch eine Prüfung machen: der GPS-Empfänger ist ja irgendwo
angeschraubt. Also sollte er gefälligst immer die gleichen Koordinaten
liefern. Bei mehr als 10m Abweichung sollte man auch der Zeit nicht
trauen. Wenn uns dann jemand reinlegen will, muss sein Störsender auch
die passende Position zur gefälschten Zeit liefern. Bei wem würde sich
ein so gezielter Angriff lohnen? Bei der Deutschen Bahn schon lange
nicht mehr ;)
Bauform B. schrieb:> Bei mehr als 10m Abweichung sollte man auch der Zeit nicht> trauen. Wenn uns dann jemand reinlegen will, muss sein Störsender auch> die passende Position zur gefälschten Zeit liefern.
So einfach ist Plausibilitätsprüfung auch nicht, da z.B. im Balkankrieg
schon mal die GPS-Genauigkeit stark reduziert wurde. Statt Autobahn
wurde ein Acker auf dem Navi angezeigt. Damit wäre Deine Zeit dann
abgeschaltet?
oszi40 schrieb:> Bei Umstellung von Sommer- auf Winterzeit usw. wird> die Sache interessanter. Es werden ja gelegentlich auch> Korrektursekunden eingefügt. Das alles sollte bei einer automatischen> Plausibilitätsprüfung bedacht werden.
Die Umstellung Sommer- <-> Winterzeit wird vom DCF angekündigt, es gibt
ein Bit dafür. Meine Uhr (nur Zeitanzeige ohne PC-Anbindung) zeigt es an
und wechselt ohne Fehler.
Die Implementierung der Schaltsekunde habe ich damals verpennt, da
bekomme ich zwei oder drei Minuten lang eine Fehleranzeige.
Würde man das in eine Zeitserverfunktion implementieren, könnte dieser
im Fehlerfall "Stratum 9" melden und die angeschlossenen PCs würden eine
Zeitübernahme verweigern - wenn sie denn zufällig in diesem Zeitfenster
stattfände.
Bauform B. schrieb:> Für die Plausibilität sollte man GPS-Zeit mit lokaler Uhr ohne> Schaltsekunden vergleichen.
Beim GPS bin ich unsicher, ich meine, der sendet die unkorrigierte Zeit
und zusätzlich die Anzahl der Schaltsekunden. Habe ich nicht selbst
gesehen, die Decoder-Chipsätze für NMEA behandeln das scheinbar intern
und liefern die korrigierte GMT aus.
Unabhängig davon: Wie genau kann sowas überhaupt werden? Die Daten des
Empfängers kommen seriell zum PC, vielleicht noch mit einem USB-Wandler
dazwischen, das hat undefinierbare Laufzeiten.
oszi40 schrieb:> So einfach ist Plausibilitätsprüfung auch nicht, da z.B. im Balkankrieg> schon mal die GPS-Genauigkeit stark reduziert wurde.> Damit wäre Deine Zeit dann abgeschaltet?
Jein, ich würde die GPS-Zeit ignorieren. Meine Zeit kommt immer von
meiner Uhr. Die Uhr wird nur per GPS-Zeit sehr behutsam korrigiert --
oder eben nicht (hoffentlich nur zeitweise).
Manfred schrieb:> Die Implementierung der Schaltsekunde habe ich damals verpennt, da> bekomme ich zwei oder drei Minuten lang eine Fehleranzeige.>> Würde man das in eine Zeitserverfunktion implementieren, könnte dieser> im Fehlerfall "Stratum 9" melden und die angeschlossenen PCs würden eine> Zeitübernahme verweigern - wenn sie denn zufällig in diesem Zeitfenster> stattfände.
Aber das passiert doch erst, wenn DCF für viele Stunden, wenn nicht
Tage, komplett ausfällt. Solange liefert ein Zeitserver immer eine
gültige Zeit. Bei einer Schaltsekunde weicht die zunächst um 1 Sekunde
von UTC ab. Der Fehler wird dann allmählich kleiner. Das ist im
wirklichen Leben angenehmer als Zeitsprünge, auch wenn's "nur" eine
Sekunde ist. Google verwendet eine Zeit, bei der der Ausgleich viele
Stunden dauert. Linux ist mit nur 2000 Sekunden ein wenig hektisch.
Wer mit dem Fehler nicht leben mag, ignoriert die Schaltsekunden und
rechnet sie erst ganz zum Schluss dazu. Für die lokale Uhr ist das
eigentlich das einzig Wahre und viel einfacher zu implementieren.
> Beim GPS bin ich unsicher, ich meine, der sendet die unkorrigierte Zeit> und zusätzlich die Anzahl der Schaltsekunden.
Ja, so ist das.
> die Decoder-Chipsätze für NMEA behandeln das scheinbar intern> und liefern die korrigierte GMT aus.
Das sollten sie, so sind die Daten definiert. Direkt nach einem
Kaltstart kennt der Empfänger die Differenz aber nicht. Die wird nur
alle 12 Minuten gesendet und wenn der Empfang schlecht ist... Was ist
jetzt besser: garkeine NMEA-Daten oder welche mit ein paar Sekunden
Fehler? Ich vermute, es gibt solche und solche Empfänger.
> Unabhängig davon: Wie genau kann sowas überhaupt werden? Die Daten des> Empfängers kommen seriell zum PC, vielleicht noch mit einem USB-Wandler> dazwischen, das hat undefinierbare Laufzeiten.
Mit einem PPS stört das alles überhaupt nicht. Was damit (und einem
guten Oszillator) möglich ist, kann man weiter oben in diesem Thread
lesen.
Ohne PPS kann man eine konstante Laufzeit messen und raus rechnen. Einen
Teil der Schwankungen auch, nämlich die Rechenzeit, die der Empfänger
pro Satellit braucht. Dann bleiben aber immer noch eher 20 als 10ms
Fehler. Aber dann kann man noch mitteln, stunden- und tagelang. Müsste
ich direkt mal Fehlerkurven malen...
> Stratum 1
Soweit ich das Konzept verstanden habe ist nur eine Cäsium Uhr Stratum
1, und alles Abgeleitete, allenfalls Stratum 2. Es geht dabei eben auch
um den Holdover. Wenn die Referenz weggeht, wieviel laeft dein Stratum
in welcher Zeit weg.
Thread beobachten
Seitenaufteilung abschalten