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!
Ist das DCF-77 Paket gültig, wird die interne RTC überschrieben: Beitrag "DCF77 Uhr in C mit ATtiny26" Peter
Wie wäre es mit einer Mischung aus 1 und 2. Du nimmst 1, syncronisierst allerdings jede 10min mit dem RTC.
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...
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.