Die Erkenntnis: Du sendest nicht bei 60.000ms, 120.000ms, 180.000ms, ... sondern bei 60.000ms, 120.013ms, 180.026ms einen Impuls... Die Bibliothek dagegen, sorgt dafür, dass wirklich bei 60.000ms, 120.000ms, ... ein Impuls gesendet wird. Du könntest natürlich auch die Berechnungszeit von Deinen 60.000ms abziehen. Also einen Impuls alle 59.987ms senden 
foo_mep:
erstmal vielen dank für die schnelle und gründliche hilfe hierdie lösung mit dem ethernet kommt auf jeden fall nicht in frage, weil die uhr in der küche hängt und ich dort kein netzwerk habe. ich kann ja nicht die ganze wohnung mit netzerkkabeln durch ziehen
ich habe eh überlegt, ob ich evtl später eine funkuhr einbaue. aber erstmal sollte die uhr so laufen.
Man könnte sich die Kabel sparen in dem man das WiFi Shield nutzt Arduino Shield List: AsyncLabs WiShield v2.0 vorausgesetzt du hast WLan.
Ich hab jetzt mal mit 13ms gerechnet, Du kannst das natürlich auch auf 85ms rechnen...
Ich finde diese Zeitservergeschichte etwas überkandiedelt. Wenn man es machen möchte weil es geht, dann ist es ok. Aber meine Armbanduhr hat ja auch kein WLAN, geschweige denn einen Ethernet Anschluß Ich kann höchstens zu einer RTC raten. Dazu wird die RTC, ein passender Quarz & eine Knopfzelle benötigt...
@bytzmaster
na erstmal das lösen
@stundenblume
wenn du das ganze über usb anschließt und laufen läst, dann kannste dir ja die impulse anzeigen lassen. da werde ja dann auch die millis mit angezeigt. da stimmt das doch dann aber mit der zeit.
wenn ich also statt millis() now() nehme dürfe sich ja nicht viel ändern, oder? ich muss ja trotzdem abfragen und die variable setzen
unsigned long lastTick;
void setup(){
Serial.begin(9600);
}void loop(){
if (millis()-lastTick>=1000){
Serial.print("Tick @ ");
Serial.println(millis());
lastTick=millis();
}
}
Versuche mal den Code. Dort siehst Du, dass bei jedem Tick deutlich ms verloren gehen. Das ist jetzt absichtlich ungünstig programmiert, um es zu verdeutlichen.
stundenblume:
Ich finde diese Zeitservergeschichte etwas überkandiedelt. Wenn man es machen möchte weil es geht, dann ist es ok. Aber meine Armbanduhr hat ja auch kein WLAN, geschweige denn einen Ethernet Anschluß
Jo das habe ich ja vorhin auch schon vorgeschlagen XD :
bytzmaster:
Weitere Möglichkeit wäre ein DS1307 zB. mit diesem hier:
Mixed-signal and digital signal processing ICs | Analog Devices
Zusammen mit nem 32kHz Quarz und 2 Wiederständen haste da ne ECHTE Hardwareuhr, die auch ne Batterie-Backup Lösung bietet.
Ansprechen kannste die über den I²C.
@bytzmaster
ich hab jetzt mal Deinen Code versucht & die 60.000ms auf 1.000ms geändert um jede Sekunde einen Impuls zu erhalten.
Ich nehme alles zurück & behaupte das Gegenteil... Bei Dir werden tatsächlich die Impulse zur "richtigen" Zeit, also bei vollen ms gesendet & ein Versatz ist auf die Schnelle nicht zu erkennen... Auch bei dem folgenden Code ist das so.
unsigned long lastTick;
unsigned long tack;
void setup(){
Serial.begin(9600);
}
void loop(){
tack=millis();
if (tack-lastTick>=1000){
Serial.print("Tick @ ");
Serial.println(tack);
lastTick=tack;
}
}
Ich werde das morgen vielleicht mal im Vergleich zu meiner DS1307 laufen lassen...
ok. ich möchte das jetzt aber esrtmal OHNE weitere hardware machen (möchte jetzt basteln und das dann mal an die wand hängen )
hmm... dann liegt es doch daran, dass millis() ungenau wird?
vlt. kann die time biblo die zeit synchron halten. in der time.cpp gibt es recht weit unten was mit sysUnsyncedTime u.s.w.
ich sehe da nicht wirklich durch aber vlt. haben sie dort eine möglichkeit gefunden fehler auszumerzen.
so, habe das ganze jetzt mal mit der time und RTC biblo sowie now() realisiert und festgestellt, dass sich aus dort der fehler einschleicht. dann wird wohl der quartz auf dem arduino nicht wirklich genau sein.
bleiben also doch nur die möglichkeiten:
- einen externen quartz als taktgeben nehmen
- über lan oder wlan den takt zu holen
- eine funkuhr zu bauen
- den fehler mit einberechnen
ich werde jetzt erstmal die letzte ausprobieren. vlt widme ich mich dann nochmal der funkuhr 
Hallo foo_mep
Der Quarz auf dem Arduino ist genau; typischerweise 100ppm Fehler (maximal, bedingt durch Exemplarstreuung und auf den ganzen zulässigen Temperaturbereich; bei 25 Grad ist der Fehler kleiner). Es kann sein, daß Du einen Arduino ohne Quarz hast, sondern einen mit einen Resonator; die sind ungenauer (0,1% = 1000ppm).
Der Arduino Uno hat einen Resonator.
Wenn Du einen Externen Oszillator hinbauen willst, dann kauf Dir gleich eine RTC. Die meisten haben einen Ausgang mit 1Hz Rechteck-Signal.
Grüße Uwe
Meiner Meinung nach ist der Arduino nicht genau genug für eine Uhr. 10-100ppm Abweichung sind locker drin. D.h. etwas in der Größenordnung von 1-10s/Tag. Je nach Exemplar und Temperatur kann das ganz schön streuen. Ich würde für eine Uhr entweder einen RTC Chip oder gleich ein Funkuhrmodul nehmen. Funkuhr hat auch gleich den Vorteil, daß man die Uhr nie wieder stellen muß.
Gruß, Udo
Hallo Udo
Eine RTC ist auch nicht viel genauer, da auch sie einen Quarz als Zeitgebendes Element verwendet. Da sind die 50Hz der Netzspannung auf längere Zeiträume sehr genau. Dies ist interesant für netzgespeiste Geräte.
Ich experimentiere gerade mit einem DCF77 Modul und habe einige Schwierigkeiten. Ziemliche viele Elektrogräte im 1m Abstand blockeren effektiv den Empfang.
Ich weiß noch nicht ob das SIgnal wegen der Berge schwach ist. Eigentlich wohne ich weniger 500 km vom Sender entfernt.
Genaue Zeitsignale sind RDS informationen in Radiosendern, GPS Empfänger (funktionieren nur außerhalb von Gebäuden) und nts Server im Internet.
Viele Grüße Uwe
Wenn du unsauber programmiert hast, nützt der genaueste Timer nichts.
Über welche Umwege wird denn die Uhr angezeigt, vielleicht verschlabbert dein Code da die Zeit , evtl durch ein For oder zusätzliche unnütze Delay....
Meiner Meinung nach ist der Arduino nicht genau genug für eine Uhr.
..das ist unsinn
Der Timer geht bei 16mhz bis µsek(millionstel secunde) genau.
Sogar µsec als Float schafft das avrgcc.
Wenn der interne Quarz mit 1 oder 8 mhz gesetzt wurde dann kann es durch Teperaturschwankunken dazu kommen.
Naja, so ganz stimmt das nicht. Quarzosszialtoren bekommt man mit entsprechendem Aufwand schon genauer hin. Auch für wenig Geld. Die RTC hier Mixed-signal and digital signal processing ICs | Analog Devices ist offensichtlich Temperaturkompensiert und damit doch gleich 1-2 Größenordnungen besser als der Arduino.
Wenn's dann noch besser werden soll, dann geht der Zoo los, ofenstabilisert, funk oder netzgesteuert usw. Ich plädiere dann im Zweifelsfall immer für DCF77 oder gleich GPS.
Gruß, Udo
Hallo Udo Klein
Hab noch keine Platine mit dem temperaturkompensierten RTC DS3231 gesehen.
Die normal in den Elektronikshops erhältlichen RTC DS130x sind nicht temperaturstabilisiert.
Du hast Recht daß DCF77 und GPS genau sind, aber der Empfang nicht so trivial.
GPS funktioniert in Gebäuden praktisch nicht.
DCF zum laufen zu bringen ist, mit der Erfahrung die ich gerade sammle, schwierig. PC und Röhrenmonitore in unmittelbarer Nähe stören. Hab noch nicht Versucht einen Arduino dranzuhängen, aber ein DSO mit ATmega vereitelt durch Störungen die Messung des Ausgangssignale wirkungsvoll. Ich weiß nicht, ob das Schuld vom meinem Modul ist oder weil ich in den Alpen wohne, auch wenn unter 500km Distanz vom Sender.
Einen Alternative sind die RDS Daten con UKW-Radio-Sendern. Radiosender empfängt man wirklich überall.
Grüße Uwe
Chronodot wäre so eine Platine: http://macetech.com/store/index.php?main_page=product_info&cPath=5&products_id=8&zenid=55d54f507f3c38605812ce3845dca0da
Gruß, Udo