DCF77-Decoder mit RoboPro und TXC

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 10 Jul 2012, 21:15

Aber vielleicht hast Du noch ein paar Tipps dazu... (kann man das Modul in eine ft-Maße-Kiste hineinbauen? wie sollte die Ferrit-Antenne ausgerichtet werden? kann man die Antenne ggf. mit Hausmitteln verstärken? welche Empfänger kommen alternativ zum Conrad-Modul in Frage?... Fragen über Fragen...).
Ok, was kann man dazu sagen?

Man kann das Modul in alles aus Kunststoff einbauen, also auch in eine Kassette (32076) mit Deckel.
Das Modul mit Antenne passt auch gerade so in ein Batteriegehäuse (32263) mit transparentem Deckel (32264). Das wäre dann sehr kompakt und anschaulich.
Als Befestigung kann der tolle Heisskleber dienen. Das 3-polige Kabel sollte ca. 25 cm lang sein.

Die Ferritantenne muss immer horizontal und mit ihrer Querseite zum Sender befestigt werden.

Eine Empfangsverstärkung ist nicht möglich. Es gibt aber aktive DCF-Antennen zum Einbau an ungünstigen Stellen (auch bei C: 641146!). Was aber immer möglich ist, ist eine Empfangsverbesserung durch einen höheren Standort, eine passende Ausrichtung des Ferrit-Stabs, einen mögl. großen Abstand zu Störquellen (PC, Mikrocontroller (ft: TXC), Router, Bildschirm, TV, Mobiltelefon, (ft-)Motoren, Leuchtstoffröhren ...).
Natürlich kann die Software auch ganz wesentlich zur Zuverlässigkeit des Empfangs beitragen, indem ungültige Telegramme sicher aussortiert werden.

Es gibt preisgünstige DCF-Module auch bei Reichelt und Pollin. Probleme: Sie arbeiten nicht an 9V und sind wesentlich "empfindlicher" als das Conrad-Modul. Eins der Module braucht einen Treibertransistor am Ausgang, auch wird eine Flanke an einem Eingang zum Start des Empfangs benötigt. Also: Ich empfehle für unsere Zwecke ausschließlich das Conrad-Modul. Es ist solide, arbeitet in einem weiten Spannungsbereich und hat kräftige Ausgangstransistoren (BC547) mit offenem Kollektor.
Gruß ftDirk

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1831
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 02 Aug 2012, 22:26

Hallo zusammen,

"wir haben fertig"! ftDirk und ich haben einen hübschen ft:pedia-Beitrag zu unserer ft-Funkuhr erstellt - und auf der Convention werdet Ihr sie auch zu sehen bekommen. Die RoboPro-Implementierung(en) sind in Kürze im Download-Bereich verfügbar. Bei Gelegenheit werden wir auch noch ein paar hübsche Fotos in der ft:c hochladen.

Atomuhrgenaue Normalzeit ist mit dem TX jetzt also für rund 10 Euro zu haben. Ich bin gespannt, in welchen tollen Anwendungen der DCF77-Empfänger zukünftig noch zum Einsatz kommt...

Beste Grüße,
Dirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 11 Aug 2012, 09:49

Hallo Leute,

wie Dirk Fox schon zum Thema ft-Funkuhr schrieb: "Wir haben fertig!"

Jetzt ist auch mein DCF77-Decoder V4 downloadbar: http://www.ftcommunity.de/data/download ... oder_4.zip
Damit haben wir jetzt sogar 2 DCF-Decoder für ft zur Verfügung. Besser geht's nimmer! Ich habe fertig.

Viel Spaß damit!

Eine genauere Beschreibung bzw. Anleitung werde ich hier noch posten ... wenn ich dazu komme ... :roll:
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 12 Aug 2012, 11:25

DCF77-Decoder V4 - Anleitung:
==========================
Wenn ihr mal ins Hauptprogramm schaut, gibt es dort 3 Threads (Software-Uhr, Uhr nach DCF stellen und DCF77-Decoder).

Wenn ihr den DCF-Decoder in eigenen Programmen nutzen wollt, muss darin der Thread DCF77-Decoder genau so vorkommen, also nur das Start-Symbol und das Unterprogramm DCF77Decoder (V0.97). Die Anzeigen von DCF-Bitnummern, DCF-Bit und DCF-Fehler könnt ihr weglassen.

In euren Programmen braucht ihr auch den mittleren Thread "Uhr nach DCF stellen". Dieser Thread beinhaltet die Regel, nach der die DCF-Zeit in die Uhr-Variablen (Sekunde, Minute, Stunde, WTag, Tag, Monat, Jahr) übertragen wird. Dazu muss man wissen, dass das Unterprogramm DCF77Decoder ständig läuft und versucht, das DCF77-Telegramm jede Minute zu decodieren. Meist soll die DCF-Zeit aber nicht jede Minute in die eigene Uhr übernommen werden, sondern z.B. nur einmal pro Stunde oder pro Tag. Diese Regel muss man in diesem Thread implementieren. Die Regel in dieser Demo ist simpel: Immer wenn ein gültiges DCF-Telegramm vorliegt (DCF_Ok ist 1), dann wird die Uhr gestellt, anschließend 20s gewartet, damit nicht in dieser Minute ein 2. Mal gestellt wird. DCF_Ok bleibt nämlich nach Empfang eines gültigen Telegramms so lange 1, bis Bit 14 der neuen Minute decodiert wird. Man sollte also mind. 15 Sekunden, nachdem DCF_Ok 1 wird, diese Variable nicht mehr abfragen, weil sie immer noch 1 sein wird.
Natürlich kann man diesen Thread auch ganz anders machen. Alle Anzeigen dieser Demo können natürlich entfallen. Wenn DCF_Ok 1 ist, KANN man die Uhr stellen, muss es aber nicht. Insofern kann man z.B. im Hauptprogramm eine Variable einführen (nennen wir sie DCF_On), durch die (wenn sie 1 wird) die Uhr gestellt wird. Dazu würde man in diesem Thread noch eine A>0 Abfrage vor der DCF_Ok Abfrage einbauen, in der DCF_On abgefragt wird. Damit kann das Stellen der Uhr aus dem Hauptprogramm "ferngesteuert" werden. Natürlich sind auch ganz andere Lösungen für die "Uhr-Stell-Regel" möglich.

Kommen wir zum 1. Thread "Software-Uhr":
Dies ist das eigentliche Hauptprogramm. Das ist hier nur eine Demo, nämlich eine "Softclock". Sie macht aus den Uhr-Variablen eine dauerhaft (naja: Solange das Programm läuft ...) anzeigende Uhr, indem die einzelnen Variablen im 1-Sekunden-Takt hochgezählt werden. Das ist hoffnungslos ungenau und von mir auch gar nicht geeicht. Das ist ja auch nicht nötig: In dieser Demo V4 wird ja ständig nach DCF-Telegramm nachgestellt, so dass die Ungenauigkeit egal ist. Die Softclock berücksichtigt auch keine Schaltjahre und korrekte Monatslängen, ist also sehr unvollkommen. Auch das ist hier egal, weil DCF77 es schon richtet.
Was ihr hier schreibt, bleibt euch überlassen. Ihr braucht ja vielleicht keine dauerhaft laufende Zeitanzeige, sondern nur auf Abruf die DCF-Zeit. Oder irgendeine ft-Konstruktion muss bei einer bestimmten Uhrzeit "zum Leben erwachen"... usw.
Da läßt sich also Vieles programmieren.

Wichtig sind folgende Regeln im Umgang mit diesem DCF77-Decoder:
1. Der eigentliche DCF77Decoder V0.97 braucht nicht verändert zu werden. Er kommuniziert über die Variablen DCF_Ok (1 = gültiges Telegramm vorhanden), DCFMin, DCFStd, DCFWTg, DCFTag, DCFMon, DCFJar (= decodierte DCF-Zeit) mit dem Thread "Uhr nach DCF stellen".
2. Der Thread "Uhr nach DCF stellen" beinhaltet die Regel, nach der die DCF-Zeit in die Uhr-Variablen übernommen wird. Das muss man selbst programmieren, wenn man eigene Regeln dafür haben will (sollte man!). Dieser Thread stellt die Uhr nach DCF-Infos, wenn DCF_Ok 1 ist (Achtung: 15 Sek. danach nicht mehr neu stellen!) und wenn die Regel dies erlaubt (müßt ihr festlegen!).
3. Das Hauptprogramm ist vollständig euer Ding. Wenn ihr eine laufende Uhr mit Daueranzeige braucht, müßt ihr auch eine "Softclock" mit den Uhr-Variablen programmieren,- wenns geht etwas besser als hier gezeigt. Diese "Softclock" könnte auch noch mal ein eigener Thread werden. Hier könnte man anstelle einer Softclock auch eine externe I2C-Echtzeituhr (RTC) einbinden. Zusätzlich müßt ihr dem Thread "Uhr nach DCF stellen" ggf. mitteilen, ob die Uhr gestellt werden soll. Alternativ macht ihr diesen Thread so "intelligent", dass sich das Hauptprogramm darum nicht kümmern muss.
Wenn man keine dauerhaft laufende Softclock braucht, genügt es auch, die DCF-Zeit regelmäßig abzufragen und entsprechend zu reagieren. Viele Möglichkeiten ...

So viel fürs erste als kleine Anleitung für den DCF77-Decoder V4 ...
Fragen :arrow: hier!
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 12 Aug 2012, 17:28

DCF77-Decoder V4 - Beschreibung:
==============================
Bei der Beschreibung beschränke ich mich auf den eigentlichen DCF77-Decoder V0.97 (Unterprogramm DCF77Decoder).
Da mein DCF-Empfänger mit invertierendem Ausgang an I8 angeschlossen ist, wird dieser Eingang (D 10V) anfangs abgefragt. Da der Decoder Pausenlängen (Highpegel = 1 an I8!) misst, summiert er in der Variable ZählerP die Durchläufe der "Messschleife" auf. Die Pause von 0,009s bestimmt die Abfragezeit von I8 (ca. 10ms). Eine schnellere Abfragezeit ist nicht sinnvoll, da intern der Wert von I8 nicht schneller aktualisiert wird. Pausenlängen messen bedeutet in diesem Fall, dass der ZählerP so lange hochgezählt wird, bis wieder ein Signalanfang (Lowpegel = 0 an I8!) bemerkt wird. Dann ist die aktuelle Pause zuende und der letzte Wert von ZählerP wird in die Variable Pause übernommen.
Zwei Dinge sind in diesem Programmteil noch auffällig:
1. Warum wird ein Vergleich A?B bei Signalanfang verwendet? Der Grund: Es wird erst dann davon ausgegangen, dass eine verwertbare Pause vorliegt, wenn sie mehr als 2 Abfragen lang (> 20ms) anliegt. Dies ist ein Schutz vor sog. "Spikes", also kurzen Signalspitzen/-einbrüchen, die Störungen entsprechen. Das ist also ein gewisser Schutz vor Störsignalen.
2. Warum gibt es die Abfrage A>6000 bei der Pausenlänge? Der Grund: Der ZählerP soll nicht überlaufen, wenn gar kein DCF-Empfänger angeschlossen ist oder aus anderem Grund ein permanenter Highpegel an I8 anliegt. Das Programm würde sich dann "aufhängen", was eigentlich gar nicht passieren dürfte (Bug in RoboPro?).
Steht die Pausendauer in "Pause" fest, wird die Dauer bewertet: Ein DCF-Bit wird als 1 (Soll: 800 oder 1800ms) erkannt, wenn die Pausendauer 71..85 (x10ms) oder 171..185 (x10ms) beträgt. Als 0 gilt das das DCF-Bit (Soll: 900 oder 1900ms), wenn die Pausendauer 86..99 (x10ms) oder 186..199 (x10ms) beträgt.
Die DCF-Bit-Information wird in "Bit" weiterverarbeitet. Ob ein "Ende-Bit" (Telegrammende: Pause 1800/1900ms!) erkannt wurde, wird in "EndBit" gespeichert.
Jedes erkannte/decodierte DCF-Bit wird gezählt (in "BitZähler") und in eine Variable "BitSchieber" bitweise von oben hineingeschoben. Was bedeutet "von oben"? Das aktuelle DCF-Bit wird an die höchste Bitstelle (15x SHL auf Bit 15) hineinkopiert (OR), dann wird der BitSchieber um eine Stelle nach rechts (nach unten) rotiert (SHR). Damit ist er bereit für das nächste DCF-Bit.
Rechts oben im Programm ist auch noch "Parität" zu erkennen. Jedes DCF-Bit wird hier addiert,- letztlich also nur die Anzahl der 1-Bits, die wir später für die Paritätsberechnung brauchen.
Danach werden mit den Verzweigungen A=0 bis A=60 die BitZähler-Stände abgefragt. Mit A=14 beginnt das DCF-Telegramm. Bei A=20 sind schon die "DCF-Flags" eingesammelt und können in DCFFlg gesichert werden. Der Sinn dieser Abfragen ergibt sich aus der Kenntnis des Aufbaus des DCF-Telegramms, der hier nicht noch einmal erläutert wird. Warum wird der BitSchieber eigentlich noch mit 9x SHR nach "unten" geschoben, bis er in DCFFlg gespeichert wird? Der Grund: Da der BitSchieber Platz für 16 Bits hat und die Flags (DCF-Bits 15..20) nur aus 6 Bits bestehen, muss der Inhalt des Bitschiebers noch nach unten geschoben werden, bis DCF-Bit 15 an Bitnummer 0 des BitSchiebers liegt. So geht das auch bei allen anderen Werten des Telegramms.
Da die Werte für Minute, Stunde ... als BCD-Zahlen decodiert werden, müssen sie mithilfe von BCD2DEC in Dezimalwerte umgewandelt werden. Das Unterprogramm MinMax testet die Werte auf den jeweils zulässigen Bereich,- für den Monat also z.B. auf 1 bis 12.

Bleibt noch das Problem der Parität:
An der Stelle A=28 (BitZähler ist 28) wird z.B. das Paritätsbit P1 (Minutenparität) ausgewertet: Die GERADE Parität bedeutet einen fehlerfreien Minutenwert. Die Variable "Parität" wird also bitweise UND-verknüpft mit 1 (AND B=1). Die nachfolgende Verzweigung bestimmt das Ergebnis: Ist A>0, dann ist die Parität UNGERADE und das Telegramm fehlerhaft. DCFErr wird also auf 1 gesetzt. Das Telegramm wird am Ende verworfen. Nach diesem Paritätstest wird Parität auf 0 gesetzt, genauso auch der BitSchieber. Das selbe Verfahren gibt es für die Paritätsbits P2 und P3.

Irgendwann ist das DCF-Telegramm zuende. Das ist der Fall, wenn ein "Ende-Bit" (Pause 1800 oder 1900ms) erkannt wurde oder der BitZähler die 59 überschreitet (darf nicht passieren: Fehler!).
Wenn am Telegrammende DCFErr den Wert 0 (kein Fehler im ganzen Telegramm!) hat, wird die Variable DCF_Ok auf 1 gesetzt. Damit liegt ein gültiges DCF-Telegramm vor, mit dem eine Uhr gestellt werden kann. DCF_Ok bleibt für eine 1/4 Minute auf 1, um dann wieder 0 zu werden. Obwohl DCF_Ok so lange 1 bleibt, sollte eine Uhr SOFORT gestellt werden, wenn DCF_Ok 1 wird, damit die DCF-Zeit möglichst rasch übernommen wird.

Bleibt noch ein Sonderfall bei A=59 (BitZähler ist 59): Die Schaltsekunde.
Hier wird im DCF-Telegramm ab und zu eine sog. Schaltsekunde eingefügt, da sich die Erde immer langsamer dreht. Die Bedingungen dafür (DCF-Bit 59 ist 0 und A2 ist 1) werden in dem (seltenen) Fall geprüft.

So viel zur kurzen Erklärung des eigentlichen DCF77-Decoders V0.97 ...
Ob es mal eine Version 1.0 gibt? Ich weiß es nicht ... ;)
Fragen :arrow: hier!
Gruß ftDirk

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Peterholland » 30 Sep 2012, 21:13

Hallo Dirk,

Es war ein interessantes und erfolgreiches FT-Treffen-2012 in Erbes-Budesheim !
Viele neue Ideeën + schöne Modellen.

Deine FT-Funkuhr, die auf der Convention 2012 zu sehen war, hat 3st I²C-LED-Displays (Conrad, Best.-Nr. 198344) für die Zeit (Stunde/Minute), Datum (Tag/Monat) und Jahr.

- Wäre es möglich auch das RoboPro-Programm mit anwendung dieser 3st I²C-LED-Displays zu uploaden ?

- Die Jumper-positionen + entsprechender Adressen sind dabei sehr wichtig, denke ich wie beim Flipper :

http://forum.ftcommunity.de/viewtopic.p ... 4&start=80


Grüss,

Peter
Poederoyen NL
Peter Poederoyen NL

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1831
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 01 Okt 2012, 13:33

Hallo Peter,

habe die Programmversion meines Convention-Modells der Funkuhr mit den drei LED-Displays (v2.1) hochgeladen.
Sobald die Admins sie online "geschubst" haben, solltest Du sie hier (http://www.ftcommunity.de/downloads.php ... ie=RoboPro) finden.

Gruß, Dirk

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

DCF77-Decoder mit RoboPro + Kuckuck

Beitrag von Peterholland » 25 Jul 2013, 16:52

Hallo,

Das Programm Funkuhr mit den drei LED-Displays (v2.1) funktioniert seit 2012 gut.

Ich habe aber einige Wochen her in Triberg für 9 Euro 2 Kuckucks-Blasebälge mit Pfeife gekauft.
Mit eine kleine Motorantrieb möchte ich diese Kuckucks-Blasebälge mit Pfeife antreiben.
Für 1 mal "Kuckuck" reicht eine Achse-Umdrehung mit Nocke + Schalter. Das wäre Einfach.

- Eine separate 4e Schleife für die Motorantrieb mit Achse + Nocke für :

- Bei CLK-Minuten -Var = 15 oder 30 oder 45 ---> eine Achse-Umdrehung für 1x "Kuckuck".

- Bei CLK-Stunden -Var Abfragen 1 bis zum 24 .....bei CLK-Stunden-Var = 13 = 1x "Kuckuck" ....usw.

Grüss,

Peter
Poederoyen NL
Peter Poederoyen NL

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Peterholland » 28 Jul 2013, 20:02

Bilder gibt es unter:

http://www.ftcommunity.de/categories.php?cat_id=2767
Grüss,

Peter
Poederoyen NL
Peter Poederoyen NL

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1831
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 10 Nov 2013, 20:41

Hallo DCF77-Fans,

die ft-Funkuhr aus ft:pedia 3/2012 gibt es jetzt auch mit Echtzeituhr (Real Time Clock - RTC); da läuft jetzt nichts mehr aus dem Takt, wenn die Langwelle eine Zeitlang nicht erreichbar sein sollte.

Verwendet habe ich den preisgünstigen DS1307 (I²C-Board ca. 15 Euro); den von ft mit Robo Pro ausgelieferten Treiber habe ich ein wenig verbessert. Treiber und Beispielprogramm habe ich in der ft:c hochgeladen (http://www.ftcommunity.de/data/download ... 07v1.0.zip). Etwas mehr zu RTCs und noch ein paar nette Beispielprogramme gibt es in der Weihnachts-ft:pedia ;-)

Beste Grüße,
Dirk

Edit: Download-Link ergänzt.
Zuletzt geändert von Dirk Fox am 11 Nov 2013, 18:07, insgesamt 1-mal geändert.

Benutzeravatar
schnaggels
Beiträge: 389
Registriert: 31 Okt 2010, 23:14
Wohnort: Kelkheim
Kontaktdaten:

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von schnaggels » 11 Nov 2013, 15:47

Na da sind wir aber schon gespannt :)

Thomas

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Peterholland » 11 Nov 2013, 18:44

Den preisgünstigen DS1307 (I²C-Board) gibt es auch bei Iprototype.nl :

https://iprototype.nl/products/componen ... ock-module

Gruss,

Peter
Poederoyen NL
Peter Poederoyen NL

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Peterholland » 24 Nov 2013, 18:48

Hallo Dirk,

Stimmt es das du im neuen RTC_Treiber DS1307 v1.0.rpp die variabele TX-Minuten nutzt statt CLK-Minuten im (alte) DCF77-Decoder v2.1
und TX-Stunden statt CLK-Stunden ?

Die Real Time Clock - RTC mit dem DS1307 funktioniert bei mir prima ! ......

In Kombination mit dem Kuckuck-antrieb gibt es aber Problemen die zusammen hangen mit die variabele TX-Stunden.
Es gleicht als ob die variabele TX-Stunden nicht stabil ist.... nur ein kleines Moment 0 ist und dann wieder die richtige Stunde....???????......und deswegen hört der Kuckuck nicht auf.

Es zeigte sich heraus das die variabele TX-Stunden auch nicht stabil ist im neuen RTC_Treiber DS1307 v1.0.rpp. (ohne Kuckuck-Antrieb)
Am TX-Display und LED-Display gibt es dann keine Problemen.

Mit verwendung der variabele TX-Stunden für andere Anwendungen fangen die Problemen an.
Ich denke auch an eine (andere) Anwendung mit einer grosse Klocke.

Was wäre möglich im Programm um die TX-Stunden stabil zu machen ?


Gruss,

Peter
Poederoyen NL

Antworten