www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zwei Uhrzeiten synchronisieren


Autor: Leo-A. H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Peter Dannegger (peda)
Datum:

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

Beitrag "DCF77 Uhr in C mit ATtiny26"


Peter

Autor: Sam .. (sam1994)
Datum:

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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: HolgerT (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Leo-A. H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.