Lösung für DCF77 Empfangsprobleme

[MatthiasS]

Geduld, muss ja nicht so bleiben, gibt ja Updates ;-)

[makki]

oder SW Problem der WS und hat erstmal nichts mit DCF77 zu tun.

Richtig. 100% einverstanden. Trotzdem kaputt

Wenn der HS eine falsche Zeit von einem NTP-server bekommt,

Nochmal:
Der HS verwendet kein NTP !

sondern das uralte Time-Protokoll.
Edit: (*) Stand V2.3.2

Das hat mehrere Nachteile:
1. wird nicht dauerhaft synchronisiert sondern nur 1x täglich (warum das ein Nachteil ist steht in der RFC)
2. wird, wie Du schreibst erst bei eiber Nichterreichbarkeit des ersten ein weiterer verwendet. Dem ist bei NTP nicht so
3. existiert keine Sicherungsschicht, die Paketlaufzeiten berücksichtigt oder eine Fehlerübermittlung zulässt.

Ich widersetze mich diesem hartnäckigen HS/NTP-Gerücht deshalb so vehement, weil ich mir das nahezu perfekte NTP nicht von der schlechten implementierung des HS kaputtreden lasse, wo nur die Doku behauptet es wäre NTP.

So kenne ich es jedenfalls von Linux.

Was hat NTP mit Linux zu tun, ausser das es dafür auch Software gibt ? Vielleicht hast Du ntpdate verwendet, das mag ausreichen um einen Client gelegentlich zu synchronisieren, ein Zeitgeber für andere (was WS oder HS ja darstellen) sollte das aber *immer* anders machen und unter Linux z.B. den ntpd verwenden, siehe sämtliche RFCs von Time bis SNTP.

Zum Beispiel: DCF77 der WS und zwei NTP Server im Netz.

Es ist im Detail ein ganz klein bisschen komplizierter als ein simple Mehrheitsentscheidung
Vor weiteren Detaildiskussionen, nichts für ungut, bitte die RFC1305 lesen und die Unterschiede zwischen den verschiedenen Synchronisierungsvarianten beachten.

Fazit: Deswegen behaupte ich dass ein NTP-Server immer der bessere Zeitgeber (evtl. mit DCF77 als eine Quelle) ist als ein DCF77-Empfänger alleine, weil damit so ein Mist einfach by Design nicht passieren kann.
Und dass das im HS seites Gira/Dacom dringend von Time auf NTP umgebaut werden sollte..

@jonofe: ich würde das Signal der WS einfach in den ntpd einfüttern, der sollte das Problem reparieren. Nicht dass ich jetzt auf Anhieb wüsste wie man sowas macht aber Du bist ja sehr erfinderisch

Makki

[Michel]

Das gilt nur für den Empfang von Zeit und Datum via EIB und ist in der Hilfe auch korrekt beschrieben.

[tbi]

Wo liegt die obere ?

Hallo Matthias,

weißt Du wo dann da die Grenze ist ? In der Hilfe steht nichts dazu ?

Dann sollte man doch im HS beide Grenzen frei setzen können, oder ?
Die Untere (Karenzzeit) und die Obere.

Gruß Tbi

[MatthiasS]

Wenn der HS eine falsche Zeit von einem NTP-server bekommt, weil der NTP-Server "kaputt" ist (falschen Wert schickt), ist auch diese Variant nicht in der Lage dies zu erkennen. Selbst wenn man einen zweiten NTP-Server eingetragen hat. Erst wenn der erste NTP-Server nicht erreichbar ist, wird der zweite genommen. So kenne ich es jedenfalls von Linux.

Allerdings gleicht der HS nicht ab, wenn die Differenz zu groß ist.

[tbi]

Interne Uhren sind immer da

Hallo Makki,

eine DCF77 Funkuhr sowie der HS haben intern eine Uhr, die immer weiter läuft. Mit DCF77 wird immer, wenn das Funksignal komplett empfangen wurde, die Zeit in der internen Uhr neu gesetzt. Das kann auch nur alle zwei Tage passieren. Dazwischen läuft die interne Uhr weiter.

Bei Swen, wie bei Jonofe, ist das Funksignal jedoch falsch ausgewertet worden, damit wurde mit einer falsche Zeit synchronisiert. Dies ist ein HW oder SW Problem der WS und hat erstmal nichts mit DCF77 zu tun.

Beim HS wird die Zeit neu gesetzt, wenn die Differenz zwischen vom IP-Netz empfangener Zeit und interner Uhr einen bestimmter Wert überschritten ist. Dieser Differenzwert ist einstellbar.

Wenn der HS eine falsche Zeit von einem NTP-server bekommt, weil der NTP-Server "kaputt" ist (falschen Wert schickt), ist auch diese Variant nicht in der Lage dies zu erkennen. Selbst wenn man einen zweiten NTP-Server eingetragen hat. Erst wenn der erste NTP-Server nicht erreichbar ist, wird der zweite genommen. So kenne ich es jedenfalls von Linux.

Technische Probleme der zugelieferten Uhrzeit kann man nur Erkennen, wenn man mehrer Quellen hat und dann eine Mehrheitseintscheidung trifft.

Zum Beispiel: DCF77 der WS und zwei NTP Server im Netz. Dann hat man drei Quellen. Die Wahrscheinlichkeit das zwei Zeitquellen gleichzeitig ausfallen ist gering. Ausfall der IP-Netzverbindung ist ja selbst leicht zu erkennen.

Übrigens holen sich NTP-Server ja auch nur die Zeit über DCF77. Das Signal ist schließlich die offizielle Zeit in Deutschland.

Gruß Tbi

[makki]

Es scheint also ein echtes Problem bei Elsner mit dem DCF77 Empfang zu geben.

Das Problem kann auch DCF77 sein, das funktioniert schlicht nicht überall. An meinem letzt Wohnort in München bspw.: katastrophal, da hat DCF77 (ohne EIB) garkeinen Spass gemacht sag ich Dir..

Es ist immer die Frage: Wovon ein System abgängig sein soll ....... DCF77-Funk oder Internet ...

Da würde ich immer NTP nehmen. das funktioniert zuverlässig, die SW ist millionenfach seit Jahrzehnten in Betrieb und ausgereift, hat eingebaute Fehlererkennungs- und Vermeidungsmechanismen und verschlucken sich nicht Ebenso, was den WS offenbar fehlt, ist eine eingebaute Uhr, die im Störungsfall frei weiterläuft (und Fehler auch erkennt).. Im Zweifelsfall tage oder wochenlang.

Das gilt für den HS aber leider nur teilw., weil er kein NTP verwendet. Steter Tropfen..

Makki

[tbi]

Hallo TRex,

hmm, und meint ihr nicht, daß eine Serverzeit über den HS dann die einfachere Lösung wäre?

Wer einen HS hat, kann das sofort machen. Oder wenn er eine andere Zeit und Datumsquelle hat. Torsten (oben) hat das ja dann so lösen müssen. Das er eine EIB Uhr nachinstallieren muste.

Wer den HS hat und Netzzugang zu NTP-Servern, also kein Problem.

Wer keinen HS hat braucht 'ne EIB Uhr .

Dann wird der Wetterstation die Zeit und Datum geschickt und sie berechnet die Beschauttung wieder aus.

Es ist immer die Frage: Wovon ein System abgängig sein soll ....... DCF77-Funk oder Internet ...

Gruß Tbi

[TRex]

hmm, und meint ihr nicht, daß eine Serverzeit über den HS dann die einfachere Lösung wäre?

Für mich stellt sich immer wieder die Frage warum ich die Zeit aus dem DCF77 Empfänger sowie aus der Wetterstation und aus dem HS bekommen kann.

Ein gegenseitiger Abgleich macht ja keinen Sinn - außer man hat den Elsner Suntrace :

wäre es denn denkbar, dem Elsner nur die Zeit mitzuteilen und so die offenbaren Bugs dort zu umgehen?

[jonofe]

Hallo,

ich habe auch eine SunTracer allerdings mit RS485 Schnittstelle und habe genau dieselben Probleme. Die WS sendet jede Sekunde die aktuellen Daten inkl. Zeit. Sporadisch empfange auch ich hier keine gültige Uhrzeit und Datum. Es wird dann nur 15:15:15 00.00.0000 gesendet. Da aber die Daten inkl. Checksumme kommen, liegt es sicher nicht an der Übertragung von WS zum PC noch an der Auswertung im PC. Es muss also in der WS liegen. Da ich die WS seit ca. einem Jahr habe und jede Minuten die Daten in eine MySQL Datenbank pumpe konnte ich genau feststellen, dass es die ersten 2 Monate funktionierte und danach nicht mehr. Ein neu ausrichten der DCF77 Antenne brachte auch keinen Erfolg. Interessanter weise ist sowohl der Zeitpunkt als auch die Dauer der Fehlübertragung nicht vorhersagbar. Einzig die Übertragung genau in der Sekunde um Mitternacht 00:00:00 ist immer falsch. Dann wird immer 15:15:15 00-00-0000 übertragen. Oft aber nur für diese eine Sekunde. Es scheint also in der Auswertung der WS was schief zu laufen. Werde wohl jetzt auch mal mit Elsner in Kontakt treten.

Als ich übrigens die Wetterstation gekauft habe, habe die ersten 2 Geräte gar keinen Empfang DCF77 zu stande gebracht, d.h. die WS wurde 2 mal ausgetauscht. Es scheint also ein echtes Problem bei Elsner mit dem DCF77 Empfang zu geben.

[swenga]

Hallo,

ja, zum Mond fliegen muessen die Haeuser nicht, aber so einige Komponenten koennte man manchmal...

Bis jetzt habe ich vom defekten teil nix mehr gehoert, mit dem Ersatzgerät sind jetzt zwei Freitage vergangen und es funktioniert.

mfg Swen

[tbi]

Cme6005

Hallo,

wen es interessiert. Bei mir war der DCF77 Empfangchip CME6005 drauf.

Ich habe dazu ein Datenblatt bzw. Applicationsbeschreibung gefunden:

http://www.c-max-time.com/downloads/getFile.php?id=514

Auf Seite 9 steht wie das deutsche Signal DCF77 ausgewertet wird. Dort steht auch das drei Paritybits in dem Signal enthalten sind. Also wenn das nicht reicht um zu sagen, ob das Signal korrekt ist ?. Da muß der nachgeschaltete Controller (der das Signal an TCO oder TCON auswertet) wirklich kaputt sein.

Gruß Tbi

[tbi]

Kaputt ist Kaputt

Hallo Swen,

zu 1.) Klar, ohne auf den BUS zu schauen ist sowieso alles nur geschätzt.

zu 2.) Also, ich weiß nicht was du genau unter weiterkoppeln verstehst. Aber bei deiner kaputten Suntracer war anscheinend genau die interne Uhr kaputt oder der Speicher dafür. Es ist immer so, dass Funkuhren intern weiterlaufen, bis sie wieder synchronisieren. Das kann sein, dass das nur einmal am Tag klappt. Das reicht aber. Denn die Ungenauigkeit der internen Uhr ist so schlecht auch nicht. Nach Wochen wird sie dann sicher langsam falsch gehen. Bei dir hat sie aber auf vollkommen falsche Werte synchronisiert. Das ist aber wirklich sehr selten. Ich habe schon viele Funkuhren gesehen, den Fehler aber noch nie.

Wenn Du es besser machen willst, kannst Du ja mit dem HS über NTP und über die Suntracer ein redundantes System aufbauen. Also beides Konfigurieren und dann mit einer Logik immer vergleichen. Wenn der Unterschied zu groß wird gib es ein Alarm.

Also, es kann immer was kaputt gehen. Auch der HS. Da hilft dann nur Redundanz. Bei wichtigen Aufgaben nimmt man auch drei Geräte, dann kann man immer noch eine Mehrheitsentscheidung treffen. Aber unsere Hütten sollen ja nicht zum Mond fliegen.

Irgendwann stelle ich den HS auch noch auf NTP um.

Das geht übrigens echt simpel. Einfach die NTP Server eintragen.

Gruß Tbi

[swenga]

Hallo,

ja, die Empfangs-LED hat eigentlich sauber geblinkt. Isnofern ist da gewaltig was schiefgelaufen, da eben eine falsche Uhrzeit als "richtig" markiert wurde. Mit dem Austauschgerät funktioniert es derzeit. Dennoch fuer mich "lessons learned":

1) Bei Zeitproblemen die ETS anschmeissen und auf den Bus schauen. Ursachen können mannigfaltig sein.

2) Es ist schade, dass die Wetterstation die Uhrzeit nicht intern weiterkoppelt (zumindest über Empfangslücken hinweg) und somit die Sonnenstandsberechnung komplett über den Deister geht. Hier könnte der Hersteller nachbessern. Derzeit heisst es: Sonnenstandsberechnung bleibt im HS. Irgendwann stelle ich den HS auch noch auf NTP um.

mfg Swen

[tbi]

Die Auswertung wars wohl.

Hallo Swen,

wenn Du einen Empfang hast, heißt das, daß das 1 Minutenlange DCF77 Signal komplett gelesen und Verstanden wurde. Dann ist die Zeit immer richtig. Anscheinend hat aber die Wetterstation dann mit dem Signal mist angestellt.

Der DCF77 Empfangs-Chip gibt das Signal dann Binär an die Auswertung in der Suntracer weiter und da scheint was nicht mehr in Ordnung zu sein.

Also nochmal entweder Du hast Empfang, dann stimmt die Zeit in dem Signal auch, oder Du hast keinen Empfang. Dann hast Du aber auch keine Zeit in der Wetterstation, und dann auch keine Beschattungsberechnung.

Ich vermute eine neue Wetterstation und alles geht wieder, Empfang hast Du ja gehabt.

Wer partou keinen Empfang hat kann die Zeit mit dem HS über NTP empfangen und an die Wetterstation schicken. Dann macht sie die Beschattungsberechnung auch wieder richtig.

Wie geht es denn mit dem Austauschgerät. Sollte doch jetzt alles wieder mit DCF77 gehen, oder ?

Gruß Tbi