Uhr mit TX und I²C LED Anzeige

[sven]

Hallo,

ich habe mal eine Uhr mittels TX und I²C LED Display gebastelt:



Hier das RoboPro Programm:



Ich lasse die Uhr mal bis morgen durchlaufen.
Mal gucken wie genau die morgen noch ist.

Morgen werden ich dann auch noch die beiden Taster auf dem TX zum stellen der Uhr programmieren.

Gruß
Sven

[sven]

Hallo!

Nach dem die Uhr nun die ganze Nacht durchgelaufen hat kann folgedes berichten:

Der TX schafft es nicht die Uhr genau zu halten und ist demnach nicht brauchbar!
Es ist jetzt 8:15 Uhr, die TX Uhr zeigt 8:22 Uhr an, damit geht die TX Uhr 7 Minuten vor.

Gruß
Sven

[qincym]

Hallo Sven,

Du kannst doch eventuell aus dem Fehler und der gesamten Laufzeit, die Du ja auch kennst, einen Faktor berechnen, mit dem die 60s-Pause "getuned" werden kann. Vielleich wird doch noch eine "genaugehende" RoboPro-Uhr daraus.

Viele Grüße
Volker-James

Nachtrag: Ich würde es einmal mit geschätzten 62s versuchen.

[ftDirk]

@ Sven,

wie wäre es zur Ergänzung der tollen Uhr mit einer I2C-RTC (z.B. DS1307)?

Das wäre doch genial!

[sven]

Hallo!

Danke schon mal für Eure Tipps.

Gibt es denn so ein I²C-RCT anschlussfertig?
In der rpp Bibliothek ist ja sogar was fertig für DS1307.
Aber einen nen IC kann man ja schlecht direkt anschließen an den TX.
Bei Conrad habe so keine fertige Platine gefunden.

Gruß
Sven

[Dirk Fox]

Hallo Sven, Volker-James,

eine nette Programmidee!

Nachtrag: Ich würde es einmal mit geschätzten 62s versuchen.

Wenn ich richtig rechne, komme ich auf 10h 22m, also 622min., in denen Svens TX 7 Minuten vorgeht. Das entspricht einem Fehler von 1,125% (eigentlich kein irrsinnig großer Wert). Jedenfalls sollte der Korrekturwert demnach bei 0,675s je Minute liegen - wenn Sven also den Stundenzähler erst 40,5 Sekunden später "weiterschaltet", sollte es einigermaßen hinkommen (62 Sekunden je Minute oder Minuten je Stunde sind zu viel - dann geht die Uhr in derselben Zeit 14 Minuten nach).

Und noch ein Tipp zu Svens Programm: Die untere Operatoren-Berechnung der Uhrzeit kannst Du weglassen - es genügt, den Minutenzähler um 1 zu erhöhen.

Gruß, Dirk

[qincym]

Hallo Dirk,

die gesamte Laufzeit von 10h22m war mir nicht bekannt. Es war nur eine Schätzung von mir. Also jetzt können wir rechnen.

(622+7)/622=629/622=1.01125

Um diesen Faktor läuft, meiner Meinung nach, die Uhr zu schnell. Die Pause (im Programm 60s) ist um diesen Faktor zu verlängern, damit die Uhr insgesamt langsamer läuft, weil die Pause länger ist.

60*1.01125=60,68

Mit einer Pause von 60,68 Sekunden könnte die Uhr im ersten Ansatz korrigiert werden.
Nachtrag: Dann stimmen auch immer die Minuten und nicht erst zur vollen Stunde.

Wenn Sven, als eventueller Mitleser, das einmal ausprobieren und berichten könnte, wäre das sehr informativ.

Ich kann mich natürlich auch irren. Das soll ja menschlich sein.

Viele Grüße
Volker-James

[sven]

Hallo!

Ich guck mal das ich das noch ausprobiere.
Will das Programm eh noch umbauen.
Eine Funktion zum Uhr stellen mittels Taster vom TX brauch ich ja auch noch.

Gruß
Sven

[qincym]

Hallo Sven,

bitte sei so nett und probiere das mal aus.

Zum Stellen der Uhr stelle ich mir die Verwendung von Tastern über die I-Eingänge vor. Zumindest würde ich mir das für mich so vostellen. D.h. im Ablauf des Programmes (und natürlich gleich zu Beginn) eine Taster-Abfrage "ich will die Uhr stellen", danach eine Verzweigung in ein Unterprogramm, das über weitere Taster die Minuten und die Stunden stellt und dann mit der gestellten Uhr in das Hautprogramm zurück kehrt.

Viel Erfolg
Volker-James

[qincym]

Hallo elektrolutz,

wenn ich eine IF-Abfrage (oder weitere Programmelemente) in den Programmablauf einbaue, wird sich mit Sicherheit der Durchlauf der Programmschleife verlängern. In diesem Fall muss die Pause von den jetzt von mir zur Diskussion gestellten 60,68 Sekunden wahrscheinlich verringert werden, um wieder "genau" zu gehen.

Über die Anzeige (I²C LED oder TX Display) hatte ich mich doch gar nicht ausgelassen. Oder habe ich da was übersehen?

Viele Grüße
Volker-James

[Dirk Fox]

Hallo Volker-James,

Deine Rechnung deckt sich mit meiner - das beruhigt mich.
Die Korrektur ist wahrscheinlich genauer, wenn man sie nur einmal pro Stunde vornimmt und nicht nach jeder Minute, denn dafür ist der Timer des TX wahrscheinlich nicht exakt genug. Im Verlauf einer Stunde sollte ein Fehler von 1,125% (etwa 45 sec.) nicht ganz so tragisch sein... Auch wenn genauer natürlich immer besser ist

Ich werde meine TXe auch mal daraufhin testen. Eine genaue Uhr wäre manchmal nicht schlecht - bis wir einen "Plug&Play"-I²C-Timer haben.

Gruß, Dirk

[thkais]

Moin,

selbst wenn die Zeiten genau wären, muss man auch die (unbekannte) Laufzeit des Programms mit einrechnen.
Insofern wäre zu überlegen, ob ein eigener Task für den Zeitgeber eine bessere Genauigkeit ergeben könnte?
Ob ein "ca." angebracht wäre, ist eine Frage der Genauigkeitsklasse, die in den technischen Daten angegeben ist....

[thkais]

Hallo Elektrolutz,

diese Differenz ist keine Überraschung für mich. In RoboPro gibt es keinen "Systemtimer", der unabhängig von irgendwelchen Programmzyklen läuft. Deshalb wird zusätzlich zur Wartezeit immer auch die Zeit vergehen, die für die Schleife benötigt wird. Dann ist ganz klar, dass in der 0,01s-Warteschleife insgesamt "weniger Zeit" vergeht - aber tatsächlich wurde die Schleife und die Abfrage 1000x öfters ausgeführt, als in der 10s-Schleife.
Deshalb auch mein Vorschlag, *einen* Task als "Systemtimer" zu nutzen - es ist aber fraglich, ob das nach einem Abgleich so funktioniert, dass der zweite Task für die Anzeige der Uhr beliebig größer oder kleiner werden kann. Hier weiß ich über die Interna von RoboPro zu wenig.
Sich über die Genauigkeit der RoboPro-Timer Gedanken zu machen, ist müßig. Weder der TX noch RoboPro sind als Uhr konzipiert worden, dann würde es schon eine RTC (Real Time Clock) brauchen - das wird mit einem eigenen Baustein und einem entsprechenden Quarz realisiert (auch beim PC). Auch bei selbstgebauten Uhren (mit µC) scheitert eine genaue Uhr an der Genauigkeit der handelsüblichen Quarze - ein Abgleich ist ebenso notwendig wie im Beispiel von sven. Lediglich sog. "Uhrenquarze" mit 32,768 kHz sind genauer.

Man müsste aus der Differenz der Timerwerte herausrechnen können, wieviel Zeit die Schleife und die Abfrage benötigen. Aber eine Aussage über die tatsächliche Genauigkeit der Timer bekommen wir damit m.E. nicht.

edit:
Ich habe die Werte 30 - 294 - 2733 - 12439 (Simulation ohne Interface). Würde mich mal interessieren, was bei anderen Konstellationen herauskommt.

[Dirk Fox]

Hallo zusammen,

dank I²C sollte der Anschluss einer RTC ja nun nicht mehr allzu kniffelig sein, oder?
Immerhin gibt es so was, z.B. http://www.maxim-ic.com/datasheet/index.mvp/id/2688

Kennt jemand einen RTC-I²C-Bausatz, der sich (ähnlich der Conrad-LED-Anzeige) ohne Lötkolben an den TX anschließen lässt?

Gruß, Dirk

[qincym]

Hallo Zusammen,

Dirks Vorschlag würde ich auf eine Funkuhr ausdehnen. Gibt es sowas? Wer ist bereit so etwas zu bauen? Eine Funkuhr ist doch genauer und stellt sich selbst (bzw. wird gestellt).

Viele Grüße
Volker-James

[thkais]

Hallo,

eine Funkuhr (DCF-77) könnte man sogar an einen normalen Eingang anschließen (man müsste lediglich prüfen, ob der Spannungspegel "passt"). Das DCF-77 Signal gibt pro Sekunde einen Impuls ab - durch Messung der Länge der Impulse bekommt man die binär kodierte Zeit. Beispiele, Datenblätter und sonstiges gibt es im Internet zu Hauf, insofern "nur" eine Fleißaufgabe.

[steffalk]

Tach auch!

Der TX hat doch die schnellen Zählereingänge. Sollte man damit nicht auch eine 50-Hz-Uhr leicht hinbekommen, die dann wunderbar genau liefe?

Gruß,
Stefan

[Dirk Fox]

Dirks Vorschlag würde ich auf eine Funkuhr ausdehnen.

Ok, ok - Ihr habt ja so Recht.
Reicht dafür denn die Empfängerplatine von Conrad? http://www.conrad.de/ce/de/product/6411 ... Detail=005
Gruß, Dirk

[Dirk Fox]

Hallo zusammen,

noch ein Nachtrag:

selbst wenn die Zeiten genau wären, muss man auch die (unbekannte) Laufzeit des Programms mit einrechnen.
Insofern wäre zu überlegen, ob ein eigener Task für den Zeitgeber eine bessere Genauigkeit ergeben könnte?

klingt überzeugend. Der "Wartezeit"-Befehl hat nach RoboPro einen relativ kleinen Fehler (siehe "Hilfe", 8.1.5): bis 8,3 h max. 1 Sek., bis 83 h max. 10 Sek. Vielleicht läuft Svens Uhr mit zwei parallelen Prozessen tatsächlich genauer.

Gruß, Dirk

[scripter1]

Dirks Vorschlag würde ich auf eine Funkuhr ausdehnen.

Ok, ok - Ihr habt ja so Recht.
Reicht dafür denn die Empfängerplatine von Conrad? http://www.conrad.de/ce/de/product/6411 ... Detail=005
Gruß, Dirk

Wenn man die beiden benötigten Pegel anpasst, könnte das durchaus funktionieren.

Achja, was man bei Conrad für 10 € bekommt, wird bei Pollin für gerade mal halb so viel Geld angeboten:
http://www.pollin.de/shop/dt/NTQ5OTgxOT ... _DCF1.html