DCF77

Ein "Wetterbericht" wird aus drei Einzelübertragungen zusammengesetzt. Um herauszufinden, welcher der drei benötigten Datensätze derzeit übertragen wird, nimmt man die aktuelle Uhrzeit zur Hilfe. Hier wird auf den Wert der Minute eine Modulooperation (Restwertdivision) mit 3 durchgeführt. Das Ergebnis ist 0, 1 oder 2. ist es 0, ist es der Erste usw.

Zwischenzeitlich gab es Tests zur Bevölkerungswarnung über eben jene 14 Bit. Um nun die Wetterdaten von den Daten zur Bevölkerungswarnung zu unterscheiden, werden Bit 0 und Bit 7 des ersten Datensatzes bei den Wetterdaten immer mit 0 übertragen. Da die Bevölkerungswarnung jedoch nie über das Teststadium hinaus gekommen ist, gibt es kaum Dokumentation über den Protokollaufbau. Meine Software unterstützt daher die Dekodierung der Warnung nicht.

Und weiter?

Nachdem die drei Datensätze empfangen wurden, werden vom ersten Datensatz Bit 0 und Bit 7 entfernt. Die werden für die weitere Bearbeitung nicht benötigt. Daraus ergeben sich 12 + 14 + 14 = 40 Bit (5 Byte). Der HKW581 benötigt hier aber dennoch im Datensatz die entfernten "Füllbits", diese werden allerdings vom Decoder selbst verworfen.

Diese 40 Bit sind mit einem DES ähnlichem System verschlüsselt und müssen nun durch einen Dekoder, z.B. dem HKW581 von HKW Elektronik (einer der Mitbegründer der Meteotime GmbH) entschlüsselt werden. Der Schlüssel für die Daten wird aus der Uhrzeit generiert, die zum Zeitpunkt des letzten Datenbits gültig war.

HKW581 an FTDI232

Der von mir am Server verwendete Wetterdatendekoder ist eine Eigenentwicklung

Als nächstes werden diese 80 + 2 Bit an den Dekoder gesendet (mit Bit 0 und Bit 7 als Füllbit). Die Übertragung erfolgt synchron seriell. Nach einiger Rechenzeit invertiert der Decoder den Taktausgang um zu signalisieren, dass der Vorgang abgeschlossen ist. Die Daten können nun ebenfalls synchron seriell aus dem Dekoder entnommen werden. Ausgegeben werden 22 Bit Daten und 2 Bit Status.

Klartext

Aus dem Dekoder gibt es direkt den benötigten Klartext. Die letzten 2 Bit geben den Status der Entschlüsselung an. Sind diese beide 0, ist die Entschlüsselung fehlgeschlagen. In den verschlüsselten Daten ist vermutlich eine Prüfsumme enthalten, welche nach der Entschlüsselung übereinstimmen muss, ist das nicht der Fall, z.B. durch ein Bitfehler in den Eingangsdaten, gibt der Dekoder einen Fehler (100000000000000000000100) aus. Ist die Entschlüsselung erfolgreich verlaufen, sind die letzten beiden Bits auf 10 festgelegt.

Die einzelnen Wetterdatensätze, 480 am Tag, werden einzelnen Regionen zugeordnet. Die Übertragung beginnt nach 24 Stunden um 22 Uhr UTC mit Region 0 erneut. Insgesamt werden 90 Regionen in Europa mit Wetterdaten versorgt. Davon 60 mit 4 Tagen Vorhersage und 30 mit zwei Tagen Vorhersage. Daraus ergibt sich folgende Reihenfolge:

Start um 22 Uhr UTC mit
Region 0 - 59 Höchstwerte 1. Tag (Heute)
Region 0 - 59 Tiefstwerte 1. Tag (Heute)
Region 0 - 59 Höchstwerte 2. Tag (Morgen)
Region 0 - 59 Tiefstwerte 2. Tag (Morgen)
Region 0 - 59 Höchstwerte 3. Tag
Region 0 - 59 Tiefstwerte 3. Tag
Region 0 - 59 Höchstwerte 4. Tag
Region 0 - 59 Wetteranomalien und Winddaten für den 4. Tag,
Da keine Tiefstwerte für den 4. Tag übertragen werden, nutzt man die freiwerdenden Kapazitäten für
Region 60 - 89 Höchstwerte 1. Tag
Region 60 - 89 Höchstwerte 2. Tag

Zu Beachten ist dabei, dass in den letzten 60 übertragenen Datensätzen die Daten für zwei jeweils Regionen übertragen werden.

Auf das genaue Kodierschema möchte ich an dieser Stelle nicht weiter eingehen. Dieses kann anhand genügender Beispiele in den Logdateien eingesehen werden.