mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR: Wetterinformationen über DCF77


Autor: Tobias Schilgen (informatiker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

soeben lese ich bei www.elv.de, dass seit November 2006 über das 
DCF-Signal auch Wetterinformationen gesendet werden sollen (siehe dazu 
auch 
http://shop.elv.de/output/controller.aspx?cid=74&d...).

Hat jemand davon gehört und weiß mehr über das Datenformat der 
Wetterinformationen? Da ich einen DCF77-Empfänger auf AVR-Basis bereits 
realisiert habe, möchte ich diesen ggf. entsprechend erweitern.

Tobias.

Autor: einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke das Zusatzsignal wird nicht leicht zu entschlüsseln sein...
"- Empfängsgeräte mit der Meteotime Technologie können die Daten 
empfangen und entschlüsseln (siehe PRODUCTS)."

Zu finden hier : http://www.meteotime.com/web/c1-200_c2-1185.aspx


Autor: Hartmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das verwendete Protokoll wäre sehr interessant...

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hört sich interessant an, was mir aber in dem Dokument von  Christoph 
Kessler schon wieder aufstösst ist dieser Satz:

[Zitat]
Die übertragenen Daten können nur mit der über den Lizenzvertrag 
beschaffbaren Dechiffriervarianten geprüft und für die Auswertung bzw. 
Anzeige nutzbar gemacht werden.
[/Zitat]

Weiss da schon jemand genaueres ob die Daten überhaupt nicht nutzbar 
sind, oder nur "schwer zugänglich" sind?

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Satz hatte ich noch gesucht, schade dann müssen wir warten, bis 
jemand das ganz rückwärts engineered hat...
Ich habe das Dokument auch nur durch rumgooglen gefunden und weiß nichts 
näheres.

Autor: Matti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael S.

Lies das Dokument von hkw-elektronik doch mal zuende!

Das steht exakt, welche Info in welchem Bit steht, welche Regionen es 
gibt etc. etc.

Mehr braucht man meiner Meinung nach nicht.

Gruss, Matti

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die 
Bit-Numerierung in der Rosette des DCF-Protokolls."
Die sind vermutlich irgendwie verscrambled, dazu braucht man noch einen 
Schlüssel

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das gilt es, herauszufinden :-), bei Gelegenheit logge ich die Bits mal 
und gucke nach Regelmäßigkeiten ;-) Lange bleibt das doch sowieso nicht 
geheim und den Schlüssel ändern können sie nicht, weil dann die auf den 
Markt geworfenen Geräte nicht mehr funktionieren.

Autor: The Slow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das steht exakt, welche Info in welchem Bit steht, welche Regionen es
> gibt etc. etc.

Da steht nur fast alles, aber
1. laut PTB ist das Signal in den bits 1-14 Ampplitudenmoduliert und 
nicht wie das Zeitsignal Phasenmoduliert

2. fehlt die Information wann die Wetterdaten für eine bestimmte Region 
gesendet werden

3. sind die Daten chiffriert und die genannten Bitpositionen beziehen 
sich auf das dechiffrierte Signal

eigentlich schade

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch ELV hat da wohl "noch" nichts eigenes. Die Wetterstation welche ELV 
vertreibt ist ein reseller Artikel von http://www.irox.ch

@Matti:
Das Dokument habe ich gelesen, aber mir erschliesst sich daraus keine 
Möglichkeit die Daten im Datenwort zu dekodieren. Aber vielleicht hab 
ich noch was anderes überlesen, was du gelesen hast...

@Christoph Kessler:
Da sich Meteotime bei PTB anscheind eingekauft hat und da wohl was 
Vertraglich bis 2013 geregelt ist, wären die schön blöd das "jederman" 
so einfach zur Verfügung zu stellen.

Aber wie schon gesagt, ich hab mich mit der Materie auch noch nicht so 
sehr beschäftigt... kann mich also auch Irren!

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mist, The Slow war schneller... ;)

Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

Rein von der Logik her sind die Daten nur schwer zugänglich. Da alle 
Empfänger auf die gleichen Daten zugreifen, kann keine richtige 
Verschlüsselung mit individuellen Passwörtern oder sowas verwendet 
werden. Das einfachste ist wohl, wenn jemand die Bits mitschreiben würde 
und sich dazu die dekodierten Informationen auf so einer Wetterstation 
anschaut.

Aber das ist auf alle Fälle eine interessante Sache. Da sollte wir dran 
bleiben.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man die Wetterstation von elv irgendwo anzapfen, um den 
dechiffrierten Datenstrom abzugreifen?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was willste damit, wenn Du die Zuordnung nicht weißt? Die 
Reihenfolge des dechiffrierten Stromes muß doch nicht der in der 
Beschreibung entsprechen. Außerdem werden die Daten wohl nicht den 
Custom-Chip verlassen, der in der Wetterstation sitzt, bevor sie auf die 
Anzeige gelangen...

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ich nehme auch an, da geht ein Bit in den Controller rein und eine 
gemultiplexter LCD-Pixelgrafik raus. Bei 14 Bit pro Minute muß der 
Rückwärts-Ingenieur viiiiel Geduld haben.

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm, da scheint sich jemand richtig gedanken über die chiffrierung 
gemacht zu haben. Es gibt einen "ASIC" (Ich Tipp auf uC oder PLD) von 
der Firma Meteo Time GmbH, ebenfalls CH, welcher den Datenstrom 
dekodiert!

http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf

Leider hab ich bei Meteo Time selbst noch nichts über den IC in 
Erfahrunge bringen können.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die Steuerung und das binäre Datenformat übernehmen Sie bitte dem 
Manuel des Lizenzvertrages"
Muß man den Manuel zum Entnehmen öffnen? Wird man dafür in der Schweiz 
nicht lebenslang verknurrt ?
"Lizenzstufen 1 bis 3"  das auch noch?

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, man muß wohl einen Dekodierchip kaufen, da schiebt man die 
kodierten Daten rein, dann kommen da die Klardaten raus.
http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf
Die Datenbeschreibung in dem anderen HKW-PDF bezieht sich
wohl auf das, was aus dem IC herauskommt.
Aufgrund der geringen Datendichte kann die Verschlüsselung
nicht sehr stark sein, wahrscheinlich gerade ausreichend,
um Anbieter unlizensierter Dekoder verklagen zu können.

Gruss
Jadeclaw.

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du sagst es, 1-Wire ist auch simple and stupid, aber leider mit nem 
Patent belegt...

Aber, warten wir mal ab, is ja auch noch nicht so alt die "Neuerung" auf 
77,5kHz!

Autor: Schlebinski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sollte doch möglich sein, solch einen IC auszuquetschen bis man die 
Verschlüsselung hat. Das sollte doch vollautomatisch mit nem relativ 
einfachen Programm gehen?!

Gruß,
Christian

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schlebinski:

mach ma; fg

vermtl. nur bedingt legal, asserdem wenn da dementsprechende Algorythmen 
dahinter stecken, schiebst du vorne 100mal 001001010 rein und bekommst 
hinten 100mal was anderes raus! ;-)

Autor: Frank (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Interessante Entwicklung. Ich dachte bisher, das die ersten 14 Bit vom 
Bundesamt für Zivilschutz zur Bevölkerungswarnung "gebucht" wurden oder 
werden sollten (s.Anhang). Aber das war dann wohl nix.

Autor: balu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also wie ich das "verschlüsseln" würde

is aber nur nene 1. gedanke

ich habe einen konfigurierbaren inverter
ich habe eine satz maskierungsbits mit welchen ich den inverter 
kofiguriere
welche maskierungsbits ich verwende mahce ich von der Kalenderwoche 
abhängig.

ergo ich greife mir 16 bit aus meinem nutzdatenstrom vernegiere das mit 
meinen der kalenderwoche netsprechnden maske und so musst du jede woche 
neu den passenden code raussuchen.  bullshit für alle weil es sich 
momentan nicht vorhersehbar ändere

mein derzeitiger speicherbedarf für die nächsten 10j

54*10*16bit~ 1kbyte

wenn ich dann noch zusätzliche dinge einbastel und beim durchschieben 
keine beshcleunigung zulasse (es geht eben nur 1 byte pro minute) dann 
könnte das länger dauern

da bräuchten alle die mit machen einen 2. empfänger für den aktuellen 
code

is aber nur ne idee vom klo  in ca 2 min ausgeschissen   erstmal guggen 
interessiert wäre ich auch

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sach ma balu, das mit dem "hinten rauskommen" war aber net so wörtliche 
gemeint...

Autor: balu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
doch die  idee ist von diesem ort   dort hat man die besten gedanken an 
manchen tagen

Autor: Rene Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube hier helfen die ganzen Vermutungen nicht weiter. Mindestens 
einer muß eine Empfängerschaltung aufbauen und die Daten über einen 
längeren Zeitraum aufzeichnen. Vieleicht bekommen wir ja ein paar Leute 
zusammen die das Projekt in Angriff nehmen. Wenn sich das ganze als 
nicht machbar herausstellt kann man immer noch aufhören. Wir haben es 
dann aber wenigstens probiert.

Zitat: "Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die
Bit-Numerierung in der Rosette des DCF-Protokolls. Die sind vermutlich 
irgendwie verscrambled, dazu braucht man noch einen Schlüssel."

Natürlich beziehen sich die Wetterbits nicht auf die Bits der Rosette, 
sondern aus 3 min werden jeweils 15 bit genommen und zu den Wetterbits 
zusammengesetzt. Warscheinlich ist hinten dran noch eine Checksumme. Ob 
die ganze Sache verschlüsselt ist wird man sehen wenn man den Empfänger 
fertig in Betrieb hat und die Wettervorhersage unsinnige Werte liefert.

Also lasst uns einen Empfänger bauen und dann weiter schauen.

Gruß Rene

Autor: Rene Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Zitat: "Die Genauigkeit und Stabilität der Trägerschwingung sowie die 
Parameter der Modulationen wurden unverändert belassen."

Habe ich doch glatt übersehen, also ist kein neuer Empfänger nötig.

Gruß Rene

Autor: Rene Zimmermann (renezimmermann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, kein neuer Empfänger! Die alten gehen vorzüglich. Ich habe gerade 
eine neue Funkuhr gebastelt, da kann man die Bits ´reinwabbeln sehen. 
Ich habe auch noch ein Reichelt-DCF-Modul liegen, das klatsch ich mal an 
einen Controller und hänge ein EEPROM dran und lasse es ein paar Tage 
daddeln. Die Daten schicke ich dann hier als TXT. Ich mache mir 
allerdings Gedanken über Falschbits bei Empfangsstörungen - das müssen 
die ja auch irgendwie kontrollierbar machen...?

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rene:
Ich stimme dir da zu, ich werde heute Abend mal ein wenig auf der 
77,5Khz "reinhören" und schauen ob sich in den abgesprochenen Bit's was 
getan hat.

The Slow hat mal zu Anfangs bemerkt:
> 1. laut PTB ist das Signal in den bits 1-14 Ampplitudenmoduliert und
> nicht wie das Zeitsignal Phasenmoduliert.

Hab den Parsus grad auch bei ptb.de gefunden.
> Die Steuereinrichtungen wurden so gestaltet, dass die Dateninhalte,
> die während der Sekunden 1 bis 14 amplitudenmoduliert übertragen werden,
> von dritter Seite beigestellt werden können.

Wenn das so ist, bekommst du diese Information nur mit einem geeigneten 
Empfänger mit. Klar, wenn die restlichen Bits, die das Zeitsignal 
übertragen gleichgeblieben sind, ändert sich für zig tausend Uhren 
nichts, aber das MeteoTime Daten bekommst du nicht mit...

Schauen wir mal was der Abend/Nacht bringen wird!


Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Am einfachsten ist es wahrscheinlich den Dekoder Chip zu kaufen und 
diesen
mit kopierten Datenströmen zu füttern. Wäre überhaupt interessant was 
dieser Chip kostet, vielleicht zahlt sich das ganze reverse Engineering 
gar nicht aus.

<
Ich mache mir
allerdings Gedanken über Falschbits bei Empfangsstörungen - das müssen
die ja auch irgendwie kontrollierbar machen...?
>

Ich nehme an das es eine Checksumme gibt.

LG
Michael

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DCF77 ist doch immer amplitudenmoduliert. Die unterschiedich langen 
Impulse bestehen aus einer Amplitudenreduzierung, das ist AM.

PS: passus (lat.) der Schritt, nicht Parsus wie parser

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Dekoderchip z.B. < 2 EUR kostet wäre ich bereit dies so zu tun. 
Da ich aber im Datenblatt zu selbigem IC schon wieder was über 
Lizensstufen und Lizensvertrag lese, wird das wohl eher nicht der Fall 
sein.

> Dechiffrier- IC zum Lesen der Meteotime Wetterdaten für die Lizenzstufen
> 1 bis 3. Die Steuerung und das binäre Datenformat übernehmen Sie bitte
> dem Manuel des Lizenzvertrages.

@Christoph Kessler:
öhm, hat recht, mit beidem... Nur komisch das PTB die Bits 1...14 anders 
beschreibt als die darüber. Und wegen Passus, ich hatte kein lat. 
ausredesuch

PS: Bist du eigentlich der mit dem Blechdosenrecycling?!?

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jaja, die Weihnachts-Keksdose als 900MHz-Resonator hab ich hier irgendwo 
schon mal gezeigt.

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habs in der CQ-DL 04/06 gesehen/gelesen.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da wars, unter "Ingenieurskunst":
Beitrag "Re: Ingenieurskunst"

Autor: for_ro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe auch heute nacht um 0.00 Uhr den Datenlogger gestartet.
Ich dachte mir, den Logger 48 Stunden laufen zu lassen und dann die 
beiden Tage zu vergleichen. Vom ersten ansehen denke ich schon, dass 
zumindestens das 14. bit eine Checksumme ist.
Ich stelle den File auch hier ein. Dann können wir die Ergebnisse 
vergleichen und zumindest Empfangsfehler von einzelnen korrigieren.

Da es z.Zt. 90 Regionen gibt, für die 4 mal täglich Informationen kommen 
und diese jeweils 3 Minuten beanspruchen, ergibt sich hieraus schon 1080 
Sendeminuten pro Tag. Der Rest bis 1440 ist bestimmt noch für 
Erweiterungen der Regionen reserviert. Jede Bit-Info besteht aus max. 42 
bit, von denen noch die Checksummen abzuziehen sind. Da es hier um 
wichtigere Infos geht, könnte ich mir auch vorstellen, dass die sich 
nicht mit Fehlererkennung zufrieden gegeben haben, sondern 
Fehlerkorrektur installiert haben.
Vermutlich bleiben die Minuten, die jeweils für eine Region benutzt 
werden, über alle Tage gleich. Dann können wir die Änderungen von einem 
Tag zum anderen für eine Region leicht sehen.
Was ich für unbedingt nötig halte ist ein funktionierender Empfänger, 
der die empfangenen und geloggten Daten im Display anzeigt. Dann könnte 
es uns gelingen, die Daten zu dechiffrieren. Ansonsten ist das wohl 
schwierig.

Gruß

Rolf

Autor: B. Jue (bjue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
ich habe mal bei meteotime angefragt, ob es den Chip zu kaufen gibt, 
hier die Antwort:
"Nein, der Chip ist als einzelteil nicht käuflich. Wir beliefern nur die 
herstellende Industrie.
Wir haben aber Kunden, die an einer Modul-Lösung mit definierter 
Schnittstelle arbeiten und diese dann an Einzelanwender anbieten werden. 
Ob diese Module noch dieses Jahr erhältlich sein werden
wissen wir aber nicht."

Gruß
Bernd

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bernd:
sowas ähnliches habe ich mir schon gedacht...

Evtl. kann mal jemand über die "Industrie" versuchen an Muster 
ranzukommen. Aber wenn da keine Stückzahlen >1000 glaubhaft 
dahintersteht, denke ich wird man da auf Granit beissen.

Haben sie was über die Lizensen gesagt? Was die kosten würden und/oder 
wie man die bekommt?

Gruß Micha,

Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd

Aus dieser Mail geht meiner Meinung nach folgendes klar hervor:

1. Meteotime war so gescheit die ersten 14Bit vom Dcf77 Signal zu kaufen
2. Meteotime will maximal abcashen
3. Meteotime behält sich vor sollte es nicht so laufen wie vorgestellt,
   noch einen abcash Versuch mittels Modulen über Hintermänner zu
   starten
4. Meteotime kann mich mal...

LG
Michael

Autor: Rolf Im forum (for_ro)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
hier mal der log (100K) vom 1.2.2007 00:00:00 bis 2.2.2007 23:59.
Checksum habe ich noch nicht wirklich entdeckt.
Wenn ich Parity Fehler dahinter geschrieben habe, dann war in der 
Zeitinformation ein Fehler, der Zeile würde ich also nicht unbedingt 
vertrauen.
Vielleicht hat ja jemand Zeit und Lust daran etwas rumzuknobeln.

Gruß

Rolf

Autor: Konrad (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Beiliegend noch ein Auszug aus 
http://www.metas.ch/de/metINFO/2006/METinfo_3_06.pdf

Mit Informationen zu Meteotime. Hilft aber bei der Decodierung auch 
nicht weiter.

Gruss Konrad

Autor: Robert Weber (rweber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann man ja das Wetter von www.meteotest.ch mit den Signalen 
vergleichen?

Markus

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@for_ro:

tnx für die Aufzeichnung!

Also nachdem ich mir die Daten nun mal durchgesehen habe und en Kollege 
mit ein wenig heuristik-algorythmen darüber hergefallen ist, bin ich im 
Moment der Meinung: --> Chaos!

In dem Dokument das Konrad gepostet hat, steht nochmals drin, das die 
Wetterdaten Zeitbezogen sein können.

for_ro, ich hab nicht die möglichkeit die Daten des Zeitzeichensenders 
so lange so aufzuzeichnen, aber könntest du das ganze nochmal incl. der 
Zeitzeichens machen? Also alle 59Bits?

Würde evtl. noch weiterhelfen...

Gruß Micha,

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Ganze hier aufmerksam mitgelesen, DCF interessiert mich 
immer.

Dann darf ich mal eine Bemerkung am Rande loswerden. ELV propagiert die 
Übertragung von Wetterdaten in den bisher "ungenutzten" Bits am Anfang 
des Telegramms. Ich habe hier 2 ELV-PC-DCF-Funkuhren (die auch die Daten 
von ELV-Wettersensoren empfangen) und wundere mich seit einem viertel 
Jahr, dass ich keine Uhrzeit mehr empfange. Nach einigem Email-Verkehr 
mit ELV habe ich die Module zur Überprüfung eingeschickt. Vor ein paar 
Tagen habe ich sie zurückbekommen.

"Aufgrund der Umstellung des DCF-Signals ist diese Uhr nicht mehr in der 
Lage, die Uhrzeit auszuwerten."

Zu gut deutsch: die Software des Controllers ist fehlerhaft und kommt 
mit der Nutzung der unteren Bits nicht klar (die Software hatte übrigens 
auch jedes mal bei der Zeitumstellung Probleme). Einfach nur peinlich 
(und ärgerlich), oder? Da werde ich wohl den verwendeten Prozessor 
"abkratzen" und einen kleinen AVR dran setzen. Ich frage mich 
allerdings, ob ich der Einzige bin, der eine solche Uhr (noch) nutzt 
(das Teil ist von 1997). Übrigens arbeiten alle meine anderen Funkuhren 
(gekaufte von Junghans bis Aldi und selbstgebaute und programmierte) 
absolut problemlos.

Also, viel Erfolg beim Nutzen der Wetterdaten, für mich bedeutet die 
Umstellung nun aber ersteinmal neue Arbeit.

Jörg

Autor: Rolf Im forum (for_ro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha,
meinst du wieder für 2 Tage?
Ich kann den heute Nacht um 0.00 Uhr starten und dann beliebig lange.

Gruß

Rolf

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg: Ich habe, so wie es scheint, ein ähnliches Problem.
Meine Auerswald DCF77 verliert nach ca. 30min die Synchronisation und 
synchronisiert dann nicht mehr. Am Empfänger liegts nicht, aus- und 
wieder einstöpseln desselben hat keinen Effekt, Nach Aus- und 
Einschalten der Uhr läuft die Synchronisation wieder korrekt durch. 
Defektzeitpunkt und Meteotime-Aufschaltung passen hier auch zusammen. Da 
ist dann wohl auch ein neuer Controller fällig. Oder ein kleiner ATTiny, 
der die Meteotime-Bits aus dem DCF-Signal entfernt. Die ELV-Uhr scheint 
sich wohl darauf zu verlassen, daß die Bits 1-14 über längere Zeit 
gleich bleiben und benutzt für die Redundanzprüfung dann alle 58 Bits. 
Die Lösung, die Bits 1-14 dauerhaft auf 0 zu setzen, könnte hier etwas 
Arbeit ersparen (z.B. die Sensorauswertung neu zu stricken).

Gruss
Jadeclaw.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab auch was zu dem Thema.

http://shop.elv.de/output/controller.aspx?cid=74&d...

Gruß Jörg

Autor: Herbert Bernardini (bernardini)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg

Kennen wir schon danke.
Aber ich zahl doch nicht 280 Euro für ein Grafikdisplay,
das DCF Daten auswertet und anzeigt. 80 und ich hätte es schon 
gekauft,...

LG
Michael

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg, jadeclaw:

Da bin ich mal gespannt, ich hab hier im Umfeld auch einige DFC77 
Empfänger die meinem support unterstehen, welche zumindest bis jetzt 
aufholzklopf keine Probleme machen...

Jörg, hast du den eMail Verkehr mit ELV noch verfügbar? Oder anders 
gefragt, was für einen Typ PC-Uhr war das? Ich hab hier auch noch solche 
"Dongles" für den Game-Port, muss ich heute Abend mal intressehalber 
anwerfen!

Vielleicht sollte man mal mit dem Problem an PTB herantreten. Denn 
immerhin sind das zwar bis jetzt nur kleinigkeiten, aber viele merken es 
evtl. garnicht das ihre Uhr nicht mehr Zeitsignal-Synchron läuft. Denn 
die meisten (mein Funkwecker inklusive) schalten einfach auf internen 
Clock um und laufen "falsch" weiter!

@for_ro:
Ja, einfach nochmal aufzeichnen, 1 oder 2 tage sollte mal für den Anfang 
wieder reichen. Aber mit der zeitinformation dabei. Also alle 59 Bits! 
Das wäre Klasse!

Gruß Micha,



PS: Meine Funkwetterstation mit DCF77 Empfänger zeigt -gerade 
aufgefallen- das Antennesymbol auch nicht mehr an. Muss ich mal heute 
Abend genauer untersuchen!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gestern abend gab es scheinbar für einige Minuten ein Empfangsproblem, 
die DCF-LED flackerte nur wild herum oder blieb für einige Minuten ganz 
aus. Etwas später rappelte sich der Empfang wieder und alles lief sauber 
weiter.

Zu dem Problem mit manchen Funkuhren kann ich nur sagen, daß früher die 
Bits 0 bis 14 halt einfach nur "0" waren. Wahrscheinlich kommen diese 
Uhren in der Parität oder einfach beim Zählen durcheinander, weil jetzt 
hin und wieder "1"en dazwischen sind. Eine Ausnullung der ersten 14 oder 
gar 20 Bits mittels eines kleinen "Zwischeninterpreters" sollte dieses 
Problem beseitigen. Meine Eigenbauuhren ignorieren die ersten 20 Bits, 
weil die bei dem Empfang eines Zeittelegramms sowieso über sind. Somit 
machen Empfangsfehler in dem Bereich das Telegramm auch nicht jedes Mal 
kaputt. Ich frage mich jetzt allerdings, wer für den Schaden aufkommt, 
der bei älteren Industrie- oder Kirchturmuhren durch die 
Protokollumstellung entsteht... Ganz zu schweigen von der Luftfahrt und 
Navigation...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Travel Rec.

>kaputt. Ich frage mich jetzt allerdings, wer für den Schaden aufkommt,
>der bei älteren Industrie- oder Kirchturmuhren durch die
>Protokollumstellung entsteht... Ganz zu schweigen von der Luftfahrt und
>Navigation...

Was für eine Protokollumstelleung? Die Paritätsbits haben immer nur die 
Zeit und Datumsbits abgedeckt. Bits 1..14 waren immer schon "dont care".

MfG
Falk

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sag mal den älteren Uhren. Irgenwas müssen die ja mit den Nullen 
gemacht haben. Daß die "Parität" sich nur auf das eigentliche 
Zeittelegramm bezieht, ist mir auch klar ;-)

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Travel Rec.

>Das sag mal den älteren Uhren. Irgenwas müssen die ja mit den Nullen
>gemacht haben. Daß die "Parität" sich nur auf das eigentliche

Wer solchen Murks programmiert muss ihn auch auf eigene Kosten updaten.
Oder er ist clever und macht einen Hype ala Y2K draus ;-)

MfG
Falk

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau! Der (völlig unbeabsichtigte) DCF-Uhren Bug ;-)

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man weiß, wann die "defekte" Uhr den Sender abfragt, könnte man ja 
um diesen Zeitpunkt herum einen eigenen DCF77-Sender neben der Uhr 
einschalten, der die korrigierten Impulse abstrahlt. Besonders geschickt 
wäre, auch die Langwellen frequenz im Controller zu erzeugen und zu 
modulieren.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Funkwecker ist 2x Abgestürzt diese Woche.  Nicht das das was damit 
zu tun hat...  panikmodus ein

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian:

Meiner "stürzt" täglich mehrmals nacheinander ab... Meist so zwischen 5 
und 5:15Uhr... aber ich denke nicht, das es was mit der Umstellung des 
DCF77 Signals zu tun hat! ;)

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Standardquarze direkt zum Runterteilen auf 77,5 kHz gibts anscheinend 
nicht
11M / 142 = 77,46k das trifft schon ganz gut
11,0592M / 143 = 77,33k
12M / 155 = 77,42k
na es läßt sich was finden, gerader Teilfaktor wäre praktischer, also 11 
MHz schon mal ein Kandidat.

Autor: Martin Kreiner (maart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die ELV-Uhren hat nicht zufälligerweise Micros*** programmiert? ;-)

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael S. (mst)

Die von mir angesprochenen PC-DCF-Funk-Empfänger sind die kombinierten 
mit DCF-Empfang und Funk-Wettersensor (AS2000 u.ä.). Gab es vor ein paar 
Jahren mal recht preiswert. "Dongle"-Empfänger liefern nur die einzelnen 
DCF-Impulse an den PC und eine Software auf dem PC liest diese dann ein 
und auswertet sie aus. Hier könnte natürlich auch hier die PC-Software 
Probleme machen.

Den Email-Verkehr mit ELV habe ich natürlich noch (allerdings zuhause). 
Großartige details kann man da (zumindest von Seiten ELV) nicht 
entnehmen. Ich habe uach lange gebraucht, um den Ausfall mit diesen 
Wetterdaten in Zusammenhang zu bringen, da waren die Module bereits bei 
ELV zur Überprüfung.

Die Idee mit dem zwischengeschalteten Controller ist gar nicht so dumm. 
Allerdings hat mich in der Vergangenheit das einfache 
"Übertragungsprotokoll" für das Auslesen mit dem PC gestört, und das 
wäre nun ein Anlass, das Ganze mal auf eine ordentliche Abfrage per 
RS232/UART umzustellen. Bisher ging das ja mit BitBanging und das läuft 
unter Win2k und aufwärts wahrscheinlich eh nicht mehr (habs noch nicht 
versucht). Tipps für die Wettersensordaten habe ich schon gefunden. 
Jetzt fehlt nur noch die nötige Zeit.

Jörg

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die "Zwischenschaltung" nach meinem Vorschlag wäre drahtlos. Ein 
DCF-Modul und ein 8-Pinner würde reichen, 11 MHz Takt, der Timer teilt 
das auf 77,5 herunter, ein Spannungsteiler am Ausgang wird von einem 
zweiten Portpin als "open collector" beschaltet im Sekundentakt nach 
Masse gezogen und damit der Ausgangspegel reduziert. Ein dritter Portpin 
ist der Eingang des DCF-Moduls. Zur vollen Stunde geht das auf Sendung 
und mit ein paar Drahtwindungen über die fehlerhafte Uhr wird die mit 
korrigierter DCF-Zeit bedient.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochn Vorschlag, besonders simpel: TTL-Doppel-Monoflop 74xx221, eines 
detektiert den fehlenden 59-Sekunden-Impuls, das andere nullt die 
nächsten 14 oder 20 Bit.

Autor: Schubser_vom_Dienst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schubs!

Bitte lasst diesen Thread nicht verhungern. Ich bin zwar zu dusselig um 
Substanzielles beitragen zu können, doch interessieren tut's mich 
brennend!

;-))

Autor: Philipp Sªsse (philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon lustig: da meckert man über heuristische Programmierungen, die 
sich den damals aktuellen Signalstand für Vereinfachungen zunutze 
gemacht haben (die nun nicht mehr gelten) und will im gleichen Atemzug 
durch Beobachtung den Code knacken, als ob damit nicht genau dasselbe 
passieren würde.

Wenn die einen Baustein verkaufen, der jahrzehntelang funktionieren muß, 
aber der Code knack-gefährdet ist, werden die sich sicherlich nicht 
allein auf "security by obscurity" verlassen. Ein Ex-Mitarbeiter, der 
das Verfahren postet und schon kann jeder Bastler das Signal decodieren? 
Nie!

Die Decodierung selbst wird auch wieder per "fernwartung" 
umprogrammierbar sein; alles andere wäre verrückt. Sobald also das 
reverse-engineering beendet ist, wird der nächste Level des Hackerspiels 
aktiviert ...

Irgendwie ist es ja auch weniger Aufwand, einen PC eine Wetterwebsite 
parsen und die Signale selbst senden zu lassen. Also wenn das hier nicht 
als sportliche Herausforderung verstanden wird, den bösen Leuten, die 
hier ein Geschäftsmodell aufbauen wollen, mal zu zeigen, wo der Hammer 
hängt ... würde ich es einfach bleiben lassen!

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ich warte grad mal auf das Log von Rolf Im forum (for_ro), damit ich 
nächste Woche im G'schäft wieder was zu tun hab! :-)

@Philipp Sªsse (philipp):
Wir sind doch hier freischaffenden Künstler, da brauchen wir über Sinn 
und Unsinn nicht nachdenken! Würde jeder so denken, "einfach bleiben 
lassen", dann bleibt das eigene geistige Know-How doch auf der Strecke. 
Selbst wenn sich nur ein Frame decodieren liesse und sie dann den 
Algorythmus ändern, hat es sich meines erachtens nach schon für "mich" 
gelohnt...

Aber ich wäre Vorsichtig mit dem zugeben und posten eines "ich habe es 
Geschafft"... Die rechtliche Lage müsste man hier erst einmal genauer 
untersuchen lassen!

Aber zu den Empfangsproblemen noch was: Ist wohl wirklich so, meine 
Wetterstation scheint da auch irgendwie ihre Probleme zu haben. Hatte 
heute ich mal die Batterien ruas und nach dem wieder einlegen, wurde die 
Uhrzeit zwar nach ein paar Minuten empfangen und auch angezeigt, aber...

...das Antennesymbol blinkt erst, wird dann dauernd angezeigt und 
verschwindet dann nach ca. 30-60min ganz. Seither blinkte es zu beginn, 
dann blieb es statisch angezeigt für normalen Empfang...

Naja, Hauptsache sie Empfängt einmal die Zeit, das Teil hätte keine 
Tasten mit denen man die Uhrzeit stellen könnte! :-)

Gruß Micha,

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Sªsse wrote:
> Wenn die einen Baustein verkaufen, der jahrzehntelang funktionieren muß,
> aber der Code knack-gefährdet ist, werden die sich sicherlich nicht
> allein auf "security by obscurity" verlassen. Ein Ex-Mitarbeiter, der
> das Verfahren postet und schon kann jeder Bastler das Signal decodieren?
> Nie!

Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr 
wenige Mitarbeiter kennen.

> Die Decodierung selbst wird auch wieder per "fernwartung"
> umprogrammierbar sein; alles andere wäre verrückt. Sobald also das
> reverse-engineering beendet ist, wird der nächste Level des Hackerspiels
> aktiviert ...

Das Update ist entweder verschlüsselt oder unverschlüsselt. Wenn es 
unverschlüsselt ist, dann bringt es nicht viel. Wenn es verschlüsselt 
ist, dann kann der Mitarbeiter, der die normale Verschlüsselung verrät, 
ja auch gleich diese Verschlüsselung verraten -> Ich kann hier also 
keinen Vorteil erkennen.

Außerdem sind Updates ja auch nicht ohne Risiko. Wenn das Update 
schiefgeht, dann produzierst Du damit ja einen Garantiefall. Außerdem 
gibt es ja Empfänger, die das Update nicht gehört bzw. nicht vollständig 
empfangen haben, für diese musst Du dann z.B. täglich das Update 
wiederholen.

Deswegen kann ich mir nicht vorstellen, dass es ein remote Update gibt.

Markus

Autor: Rolf Im forum (for_ro)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
hier die Aufzeichnungen von 2 Tagen, mit allen Ticks.
Zur besseren Lesbarkeit habe ich einige Blanks mit einfügen lassen.
Was auffällt, ist, dass die meisten Fehler durch einen zusätzlichen Tick 
während der ersten 14 Bits kommen. Damit kommen evtl. viele Uhren nicht 
zurecht. Vielleicht rühren daher eure Fehler. Die Ticks sind allerdings 
nicht immer zur vollen Stunde, wo die meisten Batterie getriebenen Uhren 
empfangen
Man müsste sich das mal mit einem Oszi ansehen. Nur sind die leider 
recht selten.

Gruß

Rolf

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
many thanks!

Gleich mal nächste Woche drüber herfallen...

Gruß Micha,

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach übrigens wenns auch nur ein ganz simples Verschlüsselungsverfahren 
ist könnt ihr aufzeichnen soviel ihr wollt und es wird trozdem immer 
zufällig erscheinen.

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hinter jedem Chaos steckt ein System!

Gruß Micha,

PS: Ich bezweifle auch, das es auch diesem Wege machbar ist, aber 
Versuchen kann man es ja mal... aber wie ich schon scheib: Zugeben würde 
ich es nicht!

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja klar, es sieht aber aus wie Zufall das sit doch der Witz bei ner 
Verschlüsselung.
Und selbst einfache Block Kryptosysteme die leicht in Hardware zum 
implementieren gehen lassen dir keine wirkliche Chance.

Autor: Rolf Im forum (for_ro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen
lasst euch bloss nicht von diesen ewigen 
Das-bringt-doch-eh-nichts-Nörglern abhalten. In der Firma haben wir ohne 
Ende Leute, die sagen, dieses oder jenes wird nichts und die sind dabei 
noch unheimlich einfallsreich. Richtig unterstützen werden immer nur 
eine handvoll.
Es macht doch Spass, an so was rumzuknobeln. Und es ist sicherlich 
niemand in der Lage zu 100% vorherzusagen, dass es nicht geht.
Als die Jungs anfingen, das S65 Display anzuschliessen habe ich auch 
gedacht, ohne Doku kriegen die das nie hin. Und was soll ich euch sagen: 
Es klappt fantastisch.
Also machen wir weiter.
Gruß

Rolf

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alle

nach meiner Meinung könnten wir die Codierung mit etwas guten Willen
dechiffrieren.


Dazu müssten aber u.a. mehrere Randbedingungen erfüllt sein:


1. Problematik Mitschnitt:

- wir benötigen viele Mitschnitte über längere Zeiträume
   von mehreren Standorten Deutschlands (wegen Raumwelle/Bodenwelle usw)

   (Rolf sein formatierter Mitschnitt wäre als Mustervorlage
   sehr gut geeignet, Rolf, großes Lob an Dich)

- Aus den vielen Mittschnitten muss ein einziger lückenloser und
   fehlerfreier "Referenz_Mitschnitt" erstellt werden.

   Denn ein einziger "fehlerbehafteter" Mittschnitt könnte die
   Decodierung/Deciffrierung extrem erschweren.

- Die Wettervorhersagen müssten auch mit protokolliert werden,
  zur Auswertung der Daten



Bis hierhin war's noch relativ einfach, gel.......



2. Decodierung / Dechiffrierung:

- zuerst sollten wir untersuchen, in welchen Abständen, wenn Überhaupt,
  das Codierverfahren geändert wird.

  Bsp: Ändert sich das Wetter nicht (Großwetterlage), sind die 
Vorhersagen
  meistens nahezu konstant

- wir müssen hier alle gemeinsam überlegen, welche WETTERINFORMATIONEN
  jeden Tag gleich gesendet worden sein könnten


Anmerkung:

Nach meiner Meinung ist das Codiersystem / Chiffriersystem sehr 
gefährtet,

denn wir wissen, welche Vorhersageinformationen enthalten sind ....


Beispiel Erfurt:
http://www.wetter.com/v2/?SID=&LANG=DE&LOC=7000&LO...



Zum rechtlichen Aspekt:

Wir sind uns doch alle einig, das wir das dechiffrierte / decodierte 
Signal nicht nutzen wollen, wir wollen doch nur wissen wie die 
Informationen codiert worden sind. Und das kann uns doch keiner 
verbieten.

Bernhard


PS:


Schaut Euch mal die Enigma an, und wir Deutschen dachten,
diese Chiffriermaschine wäre sicher... haha

http://de.wikipedia.org/wiki/Enigma_(Maschine)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich könnte mir schon vorstellen dass das nur eine halbherzige 
Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu 
machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B. 
vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0.

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Enigma an sich war schon sicher und wäre ohne bei entsprechender 
Handhabung auch nicht geknackt worden (z.B. Aufbau der Funksprüche war 
immer gleich bzw. haben immer gleich angefangen, viele Standardmeldungen 
mit immer gleichem Aufbau, Einstellungen wurden aus 
Unwissenheit/Faulheit beibehalten etc.).
Der endgültige Durchbruch um auch die Marine-Enigmas zu entschlüsseln 
kam auch erst, als ein Codebuch sowie eine Enigma in die Hände der 
Briten fiel.

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt einerseits sehr interessant, ich höre auch das erste mal davon...

Andererseits ist mir aufgefallen das meine eigenbau Funkuhr schon seit 
längerer Zeit nicht mehr oft synchronisiert ist. (Ich sehe auf dem LCD 
wenn fehler im empfangenen sind)

Ab November könnte hinkommen...

Ich muss wohl damals davon ausgegangen sein das die bits immer 0 sind 
und so baut sich die uhr wohl öfter misst beim parity check...

werde mir das wohl mal etwas genauer ansehen müssen. Ich währe auch 
durchaus bereit irgendwie dazu beizutragen die Informationen zu 
entschlüsseln (auch wenn ich noch nicht weis wie... vlt. protokolle 
posten?)

Währe doch cool ein Nokia-Display an die Uhr zu hängen und da die 
Wettervorhersage zu sehen 8-)

Ich sollte wohl besser ins Bett gehen und da weiter träumen...

achja: abo

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz wrote:
> Ich könnte mir schon vorstellen dass das nur eine halbherzige
> Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu
> machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B.
> vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0.

Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle 
Träume über dechiffrierung sind eh nahezu dahin.

http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode

Analysieren wir doch mal euren "Angriff":
>> zuerst sollten wir untersuchen, in welchen Abständen, wenn Überhaupt,
>>  das Codierverfahren geändert wird.
Warum sollte man das ändern?? (oder meisnt du wann sich die Datenblöcke 
unterscheiden?)

>> Ändert sich das Wetter nicht (Großwetterlage), sind die
>> Vorhersagen meistens nahezu konstant
im R-CBC Mode Wird gleiches niemals zweimal gleich verschlüsselt!
(Initialisierungsvektor könnte die Zeit sein oder wird im ersten Block 
übertragen)

>> wir müssen hier alle gemeinsam überlegen, welche WETTERINFORMATIONEN
>> jeden Tag gleich gesendet worden sein könnten
Selbst wenn man EXACT wüßte welche Informationen übertragen wurden kann 
man dadurch keine Rückschlüsse auf zukünftiges machen (siehe erster 
Punkt)
(Zitat)
Der CBC-Mode hat einige wichtige Vorteile:
- Klartextmuster werden zerstört.
- Jeder Geheimtextblock hängt von allen vorherigen Klartextblöcken ab.
- Identische Klartextblöcke ergeben unterschiedliche Geheimtexte.

>> Nach meiner Meinung ist das Codiersystem / Chiffriersystem sehr
>> gefährtet,
>> denn wir wissen, welche Vorhersageinformationen enthalten sind ....
Siehe oben das ist völlig Gleichgültig.
Selbst wenn ich den ganzen Tag aaaaaaaaaaaaaa...a übertrage würde 
dadraus eine Zufällige (gleichverteilte) Buchstabenfolge.

Das ist keine Schwarzmalerei, ich wollt nur drauf hinweisen das WENN die 
das auch nur etwas klever verschlüsselt haben --> no Chance

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es denn so wäre, wie oft würden gleiche Bitfolgen (gleiche 14 
Bitblöcke) bei solch einer Verschlüsselung vorkommen? (verteilt über die 
Zeit)

Autor: Uli Huber (ulihuber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

völlig unabhänging vom sportlichen Ehrgeiz, den ich sher gut verstehen 
kann, solltet ihr ein paar Dinge überlegen:
1. Da hat sich jemand (gute) Gedanken gemacht und will damit Geld 
verdienen. Das ist nicht verwerflich und das zu torpedieren ist ehrlich 
gesagt nicht lustig.
2. Sooo wichtig ist diese Information ja eigentlich gar nicht, man 
bekommt das Wetter ungefähr zig-mal am Tag kostenlos von jeder Seite 
aufgedrängt.
3. Das Hacken verschlüsselter Informationen ist strafbar, völlig 
unabhängig von der weiteren Verwendung. Wenn tatsächlich jemand das 
trozdem wollen und schaffen sollte, täte er gut daran, das nicht in 
dieser Form zu veröffentlichen. Wenn er allerdings einen Vorschlag 
postet, wie man in 14 Bits sinnvoll Wetterinformationen verpacken kann, 
kann er den sogar GPL stellen ;-)

Wäre ja schade, hier die besten Leute einige Zeit nicht mehr 
anzutreffen, oder...?

Gruß
Uli


Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man vereinfacht davon ausgeht das unser ganzes Alphabet aus 26 
Buchstaben besteht {a, b, c, ... , x, y, z} und ich dir immer ein a 
sende (also der gnze Block besteht dann aus 14 a's) würde 1/14 = 0.07 
aller Blöcke gleich sein (in etwa) was gleich der Wahrscheinlichkeit 
entspricht das ich dir was zufälliges gesendet habe (und nicht real 
verschlüsseltes).

Das "Spiel" dazu heißt "Real or Random"

A und B spielen ein Spiel nach folgenden Regeln:
- B wählt sich zufällig ein bit b aus {0,1}
- A darf nun Anfragen an B stellen (idr beliebige Bitfolgen, belibig 
viele)
- A beantwortet diese Anfrage mit der Verschlüsselung der Anfrage wenn 
das Bit b = 0 ist, ansonsten wird ein zufälliger Bitstring gleicher 
Länge ermittelt und verschlüsselt.
- Nach beendigung der Anfragephase muß A sagen ob b = 0 oder 1 war
- Wenn A richtig liegt hat er gewonnen, sonst verloren.

Man sieht das B natürlich in 50% der Fälle gewinnt wenn er einfach 
garnix anfragt sondern einfach zufällig 1 oder 0 sagt.
Deshalb ist ein "guter" Angreifer auf ein System der welcher in diesem 
Spiel mehr als 50% aller Spiele gewinnt.

Autor: Florian Roether (florian__)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn die ganze decodierung in einem 8pinner erfolgt, kann ich 
irgendwie nicht glaube das ein zu aufwendiger 
Verschlüsselungsalgorithmus verwendet wird.

Und außerdem kennen wir ja nicht nur den verschlüsselten Datenstrom, 
sondern theoretisch auch den decodierten (wenn sich jemand den 
entsprechenden chip kaufen würde).

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also wenn die ganze decodierung in einem 8pinner erfolgt
Die Anzahl der Pins sagen da nichts aus.

Ich habe mir dcf_log_2Tage_59Ticks.txt mal angesehen. 14% der Werte fürs 
Wetter (bei 2881 Werten insgesammt) kommen nach meiner Zählung zwei oder 
mehrfach vor. Jemand mit etwas Statistik könnte mal sagen ob dies bei 
zufälligen (=verschlüsselt) Werten zu erwarten wäre oder nicht.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wenn ich so einen Chip kaufen kann... und wer sagt dir das das was 
vorne reingeht 1:1 das entschlüsseltet ist was hinten rausgeht? Könnte 
ja auch sein das einfach nen ASCII String rauskommt sobald man genügend 
gültige Daten eingespeisst hat.
Und wie ich shcon sagte das entschlüseln ist nicht sehr komplex das kann 
man mit etwas Logik recht einfach machen, das schafft selsbt nen AVR 
nebenbei, jezt nimmst du noch 100 Schlüssel die gleichverteilt gewählt 
werden entschlüsselt halt der controller das ganze 100mal, das heißt 
selsbt wenn du es schaffst einen Schlüssel zu brechen, beleiben noch 99 
weitere wo du Datenmüll erhälst.

Autor: JoachimB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir die erste mitgeschnittene Datei einmal näher angesehen.
(Werte in Excel übernommen und Pivot-Tabelle erzeugt)
Es wurden insgesamt 2880 Datensätze aufgezeichnet.
6 der 14-bit-Datensätze erscheinen 4 mal.
43 erscheinen 3 mal.
279 erscheinen 2 mal und der Rest ist nur einmal vorhanden.
Mit der Annahme, dass sich das Wetter innerhalb von zwei Tagen nicht so 
häufig ändert, scheint die Verschlüsselung etwas anspruchsvoller zu 
sein. Entweder erstreckt sich die Verschlüsselung über mehrere Blöcke 
oder aber die Zeitinformation wird geschickt einbezogen.
Eine Entschlüsselung ohne "social engeneering" erscheint mir 
aussichtslos.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie im Wiki beschrieben kann man für den CBC Mode auch ein TimeStamp 
verwenden, und bei einer Zeitübertragung ist das doch ne super 
möglichkeit :)

Autor: balu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so also ich habe mal ein bissel überschlagen
die machen für 90 regionen eine 4 tage vorschau

pro tag werden 54 bit benötigt (! nur gedanklich überschlagen kein 
belastbarer wert)

macht 19440 bit die übertragen werden müssen  hier fehlen aber 
prüfsummen und redundanz denn wenn mal nicht optimaler empf ist dann 
würde sonst ne region / tag einer region ausfallen. zumal pro 24h nur 
20160 bit zur verfügung stehen passt eine vollständige widerholung gar 
nicht rein.

die jungs machen mindestens noch 2 andere sachen komprimieren oder in 
der übertragungsart überhaupt.

hat sich schonmal einer die schwingungen auf dem dcf angeguggt ?

ein normaler empf interessiert sich ja nur für die "hüllkurve"
nich das die da noch mit phasensprung innerhalb ihres bits basteln.

wie bin ich auf 54 bit gekommen?

8  windstärken     -> 3 bit
15 vorhersage tag  -> 4 bit
15 vorhersage nacht-> 4 bit
8 niederschläge    -> 3 bit
63 temp tag        -> 7 bit
63 temp nacht      -> 7 bit

bis hier isses einfach bei folgendem bin ich mir unsicher

sonnenzeiten:
dafür würde ich nicht vollständig hh:mm übertragen sondern nur die mm 
weil so markant wird sich die erde nicht schneller oder langsamer drehen 
den rest mit ungefährer vorgabe im controller
also      -> 7 bit aufgang
          -> 7 bit untergang

wetterentwicklungen kritische (11 stck.)

können ja da sein oder nicht, viele nicht in kombination
also     -> 8 bit
5 wetterlagen entspricht 6 stufen
sowie 9 windrichtungen sind beides doofe zahlen würde ich kombinieren
zu 15 stufen -> 4 bit

so das sind meine gedanken  den region würde ich nicht mit übertragen 
das ding hast zu wissen das 7:oo berlin dran ist


56 bit sind ein ganzzahliges vielfaches von 14

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den ganzen Überlegungen zur Verschlüsselung wird übersehen, dass die 
Geräte ja auch batteriebetrieben sein können und deswegen auf keinen 
Fall die ganze Zeit auf Empfang sind. Die Verschlüsselung kann sich also 
kaum auf einen größeren Bereich beziehen sondern immer nur auf ein (oder 
wenige) Telegramm(e). Wenn es also einen veränderlichen Startwert gibt, 
dann wohl tatsächlich die Zeit.

Auch darf der Entschlüsselungschip nicht beliebig viel Strom 
verbrauchen.

Will man damit einen größeren Markt abdecken, dann muss das Ganze billig 
sein, d.h. ein möglichst günstiger Prozessor -> wenig Programmspeicher, 
wenig RAM.

Markus


Autor: Jörn Paschedag (jonnyp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wärend meiner Pilotenzeit zu Beginn des Computerzeitalters wurden die 
Wetterdaten in Zahlenkolonnen per Fernschreiber übertragen. Die 
"Wetterfrösche" zeichneten an Hand dieser Daten die Wetterkarten.
Möglicherweise sind die neuen Wetterdaten im DCF77 ähnlich "codiert" wie 
damals.
Leider habe ich die alten Unterlagen nicht mehr, aber vielleicht nützt 
es, mal nach aviation weather oder nach wind aloft forecasts zu suchen 
um das alte System zu verstehen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörn Paschedag wrote:
> Wärend meiner Pilotenzeit zu Beginn des Computerzeitalters wurden die
> Wetterdaten in Zahlenkolonnen per Fernschreiber übertragen.

Das kenn ich noch. Als Gymnasiast war es ein Jahr lang meine
Aufgabe um 18 Uhr die Ablesungen zu machen, die Codierung
zu erstellen und per Fernsprecher nach Salzburg durchzugeben.

> Die
> "Wetterfrösche" zeichneten an Hand dieser Daten die Wetterkarten.
> Möglicherweise sind die neuen Wetterdaten im DCF77 ähnlich "codiert" wie
> damals.

Glaub ich ehrlich gesagt nicht. Das Zeugs ist so speziell, dass
es eigentlich nur für einen Meteorologen interessant ist.

Ich denke mal, da wird nicht viel mehr drinnen sein als:
Regionscode
Temperatur
Niederschlagswahrscheinlichkeit
Luftdruckvorhersage
schön/bewölkt/schlecht/Regen
Nebel ja/nein

Für die breite Masse reicht das.

Autor: balu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was drinn ist und mit welcher "genauigkeit" habe ich (oder wie es alle 
können auf der website lesen) aufgeschlüsselt und zusammengefasst

Autor: Jörn Paschedag (jonnyp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kbuchegg
IMHO sagt man auch heute noch Wetterfrösche zu den Meteoro-logen ;-)

Autor: ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fassen wir mal zusammen, was wir sicher wissen:
(bitte korrigieren bzw ergänzen...)

# es werden 14 bit pro minute gesendet, 20160 bit /tag
# die info wird 2x tägl. gesendet , 10080 bit /alle info
# info ist bzgl. 60 regionen , 168 bit / region (maximal)
# info besteht aus : Ort, Temp., ...(s.o. @balu , ca 50bit nötig)
- info könnte 2 oder 3x wiederholt werden
# info hat keinen einfach erkennbaren kopf, d.h.
entweder serieller string mit "marke", dann daten-block,
oder der "kopf" ergibt sich aus der zeit-info, zb jede gerade 
10-minuten-zeit ist der block-anfang
wegen fehler, empfangs-ausfall usw, muss relativ oft ein sync möglich 
sein, der datenblock hat dann parity oder nen crc (wenn verwürfelt + 
reed-solomon oder so...schlechte karten für uns)

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Christoph Kessler hat doch ganz oben im Thread den Link zur PDF 
geschickt:
http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf
Da ist doch alles haarklein aufgeschlüsselt.

Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sonic

DANKE!!!

LG
Michael

Autor: balu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei der beschreibung handelt es sich aber um die decheff version oder 
lese ich gerade was falsch

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was meinst du mit 'decheff'? Das Protokoll ist genau dasselbe wie beim 
Rest der Bits, also 'Quasi-BCD', bzw. Binär.

Autor: Andreas Kramer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da steht auch genau drinn wie das mit der Regionseinteilung ist :

Ein Wetterprotokoll für eine Wetterregion und eine Vorhersage wird über 
den Verlauf von 3 Minuten gesendet. Diese Wetterdaten sind über die 
Sendezeit einer festenRegion zugeordnet.

Sollte das jemand mal im orginal haben steht irgendwo in nem heft dabei 
wann was gesendet wird !!!!

Das bedeutet man weiß wann welcher input kommt und man weiß wie die 
Wetterdaten sind und wie sie entschlüsselt sein müssten weil es da auch 
drinn steht =)

Beispiel :

Anzahl Datenbits: Tag - 4 Bit; Nacht - 4 Bit Lage: Wetter Tag - Bit 0 
bis Bit 3 Wetter Nacht - Bit 4 bis Bit 7 Dateninhalt: verschiedene 
Wetterbeschreibungen Gültigkeitsbereich: getrennt für Tag und Nacht
usw...

Das heißt man wüsste genau wie der input unverschlüsselt sein müsste ^^ 
und man müsste den verschlüsselten input aufzeichen und das 2-3 tage und 
dann nach Gemeinsamkeiten schauen.

Zeitverschlüsselung fällt außerdem eigendlich weg da das ja immer zu 
bestimmten Zeiten gesendet wird.

Gruß Andreas ( sehr interessanter Tread )

Autor: tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber alles die Aussage auf der Encoder Seite. Was vorne herein 
kommt, kann schon wieder was ganz anderes sein. Angenommen die 
Übertragung für Gebiet X startet laut der PDF-Datei um 10:00 so könnte 
doch die eigentliche Übertragung des Signales schon um 9:00 oder 8:34 
erfolgt sein. Doppelübertragung mehrfach verteilt, Prüfsummen, 
Schlüllel, etc.

Der Controller hinter dem Encoder wartet, bis es 10:00 ist und erhält 
für das geforderte Gebiet seine Fehlerfreien Daten. Dieses System ändert 
man jeden tag anhand des Schlüssels. Ich würde sagen aufgrund der 
wenigen Bits/Tag würde eine Entschlüsselung ewigst dauern/fast nicht 
möglich sein.

Gruß,
Tubie

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alle


Könnte jemand von Euch in Erfahrung bringen, wann welche Daten für 
welche

Region gesendet werden?



(Bsp: wenn ich das Gerät um 00.00 Uhr einschalte,
stehen die Wetterinformationen um 03.00 Uhr für Erfurt zur Verfügung?
Schalte ich das Gerät erst um 4 Uhr ein, wann stehen dann die 
Wetterdaten für Erfurt zur Verfügung ? Wie sieht es für andere Regionen 
aus)


Stehen die Wetterdaten komplett zur Verfügung,

oder wird in der Stunde X die Windstärke übermittelt
      und in der Stunde Y erst die Temperatur?


Ich hätte eine große Bitte:

Stellt uns bitte einen längeren Mitschnitt zur Verfügung, wir suchen 
einzelne Bitts, die zu gleichen Uhrzeiten immer gleich sind,
in einer Datenbank (Access) wären dies / dieses schnell gefunden ;)





Bernhard

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke ich werde meinen Wetter-Datenlogger mal kurzfristig umstricken 
und statt Wetterdaten die Bits 1 bis 19 aufzeichnen. Mit 512kB läuft er 
'ne Weile, dann kann ich in Ruhe mal zumindest die Wiederholung der 
Bitmuster auswerten. Vielleicht gibt' bis dahin auch von anderer Seite 
neue Erkenntnisse.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Bedienungsanleitung dieses METE-ON1 steht drin:
"Temperaturvorhersage Tag und Nacht (beim 4ten Tag, dem DAY 3, keine 
Nachttemperatur)"
http://www.elv-downloads.de/service/manuals_hw/714...

Ich kann in der Protokollbeschreibung keine derartige Einschränkung 
finden. Bin ich zu blind dafür oder werden hier Bits gespart? Könnte 
aber natürlich auch eine Einschränkung des Gerätes sein.

Außerdem wird in der Bedienungsanleitung nochmals drauf hingewiesen, 
dass es Regionen mit 4 und Regionen mit 2-Tage Vorhersage gibt. Das 
steht zwar auch im Protokolldokument, aber da kann man es leicht 
überlesen.

Markus

Autor: wulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendwie hab ich das Gefühl, dass das ganz ohne einem Chip zum 
Testen nichts wird.
Es wäre ja auch interessant, ob der Chip so: Bit rein-->Bit raus 
arbeitet
oder zB 8x Bit rein und dann erst ein Byte raus.

Ich glaube ein Chip würde Reverse-Engineering wesentlich erleichtern

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als erstes überprüft mal ob die Wetterdaten mit gleichem Wetter zur 
gleichen Region aber zu unterschiedlichen Zeiten gesendet denoch gleich 
codiert sind. Wenn dies so ist dann ist die Wahrscheinlichkeit sehr hoch 
das der Dekoder eben nicht mit wechselnden Schlüsseln, Schlüsseln aus 
der Uhrzeit oder ähnlichem arbeitet. Sehr wahrscheinlich wäre dann 
entweder ein Schlüssel pro Region oder generell nur ein einztigster 
Schlüssel, eg. Verfahren.

Gruß Hagen

Autor: Andreas Kramer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist aber leider unmöglich zu sagen ob ein Wetter gleich war wenn sich 
bsp die Vorhersage dann um nen halben tag oder so aktuallisiert oder 
auch nur die Winddstärke sich ändert.

Also ohne Versuchsobjekt ist das eigendlich unmöglich.

Gruß Andreas

Autor: Karst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, lese schon eine Weile mit, dickes Lob an Euch Inthusiasten!!!

nach allem Horroszenario bin ich ja froh, daß unsre Kirchenuhr noch 
richtig geht mit PIC16F877 da geht die rote LED (1.richtig decodierte 
Min + 1 =2.richig dec. Minute)immer noch an und Pendel wird bei Fehler 
>10 sec angehalten, Zeit, Temp. und Pendelauslenkung alle 2h auf 
Chipcard
geschrieben, täglich mithören um auf 433 Mhz...
sri wg PIC steig grad um...

was mich stört sind die "nur 14 Bit", seid Ihr sicher, das da nicht 
weitere technische Kunstgriffe gemacht werden?

Der Text stammt von 2004, vielleicht heute nicht mehr pseudo-random sein
http://www.piester.de/dp200403.pdf

"4.3 Phasenmodulation
Zur Modulation mit einem Phasen-„Rauschen“
(PM) wird die Trägerphase entsprechend eines
PRN-Kodes (Pseudo-Random Noise Kode) mit
einem Phasenhub Dj von ± 13∞ um ihren Mittelwert
jm umgetastet [16]. Als PRN-Kode wird
eine binäre Zufallsfolge p(t) maximaler Zykluslänge
mit N Zeichen (N = 29 = 512) verwendet,
so dass die Phasenzustände jm + Dj und jm – Dj
gleich häufig (je 256 mal) auftreten. Dadurch
bleibt der Mittelwert der Trägerphase unverändert,
und die Verwendung der Trägerfrequenz
als Normalfrequenz wird durch das Phasenrauschen
nicht nennenswert beeinträchtigt. Bild 7
zeigt den Verlauf der Amplituden und derPhase der DCF77-Trägerschwingung 
während
einer Sekunde. Der Träger, die AM-Sekundenmarken
und die Phasenumtastung sind zueinander
phasensynchron. Die Erzeugung von p(t)
erfolgt mit dem in Bild 8 gezeigten Schieberegister,
dessen Ausgänge 5 und 9 über ein Exklusiv-
Oder-Gatter auf den Schieberegistereingang
rückgekoppelt sind. Jeweils 0,2 s nach Sekundenbeginn
wird das Schieberegister aus dem
Zustand Null neu gestartet und nach Ablauf
eines vollständigen Zyklus, etwa 7 ms vor der
nächsten Sekundenmarke, wieder angehalten.
Die Taktfrequenz fT des Schieberegisters beträgt
645,83 Hz und ist eine Subharmonische
(77 500/120) der Trägerfrequenz 77,5 kHz.
omit beträgt die Dauer TT eines Zeichens 1,55 ms
und die Dauer eines vollständigen Rauschzyklus
793 ms.
Im PRN-modulierten Signal dienen zehn invertierte
Pseudozufallsfolgen in den Sekunden
0 bis 9 als Minutenkennung. Andere Informationen
werden in den Bits 1 bis 14 nicht übertragen.
Generell erfolgt die Übertragung von Binärdaten
mit der PRN durch Invertieren der
Pseudozufallsfolge p(t) (siehe Bild 8). Mit jedem
Rauschzyklus wird ein Bit übertragen, wobei
nicht invertierte Pseudozufallsfolgen p(t) der binären
Null und invertierte Pseudozufallsfolgen
p(t) der binären Eins entsprechen. Wenn eine
Schaltsekunde eingeführt wird, erscheinen bei
der PRN die 10 invertierten Rauschfolgen p(t)
zur Minutenmarkenidentifizierung um 1 s später.
Ab der 15. Sekundenmarke ist die durch PM
und AM übertragene Binärinformation identisch,
so wie sie zuvor dargestellt wurde.
"

https://www.ptb.de/de/org/4/44/pdf/dcf77.pdf:

"Wegen der Anwender, die DCF77 als Normalfrequenzsender
nutzten, wurde von nun an der Träger
für die Dauer der Sekundenmarken nicht mehr
auf Null getastet sondern nur auf eine Restamplitude
von 25 % abgesenkt."

Was nicht heißt, daß das immernoch so ist. Ich weiß nicht,
welches Datum hinter diesem Text steht, aber erzählt mir mal,
welche (kommerziellen) Anwender noch ein solches Normal nutzen.
Hab das zwar heut Vormittag mal ein paar min mitgeschrieben, konnte 
allerdings keine unterschiedliche Trägerabsenkung wirklich ausmachen.

Als ich Okt. 2005 angefangen habe, DCF mittels PIC zu decodieren
las ich schon was im netz von unterschiedlichen Trägerabsenkungen, 
leider hab ich die Seite nicht wiedrgfund.

wejens die Verschlisselung...
det wird nich jans so dolle sinn, da reicht schon die Drohung
überlegt Euch mal, den Text vor 20 Jahren auf das normale DCF...
Gruss Karst

Autor: Philipp Sªsse (philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann wrote:

> Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr
> wenige Mitarbeiter kennen.

Wie geschrieben: "security by obscurity" war gestern.

>> Die Decodierung selbst wird auch wieder per "fernwartung"
>> umprogrammierbar sein; alles andere wäre verrückt. Sobald also das
>> reverse-engineering beendet ist, wird der nächste Level des Hackerspiels
>> aktiviert ...
>
> Das Update ist entweder verschlüsselt oder unverschlüsselt.

Gemeint war jetzt kein Firmwareupdate! Ein Seed, ein Paßwort o.ä. Das 
kann "unsichtbar" zwischen Nutzdaten verschwinden.

> Wenn es verschlüsselt
> ist, dann kann der Mitarbeiter, der die normale Verschlüsselung verrät,
> ja auch gleich diese Verschlüsselung verraten

Zwei-Schlüssel-System. Es ist nicht nötig, daß ein Mitarbeiter beide 
Schlüssel kennt.

> Deswegen kann ich mir nicht vorstellen, dass es ein remote Update gibt.

Wie gesagt, kein Firmwareupdate, sondern Key-Update. So würde ich es 
machen. Aber von mir aus kann man auch unterstellen, daß die auf den 
Kopf gefallen sind. Von mir aus.


Ich will ja auch niemandem den Spaß verderben. Ich habe geschrieben: 
»Irgendwie ist es ja auch weniger Aufwand, einen PC eine Wetterwebsite 
parsen und die Signale selbst senden zu lassen. Also wenn das hier nicht 
als sportliche Herausforderung verstanden wird, den bösen Leuten, die 
hier ein Geschäftsmodell aufbauen wollen, mal zu zeigen, wo der Hammer 
hängt ... würde ich es einfach bleiben lassen!« Also, warum nicht 
einfach so ehrlich sein, daß der »Nutzwert« der Aktion sich darauf 
beschränkt, es einfach zu tun?!

Autor: Michele B.. (luxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm, aber wenn es da nen keychange geben sollte, wie bekommen es nacher 
eingeschaltete stationen mit?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen
ich hab das Ganze hier sehr interessiert mitgelesen und mir auch so 
meine Gedanken zum decodieren gemacht.

Wenn ich es Codieren müßte würde ich die Zeit als quasi rollierenden 
Schlüssel mit reinnehmen. Da man ja nicht weiß wann welche Region 
gesendet wird, würde ich das auch nicht zu festen Zeiten tun, sondern 
immer wechselnd nach irgendwelchen Regeln.

Von daher könnte es sein das selbst die genauen Informationen über die 
codierten oder auch decodoerten Daten nicht viel nutzen wenn man den 
Zeitpunkt nicht kennt.

Die einzige Change scheint mir zu sein:
Daten mit zuschreiben und gleichzeitig beim Wechsel einer Anzeige an 
einem gekauften Empfänger die decodierten Daten zu nötieren und vor 
allen Dingen die genaue Zeit dazu. Und das an mehreren Tagen um zu sehen 
wann die Regionsdaten denn so kommen.


Alles sehr spannnend, aber nicht einfach wie ich glaube.
Gruß Wolfgang

Autor: Andreas Kramer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls die in Ihrem eigenen Dokument nicht lügen, dann wird !jede Region! 
immer zu einer vorbestimmten Zeit gesendet. Und das jeden Tag wieder zur 
gleichen Zeit, was den Vorteil hat der Empfänger weiß einfach um ... uhr 
ist region x und um ... +3min die nächste Region. Somit spart man sich 
das senden der Region in der ohnehin knapp bemessen Datenmenge, die man 
sicherlich somit besser verwenden kann. Damit scheidet verschlüsselung 
durch Zeit eigendlich aus.

Zu dem Fernupdate der Schlüssel das geht nicht man könnte höchstens 
sagen momentan ist Schlüssel ... gefragt aber wenn ein gerät z.b. nen 
monat nicht empfängt und in der Zeit ändert sich der Code dann wäre das 
ja unbrauchbar. Ich glaub nicht das die sowas machen würden.

Gruß Andreas

Autor: wulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Damit scheidet verschlüsselung durch Zeit eigendlich aus.

Wieso das? Du kannst ja immer noch den Key an die Zeit binden.
Damit ist lediglich ausgeschlossen, dass die Regionen irgendwann kommen.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich lese auch immer mal wieder interessiert mit. Ein Gedanke der mir kam 
(vielleicht steht es auch hier drin und ich hab es überlesen)ist, woher 
weiss der Empfänger in welcher region er steht?!? Kann man das 
einstellen oder ist da ein GPS-Empfänger mit drin :-)

Gruss,
Steffen

Autor: wulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann dem Decodier IC eigentlich egal sein. Aber das kann man dann sicher 
mit der Nummer, die auch in dem pdf gedruckt ist einstellen.

Autor: brrrrt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@stefen du hast es überlesen

es kommen alle regionen du stellst lokal ein was du willst die elv uhr 
kann 4 (5) regionen

Autor: brrrrt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ehm wieso von der stunde den wehcselnden schlüssel abhängig  machen 
geht doch auch der tag die woche das jahr

Autor: ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vermutlich is kein key drin, wozu denn? wegen ein paar irren, die selbst 
ne uhr auf avr machen?? wohl kaum.
aber: datenblock hat 3 min, gibt 42 bit.
daten sind soweit bekannt, 22 bit.
was sind die 20 restlichen???
ich vermute: der block hat ne heftige fehlerkorrektur, da info nur 4x am 
tag 1x kommt, wärs sehr doof, wenn er 6 std lang zb berlin 38° anzeigt, 
weil ein bit falsch empfangen wurde...
also : 22 b daten, 20 b crc bzw (übel) bits verwürfelt mit double reed 
solomon korrektur...dann sind bitfehler korrigierbar.
dekodieren wird dadurch...schwierig...extra key erübrigt sich.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Sªsse wrote:
> Markus Kaufmann wrote:
>
>> Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr
>> wenige Mitarbeiter kennen.
>
> Wie geschrieben: "security by obscurity" war gestern.

Ach was. Wenn ich daran denke, was beim Studium alles als veraltet und 
"macht man heute nicht mehr" bezeichnet wurde, aber heutzutage (10 Jahre 
später) immer noch gemacht wird...

> Wie gesagt, kein Firmwareupdate, sondern Key-Update. So würde ich es
> machen. Aber von mir aus kann man auch unterstellen, daß die auf den
> Kopf gefallen sind. Von mir aus.

Kryptografie ist nicht selbsterklärend. Schau doch nur mal, wieviele 
Leute glauben, die statische Verschlüsselung beim http-auth sei sicher. 
Weil, das ist ja verschlüsselt. Als ob es keine replay-Attacks geben 
würde.

Markus

Autor: Niclas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab das auch sehr interessant verfolgt ;) Ich bin auch gerade ein 
bisschen am Spielen mit Mikrokontrollern :D als nächstes steht bei mir 
ein DCF77 Wecker an und da bin ich bei Wikipedia auf die Wetterinfos 
gestoßen ;) da wurde ich natürlich neugierig :)

Mal sehen, vllt. kann ich etwas helfen und einen stetigen Datenlogger 
basteln, also die Daten gehen dann vom Controller -> PC -> Internet ;)

mfg Niclas

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wenn die die daten doppelt senden.
z.b. das jeder block um einen datensatz verschoben noch mal
gesendet wird?

Autor: Frederik Sdun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
servus
hab den thread hier gestern bekommen und wie der zufall wollte is meine 
Uhr heute 5 Monate 5 tage und 10 stunden zu früh dran gewesen(zum glück 
hab ich mich nicht vom wecker wecken lassen da ich ne Klausur 
geschrieben hab).
ich wollte nur sagen das es ne uhr für 20 € gibt die das wetter anzeigt 
bzw. vorraussagt. ob das jetzt über nen barometer oder über die 14 Bits 
passiert seh ich nicht aber man bekommt de hier: 
http://www.elv.de/output/controller.aspx?cid=74&de...

mfg batman(aber psst)

Autor: Martin F. (martin-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lässt sich denn eine Region am Wecker einstellen? Denn wenn man der Uhr 
nicht sagen kann, wo sie steht, dann wird sie sich die Daten wohl 
eigenständig besorgen. Ist die Wettervorhersage denn nur per Bikini Girl 
möglich oder gibt es da auch genauere Daten, mit denen man was anfangen 
kann, wenn man sie irgendwie mitloggt?
Gruß Martin

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die von Frederik gepostete WS empfängt keine DCF77-Wetterdaten sondern 
arbeitet nur über eigene Sensoren. Ein Barometer hat die auch nicht, nur 
Temp./Feuchte :)

Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Unter http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf gibt's Infos 
zu dem Decoder IC.
Da das Ding offenbar "active" geschaltet werden muss zum Empfangen gehe 
ich mal von folgendem Zusammenhang aus: gleiche Region -> tägl. gleiche 
Sendezeit
Woher sonst sollte der Controller wissen, wann er den IC einschalten 
soll?

> - wir benötigen viele Mitschnitte über längere Zeiträume
>    von mehreren Standorten Deutschlands (wegen Raumwelle/Bodenwelle usw)
>
>    (Rolf sein formatierter Mitschnitt wäre als Mustervorlage
>    sehr gut geeignet, Rolf, großes Lob an Dich)
>
> - Aus den vielen Mittschnitten muss ein einziger lückenloser und
>    fehlerfreier "Referenz_Mitschnitt" erstellt werden.
>
>    Denn ein einziger "fehlerbehafteter" Mittschnitt könnte die
>    Decodierung/Deciffrierung extrem erschweren.

Vielleicht sollte mal jmd. eine Website aufsetzen, wo man die 
verschiedenen empfangenen Daten sammelt und in eine Datenbank zur 
Auswertung packt...


Gruß,
  Andreas Weller

Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber noch was Anderes:
Es werden ja auch "Bevölkerungswarnungen" übertragen - hat jemand evtl. 
davon das Codierungsschema? Dazu findet sich nämlich genauso wenig - 
aber warum? Denn "Warnungen an Alle" in einem undokumentierten Format 
auszusenden ist IMHO unsinnig...

Gruß,
  Andreas Weller

Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorschlag:
Unter 
http://www.distrelec.com/ishopWebFront/catalog/pro...
gibt's eine Uhr für 99 CHF ≙ ~60 EUR.
Bei so vielen Interessenten sammeln wir, einer bestellt die Uhr und wir 
gehen folgendermaßen vor:

Wir betrachten den Chip in der Uhr als Black-Box. Von Interesse ist nur 
das Verhalten der Black Box, die über definierte Schnittstellen eine 
bestimmte Input- Output-Verarbeitung sicherstellt und ob sich eine 
Systematik finden lässt. Ziel wäre ein Reverse Engineeren des 
verwendeten Protokolls - nicht das Disassemblieren von evtl. vorhandenen 
Software.

1. Einige Zeit Daten aufzeichnen und mit der Uhrenanzeige vergleichen
2. Die serielle Kommunikation am Chip belauschen
3. Verbindung Empfänger/Chip trennen und eigene, bekannte Daten rein mit 
Vergleich welches Wetter angezeigt wird.
4. Chip raus bauen und eigene Daten rein -> output loggen

Frage: ob wohl auch wirklich dieser obskure Decoderchip darin verbaut 
ist???


Gruß,
  Andreas Weller

Autor: Michael S. (mst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@for_ro:
Ich bin noch nicht dazugekommen die Daten durchzuschauen...

@Andreas Weller:
Im Moment ist zumindest mein Stand das es wohl nur den Dekoderchip gibt.

Aber die 60EUR wäre im verglich zu dem ELV Ding für knapp 300EUR eine 
echte Überlegung wert... zumal der beide Zeitzeichensender Empfangen 
kann!

Allerdings würde ich mich als Meteotime gerne dazu bereit erklären ein 
"Softwaremodul" in C oder VHDL zur Verfügung zu stellen wenn ich dafür 
von der Firma die es beziehen möchte ein NDA und eine menge Kohle 
bekommen würde.

-hypotetisch natürlich-

Mittlerweile muss ich mir aber selbst was eingestehen und schliesse ich 
mich bedingt der Aussage von Läubi an:

Die Daten sind vermtl. zu dynamisch um damit eine evtl. korrelation auf 
Wetterdaten zu machen. Es gibt zu viel Variablen um die "Ausgangsdaten" 
mit den "Eingangsdaten" sinnvoller Weise in Verbindung zu bringen.

Das der Algorythmus allerdings wärend der Laufzeit des Systems geändert 
wird, glaube ich nicht. Erstens ist viel zu wenig Platz im Protokoll um 
sowas anständig und vorallem zuverlässig zu realisieren und zwweitens, 
was ist mit einem System welches den Software update verpasst? 250000 
Reklamationen... Ne, glaub ich nicht...

Ich würde, -könnte ich mir halt Vorstellen- das noch mit einer Art LUT 
die periodisch umgeschalten wird zusätzlich verwurschteln. Gehen wir nur 
mal vom kleines AVR aus, mit 8k Flash und 8PIN's! Oh, da krieg ich viele 
LUT's und Algorythmen rein... Wenn ich diese LUT's umschaltbar machen, 
und reserviere mir dafür -sagen wir mal- 4 Bits im Protokoll, die Sende 
ich alle 60min dann habe ich zusätzlich zu meinem Algorythmus noch 2^4 
Möglichkeiten das zu verwurschteln... und Geschwindigkeitsoptimiert muss 
es auch nicht sein... ufff

Gruß Micha,

PS: Alles natürlich rein hypotetisch, evtl. zufällige Übereinstimmungen 
mit dem "echten" Meteotime Protokoll sind rein zufällig!

Autor: DCF77 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit https://erlangen.ccc.de/index.php/DCF77 könntest du das Verhalten 
des Weckers testen ohne ihn öffnen zu  müssen.
Habt ihr mittlerweile ein "Testobjekt" organisiert.

Autor: DCF77 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@for_ro:
Schreib' mal bitte ein längeres Log mit. In news:de.org.ccc - bzw. 
http://groups.google.de/group/de.org.ccc/browse_th... 
wird das Thema auch bearbeitet.
Ein User dort meint Anzeichen zu haben, daß sich alles im 2 h Rhythmus 
wiederholt.

Vielleicht könntest du ja Schaltung und Software veröffentlichen - das 
würde gleichzeitiges Loggen zur Fehlerkorrektur vereinfachen.

Autor: P. B. (pb0)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab mir zum einfacheren Experimentieren mal ein kleines Programm zur 
Interpretation der Bits zusammengeschustert. Entspricht der 
Spezifikation im oben verlinkten Dokument. Nur war mir die Verwendung 
von Bit 15 nachtsüber unklar.

> % gcc -o bin2weather bin2weather.c
> % ./bin2weather 1100011000111100101010
> --------- Generell ---------
> Wetter Tag: vorwiegend bewoelkt (1100 => 3)
> Wetter Nacht: Nebel (0110 => 6)
> Temperatur: -1 °C (101010 => 21)
> ----- Bedeutung bei Tag -----
> Schweres Wetter: Feinstaub (0011 => 12)
> Niederschlagswahrscheinlichkeit: 45 % (110 => 3)
> ---- Bedeutung bei Nacht ----
> Wind: Scirocco S (0011 => 12)
> Windstaerke: 5-6 Bft (110 => 3)
> Bit 15 unused: 0

Wie wahrscheinlich auch immer es sein mag, dass am 4.2.(?) in 
irgendeiner der Empfangsregionen ein Schirokko wütete.

Ein paar Gedanken, wie ich zu den Bits gekommen bin:
- Laut Dokument gibt es eine Übertragung am Tag und eine bei Nacht und 
Regionen mit täglich 2 bzw. 4 Updates.
- Bit 15 schaltet tagsüber bei der Interpretation der Bits 8-11 zwischen 
"Unwetter" und "Relatives Vormittagswetter / Sonnenscheindauer" um.
- Bit 15 ist, wie es aussieht, Nachts nutzlos?
=> Bedeutet, dass es vier verschiedene Datensätze bei der Übertragung 
gibt: Tag + Bit15 ein, Tag + Bit15 aus, Nacht + Bit15 ein, Nacht + Bit 
15 aus
Also müssten die Regionen mit nur einem Update tagsüber entweder auf die 
Unwetterwarnungen (wahrscheinlich) oder die 
Sonnenscheindauer/Vormittagswetter verzichten.

Es gibt, wie erwähnt, 480 dreiminütige Zeitfenster pro Tag. Die 60 
Regionen mit vier Updates bräuchten davon 240 Zeitfenster. Die 30 
Regionen mit zwei Updates bräuchten 60 Zeitfenster. Also wären hier 180 
Zeitfenster "übrig".
Im Laufe von zwölf Stunden (Tag/Nacht-Periode) wären das 90. 90 ist auch 
die Gesamtzahl der Regionen. Na ja, muss nichts heißen.

Bei der Dechiffrierung werden aus 42 Bits irgendwie 22 ... Das Bit 15 
fiel mir hier ins Auge, weil man auf dieses bei der Übertragung 
verzichten könnte. Man wüsste sowieso, dass in einer Region mit zwei 
Updates pro Tag das Bit nie verändert werden dürfte und in Regionen mit 
vier Updates jedes zweite Mal (vielleicht auch anhand der Uhrzeit 
bestimmt) das Bit gesetzt sein müsste. Verzichten wir auf das Bit 
bleiben 21 Bit übrig. Halb so viele wie vorher, hurra.

> 10100101001110 000101 0000000 0 000000 0 000100 001 01000 11100000 0 0 00:00:00
> 01000010111011 000101 1000000 1 000000 0 000100 001 01000 11100000 0 0 00:01:00
> 11100011011100 000101 0100000 1 000000 0 000100 001 01000 11100000 0 0 00:02:00

Für die 1100011000111100101010, die ich oben verwendet hab, hab ich also 
aus Verzweiflung einfach jedes zweite Bit aus dem neueren Log von oben 
genommen. Vielleicht bilden die Zwischenräume irgendwelche Paritätsbits 
oder geXORte Werte vorheriger, um mich mal gewaltig aus dem Fenster zu 
lehnen. ;)

Grüße und vielleicht bringts was,
pb0

Autor: dd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee...

> % ./bin2weather 1100011000111100101010
> --------- Generell ---------
> Wetter Tag: vorwiegend bewoelkt (1100 => 3)
> Wetter Nacht: Nebel (0110 => 6)
> Temperatur: -1 °C (101010 => 21)
> ----- Bedeutung bei Tag -----
> Schweres Wetter: Feinstaub (0011 => 12)
> Niederschlagswahrscheinlichkeit: 45 % (110 => 3)
> ---- Bedeutung bei Nacht ----
> Wind: Scirocco S (0011 => 12)
> Windstaerke: 5-6 Bft (110 => 3)
> Bit 15 unused: 0

Aber scheinbar nicht ganz korrekt - oder die Daten waren nichts.
IMHO sollte laut http://de.wikipedia.org/wiki/Scirocco folgendes 
zutreffen:
-1 °C und Scirocco schließt sich aus.
Feinstaub und Scirocco hingegen nicht...

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -1 °C und Scirocco schließt sich aus.
Also bei dem Bild in Wikipedia welches einen Scirocco zeigen soll liegt 
vorne auf den Häuserdächern noch Schnee...

Autor: dd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Malte:

OK - ich geb's zu: Irrtum :-)
Hatte nur was von "Wüstenstrum" und Sahara gelesen...

for_ro könnte jetzt nochmal einige Tage mitschreiben, so das ein 
Vergleich mit aktuellem Wetter möglich wäre - dann müsste gleichzeitig 
jemand das Wetter zu den gelisteten Städten aus der PDF Datei täglich in 
eine Tabelle packen. Dann kann man zumindest sehen, obs näherungsweise 
stimmt

Autor: eisenbahndirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Geht es nicht eher darum aus 3*14 Bits=42 Bits (1 Protokoll für eine 
Region), 2 mal 22 Bits zu machen?? ( 1 Protokoll Tags, 1 Protokoll 
Nachts )

Die Bits 8-11 im Protokoll scheinen doch z.B. zweideutig zu sein. Im 
Tagesprotokoll werden dort schwere Wetter definiert bzw. durch Bit 15 
gesetzt z.B. die Sonnenscheindauer. Im Nachtprotokoll wird hingegen die 
Windstärke definiert.

Wozu werden dann aber die Bits 0-3 und 4-7 ( Wetterbeschreibung 
Tag/Nacht ) doppelt übertragen?? (Wenn meine Vermutung richtig wäre).

Vielleicht liege ich in meiner Überlegung falsch. Oder doch nicht?!?!

Grüße eisenbahndirk.

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso sollte man eigentlich nicht aus
3*14=42 bit genau 22 bit machen?

Eigentlich passt das doch ganz gut:
60 Regionen mit je 4 Tageswerten
    und je 3 Nachtwerten
30 Regionen mit je 2 Tageswerten
(steht so in der Detail PDF Bedienungsanleitung, insbesondere dass der 
vierte Nachtwert fehlt)
Das ergibt 60*(4+3)+30*2=480 Datenblöcke.
Das wiederum füllt genau einen Tag (480*3min=24h)
Die 2*4 bit für die Wetterlage wären dann zumindest für die 60 Regionen 
mit Tag und Nachtdaten doppelt.

Noch eins:
Wenn man 3*14=42 bit (0..41) zusammensortiert sieht man folgendes:
bit14: immer 0
bit18: Mittelwert 0.36
bit21: immer 0
bit28: Mittelwet 0.61
Bei allen anderen ist 0 und 1
gleich häufig vertreten.
Interessant ist auch noch dass an den Positionen
15-22
16-23
...
20-27
besonders häufig die Bitkombinationen
0-1 und 1-0 auftreten
0-0 und 1-1 dagegen seltener.
Weitere Besonderheiten habe ich nicht
finden können. Insbesondere keine Periodizität.
(auch keine Wiederholung nach 2 Stunden)

Einen weiteren Hinweis gibt es noch in der
Bedienungsanleitung: offensichtlich kann es
bei Empfangsstörungen passieren, dass die Daten
für einen Tag unvollständig empfangen werden. Das spricht gegen 
Interleaving und starken
Fehlerschutz, da dann - wenn überhaupt -
ein kompletter Datensatz fehlen würde.

Vermutung: Also eher einfach so etwas wie 4 bit auf 7 bit inklusive 
Fehlerschutz erweitern, dann XOR mit einem Wert der aus Datum und 
Uhrzeit mittels LUT bestimmt wird und 2 solche Einträge pro Minute 
übertragen.
Sobald jemand ein Decoder IC hat, sollte es nicht schwer sein solche 
Vermutungen durch geziellte Änderungen bei den Eingangsdaten zu prüfen. 
Ohne das IC dürfte das ziemlich schwierig sein...

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir nach P. B.'s verfahren mal 4:00:00 angeschaut...

Ergebniss:
-------------------------------------------------------------
1110  1000  1110  111  000010
=
14    8     14    7    2


Wetter Tag: Schneeregen starke Niederschläge + Schweres Wetter
Wetter Nacht: Leicher regen
Temperatur: -20°C

Bei Tag:
Schweres Wetter: Radiation / 5-8 Std. Sonne; Sprung 3
Niederschlagswarschinlichkeit: 100%


Bei Nacht:
Windrichtung: reserviert
Windstärke: >= 10
-------------------------------------------------------------

Leider eher unwarscheinlich... :(

Ich versuche mir gerade über einen Freund an so einen Chip zu kommen... 
Mal sehen was daraus wird ;)

Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also eher einfach so etwas wie 4 bit auf 7 bit inklusive
> Fehlerschutz erweitern, dann XOR mit einem Wert der aus Datum und
> Uhrzeit mittels LUT bestimmt wird und 2 solche Einträge pro Minute
> übertragen.

Was ich mich bei Ansicht von 
http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf frage ist, ob der 
Decoder IC überhaupt die aktuelle Uhrzeit übergeben bekommt. Es wäre 
doch auch denkbar, daß der MC die Wetterdaten von der Uhrzeit trennt und 
nur diese an den Chip übergibt. Nach dem Schema in dem PDF wäre auch das 
zumindest denkbar. Die Frage ist, ob dann überhaupt eine LUT existiert.

Gruß,
  Andreas Weller

Autor: wulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ein MC die Datenvoneinander trennt, dann wäre es sogar möglich, 
dass er die Wetterinformationen puffert, abwartet ob die Zeit korrekt 
empfangen wurde und erst wenn das geschehen ist schiebt er den Puffer 
zum Decodier-IC.
Also nicht 1 Bit / Sekunde sondern gleich alle 14 auf einmal.
D.h. Reverse Engineering ist leicht (bei Vorhandensein eines 
Decodier-IC)

Autor: dd (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich habe bin2weather von P. B. mal unter Windows (VC6) compiliert. 
Vielleicht animiert das ja auch Andere, die nicht die Möglichkeit haben, 
sich damit zu beschäftigen...

@Andreas Weller:
Wollte grad die 60 € Uhr aus dem Link bestellen, den du gepostet hast - 
die liefern aber nur nach .CH :-(
Hast du da vielleicht Kontakte - oder wohnst du dort?

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110 
als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ludwig Wagner wrote:
> was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110
> als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder?
Ich auch ;)

Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

> was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110
> als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder?

Im Programm heißt es aber doch z.B.

> unsigned char code = bit0 * 1 + bit1 * 2 + bit2 * 4 + bit3 * 8;

AFAIK ist es aber doch doch genau so: 1, 2, 4, 8, 16...
Hab's aber noch nicht gestartet und ausprobiert (nur den Quelltext kurz 
gesichtet)

@dd:

> Wollte grad die 60 € Uhr aus dem Link bestellen, den du gepostet hast -
> die liefern aber nur nach .CH :-(
> Hast du da vielleicht Kontakte - oder wohnst du dort?

Nein ich wohne leider nicht dort - schön wär's ;-)
Weiterhelfen: nun ja, vielleicht - ich kenn' jmd. der in .CH arbeitet...
Hab auch die Lieferbarkeit nicht überprüft. War nur eine schnelle Google 
Suche nach Alternativen zu dem 300 EUR ELV Teil.


Gruß,
  Andreas Weller

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> unsigned char code = bit0 * 1 + bit1 * 2 + bit2 * 4 + bit3 * 8;
>
>AFAIK ist es aber doch doch genau so: 1, 2, 4, 8, 16...

Die Frage ist: wie rum müssen die Bits verarbeitet werden bei dem 
Protokoll?

Um bei dem Beispiel zu bleiben:

011:
a) 0*1 + 1*2 + 1*4 = 6 oder
b) 0*4 + 1*2 + 1*1 = 3

1110
a) 1*1 + 1*2 + 1*4 + 0*8 = 7 oder
b) 1*8 + 1*4 + 1*2 + 0*1 = 14

Bei den Zeitinformationen wird nach Schema a) codiert:
http://www.gumo.de/sonstiges/zeitzeichensender/

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm... das müsste man sich mal etwas genauer anschaun, das könnte 
durchaus sinn machen

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy
Ich finde das auch gerage interessant.
mal eine frage:

laut
http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf
ist das empfänger-modul ein UE6015.
http://www.hkw-elektronik.de/deutsch/produkte/bauteile.php

ist das ein standart modul wie das von reichelt/conrad?
weil da ja noch signale zum modul gehen.
pon ist klar, nur mit dem hld kann ich garnichts anfangen.

mfg

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Datenblatt:

HLD AGC hold input
CMOS compatible, digital input; LOW active; by default set to HIGH via 
internal pull-up resistor.
AGC hold mode: HLD = HIGH sets normal function, HLD = LOW (VHLD = GND) 
holds for a short time the AGC voltage. This can be used to prevent the 
AGC from peak voltages, created by e.g. a stepper motor.
Once HLD is used then it is recommended to keep HLD activated (HLD=LOW) 
as long as the interference can be detected on the cristal filter. 
Typical values are 100…200ms.

Auf gut Deutsch: brauchen wir nicht.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.elv-downloads.de/newsletter/indexnewsle...

Die nächsten, die was vom Kuchen abhaben wollen, ohne die ersten 
14Sekunden gekauft zu haben.
Konkurenz belebt eben das Geschäft.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel

> Die nächsten, die was vom Kuchen abhaben wollen, ohne die ersten
> 14Sekunden ...


Aber in der Beschreibung steht etwas von einem Stellitenempfang, nichts 
von DCF, oder?

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JAHaa
>ohne die ersten 14Sekunden gekauft zu haben.
Wollte ich damit sagen.
Ob das stimmt?

Autor: Robert Weber (rweber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, die übertragen per Staellit. Axel schreibt ja auch "ohne die 
ersten
14 Sekunden gekauft zu haben".

Wäre auch interessant zu wissen, ob man an diese Wetterdaten einfacher 
rankommt.


Autor: Andreas Weller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich denke es funktioniert auf ähnlicher Basis wie die alten Pagernetze. 
Da stehen die schönen Sat gesteuerten Funkstationen in der Gegend rum 
und keiner benutzt mehr die Pager.
Werd das Morgen mal überprüfen...
Die Dinger senden irgendwo im 70 cm Band (ca. 460 Mhz). Die Codierung 
nannte sich Pocsag. Man konnte es immer mittels Soundkarte decodieren...

IMHO wäre eine Decodierung aber aufwändiger als bei DCF77.

Gruß,
  Andreas Weller

Autor: Lars Paetsch (lhp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal nen bischen gegoogled:

Hier ein paar Links:


Protokoll / Frequenzen etc.

http://de.wikipedia.org/wiki/POCSAG


Skyper etc. :

http://de.wikipedia.org/wiki/Skyper_%28Pager%29



vielleicht hilft das hier auch weiter

http://funkmeldesystem.de/


Ach und übrigens:

Die von e skyper und wetter.de wollen auch was vom Kuchen.

Guckst du:

http://www.emessage.de/de/skyper/index.html

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das IC zur deschifrierung hat nur 8 pins, ein serielles daten-in und ein 
serielles daten-out. Also wenn wir jetzt noch jemanden finden der beide 
seriellen BUSe belauschen kann, dann erstmal die seriellen in-daten mit 
den 14 bits des DCF77 vergleicht und dann mal eine weile die in und out 
daten logt dann müsste man das doch entschlüsseln können oder? Außerdem 
kann man dann noch raus finden wie das mit den regionen ist (eine region 
einstellen und schauen wann der IC aktiviert wird, falls das wirklich so 
läuft).

Und wenn das nicht hilft einfach mal den dekoder IC nehmen und unter dem 
Mikroskop analysieren ;)

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 a) > die seriellen in-daten mit den 14 bits des DCF77 vergleicht
 b) > unter dem Mikroskop analysieren


zu a)

Ich denke, Du wirst KEINEN Unterschied erkennen können. Sind die ersten 
14 Sekundenimpulse vom DCF nicht die seriellen In- Daten vom Chip?


zu b)

klar! Den Chip zu "Finger" nach Oldenburg schicken und via PD500 oder 
SRS326 Röntgen lassen ;-)))


Viele Grüße, sehr interessant

AxelR.

[Edit]
Zitat wird nicht grün, komisch

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<OT>
Zitat wird nicht grün, weil das '>' nicht das erste Zeichen in der Zeile 
ist.
</OT>

Gruss
Jadeclaw.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<OT>
...ist ihm nicht die Röhre verreckt!?
</OT>

d.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen POCSAG-Decoder für die Soundkarte gibts hier:
http://www.dsp4swls.de/dsp/pocsag.html
den hab ich selbst schon mit Amateurfunk-Funkruf auf 439,985 MHz 
ausprobiert

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Kessler (db1uq) wrote:
> Einen POCSAG-Decoder für die Soundkarte gibts hier:
Danke für die Info.

Gruss
Jadeclaw.

Autor: Michael Schröder (michael_sch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht bei euch grade DCF77, bei mir seit ca 20 min nicht mehr, bekomm 
hier nur 1 ser rein, außer der synchonisation. Dachte ja schon es liegt 
am empfänger, aber mein Wecker von TCM hat plötzlich auch keinen Empfang 
mehr. Kann also bitte mal jemand bestätigen, dass DCF77 noch online ist.

Danke,
Michi

Autor: tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
16:44 Uhr - DCF-77 ist auf Sendung

Autor: DCF77 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Hab' mich ml ein wenig mit dem Pocsag-Kram beschäftigt. Also bei den 
verwendeten 1200 baud ist es schon einfacher die Wetterdaten zu 
verstecken und/oder stärkere Kryptoverfahren zu verwenden. Ich denke es 
ist bei DCF77 einfacher die "relevanten" Daten zu finden: wir wissen, 
daß sie in den ersten 14 Bit stecken müssen. Bei Pocsag ist es schon 
aufwändiger...
Wer sich trotzdem mal ein Bild machen möchte: unter 
http://www.uploadwiz.com/WIZ1008554360 habe ich einen Mitschnitt 
bereitgestell der Frequenz 466.23 MHz - dürfte e*messenger sein.

Autor: Lars Paetsch (lhp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
466,23 MHz ist Scall. Wird nur noch teilweise benutzt.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also im Amateurfunkgesetz stand mal - oder staht noch ...werden 
versehentlich solche Sendungen empfangen, so darf weder deren Inhalt 
noch die Tatsache des Empfangs jemandem mitgeteilt werden... oder so 
ähnlich. POCSAG auf Amateurfunk ist dagegen frei für alle, die Frequenz 
hatte ich genannt.

Autor: Albatros (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einfach wie ihr Euch das mit dem Loggen vorstellt ist das nicht:

Aus dem Handbuch:
…
Die vom Mete-ON 3 dargestellten Wettervorhersagen werden zwischen 22:00 
und 4:00 morgens empfangen (UTC Zeit, in Zentraleuropa ist das im Winter 
+1 Stunde und im Sommer +2 Stunden). Um nach der Inbetriebnahme erste 
Vorhersagen ablesen zu können, müssen Sie also eine Nacht abwarten!

Die neuen Tagesvorhersagen stehen ab 3:00 morgens zur Verfügung. Die 
neuen Nachtvorhersagen stehen ab 6:00 morgens zur Verfügung.
….

Zusätzlich geht das ganze Gerät in den PowerSave-Mode, d.h. das IC ist 
im überwiegende Teil der Zeit deaktiv.

Hier kommen einfach zu wenige Daten zusammen, dass eine Dekodierung 
möglich wird. Aus meiner Sicht muss man das IC auslöten und mit Daten 
füttern.

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn's nervt:
abo

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas, abo ist nicht mehr nötig. Du kannst auf den Link 
"Email-Benachrichtigung aktivieren" klicken, das hat denselben Effekt.

mfg, Stefan.

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Albatros wrote:
> Hier kommen einfach zu wenige Daten zusammen, dass eine Dekodierung
> möglich wird. Aus meiner Sicht muss man das IC auslöten und mit Daten
> füttern.

Ist denn schon klar, daß dieses ominöse IC in den Geräten überhaupt 
dediziert eingebaut ist oder ob das alles irgendwie komplett integriert 
ist?
Muß mal meine schweizer Connections spielen lassen und so ein Gerätchen 
ordern. In Deutschland kosten die Dinger nämlich leider knapp 100 EUR 
plus Versand.

Gruß, Didi

Autor: wulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In Deutschland kosten die Dinger nämlich leider knapp 100 EUR plus Versand
Welche Dinger? Eine Uhr, die die Wetterdaten auswertet oder dieses 
Dekodier-IC?
100 € für ein IC ist doch schon ein bisschen heftig.
-> Um welche Uhr geht es?

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -> Um welche Uhr geht es?

um die oben gepostete...

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

wulf wrote:
>>In Deutschland kosten die Dinger nämlich leider knapp 100 EUR plus Versand
> Welche Dinger? Eine Uhr, die die Wetterdaten auswertet oder dieses
> Dekodier-IC?
> 100 € für ein IC ist doch schon ein bisschen heftig.
> -> Um welche Uhr geht es?

Sorry, hab mich etwas unklar ausgedrückt ... die "Mete-ON 3"-Uhr meinte 
ich: 99 sFr in der Schweiz und 99 EUR bei uns in Deutschland.
Frage ist eben, ob da auch wirklich der Chip drinsteckt oder ob alles 
auf einem IC integriert ist inklusive der Uhren-Funktion.
Wenn alles klappt, habe ich wohl Ende nächster oder Anfang übernächster 
Woche so ein Gerät hier und wenn man es zerstörungsfrei zerlegen kann, 
mache ich mal ein paar Bilder von der Platine.

Gruß, Didi

Autor: Albatros (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer.
Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden 
(Achtung: ist nur ca. 3 min aktiv und enthält ein zusätzliches 
Logiksignal). Viel Spaß beim Dekodieren.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albatros wrote:
> Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer.
> Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden


Hättest Du ein Bild von der Schaltung ?

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen!

Bernhard Schulz wrote:
> Albatros wrote:
>> Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer.
>> Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden
> Hättest Du ein Bild von der Schaltung ?

Das wollte ich auch gerade fragen ;-)
SO-8 korrespondiert zumindest mal mit dieser Beschreibung: 
http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf
Vor allem wäre interessant, wie einfach sich das Gehäuse der Uhr öffnen 
läßt und ob das ohne sichtbare Beschädigungen vonstatten geht 
(hoffentlich geschraubt und nicht geclipst!).
Schon mal danke an Albatros für entsprechende Infos!

Gruß, Didi

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

John-eric Kamps wrote:
> laut
> http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf
> ist das empfänger-modul ein UE6015.
> http://www.hkw-elektronik.de/deutsch/produkte/bauteile.php
> ist das ein standart modul wie das von reichelt/conrad?

Hier gibts das Datenblatt:
http://www.hkw-elektronik.de/pdfenglisch/UE6015%20...
Demnach ist es tatsächlich eine Art Standardmodul - nur ein etwas 
leistungsfähigerer Empfängerchip mit einem Haufen Optionen wie z.B. 
umschaltbare Antenneneingänge, wählbare Ausgangs-Polarität (H-L-H oder 
L-H-L), usw.
Außerdem ein klassischer ASK-(Amplitude Shift Keying)-Empfänger, also 
keine Auswertung der Phasenmodulation. Das sollte ggf. die Auswertung 
der 14 Bit durchaus vereinfachen ;-)

Grundsätzlich dürfte kein Weg daran vorbeiführen, Ein- und 
Ausgangssignal des "Dechiffrier"-ICs direkt zu vergleichen und daraus 
seine Schlüsse zu ziehen. Sonst wird man wohl kaum weiterkommen.

Gruß, Didi

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Albatros wrote:
> Die vom Mete-ON 3 dargestellten Wettervorhersagen werden zwischen 22:00
> und 4:00 morgens empfangen (UTC Zeit, in Zentraleuropa ist das im Winter
> +1 Stunde und im Sommer +2 Stunden). Um nach der Inbetriebnahme erste
> Vorhersagen ablesen zu können, müssen Sie also eine Nacht abwarten!

In diesem Dokument ist alles noch etwas detaillierter nachlesbar:
http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf
"Die Wetterdaten werden über 24 Stunden in jeder Minute ergänzend zur
Uhrzeit und dem Datum von Sekunde 1 bis Sekunde 14 übertragen.
Ein Wetterprotokoll für eine Wetterregion und eine Vorhersage wird über
den Verlauf von 3 Minuten gesendet.
Diese Wetterdaten sind über die Sendezeit einer festen Region
zugeordnet.
Die Sendezeitpunkte für die Wetterregionen entnehmen Sie bitte dem
Handbuch aus dem Lizenzvertrag.
Die übertragenen Daten können nur mit der über den Lizenzvertrag
beschaffbaren Dechiffriervarianten geprüft und für die Auswertung bzw.
Anzeige nutzbar gemacht werden.
Die Dechiffriereinheit erzeugt die Meteotime-Wetterdaten von Bit 0 - Bit
21."

Und weiter:

"Die Bitbeschreibungen in der nachfolgenden Zusammenstellung der
Wetterdaten basieren auf dem aus 3 Minuten gebildeten Datenwort. Die
Bit-Numerierung der Wetterbits bezieht sich nicht auf die
Bit-Numerierung in der Rosette des DCF-Protokolls."

Das bedeutet also:
- während 3 Minuten werden 3x14 Bit = 42 Bit übertragen
- aus diesen 42 Bit werden in der "Dechiffriereinheit" 22 Bit erzeugt
- dies sind dann die Wetterdaten für eine feste Region
- welche Daten für welche Region kann man nur dem Lizenzvertrag
entnehmen
- lt. Handbuch wird zwischen 22:00 und 4:00 UTC gesendet, hier steht 24h

Das sind doch schon mal ein paar Anhaltspunkte, auf denen man aufbauen
können sollte ...
Meine METE-ON 3 geht voraussichtlich Montag in die Post ;-)

Gruß, Didi

Autor: Michael St. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
42 bei 180 und einem intervall von 86400 zu entschlüsseln ist nicht 
schnell vollbracht mit rechnern unter 1KHz! Da hat schon 1962 eine 
Maschine... Die simple(Intervall) Änderung zu begreifen wurde schon 1938 
verstanden... Noch ein wenig AVR -- SAM und es klappt auch mit dem 
nachfolgen. Für die Kosten der Schaltung kann ich auch sicherlich ein 
Modul kaufen! Und habe dann eine Standbyschaltung unter 50uA!
Nicht alles was glänzt ist Gold, aber es zu erringen lohnt sich, es sei 
denn man ist ein studierter Student der keine Aufgaben findet. Oder ein 
Ingenieur dem bei Harz4 langweilig wird und ausser Studieren nichts 
gelernt hat!

Gruss M.



Viele Grüße
Michael

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Michael,

mir scheint, Du hast da was falsch verstanden ;-)
Es geht nicht um Aufwand/Kosten-Nutzen-Verhältnisse, sondern einfach um 
den sportlichen Ehrgeiz, das Verfahren zu decodieren ...
Klar kann man sich für den Aufwand ein Modul fertig kaufen, aber das ist 
doch langweilig. Außerdem kann man da durchaus noch was lernen dabei.

Gruß, Didi

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es darum geht das man sich alles biliger fertig kaufen könnte dann 
gäbe es hier kaum ein projekt.

Hier geht es darum Spaß am basteln zu haben und besonders darum das man 
sich alles selbst anpassen kann wie man will. Und man kann stolz sein 
wenn man fertig ist! ;)

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Definition eines Hobbys:

Mit möglichst maximalen Aufwand den geringsten Nutzen erzielen ;)

Autor: Albatros (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Gehäuse ist mit 6 Schrauben verschlossen. Lässt sich ohne 
Garantieverschleiß öffnen. Die Drähte an das IC sind Messleitungen.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Drähte an das IC sind Messleitungen.

An welchen Pin des IC liegen welche Signale an?


Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen!

Weiter oben hatten wir ja schon die Info zur ELV-Wetterstation. Jetzt 
ist es offiziell bei teltarif.de gemeldet worden:
http://www.teltarif.de/arch/2007/kw10/s25164.html

"Wohnzimmer-Wetterstation wird per Paging-Signal aktualisiert"

Gruß, Didi

Autor: Penguin 007 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Drähte an das IC sind Messleitungen.

Und - was hast du gemessen?

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schaue gerade den neuen elv-Sommerkatalog 2007 durch, da sind die 
beiden DFC77-Geräte Mete-on 1 und 3 sowie das Pager-Gerät (die 
Bezeichung WD 4000 sehe ich allerdings nirgends) drin.

Hab mal gegoogled, hier unterhalten sich auch einige zum Thema "elv WD 
4000" :
http://www.wetterstationen.info/phpBB/viewtopic.ph...

Zitat:
"Wer noch den alten Scall-Dienst kennt: die Funkzonen sind mit denen von 
Scall identisch, habe gerade die Karten miteinander verglichen. Sowohl 
Zoneneinteilung als auch Nummerierung stimmen exakt überein."
zu Scall gibts noch die Karte:
http://www.wetterstationen.info/phpBB/download.php...

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frequenzen liegen alle im 466MHz-Bereich:

http://www.trust-us.ch/ds/49/006_Scall.html :
"Zur Zeit (1994) ist Scall nur mit speziellen Scall-Empfaengern, die auf 
den Frequenzen f3(466,230Mhz) laufen, moeglich. Ab 1.3.1995 soll es 
moeglich sein, auch andere Cityruf-Empfaenger auf den Frequenzen 
f1(465,970) und f2(466,075) auf Scall umzubuchen."

http://pcphy4.physik.uni-regensburg.de/pager/grund.html :
"Cityruf 465.97MHz   Scall 466.230MHz   Skyper 465.97MHz   Telmi 
448.425MHz   Quix 448.475MHz   Euromessage 466.075MHz
Scall ist als Tarif eingestellt,  die Frequenz aber noch im Gebrauch 
durch die e*message GmbH, die auch Skyper und Cityruf von der deutschen 
Telekom übernommen hat (Situation  11/2003)."

Demnach findet die Übertragung der Wetterdaten auf 466,230 MHz statt.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi Mail@laeubi.de wrote:
> Andreas Schwarz wrote:
>> Ich könnte mir schon vorstellen dass das nur eine halbherzige
>> Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu
>> machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B.
>> vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0.
>
> Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle
> Träume über dechiffrierung sind eh nahezu dahin.
>
> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode
>

Ich denke nicht, dass eine einfache CBC zur Anwendung kommen kann. Da 
nicht alle verbundenen Systeme ( Sender und Uhren) mit einander 
verbunden sind und gleiche Startbedingungen haben. Eine sehr hilfreiche 
Information wäre z.B. zu wissen, wie schnell eine frisch eingeschaltete 
Uhr die Wetterinformationen bereit stellt. Daraus lässt sich der 
'Aufstart-Zeitpunkt' der Verschlüsselung identifizieren. Eine echte CBC 
würde nämlich erfordern, dass alle Chips immer mit Energie versorgt sind 
um den Key-Change mit zu verfolgen.

Ich tippe daher auf eine software technisch recht simple, aber 
sicherheitstechnisch sehr effektive AES mit bekanntem, aber geheimen Key 
auf beiden Seiten. Um ehrlich zu ein, genau das habe ich bei anderen 
Dingen auch so gemacht.

Was ich aber noch loswerden muss ist mein wirklicher Unmut:
1. ...dass eine Institution, die durch meine Steuergelder finanziert 
wird, Knowhow aus dem Ausland einkauft um daraus ein profitables 
Geschäft zu machen, dessen Gewinne wieder im Ausland versickern.
2. ... dass eine Einrichtung, die eine öffentliche Dienstleistung zur 
Verfügung stellt nun mit verdongelten Systemen kombiniert wird, die sich 
der Kontrolle der Öffentlichkeit entziehen.

Wenn Ihr das Protokoll knacken wollt, dann habt ihr meine volle 
Unterstützung, da es in meinen Augen eine Verletzung des Auftrages 
seitens der PTB, eine logistische / finanzielle Niederlage für die 
deutsche Industrie, und ein Schlag ins Gesicht aller deutscher 
Entwickler ist. Dafür gehört die PTB ebenso abgestraft, wie die 
meteotime. Im übrigen bin ich dafür, dass die PTB sich nun zu einem 
großen Teil aus den Lizenzen finanzieren sollte und die Beiträge aus 
Steuergeldern zurück gefahren werden müssen, da sie sich von ihrem 
Non-Profit Forschungsauftrag zurück gezogen hat.

Ich habe momentan wenig Zeit wegen Hausumbau, werde aber mal das ganze 
DCF-Material am Wochenende einsammeln und nächste Woche zu einem 
funktionsfähigen Empfänger zusammen bauen. Damit werde ich dann einen 
Langzeit-Log laufen lassen. Da mein PC eh immer an ist, kann das Modul 
das gleich in einen Logfile laufen lassen.

Gruß,
Ulrich

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey!
Kann mir jemand sagen ob und wie ich die Wetterdaten auf der 466,230 MHz 
entschlüsseln kann und ist es überhaupt erlaubt diese einfach zu 
verwenden?

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiter oben habe ich schon den Link zum Soundkarten-Decoderprogramm 
genannt. Ob die Daten verschlüsselt sind weiß ich nicht, vermutlich ja.
Empfang mit der ELV-Wetterstation ist selbstverständlich gestattet, 
selbstgebautes vermutlich nicht. Nochmal der Link:
http://www.dsp4swls.de/dsp/pocsag.html

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
>> Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle
>> Träume über dechiffrierung sind eh nahezu dahin.
>>
>> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode
>>
>
> Ich denke nicht, dass eine einfache CBC zur Anwendung kommen kann. Da
> nicht alle verbundenen Systeme ( Sender und Uhren) mit einander
> verbunden sind und gleiche Startbedingungen haben. Eine sehr hilfreiche
> Information wäre z.B. zu wissen, wie schnell eine frisch eingeschaltete
> Uhr die Wetterinformationen bereit stellt. Daraus lässt sich der
> 'Aufstart-Zeitpunkt' der Verschlüsselung identifizieren. Eine echte CBC
> würde nämlich erfordern, dass alle Chips immer mit Energie versorgt sind
> um den Key-Change mit zu verfolgen.

Muß doch garnicht...

Möglichkeit a) Fester Startwert --> unsicher, unflexibel
Möglichkeit b) Zufälliger Startwert --> muß mitübertragen werden (bei 
128bit verschl. immerhin 16byte...), guter Zufallsgenerator nötig, 
Probleme bei Übertragungsfehlern
Möglichkeit c) Zeit ist der Startwert --> Zeit wird eh übertragen und 
ist allen Empfängern "bekannt"

Möglichkeit c) ist einfach, schnell, effizent und bietet ein höchstmaß 
an Sicherheit für diesen Einsatzzweck.



Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen!

Was haltet Ihr davon, wenn wir in diesem Thread mit dem DCF77-Wetter 
weitermachen und einen neuen für die Pager-Netz-gebundenen 
Wetterstationen aufmachen?
Ich beziehe mich da durchaus mit ein, da ich hier auch schon über die 
Pager-Geschichte was geschrieben habe.

Ansonsten wird die Übersichtlichkeit in diesem Thread massiv leiden.

Meine Uhr (METE-ON 3) ist inzwischen auch eingetroffen - leider hatte 
ich noch keine Zeit, mich mit einem Datenlogger zu bewaffnen und das 
Tracen anzufangen.
In diesem Zusammenhang: die Pin-Belegung des Dechiffrier-IC ist immer 
noch nicht klar, oder habe ich das überlesen?

Danke und Gruß,
Didi

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi Mail@laeubi.de wrote:
> Möglichkeit c) Zeit ist der Startwert --> Zeit wird eh übertragen und
> ist allen Empfängern "bekannt"
>
> Möglichkeit c) ist einfach, schnell, effizent und bietet ein höchstmaß
> an Sicherheit für diesen Einsatzzweck.

Hmm... Also einen CBC aus einem öffentlichen Schlüssel... der in Form 
der Uhrzeit mitgesendet wird... Ich weiß nicht. Das klingt nach einem 
billigen XOR... Naja, alles Raterei. Loggen was das Zeug hält und dann 
mal mit Phantasie ans Werk.

Was mir auffiel, war, dass die ELV Uhr 24/7 auf Empfang ist. Etwas, dass 
mir ungewöhnlich erscheint, selbst, wenn diese Uhr mehrere (5) Wetter 
Informationen empfangen kann. Es hätte ja gereicht dann 5 mal am Tag zur 
passenden Zeit den Empfänger zu aktivieren.

Ein weiterer Umstand, der gegen das reine Zeitscheiben basierte 
Versenden von Wetterinformationen spricht, ist die Tatsache, dass 
Unwetter-Warnungen versendet werden können. Da sich diese Wetterlagen 
auch gerne kurzfristig bilden, muss es möglich sein für beliebige 
Gebiete eine Sondermeldung zwischen schieben zu können, sonst wäre das 
Feature sinnlos.
Damit sind wir aber zurück beim Datenformat, dass m.E. auch eine 
Information über die gerade gesendete Wetterzone beinhalten müsste. Es 
wäre damit möglich Sondermeldungen einzufügen, ohne die 3-Minuten regel 
zu verletzen.
Ein Empfänger, der stromsparend die Sondermeldungen ignoriert, schaltet 
zur korrekten Zeit ein, sieht anhand der Zonenkodierung, dass es vorher 
Sondermeldungen kamen und seine Zone im Verzug ist. Dann wartet er halt 
ein paar Minuten länger, bis seine Info kommt und schaltet dann ab.

Andersherum, es gibt noch freie Bits in der Tagesscheibe. Wer hat denn 
gesagt, dass diese Lückenlos ist. Warum nicht alle x Minuten eine 
Sondermeldung zulassen? Das würde es auch erklären, warum die Uhr 24/7 
auf Empfang ist.

Eine Bitte an unsere Heuristiker, die hier schon Software gebastelt 
haben um das Protokoll statistisch auszuwerten:
Kann einer von Euch mal den Bitstrom als Differenz von der Zeit 
zerlegen?
M.E. müsste es gerade in den letzten Tagen bei einem Großteil der 
Wetterinformationen einen leeren Datenblock geben, da keine schweren 
Wetter zu verzeichnen waren. Dieser Datenblock müsste sich hoffentlich 
mehrfach Täglich wiederholen.

Mal ehrlich, wenn die angepriesenen Warnungen von schwerem Wetter nicht 
kurzfristig übertragen werden können, dann ist das ganze Protokoll Mist 
und es ist nicht besser geeignet als jede Baumarkt-Wetterstation. Viel 
Aufwand um wenig Nutzen. Wer will schon erfahren, dass das, worauf er 
gestern mit dem Auto ins schleudern kam, Blitzeis war...
Also muss dafür Platz rund um die Uhr sein, sonst ist das wieder ein 
teures Produkt, dass die Menschheit nicht braucht.

Ich denke auch, dass wir im Sommer mehr Erfolg mit dem Dekodieren haben 
werden, da dann die allgemeine Wetterlage stabiler ist. Momentan ist 
immer irgendwo Wind und damit eine mehr oder weniger schnelle Änderung 
der Wetterlage möglich. Die Wahrscheinlichkeit vergleichbare 
Wetterinformationen in einem Datenstrom mit unbekanntem Anfangspunkt zu 
erhalten, ist aktuell sehr gering.

Gruß, Ulrich

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man müsste mal wissen, was in den Decoderchip reingeschrieben wird.
Wenn da nur das reingeht, was in den 14 Bits drinne war, dann wird 
definitiv nix mit der Uhrzeit initialisiert/verschlüsselt.
Wenn man dann schon dabei ist, kann man ja auch mal versuchen, das IC 
mehrfach mit der selben Datenfolge zu befüttern. Sollte dabei immer das 
Gleiche rauskommen ist es sicher kein CBC o.ä..

Gruß
Andreas

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mein Budget ist momentan arg strapaziert, daher ist das nix mit ner 
Uhr von 90..270€ nur zum zerlegen. Aber wenn jemand in der Nähe zu 
GI-WZ-WBG wohnt, das Teil hat, aber jemandem braucht, der mit einem 
schweren Agilent Mixedmode Scope umgehen kann und selbiges auch gleich 
mitbringt, dann meldet Euch. Dann ist das mit der Pinbelegung und den 
Signalen schnell gegessen.

Gruß, Ulrich

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum 
Decoder.
Ich würde eher sagen, dass da ein AVR mit dem SPI im Slavemode völlig 
ausreicht (na gut, 2 AVRs). Die Datenrate dürfte auch nicht so arg hoch 
sein, so dass man da eventuell auch mit Bitbaging aufm LPT (mit 
Levelshiftern natürlich) mitlesen kann.
Wenn ich es recht in Erinnerung habe, ist doch auch schon irgendeine 
solche Uhr fachmännisch "bedrahtet" worden. Wie sieht es denn da aus?

MfG
Andreas

Autor: No.1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> muss es möglich sein für beliebige
>Gebiete eine Sondermeldung zwischen schieben zu können, sonst wäre das
>Feature sinnlos.

Woher weiss die Uhr wo sie gerade ist?
Hamburg? Heidelberg? München?

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Lang wrote:
> Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum
> Decoder.
...

Also die Datenblätter, die hier verlinkt waren, haben ein hübsches 
Bildchen von einem 8-Pin SOIC, aber da stehen nur Nummern auf den Pinnen 
und ein hübsch buntes Blockschaltbild. Aber keine Zuordnung der Pinne zu 
den im Blockschaltbild genannten Signalen. DB 20DC-IC-deut.pdf heißt das 
Doc dazu.
Im Datenblatt wird weiterhin auf Signale an X5 und M1 bezug genommen, 
was aber mit den Ziffern 1..8 am IC nichts gemein hat.

Das witzige an dem Datenblatt ist, dass sie zu jedem Lizenzvertrag einen 
Manuel liefern... Der arme Kerl.

Gruß, Ulrich

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm...blubb

stimmt auffallend.
Der Bus ist wohl irgendein SPI-Verschnitt.
Saftung sollte einfach zu finden sein, für den Rest gibt es auch nur 
wenige möglichkeiten. Wenn man erst mal den Clock gefunden hat, sollte 
der Rest simpel sein. Ich nehme mal an, dass der Master zuerst den 
chiffrierten Kram reinblubbert und der Chip dann irgendwann mit dem 
Statuspin mitteilt, dass er fertig ist. Dann wird vermutlich noch einmal 
ein Transfer gestartet und der Master liest den Kram zurück.

Autor: Dirk W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Dirk W. wrote:
> @No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.

Den Standort stellt der Besitzer selbst ein. Allerdings werden wohl 
Daten für alle Regionen empfangen und die Standort-Einstellung wirkt 
sich nur auf die Anzeige aus.

Leider habe ich keinen (bevorzugt mehrkanaligen) Datenlogger verfügbar, 
sonst könnte ich mich da mal dranmachen.

Gruß, Didi

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bin ich nochmal ...

Habe gerade gesehen, daß in dem METE-ON 3 eine Art 
Programmierschnittstelle vorgesehen ist, die über einen kleinen Deckel 
auf der Unterseite des Gerätes auch von außen zugänglich ist. Habe mal 
zwei Bilder davon gemacht:
http://diet.gmxhome.de/pics/METE-ON3-Stecker1.jpg
http://diet.gmxhome.de/pics/METE-ON3-Stecker2.jpg

Die Pin-Bezeichnungen lauten VPP, DATA, GND, MODE und VDD. Kann sein, 
daß man da drüber die Firmware updaten kann.

Außerdem noch ein Bild von der Platine samt Decoder-Chip (hinter dem 
Elko):
http://diet.gmxhome.de/pics/METE-ON3-Platine.jpg
und eins vom DCF77-Empfänger:
http://diet.gmxhome.de/pics/METE-ON3-DCF77.jpg

Gruß, Didi

PS: Bilder übrigens sind mit einem Sony Ericsson P990i Smartphone im 
Makro-Modus aufgenommen und von 1600x1200 auf 640x480 runtergerechnet. 
Gut - die Schärfe (bzw. den Autofocus-Punkt) kann man noch optimieren, 
aber ich bin so schon ganz begeistert ;-)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schicke Fotos!

Kannst Du nicht mal versuchen, ein Foto möglichst senkrecht auf den 
Decoder Chip zu machen. Aus dem Layout sollte sich doch wenigstens die 
Pinbelegung teilweise ermitteln lassen. Nett ist doch, dass sie zur 
Ankopplung von Debuggern und Logicanalyzern direkt Messpunkte vorgesehen 
haben.

Das erleichtert die Arbeit doch ungemein :)

Gruß, Ulrich

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ulrich,

muß ich mal ausprobieren ein besseres Foto zu machen. Ist etwas 
schwierig wegen der Kabel, die recht kurz sind. Bei Gelegenheit probier 
ichs mal und bei Erfolg setze ich das Foto hier rein.

Gruß, Didi

Autor: don (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wetterstationen liefern beim Auslesen keine der 
APRS-Protokoll-Spezifikation für Wettermeldungen entprechenden 
Datenstrings. Insofern ist für die Darstellung in gängigen 
APRS-Anwendungen (z.B. UI-View) oder auf dem TH-D7, TM-D700 eine 
Umwandlung der Daten erforderlich.

Im stationären Betrieb kann eine entsprechende Umwandlung der Daten 
durch das Programm "UI-Weather" erfolgen. Die hier fragliche 
Wetterstation WS-2300 wird unterstützt. UI-Weather liest die Datei 
"curdat.lst" des beigefügten Wetterprogrammes "HeavyWeather" aus und 
generiert eine Datei "wx.txt". Hier findet sich der APRS-WX-String. 
UI-View32 greift wiederum auf diese Datei zu und versendet entsprechende 
Wetterbaken.

Problematisch ist der Betrieb hingegen, wenn ein Netzanschluss zur 
Versorgung eines Notebooks nicht verfügbar ist. Hier greifen komerzielle 
Hardwarelösungen wie "WX-Trak" von Byonics. Jedoch sind die 
unterstützten Wetterstationen in Deutschland schwerlich zu erwerben.

Ziel ist es mithin, unter Verwendung der Wetterstation WS-2300 und eines 
TNC, einen APRS -konformen Wetterstring zu erzeugen und als APRS-Bake 
auszusenden. Der Teil-String soll im Bakentext wie folgt aussehen:

_202/000g000t071r000p000b10180h46

Im Beispiel entspricht "b10180" einem Luftruck von 1018.0 hpa.

Zusätzlich sollen außerdem im "Statusfeld" weitere telemtrische Daten 
(z.B. Spannung, Helligkeit, etc.) übertragen werden.

Lösung:

Zur Lösung wurde von Joachim (DF4IAN) zunächst eine Platine für die 
Hardware-Kopplung des Einganges an die Wetterstation WS-2300 erstellt. 
Vermittels der WS.CON-Software (geschrieben mit Microchip MPLAB 
C18-Compiler in C) werden die über die erste serielle Schnittstelle bei 
der WS-2300 abgefragten Daten im integirierten PIC-18 F 252 verarbeitet. 
Der PIC-18 F 252 beinhaltet 32kByte Flash-ROM, 1.5kByte RAM, 256Byte 
EEPROM, AD-Wandler, Pulsweitenmodulator, serielle Schnittstellen, sowie 
mehrere Zeitgeber. Der Software-Kern für die Abfrage der Wetterdaten der 
WS-2300 besteht dabei in aus einer stark modifizerten Version von 
Kenneth Lavrsen’s (OZ1IDD) open2300-Software.

Die Software von Joachim unterstützt in der aktuellen Version aber zudem 
eine Analogwert-Aufbereitung mehrerer Kanäle, d.h es ist neben der 
eigentlichen Konversion der Wetterdaten auch ein Übertragen von 
Analogwerten wie z.B. U, I, Einstrahlleistung/m2, sowie uv-Strahlung 
möglich.

Am Ausgang werden die softwaremäßig im APRS-Format aufbereiteten 
Datenstrings, welche mit einem Zeitstempel der DCF-77 Uhr der 
WS-2300versehen sind, über die zweite serielle Schnittstelle an den 
Aux-Eingang des TNC 2 (mit UI-Digi 1.9 b3 Firmware) übergeben. Die Form 
der APRS-Protokoll kompatiblen Strings und die Formatierung weiterer 
telemetrischer Sensor-Daten im Statusfeld des APRS-Strings, läßt sich im 
Parametriermodus flexibel über eine seriell verbundene Eingabeeinheit 
gestalten.

In der aktuellen Version versteht Joachim das Modul ws.con, über die 
ursprüngliche Aufgabenstellung hinaus, als flexiblen Technologieträger, 
bei dem die unterschiedlichsten Eingangsdaten aufbereitet und in ein 
beliebiges Übertragungsformat umgesetzt werden können.

Autor: Michael Rubitschka (rubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Don

Schön und gratuliere!
Aber was genau hat dein Beitrag mit diesem Thread zu tun?

LG
Michael

Autor: Michele B.. (luxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe was gefunden was vielleicht auch nützlich ist:
bei Conrad gibt es jetzt eine Uhr, die auch für 50 Regionen 
Wettervorhersagen macht, allerdings soll die eine "satellitengestützte 
Funkwetterstation" sein.
Ist da vielleicht auch so eine die über DCf die daten holt? Sie kostet 
49€, für Experimente dann eigentlich eher erträglich als die 
ELV-Variante.

luxx

Autor: ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist unter http://www.wetterdirekt.com/?key=konzept  beschrieben.

also über das Pager-Netz. Nix DCF77.

Autor: Jörn Paschedag (jonnyp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für mich ist das eine manuelle Wettervorhersage, die über Satelit 
verbreitet wird.

Autor: Poul-Henning Kamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I have collected the DCF77 data stream for some time and a brief 
analysis of the new bits shows one + six correlations which give a 
strong hint about the encoding:

Collect bits 1-14 of the DCF77 timegram for periods of three minutes at 
a time and you get 42bit "meteotime" datagrams, ie: collect for minute 
00-02, 03-05, 06-08, ...57-59.

In these 42 bits, the first bit and the eight bit are always zero.

Given their respective probabilities for being set, the second and ninth 
bit are different 10% too often.

The same goes for 3rd+10th, 4th+11th, 5th+12th, 6th+13th, and 7th+14th.

It is not very often that all the first seven such pars are different, 
but it happens, and some cases even look as suspicious as this one:

   -######-------####----##-#--##-#--##---#--

The format documented in the pdf, will by nature of weather generally 
being pleasant at this time of the year, be heavy on zeros in the front 
end of the datagram, that could cause the above.

All this leads me to venture the guess that the datagrams are scrambled 
with a seven bit tapped shift-register based scrambler.

The shift register is obviously preloaded with some "magic" content at 
the start of each datagram, because otherwise the first N-ish bits would 
leak through and they clearly don't.

The other thing is that there is no such correlation for bits outside 
the first block of 14 bits of the 42 bit datagram, this could strongly 
indicate that the entire sequence of DCF77 bits are run through the 
scrambler, not just the meteotime bits.

The next logical step, is to get a "known plaintext".  With an 
"official" meteotime clock, it should be possible to "encode" the 
displayed values into a datagram, and if we know when the display 
updated, the immediately preceeding datagram is likely to be the one we 
want.

XOR'ing the "known plaintext" against the received datagram should give 
us the scrambler output for the 3 minute window, and a simple 
brute-force attack should be able to uncover the taps on the 
shiftregister and the value at the start of the 3 minute window.

Happy Hacking :-)

Poul-Henning

Autor: Mario Fischer (superdude)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Es kommt hier in einigen Postings so rueber, als ob das hier gilt:

(1) Dinge wie CBC sind in diesem Szenario nicht anwendbar
=>
(2) Zu jedem Plaintext existiert GENAU NUR EIN Ciphertext.

(1) ist korrekt: CBC geht nicht, da die Empfaenger ja nicht synchron 
starten und jederzeit aussetzen und wieder-einsteigen koennen muessen.

ABER

(2) ist falsch: Zum dem selben Plaintext koennten sehr wohl identische 
Ciphertexte existieren. Und zwar ganz ganz simpel:

Cipher := SymmetricEncrypt(Masterkey, Wetter + Zufallsstring)

('+' bezeichne hier lediglch eine Bitstring-Aneinanderkettung.)

Somit gibt es zu zwei identischen Plaintexten (Wetterdaten) NIE der 
selbe Cipher, weil sie mit unterschiedlichen Bits "gesalzen" sind!
Der Zufallsstring muss ja auch nicht besonders lang sein, um voellig 
unterschiedliche Ciphers zu identischen Plains hervorzurufen.
(vorrausgesetzt der symetrische Verschluesselungsalgorithmus ist 
halbwegs stark. Derartige Alorithmen sind allerdings auch durchaus auf 
kleinerer Hardware lauffaehig).

Die Information, auf welchen Standort sich die Wetterdaten beziehen 
muessen nicht verschluesselt gesendet werden (bei 14 CipherBits gilt es 
ja alles einzusparen was geht), sie sind ja aus Stunde:Minute ableitbar.

Fazit: Wenn der Hersteller auch nur wenige "Salt"-Bits mit einstreut, 
ist auch ein Known-Plaintext-Angriff sinnlos, und es laesst sich keine 
Tabelle
"Ciphertext <-> Plaintext" aufzubauen!

Falls es so implementiert ist schliesst das leider natuerlich auch nicht 
aus, dass zB Protokollbefehle der Art existieren, welche die Empfaenger 
dazu veranlassen, auf einen neuen Masterkey umzuschalten, wenn der alte 
kompromittiert ist.
Der neue Masterkey wuerde dann natuerlich nicht over air gehen, sondern 
nur gesagt "nehmt den 2. Masterkey aus eurer internen, 
werksseitig-initialisierten Tabelle".



Es bleibt natuerlich zu hoffen, dass das nicht so implementiert wurde 
...

Autor: Poul-Henning Kamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I wrote "CRC", not "CBC".

Poul-Henning

Autor: Mario Fischer (superdude)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Poul-Henning
hi Poul-Henning, i know you wrote CRC. CBC was mentioned above here in 
#495856.

let's hope they encrypted the weather data using a shift register as you 
estimate (or some similar security-by-obscurity stuff) - and not some 
AES.

Autor: Hein Blöd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie steht's denn mittlerweile mit Mittschnitten von DCF, angezeigten, 
und den zwischen den ICs ausgetauschten Daten?

Läßt sich vielleicht 'schon mal' die Zuordnung Region-Zeit ermitteln, 
ohne daß die Kodierung bekannt ist?
Z.B.: Sendet der Host-Controller dem meteo-chip den eingestellten 
Standort?

Woher bezieht meteotime die Wetterdaten / sind die übermittelten Daten 
auf anderem Weg uz erhalten? (sind angezeigte Daten auf der Uhr 
identisch zu einer Wetter-Seite im Netz?)

Sind die Uhren die ganze Zeit auf Empfang?
> Achtung: ist nur ca. 3 min aktiv
vs.
> ELV Uhr 24/7 auf Empfang ist

Ich bin wirklich gespannt, ob das zu knacken ist. Angesichts der 
vorhergehenden Bemühungen der PTB und anderer, ein Warnsystem zu 
implementieren (diese Informationen findet man eher, als etwas über den 
Wetterdatendeal..) ist es unverhältnismäßig, daß man für den 
Empfänger(bau) eine Lizenz kaufen muss, und das Geschäft ein Di-pol 
(schweizer Unternehmer / HKW) ist.

Autor: ProAVR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal ne blöde Frage: Sagen wir mal einer hätte den Code geknackt, 
wäre es dann nicht illegal das zu veröffentlichen??

Autor: Hein Blöd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist vielleicht ja der Grund für den abrupten Abriss der Diskussion.. 
Schön wäre dann aber ein Hinweis aus dem Kreis der Eingeweihten.. Wenn 
es nämlich möglich ist, würde ich es auch mal probieren.

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mich auch mal über ein paar Infos über den Fortschritt des 
Loggens und Vergleichens freuen!

Autor: Hein Blöd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Info von T-Systems, die den Sender betreiben:

http://www.t-systems.de/tsi/de/92946/Startseite/Ue...

Autor: DCF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Unter http://www.meteomarkt.ch/shop/catalog/index.php?cPath=2_16 gibt's 
den Wecker für mittlerweile ca. 55 EUR - das ist schon eher ein Preis, 
den ich mir vorstellen kann um ein "Referenzobjekt" zu erwerben.
Aber einen Haken gibt's: Versand nach .DE für 22,-- EUR - da stößt sich 
wohl die schweizer Post an den dt. Kunden gesund :-(

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vlt. gibts hier ja einen aus der Schweiz, der das für dich übernehmen 
kann? Vlt. hätten ja sogar mehr als eine Person interesse...

Autor: Holger Menges (holger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@all:
Wie ist denn eigentlich der Status der Signaldekodierung?
Ist da schon irgendjemand weitergekommen?

Autor: Hein Blöd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So Leute, Hosen runter! Wieso schreibt ihr nichts mehr?? Aufgegeben? Ich 
will wissen, ob man das Rätsel lösen kann! Los!

Autor: fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut dass ich diesen Thread gefunden habe!

Hier in Mainz gibt es seit einigen Monaten mit der großen Bahnhofsuhr am 
Bahnhofsgebäude. So wie es aussieht, lässt diese sich auch durch die 
Meteotime-Daten aus dem Tritt bringen. Fakt ist, dass sie nach einem 
Neueinschalten der Stromversorgung immer ein paar Tage läuft, bis wohl 
in den Bits 1-14 ein so unglückliches Muster auftritt, das sie aus dem 
Takt bringt. Dann bleibt sie einfach stehen.

Der Betreiber der Uhr, die Firma Hevert Arzneimittel (die Uhr gehört 
eigentlich zu einer Leuchtreklame) hat bereits mehrfach Techniker kommen 
lassen, die die Uhr überprüft haben, aber keinen Fehler gefunden haben 
(wie auch - das Uhrwerk ist in Ordnung). Sie haben dann immer die 
Stromversorgung unterbrochen und neu eingeschaltet, woraufhin die Uhr 
wieder ca. 1 Tag lief (ist sowas wie ein "Stadtgespräch" in Mainz, 
mittlerweile ist es schon fast eine fortlaufende Story in der 
Tageszeitung ;)

Nun, jedenfalls hat mich dieser Thread darauf gebracht, dass es 
vielleicht was mit diesen Meteo-Daten zu tun hat (vllt. wartet die uhr 
nicht brav 14 Sekunden, sondern interpretiert das erste Bit was 1 ist 
als erstes Datenbit oder so). Ich werde jedenfalls mal die Firma Hevert 
darauf hinweisen, ich weiß nicht ob die das mit dem Meteotime schon 
wissen. Vielleicht kann man der Uhr ja eine neue Firmware verpassen oder 
auch den DCF-Dekoder austauschen.

Diese Bahnhofsuhr war in den letzten Jahren morgens meine zuverlässigste 
Zeitquelle... ;)

Gruß Fabian

Autor: fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist, in meinem ersten Satz fehlt das Wort "Probleme" nach dem 8. Wort. 
;-D

Autor: 14. bit Abwarter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stehe ich jetzt komplett auf dem Schlauch? Soll das Problem tatsächlich 
an den Meteo Daten liegen?
Wie werden DCF-Dekoder ohne µC gebaut? Mit Schieberegister und solchen 
Sachen? Gibt es da eine technischen Grund die ersten 14 bits als "0" 
anzunehmen und dann ab dem 15. zu dekodieren?
Wenn nicht: Stümper!

Autor: fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube auch, dass die "Programmierer" (Entwickler, Hersteller) 
dieser Bahnhofsuhr stümperhaft gearbeitet haben.

Aber die Wetterdaten sind ja jetzt erstmal da, also muss an der Uhr 
irgendwas geändert werden. Neuer Chip oder was auch immer, jedenfalls 
finde ich die Erklärung gar nicht so unplausibel dass es irgendwas mit 
den Meteodaten zu tun hat. Schließlich trat das erste Problem mit der 
Uhr genau dann auf, nachdem die Firma Meteotime diese 14 Bit "gekauft" 
hat...

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal die zwei Tage lang geloggten Daten 
(dcf_log_2Tage_59Ticks.txt)
so umgewandelt dass in einer Zeile immer die zusammengehörenden 3 
Minuten stehen. Vielleicht hilft das beim Entschlüsseln.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich keine Anhänge schicken?

Autor: Petri (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gemeinde,

ich möchte nur etwas hinzufügen. Nach Poul-Henning Kamp (Gast)
Datum: 15.04.2007 15:17 ist jedes erste und achte Bit des ersten 14 Bit 
Satzes gleich 0. Es geht bei Minute 1 los und stellt sicherlich den Kopf 
dar.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das erste und achte Bit null sein soll, dann habe ich das oben 
falsch zusammengesetzt. Ich hätte um 00:01 Uhr anfangen müssen. Hier ist 
nochmal die richtige Version.

Ich habe mir nochmal den Beitrag von Poul-Henning Kamp durchgelesen.
Ich finde wir sollten so vorgehen wie er es beschreibt. Einmal mit einer 
Meteo-Uhr die abgelesenen Daten in Bits mithilfe des PDFs von Meteotime 
umwandeln. Dabei die Uhrzeit des Datenempfangs der eingestellten Region 
rausfinden. Dann die mitgeloggten DCF-Daten für diese Uhrzeit mit den 
Klartextdaten vergleichen und dabei den verwendeten 
Schieberegister-Algorithmus ermitteln und den Initwert bestimmen.

Oder man macht es einfacher und wartet bis irgendeiner von euch mit den 
Entschlüsselungs-ICs was rausfindet.

Autor: Dexter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi codebreakers,

Here are some infos abut the "dechiffrier-IC", discovered with an IROX 
Mete-On 3 hooked to a logger.

Without the details on the hardware, lets see the structure of 
communication:

MO3 -> DCIC (82 bits at all):
-----------------------------

0-13 (14) - first data packet (minute 1, 4, 7...)
14-27 (14) - second data packet (minute 2, 5, 8...)
28-41 (14) - third data packet (minute 3, 6, 9...)
42-49 (8) - minute (bcd)
50-57 (8) - hour (bcd)
58-65 (8) - day (bcd)
66-70 (5) - month (bcd)
71-73 (3) - weekday (bcd)
74-81 (8) - year (bcd)

Time data is the actual time. The decoding begins immediately after the 
last bit of the third packet received, so this is the time with the 
second packet transmitted.


DCIC -> MO3 (24 bits at all):
-----------------------------

0-21 - plain weather data (as described in "DB W-Protokoll-V 1.pdf", 
with a minor difference described below)
22-23 - unknown, most of the time (99%) '10', sometimes '11'

The temperature and rain data shown on the MO3 display matches exactly 
to the logged data decoded with the protocol in the pdf file.
The weather icon data is decoded as follows:

transmitted - shown
1 - 1
2 - 2
3 - 3
4 - not discovered yet
5 - 11
6 - 9
7 - not discovered yet
8 - not discovered yet
9 - not discovered yet
10 - 7
11 - 8
12 - not discovered yet
13 - 10
14 - not discovered yet
15 - not discovered yet

Other data can't be verified with the MO3, because it can display 
weather icon, temperature and rain forecast data only, and only for the 
actual day and night.

Attached You will find a log parsed with the infos above, it will make 
clear this mess.

Happy hacking,
Dexter

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich bin neu hier.

Tag zusammen  .

Das Thema interessiert mich brennend.

Vieleicht könnt ihr mit dieser Info was anfangen.





***********************************************************
Zeit (UTC):    Prognose:
22:00 - 03:59    Aktueller / kommender Tag (TODAY im Display)
04:00 - 09:59    Folgender Tag (DAY 1 im Display)
10:00 - 15:59    Darauffolgender Tag (DAY 2 im Display)
16:00 - 18:59    Darauffolgender Tag (DAY 3 im Display)
19:00 - 21:59   30 Zusatzregionen mit 2-Tages-Prognose
***********************************************************








Quelle:

http://www.wetterstationen.info/mete-on-1.php








Karl

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zunächst einmal: Klasse, dass jemand am IC mitgelogged hat.
Das ist sicher schon mal ein Schritt in die richtige Richtung.

Leider gelingt es mir nicht weitere Regelmässigkeiten zu finden.
Die Idee der XOR-Verknüpfung mit dem Ausgang eines rückgekoppelten
Schieberegisters kann man allerdings in der einfachen Form 
ausschliessen:
es gibt Datensätze die decodiert identisch sind. Wenn man jeweils zwei
solche nimmt sollten die Eingangsdaten für diese XOR verknüpft 
Rückschlüsse auf das Schieberegister zulassen. Dazu passen die Daten 
aber nicht (oder das Schieberegister ist länger als 16 bits)

Deutlich mehr Eingangsdaten könnten ein wenig helfen.

Viel wichtiger wäre aber, dass jemand mal untersucht, wie das IC
bei veränderten Eingangsdaten reagiert. Dafür ist es nötig,
dass jemand das IC entsprechend mit modifizierten Daten ansteuert.

Damit könnte man die folgenden Fragen klären:

Es gibt 82 Eingangsbits mit bis zu 42 frei wählbaren Datenbits.
Am Ausgang sind es aber nur 24 bits. Wozu dienen die restlichen bits?
a) Fehlerkorrektur  b) zusätzliche Steuerdaten c) Zufallsdaten


Dazu sollte man jeweils ein Eingangs-bit ändern: wieviele/welche bits 
ändern sich in den Ausgangsdaten?
Wenn sich bei einem bit noch nichts ändert, gibt es eindeutig einen 
Fehlerschutz für die Daten. Dann sollte man weitere bits ändern und das 
mapping vom Eingang auf den Ausgang feststellen.

Gibt es eine Abhängigkeit von vorausgegangenen Daten oder ist jeder 
3-Minuten Abschnitt einzeln decodierbar?

Dazu sollte man die Reihenfolge der Eingangsdaten verändern und 
beobachten,
ob sich das auf das Decodierergebnis auswirkt.


Ein letzter Kommentar:
Aktuell gibt es widersprüchliche Angaben dazu, wann die Daten für eine 
bestimmte Region übertragen werden:

Dexter:
00:00 - 02:59    Today-Day
03:00 - 05:59    Today-Night

http://www.wetterstationen.info/mete-on-1.php :
22:00 - 03:59    Aktueller / kommender Tag (TODAY im Display)

welche sind nun die richtigen, bzw. was ist die Quelle für die Angaben 
von Dexter?

Autor: Dexter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi "noch einer Gast",

I am working now on this "data altering project": A microcontroller will 
emulate the DCIC for the MO3 to send different plaintexts to discover 
some weather icon codes not seen yet. The same controller will also hook 
the DCIC to a PC to test different input streams:
- already received (and known as good) packets with some bits altered to 
test the error detection/correction,
- simple test packets (all zeros, all ones, etc...) to analyze the 
coding scheme.
The logs will be available soon(?)... :)

And the time problem:

Both times are the same, therefore right, because 22:00 - 03:59 is in 
UTC. Our local time (transmitted by DCF77) is UTC+2: one hour + is the 
time zone, and the another one is "daylight saving time" used in summer. 
The log shows practically the local time.

Happy hackning,
Dexter

PS: Sorry for the bad english, but my deutsch is even worse, close to 
nothing... :(

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Möglicher Lösungsansatz :  !  ?


Die Signale von der "Antenne"   (Simulierte Teildaten) an ein 
Anzeigegerät senden.  (Z.B.  nur 3 x 14 Bit   alle 3 Miuten und sonst 
KEINE Daten mehr.

Beabbachten was die Anzeige macht  !  ?


Nur mal so mein Gedanke.


P.S.  Manchmal findet auch ein Blindes Huhn ein Korn.
     Vielleicht hilft es euch, ansonsten dschnell wieder vergessen.

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs !
Lasst uns ein Wettercode Buch erbeuten und nichts wie ab nach Bletchley.
kleiner Spass.
Aber vom Prinzip her war England im 2.WK trotz des besitzes einiger 
Enigmas
nicht in der Lage ohne erbeutete Unterlagen mitzulesen.
dh. der Algor. war bekannt ,doch der war nutzlos ohne die Tages-
schlüssel.

Das Problem ist ähnlich hier:
Ich denke auch nicht ,das Keys über die Luft übetragen werden.
Die Masse an Intelligenz sitzt im IC.

Grundsätzlich muss man erstmal rausfinden ob jeweils der selbe
Input auch immer den selben Output erzeugt (an verschiedenen Uhrzeiten)
Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR)
Geber mit den Logfiles füttern und guggen was passiert.
Jetzt kann man das Logfile verändern und schaun.
und so weiter

Ich mach mit.
Gruss Andreas

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur so mal gefragt: Hat sich das niemand patentieren lassen ? Wenn ja, 
muß doch in der Patentschrift stehen, wie die ganze Sache funktioniert 
oder kann man soetwas als Firma einfach 'geheim' halten ?

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbstverständlich, kann eine Firma ein "Betriebsgeheimnis" haben, z.B. 
Cola Rezept, der rühmliche "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 
C0" key, auch glaub ich nicht das die Zusammensetzung von Chanel No.5 
irgendwo in einem Patent steht.

War jetzt der eigentlichen Sache nicht sonderlich dienlich, aber ich 
finds irrsinnig spannend, hoffentlich knackt ihr das. ;) -wiebel

Autor: AAA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR)

Geht auch standalone:
https://erlangen.ccc.de/index.php/DCF77

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Das hier ist eindeutig ein Face   ;-)

Autor: Werner A. (homebrew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das hier ist eindeutig ein Face   ;-)

aber ein hüsches...

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Face  -->  Bringt uns NICHT weiter.


Habt ihr eine  "Uhr" , bei der mann Informatieonen auslesen kann.


Ich denke so an ein Uhrmodul, das damals Conrad-Elektronik für ca. 10 
Euro hatte.

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Kann mann mit diesem Modul auch die "Wetter"-Bits einlesen  ?


http://www1.conrad.de/scripts/wgate/zcop_b2c/~flNl...

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Link nicht funktioniert, kann ich nicht schauen, was für ein 
Modul es ist (nächstes Mal bitte einfach die Bestellnummer posten) aber 
die Wetterbits empfängt prinzipiell jeder DCF77-Empfänger. Das Problem 
ist aber nicht das Empfangen, sondern das dekodieren der 
Wetterinformation.

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Habe mir aus nem AVR ne Uhr gebaut.
Wo liegen genau die Wetterbits?
von Sekunde Anfang 01 bis Ende 14   oder schon von Sekunde 00-14.
Gruss Andreas

Autor: aaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wo liegen genau die Wetterbits?
> von Sekunde Anfang 01 bis Ende 14   oder schon von Sekunde 00-14.

Kennst du http://www.dcf77.com/deutsch/kodierung.htm ?
Es müssten die ersten 14 Bit nach der Minutenmarke sein...

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur zur Info:

Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende 
aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo 
trägt. Ist zwar nicht so schick, wie das große Vorbild aus der Schweitz, 
abere dafür auch erheblich leichter zu bekommen. Kann man nur hoffen, 
dass es auch mit dem fragwürdiegn Chip bestückt ist und dieser nicht 
bereits integriert wurde.

Gruß, Ulrich

Autor: bbb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende
> aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo
> trägt.

Daten gibt's hier:
http://tinyurl.com/38e5w8

Autor: Mobifu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Habe mal bei Dexters Text Datei gleiche Outputs gesuchtund habe
festgestellt das nichtmal Ansatzweise die Inputs übereinstimmen.
Das wird wohl schwierig
Mfg Andreas

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen die Zeit und das Datum spielen ins Decoding mit rein.
Beides ändert sich in jedem Datenblock und ist niemals (wieder) gleich.

Autor: µluxx .. (uluxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber dann müsste man ja wenn man in den chip "falsche" daten 
reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche 
rausbekommen?! dann würde man sehen obs so ist oder nicht

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau. Aber das muss eben erst mal jemand ausprobieren. Soweit ich 
bisher mitgelesen habe hat es noch niemand probiert.

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt ihr das Cryptool 1.4.10
mfg andreas

Autor: AAA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Luxx:
> aber dann müsste man ja wenn man in den chip "falsche" daten
> reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche
> rausbekommen?! dann würde man sehen obs so ist oder nicht

Dexter hat geschrieben, dass er's ausprobieren möchte.


@Mobifu:
> Kennt ihr das Cryptool 1.4.10

Ist das ein hint? Leider hab' ich das falsche OS installiert :-(

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Cryptool befördert erstaunliches zu Tage.
Wenn man die Autokorrelations Funktion über einen Mitschnitt
laufen lässt der keine Uhrzeit enthält also nur die 42 Bits von ein paar
Stunden.
dann gibt es eine Periodizität mit schlüssellänge 1 ??????
Schlüssel 30 Hex
schaut mal selber .
gruss Andreas

Autor: Karl Gebhardt (gravieren)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>dann gibt es eine Periodizität mit schlüssellänge 1 ??????
>Schlüssel 30 Hex

Äh, kannst du das näher erklären!

Heißt das Input + Hex 30 (-30H)  ?



>schaut mal selber .
Wo ?

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na Cryptool runterladen und los
Schlüssel 30Hex mit XOR auf die Inputdaten.
Gruss Andreas

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehlt da zur Vollständigkeit, und um es auch ohne Cryptool 
nachvollziehen zu können, nicht noch die Information welches der 42 
Input-Bits zu welchem de 24 Output-Bits gehört? Denn bei einem einfachen 
XOR müßten ja input und output gleich lang sein.

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind doch nur statistische Betrachtungen im Bitmuster und keine
Dekodierung der Inputs.  z.B tauchen in der Autokorr. Fkt. 3 Spitzen
im Abstand von 42 Bits auf. Komisch ? 1 und 8 Bit ist klar aber das 
dritte?
Mfg Andreas

Autor: caesar (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für die "nicht Windowsnutzer" im Anhang eine PDF von Mobifu's Anregungen

Autor: caesar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant auch die automatische Vigenère Analyse:
Ermittelte Schlüssellänge: 42
Ermittelter Schlüssel: 101010010101001111100110110011111111111010
Näheres zu Vigenère: 
http://de.wikipedia.org/wiki/Polyalphabetische_Substitution

Aus den Daten in 
http://www.mikrocontroller.net/attachment/20863/dc...
wird damit:
00001100011010
10111011010111
00011100100110
10101111111101
11101111011000
01100111001100
11001000110001
10001011111010
11101010101010
11101011001110
11101111111011
01111110010010
11000001101101
10111011000001
11111100111001....

Autor: Mobifu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich den diesen Text damit analysiere erhalte ich eine
Keylänge von 35 Zeichen . Komisch ?
Andreas

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will ja keinen entmutigen, aber die Dateien mit den Daten in ASCII
Darstellung in ein Tool zu laden und auf Wunder zu hoffen
wird wohl wenig bringen.

Bisher kommt ja auch nur das heraus was vorher schon bekannt war:

-Die verschlüsselten Daten sind 42 bit lang
-Davon sind 2 bits mit Abstand 7 konstant 0

Daraus folgt, dass die Autokorrelationsfunktion periodische hohe Peaks 
im Abstand von 42 bekommt und nochmal etwa halb so hohe im Abstand von 
+/-7 um die hohen Peaks herum. (daher also 3 Peaks)

Die Vigenère Analyse spricht einfach auf diese periodische Wiederholung 
an. Und solange man Vigenère nur auf '0' und '1' anwendet, bleibt das 
sowieso eine einfache XOR Verknüpfung. Man müsste erstmal überlegen, 
wieviele bits zu einem Symbol zusammengehören, bevor das sinnvoll 
anwendbar wird.

Die oben erwähnten 0x30 als XOR Schlüssel ergeben sich wohl einfach 
daraus, dass '0'=0x30 das häufigste Zeichen ist, wenn man die Daten als 
ASCII '0' und '1' darstellt.

Trotzdem gibt es in den ersten 14 bit noch mehr Regelmässigkeiten als 
nur die beiden Werte, die konstant 0 sind. Das lässt zumindest darauf 
schliessen, dass nicht alle bits perfekt verschlüsselte Daten sind.

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum anderen läst sich nur mit den Daten aus Dexters Datei 20070716.txt 
einen Analyse durchführen. Denn dort sind Cyphertext und entsprechender 
Klartext vorhanden.

Aber ich würde mal abwarten bis Dexter den Dekoder-IC mit eigenen Daten 
gefüttert hat. Besonderst das Ergebniss von speziellen Bitmustern wie 
alles 0 und alles 1 usw. wäre hier interessant.

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch ein paar konstruktive Informationen:

Zu dem Thema gibt es zwei passende Patente bzw. Gebrauchsmuster:

DE 20 2006 017 739 U1
"Einrichtung zum Empfang verschlüsselter Informationen"

-Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet
-Beispiel: AES Verschlüsselung
-Daten und Schlüssel können bis zur Blocklänge aufgefüllt werden
-beliebige Operationen können auf die Zeitdaten angewendet werden, um 
den Schlüssel zu erzeugen


DE 20 2005 019 853.6 / EP 1798612
"Datenübertragungen in langsamen Übertragungssystemen, wie durch 
Zeitzeichensender"

22 Nutzbits + 20 Prüfbits = 42 bits
Übertragung in 3 Minuten
Minute n  :  14 Nutzbits
Minute n+1:  8 Nutzbits + 6 Prüfbits
Minute n+2:  14 Prüfbits

Die genauere Nutzung der 22 Nutzbits zu den verschiedenen Tageszeiten 
ist auch beschrieben.


Die oben beschriebene Aufteilung der Nutz und Prüfbits auf die Minuten
kann ich allerdings in den Daten bisher nicht finden.

Es würde wirklich sehr helfen, wenn jemand das IC mal mit modifizierten
Eingangsdaten füttern könnte, und die Ergebnisse berichten würde...

Autor: Mobifu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.zorc.breitbandkatze.de/crc.html
habe ich gefunden .
wenn man bischen mit spielt könnte man vermuten die ersten acht bits
gehören zu einem CrC
meine Einst. CRC Order 8/CRC Poly 4/nächsten beiden 0.
             Data länge 34/ sodas der enstehende voran gestellte Rest
             vorne und hinten immer eine Null enthält.
mfg Andreas

Autor: tatze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet
> -Beispiel: AES Verschlüsselung

Das kann man doch sicherlich ausschließen. Dann sollten die Daten doch 
etwas mehr "rauschen" und nicht so systematisch sein, wie bereits in 
anderen Postings gezeigt wurde...

Autor: Dexter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi codebreakers,

I have done more tests with DCIC. It was feed with a data packet from an 
early log, but some bits were altered to test error correction. The 
results are the following:

- First of all, the meaning of the last two (22 and 23) bits of the 
output data is now clear:
00 - decoding failed
10 - decoding passed
11 - decoding passed, but error correction was made

- Any single bit error in the time data used as key (bits 42 to 81 of 
the input) makes the decoding impossible.

- Any single bit error in the cipher text (bits 0 to 41 of the input) 
will be detected, corrected and signed in the output by DCIC.

- Double bit errors in the cipher text make the decoding impossible.

- The 0. and 7 . bits of the input data, which are always '0', are 
treated a little different: One or both of them can be inverted, the 
DCIC does not care  about it and will decode the packet without the sign 
"error correction was made". But if these don't care bits (one or both 
of them) are changed with any other bit, then the DCIC will treat this 
as double bit error, and will not decode the packet.

- If the decoding fails, then the output will show a fixed value of 
<1000000000000000000001 00> regardless of the input, so there isn't any 
chance to test the structure of the cipher algorithm with different 
tricky inputs.

Happy hacking,
Dexter

Autor: 321 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So there isn't any chance to test the structure of the cipher algorithm
> with different tricky inputs.

Is there any speed limit?
So you may input a fixed time and fuzz around the weather bits - 
brute-force checking for valid data.

As we know all three parts:
key: time
decoded: weather data
encoded: on air transmitted data
there must be a chance.

May be one should ask in sci.crypt for help...

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
With 22 data bits + 20 bits redundancy and single bit error correction:
for every valid data word there are 42 additional ones that would be
decoded with the same result (plus error correction indication).
If you just chose random data you should have a correct data word
on average every 2^20 tries i.e. one out of one Million.
If you also take the corrected into account that would be one out of
~ 25.000 tries.
Normal use could require:
5 cities  4 days  2 (day+night) = 40 decoding actions per day.
So to get one hit you would have on average an load of the decoder 
equivalent to 600 days of usage. With an increased speed at least one 
test every 3 seconds should be feasible.
The 3 seconds is just the value from the decoder datasheet.
This would give a hit on average every 21 hours. It would be interesting 
to hear which speed can be obtained in reality.

The good news: the PIC 12F509 (this is at least the decoder
in the Mebus version of the device) to my understanding
does not have any means to permanently store any information.
There is only the program EEPROM but no data EEPROM. Correct?
After a power cycle it should all be the same as before again.

So if someone can try this, it would be interesting to get a collection
of valid input data words for the same key=timestamp.
To keep this synchronized, I would suggest to start with the first
timestamp of the Dexter trace as we than already have a known correct
data word.
Having this collection of samples should allow to understand how the 
error protection is working in detail.

After that one could try different timestamps...

Autor: Dexter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
There are very hard time limits. The decoding itself takes 1.25 seconds, 
and after every decoding (or after power up) You must wait a little more 
than 30 seconds, so the overall decoding time of one packet is about 32 
seconds.

Dexter

Autor: Chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der PIC  12F509 hat keinen Daten EEPROM nur 1K Programm mit 41 Byte 
Variablen. Also ohne Spannung kein Datenerhalt. Interessant wäre die 
OSC-Beschaltung der PIN 2/3 da die Verarbeitungszeit relativ hoch ist. 
Sicherlich beabsichtigt wird der Chip in den Sleep-Modus zum Strom 
sparen geschickt.

MfG  Chip

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chip wrote:

> [...] nur 1K Programm [...]

Hat schonmal jemand, der so eine Uhr hat, versucht, das Programm 
auszulesen? Ich nehme zwar schwer an, daß die Dinger mit Code-Protection 
geflasht werden, aber es schadet ja nicht, das mal zu überprüfen... ;)

> [...] da die Verarbeitungszeit relativ hoch ist.

Die Verzögerungen könnten auch bewußt eingebaut worden sein, um das 
Reverse-Engineering zu erschweren.

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die lange Verzögerung dürfte definitiv dazu dienen, das Reverse 
Engineering zu erschweren. 30s - so lang kann nicht mal ein PIC brauchen 
um in Wallung zu kommen.

Autor: Chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deshalb die Frage nach dem Takt OSC-Beschaltung der PIN 2/3, es geht von 
außen z.B. über den vorh. Uhrenquarz 32.. kHz oder über INTOSC intern 
mit 4 MHz.
Wenn der von außen langsam getacktet ist könnte man den Pic mit max. 4 
MHz takten also 125x schneller. Das würde das Reverse-Engineering enorm 
beschleunigen.

Autor: noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal die Pins des 12F509 der Beschriftung der Testpunkte
auf der Platine der Wetterstation gegenüber gestellt.
Es handelt sich um die Mebus Wetterstation mit Meteotime Empfang von 
Real.

IC5 ist der Decoder:
VDD                    1*    8       VSS
GP5/OSC1/CLKIN   TP38  2     7  TP35 GP0/ICSPDAT
GP4/OSC2         TP36  3     6  TP37 GP1/ICSPCLK
GP3/MCLR/VPP           4     5  TP39 GP2/T0CKI

alternativ könnte noch ein anderes IC bestückt werden.
Dies hätte dann folgende Beschaltung:
                 TP37  1     8  VDD
                 TP38  2     7  MCLR/VPP
                 TP36  3     6  TP39
                 TP35  4     5  VSS

Folgende Signale sind an den Testpunkten zu finden:
TP35       clock in (high ~850us, low ~30ms)
TP36       clock out
                (während des Reintaktens der Daten:
                     wie clock in, nur einige Microsekunden verzögert
                 während der Datenausgabe:
                     invertiert zu clock in,etwas vor clock in)
TP37       data out  (24 bits)
TP38       data in   (82 bits)
TP39       control/status
               Eingabephase: low
               Ausgabephase:high
               Nachher: 45s high, alle 3s für 20us low

Die Daten ändern sich jeweils wenige Mikrosekunden vor der steigenden 
Flanke auf clock in.

Der MCLR/VPP Pin ist mit einem Kondensator verbunden, der an GND geht.

Da Pin 2 die Eingangsdaten bekommt, ist eine Verwendung als Takteingang 
ausgeschlossen.


Signale am IC:
-MCLR/VPP hat im Betrieb den gleichen Pegel wie Vdd
 (kein externer Reset im Betrieb?)
-wenn der Dekoder nicht genutzt wird, sind alle anderen Signale auf low
-alle 3 Minuten werden Daten zum Dekoder und zurück geschickt
 unabhängig davon, welche Städte gewählt worden sind

Es gibt einen Testmodus (Testtaste während des Resets gedrückt halten 
und dann mehrmals ^)
In diesem Testmodus lässt sich auch der Dekoder mit einem festen Muster 
testen:

Eingang: 01000010100011
         01101010100111
         10011000011000
10100000 Minute: 5
01001000 Stunde: 12
11001000 Tag: 13
00100    Monat:4
001      Wochentag: 4
01100000 Jahr: 06

Ausgang: 01011 10010 01010 11111 1110

Generell ist das Timing etwa folgendermassen:
82 Eingangsbits mit jeweils ~31ms: 2.5s
250ms 'Denkpause'
24 Ausgangsbits mit jeweils ~31ms: 0.7s
danach schliesst sich eine Phase an, die im Normalbetrieb 45s Sekunden 
dauert

In dieser 45s Phase ist TP39 noch auf High Pegel (mit kurzen 
Unterbrechungen von ~20us)
Die Phase kann aber offensichtlich vorher abgebrochen werden.
Im Testmodus war eine Wiederholung alle 15s möglich, da man nicht viel 
schneller durch die Punkte des Testmenüs kommt (EEPROM 
lesen/schreiben...)
Mit externer Ansteuerung sollte man also schon deutlich schneller werden 
können als bisher angenommen. Ob man auf die 3.5 Sekunden der 
eigentlichen Datenübertragung runterkommt oder die noch abkürzen kann, 
kann ich allerdings nicht sagen.


Kurze Info noch zum EEPROM auf der Platine:
es handelt sich um ein 24C512. Die 64kByte Daten werden im Wesentlichen 
wohl zum Speichern der Städtenamen, Menütexte etc., der Wetterdaten und 
Einstellungen für den Hauptprozessor verwendet. Programmcode des 
Hauptprozessors ist hier wohl nicht zu finden.
Es werden alle Daten komplett im EEPROM gespeichert. Es wird aber nur 
alle 3 Stunden ein neuer Satz geschrieben und auch die Anzeige 
angepasst. Wer also vor Ablauf der 3 Stunden einen Reset auslöst oder 
die Batterien entfernt, bekommt gar keine Daten angezeigt.
Die Zeiten sind aktuell 02:59:17 MESZ und dann alle 3 Stunden. 
Eigentlich müssten die Zeiten UTC basiert sein (00:59:17 UTC) und sich 
im Winter eine Stunde nach vorne verschieben.
Die I2C Leitungen zum EEPROM finden sich praktischerweise direkt am 16 
Pin Stecker hinter der Abdeckung.

Autor: jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
berichtigung:

1010000 0    Minute: 5
010010 0(0)  Stunde: 12 << fehler ?!
110010 0(0)  Tag: 13
00100          Monat:4
001             Wochentag: 4
01100000 0  Jahr: 6

######################################

höher als 8 stellen ohne parität gehts im zeitsignal nicht !

minute -1 parität = 7 stellen = 1010000 = 5
stunde -1 parität = 6 stellen = 010010  = 10 ! <<<
tag               = 6 stellen = 110010  = 13
wo. tag           = 3 stellen = 001     = 4  = Donnerstag
jahr -1 parität   = 8 stellen = 01100000= 6

die geklammerten nullen sind auch zuviel.

Autor: jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, monat vergessen:

minute -1 parität = 7 stellen = 1010000 = 5
stunde -1 parität = 6 stellen = 010010  = 10 ! <<<
tag               = 6 stellen = 110010  = 13
monat             = 5 stellen = 00100   = 4
wo. tag           = 3 stellen = 001     = 4  = Donnerstag
jahr -1 parität   = 8 stellen = 01100000= 6

bei stunde ist eine null zuviel und beim tag sind am ende 2 nullen 
zuviel.

stimmts nun ?

Autor: nane (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jupp
die 12 uhr angabe ist richtig gewesen mit 010010,
auch die 0 am ende der stundenreihe ist zu streichen.
und die 00 am ende von der tagesreihe ist auch unverständlich.
die frage ist - sind die nullen tatsächlich dabei gewesen,
oder sind die versehentlich bei der abschrift dazu gekommen ?

folgend ein paar, mit meiner pc-soft aufgezeichnete pakete.
1,5v funkwecker dcf-signale am gameport abgefragt.

http://dcf.cya.de
die soft für unten stehendes paketformat ist noch nicht verfügbar.
011011000100101000011000010010001100011111 1100000 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:03 Paket: 1
001001001001010110001100111110000111011001 0110000 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:06 Paket: 2
011011000000010001110001000001111011100101 1001000 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:09 Paket: 3
010100101111001110000111011010100001111101 0100100 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:12 Paket: 4
000001000000010111110011001100010100110110 1010100 1 100100 0 000001 001 10010 11100000 1 20.09.07  09:15 Paket: 5
011001001011000101011010010100110101101111 0001100 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:18 Paket: 6
001100100001100011010100111110110111110011 1000010 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:21 Paket: 7
010101100011101110111101110111011111011111 0010010 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:24 Paket: 8
000100001110011110111001000010111100110010 1110010 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:27 Paket: 9
011000100011111011111101011110011000101101 0000110 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:30 Paket: 10
010111000101010010001101011100111001011100 1100110 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:33 Paket: 11
011111100100001001010101010101001001010001 0110110 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:36 Paket: 12
011111100101010011111000010101110101011110 1001110 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:39 Paket: 13
011100000101010000111100010100011011111000 0100001 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:42 Paket: 14
011011100000001101111001101000111110111101 1010001 1 100100 0 000001 001 10010 11100000 1 20.09.07  09:45 Paket: 15
011111100100001010110110110010110111011111 0001001 0 100100 0 000001 001 10010 11100000 1 20.09.07  09:48 Paket: 16
000101100100111111100111101000101000001101 1000101 1 100100 0 000001 001 10010 11100000 1 20.09.07  09:51 Paket: 17
000100001110001111001100101000110111101011 0010101 1 100100 0 000001 001 10010 11100000 1 20.09.07  09:54 Paket: 18
010100100000101110110101111010100001000101 1110101 1 100100 0 000001 001 10010 11100000 1 20.09.07  09:57 Paket: 19
011110000000010001110001010111100110010100 0000000 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:00 Paket: 20
011101000111011100011000001001101011110111 1100000 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:03 Paket: 1
011001001010111001000010000010101011010101 0110000 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:06 Paket: 2
001000000010001100001111010100111000111101 1001000 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:09 Paket: 3
001000000010111100001111111101100111101010 0100100 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:12 Paket: 4
001111101010100001011100011000100101111110 1010100 1 000010 1 000001 001 10010 11100000 1 20.09.07  10:15 Paket: 5
010001100110010100001011001011000100010100 0001100 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:18 Paket: 6
000001000001010101100101100110011111010000 1000010 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:21 Paket: 7
011101000001010111001000111101111110111111 0010010 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:24 Paket: 8
001011000110010001001001111010111110011100 1110010 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:27 Paket: 9
010111001100010100110110111110111010000000 0000110 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:30 Paket: 10
011100100010110101001110110001100111111110 1100110 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:33 Paket: 11
001100001101110000110100111000000101000111 0110110 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:36 Paket: 12
000101100001101100011100011010000100011101 1001110 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:39 Paket: 13
010011100100110010000111000000111100011110 0100001 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:42 Paket: 14
010101100101000011011010000001100110100011 1010001 1 000010 1 000001 001 10010 11100000 1 20.09.07  10:45 Paket: 15
011001100001001111001001000101001001110001 0001001 0 000010 1 000001 001 10010 11100000 1 20.09.07  10:48 Paket: 16
000100001000001101100000111110011010001110 1000101 1 000010 1 000001 001 10010 11100000 1 20.09.07  10:51 Paket: 17
001100001000110010101001101100100110101010 0010101 1 000010 1 000001 001 10010 11100000 1 20.09.07  10:54 Paket: 18
010010101111101110000001110011000110011011 1110101 1 000010 1 000001 001 10010 11100000 1 20.09.07  10:57 Paket: 19
010101000010110110001101001101010110000000 0000000 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:00 Paket: 20
001110101100100111110010101111111110010010 1100000 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:03 Paket: 1
000001000011111101110001101101001101101101 0110000 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:06 Paket: 2
010001100011001110110110110000100000111110 1001000 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:09 Paket: 3
011001100111000001110110001111100010000111 0100100 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:12 Paket: 4
000101001110011111100001110111111100000000 1010100 1 100010 0 000001 001 10010 11100000 1 20.09.07  11:15 Paket: 5
000001000101000110101111100001110000110011 0001100 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:18 Paket: 6
001110001001110100011111001010110001110111 1000010 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:21 Paket: 7
010101001110010000100000011001110101011111 0010010 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:24 Paket: 8
001001000101110101011010100011001011000110 1110010 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:27 Paket: 9
010100100010011101001110111000011000000010 0000110 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:30 Paket: 10
000011000100111000100001010011000110100110 1100110 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:33 Paket: 11
001100101010111111001011011010100111011100 0110110 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:36 Paket: 12
001011000110010001100011000110101110111000 1001110 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:39 Paket: 13
000011001011010111100000000110101011011101 0100001 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:42 Paket: 14
000000000000010010111011001001100110100111 1010001 1 100010 0 000001 001 10010 11100000 1 20.09.07  11:45 Paket: 15
001001101011101111000100011100100110010111 0001001 0 100010 0 000001 001 10010 11100000 1 20.09.07  11:48 Paket: 16
011111000011101011110101000011001110110100 1000101 1 100010 0 000001 001 10010 11100000 1 20.09.07  11:51 Paket: 17
001111101001000011101010101110001011000100 0010101 1 100010 0 000001 001 10010 11100000 1 20.09.07  11:54 Paket: 18
010001101111011110010011110101110100101010 1110101 1 100010 0 000001 001 10010 11100000 1 20.09.07  11:57 Paket: 19
000111001100011010111000011010011110101010 0000000 0 010010 0 000001 001 10010 11100000 1 20.09.07  12:00 Paket: 20

Autor: Didi Barth (diet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen!

Habe schon ewig nicht mehr hier reingeschaut. Hut ab! Da geht ja echt 
was in Sachen Decodier-/Dechiffrier-Versuche!

Wer selbst noch eine günstige Meteotime-fähige Uhr sucht: bei ELV gibts 
inzwischen eine für 39,95 EUR mit Vier-Tages-Vorhersage: 
http://www.elv.de/output/controller.aspx?cid=74&de...
Das nächstgrößere Modell kostet 59,95 EUR und zeigt noch etwas mehr 
Daten an (Wind-Vorhersage ...): 
http://www.elv.de/output/controller.aspx?cid=74&de...
Sehr günstig, wenn man das mit der Mete-on 1 für 279 EUR vergleicht ...

Hier alle "WetterDatenStationen" bei ELV: 
http://www.elv.de/output/controller.aspx?cid=74&de...

Happy hacking,
Didi

Autor: Florian ...... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum 
gekauft?

Autor: MH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kram diesen alten Thread mal wieder nach oben. Ich habe ni