Hallo, es gibt eine ganze Seite Themen zu dieser Uhr, die auch auf allen möglichen Arduinio Shields verbaut ist. Ich habe sie vor 5 Jahren das letzte Mal benutzt und geflucht, ich habe sie heute wieder als blaue Platine am Ard. und fluche immer noch weiter! Diese Uhr verhält sich "komisch". Warum? 1. Die Genauigkeit der RTC scheint auf seltsame Weise damit zusammen zu hängen, wie oft man sie abfragt. Je öfter desto ungenauer wird sie. Wie der I2B Bus Decoder, der ja mit on-chip ist da beteiligt ist weiss ich nicht, der dürfte ja auf den Teiler keinen Einfluss haben. 2. Eine RTC ist nichts weiter als ein Teiler mit Registern. In einem CPLD ist sowas easy zu kodieren, die Genauigkeit hängt nur vom Takt ab und von nichts anderem. 3. Die Uhr hat einen Taktausgang der 1Hz ausgibt, zumindest die DS1308 hat ihn. Dran gemessen ist dort eine Abweichung feststellbar, d.h. es sind eben nicht 32768 Takte sondern vielleicht 4-5 mehr oder weniger. 4. Die Uhr verliert öfter ihre Zeitinfos und zwar wenn man die I2C Leitungen abklemmt und wieder anschliesst, ich habe das mehrfach reproduzieren können. Ursache absolut unbekannt. Plötzlich steht Blödsinn in den Registern trotz Batteriepufferung. Vor Jahren habe ich einen 15pF Drehko Trimmer parallel zum Quarz geschaltet und sie mit einem FZ auf die Sekunde genau bei 20 Grad eingestellt. Nach 2 Jahren im Schrank und einer zwischenzeitlichen Scheidung von meiner Frau, holte ich sie raus und stellte fest, dass die Abweichung keine 3 Minuten waren, 3 Minuten in 2 Jahren, einschliesslich Aufenthalt in Umzugskartons, Keller usw !!!!! Aber die Arduinio Platinen haben keinen Drehko drin, alles smd und viel zu klein um da was zu machen. Wie zur Hölle kann ich also eine dieser blauen Platinen die auch ein E2PROM draufhaben dazu bringen genau zu laufen? Lässt sich der Quarz irgendwie ziehen oder sollte man die Abweichung pro Tag einfach messen und vom Controller rechnerisch korrigieren lassen? Gruss, Christian
Christian J. schrieb: > 1. Die Genauigkeit der RTC scheint auf seltsame Weise damit zusammen zu > hängen, wie oft man sie abfragt. Je öfter desto ungenauer wird sie. Wie > der I2B Bus Decoder, der ja mit on-chip ist da beteiligt ist weiss ich > nicht, der dürfte ja auf den Teiler keinen Einfluss haben. Diese Platine ist ein typischer Arduino-Hardware-Rotz. Von Dilettanten für Dilettanten designt und entsprechend schlecht ist sie auch. Die vielen I2C Abfragen streuen in den nicht korrekt ausgewählten / falsch belasteten Uhrenquarz ein und verursachen damit Störungen auf der Taktversorgung. Darum zählt das Ding eben falsch. Christian J. schrieb: > 2. Eine RTC ist nichts weiter als ein Teiler mit Registern. In einem > CPLD ist sowas easy zu kodieren, die Genauigkeit hängt nur vom Takt ab > und von nichts anderem. Ja es ist ein Zähler. Ein CLPD ist völlig überdimensioniert. Realisieren kann man das Diskret, auf Silizium (siehe deine RTC), mit Mikrocontrollern, FPGA, GAL, ... Christian J. schrieb: > 3. Die Uhr hat einen Taktausgang der 1Hz ausgibt, zumindest die DS1308 > hat ihn. Dran gemessen ist dort eine Abweichung feststellbar, d.h. es > sind eben nicht 32768 Takte sondern vielleicht 4-5 mehr oder weniger. Eben genauso genau wie deine Taktquelle. Frequenzen genau zu vermessen bedarf allerdings sehr guter Messinstrumente. Mal die Fehlergrenzen im Handbuch des Messinstruments lesen und dann rechnen ... Christian J. schrieb: > 4. Die Uhr verliert öfter ihre Zeitinfos und zwar wenn man die I2C > Leitungen abklemmt und wieder anschliesst, ich habe das mehrfach > reproduzieren können. Ursache absolut unbekannt. Plötzlich steht > Blödsinn in den Registern trotz Batteriepufferung. Vermutlich baust du einen Kurzschluss oder die Platine ist unzureichend entstört und das Ding macht einen Reset. Christian J. schrieb: > Aber die Arduinio Platinen haben keinen Drehko drin, alles smd und viel > zu klein um da was zu machen. Ja und ? Wer Arduino nimmt der will auch keine ernsthaften Anwendungen machen ... Christian J. schrieb: > Wie zur Hölle kann ich also eine dieser blauen Platinen die auch ein > E2PROM draufhaben dazu bringen genau zu laufen? Lässt sich der Quarz > irgendwie ziehen oder sollte man die Abweichung pro Tag einfach messen > und vom Controller rechnerisch korrigieren lassen? Ein gutes Schaltungslayout, ein richtig gewählter Quarz, eine bessere RTC als dieses 0-8-15 Wald und Wiesen Ding...
Christian J. schrieb: > Wie zur Hölle kann ich also eine dieser blauen Platinen die auch ein > E2PROM draufhaben dazu bringen genau zu laufen? Schmeiss sie raus und nimm eine richtige Uhr. Beitrag "Die genaue Sekunde / RTC" Wenn man vom Digikey Lagerbestand auf die Einsatzhäufigkeit der DS1308 schließen kann, bist du einer der wenigen, der sie benutzt. Und was hat das mit dem EEPROM zu tun? Hat dein Prozessor keins? > 4. Die Uhr verliert öfter ihre Zeitinfos und zwar wenn man die I2C > Leitungen abklemmt und wieder anschliesst, ich habe das mehrfach > reproduzieren können. Was hattest du denn beim Abziehen für Pegel auf der Leitung? Oder hattest du gar den µC stromlos, so dass die Schutzdioden durch Kontaktprellen erratische Low-Pegel auf den I2C-Leitungen erzeugt haben.
Irgendein RTC hat in der Tat den Bug, daß man ihn nicht zu oft auslesen darf, sonst geht er nach dem Mond. Obs der 1307 ist, weiß ich nicht. Einen extra RTC benutze ich nicht mehr. Moderne MCs können in der Regel selber als RTC laufen. Z.B. der ATmega164 kann direkt ein 32kHz Quarz mit Power-Save (1µA Verbrauch). Ohne extra RTC entfällt auch das ganze Gefuddel mit der Datenumwandlung, also Stellen der Zeit zum RTC und wieder auslesen zum MC und den dadurch möglichen Race-Conditions. Man hat bereits alles bequem in internen Variablen und das umständliche I2C entfällt. Ich bevorzuge dabei die Zählung als 32Bit Sekunden und nachfolgende Umrechnung inklusive Sommerzeit.
Christian J. schrieb: > 1. Die Genauigkeit der RTC scheint auf seltsame Weise damit zusammen zu > hängen, wie oft man sie abfragt. Je öfter desto ungenauer wird sie. Das ist ein Effekt, der auch von RTCs im PC-Bereich wohlbekannt ist. Die Ursache ist (wie so oft) die Profitmaximierung als Grundgesetz des Kapitalismus. Das sorgte hier ganz konkret dafür, daß das gierige BWLer-Pack den Technikern den Aufwand für ein double buffering als Kostentreiber verboten hat. Damit blieb den Technikern als einzige Möglichkeit, um durch Überlauf bedingte inkonsistente Auslesedaten zu vermeiden, den Überlauf an sich zu verhindern. Sprich: den Takt während einer Abfrage zu suspendieren. Die Konsequenz ist, daß jede Abfrage das Potential hat, den Fehler der RTC zu erhöhen. Je nachdem, an welcher Stelle der Teilerkette der Takt unterdrückt wird, ist der dadurch verursachte Fehler größer oder kleiner, allerdings sinkt im Gegenzug die Wahrscheinlichkeit, daß eine Abfrage tatsächlich einen Impuls "klaut". Das gilt aber leider nur, solange die Abfragefrequenz klein in Relation zum RTC-Takt ist und nicht auch noch parasitäre Synchronisationseffekte durch eine "unglückliche" Programmierung auftreten, was leider oft der Fall ist, wenn Leute programmieren, die von Hardware keine Ahnung haben und denen der Sachverhalt des fehlenden double buffering und der sich daraus ergebenden Konsequenzen nicht bewußt ist. Die allgemein benutzte Gegenstrategie umfaßt folgende Punkte: 1) Nur eine Abfrage der RTC pro System-Startup. 2) Etablierung eines von der RTC unabhängigen Laufzeit-Systems zur Zeitmessung. 3) Gewinnung einer RTC-unabhägigen Zeitreferenz zur Laufzeit des Systems und Bestimmung eines Korrekturfaktors für die RTC sowie "Nachstellen" der RTC. So zu finden z.B. in allen üblichen Betriebssystemen von PCs...
Peter Dannegger schrieb: > Ich bevorzuge dabei die Zählung als 32Bit Sekunden und nachfolgende > Umrechnung inklusive Sommerzeit. Hast Du vielleicht ein Beispiel für deinen Ansatz? Norbert
@ c-hater (Gast) >Das sorgte hier ganz konkret dafür, daß das gierige BWLer-Pack den >Technikern den Aufwand für ein double buffering als Kostentreiber >verboten hat. Was oft genug daran liegt, dass sich Techniker viel zuviel gefallen lassen. >Damit blieb den Technikern als einzige Möglichkeit, um durch Überlauf >bedingte inkonsistente Auslesedaten zu vermeiden, den Überlauf an sich >zu verhindern. Sprich: den Takt während einer Abfrage zu suspendieren. Kannst du das belegen oder ist das nur mal wieder Spekulation?
c-hater schrieb: > Damit blieb den Technikern als einzige Möglichkeit, um durch Überlauf > bedingte inkonsistente Auslesedaten zu vermeiden, den Überlauf an sich > zu verhindern. Sprich: den Takt während einer Abfrage zu suspendieren. Aus dem Datenblatt: When reading or writing the time and date registers, secondary (user) buffers are used to prevent errors when the internal registers update. When reading the time and date registers, the user buffers are synchronized to the internal registers on any I2C START. The time information is read from these secondary registers while the clock continues to run. Wem soll man nun mehr glauben, dem Datenblatt oder c-hater?
Wem soll man nun mehr glauben, dem Datenblatt oder c-hater? Ich glaube eher dem Datenblatt. Immerhin ist das Problem bekannt seit es Timer und Uhrenbausteine gibt. Schon der Intel 8253 Timerbaustein hatte Latches um Probleme bei 2 8 bit Zugriffen auf einen 16 bit Zähler zu vermeiden. Der Aufwand dafür ist wirklich nicht sehr groß und bereitet auch einem BWLer keine Kopfschmerzen. Im übrigen: Mein DS1307 ist alles andere als genau. Allerdings geht das Ding vor. Kann man schlecht durch Anhalten des Taktes (was möglich aber meist sinnlos ist) erklären.
DS1307-hater schrieb im Beitrag #3258177: > Allerdings geht das > Ding vor. Kann man schlecht durch Anhalten des Taktes (was möglich aber > meist sinnlos ist) erklären. Das Datenblatt ist recht restriktiv, was das Layout angeht. Die Uhr läuft mit extrem niedriger Leistung. Der 32kHz Oszillator ist hochohmig. Wenn dann "normale" Datenleitungen in der Nähe verlegt sind, kommt es schnell zu extra Taktimpulsen. Aber ohne Messungen ist das alles Spökenkiekerei.
Christian J. schrieb: > Die Genauigkeit der RTC scheint auf seltsame Weise damit zusammen zu > hängen, wie oft man sie abfragt. Je öfter desto ungenauer wird sie Danke für den Tipp, jetzt weiß ich, worans liegt.
Georg G. schrieb: > Aus dem Datenblatt: > When reading or writing the time and date registers, secondary (user) > buffers are used to prevent errors when the internal registers update. > When reading the time and date registers, the user buffers are > synchronized to the internal registers on any I2C START. The time > information is read from these secondary registers while the clock > continues to run. > > Wem soll man nun mehr glauben, dem Datenblatt oder c-hater? Ich persönlich glaube nichts, was ich nicht selbst überprüft habe. Schon garnicht glaube ich das unbesehen, was anonyme Poster wie ich behaupten. Deren Äußerungen sind allenfalls als Denkanstoß nützlich. Solltest du genauso halten. Überprüf' die Sache einfach selbst. Hoppla, hast du ja eigentlich schon... Denk' einfach mal genauer über die erzielten Ergebnisse nach und darüber, wie sie sich erklären ließen...
Der Weg, Fakten die schwarz auf weiß im Datenblatt stehen, aus lauter paranoia anzuzweifeln, kann eigentlich nur in den Wahnsinn führen.
cyblord ---- schrieb: > Der Weg, Fakten die schwarz auf weiß im Datenblatt stehen, aus lauter > paranoia anzuzweifeln, kann eigentlich nur in den Wahnsinn führen. Najaaa... es soll ja auch Errata geben, die auf einem anderen Blatt stehen...
Ein Knut schrieb: Najaaa... es soll ja auch Errata geben, die auf einem anderen Blatt stehen... Wir sollten morgen weiterdiskutieren. Anscheinend ist dem einen oder anderen die gegenwärtigige Hitze nicht gut bekommen! Ich bin aus leidvoller Erfahrung kein Freund dieses Bausteins. Aber deshalb grundlos Verschwörungstheorien in die Welt zu setzen ist nicht mein Stil. Bis morgen!
Guest schrieb: > Zeigen! Meine Anmerkung bezog sich auf den Satz: cyblord ---- schrieb: > Der Weg, Fakten die schwarz auf weiß im Datenblatt stehen, aus lauter > paranoia anzuzweifeln, kann eigentlich nur in den Wahnsinn führen. Und da gibt es wirklich genug Bausteine. RTCs verwende ich auch hin und wieder, dann aber die DS1390U-33+.
Falk Brunner schrieb: >>Damit blieb den Technikern als einzige Möglichkeit, um durch Überlauf >>bedingte inkonsistente Auslesedaten zu vermeiden, den Überlauf an sich >>zu verhindern. Sprich: den Takt während einer Abfrage zu suspendieren. > > Kannst du das belegen oder ist das nur mal wieder Spekulation? Kann mich an eine solche RTC erinnern. Reicht dir das? z.B. bei der PCF8583 gibt es auch eine Einschränkung. Da muß man schnell genug lesen. Jetzt aus dem Kopf, denn ich hatte sie seit 1993 nicht mehr in der Hand.
@ Abdul K. (ehydra) Benutzerseite >> Kannst du das belegen oder ist das nur mal wieder Spekulation? >Kann mich an eine solche RTC erinnern. Reicht dir das? Nein. Die Erinnerung ist oft genug trügerisch. Ausserdem leben wir ja in einem wissenschaftlichen Zeitalter und nicht bei den alten Indiandern, die alles nur mündlich überliefert haben. >z.B. bei der PCF8583 gibt es auch eine Einschränkung. Da muß man schnell >genug lesen. Jetzt aus dem Kopf, denn ich hatte sie seit 1993 nicht mehr >in der Hand. Darum meine Forderung nach einem nachvollziehbaren Beleg.
Tja Pech. Ich arbeite nicht für umsonst an sinnlosen Projekten. Aber danke für deine Einschätzung meiner Persönlichkeit. Schau mal bei der RTC72421 - könnte diese sein. Mehr Arbeit stecke ich da jetzt nicht rein.
Abdul K. schrieb: > .B. bei der PCF8583 gibt es auch eine Einschränkung. Da muß man schnell > genug lesen. Jetzt aus dem Kopf, denn ich hatte sie seit 1993 nicht mehr > in der Hand. Das ist Nonsense, in Kapitel 7.1 unten steht ja, dass es einen Buffer gibt, der bei Lesezugriffen die Zähl-Register reinzieht. Alles andere wäre auch eine Fehlkonstruktion, da es sich hier um ein asychrones Design handelt, wo ein Buffer hin muss. Habs vorhin nochmal ausprobiert, die hat wieder die Minuten verloren beim I2C Kabelumstecken und Abziehen der Versorgung. Mag sein, dass das nicht vorgesehen ist aber dämlich ist es auf alle Fälle. Und die Genauigkeit geht defintiv sofort runter wenn man ein Massaker auf dem I2C Bus anrichtet durch Dauerlesen. Kann mir nur vorstellen, dassdas iregndwas mit EMV zu tun hat, irgerndwelceh Spikes oder Peaks, die den Quarz stolpern lassen.
Sorry Christian, aber der erste und zweite Absatz widersprechen sich in der Kompetenz. Ich habe mitnichten gesagt, es wäre die 8583! Das war ne reine Vermutung. Darfst dir aber sicher sein, daß beide meine Behauptungen bei RTCs vorkamen. Nur welche Typen kann ich dir leider nicht mehr sagen. Warum mich das nicht mehr interessiert? Weil es mittlerweile CMOS-Controller gibt. RTCs haben wir vor 20 Jahren mit NMOS-Brätern verwendet. Ich hoffe, du hast wenigstens 100 Ohm in SDA, SCL UND Ground!
Was passiert denn, wenn du auf dem I2C Radau machst mit einer nicht existenten Zieladresse? Geht die Uhr anschließend auch falsch? Dann hast du definitiv ein Problem mit Einstreuungen. Schau dir doch mal die Hinweise in App Notes zum Layout an und vergleiche mit deinem Layout. Der Oszillator läuft mit deutlich weniger als 1uW. Wenn in der Nähe eine Fliege hustet, ist er kurz verwirrt.
Häufiges Auslesen über I2C kann ein Problem sein. Ich habe das in einem Projekt erlebt, wo es allerdings mit einer anderen RTC (von NXP) durch häufiges Auslesen (bis zu 4x pro Sekunde) nach einigen Tagen Laufzeit zu Problemen kam. Dies wurde nach Fehleranalyse dadurch erklärt, daß bereits ein umgekipptes Bit auf dem I2C-Bus aus dem Lese- einen Schreibvorgang macht und die Zeit verstellt. Interessanterweise waren die einzigen RTCs mit einer sinnvollen "Schreibschutzfunktion", die ich gefunden habe, von Holtek. Andere Hersteller scheinen nicht davon auszugehen, daß der Anwender so aggressiv liest.
Mal abgesehen davon, das das Design dieser blauen Arduino RTC Platinen nicht besonders gut ist - ich hatte hier mehrere, auf denen ein falscher Quarz verbaut war (6 pF statt 12,5 pF). Ich hab da jetzt einen DS32kHz dran (statt Quarz), dann stimmt auch die Genauigkeit. Viele Grüße, egberto
egberto schrieb: > falscher > Quarz verbaut war (6 pF statt 12,5 pF). Ich hab da jetzt einen DS32kHz > dran (statt Quarz), In pF werden i.A. Kondensatoren angegeben. Und ob der falsch oder richtig ist für den Quarz, kann man von außen nicht sehen. Er muss einfach zum Quarz passen. Verrätst du uns noch, was ein DS32kHz ist?
Ist dein google defekt?? schon mal was von load capacitance als Parameter von Quarzen gehört? Beim ds32khz nimm einen der ersten 10...20 Treffer der Suchmaschine deiner Wahl. egberto
Nur kann man leider nicht sehen was das für ein Quarz ist, da er keine Beschriftung ´hat ...
einfach mal gegen einen anderen tauschen (aus altem Wecker oder so..) der Standard ist eigentlich 12,5 pF oder wie schon gesagt ds32khz anschließen. egberto
egberto schrieb: > schon mal was von load capacitance als Parameter von Quarzen gehört? Schon mal gehört, dass diese Kapazität nicht immer gleich ist? Was meinst du, warum der Quarzschleifer bei Sonderanfertigungen immer fragt "wieviel pF hättens gern?"
c-hater schrieb: > Nur eine Abfrage der RTC pro System-Startup. Das ist Quark. Ich habe mehrere DS1307 laufen, unter anderem in zwei Heizungssteuerungen, mit entsprechenden Temperaturschwankungen im Heizraum, die gehen in mehreren Jahren vielleicht mal ein paar Min falsch. Die RTCs werden dabei 24/7 8mal pro Sekunde abgefragt (weil ich da einwandfrei zu verarbeitende Zeitdaten bekomme und nicht einsehe, warum der AVR das nochmal zählen muss, wenn die RTC das schon macht). Auf dem gleichen Bus werden bis zu 32 Sensoren abgefragt und bis zu 32 Relais angesteuert. Da gibt es weder Probleme mit falschen Bits noch mit Verstellen der RTCs. Allerdings sind die RTCs auch ordentlich gepuffert und der Quarz kurz und mit Guard angebunden. Christian J. schrieb: > Habs vorhin nochmal ausprobiert, die hat wieder die Minuten verloren > beim I2C Kabelumstecken und Abziehen der Versorgung. Wenn das wärend der Datenübertragung passiert, kann es schon zum Überschreiben kommen, wenn die falschen Daten empfangen werden. Beim Abziehen der Versorgung hab ich aber noch nie Ausfälle gehabt. Eventuell mal den Brown-Out vom Controller richtig setzen. Schaltung? Layout? Es gibt für die RTCs Vorgaben, besonders zur Anbindung des Quarzes. Z.B. sollte man den Guardring tunlichst vorsehen und die Kapazitäten am Quarz klein halten (kurze Leitungen). Die RTC ist seeehr energiesparend, das heisst aber auch, dass die keine nennenswerte kapazitive Last am Quarz verträgt.
Hallo Zusammen. Ja ich weis ich bin etwas Spät, aber trotzdem... Ich Baue die Schaltung mit dem DS 1307 Selber mit DIP8 Sockel. mein Tip: Ich knipse die Lötstifte des Sockels unten ab, dort wo der Quarz sitzt (Pin 1 und 2). Den Quarz Stecke ich direkt zusammen mit dem IC oben rein. Somit habe ich keine falschen Kapazitäten und das ding läuft richtig! Die I2C Leitung ist auch so kurz wie möglich zu halten. Als Netzteil nehme ich ein altes Laptop-Netzteil, um den Trafo ca. 20cm von den Datenleitungen und uP fernzuhalten.
Tatsächlich Leichenschändung, aber das Thema habe ich kürzlich auch gehabt. Allerdings nutze ich die DS1307 eher zum verächtlich angucken - die sind ziemlich 5V-orientiert. Ich arbeite aber meist mit 3,3V. Vor einem halben Jahr hatte ich mit einem ATmega328 (als Fertigboard Arduino Pro Mini), 4-stelligem 7-Segment, LiIon-Akku und DS1302-Board eine Uhr gebastelt. So ohne alles und mit 20cm DuPont-Steckern lief das Ding nach 4 Monaten schon mehr als 20 Minuten vor. Nachdem ich den Code aufgeräumt und korrigiert hatte, kam kaum eine Besserung zustande. Den Quarz auf dem Board habe ich noch an die Massefläche gelötet sowie an die Versorgung aus der Richtung µC Abblockkondensatoren. Ich betreibe das 7-Segment im ~1kHz Multiplex, das streut offenbar gut was ein. Ich stelle die Uhr nun jeden Abend um 5 Sekunden zurück; Sommer- und Winterzeit war genau den Abend fällig, wo ich dran rumgebastelt habe, also läuft das nun auch automatisch ;) Seitdem ist jetzt über 3 Wochen nicht eine Sekunde Drift zusammengekommen. Mal ist der Umsprung eher zum Anfang der Sekunde, mal eher gegen Ende, aber insgesamt pendelt das jetzt tatsächlich ziemlich genau. Was nun die Drift von >10s am Tag auf nur 5s reduziert hat, mag ich nicht einzusortieren. Die Dupont-Kabel sind einer Kupferlackdraht-Orgie (mit kürzeren Kabelstrecken) gewichen, vielleicht hilft das zusammen mit der "Erdung" des Quarzes und der Versorgung mit konstanter Spannung via LiIon->LDO nach 3,3V. Grundsätzlich sind die 32kHz-Quarze wohl aber auch nicht die Präzisionsschwinger, wenn sie aus chinesischer Billigstproduktion kommen. Nachteil der Lösung ist, dass der µC immer mitlaufen muss, um die Drift zu kompensieren. Ist der Akku leer, rennt die Uhr wieder weg. An einem Pi arbeite ich jetzt paar Tage mit einer DS3231; ein weiteres Modell nehme ich seit Wochen immer mit zur Arbeit (starke Temperaturschwankungen hier - draußen - Arbeitsplatz - draußen) und prüfe da morgens regelmäßig die Drift. Die ist absolut im Rahmen des Datenblatts, bislang auch alles innerhalb einer Sekunde. Hatte da etwas Bammel wegen Berichten von Clone-Chips, die nur die Genauigkeit meiner DS1302 bringen. Kann ich aber nicht nachvollziehen, der TCXO läuft wie erwartet. Da die DS3231 fast nichts kosten, würde ich da nur noch drauf setzen. Habe mir daher noch ein Fünferpack bestellt, gleich in einem bastel-freundlichen Format. Ohne so einen Quatsch-Flash-Baustein: http://www.aliexpress.com/snapshot/6354261751.html
:
Bearbeitet durch User
Ich habe wochenlang einige Probleme mit den DS1307 Chinaboards gehabt.. letztendlich läuft das Ding nach dem Tausch gegen ein Markenquarz und einer CR2032(hält ja angeblich mehrere Jahre, wieso dann LIR?) jetzt seit Wochen genau.
:
Bearbeitet durch User
Habe eine vor >4 Wochen mal angetestete DS1307 grade geprüft - 4 Minuten geht sie jetzt nach schätzungsweise 6 Wochen vor. Auf diesem unsäglichen "TinyRTC I2C"-Platinchen sind zwei Kondensatoren, die sind wohl Abblockkondensatoren. Den Quarz hatte ich ebenfalls auf die Massefläche gelötet, aber hier hilft das wohl nichts. Große Einstrahlungen sind da auch nicht, das Ding läuft hier ohne irgendwas auf der Backup-LIR. Den mal austauschen, scheint eine gute Idee. Das mache ich gleich mal.
:
Bearbeitet durch User
Die DS1307 machen denselben Quatsch wie meine DS1302. Trotz getauschten Quarzes (12,5pF) in der Nacht / den vergangenen 12 Stunden zwei Sekunden gewonnen, zu schnell gelaufen. Macht also auch 4 bis 5 Sekunden am Tag. Die DS3231 hingegen laufen alle noch richtig.
Habe diesen quarz benutzt da zufällig zur Hand gehabt. MS3V-T1R-32.768 http://www.microcrystal.com/images/_PDF/2_Crystal_Metal-Package/MS3V-T1R_Pd.pdf
Braucht man denn diese Dinger unbedingt? Ich habe hier 2 Uhren. Eine mit Atmega8 und 4MHz-Quarz und eine Weitere mit Attiny2313 und ebenfalls 4 MHz-Quarz. Den Takt stelle ich mir mittels Timer-Interrupt her. Die Uhren sind beide so genau, daß ich sie nur beim Wechsel auf die Sommer/Winterzeit anfassen und stellen muß. Warum muß man draußen noch ein extra Bauelement, wie diese Real-Time-Dinger dransetzen, was zudem noch mehr Sackgang als Freude verursacht? MfG Paul
Dirk K. schrieb: > Die DS1307 machen denselben Quatsch wie meine DS1302. und warum nimmt keiner den DS3231? kostet in China nicht mehr als die DS1307 Module Paul Baumann schrieb: > Braucht man denn diese Dinger unbedingt? > Ich habe hier 2 Uhren. Eine mit Atmega8 und 4MHz-Quarz und eine Weitere > mit Attiny2313 und ebenfalls 4 MHz-Quarz. ja der Atmel kann solange tief schlafen ohne Strom zu brauchen bis er gebraucht wird, Aufwecken per PinCange IRQ aus dem /INT Ausgang der DS3231 Paul Baumann schrieb: > Warum muß man draußen noch ein extra Bauelement, wie diese > Real-Time-Dinger dransetzen, weil eine RTC auch Batterie gepuffert ohne Controllerunterstützung laufen kann
Joachim, war dir mein Text zu lang? Schau mal insbesondere den vorletzten und letzten Absatz hier: Beitrag "Re: Das ewige Drama mit der DS1307 RTC (Real Trash Clock)" Sowie aus dem zitierten Post den Satz noch zwei weiter weg vom Zitat ;)
:
Bearbeitet durch User
Weshalb braucht man eine RTC ? Um die Zeit im Sleep weiterzaehlen zu lassen... Solche RTC's koennen bei 1.8V und 0.3uA laufen.
Siebzehn Für Fuenfzehn schrieb: > Weshalb braucht man eine RTC ? > > Um die Zeit im Sleep weiterzaehlen zu lassen... Solche RTC's koennen bei > 1.8V und 0.3uA laufen. Gut, damit habe ich nicht gerechnet, weil ich eine "echte" Uhr brauche, die ich nicht erst wecken muss, damit sie mir verschlafen die Uhrzeit zeigt. ;-) MfG Paul
Siebzehn Für Fuenfzehn schrieb: > Weshalb braucht man eine RTC ? > > Um die Zeit im Sleep weiterzaehlen zu lassen... Solche RTC's koennen bei > 1.8V und 0.3uA laufen. Viele Mikrocontroller können das doch so auch schon. Meistens gibt's sogar einen Extra-Versorgungspin Vbat für die RTC-Pufferbatterie.
SuperD schrieb: > Ja und ? Wer Arduino nimmt der will auch keine ernsthaften Anwendungen > machen ... Blödsinnige Aussage!... wer Opel fährt will auch kein richtiges Auto fahren oder was...
Hurra, da wird sich >> SuperD (Gast) >> 28.07.2013 13:15 sicher freuen, daß du > Markus R. (markus_r131) > 19.11.2019 08:33 bereits heute auf seinen Beitrag reagiert hast! Gruss
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.