Taktgenauigkeit v. Quarz

Maddin schrieb:
> Nur geht die Uhr um 46 Sekunden am Tag

Sind rund 530 ppm. Für einen Quarz zu viel.
Aber ich erinnere mich ganz dunkel, auf den Arduinos ist kein Quarz, 
sonder "nur" ein Keramik-Resonator drauf. Die können durchaus 500 ppm 
daneben liegen.

Maddin schrieb:
> kann der Quarz der da standardmäßig drauf ist so ungenau sein oder zu so
> einer Ungenauigkeit führen?

Ja.

Zumal auf den Arduinos oft nicht mal ein Quarz sondern ein
keramischer Resonator drauf ist der noch ungenauer als
ein Quarz sein kann.

Ob Quarz oder keramischer Resonator kann nur ein detailliertes
Foto hier klären.

Jupp!
Hier sieht man den direkten Vergleich: 
https://arduino.stackexchange.com/questions/30964/does-the-arduino-uno-have-two-crystals

Lins in rot der 16 MHz-Quarz für den USB-Chip, rechts in gelb der 
Keramik-Resonator für den eigentlicgh Arduino-ATmega.

Der Original nano soll laut Stückliste [1] ebenfalls einen "echten" 
Quarz mit 20 ppm.
Die Clones nutzen wohl nur einen Keramik-Resonator, so auch der auf dem 
Bild von Ali.


[1] https://www.arduino.cc/en/uploads/Main/ArduinoNanoManual23.pdf

Grundsätzlich ist es nicht sinnvoll aus einem Prozessor-
Takt eine "genaue" Uhr abzuleiten da diese Taktquellen
im Allgemeinen nicht auf Genauigkeit ausgelegt sind.

Nicht umsonst haben viele Mikrocontroller zusätzlich zur
Prozessor-Takt-Quelle oft einen separaten Quarz-Anschluss
bzw. Takteingang zum Implementieren einer Uhr (RTC).

Hallo

ja die abweichung ist recht typisch für so einen Quarz (der sicherlich 
zu der niederigsten Preisklasse gehört).

Um bei deinen 32ms Wert zu bleiben:

1 Minute sind 60000mS - 32ms sind davon dann 0,053...% oder 533ppm was 
für eine Uhr viel ist aber für einen Billigstquarz gar nicht so 
schlecht.

Hinzu kommt:
Stimmen die Lastkapazitäten?
10pf bis 33pf gehen in der Praxis zwar "immer" - aber wirklich passende 
Werte sind besser und haben ihre Berechtigung. Das Problem ist:
Für solche Quarze gibt es selten Datenblätter - meist ist es sogar 
unmöglich herauszufinden welchen genauen Typ man da vor seinen Augen hat 
(Hersteller, Typenreihe).
Selbst der Hersteller der Boards hat nicht immer die Daten, bzw. 
interessiert sich nicht dafür weil es ja auch mit sogar 1% 
Frequenzabweichung (und soviel hat bei weiten nicht mal ein noch 
billiger Keramikschwinger) funktioniert.
Bei Einkaufkosten für den deutschen Endkunden von unter 4Euro (nach all 
den Zwischenhändlern, Abgaben und Versandkosten) darf man da auch nichts 
erwarten - die echten Material und Herstellungskosten pro komplettes 
bestücktes und mit den Bootloader geflshten Bord dürften sehr deutlich 
unter 1Euro liegen - und da sind die "Kostentreiber" die Platine (deren 
Herstellung selbst) und den µC liegen - für den Quarz bleibt da ein 
(wenn überhaupt) ein einstelliger Centbetrag übrig...

Tja und letztendlich:
Es kann auch schon an den fertigen Bibliotheken usw. liegen wo der 
Ersteller oft selbst nicht weis wie viele Takte diese benötigt und ob 
ein Durchlauf unter allen Umständen immer gleich lang dauert.
Selbst die internen Hardwaretimer der µC müssen ja letztendlich durch 
Software (Firmware - das Programm - den Sketch) behandelt werden...

Daher:
Alles vollkommen normal - besser wird es mit einen RTC der einen eignen 
(auf Frequenzgenauigkeit "getrimmten" Quarz nutzt) oder halt einen 
Externen Takt einer hochwertigen Taktquelle - es muss ja nicht gleich 
das Rubidium Frequenznormal sein...

Qu Artz schrieb:
> Es kann auch schon an den fertigen Bibliotheken usw. liegen

Maddin schrieb:
> Kleine einfache Uhr programmiert und über Seriell ausgegeben.
> Das funktioniert auch alles.

Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut, falls es im 
Winter mal glatt ist.
Das hat man schon vor 70 Jahren besser hingekriegt mit Zahnpasta und 
Bleistiftminen.

Beispiel: Selbst die billigste Armbanduhr ist nur ca. 1 Sekunde pro Tag 
off, d.h. max. Abweichung von ca. einer halben Minute im Monat = ca. 12 
ppm!
Und dabei erlebt sie 24-stündige Temperaturzyklen von 15 bis 20 K!

Noch Mal:
Die Arduino-Clones haben keinen Quarz, sondern einen Keramik-Resonator 
und gar keine Lastkapazitäten.

Marek N. schrieb:
> Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut

Nö.

So ein Quarz ist durchaus in der Mehrheit der Anwendungsfälle
geeignet einen ausreichend genauen Takt zu generieren.

Wie bereits erwähnt sind Keramikresonatoren als Zeitbasis für Uhren 
ungeeignet.
Aber auch bei Quarzen gibt es grosse Unterschiede. (In Grundgenauigkeit, 
Temperaturdrift, Alterung)
Eine gute Übersicht zu Quarzgenauigkeiten gibt es z.B. hier:
https://www.sprut.de/electronic/mess/frequenz.htm#erde

Die Bastellösung:
Resonator runter und Uhrenquarz an die Stelle.

Das bringt zwar neue Probleme, sollte aber auch deutlich exakter werden 
können.

Qu Artz schrieb:
> ja die abweichung ist recht typisch für so einen Quarz (der sicherlich
> zu der niederigsten Preisklasse gehört).

So einen schlecht geschliffenen Quarz zu finden, dürfte schwierig sein. 
Guck mal bei den Toleranzangaben zu den im Handel angebotenen Typen.
Hier wird wohl eher ein Keramikresonator der Schuldige sein.

Hi Maddin

vielleicht ist ja doch ein Quarz drauf?

Ich habe mal einige Arduino Leonardos (ATmega32u4) und ProMicros (auch 
ATmega32u4) untersucht. Alles 5V-Ausführung mit 16 MHz.
Hintergrund: Ich hatte mal die Uhrzeit von einer RTC (DS1307, auf einer 
billigen Logger-Shield-Platine) verwendet und mich sehr geärgert, dass 
die RTC um 5 Sek/Tag falsch ging.
Der Quarz auf den Arduino-Platinen war hingegen deutlich korrekter (die 
genaue Zahl weiss ich nicht mehr so genau, aber eben <<60 ppm).
Eigentlich hatte mich mehr die Temperaturabhängigkeit interessiert, da 
mein Logger in einer eher warmen Umgebung läuft.

Auch wenn Du in Deiner Frage das Thema Timer und Software ausklammerst, 
hierzu Anmerkungen:

(1) Nachdem Deine Uhr nachgeht, solltest Du prüfen, ob bei deinem 
Timer-Interrupt nichts verloren geht, z.B. wenn er seinerseits 
unterbrochen wird (für den Fall, dass Du das Timerregister nachlädst).

(2) Hier ein Tipp, wie man eine Uhr in der Arduino-Umgebung einfach 
realisiert, also ohne Interrupt und ohne dass Timerzyklen verloren 
gehen.

1

unsigned int tOld;

2

unsigned int tNew;

3

unsigned int tDif;

4

unsigned int tTaskTime;

5

void setup() {

6

    tNew = millis();

7

}

8

void loop() {

9

    tOld = tNew;

10

    tNew = millis();

11

    tDif = tNew-tOld; // unsigned!, Ergebnis ist immer >=0!

12

    tTaskTime += tDif;

13

    if(tTaskTime>1000) {

14

        tTaskTime -= 1000;

15

        // Hier der Programmcode für die Uhr...

16

        // z.B.  Sek = Sek + 1;

17

        // und bei Bedarf die Ausgabe über Seriell

18

    }

19

}

[sorry, ich poste zum ersten Mal in dem Forum, den Code kann man sicher 
schöner formatieren]

Martin

Martin MMH schrieb:
> [sorry, ich poste zum ersten Mal in dem Forum, den Code kann man sicher
> schöner formatieren]

Vor Allem kann man die Hinweise zum Posten von Code
berücksichtigen. Das macht es schon deutlich besser.

Siehe "Wichtige Regeln - erst lesen, dann posten!"

Martin MMH schrieb:
> Ich habe mal einige Arduino Leonardos (ATmega32u4) und ProMicros (auch
> ATmega32u4) untersucht. Alles 5V-Ausführung mit 16 MHz.

Die brauchen den auch weil sie selber USB machen. Auch das läuft mit 
Keramikresonator aus dem Takt.

Martin MMH schrieb:
"Martin MMH" schrieb:
>  ... dass die RTC um 5 Sek/Tag falsch ging.
>  Der Quarz auf den Arduino-Platinen war hingegen deutlich korrekter
>  (die genaue Zahl weiss ich nicht mehr so genau, aber eben <<60 ppm).
Korrekt müsste es heissen:
  Die RTC DS1307 ging um 12 Sek/Tag zu schnell, was mich sehr geärgert 
hat.
  Der Quarz des Arduino-Leonardo war wesentlich genauer, also <<140ppm
  (was natürlich keine besondere Kunst ist).

@weiter weg:
  sorry, wenn jetzt auch das Zitieren hier noch nicht geklappt hat.


Martin

Jörg W. schrieb:
> Wenn du mit "Uhrenquarz" einen der üblichen 32768-Hz-Quarze meinst
Jawoll!
Und natürlich muss man umfusen.
Wenn man dann auch noch OSCCAL, anhand dieses Quarzes kalibriert, 
bekommt man eine über alle Spannungs- und Temperaturebereiche genügend 
stabile interne 8MHz hin, so dass die UART immer im Timing bleibt.

Marek N. schrieb:
> Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut, falls
> es im
> Winter mal glatt ist.
> Das hat man schon vor 70 Jahren besser hingekriegt mit Zahnpasta und
> Bleistiftminen.

Kommt auf die Anwendung an!

Wir haben viele IO-Boards die nur über UART (per RS422) kommunizieren. 
Und hier sind 500ppm völlig ok. Die internen RC-Oszillatoren der STM32 
sind nämlich oft genau einen Zaken zu ungenau für sowas *1).
Da käme eine billige Taktquelle mit 1000ppm genau recht!

*1) Das hat ein Kollege ausprobiert, der wollte das nicht glauben. Bis 
die Produktion angerufen hat: "Bei der Platine haben wir 5% 
Ausschussrate beim Test der Kommunikation". Als Entwickler sagt man bei 
sowas nicht "ach das macht doch jeder so". das lernt man schnell ;-)

Jörg W. schrieb:
> 100 ppm ist für einen Quarz
> wirklich schon arg grenzwertig.

Diese 100 ppm sind doch frei erfunden worden!
> Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut,

Und wenn es tatsächlich so wäre, dann sind wohl die Lastkapazitäten 
entfernt oder frei nach Nase bestückt worden.

Jörg W. schrieb:
> Diese sollten in der Tat eher Toleranzen im Bereich von 50 ppm haben;
> bei Uhrenquarzen sind auch 10 ppm zu haben. 100 ppm ist für einen Quarz
> wirklich schon arg grenzwertig.

Ja, danke für die Korrektur, das stimmt.

Marek N. schrieb:
> Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut, falls
> es im Winter mal glatt ist.
> Das hat man schon vor 70 Jahren besser hingekriegt mit Zahnpasta und
> Bleistiftminen.

Damals existierten Schwingquarze, deren Gehäuse man aufschrauben
konnte. So liess sich tatsächlich durch Bleistift-Auftrag die
schwingende Masse vergrössern. Der Quarz schwang dann deutlich unterhalb 
der Nennfrequenz. Noch in den 1970er-Jahren eine
durchaus gebräuchliche Methode bei Hams.

https://www.radiomuseum.org/r/mil_gb_quartz_ft243ft_24.html

Marek N. schrieb:
> Selbst die billigste Armbanduhr ist nur ca. 1 Sekunde pro Tag off

Eher sogar weniger. Die schlechteste Uhr die ich gesehen habe kostete 
etwa 3 Euro und hatte 5 Minuten Abweichung pro Monat.

Marek N. schrieb:
> Ein Quarz, der 100 ppm daneben liegt taugt nur als Streugut, falls es im
> Winter mal glatt ist.

Du weißt nicht, wie schlecht Prozessorquarze sein können.
Normalerweise interessiert das niemanden, wenn die herumeiern. Wir 
hatten ein System, wo sich Mobilgerät und Station zyklisch in einem 
Zeitfenster treffen sollen, da kam ein richtig teurer Quarz an den 
Controller.

> Beispiel: Selbst die billigste Armbanduhr ist nur ca. 1 Sekunde pro Tag
> off, d.h. max. Abweichung von ca. einer halben Minute im Monat = ca. 12
> ppm!
> Und dabei erlebt sie 24-stündige Temperaturzyklen von 15 bis 20 K!

Die Armbanduhr hat es relativ einfach, solange sie am Menschen ist, ist 
die Temperaturabweichung überschaubar gering.

DCF77 heisst die allein selig machende Lösung.

Udo schrieb:
> DCF77 heisst die allein selig machende Lösung.

Falls man den noch irgendwo gut genug durch das ganze 
Schaltnetzteilrauschen empfängt. NTP oder DCF sind gute Alternativen.

Die absolute Abweichung mag nicht unerheblich sein, meistens ist sie 
aber halbwegs konstant. Das heißt, man kann einfach in Software 
korrigieren.

GPS und RDS wären auch eine Lösung...

Ich versteh das nicht das Autohersteller das bis heute nicht hinbekommen 
ihre Borduhren auf eine dieser Quellen zu synchroninsieren.

Die Borduhr von meinem Smart z.B. geht pro Woche um 1 Minute zu langsam.
Aber naja, ich muss das Ding eh jedesmal bei Sommer/Winterzeit neu 
stellen.

Horst schrieb:
>> DCF77 heisst die allein selig machende Lösung.
>
> Falls man den noch irgendwo gut genug durch das ganze
> Schaltnetzteilrauschen empfängt.

Ich wohne etwa 300km von Mainflingen entfernt und habe keine Probleme, 
DCF77 zu empfangen. Selbst wenn Störungen auftreten, läuft die Uhr mal 
eben ein paar Stunden frei - als Küchenuhr vollkommen ausreichend.

Die Erfahrung mit neun DCF-Analoguhren Marke Lebensmitteldiscounter, 
in beliebiger Ausrichtung im Haus verteilt, sagt mir, dass DCF77 in der 
Praxis sehr gut funktioniert.

NTP oder DCF sind gute Alternativen.

NTP ist keine Alternative, weil es von diesem verfluchten Internet 
abhängig ist. Wieso DCF eine Alternative zu DCF77 ist, kannst nur Du 
wissen.

Solltest Du GPS gemeint haben, das taugt auch nicht, weil es eine 
Außenantenne benötigt.

60/40 schrieb:
> GPS und RDS wären auch eine Lösung...

Wie ich sagte, GPS ist innerhalb des Hauses nicht nutzbar.

Es ist eine Weile her, dass ich mich mit RDS beschäftigt habe, die 
Zuverlässigkeit ließ stark zu wünschen übrig.

> Ich versteh das nicht das Autohersteller das bis heute nicht hinbekommen
> ihre Borduhren auf eine dieser Quellen zu synchroninsieren.
>
> Die Borduhr von meinem Smart z.B. geht pro Woche um 1 Minute zu langsam.

Die Uhr in meinem Ford hat keine erkennbare Abweichung, Navi mit GNSS ab 
Werk drin.

> Aber naja, ich muss das Ding eh jedesmal bei Sommer/Winterzeit neu
> stellen.

Das ist bei mir auch so, obwohl das System Sat-Empfang hat und die 
Fahrzeugposition kennt.

Ganz idiotisch, Softwaredilletanten: Ich stelle im Menü die Zeitzone ein 
(Berlin), betätige "mit GPS synchronisieren" und stehe danach eine 
Stunde daneben.

Nun ja, zumindest erfüllt das Auto seine Grundfunktion, sich anständig 
fahren zu lassen und viel Platz zu bieten.

Udo schrieb:
> Die absolute Abweichung mag nicht unerheblich sein, meistens ist sie
> aber halbwegs konstant. Das heißt, man kann einfach in Software
> korrigieren.

Mache das auch genau so. Habe eine DS3231 und schaue da 1x am Tag drauf. 
Berechne die Differenz, setze neu und die Software berechnet die 
Abweichung pro Minute. Die liegt für gewöhnlich im zweistelligen 
Millisekunden Bereich. Der Wert wird immer in der 59 Sekunde vom 
Millisekunden Ladewert (1000ms) abgezogen oder drauf gerechnet, je 
nachdem ob die "frei" laufende Uhr vor oder nach geht. So läuft die Uhr 
nach dem ersten Tag immer recht genau synchron zur RTC ohne das dort 
etwas springt oder zappelt (nur beim ersten Sync im Sekundenbereich, 
danach nicht wieder) Da der Wert immer wieder (alle 24h) mit berechnet 
und ggf. korrigiert wird, sollte es Schwankungen geben durch Drift wegen 
Temperatur oder Alterung.

Aber es gibt sicher noch bessere Konzepte. Die DS3231 ist ja schon sehr 
genau, habe die Pufferbatterie gegen einen Goldcap ersetzt, damit läuft 
sie rund 7 Tage ohne Versorgung weiter und ist weitgehend 
wartungsfrei...

Thorsten S. schrieb:
> So läuft die Uhr
> nach dem ersten Tag immer recht genau synchron zur RTC

...hört sich kompliziert an, ich würde immer einfach öfter 
synchronisieren!
Dafür ist die RTC doch da.

JJ