RNBFRA: Ein DCF77-Sklave

[Carlo]

So Dirk, war neugierig und habe die Uhr doch schon heute aufgebaut.

Funktioniert allerdings nicht wie erwartet, wie ist in der Beschreibung folgendes zu verstehen ?

Ein DCF-Empfänger (z.B. CONRAD 64113 muss an Pind.6 angeschlossen werden (Ausgang: "activ low" oder invertiert)

"aktiv low" ist klar,
aber oder invertiert heisst oder high, also Pegel egal, der Dekoder stellt sich drauf ein.

Naja egal, ich habe "aktiv low" angeschlossen und an PD5 blinkt es,
allerdigs setzt es mal nach 7, mal nach 8, mal nach 15 Sekunden aus,
dann fehlt ein Blinkimpuls.

1. Der komplette DCF-Status wurde auf PortB gespiegelt, so dass du dort 8 LEDs anschließen kannst.

Bit 0: 15. Impuls erreicht
Bit 1: Minutenparität OK
Bit 2: Stundenparität OK
Bit 3: Parität OK
Bit 4: 58 Impulse empfangen
Bit 5: Uhrzeit nach DCF gestellt
Bit 6: Datum nach DCF gestellt
Bit 7: DCF-Decoder EIN

LEDs bitte gegen Masse anschließen.

Bit 0 = 15. Impuls erreicht ist unwichtig, wenn überhaupt, dann 20. Impuls,
Bit 1: Minutenparität OK ist unwichtig, will ja genaue Zeit und Datum,
Bit 2: Stundenparität OK ebenfalls unwichtig, " " "
Bit 3: Parität OK ist unwichtig,
Bit 4: 58 Impulse empfangen ist unwichtig,
Bit 5: Uhrzeit nach DCF gestellt ist unwichtig,
Bit 6: Datum nach DCF gestellt ist unwichtig,
Bit 7: DCF-Decoder EIN na ja, sollte wohl immer ein sein.

Würdest du mir sagen, ob das so funktioniert?

Ich habe die LED's an Port D gegen Gnd angeschaltet und sofort nach dem einschalten sind
Bit 5: Uhrzeit nach DCF gestellt *** LED ist an ***
Bit 6: Datum nach DCF gestellt *** LED ist an ***
* * * * * * * * * das ist falsch * * * * * * * * *
Hinzu kommt das ungleichmäßige blinken der LED an PD5

Noch zu meinen obigen "ist unwichtig",
für die Auswertung -also innerhalb des Dekoders- sind Parität usw. schon wichtig.
Aber eine gültige Uhrzeit, was soll ich damit anfangen wenn z.B. das Datum ungültig ist?
Dran glauben oder nicht ?, ich würde es nicht glauben und ist somit eine unnütze Information.
Das Gleiche gilt für "gültiges Datum".

Also wirklich wichtig ist nur eine klare Aussage wie
das komplette gerade empfangene Zeittelegramm ist gültig
und passt zu der in der vorherigen Minute empfangenen Information (Plausibilität).
D.h. aber auch, eine gültige Datum/Zeit Information ist frühestens nach 2 Minuten verfügbar.

Leider ist ohne Quelltext Glauben angesagt und evtl. Fehler können nur an einer Stelle (von ein Mann) beseitigt werden.
Da werde ich mich wohl selbst ans Werk machen müssen um meine Wünsche umzusetzen.

Danke für die Mühe, Carlo

[Dirk]

@albundy:

Warum machst du so ein Geheimnis darum ?
Oder ist der Quellcode eventuell gar nicht von dir ???

Mußte diese Unterstellung hier sein? [-(
Habe ich das bei deinem Decoder auch so gesagt???
So ein Kommentar verleidet einem schon den Spaß an der Sache. Schade! Naja ...

@Carlo:
Danke für den Test, wobei ich den sehr kritischen Tenor nicht so ganz nachvollziehen kann.

... an PD5 blinkt es,
allerdigs setzt es mal nach 7, mal nach 8, mal nach 15 Sekunden aus,
dann fehlt ein Blinkimpuls.

Ich habe an PD5 den Decoder-Takt ausgegeben. Das ist nicht der regelmäßige Sekundentakt der Softuhr. Allein schon durch den Minutenimpuls am Ende des Telegramms entsteht eine "Pause". Das ist keine Fehlfunktion. Du wolltest ja auch den Decoder-Takt und nicht einen Sekundentakt, um einen Hinweis auf Empfang zu haben. "Aussetzer" nach 8 oder 15 Sekunden habe ich nicht bemerkt, wenn der Decoder synchronisiert ist. Ist er noch nicht synchronisiert, versucht er natürlich erst, sich nach dem Minutenimpuls zu synchronisieren.

Deine Anmerkungen zu den Bits des DCF-Status kann ich gar nicht teilen. Sie sind alle wichtig. Du must sie aber natürlich nicht nutzen.

Ich habe die LED's an Port D gegen Gnd angeschaltet und sofort nach dem einschalten sind
Bit 5: Uhrzeit nach DCF gestellt *** LED ist an ***
Bit 6: Datum nach DCF gestellt *** LED ist an ***
* * * * * * * * * das ist falsch * * * * * * * * *

Meinst du hier Port B ?? An Port D gibt es nur PD5 zum Beschalten.
Die Bits 5/6 von PortB sind bei mir beim Booten immer low. ABER: Wenn dein Master irgendwas senden sollte, kann er diese Bits auch auf high setzen.

Aber eine gültige Uhrzeit, was soll ich damit anfangen wenn z.B. das Datum ungültig ist?
Dran glauben oder nicht ?, ich würde es nicht glauben und ist somit eine unnütze Information.
Das Gleiche gilt für "gültiges Datum".

Hast du den Sinn dieser Bits verstanden?
Die Bits 5/6 stehen eigentlich dir zur Verfügung. Im Decoder werden beide 1, wenn ein Telegramm gültig ist und bleiben beide 1.
Du selbst kannst sie dann löschen, wenn du die Zeit als inaktuell ansiehst (z.B. jede halbe Stunde).
Die Bits haben also gar nichts mit "glauben" zu tun. Du kannst aus ihnen auch keine Schlüsse auf die TATSÄCHLICHE Gültigkeit der gelesenen Zeit ableiten, weil du ja als Nutzer für sie verantwortlich bist.
Diese Bits dienen im "Automatik-Modus" dazu, die Decodierung einmalig zu starten und dann den Decoder wieder auszuschalten.

Also wirklich wichtig ist nur eine klare Aussage wie
das komplette gerade empfangene Zeittelegramm ist gültig
und passt zu der in der vorherigen Minute empfangenen Information (Plausibilität).

Gültig: Bits 3/4 zeigen für 15 Sekunden an, dass ein gültiges Telegramm empfangen wurde.
Plausibilität: Das Telegramm wird nicht mit dem letzten Telegramm verglichen. Das muss ein solcher Decoder in 2kB auch nicht leisten. Du kannst das im Master aber leicht implementieren.

Da werde ich mich wohl selbst ans Werk machen müssen um meine Wünsche umzusetzen.

Klar. Viel Erfolg.

Noch eine allgemeine Anmerkung:
Wenn hier jemand fertige Projekte veröffentlicht, würde ich persönlich damit glimpflicher und auch etwas sorgfältiger umgehen. Von dir, Carlo, würde ich dann demnächst deine Version hier gern kennenlernen und testen!

Gruß Dirk

[Carlo]

Hallo Dirk,
irgendwie haben wir wohl unterschiedliche Vorstellungen von einem DCF Slave.

Danke für den Test, wobei ich den sehr kritischen Tenor nicht so ganz nachvollziehen kann.

Ich weiss ja nicht was damit gemeint ist, aber meine einfache Vorstellung einer funktionierenden DCF-Software ist eine komplett schlüssige und plausible Datum-Zeit-Information mit der besagten LED am Slave.

Ich habe an PD5 den Decoder-Takt ausgegeben. Das ist nicht der regelmäßige Sekundentakt der Softuhr. Allein schon durch den Minutenimpuls am Ende des Telegramms entsteht eine "Pause". Das ist keine Fehlfunktion. Du wolltest ja auch den Decoder-Takt und nicht einen Sekundentakt, um einen Hinweis auf Empfang zu haben. "Aussetzer" nach 8 oder 15 Sekunden habe ich nicht bemerkt, wenn der Decoder synchronisiert ist. Ist er noch nicht synchronisiert, versucht er natürlich erst, sich nach dem Minutenimpuls zu synchronisieren.

Ich habe den Dekoder im Freien an einem Akku betrieben. Die Antenne ist korrekt ausgerichtet nach Mainflingen.
Nach deiner Beschreibung hat es also der Dekoder nicht geschafft den Neubeginn des Zeittelegramms (fehlende Sekunde) zu erkennen oder die Synchronisation verloren.

Deine Anmerkungen zu den Bits des DCF-Status kann ich gar nicht teilen. Sie sind alle wichtig. Du must sie aber natürlich nicht nutzen.

Sagte ich doch, für die Dekodierung sicherlich, für Übermittlung zum Master nicht wirklich (denn der soll sich auf die korrekte Auswertung ja verlassen).
Was soll ich mit der der Information 15. Sekunde ?
Hilfsantenne dran oder nicht, ich will zentrale Uhrzeit und wissen ob innerhalb der letzten 24h synchronisiert wurde.
Parität ok, aber falsche Zeit/Datum (weil nicht plausibel) was soll ich damit ?

Ich habe die LED's an Port D gegen Gnd angeschaltet....
Meinst du hier Port B ?? An Port D gibt es nur PD5 zum Beschalten.
Die Bits 5/6 von PortB sind bei mir beim Booten immer low. ABER: Wenn dein Master irgendwas senden sollte, kann er diese Bits auch auf high setzen.

Tippfehler meinerseits, meinte natürlich Port B.
Mein Master sendet garnichts, da nicht angeschlossen.

Aber eine gültige Uhrzeit, was soll ich damit anfangen wenn z.B. das Datum ungültig ist?
Dran glauben oder nicht ?, ich würde es nicht glauben und ist somit eine unnütze Information.
Das Gleiche gilt für "gültiges Datum".

Hast du den Sinn dieser Bits verstanden?
Die Bits 5/6 stehen eigentlich dir zur Verfügung. Im Decoder werden beide 1, wenn ein Telegramm gültig ist und bleiben beide 1.
Du selbst kannst sie dann löschen, wenn du die Zeit als inaktuell ansiehst (z.B. jede halbe Stunde).
Die Bits haben also gar nichts mit "glauben" zu tun. Du kannst aus ihnen auch keine Schlüsse auf die TATSÄCHLICHE Gültigkeit der gelesenen Zeit ableiten, weil du ja als Nutzer für sie verantwortlich bist.
Diese Bits dienen im "Automatik-Modus" dazu, die Decodierung einmalig zu starten und dann den Decoder wieder auszuschalten.

OK, spätestens hier gehen unsere Vorstellungen total auseinander.
Wenn ich (Master) für die Gültigkeit (der Slavedaten) verantwortlich bin, wofür brauche ich dann den Slave ?
Wenn eine Software nicht offengelegt wird, habe ich dafür Verständnis.
Um besser abklären zu können ob die Software "brauchbar ist", fehlen dann doch einige wichtige Hinweise (einige sind jetzt klar geworden).
Z.B. wie wird der Sekundentakt in der Software ausgewertet ?
Nur durch die fallende Flanke ? das wäre schlecht.
Pulsbreite der Trägerabsenkung messen ? Schon besser. Mit welchen Toleranzen dann ?

Von dir, Carlo, würde ich dann demnächst deine Version hier gern kennenlernen und testen!
Gruß Dirk

Um das Ganze hier für mich abzuschließen:
Meine Vorstellung vom Slave ist,
1. Morgens so ca. 2:00 wird Datum/Uhrzeit für ungültig (als nicht synchronisiert) erklärt, die Sekunden-LED blinkt rot.
2. Wird nun ein gültiges Zeittelegramm empfangen (das zur vorherigen Minute passt), blinkt die Sekunden-LED grün.

Mögliche Abfragen vom Master wären:
Datum, Uhrzeit, synchronisiert ja/nein
Ggf. Statusbits für Sommer/Winterzeit (Ankündigung der Umschaltung)
Wieviele Tage unsynchronisiert ... bei Bedarf weitere ...

Dafür langt aber auch ein 8-pol ATtiny15 oder ähnliches.

------------
Die Zukunft wäre den "Slave" als zentralen Zeitserver per Funk oder im Stromnetz (PowerLine) ggf. X10 zu betreiben (dann ohne IIC).

Es grüßt Carlo

[Dirk]

Hallo Carlo,

ok, ich verstehe teilweise, was du haben willst. Du must natürlich deine Vorstellungen dann umsetzen. Gut wäre, wenn du das hier im Forum tun würdest.

Ich möchte aber an dieser Stelle nicht, dass hier der Eindruck im Raum stehen bleibt, dass dieses Projekt untauglich ist und "so irgendwie" von mir umgesetzt wurde.
Der Slave funktioniert wunderbar und auch nach langen Tests fehlerfrei. Bei dauerhaft eingeschaltetem Decoder (Bit 7 = 1) gelingt es problemlos, in jeder Minute ein Telegramm zu decodieren. Der Decoder ist auch recht störungsunempfindlich. Es ist bei mir noch nie vorgekommen, dass ein fehlerhaftes Telegramm übernommen wurde. Auch die Testversion mit LED-Ansteuerung sieht gut aus.

Das Projekt diente eigentlich nicht dazu, etwas zu beweisen bezüglich der DCF-Decodierung (die ist mehrfach in diesem Forum, z.B. von albundy, schon gut gelöst worden! Nb. ist hier nicht der Decoder von albundy zur Anwendung gekommen,- er war zu gross für das Projekt.), sondern dazu zu zeigen, was mit einem "kleinen" I2C-Sklaven so alles möglich ist,- und da ist eine Menge möglich.

Wenn man sich bei einem solchen Projekt Gedanken über die Umsetzung macht, fragt man sich, was der Slave alles können soll. Klar war, er sollte das DCF-Telegramm vollständig ab Bit 15 decodieren können mit vollständiger Paritätsprüfung. Das "Ergebnis" sollte ständig via I2C zu lesen sein. Da der Slave nicht wissen kann, WANN das Lesen erfolgt, muss er auch über eine "Softclock" verfügen, die die DCF-Zeitinformationen fortschreibt. Nur so macht ein DCF-Decoder mit Busabfrage Sinn.

Der Decoder sollte auch vom Master "abschaltbar" (Bit 7 Status) sein. Dann wird via I2C nur die Info der Softclock gelesen. Macht Sinn, weil man ja eine Aktualisierung der Softuhr evtl. nur zu bestimmten Zeiten will. Die Softclock sollte auch zu stellen sein (im Ausland z.B. kein DCF-Empfang!).

Dann sollte es auch eine "Automatik" geben. Diese wurde in 2 Modi umgesetzt:
1. Automatisches Einschalten des DCF-Decoders 1x pro Stunde, nach erfolgreichem Empfang wieder Ausschalten.
2. Automatisches Einschalten des DCF-Decoders, wenn die Daten der Softuhr nicht mehr aktuell sind. Somit Aktualisieren der Softuhr via DCF, dann Abschalten des Decoders. An dieser Stelle entstand die Frage, unter welchen Bedingungen die Daten der Softuhr eigentlich inaktuell werden.

Umgesetzt ist das von mir so:
Es gibt 2 Flags (Bits 5/6 des Status), die IMMER 1 werden, wenn ein gültiges DCF-Telegramm empfangen wurde und die Softuhr danach gestellt wurde.
Die Softuhr setzt Bit 5 (Softuhr-Zeit inaktuell) Ende Juni und am Jahresende auf 0, da hier Schaltsekunden eingefügt werden könnten.
Die Softuhr setzt Bit 6 (Softuhr-Datum inaktuell) Ende Februar auf 0, da es hier einen 29.2. (Schaltjahr) geben könnte.

Das heisst: IN DER REGEL BLEIBEN DIESE FLAGS NACH EINEM EINZIGEN/ERSTEN DCF-EMPFANG DAUERHAFT AUF 1.
Der angeschlossene Master kann diese Flags nun auch via I2C löschen. Warum das?
Wenn der Slave im Automatik-Modus 2 (siehe oben) betrieben wird, wird sich der Decoder nur unter folgenden Bedingungen einschalten:
1. Ende Februar
2. Ende Juni
3. Am Jahresende
4. Wenn der Master eines der Flags 5/6 gelöscht hat
Daraufhin erfolgt EINMALIG eine Telegramm-Decodierung und Softclock-Aktualisierung (Bits 5/6 werden 1 !!), dann geht der Decoder wieder ausser Betrieb.
Die Bits 5/6 haben also mit dem DCF-Decoder primär nichts zu tun, sondern mit der Softclock. Der Decoder löscht keines dieser Flags.
Wenn der Master also z.B. um 2.00 Uhr den DCF-Empfang will, dann löscht er im Automatikmodus 2 um 2.00 Uhr Bits 5/6 des Status und wartet. Wenn Bits 5/6 wieder 1 sind, kann er die neue DCF-Zeit lesen.
Alternative: Keine Automatik. Der Master schaltet den Decoder im Slave um 2.00 Uhr ein und nach erfolgreichem Empfang (Bits 3/4 für 15 Sekunden = 1 UND Bits 5/6 dauerhaft = 1) wieder aus.

Wie kann der Master erkennen, WAS ER DA VIA I2C LIEST? D.h. wie zuverlässig kann der Master erkennen, ob er die Softuhr, die aktuelle DCF-Zeit (wie aktuell?) oder Müll liest?

Durch das Statusregister:
Bits 0..2 -> Ist eines dieser Flags 1, findet gerade ein Decodiervorgang statt. Der Master kann entscheiden, ob er jetzt schon lesen möchte, oder auf das fertige/gültige Telegramm warten möchte. Wartet er nicht, liest er die Softuhr, die auf der Basis des zuletzt empfangenen DCF-Telegramms weiterläuft.
Wann war das? Eine Antwort kennt der Decoder nicht. Wenn Bits 5/6 gleich 1 sind, wurde auf jeden Fall EINMAL in der Vergangenheit ein DCF-Telegramm empfangen. Da der Master diese Bits auch löschen kann, kann er den Zeitraum seit dem letzten DCF-Empfang aber eingrenzen: Wenn sie vor 2 Stunden gelöscht wurden und jetzt 1 sind, dann fand der Empfang in diesen 2 Stunden statt.

Bits 3/4 -> Sind beide Flags 1, wurde innerhalb der letzten 15 Sekunden ein gültiges Telegramm decodiert und kann via I2C gelesen werden. Jetzt bleiben auch die Bits 5/6 high, bis eine der 4 Bedingungen (s.o.) eintritt. An dieser Stelle ist klar: Die Zeit ist sehr aktuell! Es gibt nur die Toleranz des Decoders beim Stellen der Softuhr und der Softuhr selbst (in den max. 15 Sekunden).

Ist keins der Bits 0..4 gleich 1, findet gar keine Decodierung statt. Der Master könnte dann z.B. Bit 7 lesen. Ist es Null, ist der Decoder gar nicht in Betrieb, dann kann ja auch nichts passieren. Was man dann via I2C liest, ist die reine Softuhr.
Diese wird so lange als aktuell angesehen, bis eine der Bedingungen 1..3 (s.o.) in der Softuhr eintritt. Ab diesem Moment sind nicht mehr beide Bits 5/6 gleich 1. Damit betrachtet sich die Softuhr jetzt als inaktuell.
Der Master entscheidet, was er machen möchte (z.B. Decoder einschalten!) oder er hat schon den Automatik-Modus 2 (s.o.) des Slave gewählt, dann wird vom Slave sofort wieder die DCF-Zeit geholt und kann danach gelesen werden.


Soviel zum Schluß hier noch zur Funktionsbeschreibung. Ist für mich alles sehr ausgereift und sicher.

Noch ein Wort zur "Plausibilitätsprüfung", d.h. Vergleich des gültigen Telegramms mit dem aktuellen Stand der Softuhr. Ich würde das nicht machen. Wenn ein Telegramm nach allen Prüfungen (3x Parität, 58 Impulse, Bit 20 = 1) ok ist, würde ich es AUF JEDEN FALL übernehmen, egal, was die Softuhr sagt. So ist es hier auch umgesetzt.


Soviel von mir noch etwas ausführlicher.

Ich werde dieses Projekt nur noch für mich weiterführen. Für meine Belange stellt es eine sehr komfortable Lösung dieser Aufgabe dar.


Gruß Dirk

[albundy]

Hallo Dirk,

Nb. ist hier nicht der Decoder von albundy zur Anwendung gekommen,- er war zu gross für das Projekt.)

dann doch aber nur, weil du die Lib mit unwichtigen Details (SZ , WZ , unwichtigen Statusbits u.s.w.) unnötig aufgebläht hast, was aber keinen interessiert.
Dabei hast du aber andere, wichtige Dinge, die ich damals auch noch nicht berücksichtigt habe, ausser Acht gelassen.

Noch ein Wort zur "Plausibilitätsprüfung", d.h. Vergleich des gültigen Telegramms mit dem aktuellen Stand der Softuhr. Ich würde das nicht machen. Wenn ein Telegramm nach allen Prüfungen (3x Parität, 58 Impulse, Bit 20 = 1) ok ist, würde ich es AUF JEDEN FALL übernehmen, egal, was die Softuhr sagt. So ist es hier auch umgesetzt.

und genau da, bist du total im Irrtum.
Ich kann dir mehrere Protokolle zeigen, wo die Parität jedesmal OK ist, aber die Zeitinformation total unsinnig.

Ich werde dieses Projekt nur noch für mich weiterführen.

das wird das beste sein, denn ich denke, dass dein Projekt nicht in ein Forum gehört, wo Informationen und Wissen ausgetauscht werden.
Wer hat schon etwas von einem fertig kompiliertem Hex File, was keinerlei eigene Kreativität oder Anpassungen an eigene Bedürfnisse mehr zulässt ?

[Dirk]

Hallo albundy,

Dabei hast du aber andere, wichtige Dinge, die ich damals auch noch nicht berücksichtigt habe, ausser Acht gelassen.

Das interessiert mich! Könntest du berichten, welche neuen Features du in deinen DCF-Decoder eingebaut hast? In einem Forum, in dem es um Wissen und Informationen geht, solltest du darüber schreiben.

... ich denke, dass dein Projekt nicht in ein Forum gehört, wo Informationen und Wissen ausgetauscht werden.

Das ist wirklich eine Frechheit! Eigentlich wäre eine Forum-Strafe für dich da angemessen!

Gruß Dirk

[Dirk]

Jetzt ist es noch einmal Zeit für ein größeres Update:

Das ist neu:
- Schaltsekunden-Unterstützung
- Bit 20 Prüfung
- Plausibilitätsprüfung
- Zähler für gültige Telegramme
- Verbesserter Dekoder-Sekundentakt am Ausgang

Zum Test der Schaltsekunden-Unterstützung wird ein Bascom-Programm mitgeliefert, das auf einem 2. AVR ein DCF-Telegramm mit Schaltsekunde simuliert. Das kann benutzt werden, um den Decoder zu testen.

Viel Spaß!

Gruß Dirk