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...
Thorsten S. schrieb: > Man soll die Dinger ja auch nicht zu häufig auslesen... Aha... Was sagt denn das Datenblatt zu der Behauptung?
> 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 ...
:
Bearbeitet durch User
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
Carsten-Peter C. schrieb: > Der würde die Urzeit im Atmega oder Attiny Die gab es zu Urzeiten noch nicht ;-) Da stapften noch die Dinosaurier rum.
Rainer W. schrieb: > Carsten-Peter C. schrieb: >> Der würde die Urzeit im Atmega oder Attiny > > Die gab es zu Urzeiten noch nicht ;-) > Da stapften noch die Dinosaurier rum. Ach wo, das ist UTC+3. https://de.wikipedia.org/wiki/Ur_(Stadt)
Rainer W. schrieb: > Da stapften noch die Dinosaurier rum. Und mangels genauer Zeitangabe zum Date sind die Dinos ausgestorben. mfg
Thorsten S. schrieb: > 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.
:
Bearbeitet durch User
Thorsten S. schrieb: > mehrere Minuten springt ... lass sie doch springen.
1 | //------------------- smh timer ------------------
|
2 | if (timer_smh>99) |
3 | {
|
4 | sec=sec+timer_smh/100; |
5 | timer_smh=timer_smh%100; |
6 | if(sec>59){ |
7 | sec=sec-60; min=min+1; |
8 | lcd_goto(2,4);// |
9 | lcd_int2(min);// |
10 | lcd_write(":"); |
11 | if(min==60){ |
12 | min=0; hou++; |
13 | if(hou==24) |
14 | {
|
15 | hou=0; |
16 | if(sperre_rtc==0) |
17 | {
|
18 | kk_ds1307_getAll_to_global_struct_zt(); |
19 | sub_sommerzeit(); |
20 | sperre_rtc=1; |
21 | sub_day_start(); |
22 | }
|
23 | }
|
24 | if(hou==2)sperre_rtc=0; |
25 | lcd_goto(2,1);// |
26 | lcd_int2(hou);// |
27 | lcd_write(":"); |
28 | }
|
29 | }
|
30 | lcd_goto(2,7);// |
31 | lcd_int2(sec);// |
32 | // led1_tog;
|
Für die meisten Anwendungen ist das egal. Mehr Genauigkeit erfordert halt mehr Aufwand.
Christian S. schrieb: > Rainer W. schrieb: >> Da stapften noch die Dinosaurier rum. > > Und mangels genauer Zeitangabe zum Date sind die Dinos ausgestorben. Die sind doch bei einem Flugzeugunglück... https://de.wikipedia.org/wiki/De_Havilland_DH.106_Comet
Rainer W. schrieb: > 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.
Michael B. schrieb: > 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. p.s. Adjektive schreibt man klein ...
:
Bearbeitet durch User
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.
Manchmal glaube ich es gibt hir einen versteckten Rube-Goldberg-Wettbewerb...
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?
Nein, dazu muss es nur nutzlos kompliziert gemacht werden. Gewinnen kann man damit nix, aber der TO auch nicht.
Jens M. schrieb: > Manchmal glaube ich es gibt hir einen versteckten > Rube-Goldberg-Wettbewerb... Erster Preis ist ein original Familienbenutzer.
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. Jens M. schrieb: > Das ist m.W. aber vorbei, seit die I²C sprechen. Die Dallas haben das trotzdem, wenn man per I2C Sinnloses Massen Polling betreibt.
:
Bearbeitet durch User
Philipp K. schrieb: > Kommt drauf an wie genau es bleiben soll, ich gleiche das irgendwie > zwischen 1-10 Minuten ab. (Für eine Uhr) Pro Stunde, Tag, Monat, Jahr oder Jahrzehnt?
Philipp K. schrieb: > 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.
Philipp K. schrieb: > Die Dallas haben das trotzdem, wenn man per I2C Sinnloses Massen Polling > betreibt. Vielleicht, manchmal, mag das auf die DS1307 zutreffen. Und soweit mit bekannt, eher ein Problem beim Schaltungsaufbau. Bei den DS3231 konnte ich das nicht feststellen! Trotz Dauertest über Monate
Philipp K. schrieb: > 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.
Thorsten S. schrieb: > 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.
Sn60pb38cu2 schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > der DS3231 ist einer der ganz wenigen, bei denen die > Temperaturkompensation am Oszillator ansetzt. Ich finde es gibt genügend "TXCO-RTC"s Chips. Bauform B. schrieb: > 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 :)
Rainer W. schrieb: > Bauform B. schrieb: >> 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.
Rainer W. schrieb: > 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. Bauform B. schrieb: > vielleicht mit einer > Kapazitätsdiode? Kondensatorbank mit PROM-LUT, soweit mir bekannt. Stand früher auch im Dabla oder einer Appnote.
:
Bearbeitet durch User
Jens M. schrieb: > 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.
Rainer W. schrieb: > 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...
> Die Abweichung des RC Oszillators liegt erfahrungsgemäß > bei bis zu +/- 100 ms/min. Also 1.7 Promille - parbleu! Sicher nicht bei einem üblichen ATmega.
S. L. schrieb: > 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.
an Philipp K.: Sie haben aber schon verstanden, dass von einem RC-Oszillator die Rede war?
Ne, ist ein TCXO, ich verstehe den Wert als "insgesamt". Quote Dabla ECS-TXO-2016MV https://www.mouser.de/datasheet/3/294/1/ECS-TXO-2016MV.pdf
1 | Tolerance at +25°C ± 2.0 ppm |
2 | Vs. Temp (-30 ~ +85°C) ±2.0 ppm |
3 | Vs. Temp (-40 ~ +85°C) ± 2.5 ppm |
War jetzt eben schnell eine Mousersuche 16MHz/TCXO/CMOS-Output Mit "Clipped Sine" gibts noch bessere für wenige Geld.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.