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.
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.
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.
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"?
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
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.
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.
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.
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"
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.htmhttps://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
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.
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
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ß
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
> *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
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
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
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?
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
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
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...
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)
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:
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-ExecutionPolicyRemoteSigned
In einem Powershell Fenster das Script starten und die Ausgabe am besten
in eine Datei umleiten:
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:
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.
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.
Der Vollständigkeit halber noch das von mir modifizierte Skript.
Ist vielleicht nicht schick, aber mittels Stackexchange handgeklöppelt
;) und funktioniert.