Hallo Forum,
für ein Projekt programmiere ich gerade an einem Uhrzeit-Empfänger (DCF
77).
Der Empfänger soll über I2C ansprechbar sein und eine möglichst genaue
Uhrzeit zurückgeben.
Auf der Platine befinden sich also:
- DCF77-Empfänger, Zeit läuft bei gestörtem Empfang per Timer weiter
- RTC-Modul, kann bei Bedarf pro Sekunde 1 Interrupt auslösen
Somit habe ich auch zwei Uhrzeiten, die irgendwie miteinander
synchronisiert werden müssen.
Beim Start des Moduls und bei gestörtem DCF77-Empfang soll die Zeit aus
dem RTC-Modul als Zeitbasis genutzt werden.
Ist der Empfang OK, soll die (vermutlich genauere) DCF77-Zeit als
Systemzeit gewählt werden.
Jetzt stellt sich mir nur die Frage, wie ich die beiden Zeiten möglichst
optimal verknüpfe. Dazu sind mir bis jetzt zwei Möglichkeiten
eingefallen:
Möglichkeit 1:
- Beim Start werden Zeit & Datum aus dem RTC-Modul geladen
- Diese Werte werden als Startwert für den DCF77-Empfang verwendet
- Der Empfänger zählt automatisch (per Timer) die Zeit hoch
- Wurde die Zeit korrekt empfangen, wird z.B. täglich die Abweichung des
RTC-Moduls geprüft und ggf. justiert
Möglichkeit 2:
- Das RTC-Modul löst pro Sekunde einen Interrupt aus. Im Interrupt wird
die RTC-Zeit ausgelesen.
- Besteht kein DCF77-Empfang, wird die Zeit vom RTC zurückgegeben
- Wurden DCF77-Daten empfangen, wird die Zeit vom DCF77-Modul benutzt
- Die Zeit wird weiterhin vom RTC-Modul abgerufen und als Referenz
benutzt. Sprünge o.ä. im DCF77-Signal lassen sich so erkennen und die
Daten werden verworfen.
- 1x täglich wird das RTC-Modul bei Bedarf justiert.
Beide Möglichkeiten haben ihre Vor- und Nachteile.
Möglichkeit 2 ist (vermutlich) genauer und fängt Fehler besser ab, dafür
wird das RTC-Modul ständig gepollt. Dadurch wäre aber auch ständig eine
aktuelle Zeit & Datum verfügbar, auch wenn überhaupt kein Funksignal
reinkommt.
Allgemein ist der Aufwand leider viel höher.
Möglichkeit 1 lässt sich einfacher umsetzen, unter Umständen ist die
Zeit aber ungenau. Nach dem einmaligem Auslesen läuft die Zeit nur durch
einen Timer im Atmega weiter, d.h. nach einiger Zeit können Abweichungen
auftreten.
Fehlt der Empfang komplett, wird das Datum auch nicht aktualisiert
(mangels Kalenderfunktion, nach 24 Stunden beginnt der Timer einfach
wieder bei 0)
Wie würde ihr soetwas umsetzen?
Gerne können auch komplett andere Vorschläge kommen!
Schonmal vielen Dank für eure Anregungen!
Hallo,
wie immer du synchronisierst, es besteht die Möglichkeit, dass für die
Anwendung Zeitpunkte übersprungen werden. Dabei ist es letzlich auch
egal, ob es sich um ms handelt oder wie beim Neustart um Jahre. Du must
auf jeden Fall dafür sorgen (auch in deiner Anwendungssoftware), dass
z.B. Messdaten für den Zeitpunkt 13:10 auch erfasst werden, wenn dieser
Zeitpunkt durch die Synchronisation zufällig übersprungen wurde; und es
dürfen keine 2 Messwerte entstehen, wenn die Zeit zurückgesetzt wurde.
Dafür muss man allerdings eine Schwelle festsetzen, so dass nicht
Messwerte für Wochen oder Monate nachträglich erfasst werden.
Die Sache ist also keineswegs trivial, auch ganz ohne Einstein.
Gruss Reinhard
Das hängt von der geforderten Auflösung und Genauigkeit ab.
Für normale Anwendungen, bei welcher die Urzeit auf nur 1 Sekunde
aufgelöst werdden muss, würde ich ganz klar die Uhrzeit der DCF den
Vorzug geben, die RTC Zeit fortlaufend damit syncronisieren, und bei
Ausfall der DCF Zeit auf die RTC Zeit zurückgreifen. Die RTC Zeit kann
dann nicht soviel weglaufen, es sei denn die DCF Zeit fällt tagelang
aus.
Sind die Anforderungen extrem hoch würde ich mit der Frequenz des DCF
Signals einen Rubidium Frequenznormal synchronisieren ( Die PLL hätte
dann eine Regelzeitkonstante von Tagen ) und aus der Rubidiumfrequenz
durch entsprechende Teilung meine Zeit generieren. Da wird dann auch die
Zeitsprünge zwischen ( mit DCF ) und ( ohne DCF ) verschmerzbar bleiben,
sofern man dafür sorgt, das bei Ausfall der DCF die Regelspannung des
Rubidiumnormals nicht verrissen wird.
Vielleicht reicht ja die Stabilität und Genauigkeit des
Rubidiumfrequenznormales alleine ja schon aus , so das man auf die DCF
ganz verzichten kann. Wir reden ja immerhin von einer Frequenzabweichung
von maximal 10exp-9 in der Regel sogar noch weit besser.
Und so teuer sind diese Teile ja auch nicht mehr.
Ralph Berres
Naahh, das macht man anders. Die RTC wird zum DCF synchronisiert und
nicht einfach überschrieben. Gelesen wird immer die RTC-Zeit. Diese wird
mit dem (korrekt empfangenen) DCF-Telegramm verglichen. Ist die RTC zu
langsam, werden pro Minute 1..2 Hundertstel addiert. Ist sie zu schnell,
werden 1..2 Hundertstel abgezogen. Damit gleitet die RTC der Normalzeit
hinterher. Die Abweichung ist dabei nur minimal. Vorraussetzung ist
dabei ein RTC-Chip mit Hundertstel-Sekunden-Teilung.
Ralph Berres schrieb:> die RTC Zeit fortlaufend damit syncronisieren, und bei>> Ausfall der DCF Zeit auf die RTC Zeit zurückgreifen.Knut Ballhause schrieb:> Naahh, das macht man anders. Die RTC wird zum DCF synchronisiert und>> nicht einfach überschrieben. Gelesen wird immer die RTC-Zeit.
Schreibe ich doch oben. Einziger Unterschied ist das ich auf die RTC
Zeit nur zurückgreifen würde, wenn das DCF ausfällt. Der Zeitsprung
dürfte beim überschreiben der RTC Zeit geringer sein als wenn die RTC
Zeit 2 /hundertstel hinterher hinkt, da bis zum Ausfall der DCF die Zeit
der RTC die selbe ist.
Ralph Berres
Vielleicht schreibt der TE erst mal, was er sich unter "eine möglichst
genaue
Uhrzeit zurückgeben." vorstellt.
Dieser Satz konkurriert nämlich mit der Aussage: "- 1x täglich wird das
RTC-Modul bei Bedarf justiert."
Wofür soll die Uhrzeit verwendet werden?
Ralph Berres schrieb:> Einziger Unterschied ist das ich auf die RTC> Zeit nur zurückgreifen würde, wenn das DCF ausfällt.
Das ist nicht trivial, wie willst Du einen Ausfall erkennen?
Das Signal kann ja gestört sein. Das weißt Du aber erst hinterher, wenn
das Paket komplett ist und durch die Prüfung fällt.
Deshalb nimmt man intern immer die RTC-Information zur weiteren
Verwendung.
Und ein korrektes DCF-77 Paket synchronisiert die RTC.
Die RTC kann auch besser auflösen, z.B. 1ms oder 10ms Schritte.
RTC mit Datumsfunktion und Sommerzeit ist auch keine Hexerei.
Peter
Peter Dannegger schrieb:>Das Signal kann ja gestört sein. Das weißt Du aber erst hinterher, wenn>das Paket komplett ist und durch die Prüfung fällt.> Deshalb nimmt man intern immer die RTC-Information zur weiteren> Verwendung.> Und ein korrektes DCF-77 Paket synchronisiert die RTC.
Genau so.
Peter Dannegger schrieb:> Das ist nicht trivial, wie willst Du einen Ausfall erkennen?
Man kann die 77,5 KHz auf einen retriggerbaren Monoflop geben. Die
Verzögrungszeit ist etwas länger als die Periodendauer des 77,5 KHZ
Trägers. Wenn der Träger ausfällt, wird der Monoflop nicht mehr
getriggert, und das Q Signal geht auf 0. Im Normalfall wird das Monoflop
nach jeder Periode neu getriggert und das Q Signal bleibt auf 1.
So habe ich die Ausfallserkennung in meinen DCF Frequenznormal gelöst.
Ralph Berres
Ralph Berres schrieb:> Man kann die 77,5 KHz auf einen retriggerbaren Monoflop geben. Die> Verzögrungszeit ist etwas länger als die Periodendauer des 77,5 KHZ> Trägers.
Bei einem DCF-Modul hast Du keinen Zugriff auf den Träger.
Moin,
besten Dank für eure Antworten!
Hier mal ein paar mehr Details zu der Hardware:
- DCF77-Modul: Standard-Modul von Conrad, am Ausgang liegen nur die
Daten an
- RTC-Modul: DS1307 - Auflösung 1 Sekunde. Der Taktausgang (einstellbar
auf 1Hz, 4.xx, 8.xx und 32.xx kHz) geht auf einen Interrupt-Pin
- Controller: Atmega 8 @ 4 MHz (externer Quarzoszillator)
- Schnittstellen:
intern Software-I2C und Interrupt-Eingänge für RTC und DCF77
extern I2C (Master oder Slave je nach Einstellung), RS232 TTL &
PC-Level
(später evtl. noch 1 Hz Taktsignal)
Als Anwendung schwebt mir vor, einfach eine brauchbare Zeitbasis für
beliebige Projekte zur Verfügung zu stellen.
Definition von brauchbar:
Es geht nicht um Auflösungen im ms-Bereich!
Wichtig ist, dass die Uhrzeit möglichst schnell nach dem Einschalten
verfügbar ist.
Außerdem soll sie mit der tatsächlichen Ist-Zeit übereinstimmen.
Abweichungen von z.B. 5 Sekunden wären auch noch OK, sollten aber
eigentlich nicht vorkommen.
Bei der Synchronisation darf die Zeit auch um z.B. 1-2 Sekunden
springen, das sollte aber nur im Notfall vorkommen...
