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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tobias S. (informatiker)


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&detail=10&detail2=16794&refid=).

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.

von einer (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von einer (Gast)


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


von Hartmut (Gast)


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

von Christoph Kessler (db1uq) (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Michael R. (rubi)


Bewertung
0 lesenswert
nicht lesenswert
abo

von Michael S. (mst)


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?

von Christoph Kessler (db1uq) (Gast)


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.

von Matti (Gast)


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

von Christoph Kessler (db1uq) (Gast)


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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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.

von The Slow (Gast)


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

von Michael S. (mst)


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!

von Michael S. (mst)


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

von Bri (Gast)


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.

von Christoph Kessler (db1uq) (Gast)


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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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...

von Christoph Kessler (db1uq) (Gast)


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.

von Michael S. (mst)


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.

von Christoph Kessler (db1uq) (Gast)


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?

von Jadeclaw D. (jadeclaw)


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.

von Michael S. (mst)


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!

von Schlebinski (Gast)


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

von Michael S. (mst)


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! ;-)

von Frank (Gast)


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.

von balu (Gast)


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

von Michael S. (mst)


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

von balu (Gast)


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

von Rene Zimmermann (Gast)


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

von Rene Zimmermann (Gast)


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

von Rene Z. (renezimmermann)


Bewertung
0 lesenswert
nicht lesenswert
abo

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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...?

von Michael S. (mst)


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!


von Michael R. (rubi)


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

von Christoph Kessler (db1uq) (Gast)


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

von Michael S. (mst)


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?!?

von Christoph Kessler (db1uq) (Gast)


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

von Michael S. (mst)


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

von Christoph Kessler (db1uq) (Gast)


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

von for_ro (Gast)


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

von B. J. (bjue)


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

von Michael S. (mst)


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,

von Michael R. (rubi)


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

von Rolf I. (for_ro)


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

von Konrad (Gast)


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

von Robert W. (rweber)


Bewertung
0 lesenswert
nicht lesenswert
abo

von Markus K. (markus-)


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

Markus

von Michael S. (mst)


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,

von Jörg (Gast)


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

von Rolf I. (for_ro)


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

von Jadeclaw D. (jadeclaw)


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.

von Jörg (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Herbert B. (bernardini)


Bewertung
0 lesenswert
nicht lesenswert
abo

von Michael R. (rubi)


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

von Michael S. (mst)


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!

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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...

von Falk (Gast)


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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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 ;-)

von Falk (Gast)


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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


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

von Christoph Kessler (db1uq) (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Christoph Kessler (db1uq) (Gast)


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.

von Sebastian Heyn (Gast)


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

von Michael S. (mst)


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! ;)

von Christoph Kessler (db1uq) (Gast)


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.

von Martin K. (maart)


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

von Jörg (Gast)


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

von Christoph Kessler (db1uq) (Gast)


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.

von Christoph Kessler (db1uq) (Gast)


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.

von Schubser_vom_Dienst (Gast)


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!

;-))

von Philipp S. (philipp)


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!

von Michael S. (mst)


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,

von Markus K. (markus-)


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

von Rolf I. (for_ro)


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

von Michael S. (mst)


Bewertung
0 lesenswert
nicht lesenswert
many thanks!

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

Gruß Micha,

von Läubi .. (laeubi) Benutzerseite


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.

von Michael S. (mst)


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!

von Läubi .. (laeubi) Benutzerseite


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.

von Rolf I. (for_ro)


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

von Bernhard S. (bernhard)


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&LOCFROM=7000&type=WORLD&name=Erfurt&id=40158



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)

von Andreas S. (andreas) (Admin) Benutzerseite Flattr this


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.

von Anton (Gast)


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.

von Ludwig W. (lordludwig)


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

von Läubi .. (laeubi) Benutzerseite


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

von Michael W. (mictronics) Benutzerseite


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)

von Uli H. (ulihuber)


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


von Läubi .. (laeubi) Benutzerseite


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.

von Florian R. (florian__)


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).

von Malte _. (malte) Benutzerseite


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.

von Läubi .. (laeubi) Benutzerseite


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.

von JoachimB (Gast)


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.

von Läubi .. (laeubi) Benutzerseite


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 :)

von balu (Gast)


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

von Markus K. (markus-)


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


von Jörn P. (jonnyp)


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.

von Karl H. (kbuchegg) (Moderator)


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.

von balu (Gast)


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

von Jörn P. (jonnyp)


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

von ernst (Gast)


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)

von Sonic (Gast)


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.

von Michael R. (rubi)


Bewertung
0 lesenswert
nicht lesenswert
@Sonic

DANKE!!!

LG
Michael

von balu (Gast)


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

von Sonic (Gast)


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.

von Andreas Kramer (Gast)


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 )

von tubie (Gast)


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

von Bernhard S. (bernhard)


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

von Sonic (Gast)


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.

von Markus K. (markus-)


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/71481_METE_ON1_manual_g.pdf

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

von wulf (Gast)


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

von Hagen R. (hagen)


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

von Andreas Kramer (Gast)


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

von Karst (Gast)


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

von Philipp S. (philipp)


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?!

von Michele B. (luxx) Benutzerseite


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

von Wolfgang (Gast)


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

von Andreas Kramer (Gast)


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

von wulf (Gast)


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.

von Steffen (Gast)


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

von wulf (Gast)


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.

von brrrrt (Gast)


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

von brrrrt (Gast)


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

von ernst (Gast)


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.

von Markus K. (markus-)


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

von Niclas (Gast)


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

von Marco S. (masterof)


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?

von Frederik Sdun (Gast)


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&detail=10&detail2=16783

mfg batman(aber psst)

von Martin F. (martin-f)


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

von matthias (Gast)


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 :)

von Andreas Weller (Gast)


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

von Andreas Weller (Gast)


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

von Andreas Weller (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vorschlag:
Unter 
http://www.distrelec.com/ishopWebFront/catalog/product.do/para/language/is/de/and/shop/is/CH/and/id/is/03/and/node/is/alagaaac/and/series/is/1.html
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

von Michael S. (mst)


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!

von DCF77 (Gast)


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.

von DCF77 (Gast)


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_thread/thread/1893933cb0a93fe4/0a5c858ef0c28377 
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.

von P. B. (pb0)


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

von dd (Gast)


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...

von Malte _. (malte) Benutzerseite


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...

von dd (Gast)


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

von eisenbahndirk (Gast)


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.

von noch einer (Gast)


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...

von Ludwig W. (lordludwig)


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 ;)

von Andreas Weller (Gast)


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

von wulf (Gast)


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)

von dd (Gast)


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?

von Ludwig W. (lordludwig)


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?

von Läubi .. (laeubi) Benutzerseite


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 ;)

von Andreas Weller (Gast)


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

von Guest (Gast)


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/

von Ludwig W. (lordludwig)


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

von John-eric K. (mockup)


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

von Ludwig W. (lordludwig)


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.

von Axel R. (Gast)


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

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

von Bernhard S. (bernhard)


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?

von Axel R. (Gast)


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

von Robert W. (rweber)


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.


von Andreas Weller (Gast)


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

von Lars P. (lhp)


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

von Lupin (Gast)


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 ;)

von Axel R. (Gast)


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

von Jadeclaw D. (jadeclaw)


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

Gruss
Jadeclaw.

von Dennis (Gast)


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

d.

von Christoph Kessler (db1uq) (Gast)


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

von Jadeclaw D. (jadeclaw)


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.

von Michael S. (michael_sch)


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

von tubie (Gast)


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

von DCF77 (Gast)


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.

von Lars P. (lhp)


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

von Christoph Kessler (db1uq) (Gast)


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.

von Albatros (Gast)


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.

von Andreas L. (andi84)


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

von Stefan M. (smay4finger)


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.

von Didi B. (diet)


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

von wulf (Gast)


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?

von Ludwig W. (lordludwig)


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

um die oben gepostete...

von Didi B. (diet)


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

von Albatros (Gast)


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.

von Bernhard S. (bernhard)


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 ?

von Didi B. (diet)


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

von Didi B. (diet)


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-%20DE%20V4.1.pdf
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

von Didi B. (diet)


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

von Michael St. (Gast)


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

von Didi B. (diet)


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

von Ludwig W. (lordludwig)


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! ;)

von Bernhard S. (bernhard)


Bewertung
0 lesenswert
nicht lesenswert
Definition eines Hobbys:

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

von Albatros (Gast)


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.

von Bernhard S. (bernhard)


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

An welchen Pin des IC liegen welche Signale an?


von Didi B. (diet)


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

von Penguin 007 (Gast)


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

Und - was hast du gemessen?

von Christoph Kessler (db1uq) (Gast)


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.php?t=10424&start=45&sid=b042423f83f049c3a4548d1f8480322c

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?id=3517&sid=e3c666ffdfe18d829e3d2f0c552c3249

von Christoph Kessler (db1uq) (Gast)


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.

von Ulrich P. (uprinz)


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

von Stephan (Gast)


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?

von Christoph Kessler (db1uq) (Gast)


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

von Läubi .. (laeubi) Benutzerseite


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.



von Didi B. (diet)


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

von Ulrich P. (uprinz)


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

von Andreas L. (andi84)


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

von Ulrich P. (uprinz)


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

von Andreas L. (andi84)


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

von No.1 (Gast)


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?

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.