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