DS3231 - ungenau?

Im Rahmen des Baus einer WordClock bin ich darüber gestolpert, dass mehrere Real Time Clock-Chips scheinbar grottenmäßig langsam laufen.

Um dem Phänomen auf die Spur zu kommen (und um der Aufforderung des ebay-Verkäufers nachzukommen, einen Nachweis für die Abweichungen in Wort und Bild zu liefern), habe ich ein Programm für einen Arduino Clone geschrieben, das die Uhrzeit zyklisch aus der angeschlossenen DS3231 RTC ausliest, auf einem LCD-Display anzeigt und auf der seriellen Schnittstelle an den Computer ausgibt. Parallel und “gleichzeitig” wird mittels DCF77 eine Vergleichszeit generiert, deren Werte ebenfalls auf dem Display und auf der seriellen Schnittstelle ausgegeben werden.

Ich sehe also immer beide Uhrzeiten in Echtzeit und habe die Möglichkeit, die Zeiten auf dem Computer in einer Log-Datei zu sammeln.

Mit diesem Setup kann ich nachweisen, dass offenbar alle mir zur Verfügung stehenden DS3231 RTC Chips ein Problem in Sachen Ganggenauigkeit haben, alle Chips verlieren im Laufe einer Nacht mehrere Minuten gegenüber der DCF77-geführten Vergleichszeit!

Im Internet findet sich ein Artikel bei AVR-Freaks zu diesem Thema. Hier wird die Vermutung geäußert, dass “billige China-Chips” auf sehr preiswerten RTC-Modulen keine Doppelpufferung der Zeitregister haben, die es ermöglichen würden, die Uhrzeit intern, während eines lesenden Zugriffs über I²C, ungestört weiterzuführen.

Im Datenblatt des DS3231 von Maxim ist beschrieben, dass genau diese doppelten Register vorhanden sind, um Probleme mit konkurrierendem Update der Register während eines Lese- oder Schreibzugriffs auf die Zeit-Register zu vermeiden (Stichwort atomare Zugriffe - es wäre unschön, würde man z.B. kurz vor Ende der 59. Sekunde einen Lesezugriff starten, dadurch die Sekundeninformation “59” bekommen, währenddessen wird aber die Zeit aktualisiert und beim nachfolgenden Zugriff auf die Minuten stehen die Sekunden bereits auf “00”, die Minuten sind um eine Minute erhöht gegenüber dem Zeitpunkt des Starts des Zugriffs auf die Sekunden. Die im Microcontroller angekommene Information läge dann um 59 Sekunden daneben. Durch die zusätzlichen Register wird das beschriebene Problem vermieden).

Allerdings steht nirgends explizit, dass die Uhr während eines Zugriffs ungestört weiter läuft, was der gemeine Anwender jedoch geneigt ist, zu glauben. Ich jedenfalls bin davon ausgegangen.


Die getesteten DS3231 Module sind:

verschiedene DS3231 Module

Links drei der fünf mir zur Verfügung stehenden Mini-Module, wie sie von verschiedenen Anbietern baugleich angeboten werden. Diese Module enthalten ausschließlich den DS3231 und die absolute Minimalbeschaltung zu dessen Betrieb sowie eine Lithium Primärzelle für die Pufferung.

Das erwähnte Minimum schließt ein, dass der weiter unten beschriebene SQW-Ausgang (Pin 3 des DS3231) nicht nach außen geführt ist, somit der Test ohne Änderung an der Schaltung nicht durchführbar ist. Zum Glück hat der Stecker einen unbenutzten Pin, der für die Bereitstellung des SQW-Signals genutzt werden kann. Der Umbau ist relativ simpel und kann einfach durchgeführt werden solange man im Besitz eines Lötkolbens mit feiner SMD-Spitze ist und eine ruhigen Hand hat. Die Verwendung einer Leucht-Lupe ist ebenfalls kein Fehler und kann hier nicht als Zeichen von Schwäche ausgelegt werden.

Mini-Modul mit DS3231

In der Mitte zwei Module mit gleichem Funktions- und Ausstattungsumfang wie die Mini-Module, allerdings ist die Platine einseitig bestückt, die Lithium-Zelle sitzt auf der Oberseite. Außerdem ist auf der Unterseite die Bestückung des seriellen EEPROMs vorgesehen, aber nicht ausgeführt. Zusätzlich ist eine LED verbaut, die bei Anliegen der Versorgungsspannung leuchtet, sowie ein Transistor mit Beschaltung, dessen Funktion ich nicht ergründen wollte.

mini-RTCpro Modul

Rechts schließlich ein Modul mit DS3231 und EEPROM, hier schon auf Doppelschichtkondensator umgebaut.

RTC-Modul mit umfangreichster Ausstattung

Ursprünglich sitzt auf der Unterseite dieses Moduls eine Halterung für eine Lithium-Knopfzelle CR2032, der Betrieb ist damit gegeben, aber die Langzeitstabilität ist ungeklärt. Hintergrund für diese Fragestellung ist die auf der Platine implementierte “Ladeschaltung” (ein Widerstand mit 200 Ohm in Serie mit einer 1N4148 Universaldiode). Wie die nicht aufladbare Primärzelle CR2032 mit einer permanent von außen angelegten Spannung umgeht ist unklar, in den gängigen Datenblättern zu diesen Knopfzellen wird jedoch davon abgeraten, die Zellen zu laden.

Betreibt man das Modul mit 3,3 V, kann man davon ausgehen, dass wegen der Vorwärtsspannung der Silizium-Diode von 0,7 V keine schädliche Spannung an der Knopfzelle ankommt. Der ebenfalls zulässige Betrieb des Moduls mit 5 V hingegen könnte (ich bin geneigt zu sagen müsste) Probleme erzeugen.

    Eine umfangreiche Untersuchung zu diesem Thema findet man hier, der Kollege baut Temperaturlogger für den Einsatz in Höhlen. Der uns interessierende Teil findet sich ziemlich genau in der Mitte der Seite unter der Überschrift “Addendum 2017-04-11 ”. Genaugenommen ist das schon fast das Ende des Artikels, denn die andere Hälfte der Seite sind Kommentare.

Um mich mit diesem Problem nicht befassen zu müssen, habe ich kurzerhand anstelle des Batteriehalters einen 0,1 F Doppelschicht-Kondensator mit 5,5 V Nennspannung eingebaut, der von der installierten Lademimik bei 5 V-Betrieb auf 3,8 V aufgeladen wird und die Uhr im Chip bei Stromausfall für mehrere Stunden versorgen kann.

Die Mini-Module von zwei unterschiedlichen ebay-Händlern sind im Übrigen mit DS3231M Chips bestückt, die beiden anderen Typen arbeiten mit DS3231SN Chips. Die “M”-Typen haben einen MEMS-Resonator als frequenzbestimmendes Glied an Bord, die anderen laufen mit temperaturkompensierten Kristall-Oszillatoren (TCXO). Beide Typen werden aber als “hochgenau” beworben und beschrieben, die Datenblatt-Werte geben sich in dieser Hinsicht nichts, ich gehe also von vergleichbar guten Werten aus.


Jetzt zum Testprogramm und dessen Verhalten:

Im Prinzip läuft alles in einer Schleife ab, der DCF77-Teil kümmert sich um die Dekodierung des Empfangssignals und stellt die Zeitinformation als “Timestamp”-Struktur zur Verfügung. Die RTC DS3231 wird zyklisch ausgelesen, deren Zeitinformation landet ebenfalls in einer “Timestamp”-Struktur. Die wesentlichen  Programmteile stammen aus der Implementierung der QlockThree, einer auf Github bereit gestellten Software zum Betrieb einer sogenannten WordClock, die die Zeitinformation in ganzen Worten darstellt.

Der Code wurde lediglich radikal auf das Wesentliche für die gestellte Aufgabe abgespeckt und die Ausgabe wurde auf LCD und serielle SS umgestrickt. Im Code sind noch Rudimente einer Menüführung und einer Statemachine vorhanden, diese Teile sind aber stillgelegt bzw. nicht ausprogrammiert.

Mit diesem Testprogramm hat sich bei allen mir zur Verfügung stehenden DS3231 Modulen eine weiter oben bereits beschriebene, mehr oder weniger stark ausgeprägte, Verlangsamung der Uhrzeit der RTC im Chip ergeben.

Da die Vermutung im Raum steht, dass die ungenaue Zeitführung in den DS3231 Chips durch das zyklische Pollen der I²C Schnittstelle der Chips hervorgerufen wird, habe ich das Programm so umgestellt, dass die Uhrzeit laufend in Variablen im µC geführt, und nur einmalig um Mitternacht aus der RTC aktualisiert wird.

Um dennoch eine verwertbare Genauigkeit der Uhrzeit zu erreichen, wird die Fortführung der Zeitinformation im µC durch das vom DS3231 zur Verfügung gestellte SQW-Signal getriggert. Das SQW-Signal basiert nicht auf Register-Zugriffen sondern wird in Hardware erzeugt und stört somit die RTC nicht (immer unter der Prämisse, dass die Annahme korrekt ist, dass sich die I²C-Zugriffe störend auswirken).

Dieses Signal muss bei der Initialisierung der RTC explizit eingeschaltet werden und kann bei den DS3231 auf verschiedene Frequenzen parametriert werden. Beim DS3231M ist es unveränderbar auf 1 Hz eingestellt. Die Frequenz dieses Signals ist direkt vom hochgenauen Quarz (bzw. dem MEMS -Oszillator des DS3231M) abgeleitet, und sollte somit eine ebenso hochgenaue Software-Uhr im Arduino ermöglichen.

Als Gegentest und Kontrolle ist weiterhin die DCF77-Uhrzeit vorhanden.

Nun ja, was soll ich sagen? Die Umstellung auf eine Software-Uhr (der µC führt die Zeitinformation in Variablen und wird von der RTC über das SQW-Signal gesteuert) zeigt, dass das SQW-Signal erwartungsgemäß genau zeithaltig ausgegeben wird und somit die Zeit im µC sauber der DCF77-Zeit (genaugenommen der RTC-Zeit) folgt.

Das hilft natürlich nicht bei der Fragestellung. Wir erinnern uns, es ist der Beweis zu führen, dass wiederholte Zugriffe auf die RTC-Register über die I²C-Schnittstelle die RTC ausbremsen.
Es muss also eine wenig intrusive Methode gefunden werden, die es erlaubt, die DCF77-Zeit, die im µC geführte Software-Uhrzeit und die in der RTC geführte Zeit zu vergleichen.

Ich habe deshalb die Informationen auf der seriellen Schnittstelle zum Computer so geändert, dass einmal in jeder Stunde die drei Zeiten ausgegeben werden.
Die Erwartungshaltung ist hierbei, dass sich die beiden Zeiten von DCF77 und Software-Uhr gar nicht und die RTC-Zeit anfangs ebenfalls nicht und, mit fortschreitender Laufzeit des Tests, nur unwesentlich voneinander unterscheiden.

Da ich nicht vor dem Testaufbau sitzen will um auf eine gültige DCF77 Zeitinformation zu warten, lasse ich das vom Programm erledigen. Sobald das erste Mal nach Start des Tests eine gültige und verifizierte DCF77 Zeit erkannt wurde, wird diese in die Software-Uhr und in die RTC übernommen. Ab dann laufen alle drei Uhren unabhängig voneinander, wobei die Software-Uhr natürlich von der RTC über deren SQW-Ausgang getaktet wird.

Im auf dem Computer mitlaufenden Protokoll kann ich dann das Ergebnis ablesen.

Etwas kompliziert wird die Sache noch durch die Tatsache, dass die gemeine Real Time Clock keine Sekunden-Information kennt. Bei der initialen Übernahme der DCF77 Zeit in die Software-Uhr und die RTC ergeben sich also Unterschiede im Sekunden-Bereich, das sieht man im Protokoll.

Die endgültige Version des Testprogramms zeigt dieses Verhalten nicht mehr, alle drei Uhren im Programm laufen gleichzeitig mit Sekunde 0 los, die RTC wird zum Minutenwechsel mit der DCF-Zeit beaufschlagt und läuft somit synchron.

 

Über eine Suchmaschine hier gelandet? Dann bitte mit Click Navigations Schaltflächen anzeigen

[Home] [Modelle] [Eisenbahn TT] [Was ist neu ?] [Elektronik] [Kontakt] [Links] [Tipps+Tricks]