Ein kostengünstiger NTP-Zeitserver mit DCF77 Empfänger

Inhalt

Vorweg ein paar Erfahrungen

DCF77 Empfänger für den Parallelport von Conrad Electronic

Ich hatte lange Zeit das Conrad-Electronic DCF77 Parallelport-Modul zusammen mit dem Linux Kerneltreiber pcfclock von Andreas Vögele am laufen, was aber einige Probleme mit sich brachte. Die Uhr hat recht viel Intelligenz, was bedeutet, daß sich die Uhr nur nachts nach dem DCF77 Signal stellt und sonst über einen internen Quarz läuft. Das ist aber nicht sehr vorteilhaft als Zeitreferenz für NTP, da die Uhr dann zwangsweise Sprünge macht, wenn sie nachgestellt wird.

Noch mehr Probleme macht ein stündlicher Sprung. Dabei entfernt sich die Uhr pünktlich zur vollen Stunde etwa 150msec von der Kernelzeit, was NTP oft dazu veranlasst, sich mit der Syslog-Meldung

Nov 29 11:47:10 homer ntpd[110]: synchronisation lost
Nov 29 12:43:15 homer ntpd[110]: time reset -0.185182 s

von der Uhr zu verabschieden. Wenn man nur diese Uhr hat und keine Standleitung ins Internet, ist das natürlich nicht so gut. Ich habe mir den Quellcode des Kerneltreibers schon angesehen und auch den NTP-Clocktreiber dazu, bin aber zu dem Schluß gekommen, daß die Uhr diese Sprünge verursacht und diese Peaks nur mit einer Art Software-Tiefpass rauszubekommen sind:

Offset als Diagramm, mit sichtbaren Sprüngen

Da mir persönlich eine dauerhafte Funkzeit aber lieber ist und das mit dem Parallelport-Modul wohl nicht so einfach hinzubekommen ist, habe ich mich entschieden eine "Always-On-Air"-Funkuhr zu bauen...

Diese Anleitung gibts doch schon x-mal...

Das ist richtig, aber ich mußte mir von zig Seiten die Informationen zusammensammeln. Nach einiger Zeit Recherche stellte sich außerdem heraus, daß das oft erwähnte Modul mit Digitalanzeige und herausgeführtem DCF-Signal für ca. 20 DM oder jetzt 10 Euro nicht mehr lieferbar ist (Conrad Bestellnr. 641960-44). Andere Anleitungen sind mehr DOS/Windows orientiert oder schließen das Gerät an Game- oder Parallelport an. Ich wähle bewußt das serielle Modul, da so auch problemlos der refclock_parse Treiber von NTP verwendet werden kann, der das DCF-Signal direkt von der seriellen Schnittstelle abgreift und verarbeitet.

Schaltung

Die Schaltung besteht aus drei Komponenten, dem DCF77-Modul, der Spannungsgewinnung aus der seriellen Schnittstelle und aus dem Umsetzer auf das Spannungsniveau der seriellen Schnittstelle (die ja für LOW Spannungen im Bereich 3...30 Volt und für HIGH Spannungen im Bereich -3...-30 Volt benutzt).

Die Spannung wird aus den zwei Signalen DTR und RTS gewonnen, von denen immer mindestens eines eine positive Spannung führt. Solange am seriellen Port keine Software arbeitet, sind DTR und RTS auf HIGH, führen also negative Spannung. Die NTP-Software setzt jedoch einen bzw. beide Pins (DTR, RTS) auf LOW und setzt damit eine positive Spannung, was bewirkt, daß wir +5V nach dem Widerstand und vor der Zenerdiode abgreifen können (siehe Schaltung). Damit können wir den Baustein MAX232 und den Rest der Bauteile mit einer Spannung von 5V versorgen.

Leider habe ich im Betrieb nur eine Spannung von etwa 3V auf der Schaltung, da der Stromverbrauch die Spannung am seriellen Port anscheinend so weit einbrechen läßt. Die Schaltung funktioniert zwar auch so, allerdings sind die LEDs sehr dunkel. Wenn man die LEDs wegläßt, könnte man den Stromverbrauch um etwa 2mA senken, allerdings hat man dann keine Kontrolle über den Zustand des Moduls. Eine weitere Möglichkeit, wäre die Schaltung über einen USB-Stecker zu speisen. USB liefert bis zu 500mA. Allerdings braucht man dann ein zweites Kabel und eine Sun oder eine HP hat meist keinen USB-Stecker. Als letzte Möglichkeit schließt man einfach ein externes Netzteil an.

DCF77 Receiver Modul von Conrad Electronic

Als DCF77-Empfängermodul kommt das Modul von Conrad-Electronic zum Einsatz, das unter der Bestellnummer 641138 zu haben ist. Das Modul kostet derzeit 9,95 Euro und kann meines Wissens nur bei Conrad bezogen werden. Die restlichen Bauteile müßten in jedem Elektronikladen zu bekommen sein.

Bei ELV gibts ein ähnliches Modul das 9,95 Euro kostet. Ich habe allerdings keine Ahnung, ob es genauso funktioniert wie das Conrad-Modul...

Die dritte Komponente setzt den geringen Pegel aus dem DCF-Modul um auf RS232-Pegel. Hier wird ein IC vom Typ MAX232 verwendet, das genau diese Aufgabe erledigt. Rundherum werden noch ein paar Kondenstatoren geschaltet, die benötigt werden, damit das IC intern mit einem Spannungsinverter und einem Spannungsdoppler die relativ hohen postiven bzw. negativen Spannungen erzeugen kann.

Schaltplan mit MAX232 Baustein

Die Schaltung kann relativ einfach auf einer Lochrasterplatine aufgebaut werden. Am besten man baut sich zuerst den unteren Teil der Schaltung auf, um sicherzugehen daß die Spannung von +5V erzeugt wird. Die LED zeigt das Anliegen von 5 Volt an.

Sollte die LED nicht leuchten, dann liegt weder an DTR noch an RTS ein LOW, also ein positiver Pegel an. Wenn man die Schaltung ohne Software an die serielle Schnittstelle anschließt, dann bekommt man die Spannung nicht! Ich habe das ganze mit mgetty ttyS1 getestet. Auch ein Terminalprogramm wie Minicom müßte die Pegel auf LOW ziehen, damit man die positiven Spannungen erhält. Später werden wir NTP so konfigurieren, daß es zumindest einen der beiden Pins auf LOW zieht.

Hinweis: Mir wurde mittlerweile schon oft mitgeteilt, dass es Probleme gibt, die Spannung bzw. den Strom aus der seriellen Schnittstelle zu beziehen. Mehr dazu siehe unten im Anhang.

Stückliste:

Danke an dieser Stelle an Alexander Meier vom Fachbereich Elektrotechnik an der Fachhochschule Regensburg, der diese Schaltung entworfen hat und mir bei den Hardware-Problemen immer eine große Hilfe war.

Konfiguration NTP

Die NTP-Software bekommt man am besten direkt bei www.ntp.org, wo auch die Doku im HTML-Format liegt. Manpages gibts leider bis heute nicht, man muß also einen Browser zur Hand haben.

Der Reference Clock Driver, der das RAWDCF Signal verarbeiten kann, heißt refclock_parse. Dieser Treiber ist in der Datei refclock_parse.c zu finden und ist für eine ganze Reihe serieller Uhren zuständig. Wir brauchen nur den Treiber für das reine DCF77 Signal. Dazu kompilieren wir die NTP-Software mit folgender Option:

root@homer:~/ntp-4.1.1a # ./configure --enable-RAWDCF
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
...

Wer weitere Optionen braucht, kann sie natürlich zusätzlich einkompilieren, dies ist nur die Unterstützung für die DCF77-Uhr. Konfiguriert wird die Uhr mit der folgenden Zeile:

server 127.127.8.n mode 5

n steht dabei für /dev/refclock-n, wobei diese Devices einfach symoblische Links auf die seriellen Schnittstellen sind.

Eine komplette Konfigurationsdatei könnte etwa so aussehen:

#
# File /etc/ntp.conf
#

# 
# RAWDCF Modul von Conrad an /dev/refclock-1
#
server 127.127.8.1 mode 5

logconfig all
driftfile /var/run/ntpd.drift

statsdir /var/log/ntp/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
statistics peerstats loopstats clockstats

# End of file

Für die Bedeutung der einzelnen Parameter sei auf die Online-Doku von www.ntp.org verwiesen. Zu erwähnen ist hier nur, daß die Uhr mindestens eine Minute braucht, um ein erstes Mal die korrekte Zeit zu liefern, da ein kompletter Datensatz bei DCF77 eine ganze Minute einnimmt. Die zahlreichen meldungen nach Starten des NTP-Daemons sind also kein Grund zur Beunruhigung. Nach ein paar Minuten sollte sich das Problem mit dem Auftauchen der Logmeldung clk_okay selber lösen:

19 May 12:45:19 ntpd[3884]: logging to file /var/log/ntp.log
19 May 12:45:19 ntpd[3884]: ntpd 4.1.1a@1.791 Sat May 18 10:43:46 CEST 2002 (1)
19 May 12:45:19 ntpd[3884]: signal_no_reset: signal 13 had flags 4000000
19 May 12:45:19 ntpd[3884]: precision = 19 usec
19 May 12:45:19 ntpd[3884]: kernel time discipline status 0040
19 May 12:45:19 ntpd[3884]: frequency initialized -1.053 from
			    /var/run/ntpd.drift
19 May 12:45:19 ntpd[3884]: system event 'event_restart' (0x01) status
                            'sync_alarm, sync_unspec, 1 event, event_unspec'
                            (0xc010)
19 May 12:45:26 ntpd[3884]: peer LOCAL(1) event 'event_reach' (0x84) status
                            'unreach, conf, 1 event, event_reach' (0x8014)
19 May 12:46:06 ntpd[3884]: parse: convert_rawdcf: INCOMPLETE DATA - time code
                            only has 47 bits
19 May 12:46:06 ntpd[3884]: PARSE receiver #1: conversion status "CONVERSION
                            FAILED; DATE ILLEGAL"
19 May 12:46:06 ntpd[3884]: PARSE receiver #1: interval for following error
                            message class is at least 00:01:00
19 May 12:46:06 ntpd[3884]: PARSE receiver #1: FAILED TIMECODE:
                            "----#--#-##---#R-D--S--4--24p1248-2p--4------1"
                            (check receiver configuration / cableling)
19 May 12:46:06 ntpd[3884]: clock GENERIC(1) event 'clk_baddate' (0x05)
19 May 12:46:06 ntpd[3884]: peer GENERIC(1) event 'event_peer_clock' (0x85)
                            status 'unreach, conf, 1 event, event_peer_clock'
                            (0x8015)
19 May 12:46:06 ntpd[3884]: system event 'event_clock_excptn' (0x07) status
                            'sync_alarm, sync_unspec, 2 events, event_restart'
                            (0xc021)
19 May 12:47:06 ntpd[3884]: PARSE receiver #1: packet format "RAW DCF77
                            Timecode"
19 May 12:47:06 ntpd[3884]: PARSE receiver #1: STATE CHANGE:  -> DST; TIME
                            CODE; (LEAP INDICATION; ANTENNA)
19 May 12:47:06 ntpd[3884]: PARSE receiver #1: SYNCHRONIZED
19 May 12:47:06 ntpd[3884]: clock GENERIC(1) event 'clk_okay' (0x00)
19 May 12:47:06 ntpd[3884]: peer GENERIC(1) event 'event_peer_clock' (0x85)
                            status 'unreach, conf, 2 events, event_peer_clock'
                            (0x8025)
19 May 12:47:06 ntpd[3884]: peer GENERIC(1) event 'event_reach' (0x84) status
                            'unreach, conf, 3 events, event_reach' (0x8034)

Endkontrolle

Und am Schluß kontrollieren wir natürlich das ganze anhand eines Graphen, woran man ganz deutlich sieht, daß diese Uhr "online" an der Zeit hängt und auch keine Sprünge macht, es sei denn, sie verliert über längere Zeit den Empfang. Der Offset ist außerdem sehr viel kleiner als bei der "intelligenten" Uhr:

Offset des DCF77 Empfängers als Diagramm

Allerdings wurde ich darauf hingewiesen, dass diese ca. 10 Millisekunden grossen Schwankungen immer noch viel zu gross sind. Allerdings ist das ein Linux-spezifisches Problem, das ich im Anhang aufgeführt habe.

Anhang und zusätzliche Problemchen

Linux low_latency am seriellen Port

Der eben gezeigte Plot zeigt immer noch relativ große Ausreisser, die man vermeiden kann, indem man den seriellen Port mit einem Zusatzflag low_latency konfiguriert. Ich habe einen Linux 2.4.20 Kernel, der dieses Problem hat. Danke für diesen Tip an Dr. Ralf Braun! Hier der Befehl, der dieses Flag auf dem ersten seriellen Port (PC-Hardware) setzt:

setserial `setserial -G /dev/ttyS0` low_latency

Nach Setzen dieses Flags am seriellen Port sieht der Plot endlich so aus, wie er sein sollte: Die Abweichungen bleiben in den meisten Fällen bei ca. einer Millisekunde.

Offset des DCF77 Empfängers als Diagramm mit low_latency

Probleme mit der Spannungsversorgung

Einige Male wurde mir berichtet, daß die Spannung aus der seriellen Schnittstelle nicht ausgereicht hat, die Schaltung zu versorgen. Die serielle Schnittstelle ist eben nicht dazu konzipiert, als Stromquelle zu arbeiten. Diese Probleme treten anscheinend vor allem bei Notebooks auf. Wer diese Uhr nachbauen will, müsste ein Messgerät zur Hand haben, um mit einem Widerstand die Spannungsfestigkeit des seriellen Ports zu messen zu können. Die Spannung sollte bei einem Strom von ca. 25mA nicht zu sehr einbrechen. Um die 5V sollten noch vorhanden sein.

Wer hier vor einem unlösbarem Problem steht, der kann

Das wars. Viel Spass beim nachbauen! Wer Verbesserungsvorschläge hat oder Kritik anbringen will - nur her damit! Wer Rechtschreibfehler findet, darf sie behalten

© 2002-2004 by Martin Opel