Hi Leute! Hab da mal ne Frage. An meiner Tischuhr habe ich das Problem, dass die Uhrzeit innerhalb einer Woche zwei Min. nach geht. Bei der Suche nach einer Problemlösung hier im Netz, habe ich feststellen müssen, dass es das Problem wohl öfters gibt. Aber eine zufriedenstellende Lösung konnte ich leider nicht finden. Im Anhang ein Vorschlag von mir zur Problemlösung. Kann man das so machen? Im Datenblatt vom Atmega 32 steht, dass keine Kondensatoren erforderlich sind. Wie würdet/habt ihr das Problem gelöst. Danke für eure Antworten... LG Christian
Angehängte Dateien:
-
uhrenquarz.png
5,4 KB
Die Kondensatoren haben sowohl auf die Amplitude als auch auf die Frequenz einen Einfluss. Theoretisch kann man die beiden Kondensatoren so auswählen, dass sowohl Amplitude und Frequenz optimal sind. Ist aber nicht so einfach, wenn die Kapazität des Oszilloskop-Tastkopfes höher ist, als der optimale Kondensator. Das Einfachste: Deine Software korrigiert die Uhr andauernd. Das Zweiteinfachste: Dein Programm legt das Uhrenquarz-Signal auf einen Ausgabepin. Mit einem Oszi kontrollierst du den Jitter. (Bei zu kleiner Amplitude steigt der Jitter an). Nach einer Woche kontrollierst du die Abweichung die Uhrzeit und drehst versuchsweise schneller/langsamer.
Also, DS3231 und STM32 scheiden aus. Die Uhr ist ja vom Aufbau her fertig. Die Umbauarbeiten wären einfach zu komplex. Die Korrektur über die Software, wäre Plan B. Am besten gefällt mir der Lösungsansatz "Das Zweiteinfachste" vom User "Noch einer" ^^ Ich programmiere in Bascom. Kann ich also einfach einen der Pins C6 oder C7 holen und auf z.b. C0 legen? Bsp. 'quarz PC7 quarz Alias Pinc.7 Config quarz = Input 'Zum Oszi oszi Alias Portc.0 Config oszi = Output do oszi = quarz loop end
Soweit ich weiß, kann man den Quarzpin nicht als digitalen Eingang nutzen. Geht nur über mehrere Ecken. Ein Timer-Compare-Match setzt seinen Outputpin. Direkt, ISR gäbe auch wieder Jitter.
Christian B. schrieb: > Im Anhang ein Vorschlag von mir zur Problemlösung. C1 laß weg (oder < 10 pF) und für C2 nimm max. 15 pF, wobei ich jetzt nicht darauf geachtet habe, welcher Pin des AVR Ein- oder Ausgang ist. Ggf. daher auch noch vertauschen.
-Die meisten Kontroller verlangen zwei gleich große Kondensatoren in der Quarz-Beschaltung. - Hundert pF als einer der beiden Kondensatoren ist viel zu groß, üblich sind bei Uhrenquarzen etwa zehn pF. -Trimmer sind anfällig gegen Feuchtigkeit oder Verschmutzung. Dazu kommt noch, dass es sehr teure Bauelemente sind, die dazu noch viel Platz brauchen, zuindestens im Vergleich zu einem SMD-Festkondensator. Stand der Technik ist die Verwendung von Festkondensatoren. Auch der Abgleich per Durchfräsungen von Leiterbahnen ist außer Mode gekommen. Man korrigiert per Software. (Siehe Thema "die genaue Zeit...") Will man größere Genauigkeit, nimmt man normalerweise eine funkgesteuerte Uhr. Da wird der im Laufe des Tages entstehende Fehler von einigen Sekunden während der Nacht behoben. Meist gegen zwei Uhr, wegen der dann wenigen Energiesparlampen usw. und wegen der Zeitverschiebungen Sommer-Winter. Bei Deiner Schaltung dürften schon die Streukapazitäten so groß sein, dass der Trimmer garnicht die notwendige Korrektur schafft. Merkmal: der Fehler ist immer negativ, dh. die Uhr läuft zu langsam, wenn die Kondensatoren zu groß sind.
:
Bearbeitet durch User
Die Ungenauigkeit von -2.0E-4 kommt mir sehr groß vor. Sicher, dass kein Programmfehler vorliegt? Bei ATmega16, der sollte so etwa dem ATmega32 entsprechen, korrigiere ich per Software, musste aber bei einigen hundert Stück bislang im äußersten Fall nur rund ein Zehntel korrigieren, nämlich max. 2.5E-5; dabei sind am Quarz keinerlei Kondensatoren zusätzlich angeschlossen. Zum Messen könnte man in Ihrem Fall bei einer speziellen Tastenbedienung in einen eigenen Programmteil wechseln, der auf einem freien Pin ein Rechtecksignal ausgibt; der ATmega32 hat leider kein per Fuse einschaltbares CLKOut wie die neueren uC.
Christian B. schrieb: > Bei der Suche nach einer Problemlösung hier im Netz, habe ich > feststellen müssen, dass es das Problem wohl öfters gibt. Und Lösungen dafür gibt es natürlich auch, z.B. Beitrag "Die genaue Sekunde / RTC"
Und mein Nachsatz war Unsinn, da sich CLKO ja auf den Hauptoszillator bezieht.
Peter R. schrieb: > Meist gegen zwei Uhr ... und wegen der > Zeitverschiebungen Sommer-Winter. Dann doch eher kurz nach drei.
Christian B. schrieb: > Im Anhang ein Vorschlag von mir zur Problemlösung. [den Quarz ziehen durch Verwendung eines Trimmers als Bürde] > Kann man das so machen? Natürlich kann man das so machen. Tatsächlich macht man das seit Jahrzehnten schon so. Da der niederfrequente Oszillator des AVR allerdings sehr auf Stromsparen ausgelegt ist, kann es sein daß er bei einem großen Mißverhältnis der beiden Bürdekondensatoren nicht mehr anspringt. Dann kannst du entweder an den Fuse-Einstellungen spielen (normalen Quarzoszillator für z.B. 1MHz auswählen) oder du baust den Quarzoszillator nach Lehrbuch mit einem CMOS-Gatter auf und speist den Takt in den µC.
Christian B. schrieb: > Die Korrektur über die Software, wäre Plan B. Wieso nur "Plan B"? das ist doch das, was man am schnellsten und mit minimalstem Aufwand machen kann. Für jeden Normalbegabten sollte es schon allein auf Grund eben dieser Eigenschaften eindeutig "Plan A" sein. Zumal man bei einer Softwarekorrektur u.U. auch gleich noch den Temperaturgang des Quarzes kompensieren kann (wenn man einen auch nur mäßig genauen Temperatursensor zur Verfügung hat), anstatt im Gegenteil zusätzliche Temperaturgänge (und zwar weit signifikantere als den des Quarzes alleine) durch zusätzliche Bauelemente im frequenzbestimmenden Kreis einzuführen... Da solltest du vielleicht nochmal ernsthaft drüber nachdenken...
c-hater schrieb: > durch zusätzliche Bauelemente im frequenzbestimmenden > Kreis einzuführen... Das Bauteil, das dominant die Frequenz bestimmt, ist der Quarz ;-) Daher reicht es erfahrungsgemäß, einen passenden Lastkondensator auszumessen und in der Serie durch eine Festkapazität zu ersetzen.
m.n. schrieb: > Das Bauteil, das dominant die Frequenz bestimmt, ist der Quarz Natürlich. Und der ist selber recht gut temperaturkompensiert, aber recht hilflos bezüglich der Bürdekapazitäten. Was man ja leicht daran sehen kann, daß man ihn eben mit solchen Kapazitäten ziemlich leicht in die gewünschte Richtung "ziehen" kann, mit der Umgebungstemperatur aber nur in sehr viel geringerem Maße. Passt das bis hierhin in deinen Schädel? Nun sind aber diese Bürdekapazitäten auch mit einer gewissen Temperaturabhängigkeit ausgestattet und zwar einer, die um viele, viele Größenordnungen über der des Quarzes liegt. Nun braucht man also nur den Einfluß auf die Frequenz durch die Bürdekapazität mit dem Temperatureinfluß auf eben diese Kapazität zu multiplizieren, um den Einfluß auszurechnen, den die Temperatur nunmehr indirekt zusätzlich auf die Frequenz nimmt. Kannst du mir immer noch folgen? Und wenn man dann noch die Wirksamkeit der beiden temperaturinjizierten Einflußgrößen bezüglich der Frequenz vergleicht, zeigt sich fast immer, daß der störende Einfluß durch die Temperatur durch den Einsatz von Bürdekapazitäten zum Ziehen meist deutlich größer wird. (Im Falle von Trimmern sogar ziemlich drastisch größer) > Daher reicht es erfahrungsgemäß, einen passenden Lastkondensator > auszumessen und in der Serie durch eine Festkapazität zu ersetzen. Was bezüglich der Temperatureinflüsse genau nur eins bewirkt: Du ersetzt die Temperaturkennlinie des Trimmers durch den der Festkapazität. Also neu rechnen, aber in aller Regel wieder das gleiche Ergebnis, bloß nicht ganz so erschreckend mies...
Also, die Korrektur über die Software ist mit Sicherheit eine einfach zu realisierende Lösung. Von den Möglichkeiten temperaturabhängiger Differenzen zu korrigieren mal abgesehen. Aber..... Das Problem ist ja aber, dass der Quarz nicht mit der nötigen Präzision schwingt. Da ist es doch naheliegend, dass man den Fehler erst mal an Ort und Stelle versucht zu beseitigen, bevor man in der Software "flickschusterei" betreibt. Entschuldigt bitte dieses schlimme Wort! Deshalb ist es Plan B :-) Dennoch werde ich die Softwarekorrektur in mein Programm einbauen. Wie würdet Ihr das machen? Soll ich den Timer entsprechend mit einem anderen Wert vorladen, oder soll ich ganz einfach eine Variable festlegen, die nach einer bestimmten Zeit addiert wird? Aber ganz oben auf der Liste steht bei mir jetzt erst mal einen möglichst genauen Takt aus dem Quarz raus zu bekommen.
Es sind noch keine Kapazitäten angeschlossen. Was lt. Datenblatt auch eigentlich nicht nötig ist :-/
Genau. Aber woher kommt dann diese enorme Abweichung nach unten? Schlechte Verdrahtung, ungewöhnlicher Quarz, oder doch ein Programmfehler?
Christian B. schrieb: > > An meiner Tischuhr habe ich das Problem, dass die Uhrzeit innerhalb > einer Woche zwei Min. nach geht. Oha...! > Bei der Suche nach einer Problemlösung hier im Netz, habe ich > feststellen müssen, dass es das Problem wohl öfters gibt. Aber eine > zufriedenstellende Lösung konnte ich leider nicht finden. Nein? Nochmal oha... > Im Anhang ein Vorschlag von mir zur Problemlösung. > Kann man das so machen? Im Prinzip ja, wenn man nicht solche Monsterkapazitäten nimmt. Mit 8-22pF bist Du besser bedient, der Quarz läuft einen Tick schneller, die Uhr geht weniger nach. Einfach solange versuchen, bis einer passt. Sind die C zu klein, schwingt der Quarz schlecht an (oder gar nicht), sind sie zu groß läuft er zu langsam (oder auch nicht). Statt C erstmal Lötösen einbauen, so ruinierst Du die Platine nicht. Old-Papa
Christian B. schrieb: > Es sind noch keine Kapazitäten angeschlossen. Was lt. Datenblatt auch > eigentlich nicht nötig ist :-/ Dann helfen dir aber zusätzliche C nur dann, wen du sie in Reihe zum Quarz legst. Mit den gezeichneten Bürdekapazitäten kannst du den Quarz nur noch weiter nach unten ziehen.
Das Quarz ist unmittelbar neben den Pins des µC eingelötet. Also nur drei bis vier mm Leiterbahnlänge. Das sollte nicht das Problem sein. Um einen Programmfehler auszuschließen, hab ich ein ganz einfaches Programm geschrieben. S. Anhang....
Christian B. schrieb: > Es sind noch keine Kapazitäten angeschlossen. Was lt. Datenblatt auch > eigentlich nicht nötig ist :-/ Kenne zwar Dein Datenblatt nicht, in meinem sind diese fein säuberlich eingezeichnet und beschrieben! Old-Papa
c-hater schrieb: > Kannst du mir immer noch folgen? Ich kann Dir folgen, aber ich werde nicht 'bei Dir sein'. Es überrascht ja nicht, wenn ein selbsternannter Kondensator-Hasser sich abfällig über Kondensatoren äußert.
Da muss ich jetzt leider passen, ich kann nur Assembler. Z.B. finde ich hier im 'uhrenquarz.bas' nicht einmal die Stelle, wo der asynchrone Oszillator initialisiert wird.
S. Landolt schrieb: > Aber woher kommt dann diese enorme Abweichung nach unten? Quarz mit unpassender Lastkapazität, würde ich sagen. Ist das vielleicht so ein moderner kleiner SMD-Quarz? Für µCs wie den Mega32 braucht man die älteren großen Bauformen an Stimmgabelquarz, die noch die nötige Lastkapazität aufweisen. BTW: Wenn das Ding zu langsam schwingt, bekommst Du ihn mit mehr Kapazität dran nur noch langsamer. Ein Kondensator in Reihe könnte helfen, aber der verschlechtert die Güte...
Aus dem Code: Config Clock = Soft Bedeutet das vielleicht, daß der Takt der Uhr per Software erzeugt wird und nicht von T2?
Hier der Auszug aus dem Datenblatt des Atmega 32: Timer/Counter Oscillator For AVR microcontrollers with Timer/Counter Osc illator pins (TOSC1 and TOSC2), the crystal is connected directly between the pins. No external capacitors are needed. The Oscillator is opti- mized for use with a 32.768 kHz watch crystal. Ap plying an external cl ock source to TOSC1 is not recommended. Zum code: config clock = soft, bedeutet, das Bascom eine Softwareuhr aufruft, in der die Werte 1 min sind 60 Sekunden, 60 min sind eine Stunde usw. automatisch erstellt. Wenn an den o.g. Eingängen ein Quarz angeschlossen ist, wird der verwendet. Da brauch man beim Mega 32 nix einstellen oder programmieren. Achso... Nein, es ist kein SMD Quarz. Es is n ganz normales in so nem runden Blechgehäuse :-)
:
Bearbeitet durch User
Und woher weiß Bascom, dass da überhaupt an TOSC1/2 ein Quarz angeschlossen ist? Vielleicht möchte man ja auch, warum auch immer, seine Zeit vom Hauptoszillator ableiten, wo könnte man das einstellen?
Ihn dünkt', er säh 'nen Kauderwelsch, der war nicht zu verstehn. Er guckt noch mal und merkt', es war doch ein Programm zu sehn. "Wenn das die Zukunft ist", sprach er, "wird's Altwerden nicht schön."
Ich habe bisher eigentlich in all meinen Schaltungen die Option so vorgesehen, dass man da n Uhrenquarz anschliessen kann und sonst nix. Wenn man die Uhr über z.b. einen Uhrenchip und dann über i2c einließt, dann muss man bei config clock = user eingeben.
Ich hätte jetzt vermutet, dass da config clock = asyn oder Timer2 oder T2 oder so etwas stehen muss.
> Ich habe bisher eigentlich in all meinen Schaltungen > die Option so vorgesehen, dass man da n Uhrenquarz > anschliessen kann und sonst nix. Könnte es sein, dass dann bisher immer die Zeit nicht von diesem, sondern vom Hauptoszillator abgeleitet wurde?
S. Landolt schrieb: > Ich hätte jetzt vermutet, dass da > config clock = asyn oder Timer2 oder T2 oder so etwas > stehen muss. Ist auch der Idee nach richtig. So wie ich http://avrhelp.mcselec.com/index.html?config_osc.htm verstehe, läuft die Kiste im Moment ausschließlich mit dem internen 2-MHz-Oszillator. Kann mich auch täuschen; habe weder von Bascom noch von AVRs Ahnung.
Vor ein paar Jahrzehnten las ich mal eine Anleitung das Gehäuse des Quarzes zu öffnen und von der Kontaktierung entweder mit einem Glashaarpinsel etwas abzuradieren oder mit einem weichen Bleistift etwas aufzutragen, um den Quarz abzugleichen. Bein den heutigen Preisen von Quarzen wäre das doch mal einen Versuch wert :-)
Ich habe seit etlichen Jahren 2 Uhren mit At90S2313, die mit 4MHz-Quarzen getaktet werden und keine extra Uhrenquarze. Es sind 2x22pF dran. Diese Uhren sind so genau, daß ich sie nur beim Sommer/Winterzeitwechsel stellen muß. Auch extra RTC-Schaltkreise habe ich noch nie vermisst. MfG Paul
Paul B. schrieb: > Ich habe seit etlichen Jahren 2 Uhren mit At90S2313, die mit > 4MHz-Quarzen getaktet werden und keine extra Uhrenquarze. Ich fürchte, die AVR-/Bascom-Leute verstehen unter einem "internen Oszillator" den internen RC-Oszillator und unter einem "externen Oszillator" den internen Oszillator mit externem Quarz. Einen echten externen Oszillator gibts in diesem Weltbild nicht. Falls meine Annahme stimmt, würde die Uhr des TO im Moment mit einem 2-MHz-RC-Oszillator laufen...
und warum dreht Ihr nicht ein wenig am Trimmer oder verändert das andere C ?
Also, ob ich da jetzt den internen oder externen Oszillator benutze, und ob das externe ein Quarz oder ein anderer Taktgeber ist, bestimmt man ja aber über die Fuses. Und nicht unbedingt im Code. Die beiden Eingänge TOSC1 und TOSC2 sind ja extra für einen asynchronen Takt gedacht. Haben also nix mit dem Takt des Prozessors zu tun. Das mit dem config osc hab ich noch nie beachtet. Darauf wird auch in keinem Programmbeispiel für eine Uhr eingegangen. So wie ich das in der Hilfe verstehe ist das nur für ATXMEGA Chips. Hat also nix mit Atmega 32 oder so zu tun.
Genau das ist ja die Frage! Macht es Sinn das über zusätzliche Kondensatoren zu lösen, und wenn ja, wie? Oder ist es eher ein Softwaresache, oder oder oder....
Paul B. schrieb: > Diese Uhren sind so genau, daß ich sie nur beim Sommer/Winterzeitwechsel > stellen muß. Das ist doch nun wirklich eine Sache, die man der Software überlassen sollte, nachdem sich die Politik auf einen Algorithmus für den Umschalttermin geeinigt hat und diesen anscheinend als heilige europäische Kuh weiter verehren will, obwohl so richtig keiner weiss, was das wirklich bringt.
Wolfgang schrieb: > obwohl so richtig keiner weiss, > was das wirklich bringt. Jedes Jahr immer das gleiche weinerliche Gejammer. Es bringt ganz einfach, dass man im Sommer einen längeren Abend hat.
Christian Betzen schrieb: > Macht es Sinn das über zusätzliche Kondensatoren zu lösen Kondensator wo? Die Stelle, an der Sie es versuchen, hat m.E. gar keinen Einfluss auf Ihr Programm; was sich übrigens leicht feststellen lässt, nämlich indem Sie den Quarz dort, an TOSC1/2, ablöten und schauen, ob die Uhr weiterläuft. Die Benutzung eines 32 KiHz-Quarzes ('Uhrenquarz') an TOSC1/2 ist programmtechnisch nicht ganz einfach, und ich kann mir nicht vorstellen, dass Bascom das irgendwie ohne weitere Vorgaben vollautomatisch erledigt bzw. erledigen könnte - wie auch? > $crystal = 16000000 Sehe ich das richtig, dass Sie für den Hauptoszillator einen 16 MHz Quarz benutzen? Wenn ja, mit welchen Kondensatoren, und ist CKOPT eingeschaltet? Ich nehme an, Ihre Zeit kommt von hier.
eric schrieb: > und warum dreht Ihr nicht ein wenig am Trimmer > oder verändert das andere C ? Das hatten wir doch schon. Der TE beklagt sich über eine zu langsam laufende Uhr, obwohl im Moment noch gar keine Kapazitäten verbaut sind. Ausserdem ist gar nicht klar, mit welchem Oszillator die Uhr gerade angetrieben wird. Wenn es tatsächlich der 32kHz Uhrenquarz ist, bringen externe Kondensatoren gar nichts, wenn sie so verschaltet werden wie im ersten Bild, denn dann läuft der Quarz noch langsamer. Um den Quarz nach oben zu ziehen, müsste man eine Kapazität in Reihe mit dem Quarz schalten. Man muss also erstmal klären, ob der Uhrenquarz das zeitbestimmende Element hier ist.
Hallo, zu Bascom kann ich nichts sagen, zum Uhrenquraz nur soviel: mit Kondensatoren wird er nur noch langsamer, wenn er jetzt schon zu langsam ist. Ich habe hier gerade eine Steckbrett-Uhr rumliegen. Zeitbasis ist der 16MHz Quarz am AVR, die Abweichung ca. 2s pro Tag, müßte so 2.5E-6 sein, das kommt mir realistisch vor. Da könnte ich problemlos einen der 22pF durch einen 10/40pF Trimmer erstzen und ziehen. Ist mir aber im Moment egal, ich teste nur die Ansteuerung der VFD-Röhren. Gruß aus Berlin Michael
> Abweichung ca. 2s pro Tag, müßte so 2.5E-6 sein
Ersteres ist okay, aber Letzteres - nanu?
Guten Morgen! Also, hab eben mal schnell das Uhrenquarz ausgelötet. Und wie zu erwarten läuft die Uhr dann nicht. Also kann man ja dann schon mal sagen, das der Takt für die Uhr von diesem Quarz kommt. Der Rest des Programms läuft ganz normal ab. Wird also von dem 16MHz Quarz angetrieben. Der 16MHz Quarz wird mit 22pF gezogen. CKOPT war bis gestern eingeschaltet. Habe es jetzt mal ohne probiert, weil ich mir nicht sicher war, ob da nicht interne Kapazitäten an den TOSC Anschlüssen aktiviert werden. Die Uhr ist jetzt neun Stunden gelaufen und zeigt eine Differenz von zwei Sekunden zu meiner Funkuhr. Da das Quarz jetzt ausgelötet ist, werde ich mal ein anderes Uhrenquarz einlöten.
:
Bearbeitet durch User
CKOPT wirkt auf XTAL1/2, und diese zusätzlichen 36 pF wären dann zusammen mit den 22 pF die Ursache für das zu langsame Laufen, wenn! - ja wenn die Uhr nicht stehenbliebe bei abgehängtem TOSC. Jetzt weiß ich erstmal nicht mehr weiter.
Hab eben mal in meiner Elektronikkiste gekramt und noch nen Aufbau mit nem Atmega16 einem LCD und der gleichen Kombination von Quarz und Uhrenquarz gefunden. Werd da jetzt mal ein kleines Uhrenprogramm aufspielen und parallel laufen lassen. Aber ich rechne nicht mit einem besseren Ergebnis.
Christian B. schrieb: > Die Uhr ist jetzt neun Stunden > gelaufen und zeigt eine Differenz von zwei Sekunden zu meiner Funkuhr. Das ist doch schon mal eine Ansage. Eine ganze Menge, das entspricht ja etwa 2/32400 = 6,17 * 10E-5 Entweder benutzt du jetzt den Algorithmus aus Beitrag "Die genaue Sekunde / RTC" der ja voraussetzt, das du die Abweichung mal gemessen hast oder trimmst die Hardware. Wenn die Uhr vorgeht, helfen Bürdekapazitäten, wie in deinem Eröffnungsbeitrag. Wenn die Uhr nachgeht, musst du den Quarz noch oben ziehen - wie o.a. geht das, indem du einen C in Reihe mit dem Quarz schaltest. Je kleiner dieser ist, umso höher schwingt der Quarz, allerdings wird die Gefahr des Abreissens der Schwingung immer grösser. Probier mal so etwa 33pF-56pF. Du solltest aber, wenn vorhanden, mal einen anderen Quarz einsetzen.
Irrtum meinerseits (noch kein Kaffee heute morgen): CKOPT schaltet zwischen full-swing und low-power Modus, die 36 pF gelten nur bei 'Low-frequency Crystal Oscillator'.
Mal ne ganz andere Idee: Du könntest auch nen DCF77 Empfänger an den Mikrocontroller hängen. Den lässt du einmal pro Tag synchronisieren. Dann hast du kein Problem mehr, wenn der Quarz nicht ganz passt.
Oder noch besser: eine DCF77-Uhr per Kamera einlesen. Dann hat man gleich eine automatische Sommer-Winterzeit Umschaltung. Auch der 29.02. wird völlig ohne aufwändige Software ermittelt. Einfacher geht es doch nicht :-(
Ohne jetzt die genauen Verhältnisse zu kennen ..... vielleicht muss das so sein .... ich kenne ja auch die Quarz-Daten des Thread-Erstellers nicht ...... aber die 100pF Lastkapazität am Quarz kommen mir sehr hoch vor. Könnte ein Grund sein warum die Uhr etwas zu langsam läuft bzw der Quarz etwas zu niederfrequent schwingt. Niemand hält einem davon ab die Funtktionsgrenzen des Aufbaus mal auszutesten und zu sehen bei welchen Extremwerten der Last-Cs das Zeugs noch funktioniert (Temperaturbereicht, Versorgungsspannung...) Vieleicht ist bei diesen "Streuparametern" dann auch die gewünschte Genauigkeit dabei.
Ja, das is schon klar, dass mit dem DCF. Aber darum geht es hier erst mal nicht. Die Uhr soll mit Quarz so genau wie möglich laufen. Im Vergleich ist mein analoger Wecker auf meinem Nachttisch genauer wie meine Tischuhr. Das kann ich so noch nicht ganz akzeptieren. Eine Uhr aus Zahnrädern besser als eine mit nem µC....
Christian B. schrieb: > Eine Uhr > aus Zahnrädern besser als eine mit nem µC.... Eine Uhr aus Zahnrädern hat heutzutage auch einen Quarz drin.
eric schrieb: > Es bringt ganz einfach, dass man im Sommer einen längeren Abend hat. Und was bringt es im Winter?
Wolfgang schrieb: > Und was bringt es im Winter? ...die normale Zeit. Wenn Du das nicht von alleine weisst, verstehe ich, warum Du über den Sommer jammerst.
Also liebe Leute! Ich glaube wir können hier an dieser Stelle den Sack zumachen. Die Uhr läuft jetzt 8 Stunden und ich kann keine Differenz feststellen. Die Lösung für das Problem war der Quarzwechsel. Beide Quarze sind aus dem Sortiment von R*ichelt. Das Quarz was nicht richtig funktionierte, hat die Best. Nr. 0,032768-L6. Das was jetzt verbaut ist hat die Best. Nr. 0,032768. Vielleicht kann ja mal jemand sich die Artikel anschauen und mir erklären, warum das eine funktioniert und das andere nicht. Danke an alle, die sich mit mir zusammen den Kopf zerbrochen haben, um nach einer Lösung zu suchen.
Christian B. schrieb: > Die Lösung für das Problem war der Quarzwechsel. Sag ich doch ;-) Am Quarztyp wird es nicht liegen; auch diese mini-Quarze liefern im abgeglichenen Zustand (Trimmer-C ;-) die Sollfrequenz.
Tja, da haben Sie wohl ganz ungewöhnliches Pech gehabt. Von genau dieser Reichelt-Bestnr. '0,032768-L6' habe ich über die Jahre hinweg über 700 Stück verbaut, zuerst an ATmega16, dann an ATmega16A, und immer lag die nötige Korrektur innerhalb von 2.5E-5, ich hatte lediglich einen einzigen Totalausfall beim Quarz.
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.