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 hier: “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ährend des laufenden Zugriffs wird aber die Zeit aktualisiert.
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.
Resultat: Die im Microcontroller angekommene Information liegt 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:

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 ruhige Hand hat. Die Verwendung einer Leuchtlupe ist ebenfalls kein Fehler und kann hier nicht als Zeichen von Schwäche ausgelegt werden.

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.

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

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

Zwei Ausschnitte der Log-Datei eines der Module kann ich hier einfügen:
---------------
Start Uhrzeit-Check DS3231 DCF77 in SYNC, 1 Sekunde Differenz zwischen DCF77 und RTC

DCF77: 10.09.2018 - 22:19:01 RTC: 10.09.2018 - 22:19:00
DCF77: 10.09.2018 - 22:19:11 RTC: 10.09.2018 - 22:19:10
DCF77: 10.09.2018 - 22:19:21 RTC: 10.09.2018 - 22:19:20
DCF77: 10.09.2018 - 22:19:31 RTC: 10.09.2018 - 22:19:30
DCF77: 10.09.2018 - 22:19:41 RTC: 10.09.2018 - 22:19:40
...
...
DCF77: 11.09.2018 - 8:25:21 RTC: 11.09.2018 - 8:24:01
DCF77: 11.09.2018 - 8:25:31 RTC: 11.09.2018 - 8:24:11
DCF77: 11.09.2018 - 8:25:41 RTC: 11.09.2018 - 8:24:21
DCF77: 11.09.2018 - 8:25:51 RTC: 11.09.2018 - 8:24:31
DCF77: 11.09.2018 - 8:26:01 RTC: 11.09.2018 - 8:24:41

Hier geht die RTC mit DS3231 nach ca. 10 Stunden ca. 1:20 Minuten nach
---------------

---

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 im µC 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 auf den Lauf der RTC auswirken).

Dieses Signal muss bei der Initialisierung der RTC explizit eingeschaltet werden und kann bei den DS3231SN 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.

Zwei Ausschnitte der Log-Datei dieses Programms:
---------------
Start Uhrzeit-Check DCF gegen SoftClock, 1 Sekunde Differenz zwischen SoftClock und DCF

DCF77: 09.10.18 - 11:41:08     SoftClock: 11:41:07
DCF77: 09.10.18 - 11:41:18     SoftClock: 11:41:17
DCF77: 09.10.18 - 11:41:28     SoftClock: 11:41:27
DCF77: 09.10.18 - 11:41:38     SoftClock: 11:41:37
DCF77: 09.10.18 - 11:41:48     SoftClock: 11:41:47
DCF77: 09.10.18 - 11:41:58     SoftClock: 11:41:57
...
...
DCF77: 09.10.18 - 19:03:08     SoftClock: 19:03:07
DCF77: 09.10.18 - 19:03:18     SoftClock: 19:03:17
DCF77: 09.10.18 - 19:03:28     SoftClock: 19:03:27
DCF77: 09.10.18 - 19:03:38     SoftClock: 19:03:37
DCF77: 09.10.18 - 19:03:48     SoftClock: 19:03:47
DCF77: 09.10.18 - 19:03:58     SoftClock: 19:03:57

Hier zeigt die mit dem SQW-Signal der RTC getaktete Software-Uhr nach ca. 8 Stunden keine Abweichung gegenüber dem Start.
---------------

---

Man sieht, der SQW-Ausgang des RTC-Chip läuft akkurat im Sekundentakt und kann dazu verwendet werden, eine Software-Uhr im µC zu takten.

Die im Forum AVR-freaks von einigen Personen vertretene Theorie, die Zeit-Abweichung läge an ungenauen Quarzen der verwendeten RTC-Module, ist hiermit meiner Meinung nach wiederlegt  (Achtung: Diese Ansicht wird weiter unten wiederlegt).

Bliebe noch zu erwähnen, dass der von mir angeschriebene Verkäufer der RTC-Module auf meine Beweisführung nicht mehr reagiert hat.

---

Nachtrag
Weitere Untersuchungen an den RTC-Modulen im Rahmen von Änderungen an der WordClock Firmware die zum Ziel haben, die Uhr auch ohne WLAN mit vertretbaren Abweichungen betreiben zu können, haben ergeben, dass alle oben vorgestellten RTC-Module auch ohne Registerzugriffe zu langsam laufen.

Das schließt den SQW-Ausgang ein. Die Periodendauer des 1 Hz SQW-Signals ist bei allen Modulen in der Größenordnung von 1..3 ms zu lang, eine damit gesteuerte Uhr verliert also ca. 3..4 Minuten in 24 Stunden.

Diese Ergebnisse habe ich mit drei verschiedenen Vorgehensweisen erhalten:

• Manuelle Ermittlung der Abweichung anhand der Uhrzeit der WordClock im vergleich zur Rechner-Uhr
• Messung der Periodendauer mit einem Arduino Skript, interruptgesteuert und durch Messung mittels micros() Aufrufen
• Messung der Periodendauer mit einem Arduino Skript unter Verwendung der pulseIn() Funktion

Warum ich mit dem oben vorgestellten Testprogramm keine Abweichungen ermittelt habe, nachdem ich auf reine SQW-Taktung umgestellt hatte, ist mir somit nicht erklärlich.

Nachtrag
Inzwischen habe ich eine Rückmeldung von Harald T. erhalten. Er hat sich mehrere RTC -Module bei einem deutschen Händler bestellt und deren 32 kHz-Ausgänge mit einem hochgenauen Frequenzzähler überprüft. Bei 7 von 9 gemessenen Modulen liegt die Ausgangsfrequenz um 34 Hz bis 120 Hz zu niedrig, meine Beobachtungen werden also eindeutig untermauert.

Erwähnenswert ist vielleicht, dass man auch Glück haben kann, immerhin haben 2 von 9 Modulen die Spezifikation lt. Datenblatt - die zulässige Abweichung beträgt +- 2ppm - eingehalten. Allerdings ist der geneigte Bastler vermutlich in den seltensten Fällen in der Lage, die Einhaltung der Spezifikation nachzumessen um zu entscheiden, ob das fragliche Modul guten Gewissens eingesetzt werden kann.