/edit: Bitte beachtet auch das Update im forum-raspberrypi.de, etwaige andere Forumsbeiträge über Google und die Kommentare unter diesem Artikel. Ich selber habe leider den RaspberryPi mit DCF77 nicht mehr im Einsatz, da es eine Auftragsarbeit war.
Gerade habe ich einen Raspberry Pi zur Funkuhr aufgerüstet. Das Funksignal kommt vom DCF77 – das ist der Sender, den auch eure normalen Funkuhren benutzen.
(Hinweis: Das war damals ein Raspberry Pi 1 oder 1+. Ich weiß leider nicht, ob das mit den aktuellen Generationen noch genau so funktioniert. Ich bin sehr dankbar, wenn Ihr Eure Erfahrungen mit aktuellen Raspberrys in den Kommentaren teilt!)
Conrad DCF77 Platine
Als erstes besorgt ihr euch die DCF77 Platine von Conrad: http://www.conrad.de/ce/de/product/641138/Conrad-DCF-Empfaengerplatine
Verkabelung
Sobald ihr die habt, beschriftet am besten gleich die Kontakte mit ihren Nummern:
- 1: Masse / GND
- 2: Betriebsspannung / VCC
- 3: DCF Ausgang, normal
- 4: DCF Ausgang, invertiert
Kontakt 3 werden wir überhaupt nicht benutzen.
Zwischen Kontakt 2 und Kontakt 4 klemmt ihr einen Widerstand. Ich habe einen mit circa 6 kOhm benutzt.
Aus den Kontakten 1, 2 und 4 legt ihr jetzt jeweils ein Kabel heraus. Das Ende der Leitung ist am besten eine Steckverbindung, die man später einfach auf einen Pin draufstecken kann. Tut euch selber einen Gefallen, und verwendet (im Unterschied zu mir) drei verschiedenfarbige Kabel.
Ausrichtung
Bei der Platine ist eine Antenne dabei. Das ist dieses fette graue Ding aus Ferrit. Damit die Antenne den besten Empfang bekommt, richtet ihr sie „gegensätzlich“ zum Sender aus. Der Sender steht bei Frankfurt am Main (konkreter: Mainflingen).
Schaut am einfachsten bei Google Maps nach, wo ihr seid und wo Mainflingen ist: https://www.google.de/maps/place/Mainflingen,+Mainhausen/@50.3750485,9.3278463,7z/data=!4m2!3m1!1s0x47bd3f059ce2631b:0xa224352a99a4560
Schaut dann grob, was die Himmelsrichtung ist (von mir aus liegt Mainflingen in Richtung Nord-Nord-Ost). Nehmt dann einfach euer Smartphone zur Hand, schaut auf die Compass App und sucht wo die Himmelsrichtung ist. Wenn ihr die habt, dann muss die Antenne einfach 90° dazu gedreht werden. Außerdem sollte die Antenne einfach horizontal liegen und nicht etwa stehen. Achtet zudem darauf, dass die Antenne ausreichend weit von technischem Gerät entfernt ist. Ganz schlecht ist beispielsweise, die Antenne auf den Raspberry Pi zu legen oder in ein gemeinsames Gehäuse zu verbauen. (Die Chips erzeugen hochfrequente Wellen, die dann direkt wieder in eure Antenne gehen und das Signal komplett unbrauchbar machen.)
Raspberry Pi bzw. NTPd
Ich gehe mal davon aus, dass ihr den RPi schon eingerichtet habt. In meinem Fall habe ich die Raspbian Distribution verwendet. Bei einer anderen funktionieren die Dinge vielleicht etwas anders.
Verkabeln
Die Kabel die von der Platine kommen müssen natürlich noch an den RPi gesteckt werden. Eine Übersicht der Pins im Allgemeinen gibt es hier:
(Die Grafik ist von http://developer-blog.net/hardware/raspberry-pi-gpio-schnittstelle-teil-1/, dem ewiger Dank und Ehre gebührt.)
Die Pins werden nun wie folgt verbunden (links die DCF77 Platine mit den Bezeichnern von oben, rechts der RPi mit den Bezeichnern der Grafik):
- 1 (GND) → 9 („Ground“)
- 2 (VCC) → 1 („3V3“)
- 3 bleibt leer
- 4 (DCF) → 10 (GPIO15 RXD)
Serielle Konsole frei machen
Die Signale kommen später auf der seriellen Konsole an. Da das Linux standardmäßig diese Konsole für etwas anderes verwendet, müssen wir die erst noch frei machen. Dazu bearbeiten wir zuerst die Datei /boot/cmdline.txt. Standardmäßig stehen dort einige Parameter mit ttyAMA0 drin. Diese entfernen wir. Danach sah die Datei bei mir so aus:
wc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Die nächste Datei ist /etc/inittab. Dort kommentieren wir ebenfalls die Zeile zu ttyAMA0 aus:
#Spawn a getty on Raspberry Pi serial line #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
NTP einrichten
NTP beim if-up verhindern
Standardmäßig wird die Zeit von einem NTP Server geholt, wenn Raspbian eine Netzwerkverbindung bekommt. Das können wir in /etc/network/if-up.d/ntpdate abstellen. Da kann man als zweite Zeile einfach folgendes einfügen:
exit 0
Man kann die Datei stattdessen aber vermutlich auch einfach löschen.
Symlink setzen
Die Daten vom DCF77 Empfänger kommen über /dev/ttyAMA0 rein. Der ntpd wird die Daten aber auf /dev/refclock-0 erwarten. Also legen wir einfach einen Symlink. Da /dev ein tmpfs ist, muss der Link bei jedem Start neu erstellt werden. Das können wir einfach in /etc/init.d/ntp machen:
if [ ! -L /dev/refclock-0 ]; then ln -s /dev/ttyAMA0 /dev/refclock-0 fi ## diese vorhandenen Zeilen auskommentieren #if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then # NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp" #fi
Zusätzlich haben wir damit noch ntpd gesagt, dass er sich nicht weiter um andere NTP-Server kümmern soll, über die wir evtl. von unserem Router informiert wurden.
NTPd einrichten
Die /etc/ntp.conf sollte so aussehen:
driftfile /var/lib/ntp/ntp.drift # Enable this if you want statistics to be logged. logfile /var/log/ntpd logconfig =all statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable # By default, exchange time with everybody, but don't allow configuration. restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 # nicht zwingend notwendig, nur für spätere Berechnung der fudgetime server ptbtime1.ptb.de noselect server ptbtime2.ptb.de noselect server ptbtime3.ptb.de noselect # der eigentliche Zeit"server", d.h. unser DCF77-Empfänger server 127.127.8.0 mode 5 # diese Zeile beachten wir erst später, und dient zur Korrektur der Signallaufzeit fudge 127.127.8.0 time1 YOUR_CALCULATION
Besonders wichtig ist die letzte Zeile. Diese etwas merkwürdige IP Adresse weist den ntpd an, den DCF77 Empfänger zu benutzen. Was man dabei wirklich wissen sollte, ist dass die 0 bedeutet, dass /dev/refclock-0 verwendet werden soll. Die 8 und das mode 5 sind auch wichtig, aber für’s Verständnis bzw. nachbauen egal.
Logging und Permissions
Dann gehen wir noch in /var/log und legen eine Datei ntpd an:
sudo touch ntpd && sudo chown ntp:ntp ntpd
Da der ntpd unter dem User „ntp“ läuft, muss dieser noch Zugriff auf die ttyAMA0 bzw refclock-0 bekommen:
sudo adduser ntp tty ; sudo adduser ntp dialup
(Meiner Meinung nach muss es die Gruppe dialup sein, aber einige Leute meinen, es sei tty. Daran soll es aber nicht scheitern: deshalb einfach beide.)
Logging Beispiele
Nachfolgend einige Meldungen aus dem ntpd-Log, und was sie bedeuten:
# vom Signal sind nur 7 bits angekommen; danach war die Verbindung gestört 31 Jul 00:07:00 ntpd[2533]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 7 bits # alle Bits sind angekommen, aber der Paritäts-Check ist fehlgeschlagen 30 Jul 23:35:00 ntpd[2396]: parse: convert_rawdcf: parity check FAILED for "#-######-#--#---A--LS-2-81--P1---12p---8121-412----2-8---8" # die Uhr hat sich erfolgreich synchronisiert und ntpd stellt seine Dienste im Netz bereit 31 Jul 00:08:00 ntpd[2533]: 0.0.0.0 c215 05 clock_sync
Fertig
Jetzt noch neustarten, und das sollte es dann auch gewesen sein.
Falls es nicht funktioniert, ist das natürlich schade. Unter /var/log/ntpd gibt es evtl. weitere Anhaltspunkte. Ebenso gibt ein „ntpq -c as -c cv -c rv“ mitunter sinnvolle Informationen.
Sollte etwas grundlegend nicht funktionieren, ist man ohne Elektrotechnik-Kenntnisse und -Bastelkiste vermutlich aufgeworfen.
Software-seitig gibt es dieses sehr hilfreiche Tool: https://github.com/rene0/dcf77pi Damit kann man die Daten des Empfängers auslesen. Die DCF-Verbindung sollte dazu auf Pin 11 (GPIO17) gelegt werden. Zusätzlich muss man eventuell in der Config (wenn ich mich recht erinnere) „activehigh = 0“ setzen
Fudgetime korrigieren
Wenn man NTP übers Internet benutzt, dann kann er die Latenz recht gut messen und herausrechnen. Bei Funk geht das aber nicht, da er nicht weß wie lange das Signal denn nun zum Verarbeiten gebraucht hat. Deswegen kann man einmal am Anfang einen Internet-NTP Server als Referenz nehmen, um das zu berechnen.
Kopiert euch dafür dieses schnell von mir zusammengefrickelte Skript und führt es aus:
echo "This script will calculate the mean offset if you provided some noselect ntp-servers in your ntp.conf" echo "If you did not provide any noselect ntp servers, this script will fail. It will also fail if those servers are not reachable." echo echo "Your current fudge time is:" ntpq -c cv | grep fudgetime1 | cut -d" " -f 5 echo echo "The mean offset (compared to the 'noselect' ntp-servers in your ntp.conf) is:" cat /var/log/ntpstats/peerstats | grep -v 127.127.8 | cut -d" " -f 5 | awk '{a+=$1} END{print a/NR}' echo echo "Add up those values, divide them by 1000, and add this line to your ntp.conf:" echo "fudge 127.127.8.0 time1 YOUR_CALCULATION"
In der Ausgabe sollte so etwas stehen wie, dass die aktuelle Fudgetime (fest einprogrammiert) 292ms ist, und der gemessene Offste ist zusätzlich vermutlich circa 640ms. Das rechnet ihr zusammen, dividert es durch 1000 und tragt dann also bspw. das hier in die ntp.conf ein:
fudge 127.127.8.0 time1 0.932
automatischer Restart bei Panic Stops
Manchmal, wenn auch tendentiell selten, kommt es vor, dass der Sender eine falsche Uhrzeit empfängt. Meist wird das durch Parity-Bits verhindert – aber manchmal schlägt das fehl. Wenn die Zeit dann mehr als 1000 Sekunden von der aktuellen abweicht, dann beendet sich ntpd. Im Falle von NTP mag das sinnvoll sein, aber bei einer DCF77-Funkuhr ist das eher kontraproduktiv.
Deswegen richten wir ein Monitoring ein, das einfach ntpd neustartet sobald er sich beendet hat. Dazu installieren wir zuerst das Paket „monit“ und richten dann die Datei /etc/monit/conf.d/ntpd ein:
check process ntpd with pidfile /var/run/ntpd.pid group ntpd start program = "/etc/init.d/ntp start" stop program = "/etc/init.d/ntp stop"
Hi,
tolles Projekt! Habe ich nachgebaut, aber scheint ein Problem zu geben, welches ich nicht herausfinde.
Kannst du mir vielleicht helfen und hast ein Idee? Ich nutze im Gegensatz zur dir einen RaPi B+
# ntpq -c as -c cv -c rv
ind assid status conf reach auth condition last_event cnt
===========================================================
1 45447 8011 yes no none reject mobilize 1
associd=0 status=0000 , no events, clk_unspec,
device="RAW DCF77 CODE (Conrad DCF77 receiver module)", timecode=,
poll=236, noreply=0, badformat=0, baddata=0, fudgetime1=3903.150,
stratum=1, refid=DCFa, flags=0, refclock_time="",
refclock_status="", refclock_format="RAW DCF77 Timecode",
refclock_states="*NOMINAL: 04:11:06 (100.00%); running time: 04:11:06"
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version="ntpd 4.2.6p5@1.2349-o Mon Feb 9 03:34:42 UTC 2015 (1)",
processor="armv6l", system="Linux/3.18.7+", leap=11, stratum=16,
precision=-20, rootdelay=0.000, rootdisp=225.990, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
clock=d899aafa.f0a1db63 Thu, Feb 26 2015 15:23:54.939, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-12.837, sys_jitter=0.000,
clk_jitter=0.001, clk_wander=0.000
Das Loglevel habe ich auch erhöht und im im ntpd Log steht das hier, nach dem Start, aber mehr kommt dann auch nicht.
26 Feb 11:12:48 ntpd[3655]: NTP PARSE support: Copyright (c) 1989-2009, Frank Kardel
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: reference clock "RAW DCF77 CODE (Conrad DCF77 receiver module)" (I/O device /dev/refclock-0, PPS device /dev/refclock-0) added
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: Stratum 0, trust time 00:00:00, precision -20
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: rootdelay 0.000000 s, phase adjustment 0.292000 s, PPS phase adjustment 0.000000 s, normal IO handling
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: Format recognition: RAW DCF77 Timecode
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: NO PPS support
26 Feb 11:12:48 ntpd[3655]: GENERIC(0) 8011 81 mobilize assoc 45447
26 Feb 11:12:48 ntpd[3655]: PARSE receiver #0: new phase adjustment 3.903150 s
26 Feb 11:12:48 ntpd[3655]: 0.0.0.0 c016 06 restart
26 Feb 11:12:48 ntpd[3655]: 0.0.0.0 c012 02 freq_set kernel -12.837 PPM
Wie man hier sieht, ist reach auf 0, was wohl bedeuten soll, dass er den Empfänger nicht erreicht
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
GENERIC(0) .DCFa. 1 l - 64 0 0.000 0.000 0.000
Wenn ich von einem anderen Linux System ntpdate ausführe, bekomme ich diese Fehlermeldung
# ntpdate -vd pi
26 Feb 18:04:53 ntpdate[15893]: ntpdate 4.2.6p5@1.2349-o Sat Dec 20 18:47:36 UTC 2014 (1)
transmit(192.168.178.41)
receive(192.168.178.41)
transmit(192.168.178.41)
receive(192.168.178.41)
transmit(192.168.178.41)
receive(192.168.178.41)
transmit(192.168.178.41)
receive(192.168.178.41)
192.168.178.41: Server dropped: strata too high
server 192.168.178.41, port 123
stratum 16, precision -20, leap 11, trust 000
refid [192.168.178.41], delay 0.02617, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: d899abe5.3419c93a Thu, Feb 26 2015 15:27:49.203
transmit timestamp: d899d0bc.11614720 Thu, Feb 26 2015 18:05:00.067
filter delay: 0.02620 0.02620 0.02617 0.02618
0.00000 0.00000 0.00000 0.00000
filter offset: -9430.86 -9430.86 -9430.86 -9430.86
0.000000 0.000000 0.000000 0.000000
delay 0.02617, dispersion 0.00000
offset -9430.864957
26 Feb 18:05:00 ntpdate[15893]: no server suitable for synchronization found
Wenn du eine Idee hättest, wäre das echt super! Danke sehr schon im vorher.
Hi,
leider habe ich das Projekt damals in Auftrag zusammengebaut und nun nicht mehr in Reichweite.
Es gibt neben ntpd aber noch weitere Tools, die mit dem Signal umgehen können: z.B. das hier https://github.com/rene0/dcf77pi und das http://www.comif.de/rpi-dcf77-interface
Ansonsten kann ich dir eigentlich nur empfehlen, mal in einem RPi-Forum nachzufragen. Das Projekt ist leider zu lange her, als dass ich noch aus dem Kopf heraus irgendetwas sinnvolles beisteuern könnte. :)
Du kannst höchstens mal noch sicherstellen, dass die Antenne weit genug von anderen Geräten entfernt ist und dann die obige Softwares ausprobieren.
Viel Erfolg und Spaß!
Hallo, ich möchte genau das gleiche zusammenbauen. Daher danke schonmal für die Anleitung! Ich verstehe aber nicht ganz wozu der Widerstand zwischen VCC und DCF_inv benötigt wird? Ich würde mich da über eine kurze Erklärung freuen. Danke, Martin
Hi Martin,
ich selber bin in Elektrotechnik leider ziemlich unbewandert – das stand so auf dem beiliegenden Zettel der Platine ;-). Vielleicht kann dir in einem E-Technik-Forum jemand qualifizierter helfen.
Viele Grüße!
Hallo zusammen,
es ist ganz einfach:
der DCF77-Empfänger hat einen Open-Collector-Ausgang d.h. dieser schaltet gegen Masse (GND). Würde der Widerstand nicht vorhanden sein hätten der Ausgang einen nicht definierten Zustand oder halt 0V. Der definierte Zustand von 3,3V wird durch den Widerstand festgelegt. Der Widerstand wird auch „Pullup“ bezeichnet.
Hallo,
hat jemand dieses Projekt aktuell an einem Pi2 oder Pi3 funktionstüchtig zum laufen gebracht?
Habe schon vieles probiert, aber eine Zeit wurde bisher nie geliefert.
Das Modul ist zumindest in Ordnung, da es seriell angeschlossen an einem PC die Uhrzeit liefert.
Hallo Ricky,
Da ich mich mit DCF77 bereits Jahre beschäftige und mit RS232 nie glücklich wurde, habe ich für den RaspberryPi selbst ein C-Programm geschrieben, das das Signal des Empfängers direkt an einem GPIO auswertet.
Download des Sourcecode: http://lepanto.at/download/dcf77_clock.c
Kompilieren mit:
$ gcc -Wall -pedantic -std=c99 -lrt -lwiringPi -o dcf77_clock dcf77_clock.c
Wie du siehst, braucht man dazu die Library ‚wiringPi‘, die aber schon im Raspian enthalten ist.
# aptitude install wiringpi
Die Library ‚rt‘ (steht für ‚realtime‘) ist im Basissystem schon installiert.
Mit dem Parameter -h erhält man eine kurze Hilfe.
$ ./dcf77_clock -h
Usage: ./dcf77_clock [-h] [-D] -g [-g ] [-u ] [-f ] [-t ]
-h this helptext
-D debbuging (don’t fork to background)
-g GPIO-pin (or pins) that is connection to the receiver
-u unit-number of NTP shared memory driver
-f fifoname to send additional data (bit 1 to 14)
-t tolerance in milliseconds (default: 25)
Der Parameter ‚-g ‚ muß einmal vorhanden sein, kann auch ein
zweites mal vorkommen. Damit wird der GPIO-Pin angegeben auf dem das
Signal anliegt. Wenn man beim Conrad-Empfänger beide Signale an den
RaspberryPi anklemmt, kann man den Parameter zweimal angeben.
Das Programm verwendet die WiringPi-Nummerierung.
–> https://pinout.xyz/pinout/wiringpi
Der Parameter ‚-u ‚ ist die ‚Shared Memory Unit‘ die das Programm
verwenden soll, um den NTPD die Zeitdaten zu übergeben.
In der ntp.conf wird das mit den folgenden Zeilen eingerichtet:
server 127.127.28.0 minpoll 6 maxpoll 6
fudge 127.127.28.0 time1 0.030 refid DCF
Der ‚time1‘ Parameter liegt bei mir etwa bei 0.030. Du kannst den auch weglassen und selbst messen welchen Versatz dein Empfänger hat. Anleitungen wie man den Versatz eines Empfängers herausfindet, gibt es genug im Netz.
Wichtig ist hier bei der Pseudo-IP (127.127.28.x / die 28 steht für Shared Memory) die letzte Nummer. Das ist die Shared Memory Unit.
Die Unit 0 und 1 können nur von root beschrieben und gelesen werden.
Alle weiteren auch von unprivilegierten Usern.
Leider muß das Programm als root laufen, da es sonst keinen Zugriff auf
die GPIOs bekommt, daher kann man auch Unit 0 und/oder 1 verwenden.
Der Parameter ‚-t ‚ legt die Toleranz fest, die die Flanken
aufweisen dürfen.
Das DCF77-Signal fällt exakt bei einer Sekunde auf 15% Signalstärke ab
(fallende Flanke). Nach 100ms (Bitwert: 0) bzw. 200ms (Bitwert: 1)
steigt es wieder auf 100% an (steigende Flanke).
Durch äußere Einflüsse oder etwas schlechtem Empfang weichen die Zeiten
etwas ab, meistens sind sie kürzer. Die Toleranz gibt an um wieviel
Millisekunden die Flanken versetzt sein dürfen, damit es noch als gültig
gewertet wird.
Mit dem Parameter ‚-f ‚ kann man eine FIFO (named pipe) angeben,
an die die extra Daten übergeben werden, wenn man diese Auswerten will.
Seit Jahren werden in diesen Extrabits Wettervorhersagen von der Firma
MeteoTime übertragen. Diese Daten sind verschlüsselt und man braucht
offiziell einen Microchip der Firma HKW um diese zu entschlüsseln.
(Damit habe ich mich vor 2 Jahren beschäftigt)
Es gab auch vor Jahren einen Versuch Katastrophenalarm darüber
umzusetzen. Ob das nun aktiv betrieben wird, weiss ich leider nicht und
auch das Protocol wurde nie öffendlich bis ins Detail beschrieben.
Übrigens:
Bei allen Schaltungen im Netz (wie auch hier) wird ein PullUp-Widerstand verwendet.
Das ist bei diesem Programm nicht erforderlich, da es die eingebauten
PullUp-Widerstände vom RaspberryPi verwendet.
Wichtig:
Da die GPIOs nur bis 3V3 spannungsfest sind, sollte man den Empfänger nur mit 3V3 versorgen.
Die meisten Empfänger arbeiten aber schon ab 1V2 bzw. 2V5, also ist das kein Problem.
Bei mir laufen aktuell 3 Empfänger völlig ohne Probleme an einem RaspberryPi (für jeden Empfänger ein eigener GPIO und Prozess, und jeder Prozess mit einer anderen Unit).
Danke, hat funktioniert :-)
Danke für das tolle Tool, wo der ntpd kein sauberes DCF77 Signal ausgelesen bekommt klappt es mit deinem ShardMemoryInterface direkt.
Auch von mir vielen Dank für das Tool und die Erklärung dazu!
Leider ist meine Systemzeit beim booten in der Regel mehr als 20 min daneben, weshalb das Programm folgende Meldung bringt: „Systemclock is more than 20 minutes off time. Set it hard!“
Anscheinend umgeht das Programm das setzen der Systemzeit in diesem Fall, was für meine Anwendung leider weniger wünschenswert ist.
Ich hab schon versucht den Code so abzuändern, daß in jedem Fall die Zeit gesetzt wird – hab’s aber anscheinend nicht richtig verstanden :-/
Könnte mir dabei jemand weiterhelfen?
Vielen lieben Dank schon mal und frohe Ostern!
Zeile 1097 ist auskommentiert. Nimm mal das ‚//‘ am Anfang weg und kompilier nochmal.
Das Problem ist, wenn die Zeit mehr als ca. 20min abweicht, beendet sich NTP weil ein time-trift um 20min auszugleichen zu lange dauern würde.
In Zeile 1097 wird die Zeit sofort hart gesetzt (also nicht getriftet).
Soweit ich mich erinnere habe ich das aber auskommentiert weil der NTP die Systemzeit kontrollieren soll und er sich ebenfalls beendet wenn ihm unterm Hintern die Systemzeit umgestellt wird.
Aber ein Versuch ist es wert. Eventuell läuft NTP weiter, ist ja schon eine Zeit lang her und das Verhalten könnte sich geändert haben.
Schau Dir auch mal die Optionen vom NTP an, eventuell lässt der sich so einstellt, daß er sich nicht beendet und den Zeitsprung akzeptiert.
Hallo zusammen,
ich habe diesen Beitrag schon einige male durchgelesen. Bin gerade dabei einen Raspi 3 b+ als Zeitserver zu basteln aber wie es auch ist…. Läuft nicht! DCF77 Modul von Conrad angeschlossen (laut beschreibung weiter oben), die /etc/ntp.conf angepasst und siehe da, es funktionierte nicht. Dann habe ich in denn Kommentaren die Hinweise von Sascha gelesen :-) habe es so wie von Sascha beschrieben konfiguriert und das Ergebnis war:
/home# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
SHM(0) .DCF. 0 l – 64 0 0.000 0.000 0.000
de.pool.ntp.org .POOL. 16 p – 64 0 0.000 0.000 0.000
ptbtime1.ptb.de .SHM. 1 u 32 64 377 26.531 0.411 10.841
ptbtime2.ptb.de .PTB. 1 u 21 64 377 25.260 -0.689 2.953
ptbtime3.ptb.de .PTB. 1 u 26 64 377 24.977 -0.708 7.802
+ntp2.wtnet.de 10.129.40.211 2 u 18 64 377 27.061 0.270 2.212
*alpha.rueckgr.a 131.188.3.222 2 u 21 64 377 21.502 0.406 5.548
+spacys.de 130.149.17.8 2 u 28 64 377 21.467 0.099 7.212
+swanhild.pflug- 124.216.164.14 2 u 22 64 377 20.177 -2.811 5.259
+panel1.web2.clu 131.188.3.223 2 u 8 64 377 36.333 -4.391 8.823
+ns2.customer-re 192.53.103.108 2 u 5 64 377 23.366 -1.317 5.203
+evilhannie.eu 213.239.239.165 3 u 12 64 377 21.258 0.392 4.928
cat /var/log/ntpd
12 Nov 13:44:50 ntpd[704]: Listening on routing socket on fd #22 for interface updates
12 Nov 13:44:50 ntpd[704]: 0.0.0.0 c01d 0d kern kernel time sync enabled
12 Nov 13:44:50 ntpd[704]: 0.0.0.0 c012 02 freq_set kernel -9.536 PPM
12 Nov 13:44:50 ntpd[704]: 0.0.0.0 c016 06 restart
12 Nov 13:44:50 ntpd[704]: DNS ptbtime1.ptb.de -> 192.53.103.108
12 Nov 13:44:50 ntpd[704]: DNS ptbtime2.ptb.de -> 192.53.103.104
12 Nov 13:44:50 ntpd[704]: DNS ptbtime3.ptb.de -> 192.53.103.103
12 Nov 13:44:52 ntpd[704]: Soliciting pool server 213.209.109.44
12 Nov 13:44:53 ntpd[704]: Soliciting pool server 78.46.53.2
12 Nov 13:44:54 ntpd[704]: Soliciting pool server 178.63.9.212
12 Nov 13:44:55 ntpd[704]: Soliciting pool server 62.75.202.83
12 Nov 13:47:13 ntpd[704]: Soliciting pool server 85.25.210.112
12 Nov 13:47:14 ntpd[704]: Soliciting pool server 62.116.130.3
12 Nov 13:47:15 ntpd[704]: Soliciting pool server 176.9.42.71
12 Nov 13:47:16 ntpd[704]: Soliciting pool server 131.234.137.64
12 Nov 13:48:09 ntpd[704]: 0.0.0.0 c615 05 clock_sync
cat /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
logfile /var/log/ntpd
logconfig =all
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool:
#pool 0.debian.pool.ntp.org iburst noselect
#pool 1.debian.pool.ntp.org iburst noselect
#pool 2.debian.pool.ntp.org iburst noselect
#pool 3.debian.pool.ntp.org iburst noselect
#DCF77 Modul
server 127.127.28.0 minpoll 6 maxpoll 6
fudge 127.127.28.0 time1 0.030 refid DCF
#server 127.127.8.0 mode 5 iburst prefer
#fudge 127.127.8.0 time1 0.869573 stratum 1 refid DCF
pool de.pool.ntp.org minpoll 6 maxpoll 6
#Dient nur zur berechnung der fudgetime
server ptbtime1.ptb.de noselect
server ptbtime2.ptb.de noselect
server ptbtime3.ptb.de noselect
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page
# might also be helpful.
#
# Note that „restrict“ applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.
# By default, exchange time with everybody, but don’t allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
#restrict -6 default kod notrap nomodify nopeer noquery
#restrict 192.168.43.0 mask 255.255.255.0 nomodify notrap
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
# Needed for adding pool entries
restrict source notrap nomodify noquery
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255
# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
Ich würde mich über jede Hilfe freuen….
@s4nt4
Ich habe das selbe Probleme, am Pi 3b+. will der DCF77-Empfänger ( von Reichelt, baugleich dem Conrad ) nicht laufen.
Der Empfänger selber liefert Signale, nur der Pi erkennt die scheinbar nicht.
bei einem ntpq -c as -c cv -c rv -p 127.0.0.1. bekomme ich:
..
associd=0 status=0000 no events, clk_unspec,
device=“RAW DCF77 CODE (Conrad DCF77 receiver module)“, timecode=,
poll=4, noreply=0, badformat=0, baddata=0, fudgetime1=292.000, stratum=0,
refid=DCFa, flags=0, refclock_time=““, refclock_status=““,
refclock_format=“RAW DCF77 Timecode“,
..
Bei Timecode müsste die Bits erscheinen.
Jemand eine Idee, was das sein kann. Ich bin ja schon kurz davor, auf GPS umzusteigen.
@Thomas
ich bin schon ein wenig weiter… meine Ausgabe zeigt mir folgendes:
bei einem ntpq -c as -c cv -c rv -p 127.0.0.1. bekomme ich:
associd=0 status=0012 1 event, clk_bad_format,
device=“RAW DCF77 CODE (Conrad DCF77 receiver module)“,
timecode=“###############RADMLS1248124P124812P1248121241248112481248P??“,
poll=16, noreply=0, badformat=1, baddata=0, fudgetime1=292.000,
stratum=0, refid=DCFa, flags=0, refclock_time=““,
refclock_status=““, refclock_format=“RAW DCF77 Timecode“,
refclock_states=“*BAD FORMAT: 00:16:39 (100.00%); running time: 00:16:39″
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version=“ntpd 4.2.8p10@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1)“,
processor=“armv7l“, system=“Linux/4.14.79-v7+“, leap=11, stratum=16,
precision=-21, rootdelay=0.000, rootdisp=14.985, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
clock=df9929b1.f8e7e923 Fri, Nov 16 2018 12:34:09.972, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
GENERIC(0) .DCFa. 0 l – 64 0 0.000 0.000 0.000
de.pool.ntp.org .POOL. 16 p – 64 0 0.000 0.000 0.000
ptbtime1.ptb.de .SHM. 1 u 18 64 377 25.746 3607947 2.743
ptbtime2.ptb.de .PTB. 1 u 7 64 377 26.466 3607946 3.083
ptbtime3.ptb.de .PTB. 1 u 14 64 377 26.190 3607947 2.874
Beim: tail -f -n 100 /var/log/syslog | grep ntpd
Nov 16 12:36:37 ccop117 ntpd[523]: parse: convert_rawdcf: start bit / parity check FAILED for „###############RADMLS1248124P124812P1248121241248112481248P??“
Heißt aslo:
# alle Bits sind angekommen, aber der Paritäts-Check ist fehlgeschlagen
Frage: Was mache ich da falsch? Oder muss es noch decodiert werden????
@Tomas: zur deiner Frage „nur der Pi erkennt die scheinbar nicht.“: ich habe den ntp in die Gruppe tty UND dialout hinzugefügt, dann denn GPIO 15 (PIN10 auf dem Raspi) auf IN gesetzt, dannach bekam der DCF seinen timecode!
@Thomas
Beim Raspi 3+ ist das „ttyAMA0“ jetzt „ttyS0“ („0=Null“ nicht mit „o=oh“ verwechseln)
@s4nt4
könntest du mal deine /boot/cmdline.txt. posten ?
Ich habe auf einer Webseite ein kleines Script gefunden, welches die Impulse der DCF77 mitliest und anzeigen kann ( auch auf einem Port ausgeben um eine LED anzuschliessen ) , da kommt ziemlicher Müll raus.
Den Tip von dir probiere ich morgen mal direkt aus.
Ich habe gerade eine RTC-Baustein angeschlossen und installiert, der nutzt meine Ports nun auf dem Pi
Hi Thomas,
hier meine boot conf. ich bin noch am Herumprobieren, kriege aber die Signale nicht ausgewertet.
Timecode habe ich bekommen, den parity check failed aber nicht weg bekommen.
Ich komm nicht weiter und stehe kurz vorm scheitern des Projektes.
Ich hoffe, dass es sich jemand findet der diese Thematik hatte und das Problem behoben hat.
um jeden Rat wäre ich sehr dankbar!!
root@xxx:/home# cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default „safe“ mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display’s size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
enable_uart=1
#core_freq=250
init_uart_baud=9600
#dtoverlay=pi3-miniuart-bt
#enable_LOCAL-CLOCK=1
#enable_parse-clocks=1
#enable_SHM=1
#enable_NMEA=1
Hallo,
danke, aber ich meinte die Datei. /boot/cmdline.txt. :)
Im Moment habe ich auch keine Idee, warum das Zeitsignal nicht ausgewertet wird. Hab schon einen andere RasPi genommen ( 3. stat 3b+ ), aber kein Unterschied.
Das Script, welches ich auf einer Webseite gefunden habe, zeit die Impulse auf dem Port an, aber irgentwie klappt die Auswertung nicht sauber, da kommt nur Müll raus.
Ich bin derzeit auch in der Überlegung, statt DFC77 doch GPS zu nehmen oder nur reine Internet-Zeitserver + einer Hardware-RTC ( die funktioniert wunderbar ).
Hab eine RTC vom Typ „DS3231 für RasPi“ für wenige Euros beim Onlineauktionshaus bestellt, lässt sich direkt auf den GPIO-Port aufsteckt, etwas Konfig ( Google war mein Freund ) und fertig.
@Thomas,
die /Boot/cmdline.txt ist bei mir unverändert. Die Einstellung über „raspi-config“ „nr 5 – serial“ auf „nein“ reicht dazu aus.
@ Thomas,
die Recherche geht auf einem Raspi-Forum weiter.
Hier der link:
https://forum-raspberrypi.de/forum/thread/35437-raspberry-pi-dcf77-pollin/?postID=298085&highlight=dcf77%2BRaspi%2B3#post355355
Am Fuß der Seite kommt das interessante zum Thema Rpi3