Archiv verlassen und diese Seite im Standarddesign anzeigen : RNBFRA: Ein DCF77-Sklave
... und noch ein neuer Sklave? (Was soll denn das???)
PicNick hat dem 2313-Coprozessor auf der RNBFRA ja schon beigebracht, wie er als I2C-Slave 10 Servos ansteuern kann.
Guckst du da: https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=21164
Danach konnte er auch noch infraroten RC5-Code senden und empfangen (RNIRI2C).
Guckst du dort: https://www.roboternetz.de/phpBB2/viewtopic.php?t=23253
Jetzt gibt's hier noch ein altes Problemchen: Die DCF77-Decodierung.
Sie kostet ja bekanntlich Timer- und weitere Ressourcen auf dem Hauptprozessor.
Wie wäre es, wenn es einen komfortablen DCF77-Decoder-Chip mit I2C-Ausgabe gäbe?
Weiß jemand, ob es tatsächlich einen solchen Chip gibt?
Egal,- auf jeden Fall gibt es ihn ab heute!
An den 2313 auf der RNBFRA muss ein DCF-Empfänger (z.B. CONRAD 641138) an Pind.6 = "Servo 10" angeschlossen werden.
In den Coprozessor AT90S2313 oder ATtiny2313 gehört das Prog "RNDCF77I2C.BIN". Es ist nicht nur in einem 2313 auf der RNBFRA lauffähig, sondern kann auch auf anderen Platinen arbeiten, auf denen SDA = Portd.2 und SCL = Portd.3 ist.
Der M32 arbeitet dann das Demoprog "RNDCF77I2CTest.bas" ab.
Als Demo liest der Master (M32) zweimal pro Sekunde den kompletten Puffer des Slave aus. Das sind insgesamt 9 Bytes: Decoder-Status, Sekunde, Minute, Stunde, Tag, Wochentag, Monat, Jahr und DCF-Flags.
Die Daten werden dann über ein 16*4-LCD oder über die serielle Schnittstelle ausgegeben.
Der Inhalt des Decoder-Status und der DCF-Flags, sowie die weiteren Funktionen werden in der Anleitung (RNDCF77I2C.doc) erklärt.
Zusätzlich läßt der Master in der Demo noch über den Energieport der RNBFRA 1.22 (PCF3) drei LEDs blinken.
Viel Spaß!
Gruß Dirk
[rndcf77i2c.zip gelöscht! Neue Version im Beitrag vom 22.10.06!]
Wir müssen (Wenn's dir recht ist) diese Projekt in der Wiki dokumentieren, denk ich, im Prinzip unabhängig von der Netzwerkgeschichte.
"Praxis : xxxx2313" oder so.
Sonst trocknet uns der Thread ein, und dann find' wieder keiner nix.
Es ist offenbar tasächlich wurst, ob Tiny2313 oder AT90S2313 ?
Das mit der Wiki wäre sicher gut. Ich trage da gern einen Teil bei! Austrocknen soll da ja nix. [-X
tiny oder 90S2313 scheint wohl egal, klappt bei mir (zumindest mit diesem Prog) auf beiden.
Allgemein fällt mir noch ein, dass ich es eigentlich schade finde, dass die neueren RN-Boards keinen CoP mehr haben. Er könnte nützlich sein!
... oder wie wär's mit einem kleinen RN-Board mit dem 2313? Braucht nur einen Pfostenstecker für die Ports und einen I2C-Stecker.
Vielleicht liest ja Frank mit!?
Gruß Dirk
Naja, es ist grundsätzlich klar: wenn die Anbindung (I2C) klappt, kann man leicht kleine Zusatz-Boards mit kleinen µC'S für diverse Nebenrollen
einsetzen. Das ist ein weites Feld, fast nicht auszudenken.
SO gesehen wär ein kleines Basis-board für den Tiny nicht schlecht.
Mit einem Bootloader für I2C ? Schlecht ?
Andererseits bau ich mit einer lochrasterplatine und ein paar Drähten ein 2313-er Board in einer 1/4 Stunde zusammen. Ist fast ein Grenzfall.
Dirk, jetzt war ich ganz frech und hab' mal die Zip-File in meine HP zum Downloaden reingestellt.
http://www.oldformation.at/electronic/download/down.htm
Zwei Bitten:
1 Probier mal, ob des klapt
2 nachträgliches Einverständnis
Das Downloaden klappt!!
jon
Hallo PicNick,
ad 1: klappt!
ad 2: yes
Gruß Dirk
So, jetzt ist noch ein kleinerer Bug in der Softuhr aufgefallen und beseitigt.
Außerdem habe ich jetzt das Prog noch etwas ausführlicher mit dem ATtiny2313 getestet (vorher hauptsächlich mit dem AT90S2313).
Gruß Dirk
Also hier die Version 1.12:
[rndcf77i2c.zip gelöscht! Neue Version im Beitrag vom 16.12.06!]
GUt, Dirk, ist stell' das dann auch gleich zum Download auf die HP
Hallo Dirk,
ist eine Status-LED machbar / sinnvoll ?
Soll anzeigen ob die Software-Uhr DCF synchronisiert ist.
Könnte ja im Sekundenrythmus blinken (zum ausrichten),
rot = nicht synchronisiert,
grün = synchronisiert.
MfG Carlo
Ich habe einen DCF-Empfänger von AATiS, der hat 2 Status-LEDs, eine grüne für logisch 1 und eine Rote für Logisch 0, die dann im Sekundentakt entsprechend blinkt, sowas fänd ich vielleicht ganz praktisch (auch als DUO-LED)
Nee, das meine ich nicht,
könnte man ja selbst machen per Inverter.
Ich möchte nicht wissen was aus den "Conrad" Modul rauskommt,
sondern was der Dekoder sieht.
Speziell interessiert aber, synchronisiert oder nicht.
Das mit dem Sekundenblinken ist Zugabe.
Carlo
@Carlo,
Speziell interessiert aber, synchronisiert oder nicht.
Das ganze DCF77-Telegramm wird ja jede Minute für die Folgeminute gesendet. Selbst wenn man mit einer LED die ankommenden Impulse sichtbar macht, bedeutet das NICHT, dass in dieser Minute ein gültiges (= synchrones) Telegramm empfangen wird.
"Synchronisiert" kann also beim Decoder nur bedeuten, dass ab der 15. Sekunde jeder Minute nacheinander die Bits 0..2 im DCF-Status gesetzt werden und dann ab der 58. Sekunde die Bits 3..4 gesetzt werden. Diese Bits bleiben dann wieder bis zur 15. Sekunde der neuen Minute gesetzt. Nur wenn dieser Ablauf immer wieder stattfindet, ist der Decoder "synchronisiert".
Wenn man das so betrachtet, stellt sich die Frage, ab welchem Zeitpunkt man dann die Synchron-LED ein- oder ausschalten würde, da das Ganze ja ein zyklischer Prozess ist.
Man kann es sich aber auch einfacher machen: Sobald Bit 0 ODER Bits 3/4 im DCF-Status gesetzt sind, ist synchroner Empfang sehr wahrscheinlich.
Aus dieser Logik könnte der Master evtl. eine Anzeige "synchron/nicht synchron" machen!?
Gruß Dirk
Hallo Dirk,
ist wohl nicht so einfach ?
Ich möchte nicht am Master sondern am Slave sehen,
ob die Softwareuhr DCF-synchronisiert ist.
Da der Quelltext wohl nicht verfügbar ist (habe nichts gefunden)
wäre meine Vorstellung so:
In den frühen Morgenstunden (weil störungsärmer)
so ca. 2 - 4 Uhr wird bei korrekt empfangener DCF-Zeit die Softwareuhr
synchronisiert und nach meinem Wunsch dies per LED am Slave angezeigt.
Die Softwareuhr läuft für 24h genau genug auch ohne erneute Sync.
Sollte der Quelltext verfügbar sein, könnte ich es selbst nachrüsten.
Carlo
Hallo Carlo,
ist wohl nicht so einfach ?
Doch, doch! Aber die 2 kB des 2313 sind voll. Werde trotzdem 'mal sehen, was sich machen läßt. O:)
In den frühen Morgenstunden (weil störungsärmer)
so ca. 2 - 4 Uhr wird bei korrekt empfangener DCF-Zeit die Softwareuhr
synchronisiert und nach meinem Wunsch dies per LED am Slave angezeigt.
Das ist durch den steuernden Master ohne Probleme zu erreichen:
Er liest ab und zu die Zeit (Softuhr) vom Slave, schaltet um 2.00 Uhr den Decoder des Slave ein und löscht Bits 5/6 des DCF-Status. Der Slave setzt dann Bits 5 und 6 im DCF-Status wieder auf high, sobald ein gültiges Telegramm empfangen wurde. Diese Bits bleiben den ganzen Tag lang high, so dass man immer nachvollziehen kann, dass da ein Stellen der Softuhr nach DCF erfolgt ist.
Aber ich habe kapiert, dass du eine LED-Anzeige vorziehst. Könntest Du mir noch sagen, bei welcher Bedingung sie sich einschalten soll?
Es gibt da einige Möglichkeiten fürs Einschalten dieser LED:
1. Ein gültiges DCF-Telegramm wurde empfangen und die Softuhr danach gestellt (das sind Bits 5/6 des DCF-Status).
2. Es liegt überhaupt ein DCF-Signal an (evtl. ein gepulster Ausgang).
3. Der DCF-Decoder ist mit der DCF-Aussendung synchronisiert und aktualisiert also jede Minute die Softuhr (macht nur Sinn bei dauerhafter Decodierung).
Wie gesagt: Ich schau 'mal, was geht!
Gruß Dirk
Hallo Dirk,
Aber ich habe kapiert, dass du eine LED-Anzeige vorziehst.
Ja, will am Slave sehen was Sache ist (unabhängig vom Master).
Es gibt da einige Möglichkeiten fürs Einschalten dieser LED:
1. Ein gültiges DCF-Telegramm wurde empfangen und die Softuhr danach gestellt (das sind Bits 5/6 des DCF-Status).
Ja, genau so.
Allerdings gültig innerhalb der letzten 24h empfangen.
2. Es liegt überhaupt ein DCF-Signal an (evtl. ein gepulster Ausgang).
Auch richtig und wichtig für die Ausrichtung der Antenne.
3. Der DCF-Decoder ist mit der DCF-Aussendung synchronisiert und aktualisiert also jede Minute die Softuhr (macht nur Sinn bei dauerhafter Decodierung).
Nein, siehe bei 1.
Das alles mit einer rot/grün LED 2-polig zwischen zwei Portpin's,
rot blinkend = gepulster Ausgang, siehe Punkt 2.
grün blinkend = gepulster Ausgang und synchronisiert.
Die Antwort ob der Quellcode erhältlich ist fehlt noch.
Gruß Carlo
Hallo Carlo,
anbei eine Testversion für dich.
Ich hatte leider keine Zeit, sie selbst zu testen.
Zusätzliche Funktionen:
1. Der komplette DCF-Status wurde auf PortB gespiegelt, so dass du dort 8 LEDs anschließen kannst. Ist das nicht eine Lightshow! O:)
2. Der Decoder-Takt wurde auf PortD.5 gespiegelt.
LEDs bitte gegen Masse anschließen.
Würdest du mir sagen, ob das so funktioniert?
Die Antwort ob der Quellcode erhältlich ist fehlt noch.
Nein, ist nicht erhältlich.
Gruß Dirk
[rndcf77i2c_led.zip gelöscht! Neue Version im Beitrag vom 16.12.06!]
Hallo Dirk,
Die Antwort ob der Quellcode erhältlich ist fehlt noch.
das hätte mich auch interessiert.
Nein, ist nicht erhältlich.
das ist aber schade...
Wobei mich deine Version doch sehr interessieren würde.
Warum machst du so ein Geheimnis darum ?
Oder ist der Quellcode eventuell gar nicht von dir ???
Hallo Dirk,
danke für die schnelle Umsetzung.
Kann ich leider erst Montag testen, melde mich dann.
Das der Quellcode nicht frei ist, schade aber verständlich.
Grüße, 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 641138) 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
@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
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
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
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 ?
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
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
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.