Hi, ich habe einen arduino nano v3 mit Atmega168: https://de.aliexpress.com/item/32825427901.html als Grundlage für eine Uhr. Timer 1 genommen, und entsprechend eingestellt (1ms int.) Kleine einfache Uhr programmiert und über Seriell ausgegeben. Das funktioniert auch alles. Nur geht die Uhr um 46 Sekunden am Tag (32ms pro Minute) nach. Es ist mir klar das man tausend Dinge dafür wissen muss, aber mal ausgegangen davon dass es nicht am Timer oder meiner Software liegt - kann der Quarz der da standardmäßig drauf ist so ungenau sein oder zu so einer Ungenauigkeit führen? Danke. M.
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: > Hier sieht man den direkten Vergleich: Man sieht es auch in seinen Aliexpress-Bildern gut. > Der Original nano soll laut Stückliste [1] ebenfalls einen "echten" > Quarz mit 20 ppm. Nicht beim Nano V3. Der benutzt einen FT232RL (der keinen Quarz braucht) fürs USB und einen CSTCW16M0V53-R0 von MuRata als MCU-Takt. Sieht man bei Arduino nur in den Eagle-Designdaten: https://content.arduino.cc/assets/Nano-reference.zip https://www.murata.com/en-us/products/productdetail?partno=CSTCE16M0V53-R0 MuRata gibt ±0,5 % als Toleranz an, das wären bis zu 400 Sekunden pro Tag als mögliche Abweichung.
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
Hallo, es gibt auch bezahlbare Quarze mit 10 - 30 ppm. Wenn das reicht okay. Nur würde ich für eine Uhr eine RTC nehmen. Entweder deren Daten auslesen oder deren 1Hz Takt verwenden. Eine DS3231 S oder SN. Problem ist, als nackter Chip derzeit nirgends erhältlich. ;-)
Die Bastellösung: Resonator runter und Uhrenquarz an die Stelle. Das bringt zwar neue Probleme, sollte aber auch deutlich exakter werden können.
Auch richtig gefused oder benutzt das Ding den internen RC-Oszillator?^^
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
:
Bearbeitet durch Moderator
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!"
weiter weg schrieb: > Vor Allem kann man die Hinweise zum Posten von Code > berücksichtigen Ich habe mal die Code-Tags nachgezogen. EAF schrieb: > Die Bastellösung: > Resonator runter und Uhrenquarz an die Stelle. Wenn du mit "Uhrenquarz" einen der üblichen 32768-Hz-Quarze meinst: danach dürfte einfach gar nichts mehr gehen. Der Oszillator ist schlicht für diese Frequenz nicht ausgelegt. Man müsste zuvor den Quarzoszillator in den Fuse-Einstellungen abwählen, danach sind diese beiden Pins tatsächlich per Software-Alternative für einen 32-kHz-Quarz geeignet. Martin MMH schrieb: > vielleicht ist ja doch ein Quarz drauf? Sieht im Foto bei Aliexpress überhaupt nicht danach aus. Der Keramikresonator dort passt zur beobachteten Abweichung recht gut dazu.
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.
Horst schrieb: > Auch das läuft mit Keramikresonator aus dem Takt. Fullspeed-USB kann gerade so klappen (±0,25 %), je nach Resonator. Der oben genannte MuRata-Resonator wäre mit ±0,5 % natürlich schon daneben.
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 ;-)
Blumpf schrieb: > Kommt auf die Anwendung an! Marek hat sich nicht allgemein auf Taktquellen bezogen, sondern auf Quarze. 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.
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.
Beitrag #6895517 wurde von einem Moderator gelöscht.
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
Maddin schrieb: > Nur geht die Uhr um 46 Sekunden am Tag (32ms pro Minute) nach. Wenn das Arduino-Board keinen großen Temperaturschwankungen ausgesetzt ist (wegen der Temparaturabhängigkeit der Frequenz bei den verwendeten Keramik-Resonatoren) kann man die Nacheilung der Uhrzeit einfach per Software in der msec-Interrupt-Routine korrigieren, indem man den msec-Zähler beim Sekundenüberlauf (Sekunden = 59 --> 0, sprich jede Minute) im vorliegenden Fall auf 32 setzt statt auf 0. Mit dieser Methode kann man durchaus ca. 1 Sekunde Abweichung pro Monat erreichen. Mehr dazu siehe http://www.led-treiber.de/html/leds_display.html#Zwischenzeit, wobei in meinem Beispiel etwas gröber mit 10 msec-Interrupts gearbeitet wird. Deshalb wird hier etwas ungenauer sogar nur 1/10 der Abweichung korrigiert. Bei meinem Arduino-Uno-Clone war die Abweichung der Resonator-Frequenz ohne Korrektur "nur" 200 ppm.
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.
Zwei Details... Uhrenquarze sind anders spezifiziert. Uhrenquarze sind so gut weil sie bei konstanter Temperatur laufen. Und auch deren Parameter so optimiert sind fuer diese Temperatur. zweitens. Auch wenn bei einem besseren quarz der Fehler kleiner wird, wird er nicht Null. Daher sollte ein konzept vorhanden sein : - wie wird die Uhr neu gesetzt. zB wenn das Geraet mit dem PC verbunden wird. - Weshalb ist welche Abweichung zulaessig. Falls die Uhr neu gesetzt wird muss man mit Loggern aufpassen. Ploetzlich haben die aufgenommenen Daten einen Ueberlap, resp eine Zeitperiode fehlt.
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.
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.
Eberhard H. schrieb: > Wenn das Arduino-Board keinen großen Temperaturschwankungen ausgesetzt > ist (wegen der Temparaturabhängigkeit der Frequenz bei den verwendeten > Keramik-Resonatoren) kann man die Nacheilung der Uhrzeit einfach per > Software in der msec-Interrupt-Routine korrigieren, indem man den > msec-Zähler beim Sekundenüberlauf (Sekunden = 59 --> 0, sprich jede > Minute) im vorliegenden Fall auf 32 setzt statt auf 0. > > Mit dieser Methode kann man durchaus ca. 1 Sekunde Abweichung pro Monat > erreichen. Noch genauer kann es werden, wenn man die Kompensation temperaturabhängig macht. Der uC hat ja einen Temperatursensor. Bedingt aber, dass man mit 2 einigermaßen konstanten Temperaturen kalibrieren kann.
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.
Manfred schrieb: > Ich wohne etwa 300km von Mainflingen entfernt und habe keine Probleme, > DCF77 zu empfangen. Das ist ja bei der Wellenlänge noch nicht einmal im Fernfeld. :-) Interessanter ist das in > 1000 km Entfernung vom Sender. Da trennt sich die Spreu vom Weizen. Hier im Arbeitszimmer auf meinem Basteltisch habe ich keine Chance, einen DCF77-Empfänger sinnvoll zu betreiben. 5 m weiter weg im Wohnzimmer ist das kein Problem, einigermaßen brauchbare Ost-West-Ausrichtung der Antenne hilft aber sehr. Schön an diesen langen Wellen ist, dass man sie halt selbst im Keller gut empfangen kann. Hier werkelt eine zeitgesteuerte Hofbeleuchtung, die hat mit ihrem DCF77-Empfänger kein Problem.
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
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.