Inhaltsverzeichnis
DCF77-Decoder als Bascom-Library
Im RN-Forum ist das Thema DCF77-Decodierung schon häufig diskutiert worden. Dieser Wiki-Artikel soll einmal grundlegend beschreiben, wie man einen DCF77-Decoder programmieren kann. Da ich hauptsächlich mit Bascom arbeite, war es naheliegend, den Decoder als Bascom-Asm-Library zu schreiben. Er hat bis zur jetzigen Version 4.00 einen langen Weg mit unterschiedlichen Verbesserungen hinter sich.
DCF77-Grundlagen
Seit dem 1.9.1970 wird in Deutschland die amtliche Zeit über 24 Stunden ausgesendet. Der DCF77-Sender steht in Mainflingen bei Frankfurt. Sein 77,5 kHz Trägersignal wird von meistens schmalbandigen Empfängern überall in Westeuropa in Form von "Funkuhren" empfangen. Die Empfänger in den Funkuhren liefern am Ausgang die "Hüllkurve" des amplitudenmodulierten Signals. DCF77-Empfänger werden auch unabhängig von Funkuhren angeboten (z.B. CONRAD Best.-Nr. 641138 oder von Reichelt ...). Das Ausgangssignal der Empfänger kann direkt an einen Eingangs-Pin eines Mikrokontrollers gelegt und von diesem weiter verarbeitet werden. Diese Weiterverarbeitung ist die DCF77-Decodierung, die dieser Artikel beschreibt.
Aufbau des DCF77-Signals
Der DCF77-Sender sendet sogenannte "Sekundenmarken". Sie bilden den Anfang jeder Sekunde und sind entweder 100ms oder 200ms lang. Während dieser 0,1s oder 0,2s wird die Sendeleistung auf etwa 25% abgesenkt. Danach beginnt eine "Pause" mit der vollen Sendeleistung (100%). Diese Pause ergänzt die laufende Sekunde: Sie ist also 900ms lang, wenn die Sekundenmarke 100ms lang war oder 800ms lang, wenn die Sekundenmarke 200ms lang war. Die Sekundenmarken werden von 0 bis 58 durchnummeriert. Eine 59. Marke gibt es normalerweise nicht, stattdessen verlängert sich die Pause nach der 58. Sekundenmarke auf 1900ms oder 1800ms (je nach Länge der 58. Marke). Diese Pause dient bei den Decodern zur Synchronisation: Wenn sie endet, beginnt die neue Minute und damit auch das nächste DCF77-Telegramm mit der Sekundenmarke 0.
Im weiteren Text verwenden wir diese Begriffe:
- Pause: Eine Pause bezeichnet die Phasen mit 100% Sendeleistung.
- Sekundenmarke: Eine Sekundenmarke ist die Phase mit 25% Sendeleistung.
- DataBit: Ein DataBit besteht aus der Sekundenmarke (100/200ms) und aus der zugehörigen Pause (900/800ms).
- LastBit: Ein LastBit kommt nur EINMAL in jeder Minute vor und kennzeichnet das Ende der Minute. Es besteht aus der (normalerweise 58.) Sekundenmarke (100/200ms) und der zugehörigen Pause (1900/1800ms).
- (DCF77-)Telegramm: Ein Telegramm ist die vollständige DCF77-Information, die in einer Minute gesendet wird. Sie endet mit einem LastBit. Mit dem Ende des LastBits beginnt die Minute, auf die sich die Informationen des Telegramms beziehen. Somit kann am Ende des LastBits eine Uhr gestellt werden.
- (Data-/Last-)Bit0: Ein DataBit oder LastBit ist ein Bit0, wenn die Sekundenmarke 100ms lang ist. Bit0 entspricht dem logischen "low" oder "0".
- (Data-/Last-)Bit1: Ein DataBit oder LastBit ist ein Bit1, wenn die Sekundenmarke 200ms lang ist. Bit1 entspricht dem logischen "high" oder "1".
Wenn ich gesagt habe, dass es eine 59. Sekundenmarke normalerweise nicht gibt, dann war das sicher richtig. Es gibt aber eine wichtige Ausnahme.
Einfügen einer Schaltsekunde
Tendenziell dreht sich unsere Erde immer langsamer um ihre Achse und "trudelt" dabei noch. Das bedeutet, dass in unregelmäßigen Abständen sogenannte "Schaltsekunden" in die UTC eingefügt werden müssen, um den Gleichlauf der UTC mit der Erdrotation sicher zu stellen. Die vorläufig letzte Einfügung einer Schaltsekunde fand im Januar 2006 statt. Möglich sind solche Einfügungen am 1.1. und 1.7. jedes Jahres. Das Einfügen einer Sekunde bedeutet für die Aussendung dieses speziellen DCF77-Telegramms, dass die Minute aus 61 Sekunden besteht. Das wird so umgesetzt, dass die 58. Sekundenmarke (P3) nicht wie sonst ein LastBit, sondern ein DataBit ist und sich noch ein weiteres LastBit anschließt. Dieses zusätzliche LastBit hat eine Sekundenmarke von 100ms (LastBit0) und eine Pause von 1900ms. Damit beginnt die neue Minute mit einer Verzögerung von 1 Sekunde, d.h. eine Schaltsekunde wurde eingefügt.
Informationen im DCF77-Telegramm
In jeder Minute werden Informationen durch die unterschiedliche Länge der Sekundenmarken übertragen.
| BIT-NR. | BEDEUTUNG DES DCF77-BITS: |
| 0..14 | Interne PTB-Informationen |
| 15 R | Rufbit für Alarmierung der PTB-Mitarbeiter |
| 16 A1 | Ankündigung des Wechsels MEZ <-> MESZ |
| 17 Z1 | \__ Z1/Z2: 10 = MESZ, 01 = MEZ |
| 18 Z2 | / |
| 19 A2 | Ankündigung einer Schaltsekunde |
| 20 S | Startbit f. Zeitinformationen (immer 1) |
| 21 | Minute x 1 |
| 22 | Minute x 2 |
| 23 | Minute x 4 |
| 24 | Minute x 8 |
| 25 | Minute x 10 |
| 26 | Minute x 20 |
| 27 | Minute x 40 |
| 28 P1 | Minutenparität (gerade Parität Bits 21..27) |
| 29 | Stunde x 1 |
| 30 | Stunde x 2 |
| 31 | Stunde x 4 |
| 32 | Stunde x 8 |
| 33 | Stunde x 10 |
| 34 | Stunde x 20 |
| 35 P2 | Stundenparität (gerade Parität Bits 29..34) |
| 36 | Tag x 1 |
| 37 | Tag x 2 |
| 38 | Tag x 4 |
| 39 | Tag x 8 |
| 40 | Tag x 10 |
| 41 | Tag x 20 |
| 42 | Wochentag x 1 |
| 43 | Wochentag x 2 |
| 44 | Wochentag x 4 |
| 45 | Monat x 1 |
| 46 | Monat x 2 |
| 47 | Monat x 4 |
| 48 | Monat x 8 |
| 49 | Monat x 10 |
| 50 | Jahr x 1 |
| 51 | Jahr x 2 |
| 52 | Jahr x 4 |
| 53 | Jahr x 8 |
| 54 | Jahr x 10 |
| 55 | Jahr x 20 |
| 56 | Jahr x 40 |
| 57 | Jahr x 80 |
| 58 P3 | Datumsparität (gerade Parität Bits 36..57) |
| (59) | Evtl. Schaltsekunde (immer 0) |
Ein intaktes DCF77-Telegramm sieht also z.B. so aus (Bits 15..58):
Bits 15..20 Minute P1 Stunde P2 Tag Wochentag Monat Jahr P3
000101 0000000 0 000000 0 100000 011 10000 01100000 0
Es enthält folgende Informationen: 0.00 Uhr MEZ am Samstag, den 1.1.06. Die Uhrzeit- und Datumsangaben sind BCD-codiert. Der dezimale Wert ergibt sich durch Addition der in der Tabelle angegebenen Multiplikatoren an den Stellen, an denen das jeweilige Bit ein Bit1 ist. Die Paritätsbits P1..P3 ergänzen die zugeordneten DCF77-Bits jeweils auf eine gerade Parität. Wenn es z.B. bei den Stunden-Bits 29..34 genau 3 Bits gibt, die 1 sind, dann muss P2 ein Bit1 sein, um eine gerade Parität zu erreichen. Wenn P2 dann ein Bit0 ist, ist das Telegramm fehlerhaft.
Ein intaktes DCF77-Telegramm erfüllt folgende Bedingungen:
- Bit 20 (S) ist ein Bit1
- Die Paritätsbits P1..P3 ergeben eine korrekte gerade Parität
- Es wurden genau 58 Bits (Ausnahme: Schaltsekunde!) decodiert
- Im Fall der Schaltsekunde ist das Bit 59 ein (Last-)Bit0
Dieses intakte DCF77-Telegramm muss anschließend noch auf Plausibilität überprüft werden, bevor es zum Stellen einer Uhr benutzt werden kann. Grund: Ein Telegramm könnte zwar intakt sein, aber z.B. folgendes Datum enthalten: 0.13.101. Da es keinen Tag 0, keinen Monat 13 und kein Jahr 101 geben kann, ist solch ein Telegramm nicht plausibel, also ebenfalls fehlerhaft. Eine Uhr darf mit solchen Informationen nicht gestellt werden. Zulässige (plausible) Werte sind:
- Minute: 0..59
- Stunde: 0..23
- Tag: 1..31
- Wochentag: 1.. 7 (für Montag..Sonntag)
- Monat: 1..12
- Jahr: 0..99
Wenn ein DCF-Decoder ein Telegramm als intakt und plausibel getestet hat, steht prinzipiell dem Stellen der Uhr mit diesen Informationen nichts mehr im Wege.
Bei besonders hohen Anforderungen an die Zuverlässigkeit von Zeit-Informationen werden jedoch noch weitere Prüfungen durchgeführt, bevor das Telegramm als "gültig" bzw. valide angesehen wird:
- Wie viele Telegramme vor dem aktuellen Telegramm waren ebenfalls intakt und plausibel?
- Ist das aktuelle Telegramm gleich dem vorherigen Telegramm plus 1 Minute?
Die Prüfung der ersten Frage kann in Form eines Grenzwertes erfolgen: Das aktuelle Telegramm ist nur dann gültig (und wird übernommen), wenn z.B. mindestens 2 vorherige Telegramme ebenfalls intakt und plausibel waren. Damit würde nach einer Empfangsstörung (d.h. einem fehlerhaften Telegramm) erst das 3. intakte und plausible Telegramm in Folge wieder übernommen. Durch diese Prüfung kann eine zusätzliche, durch die Wahl des Grenzwertes auch quasi "einstellbare" Sicherheit besonders bei schlechtem Empfang erreicht werden.
Die zweite o.g. Prüf-Frage beinhaltet den Vergleich des aktuellen mit dem vorherigen Telegramm. Da das aktuelle Telegramm die Folgeminute des vorherigen Telegramms abbildet, kann man durch den Vergleich weitere Sicherheit gewinnen. In der Regel werden sich zwei aufeinanderfolgende Telegramme nur geringfügig (durch die Minute!) unterscheiden, d.h. sie sind hoch redundant. Bei Überträgen (z.B. am Monats- oder Jahresende) wird der Anteil redundanter Informationen jedoch deutlich geringer sein. Dies gilt auch bei MEZ-MESZ-Wechseln und bei Schaltjahren (am 29.2.!). Die Prüfung kann in Decodern recht unterschiedlich oder gar nicht umgesetzt werden. Im hier beschriebenen DCF-Decoder wird diese Prüfung nicht durchgeführt.
... WIRD FORTGESETZT!!! ...
--Dirk 12:41, 9. Dez 2006 (CET)
