NTP mit Minutenimpuls synchronisieren

[stw]

Hi,

ich habe einen Rechner, der seine Zeit über DCF77 bekommt (keine Inetverbindung). Die Zeit wird eigentlich recht schnell gestellt, leider weicht sie aber um ein paar Sekunden ab. Dies ist besonders blöd, weil daneben eine analoge Uhr steht, derren Zeit exakt geht (über einen anderen DCF77-Empfänger, der rund um die Uhr läuft). Diese andere Uhr bekommt einen Minutenimpuls.

Frage: Kann ich in NTP so einen Minutenimpuls einlesen, um die Uhr genau auf die Andere zu synchronisieren?

Gruß
stw

[dufty2]

Mmmh, denke nicht, daß das geht.

Du hast einen Debian (stable?/tesing?/sid?)-Rechner und an dem hast Du einen DCF77-Empfänger (die es Reichelt oder Conrad etc. gibt) angeschlossen, richtig?
Im NTP-Palaver ist dieser DCF77-Empfänger ein Stratum 0 und Dein Debian-Rechner der dazugehörige Stratum-1 Zeitserver.

Auf der anderen Seite hast Du so 'ne analoge Funkuhr a la Junghans als DCF77-Empfänger, richtig?
Das ist nun ein weiterer Stratum-0 Zeitserver, aber da es "nur" eine analoge Uhr ist und kein Computer, gibt es dort keinen Stratum-1 Zeitserver.

Meines Wissens (kann mich da täuschen) läuft das NTP (da es ein Netzwerkprotokoll ist und so Computer benötigt) nur zwischen Stratum-1 und kleiner (also z. B. Stratum-2, Stratum-3), aber nicht zwischen verschiedenen Stratum-0 und Stratum-1 Servern.

[BenutzerGa4gooPh]

Funkuhr:

Obwohl das Zeitsignal kontinuierlich gesendet wird, wird es aus Stromspargründen oft nur ab und zu zum Nachstellen abgefragt. Bei Uhren, die mit größeren Zellen betrieben werden, ist ein Empfang jede volle Stunde üblich, bei Armbanduhren mit Knopfzellen oder mit Solarzellen nur einmal pro Tag, meist zwischen 2:00 und 4:00 Uhr morgens.

https://de.m.wikipedia.org/wiki/Funkuhr
DCF77, nötige Empfangsdauer:

Um zumindest eine korrekte Uhrzeit zu erhalten, bedeutet das für den Anwender einer Funkuhr, dass der Empfang mindestens knapp über 38 Sekunden laufen muss. Von dieser Zeitspanne sind zwei Sekunden (58. Sekunde sowie die Lücke der 59. Sekunde) nötig, damit sich der Empfänger auf den Anfang der neuen Minute synchronisieren kann, sowie 36 Sekunden zum Empfang des Zeittelegramms inklusive des Paritätsbits. Spätestens nach 120 Sekunden störungsfreien Empfangs hätte die Uhr aber alle nötigen Informationen zur Verfügung.

https://de.m.wikipedia.org/wiki/DCF77

Qualität Funksignal, Synchronisationsintervall, systematischer Fehler?

NTP zwischen DCF77-Empfaenger und NTP-Client (PC)? Muss dann wohl ein spezieller DCF77-Empfaenger (mit NTP-Server) sein. Bauen kann man es bzw. wird professionell hergestellt:
http://www.obbl-net.de/dcf77.html
http://www.raspberry-pi-geek.de/Magazin ... Zeitserver
https://www.meinberg.de/german/products ... server.htm
Genauigkeit von Eigenbauten eher fraglich. Kann man wohl besser professionelle NTP-Server im Netz benutzen.

Netz- und Telefonprovider (Takt für Übertragungstechnik erforderlich) nutz(t)en spezielle Technik per GPS mit Dachantennen. Bin schon ne Weile raus aus dem Fach.

[spiralnebelverdreher]

ich habe einen Rechner, der seine Zeit über DCF77 bekommt (keine Inetverbindung). Die Zeit wird eigentlich recht schnell gestellt, leider weicht sie aber um ein paar Sekunden ab.

Wie hast du diese Abweichung festgestellt? Direkte visuellen Vergleich der Uhranzeigen? Schwankt die Abweichung oder ist sie konstant?

Dies ist besonders blöd, weil daneben eine analoge Uhr steht, derren Zeit exakt geht (über einen anderen DCF77-Empfänger, der rund um die Uhr läuft). Diese andere Uhr bekommt einen Minutenimpuls.

Ich weiß natürlich nicht wie deine andere Uhr mit der Uhrzeit versorgt wird und was das für ein Typ ist.

Bei mir in der Küche hängt bspw. so eine DCF77 Wanduhr, die so zwischen 20 und 30 Euro gekostet hat. Diese Uhr hat die Eigenschaft, das DCF77 Signal nur ein oder wenige Mal täglich auszuwerten (wahrscheinlich um Batteriestrom zu sparen) und läuft die meiste Zeit mit ihrem eigenen Quarz. Der Minutenzeiger springt dann am Ende der Minute auf den nächsten Wert. Meinst du das mit Minutenimpuls?

Oder habt ihr eine Werksuhr, die an einer zentralen Uhr (Zentraluhr) hängt? Diese Uhren waren früher bei der Bahn weit verbreitet; sie hatten die Eigenschaft, dass der volle Umlauf des Sekundenzeigers in ca 58s erfolgte (einfacher Elektromotor, kein Quarz) um dann 2s Pause zu machen. Mit dem Minutenpuls der Zentraluhr rückte der Minutenzeiger weiter und der Sekundenzeiger rannte wieder los. Eine gute Genauigkeit war da natürlich zum Minutenbeginn gegeben.

Frage: Kann ich in NTP so einen Minutenimpuls einlesen, um die Uhr genau auf die Andere zu synchronisieren?

Das kommt auf den DCF77 Empfänger an. Ich kenne noch die alten Funkuhren, die einen seriellen Ausgang zum Rechner hatten. Auf dem Rechner war ein Programm nötig, das die serielle Schnittstelle abfragte und dann intern die Zeit weiter verwendete (anzeigte, verteilte, ...). Wenn du so etwas hast, brauchst du natürlich einen Treiber für die Schnittstelle und einen ntp Serverprozess auf deinem Rechner.

Heutige DCF77 Empfänger haben einen kleinen Rechner an Bord, der einen ntp Server betreibt und über das ntp-Protokoll die Uhrzeit im lokalen Netz verteilt. Dann muss die IP-Adresse dieses Dienstes den anderen Rechnern im LAN bekannt gemacht werden, wofür es mehrere Methoden gibt (bspw. auch Verteilung über DHCP).

Am besten schaust du mal in die Doku deines DCF77 Empfängers und bei weiteren Fragen postest du weitere Details hier.

[dufty2]

Meinst du das mit Minutenimpuls?

Vermutlich meint er die Sammlung+Auswertung des DCF77-Signals, welches aufgrund der geringen Bandbreite (1 bit/s) fast eine Minute dauert (näheres siehe Jana's Links).
Die Hoffnung wäre dann, wenn das Signal ständig (sprich minütlich) ausgewertet wird, das der Rechner zeitlich synchron zu der Analoguhr geht.
Wobei noch fraglich ist, ob dies bei der Analoguhr tatsächlich der Fall ist, denn diese "30 € -Junghans-Dinger" machen es - wie Du schon erwähnt hast - ja gar nicht, sondern 1x stündlich oder gar nur 1xtäglich.

Warum allerdings nach der Synchronisation mit dem DCF77 die Rechneruhr einige Sekunden daneben liegt, ist mir ein Rätsel; dachte, der Abstand wäre viel, viel geringer.
Habe aber selbst keine Stratum-0 bzw. Stratum-1 Uhr.

[spiralnebelverdreher]

Meinst du das mit Minutenimpuls?

Vermutlich meint er die Sammlung+Auswertung des DCF77-Signals, welches aufgrund der geringen Bandbreite (1 bit/s) fast eine Minute dauert (näheres siehe Jana's Links).
Die Hoffnung wäre dann, wenn das Signal ständig (sprich minütlich) ausgewertet wird, das der Rechner zeitlich synchron zu der Analoguhr geht.
Wobei noch fraglich ist, ob dies bei der Analoguhr tatsächlich der Fall ist, denn diese "30 € -Junghans-Dinger" machen es - wie Du schon erwähnt hast - ja gar nicht, sondern 1x stündlich oder gar nur 1xtäglich.

Warum allerdings nach der Synchronisation mit dem DCF77 die Rechneruhr einige Sekunden daneben liegt, ist mir ein Rätsel; dachte, der Abstand wäre viel, viel geringer.
Habe aber selbst keine Stratum-0 bzw. Stratum-1 Uhr.

Der Abstand ist viel geringer, sobald der DCF77 Empfänger mehrere Minuten ununterbrochen guten Empfang hat. Auch wenn der Empfang mal weg geht oder der DCF77 Sender wegen Wartunsgarbeiten oder Gewitter abgeschaltet wird, merkst du sehr wenig davon. Wirklich gute DCF77 Empfänger haben eine sehr genaue, temperierte interne Quarz-Uhr (oder noch was besseres) mit einer internen Ungenauigkeit im niedrigen einstelligen Sekundenbereich pro Jahr. Ihren internen ntp Server versorgen sie mit dieser Zeit und der DCF77 Empfänger dient der Kontrolle und dem Fein-Tuning der Uhrzeit.

Ich vermute die Probleme des Thread-Owners an anderer Stelle: Er bezieht seine Uhrzeit nicht wirksam vom DCF77 Empfänger, obwohl die Kabel alle an den richtigen Stellen eingesteckt sind.

[stw]

Der Empfang des DCF77-Signals gehts über ein Conrad-Modul, dass an den Rechner angeschlossen ist.

Wie hast du diese Abweichung festgestellt? Direkte visuellen Vergleich der Uhranzeigen?

Korrekt. Die Sekunden nähern sich immer mehr an, aber das dauert sehr lange (2h und mehr).

Oder habt ihr eine Werksuhr, die an einer zentralen Uhr (Zentraluhr) hängt? Diese Uhren waren früher bei der Bahn weit verbreitet; sie hatten die Eigenschaft, dass der volle Umlauf des Sekundenzeigers in ca 58s erfolgte (einfacher Elektromotor, kein Quarz) um dann 2s Pause zu machen. Mit dem Minutenpuls der Zentraluhr rückte der Minutenzeiger weiter und der Sekundenzeiger rannte wieder los. Eine gute Genauigkeit war da natürlich zum Minutenbeginn gegeben.

Richtig, hier hängt eine Nebenuhr, die von einer zentralen Mutteruhr ihren Minutenimpuls bekommt. Diesen würde ich gerne zur Synchronisation benutzen.

[cosmac]

hi,

Also alles ganz normal. Es gibt jede Minute ein elektrisches Signal. Dann würde ich versuchen, dieses Signal mit einem kleinen passiven Adapter in den Rechner zu bringen

Die beiden Widerstände müssen natürlich zur Signalspannung passen, die Polarität spielt keine Rolle, auch abwechselnd + und - geht.

Das Teil liefert am /dev/ttyxxx jede Minute ein oder mehrere zufällige Zeichen ab. Wahrscheinlich kann man die Baudrate so einstellen, dass genau ein Zeichen ankommt. Ein Programm kann so den Minutenbeginn auf ca. 1/10 Sekunde genau erfahren. Die restliche Zeitinformation bekommt man per clock_gettime(2) oder per sysfs von der RTC. Die muss einmal von Hand auf ±29 Sekunden genau gestellt werden. Damit kann das Programm synchron zum Impuls die absolute Zeit an den ntpd übergeben.

Das geht wahrscheinlich über den parse-Treiber am einfachsten. Der erwartet einmal pro Sekunde eine Zeile Text mit Datum und Uhrzeit. Den Text zu erzeugen ist trivial. Die Übergabe kann per pseudo-tty und evt. socat erfolgen. Die Frage ist, ob der ntpd mit den fehlenden 59 Meldungen klar kommt. Aber auch die müsste man aus der Systenzeit ausreichend genau erzeugen können.

[dufty2]

Cooler post, cosmac, Hut ab!

Als Nicht-Bastler würde ich, wenn's mit DCF77 nicht hinhaut, mit GPS probieren.
Und wenn das auch nicht geht, 'ne echte Atomuhr.
Sollen jetzt auch gar nicht mehr so teuer sein.

[cosmac]

Cooler post...
Als Nicht-Bastler würde ich, wenn's mit DCF77 nicht hinhaut, mit GPS probieren.

Danke!
Aber USB-GPS-Maus auspacken, einstecken, geht -- wie langweilig! Na gut, das nächste Fenster sollte nicht weiter als 5 bis 10m vom Rechner entfernt sein.

[stw]

Hi cosmac,

zu deiner Lösung: kann ich weiterhin einen DCF77-Empfänger betreiben, denn die Minuten weichen schon nach ein paar Tagen Stillstand ab, und kann ich dafür nicht belegte Adern der seriellen Schnittstelle, an der der DCF77-Empfänger hängt, nutzen (Einplatinenrechner, hab nur eine für den Empfang frei)?

[BenutzerGa4gooPh]

Der Empfang des DCF77-Signals gehts über ein Conrad-Modul, dass an den Rechner angeschlossen ist.

... nicht belegte Adern der seriellen Schnittstelle, an der der DCF77-Empfänger hängt, nutzen (Einplatinenrechner, hab nur eine für den Empfang frei)?

Nach etlichen Threadantworten mit "vermutlich" sollte man mittlerweile auf die Idee kommen, genauer zu beschreiben, wenigstens das Zitierte. Links auf Datenblätter im Netz und ASCII-Skizzen sind hilfreich.

[spiralnebelverdreher]

Der Empfang des DCF77-Signals gehts über ein Conrad-Modul, dass an den Rechner angeschlossen ist.

Wie hast du diese Abweichung festgestellt? Direkte visuellen Vergleich der Uhranzeigen?

Korrekt. Die Sekunden nähern sich immer mehr an, aber das dauert sehr lange (2h und mehr).

Aber nach den 2h bleibt der Unterschied konstant sehr gering? Das wäre ein gutes Zeichen. Wenn nach 2h alles ok ist, wo ist dann das Problem? Oder ist das Problem, dass es nach dem Kaltstart des Rechners immer etwa 2h dauert bis die Uhrzeiten abgeglichen sind?
Ich weiß nicht, ob du dich mit der Arbeitsweise eines ntp-Servers und eines ntp-Clients mal näher beschäftigt hast. Solltest du aber auf jeden Fall tun bevor du zum Lötkolben greifst. Der ntp-Client fragt (sehr vereinfacht gesagt) den ntp-Server regelmäßig nach der der Uhrzeit und vergleicht diese mit der eigenen Uhrzeit. Bei Abweichungen stellt er seinen eigene Uhr etwas schneller oder langsamer ein, mit dem Ziel, irgendwann fast gar nichts mehr nachstellen zu müssen. So weit so einfach, aber im realen Leben ist es viel komplizierter: Die Laufzeit der Uhrzeitinformation im IP-Netzwerk ist nicht konstant, die Uhrzeit des Clients hängt auch der Temperatur seiner Hardware ab usw. Deshalb nimmt der Client immer nur geringe Änderungen vor, um nicht dauernd von zu schnell auf zu langsam auf zu schnell zu wechseln. Bei der Erstsynchronisation führt das dann zu einer langsamen Annäherung der Uhrzeiten. Das ist aber nicht gottgegeben, sondern kann durch gezielte Änderung von Konfigurationsparametern (wie häufig werden Uhrzeiten verglichen? Wie groß ist die maximale Änderung?, ...) beeinflusst werden. Man sollte da aber wissen, was man tut. Sonst holt man sich damit Verschlechterungen an anderer Stelle herein.

BTW, Kannst du das Modul von Conrad mal hier verlinken?

Oder habt ihr eine Werksuhr, die an einer zentralen Uhr (Zentraluhr) hängt? Diese Uhren waren früher bei der Bahn weit verbreitet; sie hatten die Eigenschaft, dass der volle Umlauf des Sekundenzeigers in ca 58s erfolgte (einfacher Elektromotor, kein Quarz) um dann 2s Pause zu machen. Mit dem Minutenpuls der Zentraluhr rückte der Minutenzeiger weiter und der Sekundenzeiger rannte wieder los. Eine gute Genauigkeit war da natürlich zum Minutenbeginn gegeben.

Richtig, hier hängt eine Nebenuhr, die von einer zentralen Mutteruhr ihren Minutenimpuls bekommt. Diesen würde ich gerne zur Synchronisation benutzen.

Synchronsiation? Ich habe da meine Zweifel, ob das so einfach geht. Erstens ist der Minutenimpuls nicht uhrzeitbehaftet. Du siehst nur, dass sich ein Minutenwert ändert. Du weißt aber nicht, ob deine Uhr im Rechner der Zentraluhr 3 Minuten hinterher oder 5 Minuten voraus läuft. So eine primitive Synchronisation setzt voraus, dass die Uhrzeit schon auf etwa +/- 20s genau abgeglichen sind. Wie stellst du das sicher?
Zweitens musst du dann heftigst an deinem ntp-Client (oder an einem eigenen ntp-Server) herumprogrammieren, damit er auf die Minutentakte der seriellen Schnittstelle hört.
Drittens würde ich mir die Signalqualität des Minutentaktes mal mit einem Speicher-Oszilloskop anschauen: Wie ist die Flankensteilheit des Signals? Gibt es Störungen wie Rauschen oder Brummen auf der Leitung?

Insgesamt würde ich von Cosmacs Idee einer HW-Lösung (Optokoppler) abraten. Das geht deutlich einfacher.

[stw]

Modul von Conrad (641138), beschaltet nach http://linuxwiki.de/EigenbauFunkuhr

Code: Alles auswählen

Rechner (ttyS)-----------------------------------------DCF77-Empfänger
                                        |----------Minutenimpuls einspeisen

[MSfree]

Modul von Conrad (641138), beschaltet nach http://linuxwiki.de/EigenbauFunkuhr

Die Anleitung kenne ich. Dort wird aber nur der Sekundenpuls des DCF-Empfängers genutzt, um den NTP zu synchronisieren. Ohne einen NTP-Server, der die Absolutzeit liefert, funktioniert das nicht.

Der NTP-Dienst unter Linux kann das DCF-Signal nicht dekodieren und die Uhrzeit aus dem Bitmuster des Signals heraus lesen. Wenn man dann letztlich doch einen Internet-NTP-Server ansprechen muß, ist der Sinn eines DCF-Empfängers ziemlich begrenzt.

Ich habe mir ein kleines C-Programm geschrieben, das das Bitmuster aus dem o.g. DCF-Empfängers, der an die GPIO-Pins eines Raspis angeschlossen wird, dekodiert.

[cosmac]

die Minuten weichen schon nach ein paar Tagen Stillstand ab

Modul von Conrad (641138)

Frage: Kann ich in NTP so einen Minutenimpuls einlesen, um die Uhr genau auf die Andere zu synchronisieren?

Nein. Bzw. "kann" schon, aber es bringt nichts. Der ntpd verstellt die Rechneruhr immer so langsam, egal, ob er DCF oder den Minutenimpuls benutzt. Wenn du die Rechneruhr zu Anfang direkt richtig stellen willst, muss die genaue, absolute Zeit ja irgendwo her kommen (DCF, GPS, TCXO, ...). Also brauchst du den Minutenimpuls nicht mehr. Außerdem ist der Minutenimpuls per Definition genauso genau wie dein DCF.

Das Problem ist ja die schlechte Rechneruhr kombiniert mit dem sehr langen Stillstand. Deswegen nützt auch ein einfacher GPS-Empfänger nichts, der braucht nach mehreren Tagen ohne Strom auch ein paar Minuten, genau wie DCF. Und so lange darf der Rechner eigentlich nicht starten (mitten im Betrieb möchte man die Uhr nicht um Minuten auf einmal verstellen).

Gut wäre ein Empfänger, der nicht ausgeschaltet wird. Der kann sofort die richtige Zeit liefern. Oder ein Empfänger mit gutem Quarz und Batterie. Der liefert direkt nach dem Einschalten seine Quarz-Zeit und synchronisiert sich gemütlich im Hintergrund. Oder du spendierst dem Rechner eine gute Uhr mit Batterie. Für manche Einplatinenrechner gibt es kleine steckbare Module, sogar mit TCXO.

[spiralnebelverdreher]

die Minuten weichen schon nach ein paar Tagen Stillstand ab

Modul von Conrad (641138)

Frage: Kann ich in NTP so einen Minutenimpuls einlesen, um die Uhr genau auf die Andere zu synchronisieren?

Das Problem ist ja die schlechte Rechneruhr kombiniert mit dem sehr langen Stillstand. Deswegen nützt auch ein einfacher GPS-Empfänger nichts, der braucht nach mehreren Tagen ohne Strom auch ein paar Minuten, genau wie DCF. Und so lange darf der Rechner eigentlich nicht starten (mitten im Betrieb möchte man die Uhr nicht um Minuten auf einmal verstellen)

Wenn die genaue Uhrzeit von Anfang an wichtig ist muss man halt ein paar Euronen spendieren für eine Lösung, die das erfüllt ("always on", batteriegepufferte CMOS-Uhr, ...) bzw. wenn man dieses Geld nicht ausgeben kann / will, dann muss man den Hochlauf des Gerätes so gestalten, dass erst nach erfolgter Uhrzeitsynchronisation die kritischen Anwendungen gestartet werden. Was aber dann auch dazu führen kann, dass die Anwendung sehr lange nicht gestartet wird (DCF Signal schlecht oder ganz weg wegen Wartung des Senders).

Mir ist mit dem geposteten Link nicht klar, was denn an der seriellen Schnittstelle übergeben wird und vor allem welches Programm denn dies auswertet. Hast du da weitere Infos?

Noch eine selbst erlebte Geschichte zum Thema DCF77 und Signalqualität: Wir hatten nach Einbau einer neuen Heizung den Effekt, dass morgens manchmal die Vorlauftemperatur deutlich zu kühl war. Das Steuerungsdiplay ging davon, dass es mitten in der Nacht war. Ich hab die Uhrzeit dann korrigiert und gut war. Einige Tage war die Uhrzeit wieder falsch, wieder korrigiert. Das wiederholte sich mehrfach. Besonders merkwürdig war, dass die Abweichungen immer ganz Stunden waren. Die Minutenwerte stimmten immer. Ich hab dann mal nachgeforscht, und tatsächlich hatte die Heizungssteuerung einen DCF77 Empfänger und die Leitung zum Außentemperaturfühler war die Antenne. Diese Leitung ging am Waschkeller vorbei und der Elektrosmog eines Waschmaschinenmotors wurde dann vom DCF77 Empfänger als Uhrzeit interpretiert. Ich habe den DCF77 Teil in der Heizung dann abgestellt und die Probleme waren weg. Nachteil: Automatische Umstellung Sommer/Winterzeit ist damit auch weg.

[cosmac]

Mir ist mit dem geposteten Link nicht klar, was denn an der seriellen Schnittstelle übergeben wird und vor allem welches Programm denn dies auswertet. Hast du da weitere Infos?

meinst du diesen?

Modul von Conrad (641138), beschaltet nach http://linuxwiki.de/EigenbauFunkuhr

Dort wird direkt der ntpd selbst benutzt, d.h. sein spezieller refclock-Treiber, der die DCF-Rohdaten dekodieren kann. Dem werden die einzelnen Bits der DCF-Daten übergeben (100ms = 0, 200ms = 1). Die kommen direkt aus dem AM-Demodulator des Empfängers. Das Programm muss die filtern und die Impulslänge ermitteln und z.B. entscheiden ob ein 150ms-Impuls eher eine 1 oder eine 0 war. Wenn die Entscheidung falsch war und das zweimal passiert, kommt eine falsche Zeit raus. Wenn es den Impuls sicherheitshalber ignoriert, gehen erstmal die Daten einer ganzen Minute verloren. Na gut, ein Bit kann man aus den Nachbar-Minuten rekonstruieren. Man kann da beliebig viel Aufwand treiben, damit es auch bei mäßigem Empfang noch funktioniert.

Viel wichtiger ist eine gute Fehlererkennung, die nicht nur die drei Parity-Bits nutzt sondern die ganze Redundanz der Daten. Man weiß ja z.B. im Voraus, wie sich zwei aufeinander folgende Minuten unterscheiden müssen. Nach meiner Erfahrung macht dieser ntpd-Treiber den Job nicht besonders gut.

Mein schönstes DCF-Erlebnis: auf einem kleinen Bahnhof gibt es drei Uhren mit je einem eigenen DCF-Empfäger. Alle drei zeigen unterschiedliche Zeiten an

[dufty2]

Modul von Conrad (641138), beschaltet nach http://linuxwiki.de/EigenbauFunkuhr

Die Anleitung kenne ich. Dort wird aber nur der Sekundenpuls des DCF-Empfängers genutzt, um den NTP zu synchronisieren. Ohne einen NTP-Server, der die Absolutzeit liefert, funktioniert das nicht.

Der NTP-Dienst unter Linux kann das DCF-Signal nicht dekodieren und die Uhrzeit aus dem Bitmuster des Signals heraus lesen. Wenn man dann letztlich doch einen Internet-NTP-Server ansprechen muß, ist der Sinn eines DCF-Empfängers ziemlich begrenzt.

Mmmh, das glaube ich so jetzt nicht
Wenn ich mir die debian/rules vom ntp-Paket anschaue, so steht da

Code: Alles auswählen

--enable-all-clocks --enable-parse-clocks --enable-SHM

Ein configure-Testlauf zeigt auch

Code: Alles auswählen

checking Meinberg clocks... yes
checking DCF77 raw time code... yes

Wenn ich stw richtig verstanden habe, hat sein Einplatinencomputer keine Internetverbindung und auch keine Realt-Time-Clock (RTC), also quasi ein raspi.
Er würde dann überhaupt keine Zeiteinstellung bekommen, wenn Du recht hättest