Ich habe eine Hopf Clock Mouse und wüßte gerne, wie man dem Ding die Uhrzeit entlockt. Sendet man mit einem Terminalprogramm Zeichen an die Clock Mouse, so werden sie nur zurückgeschickt. Praktisch so, als wenn man im Stecker RxD mit TxD verbindet. Ein Zeittelegramm kommt nicht. Weiß da jemand mehr? Würde es mir ersparen, einen RS232-Sniffer aufzubauen, um den Originaltreiber bei der Arbeit zu belauschen. Gruß Jadeclaw.
Hast du schon mal bei google geguckt? http://www.guntram.de/funkuhr/ hier gibts sogar linux driver code.
Habe ich, werde allerdings nicht schlau daraus, was da eigentlich an das Modul gesendet wird. Endanwendung ist allerdings auch nicht am PC, sondern ein AVR soll sich die Daten abholen. Gruß Jadeclaw.
Ich hab mir den Linux Treiber mal angeschaut. Sieht so aus als würde die Uhr ständig ihre Daten rausschieben. Denn es wird nie etwas gesendet. In readclock ist eine kleine state-machine die auf ein \r wartet und ab dann die Uhrzeit (und andere Flags) parst. Die UART Parameter kannst du ja in der Funktion openserial sehen. Du hast aber auch mal ein paar Minuten gewartet, bis sich die Uhr synchronisiert hat? Vielleicht fängt sie dann an Daten zu senden.
Die Uhr sendet nicht von alleine. Hab' das Teil gerade seit 30 Minuten am HTerm dran. Und im Windows-Treiber ist ein Bedienprogramm dabei, mit dem man gezielt den PC mit der Uhr synchronisieren kann. Die Clock Mouse enthält eine CMOS-Echtzeituhr mit Batterie, die sich einmal am Tag per DCF77 stellt. Gruß Jadeclaw.
In der Doku http://www.hopf.com/manuals/deutsch/pdf_7---/d7201-7221_1800.pdf sind die Parameter auf Seite 52 beschrieben (Daten kommen mit 300Baud, 7Bit, Parity) Gruss Frank
Richtig, so habe ich HTerm auch eingestellt. Und auch die Abfrageprozeduren auf Seite 14 hatte ich auch schon durchprobiert --> erfolglos. Gruß Jadeclaw.
Ja. Dazu legt man sich nachts um 2 auf die Lauer oder drückt den rückseitig in einem tiefen Loch befindlichen Taster, die LED beginnt im DCF-Takt zu blinken, ist die Uhr dann synchronisiert, geht die LED aus, um Strom zu sparen. diese Synchronisation ist völlig unabhängig vom Anschluß an den PC, wie auch die Abfrage unabhängig davon ist, ob die Uhr zum Zeitpunkt der Abfrage gerade Empfang hat oder nicht. Die Uhr muß nur einmal erfolgreich mit DCF77 synchronisiert haben. Zwei Mignonzellen halten dabei die CMOS-Uhr am Laufen, wenn der PC aus ist. Und ja, die Batterien sind voll. Gruß Jadeclaw.
du kanns ja mal schauen, was am PC die anderen Pegel RTS/CTS usw. so machen, eventuell wird die Übertragung darüber "angeschubst". Ist aber nur so eine Idee...
Thema rauskram: Hallo, ich habe auch gerade eine Clock Mouse von hopf (eigentlich von HKW-elektronik)am Wickel, ist das Thema für Jemanden noch interessant? Ich habe eine Aufzeichnung der RS-232 Kommunikation. Grüße Mathias
Mathias schrieb: > Ich habe eine Aufzeichnung der RS-232 Kommunikation. Da die Dinger fuer die 5.- wohl demnaechst hier in Massen auftauchen, rueck doch mal Infos raus. Ich habe mir naemlich auch ein paar davon geschnappt und bekomme nichts raus. Ich habe aber auch noch nicht wirklich viel damit rumprobiert, nicht mal richtig rein geguckt. Also Batterien rein, angestoepselt, im Terminal kam nichts und in die Im-Winter-Unerledigte-Projekte-Kiste gelegt. /edit Mit dem Programm von der Floppy laeuft das Ding aber einwandfrei. Ist natuerlich ein DOS - Programm, die "Uhr" ist ja schon ein bisschen aelter :o) Ich haenge es mal an.
:
Bearbeitet durch User
Barney Geroellheimer schrieb: > Da die Dinger fuer die 5.- wohl demnaechst hier in Massen auftauchen, > rueck doch mal Infos raus. > Ich habe mir naemlich auch ein paar davon geschnappt und bekomme nichts > raus. Wie kommat Du darauf, dass die auftauchen und wo hast Du Deine "geschnappt"?
Simon K. schrieb: > Hast du schon mal bei google geguckt? http://www.guntram.de/funkuhr/ Wohl nur im Archiv? http://web.archive.org/web/20050206212248/http://guntram.de/funkuhr/
Guido Lehwalder schrieb: > Wie kommat Du darauf, dass die auftauchen und wo hast Du Deine > "geschnappt"? Weil die seit Wochen auf allen moeglichen Plattformen fuer unter 5.- angeboten werden. Auch "Pakete" mit gleich 10stk. und mehr. Ich habe auch mal 5Stk. genommen. Fuer den Preis habe ich zumindest mal schoene Gehaeuse und funktionieren tun die ja auch im Prinzip. Hier auch, funktioniert bei mir nur nicht, muss ich mich erst mal duchwuehlen. Suse 6.0 ist ja nun auch schon "etwas" aelter. http://www.gbl-software.de/hopf/index.html
:
Bearbeitet durch User
Hi, könntest du mal eine Plattform/passenden Suchbegriff nennen? Danke.
Snarf schrieb: > könntest du mal eine Plattform/passenden Suchbegriff nennen? Auf Anhieb habe ich "nur" 60 Stueck fuer 149EUR gefunden: http://kleinanzeigen.ebay.de/anzeigen/s-anzeige/60-stueck*neu*hopf*clock-controller*dcf-77***originalverpackung*/207339855-225-1809?ref=search
Danke für den Link. 150Eur für 60 Stück ... ich tät 10 Stück nehmen zum "basteln", aber was mach ich mit den restlichen 50?
Willst Du jetzt 'ne Sammelbestellung starten ? Warum schreibst oder rufst Du da nicht einfach mal an ?
:
Bearbeitet durch User
hallo Mathias, Du hattest gepostet das Du Aufzeichnungen vom Datenstrom der hopf-hkw DCF77 Uhr hast. Kannst Du mir die mal zukommen lassen? Und vielleicht auch die Einstellungen des COM-Ports und wie Du die Kommunikation nagestoßen hast? Ich bin hier bei mir am Verzweifeln und kriege ums verrecken keine Daten aus der Uhr. Außer mit dem DOS-Programm :) Vielen Dank schon mal für Deine Mühe mfg René Pfotenhauer
René, schon weitergekommen? Habe auch schon stundenlang versucht irgendwelche Datenblätter zu finden - leider nichts gefunden und auch sonst bin ich mit dem Sniff der RS232 nicht weitergekommen. Grüße P.
Dann schaut euch mal die Handshake Leitungen an Ihr Schlaumeier ;-)
Hallo, hoppla, hier passiert ja doch was. Ich habe auch so eine 5,- Euro Uhr beim großen E erworben. Ich hatte Kontakt zum Hersteller der Uhr (HKW) und der hat mir die Infos zukommen lassen die in der TXT-Datei zu lesen sind. Diese gelten allerdings für das aktuelle Modell. Inwiefern dort Änderungen gegenüber dem alten Modell existieren weiß ich natürlich nicht. Ich hab auch das DOS-Programm zum laufen bekommen und hab diese Kommunikation mitgeloggt (siehe Anhang). Mit einem Terminalprogramm hab ich leider auch keine Infos aus der Uhr bekommen. Grüße Mathias
Hi, leider habe ich hier keinen Empfang, wenn die Uhr auf dem Tisch liegt, da muss ich mir noch was einfallen lassen. Aber hier hat das mal jemand ueber Lunux gemacht. Die Abfrage steht ja im Quelltext, das sollte dann wohl auch so ueber das Terminal funktionieren. http://www.gbl-software.de/hopf/index.html Empfangen tut die Uhr am kleinen IC neben der Antenne, wie eine ganz normale Funkuhr. Man muss allerdings 5V drauf geben weil der µC dieses IC nach etwas ueber 2min abschaltet. Die Zeit wird von der Software angefordert und im µC decodiert. Der gibt dem IC dannn auch Spannung. So lange ist die Uhr tot um Strom zu sparen. Zu dem IC und auch zu dem µC habe ich keinerlei Infos gefunden. Wie gesagt, ich kann auch nicht vernuenftig messen da ich hier noch keinen Empfang habe. Bei Gelegenheit lege ich die Antenne mal raus, dann sehen wir weiter.
Und in der TXT Datei steht wenn man die Uhr mit eigener Software bzw. Hardware benutzen will folgendes: Die positive Spannung wird durch DTR bereitgestellt. Bei der Bereitstellung der negativen Spannung gibt es abhängig von der gewählten Form des Datenaustauschs zwei Möglichkeiten: 1. Die Funkuhr wird mit ASCII-Zeichen, wie unter 5. beschrieben, angesprochen. In diesem Fall wird die negative Spannung durch TxD bereitgestellt. Das erfolgt automatisch, denn TxD ist in Ruhe immer negativ und nur in den kurzen Momenten positiv, in denen der PC Zeichen an die Funkuhr sendet. 2. Die Funkuhr wird gemäß der Beschreibung in Punkt 2.3 angesprochen. In diesem Fall kann TxD während der Datenübertragung auf positivem Pegel liegen und so nicht die negative Betriebsspannung der Schnittstelle liefern. Deshalb gibt es die zusätzliche Möglichkeit, die negative Spannung auch über RTS zu liefern. RTS ist also auf Low-Pegel zu programmieren, falls die Datenübertragung durch statischen High-Pegel von TxD ausgelöst werden soll.
Also DTR wird für den positiven Pegel der Seriellen Ausganstreiber benötigt und RTS bzw. TXD für den negativen.
Ich habe auch mehrere dieser Uhren. Der kleine IC in der Nähe des Antennenanschlusses scheint bei mir aber nicht einfach nur das demodulierte Signal (1 Pulse pro Sekunde, verschiedene Länge je nach 0 oder 1) auszugeben. Ich sehe da vielmehr einen ständig laufenden Takt faster Frequenz, dessen DutyCycle im Sekundentakt mehr oder weniger Stark veriiert. Seriell konnte ich auch noch keine Zeit raus holen. Ich würde die Module gerne als Zeitquelle für meine Basteleien verwenden, entweder in der urspränglischen Form mit Batteriebetrieb oder einfach nur den Empfangsteil mit dann eigener Auswertung.
Wenn jemand die Belegung der beiden Stecker ausbaldovert, also auch die Schleifen innerhalb des RS232 Steckers, kann ich da heute Abend mal einen LA dran haengen. Und wie gesagt interessant waeren Daten der beiden ICs. Vielleicht findet da jemand was.
Welche "beiden" Stecker? Die Clock-Mouse hat doch nur einen?! Grüße
wenn ich mich nicht vertan habe dann: Uhrseitig: DB9: 1- braun 7 - RTS 2- grün 6 - DSR 3- blau 5 - GND 4- grau 4 - DTR 5- gelb 3 - TxD 6- weiss 2 - RxD Gruß Patrick
Leider hat das null Sinn, denn ohne Empfang kann ich kaum was machen. In einem anderen Thread habe ich mal nachgefragt ob ich die Antenne selbst irgendwie verlaengern kann. Von sowas habe ich keine Ahnung. Dann sehen wir weiter. Beitrag "DCF77 Antenne verlaengern / Anpassen"
Hat jemand eine Software, um mit dieser Uhr Maus für Windows arbeiten?
Hallo ist weiter oben schon geschrieben RCCD.COM, läuft auch unter Win7 Gruß
Guest schrieb: > Hat jemand eine Software, um mit dieser Uhr Maus für Windows arbeiten? Ich bin gerade dabei einen Clock Driver für den ntpd (von http://www.ntp.org) zu schreiben. Unter Windows funktioniert er prinzipiell schon, nur schön ist der Code noch nicht. Unter Linux sollte er theoretisch auch gehen, ich habe aber aktuell keine Möglichkeit dies zu testen. Ich werde mal die Schaltung untersuchen und testen ob man den Empfänger auch direkt an die 3,3V IOs des Raspberry Pi hängen kann. Hat jemand Interesse an der Software? Wer das ntp Paket nicht kennt: das kann man sich für Windows am einfachsten hier runterladen, am besten zusammen mit dem Server-Monitor: https://www.meinberg.de/german/sw/ntp.htm https://www.meinberg.de/german/sw/ntp-server-monitor.htm Dann muss man noch die ntpd.exe gegen die Version von mir austauschen und das Config-File erstellen. Bei ebay Kleinanzeigen gibt es noch viele von den Hopf ClockMouse Empfängern (HKW Clock Controller). Diese kosten je nach Anzahl zwischen 5,- und 3,- Euro zuzüglich Porto. http://www.ebay-kleinanzeigen.de/s-hopf-dcf/k0 Wie hoch die Genauigkeit der Empfänger ist, d.h. wie viele Millisekunden Abweichung vom DCF77 Referenzsignal es gibt kann ich noch nicht sagen. Das hängt davon ab, wie genau sie auf die Phase des DCF77 einrasten und wie hoch die Drift der Quartzuhr ist. Eigentlich wollte ich nur den Empfangsteil verwenden und an einen ATmega32U4 hängen mit dem Code von https://github.com/udoklein/dcf77. Dieser Code dürfte von der Robustheit nicht zu schlagen sein, aber leider deckt er meine Ansprüche an die Genauigkeit noch nicht ganz ab. Der Anspruch liegt bei 1 ms Genauigkeit, momentan komme ich auf etwa 10 ms. Warum ich diese Genauigkeit gaben möchte? Weil jeder sagt, dass man maximal 2 bis 5 ms Genauigkeit erreichen kann :-). Außerdem benötige ich eine genaue Uhr als Referenzuhr für Genauigkeitsmessungen von anderen Uhren und der GPS Empfang ist hier mies. Das Signal was aus dem Empfang-IC der ClockMouse rauskommt ist aber leider ein PWM Signal mit ein paar hundert Hertz und aus diesem kann man kein Millisekunden genaues Event für die Flanken des DCF-77 Signals mehr gewinnen. Michael
:
Bearbeitet durch User
Vorsicht, es gab früher auch solche Empfänger mit eingebauter Quarzuhr welche einfach die Uhrzeit auf Anfrage ausgegeben haben. Solche sind natürlich zur Zeitbestimmung ungeeignet. Ich hab mir gerade den Quellcode des Linux-Programms angeschaut, laut dem gibt die Uhr die Zeit einfach in ASCII aus... vielleicht kann man aber die Hardware so umbauen, dass einfach das demodulierte DCF77-Signal auf den Steuerleitungen anliegt. Dann kann das der ntpd direkt verarbeiten.
:
Bearbeitet durch User
Michael D. schrieb: > Außerdem benötige ich > eine genaue Uhr als Referenzuhr für Genauigkeitsmessungen von anderen > Uhren und der GPS Empfang ist hier mies. Dann brauchst Du einen Korrelationsempfänger. Die sind allerdings deutlich aufwändiger, so als IC gibts die nicht. Kommerziell schaut so was so aus: https://www.meinberg.de/german/products/3he-dcf77-korrelations-empfaenger.htm
Christian B. schrieb: > Dann brauchst Du einen Korrelationsempfänger Der verlinkte Empfänger ist mit Genauigkeitsangaben von "typisch 20 µs, max. 50 µs" schon um Faktor 50 besser als die 1 ms welche ich gerne hätte und vom Budget her wahrscheinlich sogar um mehr als den Faktor 100 für ein Hobbyprojekt :-) > vielleicht kann man aber die Hardware so umbauen, dass einfach das > demodulierte DCF77-Signal auf den Steuerleitungen anliegt. Wie geschrieben konnte ich direkt am Empfänger-IC (Beschriftung ist glaube ich U2900) nur ein FM Rechteck-Signal entdecken. Wenn die Frequenz deutlich über 1 kHz liegen würde könnte ich damit sogar was anfangen, aber nicht mit wenigen hundert Hertz. Das IC ist beschriftet mit TFK U 2900 B 45 A 327 Wenn es Infos zu diesem IC gäbe wäre mir auch schon geholfen. > Dann kann das der ntpd direkt verarbeiten. Ich hab mir den Code angesehen. Das Signal wird dabei mit 50 Baud eingelesen, d.h. alleine die Abtastungenauigkeit liegt schon bei ca. 20 ms. Michael
Michael D. schrieb: > besser als die 1 ms welche ich gerne 1ms ist schon sehr sportlich für einen DCF-77-AM Empfänger. Bedenke, dass der Sender die Flanken da schon auf einige Millisekunden abrundet. Sprich Deine AGC muss denn sehr genau arbeiten.
Mathias schrieb: > Hallo, > hoppla, hier passiert ja doch was. > > Ich habe auch so eine 5,- Euro Uhr beim großen E erworben. > > Ich hatte Kontakt zum Hersteller der Uhr (HKW) und der hat mir die Infos > zukommen lassen die in der TXT-Datei zu lesen sind. Diese gelten > allerdings für das aktuelle Modell. Inwiefern dort Änderungen gegenüber > dem alten Modell existieren weiß ich natürlich nicht. > > Ich hab auch das DOS-Programm zum laufen bekommen und hab diese > Kommunikation mitgeloggt (siehe Anhang). > > Mit einem Terminalprogramm hab ich leider auch keine Infos aus der Uhr > bekommen. > > Grüße > Mathias Hallo Mathias und Autoren, wir haben 4x hopf HKW **Clock Controller**DCF 77**Originalverpackung* gekauft und auf den Disketten ist die Dos-Software nicht mehr lesbar. Kann mir einer das DOS-Programm geben. Gruß Franz
Hallo Franz das DOS Programm ist weiter oben schon verlinkt. Grüße Patrick
Moin, wollen wir mal den alten Schinken hier aus der Versenkung holen :D Hat jemand mal die UHR unter Win7 64bit zum reden gebracht? rccd.com will nur auf 32bit laufen Hab den Hersteller nu schon zwei mal angeschrieben, aber die reagieren gar nicht. :( Ich hab nen ntpd hier der erkennt auch die Hopf uhr laut dem servertool aber reden tun die nicht miteinander. Wäre kuhl wenn hier noch einer lebt der das zum laufen bekommen hat. Gruß
Angehängte Dateien:
-
Hterm_Antwort.PNG
250 KB -
Dos1.PNG
69 KB -
Dos2.PNG
63 KB
Habe mich nun bald 1 Woche mit der Uhr beschäftigt. Nachdem ich mit allen USB <-> Seriell Adaptern und virtuellen Maschinen nicht weitergekommen bin, habe ich letztendlich Windows 98-SE auf einen alten Dell Optiplex GX260 mit Hardware Com Port gepackt. Was ich schon mal sagen kann ist das die Uhr immer 16 Byte als Antwort sendet, wobei Byte 16 nur eine neue Zeile ankündigt "\r". Die Optionen in der Dos Datei wie etwa /d für nur Tag ist nur für die Ausgabe. Weiter sind von den ersten 15 Byte sind jeweils nur die unteren 4 Bit relevant so wie es auch weiter oben in der DATA_DT.TXT Datei steht. Allerdings scheinen die Bits 2 & 3 in Byte 14 gegenüber der Anleitung vertauscht zu sein. Aber das werde ich ja bald sehen da ja die Uhrumstellung ansteht. > Bit3 =1 während MEZ, =0 während MESZ > Bit2 =0 während MEZ, =1 während MESZ Das irgendetwas an die Uhr gesendet wird sobald die Dos Datei eine Abfrage startet kann ich nicht erkennen. Somit fallen auch alle Hinweise aus obiger txt Datei flach die sich auf das Abfragen beziehen. Der Trick besteht scheinbar legentlich darin das Uhrseitig Pin Pin6 | Gelb | Rx kurz von - 11,14 V auf bis zu + 10,68 V wechselt. Legt man kurz eine Spannung zwischen 3 und 11 an kann man die Uhr auch manuell zum senden bewegen. Die verbaute 60mm Antenne konnte ich problemlos gegen ein 100mm tauschen. Den Batteriehalter habe ich ausgebaut, Strom kommt über USB und wird auf 3,17 V runtergeregelt. In dem .rar Archiv ist die komplette Diskette v1.2.
Stephan K. schrieb: > Die verbaute 60mm Antenne konnte ich problemlos gegen ein 100mm > tauschen. Cool, echt cool. Das sich damit noch wer beschaftigt... nochmal echt cool Trotz grosser Antenne habe ich hier (Bastelbude) keinen Empfang. Irgendwann, wenn Winter ist und nix zu tun ist" - Kiste. Ich habe aber einen Arduino-Sender gefunden, der mir das "Simuliert". So geht es dann auch frueher in die Bastelbude. https://blog.blinkenlight.net/experiments/dcf77/dcf77-generator/
wie ich weiter oben bereits geschrieben hatte, habe ich für ntpd einen Treiber entwickelt. ntpd läuft auf quasi allen Betriebsystemen, ob 32- oder 64-Bit. Es hat sich nur bisher niemand dafür interessiert. Ich selbst verwendet mittlerweile GPS. Mit den aktuellen Empfängern (UBlox NEO-M8N) geht dies sogar wenn die Antenne in Innenraum am Fenster angebracht ist und in meiner Umgebung sogar besser als DCF77. Mit einem Raspberry Pi habe ich das zusammen mit PPS laufen und seither eine ziemlich genaue Uhr. FTDI USB Seriell Adapter funktioniert bei mir mit dem Hopf Teil, allerdings habe ich das noch nicht in Kombination mit dem ntpd Treiber getestet, sondern nur manuell mit einem Terminalprogramm. Der Trick bei dem Teil ist, dass man durch DTR und RTS die Uhr zurücksetzen kann (d.h. Empfang wir neu begonnen) oder eben die aktuelle Zeit abrufen kann. Michael
Michael D. schrieb: > Der Trick bei dem Teil ist, dass man durch DTR und RTS die Uhr > zurücksetzen kann (d.h. Empfang wir neu begonnen) oder eben die aktuelle > Zeit abrufen kann. Hier konkret die Beschreibung der Signale. Normalbetrieb DTR=cleared, RTS=cleared, BREAK=cleared Währendessen kann die Uhr per DCF77 synchronisiert werden, ich denke das macht sie wahrscheinlich einmal in der Nacht? Daten werden keine ausgegeben. Abfrage der Uhrzeit DTR=cleared, RTS=cleared, BREAK=set Es wird jede Sekunde folgendes Telegramm mit 300 Baud ausgegeben (jeweils mit CR abgeschlossen): 200151221111753 200152221111753 200153221111753 In diesem Modus ist keine DCF77 Synchronisierung möglich, außerdem wäre es möglich, dass die Batterie stärker belastet wird. Man sollte dies also nur machen, solange man die Uhrzeit tatsächlich benötigt. Reset der internen Uhrzeit DTR=set (für ca. 8 bis 10 Sekunden), RTS=cleared, BREAK=cleared Nachdem DTR wieder auf "cleared" gestellt ist, Wird die Zeit zurückgesetzt und der DCF77 Empfang wird gestartet. Solange DTR=set ist, bleibt der Empfänger im Reset stehen. Vor allem der Punkt, dass man die Uhrzeit nicht dauernd abfragen sollte hat meinen ntpd RefClock Treiber durcheinandergebracht. Dies muss ich noch ändern, dann sollte er eigentlich vernünftig funktionieren und ich kann ihn veröffentlichen. Zum Testen nimmt man am besten "RealTerm", schaltet Hardware Flow Control ab und kann dann auf der Seite "Pins" RTS, DTR und BREAK wie oben beschrieben setzen. Wenn man DTR=clear nicht schnell genug einstellt (<8 Sekunden), dann wird die Zeit zurückgesetzt. Viele Grüße, Michael
:
Bearbeitet durch User
> *Abfrage der Uhrzeit* > DTR=cleared, RTS=cleared, BREAK=set > Es wird jede Sekunde folgendes Telegramm mit 300 Baud ausgegeben > Zum Testen nimmt man am besten "RealTerm", schaltet Hardware Flow > Control ab und kann dann auf der Seite "Pins" RTS, DTR und BREAK wie > oben beschrieben setzen. > Michael Danke, für den super Tip sowohl für das "Break" als auch "Realterm"! Das Programm kannte ich noch gar nicht. Habe bisher immer probiert die Uhr per HAmmerTerm zum Senden zu bewegen. In der Txt Datei oben stand ja was von "o" senden damit die Uhrzeit zurück kommt. Wie ein paar mal zu lesen war ist ja scheinbar die Meinung das sich niemand für den NTP Treiber interessiert. Zumindest mich würde der durchaus interessieren. Allerdings nicht als fertige bin bzw. exe auf einem Windows Pc. Habe hier ebenfalls einen Pi3 mit Adadfruit Gps / PPS und Dachantenne als reinen NTP Server am laufen. Mal sehen wie es in den nächsten Wochen mit Freizeit aussieht. Schreibe gerade mit C# eine Windows exe die das DOS Fenster nachbildet. Die 100 mm Antenne funktioniert so weit schon mal sehr gut, gerade mache mir eine kleine Platine um 5V per Usb auf die originalen 3,17 V zu drosseln.
Hallo Stephan, Stephan K. schrieb: > Wie ein paar mal zu lesen war ist ja scheinbar die Meinung das sich > niemand für den NTP Treiber interessiert. > Zumindest mich würde der durchaus interessieren. Allerdings nicht als > fertige bin bzw. exe auf einem Windows Pc. Mein Windows Büro-Rechner macht derzeit Probleme. Es läuft irgendeine übel programmierte Uhrzeit Synchronisation welchen ca. 1x pro Minute die Uhrzeit hart stellt und dabei ständig Sprünge zwischen 4 ms und manchmal bis zu 400 ms erzeugt. Vor einem halben Jahr konnte ich das noch nicht feststellen und ich weiß noch nicht so recht, wie ich die Software identifizieren kann, schätze mal unser IT-Team hatte diese tolle Idee. Die Windows w32time Zeit-Synchronisation ist es nicht, die habe ich abgeschaltet. Momentan bin ich am Testen auf einen IOT2040 unter Linux. Was mich vor allem interessiert sind die Abweichungen zu GPS und wann der Empfänger sich tatsächlich synchronisiert und wie er dazwischen wegdriftet. Ich konnte regelmäßig Sprünge von ca. 15 ms beobachten und denke das sind die Zeiten an welchen sich der Empfänger synchronisiert. Was auch noch nicht so richtig gut passt ist der Code für die Abfrage der seriellen Schnittstelle, da dies zum Teil vom ntpd selbst gemacht wird und mir noch nicht klar ist, wann er der Meinung ist ein komplettes Telegramm empfangen zu haben (nach Anzahl Zeichen oder wenn CR empfangen wird). Die Telegramme werden ca. 730 ms nach Beginn der Sekunde empfangen (laut clockstat log). Wenn diese Zeit konstant ist, kann man sie gut kompensieren. 533 ms davon kommen von der Übertragung des Telegrams bei 300 Baud, der Rest könnte eine Wartezeit auf weitere Zeichen sein. Michael
Michael D. schrieb: > wann der Empfänger sich tatsächlich synchronisiert Nach der Auswertung meiner Logs kann ich sagen, dass dies höchstwahrscheinlich jede Stunde passiert. > und wie er dazwischen wegdriftet. Mein Empfänger hat aktuell auf dem Fensterbrett eine Drift von ca. -1,3 ppm. Beim Synchronisieren per DC77 gibt es Abweichungen bis zu ca. +-20 ms. Michael
:
Bearbeitet durch User
Hi,
Im Anhang findet ihr den ntpd RefClock Treiber für die Hopf Clockmouse
als Patch für ntpd 4.2.8p10.
Hier eine Beispielkonfiguration dafür:
# configuration in ntp.conf ("mode 1" is important!)
# don't use maxpoll values below 8 (256 seconds) to allow
# the receiver to synchronize with DCF77.
# Maxpoll values larger than 12 (4096 seconds) are not recommended
# because of the drift and the hourly synchronization of the receiver
server 127.127.38.1 iburst minpoll 8 maxpoll 12 mode 1
fudge 127.127.38.1 time1 +0.212
Die in dieser Konfiguraion verwendete COM Schnittstelle ist COM1 unter
Windows, bzw. /dev/hopfclock1 unter Linux (als Softlink zu erstellen).
Dies ist die ".1" am Ende der "IP-Adresse". Maximal kann man hier meines
Wissens Werte bis 4 angeben.
Michael
Hallo, durch einen Ausfall des DCF77 Empfangs musste ich leider feststellen, dass die eingebaute Quarzuhr meines Clock Controller ohne Empfang sehr schnell wegdriftet. Die Frage ist was stärker driftet, die interne PC-Uhr oder die externe Quarzuhr des DCF-77 Empfängers. ntpd kann die systematische Drift der PC-Uhr recht gut kompensieren, selbst wenn er einige Zeit keinen Empfang hat. Aus diesem Grund sollte der Code geändert werden, d.h. anstatt der Konstanten HOPFCM_ST_VALID sollte HOPFCM_ST_PREV_RECP_OK verwendet werden. Original + if (((statusbits & (HOPFCM_ST_VALID | HOPFCM_ST_FIRST_RECP_ABORTED | HOPFCM_ST_BATTERY_LOW)) != (HOPFCM_ST_VALID)) Neu + if (((statusbits & (HOPFCM_ST_PREV_RECP_OK | HOPFCM_ST_FIRST_RECP_ABORTED | HOPFCM_ST_BATTERY_LOW)) != (HOPFCM_ST_PREV_RECP_OK)) Getestet habe ich das noch nicht. Rückmeldungen sind erwünscht. Michael.
Habe das soweit am laufen nur steht da: Current local NTP Status: Please wait... Mehr passiert da nicht. Empfang habe ich, zumindest mit RCCD.com kann ich es testen und der gibt mir alles, also Datum und Uhrzeit, korrekt aus. Micky
Micky M. schrieb: > Current local NTP Status: Please wait... Wer (welches Tool) gibt diese Meldung aus? Welches Betriebssystem verwendest du? mit ntpq kannst du die Diagnose von ntpd abfragen. Die genaue Syntax habe ich nicht exakt im Kopf. ntpq -p ntpq -c rv0 dann kannst du noch die Logs (bzw. Stats) im ntpd.conf aktivieren und siehst so jedes einzelne Telegramm welches empfangen wurde. Wenn du die Änderung wie beschrieben gemacht wird, dann wird nur synchronisiert solange der Empfänger auch tatsächlich Empfang hat. Der Hintergrund dazu ist, dass die (von ntpd) kompensierte Drift deines PC Quarzes geringer ist als die eingebauten (unkompensierten) Uhr des DCF77 Empfängers. Zeitsynchronisation ist ein sehr langsamer Prozess, das kann schon Stunden dauern bis die Uhrzeit tatsächlich akzeptiert wird. Mindestens 900 Sekunden dauert schonmal die erste Messung der Drift deines Quarzes. Michael
:
Bearbeitet durch User
Ich nehme Windows Vista Home Premium 32 Bit. Das Programm was diese Meldung ausgibt ist NTP Time Server Monitor by Meinberg 1.04. Das andere Programm was ich nehme ist ntp-4.2.4p8@lennon-o-lpv-win32. Die können hier stundenlang laufen. NTP wird nicht synchronisiert. Damit auch nicht die Pc Uhr. Micky
mickymm schrieb: > Das Programm was diese Meldung ausgibt ist NTP Time Server Monitor by > Meinberg 1.04. Das ist schomal sehr gut, dass hätte ich auch empfohlen :-) Das liefert aber auch deutlich mehr Diagnose als nur "Current local NTP Status: Please wait...", z.B. das Server-Status-Wort. > Das andere Programm was ich nehme ist ntp-4.2.4p8@lennon-o-lpv-win32. Hast du das aus den Sourcen selbst übersetzt und vorher den Patch aus meinen Posting applied? Ansonsten wird es nicht funktionieren. Normalerweise muss die Uhrzeit des PCs in einem Bereich von +-20 Minuten bereits korrekt gehen, ansonsten wird die Uhrzeitquelle ignoriert. Man kann auch beim Starten ein Flag angeben ("-g -x"), damit immer synchronisiert wird, aber gerade beim störungsanfälligen DCF77 Empfang ist dies nicht zu empfehlen. Windows Kommandozeilenoptionen siehe hier: https://www.eecis.udel.edu/~mills/ntp/html/ntpd.html Michael
:
Bearbeitet durch User
Ich habe nichts compiliert. Habe einfach diese .diff Datei ins Verzeichnis kopiert und im NTP Konfiguration File das hier eingegeben: server 127.127.38.1 iburst minpoll 8 maxpoll 12 mode 1 # don't use maxpoll values less than 8 fudge 127.127.38.1 time1 +0.212 # I'm still investigating the exact value and the reason where this comes from to get rid of it Ok, so kann das natürlich nicht gehen. Gibt es denn nicht eine lauffähige gepatchte Version? Micky
Micky M. schrieb: > Ok, so kann das natürlich nicht gehen. Gibt es denn nicht eine > lauffähige gepatchte Version? Klar, gepatchtes binary für Win32 siehe Anhang. Ist eine Version ntpd 4.2.8.p10. Michael
Ich grab diese Leiche nochmal aus, weil ich auch so ein Spielzeug habe und nutzen wollte. Mir ist aufgefallen, das ich für das vorletzte Byte aktuell immer 5 zurückbekomme in ASCII, also 0101 Anleitung sagt:
1 | Bit3 Ankündiging Schaltsekunde, Bit19 des DCF77-Protokolls |
2 | Bit2=1 während MEZ, =0 während MESZ, Bit18 des DCF77-Pr. |
3 | Bit1=0 während MEZ, =1 während MESZ, Bit17 des DCF77-Pr. |
4 | Bit0 Ankündigung Wechsel MEZ-MESZ und umgekehrt, Bit16 des DCF77-Pr. |
Nanü? Wieso ist das Wechselbit aktiv? Das sollte nur Nachts kurz vorher an sein, nicht jetzt. Aktuell sagt die Kiste in Ascii "104154413032553", und das passt, bis auf das Bit. Warum ist dem so?
Jens M. schrieb: > Warum ist dem so? Ist das bei anderen Empfängern auch so? Auf der Seite wo A1 (Bit 16) beschrieben ist, steht ein Kontakt von der PTB, den man fragen könnte ob die bei sich was geändert haben: https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/zeitcode.html Viele Grüße, Michael
:
Bearbeitet durch User
Michael D. schrieb: > Ist das bei anderen Empfängern auch so? https://dcf77logs.de/logs/DcfLog_20250313/dcf Da sieht es fast so aus, als ob die Maus die Bits um 1 verschiebt.
Michael D. schrieb: > Ist das bei anderen Empfängern auch so? Ich hab leider aktuell keinen der das anzeigen könnte, und technisch wäre es mir auch egal, es wunderte mich nur. Bauform B. schrieb: > Da sieht es fast so aus, als ob die Maus die Bits um 1 verschiebt. Wie meinen? Im Log steht für die 4 fraglichen Bits und die beiden Nachbarn 0 0010 1, allerdings ist hier Bit 19 rechts. Die Clockmouse sagt in der Notation x 1010 x, das ist wenn dann 2 Bits verschoben, aber der Rest passt?! Ändert sich auch mit neuem Empfang und Kaltstart nicht. Da die Doku zu 99% nicht zutrifft, hat das Bit evtl. eine andere Bedeutung als da steht. Denn: alle anderen Bits liefern korrekte bzw. plausible Daten. Zumindest was MEZ/MESZ und das letzte Byte angeht.
Jens M. schrieb: > Bit0 Ankündigung Wechsel MEZ-MESZ und umgekehrt, Bit16 des DCF77-Pr. Ich habe mal in meinem Sourcecode nachgesehen, dort hatte ich folgendes geschrieben:
1 | +// must have different meaning or is inverted, example value: 200151221111753 => DST_SW_ANNOUNCE would be set |
2 | +//#define HOPFCM_DCF_DST_SW_ANNOUNCE 0x01 /* daylight saving switch annoucement (DCF77 bit 16)*/ |
Ich hatte damals also auch festgestellt, dass der Wert nicht stimmt bzw. ggf. invertiert ist. Wäre also interessant, wenn Du Ende des Monats bei der Zeitumstellung dieses Bit mal mitloggt wie es sich verhält in den Stunden vor und während der Zeitumstellung. Für meinen Code im ntpd habe ich das sowieso nicht benötigt. Michael
:
Bearbeitet durch User
Och kucke mal, das ist interessant. Ich versuch dran zu denken... Bin ja selber gespannt. edit: War es nicht so, das es entweder Daten oder Empfang gibt? Dann muss ich was basteln, das die Daten nur einmal pro Minute (besser vielleicht sogar nur alle 5 Minuten) angefordert werden und in einer Datei landen. Jemand ne Idee für Windows mit Bordmitteln? Ich wollte nur ungern morgens um halb zwei nachsehen müssen...
:
Bearbeitet durch User
Jens M. schrieb: > Jemand ne Idee für Windows mit Bordmitteln? Ich wollte nur ungern > morgens um halb zwei nachsehen müssen... Ich habe mal ein Powershell script schreiben lassen, aber noch nicht getestet. Muss erst mal eine Clockmouse finden.
1 | # Define COM port and settings (Use \\.\ notation for COM ports > 9)
|
2 | $portName = "COM1" # adapt to your clockmouse port |
3 | $baudRate = 300 # Set baud rate to 300 |
4 | $parity = [System.IO.Ports.Parity]::None |
5 | $dataBits = 8 |
6 | $stopBits = [System.IO.Ports.StopBits]::One |
7 | |
8 | # Endless loop
|
9 | while ($true) { |
10 | # Open the serial port
|
11 | $serialPort = New-Object System.IO.Ports.SerialPort $portName, $baudRate, $parity, $dataBits, $stopBits |
12 | $serialPort.Open() |
13 | |
14 | # Send a BREAK signal for 2 seconds
|
15 | $serialPort.BreakState = $true |
16 | Start-Sleep -Seconds 2 |
17 | $serialPort.BreakState = $false |
18 | |
19 | # Read until CR ('\r') is received
|
20 | $receivedData = "" |
21 | do { |
22 | if ($serialPort.BytesToRead -gt 0) { |
23 | $char = [char]$serialPort.ReadByte() |
24 | $receivedData += $char |
25 | }
|
26 | } while ($char -ne "`r") # Stop when CR is received |
27 | |
28 | # Print the received data (without trailing CR)
|
29 | Write-Output "Received: $($receivedData.TrimEnd("`r"))" |
30 | |
31 | # Close the port
|
32 | $serialPort.Close() |
33 | $serialPort.Dispose() |
34 | |
35 | # Wait for 2 minutes before repeating
|
36 | Start-Sleep -Seconds 120 |
37 | }
|
als readhopf.ps1 speichern und den output in eine Datei umleiten. ggf. muss Powershell erst noch aktiviert werden in einer Powershell mit Admin Rechten folgendes aufrufen:
1 | Set-ExecutionPolicy -ExecutionPolicy RemoteSigned |
Michael
:
Bearbeitet durch User
Michael D. schrieb: > Ich habe mal ein Powershell script schreiben lassen Bin gespannt, ob die Halluzination funktioniert, ich teste das bei Gelegenheit. Welche KI war's?
Jens M. schrieb: > Bin gespannt, ob die Halluzination funktioniert, ich teste das bei > Gelegenheit. > Welche KI war's? ChatGPT :-) Solche Brot- und Butter Lösungen sind oft zu 90% korrekt, bei komplexeren Dingen wo es ums Verstehen geht, ist die Quote deutlich schlechter. Michael
Michael D. schrieb: > Ich habe mal ein Powershell script schreiben lassen, aber noch nicht > getestet. Muss erst mal eine Clockmouse finden. Hier im Anhang eine manuell überarbeitete Version eines Powershell Scripts welche alle 10 Minuten die Uhrzeit ausliest und danach die Resynchronisation aktiviert. An der LED kann man sehen, wenn der DCF77 Empfang aktiviert wird. Damit kann man die hoffentlich das Bit 16 für die Sommer-/Normalzeitumstellung debuggen. Im Script muss noch der Serial Port angepasst werden:
1 | $portName = "COM3" |
Ich kann nicht sagen, was passiert, wenn man Portnummern größer als 9 hat, ich würde das lieber vermeiden. Das hier gilt weiterhin: ggf. muss Powershell erst noch aktiviert werden in einer Powershell mit Admin Rechten folgendes aufrufen:
1 | Set-ExecutionPolicy -ExecutionPolicy RemoteSigned |
In einem Powershell Fenster das Script starten und die Ausgabe am besten in eine Datei umleiten:
1 | read_hopf_serial.ps1 >hopf.log |
Das Logfile sollte dann so aussehen:
1 | Received: 011945420032553 |
2 | Received: 012502420032553 |
Michael
:
Bearbeitet durch User
Jens M. schrieb: > Denn: alle anderen Bits liefern korrekte bzw. plausible Daten. > Zumindest was MEZ/MESZ und das letzte Byte angeht. Kannst du heute nacht mal mitloggen, siehe das korrigierte Powershell script welches ich im letzten Posting als Anhang geschickt habe? Aktuell sehen die Daten bei mir so aus:
1 | Received: 105541528032553 |
2 | Received: 110059528032553 |
3 | Received: 110617528032553 |
4 | Received: 111135528032553 |
5 | |
6 | Received: 142646629032553 |
7 | Received: 143202629032553 |
8 | Received: 143718629032553 |
9 | Received: 144234629032553 |
10 | Received: 144750629032553 |
Michael
:
Bearbeitet durch User
Ja, Dauerlog läuft, ich hab das Skript noch ein wenig überarbeitet so das es Klartext dekodiert und eine Logdatei zusätzlich zur Liveausgabe macht. Aktuell sehe ich
1 | 183626629032553 Sa 29.03.25 18:36:26 0101 0011 |
Wenn der Empfang leicht gestört ist (es flackert ab und zu extra), bekomme ich oft in den 5 Minuten (und 17 Sekunden) keine Zeit, manchmal sogar schmiert das Skript ab beim Einlesen der Daten der Seriellen. Ich habe den Aufbau daher in eine elektrisch ruhige Umgebung verfrachtet und kann nur via Teamviewer hin. Hat die ganze Woche geloggt, keine Fehler bis auf gelegentliche nichtsyncs. Natürlich schmiert heute Nacht der Laptop ab ;) Die Mouse braucht ~45 Sekunden nach der Skriptausgabe bis die LED reagiert, dann ein paar Fehlzündungen (Daueran, Daueraus für mehrere Sekunden) bis es regelmäßig blinkt, da wird wohl die AGC angepasst. Aber der Dekoder ist recht pingelig, das hätte ich von Hopf anders erwartet. Sogar in der Doku oben steht bei der Empfangsqualität, das unter 3 von 5 nix geht, leider ist die Maus zu doof das auszugeben, aber wenn gelegentliche Extrapulse so den Empfang versauen... Sie braucht anscheinend echt 2 vollständige intakte Protokolle hintereinander für eine gültige Zeit. Bin gespannt was morgen in der Datei steht.
:
Bearbeitet durch User
Jens M. schrieb: > Die Mouse braucht ~45 Sekunden nach der Skriptausgabe bis die LED > reagiert, dann ein paar Fehlzündungen (Daueran, Daueraus für mehrere > Sekunden) bis es regelmäßig blinkt, da wird wohl die AGC angepasst. Das bewegt sich in dem zeitlichen Rahmen wie mein Eigenbau, der auf einer PTB-Schaltung der 70er-Jahre basiert. Die heute käuflichen China-Module starten schneller, was man aber mit Jitter und erheblichen Abweichungen der 100/200ms bezahlen muß. > Aber der Dekoder ist recht pingelig, das hätte ich von Hopf anders > erwartet. Das ist auch gut so. Meine erste DCF-Uhr war eine Ansammlung ganz vieler TTL-ICs und zeigte sporadisch falsch an, das will man nicht habem. > Sogar in der Doku oben steht bei der Empfangsqualität, das unter 3 von 5 > nix geht, leider ist die Maus zu doof das auszugeben, aber wenn > gelegentliche Extrapulse so den Empfang versauen... > Sie braucht anscheinend echt 2 vollständige intakte Protokolle > hintereinander für eine gültige Zeit. Meine später mit CPU gebaute Uhr zeigt nach dem ersten Satz an, aber macht die Feheranzeige erst aus, wenn zwei gültig plausible Datensätze empfangen wurden. Egal wie, ich will niemals eine falsche Zeit sehen! In einem älteren Thread hat der Gustav seine DCF-Kuckucksuhr gezeigt: Beitrag "DCF77 - Kuckucksuhr" In seinem YT-Video erklärt er sehr detailliert, wie man Fehler detektiert, ausnahmsweise mal kein Idiotenfilmchen: https://www.youtube.com/watch?v=oywM7ytlZ7o
So, nu: Die Clockmouse ist offensichtlich noch wesentlich einfacher gestrickt als man denken würde.... Für den Großteil der Zeit (bis auf gelegentliche nicht-Syncs) gibt sie
1 | 234249629032553 Sa 29.03.25 23:42:49 0101 0011 |
2 | 234806629032553 Sa 29.03.25 23:48:06 0101 0011 |
3 | 235323629032553 Sa 29.03.25 23:53:23 0101 0011 |
4 | 235840629032553 Sa 29.03.25 23:58:40 0101 0011 |
5 | 000357730032553 So 30.03.25 00:03:57 0101 0011 |
6 | 000914730032553 So 30.03.25 00:09:14 0101 0011 |
7 | 001431730032553 So 30.03.25 00:14:31 0101 0011 |
8 | 001948730032553 So 30.03.25 00:19:48 0101 0011 |
aus. Nach meinem Verständnis sollte ab Sonntag morgen 01:00 das Bit für die SoWi-Warnung gesetzt sein, was die Mouse aber nicht anzeigt:
1 | 013903730032553 So 30.03.25 01:39:03 0101 0011 |
2 | 014420730032553 So 30.03.25 01:44:20 0101 0011 |
3 | 014937730032553 So 30.03.25 01:49:37 0101 0011 |
4 | 015454730032553 So 30.03.25 01:54:54 0101 0011 |
Um 02:00 am Sonntag macht die Zeit einen Hops, d.h. auf 1:59:59 folgt 03:00:00, oder? Natürlich hat das Skript gerade passend um genau kurz nach 2 abgefragt, d.h. es kommt noch die Quarzzeit 02:00:11, dann der Resync, der plötzlich 03:00 liefert. Der Decoder kann es offensichtlich nicht glauben, die letzten 24h waren frei von Empfangsfehlern, was ein Zufall das es genau jetzt klemmt:
1 | 020011730032551 So 30.03.25 02:00:11 0101 0001 |
2 | 000455000000050 So 00.00.00 00:04:55 0101 0000 |
Aus welchem Grunde um 02:00 das vorletzte Bit Null ist? Angeblich "=0 wenn der vorhergehende Empfangsversuch nicht erfolgreich war", dagegen spräche die korrekte Zeit, die nach dem Reset definitiv 0:0:0 ist. Jetzt glaubt er es jedenfalls und liefert die offizielle MEZ, aber ohne das er das auch ansagt:
1 | 031044730032553 So 30.03.25 03:10:44 0101 0011 |
2 | 031601730032553 So 30.03.25 03:16:01 0101 0011 |
3 | 032118730032553 So 30.03.25 03:21:18 0101 0011 |
4 | 032635730032553 So 30.03.25 03:26:35 0101 0011 |
Fazit: das letzte Byte kann nur ASCII 0, 1 oder 3 sein, und m.E. sind alle Werte !=3 ein Zeichen für eine ungültige Zeit. Ansonsten ist die komplette "Anleitungs-Textdatei" nutzlos, bis auf die Parameter für die serielle Schnittstelle. Schade, ein autonomer Dekoder wäre cool gewesen, aber das Ding ist pingelig und oft gestört. Es wundert mich, das man damals so ein kurzes Kabel drangemacht hat. Ich musste mich schon reichlich verrenken um einen Platz zu suchen an dem das Skript nicht dauernd abstürzt, weil die Mouse überhaupt keine Daten liefert oder völligen Quatsch. Der Laptop und die Mouse stehen jetzt in einem Industriegebiet, da ist am WE alles aus, alle Elektrogeräte sind min. 10m entfernt, kein Licht, das einzige was läuft ist 230V für die Heizung, DECT und WLAN, beides aber gut entfernt. Bei mir zuhause ist kein Empfang möglich, es blinkt zwar erkennbar lang und kurz, aber oft auch mal extra, wenn jemand Licht anmacht o.ä. Die Kabel vom Laptop sind lang gestreckt, das serielle Kabel der Mouse hängt am einem USB-Adapter, die Mouse vor dem Fenster. Standort etwa 300km von Mainflingen entfernt. Kommerzielle Uhren (billiger Kram u.A. von Feinkost Albrecht, aber auch aus dem Elektroschrott) sind wesentlich besser darin eine gültige Zeit zu finden, und die Blinkenlights-Library für Arduino funktioniert auch an Stellen an denen als Mensch kein verständliches Blinken mehr zu erkennen ist. Die Hopf Clockmouse hat einen deutlich besseren Empfänger als es die Pollin- und Reichelt-Module sind (blinkt gleichmäßiger im direkten Vergleich an "Grenzstellen"), gleichzeitig lässt sich der Dekoder von auch nur einer einzigen "Fehlblinkung" irritieren und ignoriert diese ganze Minute. Dazu reichts teilweise schon, das Gehäuse zu bewegen, zack, nach 5 Minuten noch keine gute Zeit im Skript. Offtopic und trotzdem im Zusammenhang und interessant: Ich habe mehrere Funkuhren verschiedenster Fabrikate herumgetragen und dauernd neugestartet in den letzten Tagen. Dabei habe ich eine ganz billige markenlose Zeigeruhr, die sich zunächst normal verhält, sie dreht ihre 3 Zeiger auf die 12 und wartet, dann dreht sie vor. Allerdings geht sie dann immer exakt 17 Sekunden nach?!?! Wie kommt das denn? Das andere Uhren teils eine Sekunde verschieden stehen, daran kann man sich gewöhnen, das scheint das Programmierermissverständnis zu sein, ob der Puls jetzt diese oder die nächste Sekunde angibt. Eine Uhr ist auch dabei, die gerne "1 bit" falsch geht, eins der Digits ist um 1, 2, 4 oder 8 daneben. Interessanterweise korrigiert sich das zur glatten Stunde.
:
Bearbeitet durch User
Der Vollständigkeit halber noch das von mir modifizierte Skript. Ist vielleicht nicht schick, aber mittels Stackexchange handgeklöppelt ;) und funktioniert.
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.