DS1302 Batterietest

[Thomas S. (thomas_s72)]

Hallo,
wie testet man vorm Auslesen des DS1302 ob die verfügbare Zeit überhaupt 
glaubhaft ist?

Ich hab so ein Ding in meinem Webserver (Ulrich Radig mit XMEGA64). Der 
zieht seine Zeit vom NTP und aktualisiert den DS1302 periodisch.
Diese Zeit wird zu automatischen Schaltvorgängen herangezogen, Rolladen 
und Warmwasserzirkulation.

Nun setzt mein Internet hin und wieder aus und mein Webserver startet 
nachts immer neu (hängt nach Wochen sonst manchmal).

Ich lese dann die Zeit aus der RTC wenn NTP mal wieder nicht verfügbar 
ist. Ich würde gerne dabei prüfen, ob die RTC Zeit glaubhaft ist. Also 
eigentlich, ob die Batterie noch voll ist.

Dazu scheibe ich beim Update Bitmuster in mehrere RAM Zellen, diese lese 
ich dann beim Neustart aus. Stimmen die, so sollte die Batterie OK sein.
Aber auch ohne Batterie behält das Ding die RAM Infos, wenigstens eine 
Minute oder so. Natürlich läuft die Uhr ohne Batterie nicht weiter, die 
Zeit ist also Mist.
Wie realisiert man sinnvoll einen Battrietest um die Gültigkeit der 
ausgelesenen Zeit zu beurteilen?

Momentan schalte ich VCC der Uhr beim Start ab und lese meine Muster 
aus.
Stimmen die nicht ist die Batterie leer (das klappt wenn ich die 
Batterie abklemme). Dann schalte ich VCC an und los geht's.
Oder sollte man die Zeit ohne VCC innerhalb 1500ms zweimal auslesen und 
testen ob sich die Sekunde geändert hat? Das würde zeigen, dass die RTC 
tickt.
Macht jemand das so oder wie sind die Meinungen? Im PDF der DS1302 steht 
nix vom RAM Verhalten bei totalem Blackout. Ich ging davon aus dass bei 
leerer Batterie die RAM Zellen umkippen, scheint aber nicht so schnell 
zu passieren.

Wäre für Ideen dankbar.

Gruß
Thomas

[Wolfgang (Gast)]

Thomas S. schrieb:
> Wie realisiert man sinnvoll einen Battrietest um die Gültigkeit der
> ausgelesenen Zeit zu beurteilen?

Du könntest ab und zu die Batteriespannung per ADC nachmessen und dann 
erstmal davon ausgehen, dass bei guter Batterie die Zeit auch ok ist. 
Wenn du dann beim NTP-Update auch noch den Uhrenfehler (Stand, Gang) 
auswertest, merkst du, wenn da etwas faul ist.

[eProfi (Gast)]

Da die RAM data retension voltage  niedriger als die 
mindest-Oszillator-Spannung sein dürfte, würde ich zusätzliche Test 
durchführen:
 - Plausibilität
 - Z.B. jede Stunde oder jeden Tag einmal das (sicher richtige) Datum 
ins Flash / Eeprom schreiben (Ringpuffer, damit der Verschleiß 
gleichmäßig verteilt wird).  Dann bei zweifelhafter Zeit den 
Zeitunterschied zur letzten sicheren Zeit berechnen. Er sollte weniger 
als die Update-Rate sein.

[eagle user (Gast)]

Oder einen vernünftigen RTC-Chip verwenden... Der PCF2129T hat einen 
internen Komparator und ein Statusregister mit Batterie-Leer-Flag und 
Oszillator-Stop-Flag.

Zum Preis des DS1302 gibt es gratis:
 * einen internen Quarz
 * Temperaturkompensation (TCXO, auch die 32kHz sind kompensiert)
 * echtes SPI- und I2C-Interface im gleichen Chip
 * Takt-Ausgang (1Hz oder 1kHz bis 32kHz)
 * Interrupt-Ausgang für Alarm, Timer, Watchdog, Batterie leer, 
Timestamp
 * Timestamp-Eingang
 - kein RAM (für 50 Cent mehr gibt's den PCF2127T mit 512 Byte RAM)

Und nein, ich bekomme keine Prämie von NXP.

[Thomas S. (thomas_s72)]

Hallo,
das mit dem EEPROM scheint mir die eleganteste Lösung zu sein.
Zeit merken, wenn ich auslese muss diese größer als letztes Mal sein.

Versuche ich mal so, danke und einen schönen Sonntag noch.

Gruß

Thomas