Raspberry Pi und DCF77 Empfänger von Conrad

/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

DCF77 Platine Beschriftung

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:

Raspberry Pi Pins und Belegung

(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)

DCF77 Platine

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"

21 Kommentare

  1. 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.

    1. 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ß!

  2. 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

    1. 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!

      1. 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.

  3. 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.

    1. 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).

      1. 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!

  4. 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.

  5. 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….

  6. @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.

    1. @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!

  7. @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

    1. 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

  8. 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.

    1. @Thomas,

      die /Boot/cmdline.txt ist bei mir unverändert. Die Einstellung über „raspi-config“ „nr 5 – serial“ auf „nein“ reicht dazu aus.

Schreibe einen Kommentar zu Marc Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert