Was ich immer schon mal wissen wollte. Wenn man beispielweise mit der DS3231 eine Uhr baut, wie geht man da generell mit dem Abgleich um?
Wie oft liest man die Uhr aus, wenn man bespielsweise einen Atmega mit dem internen RC Oszillator laufen hat...?
Man programmiert sich ja eine Uhr auf dem Atmega und synchronisiert die dann mit der rtc, oder? Wäre ja blöd wenn man das beispielweise alle 24h macht, die Uhr dann aber mehrere Minuten springt ...
Man soll die Dinger ja auch nicht zu häufig auslesen...
Wie oft liest man die Uhr aus, wenn man bespielsweise einen
Atmega mit dem internen RC Oszillator laufen hat...?
Nun - rechnen!
Im günstigen Fall hat man damit 3 % Abweichung, ist eine Genauigkeit von 1 Sekunde verlangt, muss folglich die RTC jede halbe Minute ausgelesen werden.
PS:
Der DS3231 hat ja einen 32 KiHz-Ausgang - diesen als Interrupt für den ATmega zu verwenden könnte sinnvoll sein ...
Es gibt/gab mal RTCs die man nicht so oft auslesen sollte, weil es da zu Zählfehlern kommen konnte.
Das ist m.W. aber vorbei, seit die I²C sprechen.
Man muss aber dennoch auf die Reihenfolge und den Zeitpunkt des auslesens der Register achten, damit es nicht dazu kommt das man über einen Minuten-/Stunden-/Tagessprung ausliest.
Zum anderen haben viele einen Ausgang, der einen Takt abgeben kann, teilweise z.B. feste 32768kHz, teilweise auch programmierbar, z.B. auf 1Hz.
Den kann man an einen Pin des Controllers andocken und dann dort entsprechend benutzen, dann ist der Takt des Controllers reichlich egal. Ja, technisch gesehen sind die Takte asynchron und daher kommt es zu winzigen Sprüngen in der Dauer z.B. einer Sekunde, aber für menschliche Wahrnehmung ist das genau.
Damit kann man dann selber Sekunden zählen und nur einmal pro Minute die Uhr abfragen, oder eben auch "immer nach dem Signal" die RTC komplett auslesen.
Oder drittens man rechnet aus wie lange der Controller braucht um mit seinem Takt 1/2 LSB Abweichung zu bauen und liest immer in diesem Intervall.
Die programmiertechnisch einfachste Lösung dürfte die zweite sein:
Warte auf 1PPS-Signal
Lies die RTC
Bring das auf's Display
wieder von vorne.
Wenn die Schaltung noch anderen Kram machen muss, sollte man probieren das in den 4. Schritt zu packen.
Moin,
vielleicht ist es einfacher dem Atmega einen Quarz oder Oszillator zu gönnen. Der würde die Urzeit im Atmega oder Attiny gleich genau erzeugen können und der Aufwand ist geringer. Nur eine freier Timer muss vorhanden sein
Gruß
Carsten
Wäre ja blöd wenn man das beispielweise alle 24h macht, die Uhr dann
aber mehrere Minuten springt ...
Dann hat man blöd programmiert. Nach den ersten 24h kann das vielleicht passieren, aber daraus sollte der ATmega lernen, den Fehler seines RC-Oszillators bestimmen und den Gang seiner Software-Uhr immer entsprechend korrigieren, so dass es nicht wieder zu so großen Abweichungen kommt.
Dann hat man blöd programmiert. Nach den ersten 24h kann das vielleicht
passieren, aber daraus sollte der ATmega lernen, den Fehler seines
RC-Oszillators bestimmen und den Gang seiner Software-Uhr immer
entsprechend korrigieren,
Blöderweise arbeitet der RC Oszillator Temperatur- und Betriebsspannungsabhängig.
Es sieht einfach doof aus, wenn die Anzeige nicht gleichmässig im Sekundentakt springt. Ob man dazu die RTC 20 x pro Sekunde ausliest, oder eine PLL nur 1 x am Tag synchronisiert, bleibt dem Programmierer überlassen.
Blöderweise arbeitet der RC Oszillator Temperatur- und
Betriebsspannungsabhängig.
Wenn man schon einen RC Oszillator als Zeitbasis für eine Uhr verwenden will, tut man das tunlichst nur bei halbwegs stabilen Bedingungen. Solange das Ding unter Wohnraumbedingungen betrieben wird, ist der Mittelwert über 24h recht stabil. Wenn das dem Anwender nicht reicht, muss er eben öfter bei der RTC nachfragen oder direkt die RTC für die Zeit in der Anwendung nutzen.
Es ging um die Kalibrierung des RC-Oszillator gegen die RTC.
Im Endeffekt ist das eine PLL mit einer Referenzfrequenz entsprechend dem RTC-Abfragetakt.
Es sieht einfach doof aus, wenn die Anzeige nicht gleichmässig im
Sekundentakt springt.
Entweder überschätzt du maßlos dein absolutes Zeitgefühl oder die Instabilität eines RC-Oszillators. Wie oft hast du auf einer Uhr schon eine Schaltsekunde gesehen? Das dürfte so ziemlich die größtmögliche Ungleichmäßigkeit im Ablauf einer Minute auf einer Uhr sein.
Es gibt ja ATMega mit Timer2, auch mit clock Pins. Dort kann man einen 32768Hz Quartz anhaengen. die gibt es fuer wenig Geld mit erhoehter Genauigkeit, zB mit 10 ppm anstelle von 100ppm. Wenn man in dessen Inerrupt eine Uhr zaehlen laesst muss man diese Uhr eigentlich nur beim Powerup einmal vom RTC laden.
/Dafür/ müsste die Anzeige aber mechanisch sein (hatten wir das nicht gerade?) und man braucht noch einen Thermostat für den 10ppm-Uhrenquarz am AVR. Am besten mit Kohle beheizt, Gas wäre ja zu einfach. Das kostet dann zwei Förderbänder und einen Ozongenerator oder was hilft gegen statische Aufladung?
Kommt drauf an wie genau es bleiben soll, ich gleiche das irgendwie zwischen 1-10 Minuten ab. (Für eine Uhr)
Will man durchgehend einen sehr genauen z.B. Millisekunden Takt haben, kann man die Minütlich synchronisierte Zeit mit dem 32khz Signal abgleichen. So kann man eine X Tages Stopuhr mit 2ppm und 32768/Sekunde umsetzen.
Man kann auch ein 1 Sekunden Takt nehmen, und dazwischen mit dem 16Mhz Basistakt zählen. Das muss man dann nach Genauigkeit abwägen.
Die Dallas haben das trotzdem, wenn man per I2C Sinnloses Massen Polling
betreibt.
Daher macht es Sinn, den 1Hz-Ausgang zu nutzen, der immer dann signalisiert, wenn die Zähler eh "eins weiter" sind.
Man hat dann knapp eine Sekunde Zeit alles aus der RTC rauszuholen, bevor die Vorsichtsmaßnahmen beachtet werden müssen.
Für eine Schaltung deren Hauptzweck ist eine Uhr zu sein ist das ideal weil einfach zu bauen, einfach zu programmieren und genau ist es auch noch.
Will man durchgehend einen sehr genauen z.B. Millisekunden Takt haben,
kann man die Minütlich synchronisierte Zeit mit dem 32khz Signal
abgleichen. So kann man eine X Tages Stopuhr mit 2ppm und 32768/Sekunde
umsetzen.
Man kann auch ein 1 Sekunden Takt nehmen, und dazwischen mit dem 16Mhz
Basistakt zählen.
Wobei das 32kHz Signal bei den meisten RTCs nicht so genau ist wie der 1 Sekunden Takt. Der DS3231 ist einer der ganz wenigen, bei denen die Temperaturkompensation am Oszillator ansetzt. "Normale" RTCs machen das weiter hinten digital. Bei denen ist die 1 Sekunde exakt, aber nur über viele 32kHz-Perioden gemittelt, z.B. über 512 Sekunden. Der RV-3032-C7 schafft das angeblich in 1 Sekunde.
Für eine normale Uhr ist der 1 Sekunden Takt ideal. I2C braucht man damit nur genau einmal nach einem Stromausfall.
Man soll die Dinger ja auch nicht zu häufig auslesen...
Das Datenblatt zur DS3231 ist da unmissverständlich:
When reading or writing the time and date registers,
secondary (user) buffers are used to prevent errors when the
internal registers update. When reading the time and date
registers, the user buffers are synchronized to the internal
registers on any START and when the register pointer
rolls over to zero. The time information is read from these
secondary registers, while the clock continues to run. This
eliminates the need to reread the registers in case the
main registers update during a read.
Das Datenblatt zur DS3231 ist da unmissverständlich:
Das Problem ist natürlich nicht das Datenblatt!
Auch nicht diese RTC.
Sondern die menschliche Fähigkeit, ein erlebtes, oder nur gehörtes, Problem auf alles zu projizieren, was nicht schnell genug auf den Baum kommt.
Gerüchteküche und Vorurteile
Und diese lassen sich eher selten durch Fakten beeinflussen.
Wobei das 32kHz Signal bei den meisten RTCs nicht so genau ist wie der 1
Sekunden Takt.
Woher soll der 1 Sekunden Takt einer RTC denn sonst kommen, wenn nicht durch Teilung aus dem 32768Hz-Takt?
Die saubere Teilbarkeit ist doch genau der Grund für diese Taktfrequenz.
Für eine normale Uhr ist der 1 Sekunden Takt ideal. I2C braucht man
damit nur genau einmal nach einem Stromausfall.
Genau so isses.
Ich habe einen 3 Jahres mit dem dS3231 auf 2-2,5ppm pro Jahr durch. (Nie unter 10 Grad.)
Dazu auch parallele Synchronisierung zur Langzeitmessung von Takten mit 16Mhz der MCU, GPS-PPS und TCXO-RTC als Zweitbasis bzw. Sekundenreferenz von der dann der 16Mhz Takt in eigenem Zähler korrigiert wurde (Digitale Kompensation.)
Das ist aber schon 10 Jahre her, es war aber nur eine Spielerei im Heim-Labor :)
Wobei das 32kHz Signal bei den meisten RTCs nicht so genau ist wie der 1
Sekunden Takt.
Woher soll der 1 Sekunden Takt einer RTC denn sonst kommen, wenn nicht
durch Teilung aus dem 32768Hz-Takt?
Die saubere Teilbarkeit ist doch genau der Grund für diese Taktfrequenz.
das /war/ der Grund für diese Frequenz, damals, im vorigen Jahrhundert. Heute kann eine RTC abwechselnd zwei verschiedene Teiler benutzen und so den Fehler der 32kHz reduzieren. Dadurch ist der 1Hz Takt im Mittel genauer als die 32kHz.
Ja, Dallas hat damals feste 32768:1 benutzt und zum Abgleich die Kapazität(en) im Quarzoszillator verändert, vielleicht mit einer Kapazitätsdiode? Aber heutzutage muss ja alles digital funktionieren.
Woher soll der 1 Sekunden Takt einer RTC denn sonst kommen, wenn nicht
durch Teilung aus dem 32768Hz-Takt?
Er meinte bei einer RTC mit Temperaturkompensation, wie z.B. der 3231.
Da gibt es grundsätzlich 2 Methoden:
a) Entweder wird die 32.768kHz-Frequenz des Quarzes angepasst, d.h. der Oszillator selber wird temperaturgeregelt.
b) Oder der Chip passt den Teiler an, und teilt nicht fest durch 32768.
Das kann passieren durch 2 abwechselnde Teiler, die abechselnd verwendet werden, oder durch einen anpassbaren Teiler.
Alternativ gibt es auch die Version, das der Zähler nicht auf 0 initialisiert wird, sondern einige Zähler vorgegeben werden.
Bei a) ist der Taktausgang wenn auf 32.768kHz programmiert eben genau weil temperaturkompensiert.
Bei b) hingegen geht der Quarz und damit der 32.768kHz Takt je nach Temperaturgang leicht falsch.
Der 1Hz-Ausgang ist aber in beiden Fällen temperaturkompensiert und damit zu bevorzugen.
Kondensatorbank mit PROM-LUT, soweit mir bekannt.
Stand früher auch im Dabla oder einer Appnote.
Jepp, das wird in der "Aging Offset Register" Beschreibung erklärt.. man kann so Kondensatoren als Grundlast aktivieren oder deaktivieren um sogar noch Feintuning zu betreiben.
One LSB represents one small capacitor to be switched in or out of the capacitance array at the crystal pins. The aging offset register capaci-
tance value is added or subtracted from the capacitance value that the device calculates for each temperature compensation.
RC-Oszillators bestimmen und den Gang seiner Software-Uhr immer
entsprechend korrigieren
mache ich auch so. 1x am Tag, immer morgens um drei. ich berechne mir die ms Abweichung pro minute und stelle den internen Softtimer für die Uhr entsprechend ein, sodass immer in der 59. Sekunde einer Minute etwas korrigiert wird. So läuft sie den ganzen Tag sehr sehr genau...
Die Abweichung des RC Oszillators liegt erfahrungsgemäß bei bis zu +/- 100 ms/min. - hab nie im Datenblatt nach der "Genauigkeit" geschaut...
Also 1.7 Promille - parbleu!
Sicher nicht bei einem üblichen ATmega.
kommt drauf an, ich habe einen Atmega auch schon mit einem 5€ Oszillator (Edelstahlgehäuse) bestückt. Der hatte mit 16Mhz viel geringere Abweichungen als ein 5 €Cent Arduino Onboard Oszillator.
Stell dir mal vor, es gibt Oszillatoren für weniger als 1,50€, die 1,5ppm absolute Toleranz (plus 0,5ppm für -40-85°C, plus ß,5ppm Alterung) bieten.
Leider nur 3,3V, aber man muss ja nicht unbedingt einen 5V-Prozessor benutzen.
