Guten Tag ich bin momentan mit der programmierung einer Uhr beschäftigt und bin etwas aufm holzweg im moment Ich verwende einen ATmega325 und einen 10Mhz Quarz Ich benutze den Timer1(16bit). Dafür habe ich ausgerechnet 10Mhz Prescaler OCR1AH:OCR1AL = 10Hz = 100ms 10MHz 64 15624 = 10Hz =100ms Das OCR register ist mit 15624 geladen denn der fängt ja mit 0 anzu zählen. wenn ich nun in der Simulation einen Breakpunkt in der ISR von Timer 1 Setze genau bei dem Punkt wo auch das Sekundenregister erhöht wird alle 1.000.000,00 µs das Sekunden Register um 1 erhöht. Aber wenn ich das Programm auf dem µC laufen lasse dann habe ich das Problem das die Uhr nach ca 5Tagen bereits 2min und 45s langsamer läuft als meine Funk uhr die ich zum vergleich nehme. wie korrigiert man so einen zeit versatz nun am besten?
Du musst die Quarz-Frequenz leicht verstimmen. Der Quarz hat einen gewissen Fehler, der sich hier eben durchsetzt. Eine Verstimmung erreichst du durch Änderung der Kondensatoren, die vom Quarz gegen Masse gehen.
http://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC kurz gesagt dein Quarz hat keine 10Mhz...
Seb schrieb: > Aber wenn ich das Programm auf dem µC laufen lasse dann habe ich das > Problem das die Uhr nach ca 5Tagen bereits 2min und 45s langsamer läuft > als meine Funk uhr die ich zum vergleich nehme. Gratuliere. Du hast soeben rausgefunden, dass dein 10Mhz Quarz nicht mit exakt 10000000 Schwingungen in der Sekunde arbeitet, sondern mit ein bischen weniger (ist normal. kein Grund zur Beunruhigung) Mach eine genau Zeitmessung über mehrere Tage und rechne zurück, wie groß die Quarzfrequenz wirklich ist, und berechne dann mit Vorteiler den OCR Wert noch einmal. Dann sollte es passen.
Meinst du mit einer Zeit Messung das ich Morgen um 09:00:00 auf meinen Funkwecker gucke und auf meine Uhr und dann nächste woche nochmal beide zeiten vergleiche und diese Differenz dann einfach versuche zurückzurechnen ? Oder wie meintest du das ? Danke schonmal fuer die brauchbaren antworten - an eine Toleranz vom quarz hab ich garnicht gedacht, weil doch alle immer davon sprechen das die so genau sind
Seb schrieb: > Danke schonmal fuer die brauchbaren antworten - an eine Toleranz vom > quarz hab ich garnicht gedacht, weil doch alle immer davon sprechen das > die so genau sind Im Vergleich zu anderen Taktgebern sind sie verdammt genau :) Es gibt halt Toleranzen bezogen auf Temperatur und Genauigkeit. ( meist ca. 20 ppm )
http://de.wikipedia.org/wiki/Zaunpfahlproblem Wenn ich mich nicht täusche springt der AVR unmittelbar bei erreichen von 0 auf den OCR Wert und nicht erst im nächsten Takt 0 = 15625 Jedenfalls weit logischer als die Toleranzen von nem Quarz, die durchaus mal ne Minute im Monat ausmachen (Meine Erfahrung)
Wald-und Wiesenquarze haben eine Abweichung von +/- 30 ppm. In 5 Tagen sind das rund +/- 13 s. Die Abweichung von 2 m 45 s ist da doch ein wenig hoch.
Es gibt doch auch die Möglichkeit an den AVR nen Uhrenquarz unzuschließen, mach doch das, google einfach mal danach, das dürfte schon wesentlich genauer sein.
Wenn er 15625 Zählvorgänge in einem bestimmten Zeitintervall benötigt, dann muss er OCR auf 15624 setzen. Denn auch der Übergang von 15624 nach 0 ist ein Zählvorgang. Anders ausgedrückt: Mit einem OCR von 15624 dauert es 15625 Timer Ticks bis der Timer einmal rundum wieder bei 0 angelangt ist. So gesehen passt das schon. PS: Wenn überhaupt, dann müsste er einen kleineren Wert als 16524 ins OCR Register eintragen. Seine Uhr geht zu langsam! Mit einem größeren OCR Wert würde sie noch langsamer gehen.
Martin schrieb: > Wald-und Wiesenquarze haben eine Abweichung von +/- 30 ppm. > > In 5 Tagen sind das rund +/- 13 s. Die Abweichung von 2 m 45 s ist da > doch ein wenig hoch. Du hast den Vorteiler von 64 übersehen. Der spielt da noch mit rein und vergrößert den Fehler. Aber das wird er schon noch merken, dass er da einen Vorteiler von 1 haben möchte, wenn er dann ausrechnet, wie sich das alles bei seiner 'kummen' Quarzfrequenz ausgeht.
... Du hast den Vorteiler von 64 übersehen. Der spielt da noch mit rein. ... Hoppla, wieso ändert sich dann die Abweichung von 30 ppm? Die sollte doch gleich bleiben.
Nö, tut sie nicht, du hast ne Abweichung von 30 auf eine Million Takte und durch das schnelle Quarz mehr Takte pro Sekunde, das macht also auch die Abweichung pro Sekunde größer!
Marc, wo ist mein Fehler? Bitte vorrechnen!
1 | 5 * 24 * 3600 s / 10^6 * 30 = 12,96 s (1 MHz Quarz) |
2 | |
3 | 5 * 24 * 3600 s / (10 x 10^6) * 300 = 12,96 s (10 MHz Quarz) |
Ich selbst, baute vor etwa 15 Jahren eine DCF77-Uhr auf einem SAB80C515A mit Quarz 18MHz. Das ist ein altes 8051-Derivat von Siemens/Infineon. Wenn das Funksignal ausfällt, geht die Uhr auch 1 Minute am Tag falsch. Obwohl die Timer-Simulation exakt war. Aus den verschiedenen Literaturen habe ich gelesen, daß der Quarz umso genauer wird, je mehr man die Kapazitäten erhöht. Das steht jedoch im Gegensatz zum schnellen und sicheren Anschwingverhalten des µC. Meine beiden Kapazitäten haben 22pF. Für höhere Präzision, sind 100pF empfohlen. Entweder, braucht man da eine Trimmerschaltung, oder z.B. ein EEPROM, in dem man Timer-Korrekturwerte mittels Tasten während des Betriebes ablegen kann. Ein Hex-Kodierschalter an freien Pins oder ein Poti am ADC könnte es auch noch tun. Andererseits, ist ein Ausfall des Funksignals höchst selten bis gar nicht. Deswegen schenke ich dieser Erscheinung auch keine Beachtung.
@Wilhelm (Gast) >Wenn das Funksignal ausfällt, geht die Uhr auch 1 Minute am Tag falsch. >Obwohl die Timer-Simulation exakt war. Welch Wunder . . . >Aus den verschiedenen Literaturen habe ich gelesen, daß der Quarz umso >genauer wird, je mehr man die Kapazitäten erhöht. Das ist Unsinn. Die Kapazitäten müssen auf den Quarz abgestimmt sein, nicht mehr, nicht weniger. Wenn man dann einen erwischt, der mit den meist verwendeten 22pF nicht zufrieden ist, muss man halt einen Trimmer nutzen. >Meine beiden Kapazitäten haben 22pF. Für höhere Präzision, sind 100pF >empfohlen. Viel zu viel. Über 33pF kommt man selten hinaus. MfG Falk
Seb: Nutzt du den CTC-Modus oder setzt du den Timer manuell auf 0 zurück?
Es wurde bereits darauf hingewiesen, aber nochmal:
1 | > 10MHz / 64 / 15624 = 10Hz =100ms |
2 | |
3 | > Das OCR register ist mit 15624 geladen [..] |
Das ist falsch. Um durch n zu teilen, muss OCR mit n-1 geladen werden. Das dürfte den größten Teil der Abweichung erklären.
Hc Zimmerer schrieb: > Es wurde bereits darauf hingewiesen, aber nochmal: >
1 | >> 10MHz / 64 / 15624 = 10Hz =100ms |
2 | > |
3 | >> Das OCR register ist mit 15624 geladen [..] |
4 | > |
> Das ist falsch. Um durch n zu teilen, muss OCR mit n-1 geladen werden.
Hat er.
Seine formale Division ist falsch angeschrieben.
Es muss lauten
1 | 10MHz / 64 / 15625 = 10Hz =100ms |
OCR auf 15624 ist korrekt. (Ich habs 3 mal nachgerechnet)
5 d = 5 24 3600 = 432000 s Nachgehen um 2 m : 45 s = 165 s bedeutet Fehler = 165/432000 = 382 : 1000000 = 382 ppm (zu langsam) (ppm = auf eine Million bezogen) Ich habe bisher nur mit ATMega8 und einigen ATTiny gearbeitet, aber da war der Fehler bei 4...16 MHz-Quarz und 2 x 22 pF meist so, dass er um 30-50 ppm zu schnell war. Mit 27...33 pF kam ich dann auf Fehler < 10 ppm. Wenn's genauer sein soll, klappt es oft mit 27 pF und 22 pF parallel zu einem 6...30 pF Trimm-C. - Stimmt die Schaltung? - Kann man beim ATmega325, interne Cs ein- / auszuschalten? Schalte sie aus! (Fuse-Bits) - Stimmen die C-Werte? Bei schwingfreudigen Quarzen könnte man vielleicht mit 2 x 220 pF, statt 2 x 22 pF, auch zu dieser ungewöhnlichen Frequenzabweichung kommen...
Hallo Seb, schreib dir doch eine kleine Software für den Atmel.. so als Frequenzzähler. dann misst der Atmel mit dem evt. falschen Quarz seine eigene Frequenz. unabhängig von allen Quarzfehlern sollte das aber konsistent sein. mit dieser Methode lassen sich Softwarefehler aufspüren. gruss k.
Bitte 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.