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

DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 29 Jun 2012, 21:34

Hallo Leute,

nach Anregung hier:
http://forum.ftcommunity.de/viewtopic.p ... 9206#p9122
... mache ich hier mal einen Thread auf, dessen Ziel die Entwicklung eines DCF77-Decoders in RoboPro ist.

Hardware:
Was brauchen wir (Bestell-Nummern von Conrad)?
1. DCF77-Empfänger (641138)
2. Widerstand 4,7 kOhm (403334)
3. Kondensator 100 nF (500812)

4. ft-Kabel (3 Adern) zur Verbindung zwischen DCF77-Empfänger und TXC mit Steckern für +9 V, GND, DCF-Signal-Ausgang.

Wenn man die Antenne (Ferritstab) des DCF77-Empfängers befestigen will, kann man zusätzlich mit bestellen:
1. Kunststoff-Schellen 8mm 2x (531146)
2. Kunststoff-Distanzbolzen 2x (534706)
3. Kunststoff-Schraube M3 2x (830228)
4. Kunststoff-Mutter M3 2x (815969)
Mit diesen Teilen kann der Ferritstab an der Empfängerplatine befestigt werden.

Anschluss:
1. Widerstand einklemmen zwischen Klemme 2 und 4 des DCF77-Empfängers
2. Kondensator einklemmen zwischen Klemme 1 und 2 des DCF77-Empfängers
3. DCF77-Empfänger Klemme 1 (GND) mit TXC GND (Masse) verbinden
4. DCF77-Empfänger Klemme 2 (+) mit TXC 9 V (+9 V) verbinden
5. DCF77-Empfänger Klemme 4 (invertierter Ausgang) mit TXC I8 verbinden

Test:
Mit den beiden Testprogrammen, die ich in den Download-Bereich einstellen werde.

Soweit erst einmal.

Wer hat Lust, beim DCF77-Decoder mit zu machen?
Gruß ftDirk

thkais
Beiträge: 376
Registriert: 31 Okt 2010, 21:45

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von thkais » 30 Jun 2012, 05:54

Hallo,

zur Befestigung hätte ich noch einen Vorschlag: Heißkleber. Geht schnell und man braucht nicht himmelviele Schrauben und Schellen ;-)

Noch eine Anmerkung zum Pull-Up Widerstand: Eventuell könnte man den auch weglassen, sicher bin ich mir momentan nicht - wenn man den TX-Eingang auf "Taster" stellt, wird ein interner Pull-Up innerhalb des TX zugeschaltet. Müsste man probieren, ob das funktioniert.
Gruß
Thomas

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 30 Jun 2012, 12:33

... zum Pull-Up Widerstand: Eventuell könnte man den auch weglassen ---
Ich hab's mit D 5k und D 10V probiert ohne Erfolg. Da müßte man evtl. noch weiter mit den analogen Eingangsarten testen ...

Meine Eingangsart von I8 ist also "D 10V" mit dem beschriebenen Pullup-Widerstand. Schön ist ja, dass man nicht löten muss, sondern die wenigen Teile anschrauben kann.

Wer mitmachen will und die Teile irgendwann zusammengebaut hat, muss nicht unbedingt auf das Freischalten der Tests warten:
Mit einem Universaleingang, eingestellt auf I8 und Eingangsart D 10V, sowie auf Statisch: Immer verbunden ...
und einem daran angeschlossenen Bedienfeldausgang (Lampe) mit Anzeigelampe ...
und einem leeren Hauptprogramm (z.B. mit Endlos-Warteschleife) ...
kann man schon einmal die Pausen des DCF77-Signals sehen. Man müßte kürzere (800 ms) und längere (900 ms) gerade so unterscheiden können und auf jeden Fall einmal pro Minute eine lange Pause (1,8/1,9 s). Diese lange Pause beginnt in Sekunde 58 und endet mit dem Minutenende (Vergleich z.B. mit einer anderen digitalen Funkuhr). Wenn das so klappt, ist der Emfang des DCF77-Signals schon einmal ok und es kann weiter gehen ...

Noch ein paar Hinweise auf die Position des DCF77-Emfängers, wenn er erfolgreich empfangen soll:
1. Mehr als 50 cm entfernt von PCs, Laptops, Funkmäusen, Monitoren, Handys, Routern ...
2. Mehr als 20 cm entfernt vom TXC
3. Antenne des Empfängers (quer!) ausgerichtet Richtung Mainflingen (Frankfurt)
4. Möglichst wenig Hindernisse in Richtung des Senders, evtl. an ein Fenster stellen ...
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 30 Jun 2012, 14:36

Während ihr evtl. als Interessierte auf die Hardware wartet oder zumindest mitlesen wollt, können wir uns ein bißchen mit der Theorie des DCF77-Systems beschäftigen:

Das DCF77-System wird zur Verfügung gestellt von der PTB (Physikalisch-Technische Bundesanstalt) in Braunschweig. Die Abt. 4 ist für die Erzeugung des DCF77-Protokolls verantwortlich. Hier kann man nachlesen, was da gemacht wird:
http://www.ptb.de/cms/index.php?id=1787

Die PTB überwacht von Braunschweig aus die Erzeugung des DCF77-Protokolls, es wird dann vom Betreiber der Sendeanlage (Media Broadcast GmbH, früher Deutsche Bundespost) in Mainflingen übernommen und auf 77,5 kHz gesendet. Zu empfangen ist das Signal fast überall in Europa.
Wer Genaueres wissen will, sollte sich auf der verlinkten Seite die "PDF-Datei" herunter laden.

Außer der Zeitinformation werden durch den DCF77-Sender noch Wetterinformationen übertragen (in den ersten 15 Sekunden jeder Minute).
Informationen finden sich hier:
http://www.ptb.de/de/aktuelles/archiv/p ... 061212.htm
Die Schweizer Firma Meteo Time GmbH nutzt diese Übertragung, um codierte regionalisierte Wetterinformationen in ganz Europa zur Verfügung zu stellen. Zur Decodierung benötigt man eine Lizenz. Diese erwirbt der Kunde z.B. mit dem Kauf einer Wetterstation mit der Kennzeichnung "DCF77" und "METEOTIME". Für die Zeitübertragung sind diese Informationen nicht relevant.

Wie sieht nun das DCF77-Protokoll aus?
Sehen wir uns den Zeitcode:
http://www.ptb.de/cms/fachabteilungen/a ... tcode.html ...
einmal an:
In jeder Minute werden 59 (Nr. 0 bis 58) Bits (= 0/1 Informationen) gesendet.

Bedeutung:
Bit 0 = Startbit (immer 0)
Bits 1 bis 14 = Wetterinformationen der Meteo Time GmbH
Bits 15 bis 20 = So genannte "Flags" (Bit 20 immer 1)
Bits 21 bis 27 = Minute
Bit 28 = Minutenparität (P1)
Bits 29 bis 34 = Stunde
Bit 35 = Stundenparität (P2)
Bits 36 bis 41 = Kalendertag
Bits 42 bis 44 = Wochentag
Bits 45 bis 49 = Kalendermonat
Bits 50 bis 57 = Kalenderjahr
Bit 58 = Datumsparität (P3)
Bit 59 = Schaltsekundenbit (immer 0)

Die Zeitinformationen beziehen sich immer auf die FOLGEMINUTE. Das heißt:
Mit dem Beginn von Bit 0 der nächsten Minute kann diese Information zum Stellen einer Uhr verwendet werden. In der Minute 21:59:15 bis 21:59:59 werden also die Datums- und Zeitinformationen für die Minute ab 22:00 gesendet.

Wie werden die einzelnen Bits übertragen:
Für jedes Bit steht ja eine Sekunde des DCF77-Protokolls zur Verfügung. Das Bit ist "0", wenn auf einen Impuls von 100 ms eine Pause von 900 ms folgt.
Das Bit ist "1", wenn der Impuls 200 ms lang ist und die Pause 800 ms. Bleibt noch die Frage, wie ein DCF-Decoder das Ende (Bit 58) des Protokolls erkennen kann:
Da mit Bit 58 die Minute ja noch nicht zuende ist, wird die Pause des 58. Bits (P3) um eine Sekunde verlängert, beträgt also 1800 ms oder 1900 ms (je nach Bitwert von P3). Durch diese lange Pause können Decoder das Ende des Protokolls erkennen. Direkt nach dieser Pause beginnt die neue Minute.
Es gibt eine Ausnahme: Wenn eine Schaltsekunde eingefügt werden muss (z.B. MORGEN am 1.7.12 um 2:00 Uhr!), gibt es nach P3 ein weiteres Bit (59) und erst daran anschließend eine Pause von 1,9 s. Damit hat die laufende Minute nicht 60, sondern 61 Sekunden.
Wen es interessiert: Dieses recht seltene DCF-Protokoll wird am 1.7.12 ab 01:59:15 Uhr gesendet. Die letzte Schaltsekunde wurde Anfang 2009 eingefügt. Angekündigt wird jede Schaltsekunde eine Stunde vorher durch das Bit A2 (Nr. 19): Es bekommt den Wert "1" (sonst immer "0").

Wenn man das DCF77-Protokoll decodieren will, muss man also Impulslängen messen. Am besten ist es, nicht die Impulse (100/200 ms), sondern die Pausen zu messen (800/900/1800/1900 ms). Grund: Mit den Pausen erhält man auch die Information über das Ende des Protokolls.
RoboPro kann auch Impulslängen messen. Dazu braucht man z.B. eine Zählschleife mit einer Laufzeit von 10 ms. Diese Laufzeit ist zu empfehlen, weil die Eingänge sowieso nicht häufiger abgefragt bzw. ausgegeben werden.
In dieser Schleife kann man dann die Durchläufe zählen, so lange eine Pause dauert. Wenn das richtig umgesetzt ist, müßte man also Zahlenwerte von ca. 80, 90, 180 und 190 bestimmen können.

Das dürfte ja mal nicht so schwer sein, oder ...?

Fortsetzung folgt ...
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 30 Jun 2012, 14:46

Hallo ftDirk,

tolle Vorarbeit! Jetzt ist die ft:pedia online, da kann ich mir ein neues Projekt vornehmen...
Werde erstmal Deinen Hardware-Empfehlungen folgen und mich dann an die Software setzen.

Beste Grüße,
Dirk
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

thkais
Beiträge: 376
Registriert: 31 Okt 2010, 21:45

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von thkais » 30 Jun 2012, 15:09

Hallo,

noch ein Hinweis: Wenn man eine Schleife mit 10ms in RoboPro erreichen will, muss man die Laufzeit der Schleife selbst berücksichtigen (der Timer-Befehl wartet nur die 10ms ab, die Schleife selbst kommt noch hinzu).
Bitarithmetik mit Prüfsummenberechnung in RoboPro - das wird lecker ;)
Gruß
Thomas

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 30 Jun 2012, 15:14

Hallo Thomas,

in meinen ersten Tests (ich habe sie schon upgeloadet und warte auf die Freischaltung) mußte ich eine Verzögerung von 0,009 Sek. einbauen, um realistische Zählerwerte (80, 90, 180,190) zu bekommen.

Das kann man evtl. noch "feintunen" ... ;)
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 30 Jun 2012, 17:26

Bitarithmetik mit Prüfsummenberechnung in RoboPro - das wird lecker
Da ich immer für leckere Sachen zu haben bin, können wir uns ja erst mal gedanklich mit der Auswertung beschäftigen:

Nach einer langen Pause müßte ich also anfangen, die empfangenen Bits "einzusammeln". Ich kann das so machen, dass ich das DCF-Bit (0 oder 1) oben in eine ganzzahlige Schiebe-Variable "hineinschiebe". Unsere Variablen können 16 Bits (Nr. 0..15) aufnehmen. Ich würde also das empfangene Bit (0 oder 1) zuerst 15x nach links schieben (SHL). Damit steht es an Bitposition 15.
Dann verknüpfe ich das Ergebnis bitweise über den Oder-Operator (OR) mit der Schiebe-Variable.
Zum Schluß schiebe ich die Bits noch eine Stelle weiter nach rechts (SHR) und das Ergebnis wandert in die Schiebe-Variable zurück.
Mit der letzten Schiebeaktion nach rechts habe ich "oben" in der Schiebe-Variablen (Bit 15) wieder Platz gemacht für das nächste DCF77-Bit.

Soweit so gut.

Es werden allerdings 59 Bits gesendet. Die passen natürlich nicht alle in die Schiebe-Variable. Das müssen sie letztlich auch nicht, weil ich ja die einzelnen Zeitinformationen (Flags, Minute, Stunde, Tag, Wochentag, Monat, Jahr) sowieso GETRENNT haben möchte.
Ich muss also die Bit-Schieberei immer dann unterbrechen, wenn ich das jeweils letzte DCF-Bit der Einzel-Infos erreicht habe.
Beispiel Tag:
Ich schiebe Bits 36 bis 41 in die Schiebe-Variable (die natürlich vorher auf 0 gesetzt wurde!) hinein. Das sind 6 Bits, so dass sie in der Schiebe-Variable die Bits 10..15 belegen, BEVOR die o.g. letzte Schiebeaktion (1x SHR) zum Tragen kommt. Danach liegen die 6 Bits des Tages in den Bits 9..14 der Schiebe-Variable.
Nun müssen diese 6 Bits noch an den Anfang der Schiebe-Variable kommen, also schiebe ich sie 9x nach rechts (9x SHR). Sie liegen nun endgültig in den Bits 0..5 der Schiebe-Variable, wo sie auch hingehören.
Damit ist die Info über den Tag (1..31) angekommen und kann in eine neue Variable kopiert werden.
Leider ist das der Tag als BCD-Information. Ich muss also noch eine Umwandlung BCD-DEC durchführen,- ein passendes Unterprogramm gibt es schon in den RoboPro-Demos (im Treiber für die RTC DS1307). Nun habe ich endlich den Tag decodiert.
So geht es dann weiter mit allen Einzel-Infos.
Am Ende des DCF-Protokolls (am Ende der langen Pause) kann nun die Uhr (z.B. einer RTC oder eine Software-Uhr) mit den decodierten Infos gestellt werden.

Die schreckliche Sache mit der "Prüfsummenberechnung" folgt ... :?
Zuletzt geändert von ftDirk am 03 Jul 2012, 15:59, insgesamt 1-mal geändert.
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 30 Jun 2012, 19:53

Bevor es um "Prüfsummen" geht, muss man zuerst über das "Sicherheitskonzept" des DCF77-Protokolls reden:

Leitsatz:
Ein DCF77-Protokoll ist GÜLTIG (valide), wenn es INTAKT und PLAUSIBEL ist. Eine Uhr darf nicht mit ungültigen DCF-Daten gestellt werden.

Was bedeutet das?

Ein DCF77-Protokoll (bzw. Telegramm) ist INTAKT, wenn alle 6 folgenden Punkte erfüllt sind:
1. DCF Bit 0 ist 0
2. DCF Bits 17 und 18 sind ungleich
3. DCF Bit 20 ist 1
4. Die Paritätsbits 28, 35 und 58 enthalten eine korrekte gerade Parität (darüber müssen wir noch reden ...)
5. Es wurden genau 58 DCF Bits decodiert
6. Im Fall der Schaltsekunde: DCF Bit 59 ist 0 und DCF Bit 19 ist 1

Ein DCF77-Protokoll ist PLAUSIBEL, wenn alle decodierten Werte im möglichen Bereich liegen. Ein Wert von 11 für den Wochentag ist z.B. nicht plausibel. Man kann es auch allgemeiner sagen:
Ein DCF77-Protokoll ist plausibel, wenn es die Folgeminute der aktuellen Minute enthält.

Also: INTAKT + PLAUSIBEL = GÜLTIG

Man kann dann die Sicherheit noch erhöhen, indem man GÜLTIGE Protokolle ZÄHLT. Man gibt dann z.B. vor, dass nur jedes 3. gültige Protokoll in direkter Folge zum Stellen der Uhr verwendet werden darf. Dadurch kann man indirekt bessere Empfangsbedingungen zum Stellen der Uhr verwenden. Häufig sind das Nachtzeiten, da in der Nacht der Störpegel von Elektrogeräten geringer ist.

Mein Vorschlag:
Wir kümmern uns zuerst überhaupt nicht um diesen Quatsch und versuchen, die Werte erst einmal richtig zu decodieren. Dazu muss man nicht einmal die Paritätsbits auswerten. Ohnehin ist es unsere Entscheidung, wie sicher wir gehen wollen.
Das macht's doch entschieden leichter ... ;)
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 30 Jun 2012, 23:33

Hallo ftDirk,

die Implementierung sollte nicht so schwierig sein. Ein paar Ideen zur Struktur:

A. Uhr stellen

1. Synchronisation: Wir warten, bis wir 1,9 sec. lang den Wert 0 anliegen haben (Start des nächsten Datagramms).
2. Wir zählen 21 Bit und vergessen sie erstmal.
3. Wir empfangen 7 Bit und shiften sie in eine Variable (= Minute), dann ignorieren wir ein Bit.
4. Wir empfangen 6 Bit und shiften sie in eine Variable (= Stunde).

Für die Zeitauswertung genügt das erstmal. Dann bleibt genug Zeit (24 sec.), um bei Bedarf die Uhr zu stellen, bis das nächste Datagramm kommt.

B. Datum stellen

Eine separate Routine sollte das Datum auswerten.
Das sollte m.E. üblicherweise nur einmal - beim Einschalten - passieren, vielleicht sinnvollerweise bevor man die Zeit aus dem Datagramm ausliest.

1. Synchronisation (s.o.)
2. Wir zählen 35 Bit und vergessen sie.
3. Wir empfangen 6 Bit und shiften sie in eine Variable (Kalendertag).
4. Wir empfangen 3 Bit und shiften sie in eine Variable (Wochentag).
5. Wir empfangen 5 Bit und shiften sie in eine Variable (Monat).
6. Wir empfangen 8 Bit und shiften sie in eine Variable (Jahr).

Anschließend stellen wir das Datum ein und zeigen es an.

Herzlicher Gruss,
Dirk
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

Benutzeravatar
steffalk
ft:pedia-Herausgeber
Beiträge: 1107
Registriert: 01 Nov 2010, 16:41
Wohnort: Karlsruhe
Kontaktdaten:

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von steffalk » 01 Jul 2012, 11:19

Tach auch!

Also ehrlich, das *schreit* doch geradezu nach einem ft:pedia-Artikel.

Gruß,
Stefan

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 01 Jul 2012, 11:48

Hallo Dirk,

genial! Das könnte gut klappen.

Was noch bleibt, bevor ich meine "Vielschreiberei" erstmal beende, ist die Sache mit der Parität.

Beim Stichwort "INTAKTES DCF77-Protokoll" hatte ich weiter oben als 4. Punkt erwähnt:
Die Paritätsbits 28, 35 und 58 enthalten eine korrekte gerade Parität (darüber müssen wir noch reden ...)
Also reden wir darüber:
Es gibt drei Paritätsbits P1, P2 und P3. Sie dienen dazu, eine gewisse Sicherheit zu erreichen, dass die Minute (P1), die Stunde (P2) und das Datum (P3) INTAKT sind. Dabei ist die Uhrzeit so wichtig, dass sie mit zwei Paritätsbits (P1, P2) gesichert wird, während eins (P3) für das Datum (Tag, Wochentag, Monat, Jahr) ausreichen muss. Durch die Paritätsbits können einzelne "Bitdreher" (aus 0 wird 1 oder umgekehrt), z.B. durch schlechten Empfang, gut erkannt werden.

Wie geht das mit der "geraden Parität"?
Nehmen wir P1. Dieses Bit 28 heißt Minutenparität. Es ist die Parität der DCF-Minutenbits 21 bis 27. In diesen 7 Bits gibt es Einsen und Nullen. Man kann nun die Einsen zählen. Dabei kommt man entweder auf eine GERADE oder eine UNGERADE Zahl von Bits.
Nehmen wir an, man zählt 3 Einsen in allen 7 Minutenbits. Dann ist die Zahl der Einsen UNGERADE. Um eine GERADE Parität zu erreichen, muss P1 eine "1" enthalten. Damit kann man in den 7 Minutenbits UND in P1 zusammen wieder eine GERADE Anzahl von Einsen finden.
Würden wir jedoch z.B. 4 Einsen in allen 7 Minutenbits zählen, dann hätten wir schon eine GERADE Zahl von Einsen. Demnach würde P1 als "0" gesendet, damit die Parität GERADE bleibt.

P1 bildet also die gerade Parität der Minutenbits 21 bis 27 ab.
P2 funktioniert genauso für die Stundenbits 29 bis 34 und
P3 für die Datumsbits 36 bis 57.

Wie kann man das im DCF77-Decoder umsetzen?
Man würde in den drei Bereichen alle Einsen zählen. Ist die Zahl z.B. in den Minutenbits GERADE, muss P1 "0" sein. Ist das nicht der Fall, ist das Protokoll nicht intakt.

In RoboPro gibt es zwar keinen direkten Operator für GERADE/UNGERADE. Das läßt sich aber auf Bit-Ebene einfach beantworten: Wenn Bit 0 einer ganzzahligen Variable "0" ist, dann ist die Zahl GERADE. Umgekehrt ist sie UNGERADE, wenn Bit 0 "1" ist. Man kann also die Bit-Zähler-Variable bitweise UND-verknüpfen (AND) mit der Konstante "1". Ist das Ergebnis > 0, dann ist der Bit-Zähler UNGERADE.
Bewerten kann man das Ergebnis auf zwei Arten: Für die Minutenparität zählt man z.B. die Einsen der DCF-Bits 21 bis 28 (also MIT P1!). Dann muss das Ergebnis GERADE sein. Oder man zählt die DCF-Bits 21 bis 27. Ist das Ergebnis UNGERADE, muss P1 "1" sein, sonst "0". Beide Tests führen zum selben Ergebnis.

Noch ganz kurz zu den "DCF-Flags" (DCF-Bits 15 bis 20).
Sie haben folgende Bedeutung:
Bit 15 (R): Rufbit für PTB-Mitarbeiter (1, wenn etwas nicht stimmt ...)
Bit 16 (A1): Ankündigung des Wechsels MESZ <-> MEZ (1 Stunde vorher auf 1, sonst 0)
Bit 17 (Z1) und Bit 18 (Z2): Zeitzonenbits (Z1/Z2 = 1/0 -> MESZ; Z1/Z2 = 0/1 -> MEZ; Z1 u. Z2 müssen immer ungleich sein!)
Bit 19 (A2): Ankündigung einer Schaltsekunde (1 Stunde vorher auf 1, sonst 0)
Bit 20 (S): Startbit der Zeitinformationen (immer 1)


So viel von mir! Ich melde mich wieder, wenn die 2 Testprogramme im Download-Bereich stehen.

P.S. (@Dirk):
Ich bin schon jetzt gespannt, was du aus dem Ganzen für einen schönen ft:pedia Artikel nutzen kannst!
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 01 Jul 2012, 15:05

Hallo Dirk,

das klingt gut. Nach dem Empfang der Zeit (A.) bleibt genug Restzeit, um die Parität zu prüfen - ich würde es am Schluss machen (und bei einem Fehler das Datagramm "wegwerfen"), um das Timing-Problem beim Empfang nicht zu verkomplizieren.

Meine Conrad-Bestellung ist noch unterwegs, sobald die Teile da sind, lege ich los...
ftdirk hat geschrieben:Ich bin schon jetzt gespannt, was du aus dem Ganzen für einen schönen ft:pedia Artikel nutzen kannst!
Ich habe schon angefangen, hyperaktiv wie ich gerade bin dank publizierter ft:pedia 2/2012 :-) - Strukturidee: ein wenig Geschichte (UTC, PTB), dann kommt das Protokoll, dann die Hardware, dann die Software. Wahrscheinlich genug Stoff für zwei Beiträge oder einen langen - entweder gibst Du Dich also als Mit-Autor her, oder wir teilen in zwei... :-)

Beste Grüße,
Dirk
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 06 Jul 2012, 00:32

Hallo Dirk,

heute abend fand ich auf meinem Schreibtisch das Conrad-Paket - und wenig später empfing mein Empfänger (im Interface-Test schaltete im Sekundentakt der Eingang I8 kurz auf "1"). Jetzt liefert die "RoboPro-Uhr" bereits erste Ergebnisse (noch ohne Parity-Tests, das hebe ich mir für's Wochenende auf).

Erste wichtige Erkenntnis aus meinen Versuchen: Es geht fast ohne "Zeitzähler" - ich warte in einem Unterprogramm "GetSignal" einfach, bis eine positive Flanke kommt, danach prüfe ich, ob das Signal nach 0,1 sec. immer noch anliegt. Wenn ja, ist der Wert =1, wenn nein, ist er =0. Richtig zählen muss ich nur in der Sync-Funktion, in der ich auf das nächste Datagramm warte (also auf mehr als 0,9 sec. ohne positive Flanke).

Beste Grüße,
Dirk
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 06 Jul 2012, 22:45

Hallo Dirk,

das klingt schon gut!

Dann ist der Erfolg ja schon gesichert ... :o

Wahrscheinlich ist dein fertiger Decoder eher downloadbar, als meine 2 Testprogs. Grrr :cry:
Warum dauert das eigentlich sooo lange?
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 07 Jul 2012, 16:23

Oh, jetzt ging es ja schnell ... ;)

Hier: http://www.ftcommunity.de/data/download ... 7tests.zip
... sind jetzt die 2 DCF77-Tests online.

Der 1. Test zeigt nur, wie man die Pausen- und Impulslängen anzeigen kann.

Der 2. Test stellt das DCF77-Telegramm forlaufend dar.
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 10 Jul 2012, 01:03

Hallo zusammen,

sodele... meine erste Programmversion ist jetzt auch hochgeladen. Sie synchronisiert sich minütlich und aktualisiert abwechselnd Uhrzeit und Datum - ist also noch keine komplette Uhr, sondern erstmal ein DCF77-Decoder in RoboPro. Damit kann man jetzt vieles machen, z.B. eine mechanische Uhr stellen, eine Ausgabe auf ein I²C-LCD-Display zaubern oder eine I²C-Echtzeituhr mit der Atomuhr in Braunschweig synchronisieren :-)

By the way: Ich habe bei der Gelegenheit das BCD2DEC-Konverter-Unterprogramm von Rei Vilo optimiert; es verwendet jetzt nur noch Bitoperationen. Das ist vielleicht auch für andere Programme nützlich.

Gruß, Dirk

P.S.: Die Erstfassung des ft:pedia-Beitrags ist auch fast fertig - fehlt nur noch der Hardware-Part, bei dem ich auf ftDirk setze ;-)
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von ftDirk » 10 Jul 2012, 16:32

- fehlt nur noch der Hardware-Part, bei dem ich auf ftDirk setze
Ok, gern.
Aber was wäre der "Hardware-Part"?
Streng genommen ist das ja eigentlich nur der Einkauf der Teile, deren Verdrahtung und Anschluss an den TXC. Das ist nur ein kurzer Textblock (steht ja schon in diesem Thread), den wir gern so übernehmen können.
Oder hattest du an etwas anderes oder an mehr gedacht :?:

P.S.: Wo ist dein ROBOPro-DCF77-Decoder? Ich habe ihn noch nicht in den Downloads gefunden ...
Gruß ftDirk

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

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Dirk Fox » 10 Jul 2012, 18:13

Hallo ftDirk,
ftDirk hat geschrieben:Aber was wäre der "Hardware-Part"? Streng genommen ist das ja eigentlich nur der Einkauf der Teile, deren Verdrahtung und Anschluss an den TXC. Das ist nur ein kurzer Textblock (steht ja schon in diesem Thread), den wir gern so übernehmen können.
ok, habe ich schonmal so übernommen. 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...).
ftDirk hat geschrieben:P.S.: Wo ist dein ROBOPro-DCF77-Decoder? Ich habe ihn noch nicht in den Downloads gefunden ...
Tja, das wissen allein unsere göttlichen Admins ... ;-)

Beste Grüße,
Dirk
http://fischertechnik-blog.de - technikgeschichte-mit-fischertechnik.de - http://ftpedia.de

Masked
Beiträge: 497
Registriert: 18 Okt 2010, 18:19

Re: DCF77-Decoder mit RoboPro und TXC

Beitrag von Masked » 10 Jul 2012, 18:40

Dirk Fox hat geschrieben:
ftDirk hat geschrieben:P.S.: Wo ist dein ROBOPro-DCF77-Decoder? Ich habe ihn noch nicht in den Downloads gefunden ...
Tja, das wissen allein unsere göttlichen Admins ... ;-)
Ist freigeschaltet!
Grüße,
Martin

Antworten