Forum: Mikrocontroller und Digitale Elektronik Zwei Uhrzeiten synchronisieren


von Leo-A. H. (Gast)


Lesenswert?

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!

von Peter D. (peda)


Lesenswert?

Ist das DCF-77 Paket gültig, wird die interne RTC überschrieben:

Beitrag "DCF77 Uhr in C mit ATtiny26"


Peter

von Sam .. (sam1994)


Lesenswert?

Wie wäre es mit einer Mischung aus 1 und 2.
Du nimmst 1, syncronisierst allerdings jede 10min mit dem RTC.

von Reinhard Kern (Gast)


Lesenswert?

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

von Ralph B. (rberres)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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.

von Ralph B. (rberres)


Lesenswert?

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

von HolgerT (Gast)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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.

von Ralph B. (rberres)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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.

von Leo-A. H. (Gast)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.