In einem LAN sollten alle
Maschinen die selbe Zeit haben – egal ob Server, PC oder kleiner Controller,
wie z.B. ein Pi für Echtzeitsteuerung, wie in
“Raspberry for remote services”
(siehe auch
Publikationen)
beschrieben.
Der Hintergrund: Sie wollen
- vergleichbare Zeiten von Dateien and
- Log-Dateieinträgen, die über mehrere Systeme hinweg eine korrekt sortierbare Reihenfolge ergeben. Sie haben
- verteilte Steuerungen mit zeitlich koordinierten Aktionen.
Diese zeitabhängigen Aktionen und Eigenschaften versagen, wenn die interne Zeit dieser Systeme zu weit voneinander abweichen. Folglich haben wir eine (harte oder weiche) diesbezügliche Echtzeitanforderung. Und “Echtzeit” sagt auch hier nichts über absolute Zahlen. Die noch tolerierbare Abweichung zwischen zwei dieser Systeme kann zwischen 50ns and 20s liegen – je nachdem. Falls aber ein System nach dem Neustart/Einschalten weder Datum noch Stunde kennt ist jede Hoffnung vergebens.
NTP-Server
Der bewährte Weg zu gleicher Zeit ist, alle diese System den gleichen
NTP-Server oder den gleichen sortierten
Satz von Servern nutzen zu lassen. Zumindest einer muss für alle diese
Rechner via (W)LAN
erreichbar sein.
Ein guter Ansatz sind ein oder zwei eigene NTP-Servers in diesem internen
(W)LAN, welche ihrerseits eine oder mehrere externe Zeitquellen nutzen.
Gründe für einen gemeinsamen internen NTP-server sind die intern stabilere
Übertragungszeit und Erreichbarkeit für alle. Nicht alle
internen Computer und Steuerungen dürfen ja ins Internet.
Die interne Rolle “NTP-Server” bekommen oft die Domain Controller (DC), mit üblicherweise internen IP-Adressen von p.r.v.1 bis p.v.r.4. In Privathäusern und kleinen Firmen werden die DC-Rollen DNS (und DHCP) oft vom Router des Internet-Providers oder dem privaten Router übernommen. In Deutschland wird dies oft eine fritz.box sein, mit standardmäßig IP 192.168.178.1. Der folgende Auszug aus /etc/ntp.conf setzt fritz.box als alleinigen Zeitserver ein:
# I need to talk to one NTP server or two (or three).
server 192.168.178.1
# pool.ntp.org maps to ~1000 low-stratum NTP servers.
#pool 0.debian.pool.ntp.org iburst
Beachten Sie, dass alle pool-Einträge auskommentiert wurden, damit der
client nicht von der fritz.box weggelockt wird. Sie könnten sonst die
anderen Angebote vorziehen. Eine fritz.box, die dutzente Telefone 100 aktive
(W)LAN clients, USB-Laufwerke und manches mehr zu handhaben versucht, ist da
wohl unattraktiver als ein ausgewachsener NTP-Server im Internet. Wenn
Sie extra Quellen oder pools wollen nutzen Sie indirekt die Zeitquelle der
fritz.box: ntp1.t-online.de; 2.europe.pool.ntp.org
.
Die Verfügbarkeit und Nutzung der eines NTP-Servers testet man z.B. mit:
ntpstat # Linux
w32tm /stripchart /computer:192.168.178.1 /dataonly /samples:5 & REM Windows
NTP mit fritz.box und Raspberry Pi
Mit einer FRITZ!Box 7490 mit FRITZ!OS 7.21 hatten wir einen Ausfall ihres NTP-Servers für alle clients (diagnostiziert mit by w32tm, ntpstat etc.), wobei die NTP-Serverkonfiguration intakt und die gesamte (W)LAN-Kommunikation OK waren. Schließlich half es (in Netzwerk -> Netzwerkeinstellungen) den Haken für die NTP-Serverrolle zu entfernen, OK zu drücken und nach einem Schluck Kaffee wieder zu setzen. Das Rücksetzen der FRITZ!Box mit Netz Aus hätte wohl das selbe bewirkt war aber mitten an einem Arbeitstag unzumutbar.
Wenn man NTP-Problemen nachgehen muss, ist der Mix von Linux- und Windows-Systemen im Netz schon Mühsal genug. Dann aber gerade auf den neuesten Raspians (nun teilweise Raspberry Pi OS genannt) auf einmal die Standard-NTP-Linux-Werkzeuge und -Vorgehensweisen nicht mehr zu haben, ist schon eine überraschende Dreistigkeit.
Natürlich wollten wir die Standardwerkzeuge mit ihrem Schatz an Dokumentation und Erfahrung zurück:
sudo service systemd-timesyncd stop
sudo systemctl disable systemd-timesyncd --now
sudo apt-get install ntp ntp-doc
sudo nano /etc/ntp.conf # see changes above
sudo apt-get install ntpstat
sudo apt-get install openntpd
sudo apt-get install ntpctl # may not work ntpstat suffices
sudo timedatectl set-ntp True
sudo systemctl restart ntp # it might take 3 min until sync
sudo ntpdate -u fritz.box # force setting time on a very async client
Das stellt die Einheitlichkeit der unserer Linuxe bezüglich NTP wieder her.
NTP-Ausfall
Wenn NTP in einem lokal Bereich ausfällt, beginnt das weg driften der clients
von der offiziellen Zeit und voneinander. Ein client mit einem Neustart in
dieser Situation hat dann evtl. sogar eine total blödsinnige Zeit. Nun,
einige Linuxe und Rasbians garantieren mit einer
Datei /etc/fake-hwclock.data
wenigstens eine monotone Zeit
über Runterfahren und Wiederanlauf hinweg aber natürlich keine Korrektheit.
Um in der Gegenwart von NTP-Ausfällen Korrektheit zu erreichen oder aufrecht zu erhalten braucht man eine redundante Zeitquelle.
Echtzeituhren
Hierfür werden oft sogenannte “Echtzeituhren” eingesetzt. Es sind batteriebetriebene Quarzuhren ohne Zeiger oder Anzeige aber mit einer Schnittstelle zum Prozessor zum Auslesen und Stellen. Sobald das NTP-basierte Stellen ausfällt, driften sie wie jede andere unsynchronisierte Uhr, und wenn ihre Batterie schwach wird, driften sie schneller oder fallen gar aus.
Wenn Ihre Hardware vom Grund-Design her so eine “Echtzeituhr” hat, und diese vom Betriebssystem ohne zusätzliche Konfiguration korrekt gehandhabt wird, so mag man dergleichen nutzen. Bei Standard-PCs ist das meist so.
Aber zögern Sie, so was nur bedingt nützliches einem Embedded-Controller
hinzuzufügen. Es kann von vornherein oder nach updates schwierig zum Laufen
zu bringen sein. Und ein Batteriewechsel wird an manchem
Einbauort eines Controllers zum Albtraum.
Eine gute Alternative kann das Nutzen des DCF77-Signals mit einem
preiswerten DCF77-Empfänger sein.
DCF77-Signal
Die offizielle, gesetzliche deutsche Zeit wird von der PTB mit weltweit synchronisierten Atomuhren dargestellt und über den Langwellensender DCF77 in der Nähe von Aschaffenburg/Main verbreitet. Er kann in weiten Teilen Europas empfangen werden. Sein 77,5kHz-Träger ist sowohl amplituden- (AM) als auch phasenmoduliert (PM).
Am Beginn der meisten Sekunden wird die Amplitude für 100 ms (false) oder für 200 ms (true) auf 15% reduziert. Von etwa 3ms vor Sekundenbeginn bis genau 200 ms danach ist die Phase 0°. Sonst wird sie so ±13° moduliert, dass die Verschiebung insgesamt Null ist.
Die PM ist wesentlich weniger anfällig gegenüber
EMI und der
Sekundentick kann exakter erfasst werden (etwa 2µs verglichen
mit 200µs bei AM). Eine Störquelle bei PM ist die ungewollte zusätzliche
Modulation durch eine im Sturm bewegte (große) Sendeantenne. (Solche
und andere Störungen werden vermutlich über das “Rufbit” 15 gemeldet.)
Die Technik eines PM-Empfängers und die Dekodierung ist komplizierter
und deutlich teurer. Wir werden uns, wie viele, trotz aller PM-Vorzüge auf
mit AM-Empfängern zufriedengeben.
Das AM-Signal liefert einen Start-Tick für alle Sekunden außer der letzten einer Minute (59, 60, 61). Diese Pulse ergeben einen langsamen (1 bit /s) Datenstrom. Die Kodierung der 59 Telegramm-Bits liefert alle Zeit- und Datumsinformation einschließlich MEZ (CET) / MESZ (CEST). Also bekommen wir auch die Weltzeit UTC.
Mithin bekommt unser Controller/Computer mit einem DCF77-Empfänger eine Minute nach dem Beginn des Empfangs Standardzeit.
Jeder NTP-Server in Europe mit etwas Verstand wird letztlich die Atomuhren der PTB (und somit DCF77) nutzen. Ein System das seine Zeit mit DCF77 synchronisiert, ist somit NTP-konform. Ein Umschalten auf NTP wird so keine Sprünge oder lange Anpassungszeiten verursachen.
Schaltsekunden
Die gute Übereinstimmung zwischen DCF77 und NTP fehlt in der letzten Stunde vor einer Schaltsekunde, falls der betreffende Server wie viele das sogenannte “leap second smearing” machen (eine Idee 2011 von Google). Diese NTP-Server liefern dann 1000 s lang die falsche Zeit. Da DCF77 in der letzten Stunde davor Schaltsekunden ankündigt, ist man informiert, ohne das IERS bulletin C lesen zu müssen.
Der Zweck von Schaltsekunden ist es, die hochgenaue Standard-Atomzeit mit der unpräzisen Erdrotation in Übereinstimmung zu bringen. In den 1950ern dekretierte die Norm UTC, dass das Büro der Erdrotation zweimal im Jahr Minuten mit 58, 59, 61 oder 62 seconds international verbindlich anordnen kann.
Dieser vom Mittagsbesteck
nehmen inspirierte Unsinn – Entschuldigung, meine unmaßgebliche Meinung*)
– wurde vom Posix/Unix-Zeitstandard gekrönt, der die Extra-Sekunden
nicht darstellen kann**).
Er zählt die Sekunden ab einem Startdatum (epoch) und legt 84600 s/Tag
für diese Zählung (stamp) fest bzw. 31536000 s für’s Standardjahr. Das System
UTC+Posix verletzt das Prinzip
“ausgeschlossenen Widerspruch”.
Der Auszug aus dem
IERS Bulletin C 52
mit ergänzten NTP Zeitstempeln zeigt das Problem:
3692217599 2016 December 31, 23h 59m 59s
3692217??? 2016 December 31, 23h 59m 60s
3692217600 2017 January 1, 0h 0m 0s
Nu liefer DCF77 nicht UTC sondern
TAI
als MEZ(CET)/MESZ(CEST) mit einen eineindeutigen Funktion
(bzw. umkehrbaren Abbildung). Somit ist DCF77 natürlich korrekt und
widerspruchsfrei im Gegensatz zum UTC-basierten NTP.
______
Anm. *): Möge der Brexit die Macht der Britischen Admiralität soweit
mindern, dass der Rest der Welt die Schaltsekunden loswerden
kann.
Anm **): Die Schöpfer von UTC vergaßen die Normung einer (Sekunden-)
Zählerdastellung in den 1950ern, und die Posix-Leute machten dies dann
in den 1970ern – wenn nun auch falsch.
DCF77-Empfänger
Wir betrachten nur AM-Empfängermodule. Man bekommt Platine + Ferritantenne für unter 10€ und bessere ab 14€. Mit den Kosten für ein kleines Gehäuse aus Kunststoff (!) 5 m Kabel – für eine freie gute Platzierung der Antenne – bekommt man einen direkt an beispielsweise einen Raspberry Pi anschließbaren Empfänger für unter 30€.
Eigenschaften:
o braucht (nur) einen beliebigen digitalen Eingang des
Controllers
- üblicherweise keine DCF77-Unterstützung des OS
- eigene DCF77-Software / -Anwendung benötigt (durchaus machbar)
+ es braucht keine Batterie
+ das Modul kann mit dem Controller zusammengebaut *) und
+ von ihm (einem Raspberry Pi z.B.) versorgt werden
+ das Modul kann ebenso mehrere Meter vom Controller entfernt
platziert werden
+ das Signal eines Empfängers kann auch an mehrere **)
Controller verteilt werden.
AM-Empfängermodule unter 10€ gibt es bei Pollin und einigen anderen. Sie wurden mit Erfolg eingesetzt. Man teste sie vorher mit einem Oszilloskop oder einem Program wie dcf77onPi (vorher testOnPi). Der log-Auszug
test µs stamp pulse µs sec res period µs stamp - corr decode
DCF77 2.630.290.551 110060 7: F.M 2020225 15:43:06.133 -.188 |o|
DCF77 2.631.001.112 187210 0: T#b 710561 15:43:08.231 -. 13 minErr
DCF77 2.631.281.253 12020 1: s#b 280141 15:43:08.766 -.188 | |
DCF77 2.631.891.315 187991 2: T#b 610062 15:43:09.222 -. 40 |-|
DCF77 2.632.275.296 39190 3: F#b 383981 15:43:09.683 -.177 |o|
DCF77 2.632.771.357 176720 4: T#b 496061 15:43:10.205 -. 35 |-|
DCF77 2.632.815.177 34270 5: F#b 43820 15:43:10.558 -. 7 |o|
DCF77 2.632.860.417 6660 6: s#b 45240 15:43:10.575 -. 29 | |
DCF77 2.632.996.258 28510 7: s#b 135841 15:43:10.642 -. 18 | |
DCF77 2.633.033.588 130580 8: u#e 2120225 15:43:10.767 -. 17 | |
zeigt fehlerhafte (erroneous e) und undefinierte (u) Resultate sowie
kurze / spitze (b s) Modulations-Pulse und Perioden. Dies passiert unter
sehr schlechten Empfangsbedingungen (falsch ausgerichtete Antenne oder
starke Störungen) oder mit schlechten Empfänger-Modulen.
Derartige Module bestehen aus einem AM-Empfangs-Chip (MAS6180 z.B.), einem
Filter-Quarz und sonst praktisch nichts. Der Ausgangs-Pin ist sehr
störempfindlich – quasi ein Eingang. Manche Module gehen beim Anschließen
eines abgeschirmten Kabels kaputt (was die Freude am Schnäppchen beendet).
Diese “MAS6180 plus Nichts”-Module brauchen immer eine zusätzliche
OC-Ausgangsstufe und Filter für die
Versorgungsspannung. Ohne diese Maßnahmen sieht man selten 2 Minuten
fehlerfreien Empfang.
______
Anm. *): Es ist klüger Empfangsmodul mit der Ferritantenne in ein extra
Gehäuse zu tun und diese mit einem dreipoligen (möglichst abgeschirmten)
Kabel zum Controller zu versehen.
Anm. **): In dem Fall wären mehrere NPN-OC-Ausgangsstufen vorzusehen wie auch
Maßnahmen bei der Versorgung des Empfängers.
Letztlich gibt man besser 12..16 € (oder mehr) für ein Modul aus, das von Haus aus all dies mitbringt, wie z.B das auf den Abbildungen gezeigte CANADUINO DCF77 receiver kit. Es kommt mit allem notwendigen Extras zum AM-Empfangs-Chip: Ausgangsstufen, Stromversorgung, und sogar LEDs zum optionalen Beobachten von Operation und Zustand. Trotz ja vorhandener push/pull-Ausgangsstufen empfehlen wir einen zusätzlichen OC-Ausgang, da dieser eine unabhängige Wahl und Schaltung der Versorgung von Empfänger und Controller erlaubt: NPN, hfe>200, Rbase 100kΩ; Rcoll 10..100kΩ, der pullup vom Pi reicht.
Der Log-Auszug für den Canaduino-Empfänger ist offensichtlich am 04.01.21 um 15:08 entstanden.
test µs stamp pulse µs sec res period µs stamp - corr decode
DCF77 0.522.295.426 183491 127: T.M 2001026 15:07:58.226 -. 83 mSrch
DCF77 0.523.295.068 82340 0: F.S 999642 15:08:00.126 -.182 minute
DCF77 0.524.293.681 182271 1: T.S 998613 15:08:01.225 -.185 |-|
DCF77 0.525.294.905 183870 2: T.S 1001224 15:08:02.226 -.183 |-|
:
DCF77 0.537.294.503 182981 14: T.S 998632 15:08:14.228 -. 84 |-|
DCF77 0.538.297.096 83881 15: F.S 1002593 15:08:15.126 -. 81 antOK
DCF77 0.539.296.099 80450 16: F.S 999003 15:08:16.126 -. 83 dlsKp
DCF77 0.540.295.321 83350 17: F.S 999222 15:08:17.127 -.181
DCF77 0.541.295.404 181171 18: T.S 1000083 15:08:18.224 -. 83 MEZ
DCF77 0.542.293.516 82270 19: F.S 998112 15:08:19.126 -.184 noLpS
DCF77 0.543.292.039 183611 20: T.S 998523 15:08:20.225 -.186 time:
:
DCF77 0.550.293.047 84330 27: F.S 999623 15:08:27.126 -. 87 hh:09
DCF77 0.551.294.209 85870 28: F.S 1001162 15:08:28.127 -.183 __:__
:
DCF77 0.557.292.804 84420 34: F.S 998672 15:08:34.127 -.185 15:mm
DCF77 0.558.291.607 184541 35: T.S 998803 15:08:35.226 -. 89 __:__
:
DCF77 0.564.292.682 84070 41: F.S 998203 15:08:41.126 -.187 04.mm.
DCF77 0.565.294.654 186470 42: T.S 1001972 15:08:42.228 -. 84
DCF77 0.566.293.897 83701 43: F.S 999243 15:08:43.127 -. 84
DCF77 0.567.289.019 84670 44: F.S 995122 15:08:44.126 -.189 Day:Mo
:
DCF77 0.572.290.832 88390 49: F.S 1000882 15:08:49.127 -.186 dd.01.
DCF77 0.573.291.855 185871 50: T.S 1001023 15:08:50.225 -. 86
:
DCF77 0.580.290.432 84920 57: F.S 997312 15:08:57.127 -.189 .2O21
DCF77 0.582.291.829 187961 58: T.M 2001397 15:08:58.227 -. 86 ______
DCF77 0.583.290.190 86009 0: F.S 998361 15:09:00.126 -. 90 minute
DCF77 0.584.292.262 89550 1: F.S 1002072 15:09:01.128 -.188 |o|
DCF77 0.585.293.105 188381 2: T.S 1000843 15:09:02.229 -.185 |-|
Der Auszug zeigt keine Fehler beim Canaduino-Modul und gutes timing. Logs über drei Tage zeigten drei Fehler pro Stunde. Dies ist ohne weiteres tolerierbar. 20 oder gar mehr als 100 – mit anderen Modulen durchaus beobachtet – gefährden die Verfügbarkeit der Zeitinformation. 100 oder mehr pro Stunde ist quasi ein Ausfall.
Gerechterweise sei gesagt: Man kann “MAS6180 plus Nichts”-Modulen
mit zusätzlicher Beschaltung, sorgfältigster Antennenausrichtung und
sehr weichen Zeitkriterien (so dass der Unterschied von true und false
verschwimmt) schon verwenden. Man könnte sogar versuchen Spikes innerhalb
einer Sekunde mit gemäßigt intelligenten Algorithmen auszufiltern.
Aber ist es das wert? Nimm einfach ein gutes Modul
und genieße die Ergebnisse.
Modulanschluss am µC
Wenn man mehrere Empfangs-Module *) und/oder Dekodierer (wie hier Pis)
hat, empfehle ich einen dreipoligen oder gar vierpoligen 3,5mm Klinkenstecker
– männlich und Kabel am Empfänger, weiblich beim Pi. Die einzig vernünftige
Belegung ist:
1 Ub +
2 DCF77-Signal **)
3 / - AM “receiver Off” Eingang ***)
4 / 3 Ground, -, Masse
Es gibt kommerziell komplette AM-Empfangsgeräte mit (natürlich *))
kompatiblen dreipoligen 3.5mm Klinkensteckern, unter Namen wie “Aktivantenne”
oder “Filterantenne”. Für immer noch vernünftige Preise sind Sie damit vom
Bohren und Löten erlöst. Andererseits sind diese in den meisten Fällen
kritischer Bedingungen (Störungen) den hausgemachten Canaduino-Geräten
unterlegen.
______
Anm. *): Beim Stecken und Ziehen werden bei dieser Belegung keine
Signal-Pins gefährdet.
Auch unter (gleicher Versorgungs-) Spannung ist das praktisch
sicher. Bei jeder anderen Permutation ist es das nicht.
Anm. **): Falls frei ordnen Sie den AM-Ausgang des Empfängers beim PI GPIO 15
(PIN10, UART in) zu.
Dies könnte die Verwendung von sog. “raw DCF77 input drivers” für
NTP Server erlauben.
Deren Programmierer legten sich auf einen UART [sic!] anstelle eines simplen
Binäreingangs für das binäre AM-Signal fest.
Anm. ***a): Dies ist i.A. der PDN (power down) Pin des
MAS6180C AM-Empfänger-IC. Plus oder offen bedeutet Aus/keine Operation.
Gewöhnlich schließt man diesen Eingang einfach an Masse an. Mit dem
vierpoligen Klinkenstecker in der dreipoligen Buchse passiert das
von selbst.
Anm. ***b): Wenn ein Pi-GPIO-Pin dieses Empfänger-Aus-An steuern soll,
empfiehlt sich an (auch) dieses Stelle eine open collector-Ausgangsstufe
mit einem kleinen Schutz-Rc von etwa 220 Ohm.
DCF77-Implementierung mit dem Pi
Soweit betrachteten wir den Vorzug von DCF77 gegenüber batteriebetriebenen sogenannten “Echtzeituhren” als redundante Zeitquelle für einen “Zoo” von Controllern – in unseren Projekten vielfach Pis.
Zu Algorithmen und Tricks für die DCF77-Dekodierung in C siehe den Beitrag Dekodieren der DCF77 AM-Signale mit einem Pi.
Kommentare
Möchten Sie einen Kommentar abgeben — auch gerne auf Englisch? Besuchen Sie die issue-Seite auf GitHub.Zum Kommentieren benötigen Sie ein GitHub-Konto.
Dieser Beitrag hat einen gemeinsamen Kommentarbereich mit /timeSyncLocNet.html.