Forum: Mikrocontroller und Digitale Elektronik Ungeauigkeit bei Zeitmessung mit Quarz


von Torsten W. (torsten_w)


Lesenswert?

Hi,

ich benutze grade einen atmega32 mit 16 Mhz Quarz zu Zeitmessung, indem 
ich mittels Interrupt jede Sekunde eine Variable inkrementiere.
Ich habe bei 24 Stunden Zeitmessung einen Zeitunterschied zu meinem 
Computer von ca. 2 Sekunden.
Ich wollte an dieser Stelle fragen, ob so eine Abweichung normal ist, 
oder ob das z.B. daran liegen könnte, dass ich den Quarz auf der 
Lochrasterplatine schräg verbaut hab, da der HC49U Quarz den ich 
verwende scheinbar nicht das Rastermaß 2,54 hat. Der eine Pin des IC ist 
also etwas weiter vom Pin des Quarzes entfernt als der andere.
Falls solch eine Abweichung eher unnormal ist, werde ich auch nochmal 
gern den gesamten Aufbau und Code posten.

Gruß,
toti

von Tim (Gast)


Lesenswert?

2/86400 = 23,15ppm
Und wie viel ppm hat dein Quarz?
Stimmt die Temperatur?
Lastkapazitäten passen?

von Peter II (Gast)


Lesenswert?

Die frage ist: Wie ermittelnst du bei 16Mhz die genaue Sekunde?

von Falk B. (falk)


Lesenswert?


von Peter R. (pnu)


Lesenswert?

2 Sekunden in 86400sec sin 1/43200 -stel, in ppm ausgedrückt 23ppm.

Das ist schon eine Ungenauigkeit, wie sie der Quarz durch das nur grob 
eingestellte Last-C bekommt. Also etwas, das für einen Quarz normal ist.

Mit einem Trimmer am Quarz könnte man die Frequenz nachjustieren, nur 
hat das wenig Zweck, da die Temperaturdrift eines Quarzes auch schon im 
Bereich von etwa 20ppm liegt.

Bei einer Uhr ist aber nicht der Trimmer sondern die Korrektur per 
Software erste Wahl.

Wenn man genauer als 10..20ppm bei einem Quarz haben will, muss man 
schon seinen Temperaturgang kompensieren, aber dann wirds recht 
aufwändig.

Wenn man einei Quarz auf der Leiterplatte mit (warmen) Fingern anfasst 
bekommt man schon eine Frequenzverschiebung von einigen ppm: durch die 
Kapazität der Hand sofort, durch die Wärme der Hand nach einigen -zig 
Sekunden zusätzlich.

von Anja (Gast)


Lesenswert?

Torsten W. schrieb:
> Ich habe bei 24 Stunden Zeitmessung einen Zeitunterschied zu meinem
> Computer von ca. 2 Sekunden.

Du weißt aber Schon wie in Deinem Computer die Zeit erzeugt wird.

14.31818 MHz  12  65536 / 65536 = 1 Stunde mit 3599.5920... Sekunden.

Gruß Anja

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Torsten W. schrieb:
> Ich wollte an dieser Stelle fragen, ob so eine Abweichung normal ist,
Ja.
Genauere Quarze bekommst du nur gegen viel Geld. Wobei natürlich die Uhr 
deines Computers auch in die selbe Richtung falsch gehen könnte...
Nimm besser sowas wie DCF77 als Referenz.

von Torsten W. (torsten_w)


Lesenswert?

Also im Datenblatt werden 30ppm angegeben, wäre also im annehmbaren 
Bereich. Ich verwende zwei 22pF Kondensatoren obwohl im Datenblatt 32pF 
als Lastkapazität angegeben wurden. Ich muss zugeben, dass ich da bis 
jetzt nicht drauf geachtet hab, weil ich immer davon ausgegangen bin, 
dass 22pF bei einem herkömmlichen Quarz ausreichen (beim rn-controll ist 
es glaub ich auch so).
Die Temperatur liegt konstant bei Raumtemperatur.
Könnte diese Wegdifferenz zwischen den Pins das ganze denn noch 
verstärken?

von ... (Gast)


Lesenswert?

Torsten W. schrieb:
> Ich verwende zwei 22pF Kondensatoren obwohl im Datenblatt 32pF ...

Da mußt Du dann aber auch noch die Eingangskapazitäten deines 
Mikrokontrollers mit einrechnen.

von Skua (Gast)


Lesenswert?

Torsten W. schrieb:
> Könnte diese Wegdifferenz zwischen den Pins das ganze denn noch
> verstärken?

Nee.

von Peter D. (peda)


Lesenswert?

Miß die Abweichung über mehrere Tage, errechne damit die wirkliche 
Quarzfrequenz und trage sie dann in den Code ein.

Quarzuhren werden auch erstmal abgeglichen. Dazu werden dann einige 
Brücken durchtrennt. Nur ältere hatten noch nen Trimmer.

Um den Temperaturgang brauchst Du Dir keine Gedanken zu machen. Der ist 
bei üblichen Uhrenquarzen sogar schlechter als bei MHZ-Quarzen.


Peter

von Torsten W. (torsten_w)


Lesenswert?

Danke erstmal für die Vielen Antworten. Ich hab jetzt erst im Nachhinein 
gesehen, dass da noch einiges kam während ich meinen letzten Post 
gemacht hab.
Bezüglich der Frage, wie ich die Sekunde berechne, hatte ich ja schon 
gesagt, dass ich das mittels eines overflow interrupts mache mit einem 
prescaler von 256, wo ich bei jedem Interrupt den Timer schonmal mit 
einem Wert von 3036 vorlade.
Ich werde dann mal die Abweichung über mehrere Tage messen (mit 
verschiedenen Geräten) und das ganze dann Softwareseitig optimieren.
Vielen Dank.

von Peter II (Gast)


Lesenswert?

Torsten W. schrieb:
> schonmal mit einem Wert von 3036 vorlade.
ich kann mir schon vorstellen das das schon das Problem ist. Denn der 
Overvlow interupts wird nicht immer zu gleichen zeit aufgerufen. z.b. 
Wenn ein andere Interupts abgearbeitet wird. Damit verschieb sich der 
Zeitpunkt des vorladens.

von spess53 (Gast)


Lesenswert?

Hi

>Bezüglich der Frage, wie ich die Sekunde berechne, hatte ich ja schon
>gesagt, dass ich das mittels eines overflow interrupts mache mit einem
>prescaler von 256, wo ich bei jedem Interrupt den Timer schonmal mit
>einem Wert von 3036 vorlade.

Schon mal etwas von CTC gehört?

MfG Spess

von holger (Gast)


Lesenswert?

>Bezüglich der Frage, wie ich die Sekunde berechne, hatte ich ja schon
>gesagt, dass ich das mittels eines overflow interrupts mache mit einem
>prescaler von 256, wo ich bei jedem Interrupt den Timer schonmal mit
>einem Wert von 3036 vorlade.

Nimm nicht den Overflow Interrupt. Benutze CTC dann wirds
etwas besser.

von Peter R. (pnu)


Lesenswert?

Man sollte für den Timer eine Betriebsart wählen, bei dem der reload 
fest abläuft. (z.B.CTC mode) Dann wird zwar ein Interrupt ausgelöst, der 
Timer arbeitet dann zyklisch, nicht durch die Interrupt-Routine 
unterbrochen. Die bringt eine zusätzliche Zeitverzögerung durch 
abarbeiten des aktuellen Befehls, Stack-Operationen usw. bis endlich das 
reload des Timers stattfindet.

von spess53 (Gast)


Lesenswert?

Hi

>nicht durch die Interrupt-Routine
>unterbrochen. Die bringt eine zusätzliche Zeitverzögerung durch
>abarbeiten des aktuellen Befehls, Stack-Operationen usw. bis endlich das
>reload des Timers stattfindet.

Der TO hat einen Prescaler von 256. Da kann man in der Interruptroutine 
Romane schreiben (zumindest in Assembler). Der Unsicherheitsfaktor ist 
der Prescaler, der ungehindert weiterläuft.

MfG Spess

von Peter II (Gast)


Lesenswert?

spess53 schrieb:
> Der TO hat einen Prescaler von 256. Da kann man in der Interruptroutine
> Romane schreiben (zumindest in Assembler). Der Unsicherheitsfaktor ist
> der Prescaler, der ungehindert weiterläuft.
ich hatte zwar schon mal in der Doku gesucht aber nicht nichts gefunden, 
wo steht das der Prescaler weiter läuft wenn man den Timerwert ändert?

von spess53 (Gast)


Lesenswert?

Hi

>ich hatte zwar schon mal in der Doku gesucht aber nicht nichts gefunden,
>wo steht das der Prescaler weiter läuft wenn man den Timerwert ändert?

Wozu gibt es dann einen separaten Prescaler-Reset?

MfG Spess

von holger (Gast)


Lesenswert?

>ich hatte zwar schon mal in der Doku gesucht aber nicht nichts gefunden,
>wo steht das der Prescaler weiter läuft wenn man den Timerwert ändert?

Das steht nirgendwo. Wozu auch? Natürlich läuft der weiter.
Wer sollte ihn daran hindern?

von Peter II (Gast)


Lesenswert?

holger schrieb:
> Das steht nirgendwo. Wozu auch? Natürlich läuft der weiter.
ich kann mir schon vorstellen das wenn man mit dem Timer etwas genau 
timen will das es so gewollt ist das der Prescaler zurückgesetzt wird, 
wenn man die Timerwert neu lädt oder den Timer aktiviert.

von spess53 (Gast)


Lesenswert?

Hi

>Wer sollte ihn daran hindern?

Der Prescaler-Reset.

MfG Spess

von spess53 (Gast)


Lesenswert?

Hi

>ich kann mir schon vorstellen das wenn man mit dem Timer etwas genau
>timen will das es so gewollt ist das der Prescaler zurückgesetzt wird,
>wenn man die Timerwert neu lädt oder den Timer aktiviert.

Nein. Der Prescaler läuft unabhängig.

MfG Spess

von Vuvuzelatus (Gast)


Lesenswert?

>...wenn man mit dem Timer etwas genau timen will das es so gewollt ist das
>der Prescaler zurückgesetzt wird, wenn man die Timerwert neu lädt oder den
>Timer aktiviert.

Nein, es ist genau umgekehrt: Das Timing wird präzise, wenn der 
Prescaler beim Neuladen eines Timerwertes gerade nicht zurücksetzt 
wird. Unter der Voraussetzung, dass zum Zeitpunkt des Neuladens der 
Prescaler garantiert noch nicht sein Maximum erreicht und einen neuen 
Timertick erzeugt hat, bleibt das Timing exakt, auch wenn das Neuladen 
unregelmäßig etwas früher oder später erfolgt. Wer daran noch zweifelt, 
möge es mal im Simulator durchspielen, da kann man das schön 
nachvollziehen.

Der Prescaler wird nur zurückgesetzt, wenn im Code ein Prescaler-Reset 
ausgelöst wird (durch Setzen des Bits PSR01 bzw. PSR2 im SFIOR). 
Übrigens: Beim ATmega8/16/32 teilen sich T/C0 und T/C1 einunddenselben 
Prescaler. Das beantwortet die Frage indirekt auch.

von Peter II (Gast)


Lesenswert?

Vuvuzelatus schrieb:
> Nein, es ist genau umgekehrt: Das Timing wird präzise, wenn der
> Prescaler beim Neuladen eines Timerwertes gerade nicht zurücksetzt
> wird.

es kommt darauf man was man machen will, wenn man in X ms etwas mit dem 
timer ab jetzt auslösen will und dafür den timerwert setzt, dann wird es 
genauer wenn man auch gleichzeitig den prescaler auf 0 setzt.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Wenn es genauer sein soll, dann nehme  eine TXCO wie die FOX924 Typen 
von Digikey.

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
Noch kein Account? Hier anmelden.