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.
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
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?
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.
@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
"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
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.
> 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
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!
@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.
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...
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.
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.
"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?
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.
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!
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
@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! ;-)
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.
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
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
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
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...?
@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!
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
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
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?!?
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
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
@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,
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
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
@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,
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
@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.
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
@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!
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...
@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
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 ;-)
@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
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.
@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! ;)
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.
@ 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
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.
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.
Schubs!
Bitte lasst diesen Thread nicht verhungern. Ich bin zwar zu dusselig um
Substanzielles beitragen zu können, doch interessieren tut's mich
brennend!
;-))
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!
...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,
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
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
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.
...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!
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.
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
@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)
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.
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.
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
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
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
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.
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).
> 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.
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.
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.
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
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
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.
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.
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)
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 )
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
@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
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.
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
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
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
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
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
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?!
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
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
>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.
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
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.
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
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
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)
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
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 :)
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
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
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
@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!
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.
@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.
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
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...
> -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...
@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
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.
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...
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 ;)
> 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
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)
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?
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 ;)
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
>> 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/
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.
@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?
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.
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
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 ;)
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
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
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
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.
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.
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.
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
>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?
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
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.
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 ?
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
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
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
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
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
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! ;)
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
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.
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
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?
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
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.
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
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
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
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
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
> 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?
Andreas Lang wrote:
> Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum> Decoder.
...
Also die Datenblätter, die hier verlinkt waren, haben ein hübsches
Bildchen von einem 8-Pin SOIC, aber da stehen nur Nummern auf den Pinnen
und ein hübsch buntes Blockschaltbild. Aber keine Zuordnung der Pinne zu
den im Blockschaltbild genannten Signalen. DB 20DC-IC-deut.pdf heißt das
Doc dazu.
Im Datenblatt wird weiterhin auf Signale an X5 und M1 bezug genommen,
was aber mit den Ziffern 1..8 am IC nichts gemein hat.
Das witzige an dem Datenblatt ist, dass sie zu jedem Lizenzvertrag einen
Manuel liefern... Der arme Kerl.
Gruß, Ulrich
hmmm...blubb
stimmt auffallend.
Der Bus ist wohl irgendein SPI-Verschnitt.
Saftung sollte einfach zu finden sein, für den Rest gibt es auch nur
wenige möglichkeiten. Wenn man erst mal den Clock gefunden hat, sollte
der Rest simpel sein. Ich nehme mal an, dass der Master zuerst den
chiffrierten Kram reinblubbert und der Chip dann irgendwann mit dem
Statuspin mitteilt, dass er fertig ist. Dann wird vermutlich noch einmal
ein Transfer gestartet und der Master liest den Kram zurück.
Moin!
Dirk W. wrote:
> @No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Den Standort stellt der Besitzer selbst ein. Allerdings werden wohl
Daten für alle Regionen empfangen und die Standort-Einstellung wirkt
sich nur auf die Anzeige aus.
Leider habe ich keinen (bevorzugt mehrkanaligen) Datenlogger verfügbar,
sonst könnte ich mich da mal dranmachen.
Gruß, Didi
Da bin ich nochmal ...
Habe gerade gesehen, daß in dem METE-ON 3 eine Art
Programmierschnittstelle vorgesehen ist, die über einen kleinen Deckel
auf der Unterseite des Gerätes auch von außen zugänglich ist. Habe mal
zwei Bilder davon gemacht:
http://diet.gmxhome.de/pics/METE-ON3-Stecker1.jpghttp://diet.gmxhome.de/pics/METE-ON3-Stecker2.jpg
Die Pin-Bezeichnungen lauten VPP, DATA, GND, MODE und VDD. Kann sein,
daß man da drüber die Firmware updaten kann.
Außerdem noch ein Bild von der Platine samt Decoder-Chip (hinter dem
Elko):
http://diet.gmxhome.de/pics/METE-ON3-Platine.jpg
und eins vom DCF77-Empfänger:
http://diet.gmxhome.de/pics/METE-ON3-DCF77.jpg
Gruß, Didi
PS: Bilder übrigens sind mit einem Sony Ericsson P990i Smartphone im
Makro-Modus aufgenommen und von 1600x1200 auf 640x480 runtergerechnet.
Gut - die Schärfe (bzw. den Autofocus-Punkt) kann man noch optimieren,
aber ich bin so schon ganz begeistert ;-)
Schicke Fotos!
Kannst Du nicht mal versuchen, ein Foto möglichst senkrecht auf den
Decoder Chip zu machen. Aus dem Layout sollte sich doch wenigstens die
Pinbelegung teilweise ermitteln lassen. Nett ist doch, dass sie zur
Ankopplung von Debuggern und Logicanalyzern direkt Messpunkte vorgesehen
haben.
Das erleichtert die Arbeit doch ungemein :)
Gruß, Ulrich
Hallo Ulrich,
muß ich mal ausprobieren ein besseres Foto zu machen. Ist etwas
schwierig wegen der Kabel, die recht kurz sind. Bei Gelegenheit probier
ichs mal und bei Erfolg setze ich das Foto hier rein.
Gruß, Didi
Wetterstationen liefern beim Auslesen keine der
APRS-Protokoll-Spezifikation für Wettermeldungen entprechenden
Datenstrings. Insofern ist für die Darstellung in gängigen
APRS-Anwendungen (z.B. UI-View) oder auf dem TH-D7, TM-D700 eine
Umwandlung der Daten erforderlich.
Im stationären Betrieb kann eine entsprechende Umwandlung der Daten
durch das Programm "UI-Weather" erfolgen. Die hier fragliche
Wetterstation WS-2300 wird unterstützt. UI-Weather liest die Datei
"curdat.lst" des beigefügten Wetterprogrammes "HeavyWeather" aus und
generiert eine Datei "wx.txt". Hier findet sich der APRS-WX-String.
UI-View32 greift wiederum auf diese Datei zu und versendet entsprechende
Wetterbaken.
Problematisch ist der Betrieb hingegen, wenn ein Netzanschluss zur
Versorgung eines Notebooks nicht verfügbar ist. Hier greifen komerzielle
Hardwarelösungen wie "WX-Trak" von Byonics. Jedoch sind die
unterstützten Wetterstationen in Deutschland schwerlich zu erwerben.
Ziel ist es mithin, unter Verwendung der Wetterstation WS-2300 und eines
TNC, einen APRS -konformen Wetterstring zu erzeugen und als APRS-Bake
auszusenden. Der Teil-String soll im Bakentext wie folgt aussehen:
_202/000g000t071r000p000b10180h46
Im Beispiel entspricht "b10180" einem Luftruck von 1018.0 hpa.
Zusätzlich sollen außerdem im "Statusfeld" weitere telemtrische Daten
(z.B. Spannung, Helligkeit, etc.) übertragen werden.
Lösung:
Zur Lösung wurde von Joachim (DF4IAN) zunächst eine Platine für die
Hardware-Kopplung des Einganges an die Wetterstation WS-2300 erstellt.
Vermittels der WS.CON-Software (geschrieben mit Microchip MPLAB
C18-Compiler in C) werden die über die erste serielle Schnittstelle bei
der WS-2300 abgefragten Daten im integirierten PIC-18 F 252 verarbeitet.
Der PIC-18 F 252 beinhaltet 32kByte Flash-ROM, 1.5kByte RAM, 256Byte
EEPROM, AD-Wandler, Pulsweitenmodulator, serielle Schnittstellen, sowie
mehrere Zeitgeber. Der Software-Kern für die Abfrage der Wetterdaten der
WS-2300 besteht dabei in aus einer stark modifizerten Version von
Kenneth Lavrsen’s (OZ1IDD) open2300-Software.
Die Software von Joachim unterstützt in der aktuellen Version aber zudem
eine Analogwert-Aufbereitung mehrerer Kanäle, d.h es ist neben der
eigentlichen Konversion der Wetterdaten auch ein Übertragen von
Analogwerten wie z.B. U, I, Einstrahlleistung/m2, sowie uv-Strahlung
möglich.
Am Ausgang werden die softwaremäßig im APRS-Format aufbereiteten
Datenstrings, welche mit einem Zeitstempel der DCF-77 Uhr der
WS-2300versehen sind, über die zweite serielle Schnittstelle an den
Aux-Eingang des TNC 2 (mit UI-Digi 1.9 b3 Firmware) übergeben. Die Form
der APRS-Protokoll kompatiblen Strings und die Formatierung weiterer
telemetrischer Sensor-Daten im Statusfeld des APRS-Strings, läßt sich im
Parametriermodus flexibel über eine seriell verbundene Eingabeeinheit
gestalten.
In der aktuellen Version versteht Joachim das Modul ws.con, über die
ursprüngliche Aufgabenstellung hinaus, als flexiblen Technologieträger,
bei dem die unterschiedlichsten Eingangsdaten aufbereitet und in ein
beliebiges Übertragungsformat umgesetzt werden können.
Hallo,
ich habe was gefunden was vielleicht auch nützlich ist:
bei Conrad gibt es jetzt eine Uhr, die auch für 50 Regionen
Wettervorhersagen macht, allerdings soll die eine "satellitengestützte
Funkwetterstation" sein.
Ist da vielleicht auch so eine die über DCf die daten holt? Sie kostet
49€, für Experimente dann eigentlich eher erträglich als die
ELV-Variante.
luxx
I have collected the DCF77 data stream for some time and a brief
analysis of the new bits shows one + six correlations which give a
strong hint about the encoding:
Collect bits 1-14 of the DCF77 timegram for periods of three minutes at
a time and you get 42bit "meteotime" datagrams, ie: collect for minute
00-02, 03-05, 06-08, ...57-59.
In these 42 bits, the first bit and the eight bit are always zero.
Given their respective probabilities for being set, the second and ninth
bit are different 10% too often.
The same goes for 3rd+10th, 4th+11th, 5th+12th, 6th+13th, and 7th+14th.
It is not very often that all the first seven such pars are different,
but it happens, and some cases even look as suspicious as this one:
-######-------####----##-#--##-#--##---#--
The format documented in the pdf, will by nature of weather generally
being pleasant at this time of the year, be heavy on zeros in the front
end of the datagram, that could cause the above.
All this leads me to venture the guess that the datagrams are scrambled
with a seven bit tapped shift-register based scrambler.
The shift register is obviously preloaded with some "magic" content at
the start of each datagram, because otherwise the first N-ish bits would
leak through and they clearly don't.
The other thing is that there is no such correlation for bits outside
the first block of 14 bits of the 42 bit datagram, this could strongly
indicate that the entire sequence of DCF77 bits are run through the
scrambler, not just the meteotime bits.
The next logical step, is to get a "known plaintext". With an
"official" meteotime clock, it should be possible to "encode" the
displayed values into a datagram, and if we know when the display
updated, the immediately preceeding datagram is likely to be the one we
want.
XOR'ing the "known plaintext" against the received datagram should give
us the scrambler output for the 3 minute window, and a simple
brute-force attack should be able to uncover the taps on the
shiftregister and the value at the start of the 3 minute window.
Happy Hacking :-)
Poul-Henning
Hallo,
Es kommt hier in einigen Postings so rueber, als ob das hier gilt:
(1) Dinge wie CBC sind in diesem Szenario nicht anwendbar
=>
(2) Zu jedem Plaintext existiert GENAU NUR EIN Ciphertext.
(1) ist korrekt: CBC geht nicht, da die Empfaenger ja nicht synchron
starten und jederzeit aussetzen und wieder-einsteigen koennen muessen.
ABER
(2) ist falsch: Zum dem selben Plaintext koennten sehr wohl identische
Ciphertexte existieren. Und zwar ganz ganz simpel:
Cipher := SymmetricEncrypt(Masterkey, Wetter + Zufallsstring)
('+' bezeichne hier lediglch eine Bitstring-Aneinanderkettung.)
Somit gibt es zu zwei identischen Plaintexten (Wetterdaten) NIE der
selbe Cipher, weil sie mit unterschiedlichen Bits "gesalzen" sind!
Der Zufallsstring muss ja auch nicht besonders lang sein, um voellig
unterschiedliche Ciphers zu identischen Plains hervorzurufen.
(vorrausgesetzt der symetrische Verschluesselungsalgorithmus ist
halbwegs stark. Derartige Alorithmen sind allerdings auch durchaus auf
kleinerer Hardware lauffaehig).
Die Information, auf welchen Standort sich die Wetterdaten beziehen
muessen nicht verschluesselt gesendet werden (bei 14 CipherBits gilt es
ja alles einzusparen was geht), sie sind ja aus Stunde:Minute ableitbar.
Fazit: Wenn der Hersteller auch nur wenige "Salt"-Bits mit einstreut,
ist auch ein Known-Plaintext-Angriff sinnlos, und es laesst sich keine
Tabelle
"Ciphertext <-> Plaintext" aufzubauen!
Falls es so implementiert ist schliesst das leider natuerlich auch nicht
aus, dass zB Protokollbefehle der Art existieren, welche die Empfaenger
dazu veranlassen, auf einen neuen Masterkey umzuschalten, wenn der alte
kompromittiert ist.
Der neue Masterkey wuerde dann natuerlich nicht over air gehen, sondern
nur gesagt "nehmt den 2. Masterkey aus eurer internen,
werksseitig-initialisierten Tabelle".
Es bleibt natuerlich zu hoffen, dass das nicht so implementiert wurde
...
@Poul-Henning
hi Poul-Henning, i know you wrote CRC. CBC was mentioned above here in
#495856.
let's hope they encrypted the weather data using a shift register as you
estimate (or some similar security-by-obscurity stuff) - and not some
AES.
Wie steht's denn mittlerweile mit Mittschnitten von DCF, angezeigten,
und den zwischen den ICs ausgetauschten Daten?
Läßt sich vielleicht 'schon mal' die Zuordnung Region-Zeit ermitteln,
ohne daß die Kodierung bekannt ist?
Z.B.: Sendet der Host-Controller dem meteo-chip den eingestellten
Standort?
Woher bezieht meteotime die Wetterdaten / sind die übermittelten Daten
auf anderem Weg uz erhalten? (sind angezeigte Daten auf der Uhr
identisch zu einer Wetter-Seite im Netz?)
Sind die Uhren die ganze Zeit auf Empfang?
> Achtung: ist nur ca. 3 min aktiv
vs.
> ELV Uhr 24/7 auf Empfang ist
Ich bin wirklich gespannt, ob das zu knacken ist. Angesichts der
vorhergehenden Bemühungen der PTB und anderer, ein Warnsystem zu
implementieren (diese Informationen findet man eher, als etwas über den
Wetterdatendeal..) ist es unverhältnismäßig, daß man für den
Empfänger(bau) eine Lizenz kaufen muss, und das Geschäft ein Di-pol
(schweizer Unternehmer / HKW) ist.
Das ist vielleicht ja der Grund für den abrupten Abriss der Diskussion..
Schön wäre dann aber ein Hinweis aus dem Kreis der Eingeweihten.. Wenn
es nämlich möglich ist, würde ich es auch mal probieren.
Hallo!
Unter http://www.meteomarkt.ch/shop/catalog/index.php?cPath=2_16 gibt's
den Wecker für mittlerweile ca. 55 EUR - das ist schon eher ein Preis,
den ich mir vorstellen kann um ein "Referenzobjekt" zu erwerben.
Aber einen Haken gibt's: Versand nach .DE für 22,-- EUR - da stößt sich
wohl die schweizer Post an den dt. Kunden gesund :-(
Gut dass ich diesen Thread gefunden habe!
Hier in Mainz gibt es seit einigen Monaten mit der großen Bahnhofsuhr am
Bahnhofsgebäude. So wie es aussieht, lässt diese sich auch durch die
Meteotime-Daten aus dem Tritt bringen. Fakt ist, dass sie nach einem
Neueinschalten der Stromversorgung immer ein paar Tage läuft, bis wohl
in den Bits 1-14 ein so unglückliches Muster auftritt, das sie aus dem
Takt bringt. Dann bleibt sie einfach stehen.
Der Betreiber der Uhr, die Firma Hevert Arzneimittel (die Uhr gehört
eigentlich zu einer Leuchtreklame) hat bereits mehrfach Techniker kommen
lassen, die die Uhr überprüft haben, aber keinen Fehler gefunden haben
(wie auch - das Uhrwerk ist in Ordnung). Sie haben dann immer die
Stromversorgung unterbrochen und neu eingeschaltet, woraufhin die Uhr
wieder ca. 1 Tag lief (ist sowas wie ein "Stadtgespräch" in Mainz,
mittlerweile ist es schon fast eine fortlaufende Story in der
Tageszeitung ;)
Nun, jedenfalls hat mich dieser Thread darauf gebracht, dass es
vielleicht was mit diesen Meteo-Daten zu tun hat (vllt. wartet die uhr
nicht brav 14 Sekunden, sondern interpretiert das erste Bit was 1 ist
als erstes Datenbit oder so). Ich werde jedenfalls mal die Firma Hevert
darauf hinweisen, ich weiß nicht ob die das mit dem Meteotime schon
wissen. Vielleicht kann man der Uhr ja eine neue Firmware verpassen oder
auch den DCF-Dekoder austauschen.
Diese Bahnhofsuhr war in den letzten Jahren morgens meine zuverlässigste
Zeitquelle... ;)
Gruß Fabian
Stehe ich jetzt komplett auf dem Schlauch? Soll das Problem tatsächlich
an den Meteo Daten liegen?
Wie werden DCF-Dekoder ohne µC gebaut? Mit Schieberegister und solchen
Sachen? Gibt es da eine technischen Grund die ersten 14 bits als "0"
anzunehmen und dann ab dem 15. zu dekodieren?
Wenn nicht: Stümper!
Ich glaube auch, dass die "Programmierer" (Entwickler, Hersteller)
dieser Bahnhofsuhr stümperhaft gearbeitet haben.
Aber die Wetterdaten sind ja jetzt erstmal da, also muss an der Uhr
irgendwas geändert werden. Neuer Chip oder was auch immer, jedenfalls
finde ich die Erklärung gar nicht so unplausibel dass es irgendwas mit
den Meteodaten zu tun hat. Schließlich trat das erste Problem mit der
Uhr genau dann auf, nachdem die Firma Meteotime diese 14 Bit "gekauft"
hat...
Ich habe mal die zwei Tage lang geloggten Daten
(dcf_log_2Tage_59Ticks.txt)
so umgewandelt dass in einer Zeile immer die zusammengehörenden 3
Minuten stehen. Vielleicht hilft das beim Entschlüsseln.
Hallo Gemeinde,
ich möchte nur etwas hinzufügen. Nach Poul-Henning Kamp (Gast)
Datum: 15.04.2007 15:17 ist jedes erste und achte Bit des ersten 14 Bit
Satzes gleich 0. Es geht bei Minute 1 los und stellt sicherlich den Kopf
dar.
Wenn das erste und achte Bit null sein soll, dann habe ich das oben
falsch zusammengesetzt. Ich hätte um 00:01 Uhr anfangen müssen. Hier ist
nochmal die richtige Version.
Ich habe mir nochmal den Beitrag von Poul-Henning Kamp durchgelesen.
Ich finde wir sollten so vorgehen wie er es beschreibt. Einmal mit einer
Meteo-Uhr die abgelesenen Daten in Bits mithilfe des PDFs von Meteotime
umwandeln. Dabei die Uhrzeit des Datenempfangs der eingestellten Region
rausfinden. Dann die mitgeloggten DCF-Daten für diese Uhrzeit mit den
Klartextdaten vergleichen und dabei den verwendeten
Schieberegister-Algorithmus ermitteln und den Initwert bestimmen.
Oder man macht es einfacher und wartet bis irgendeiner von euch mit den
Entschlüsselungs-ICs was rausfindet.
Hi codebreakers,
Here are some infos abut the "dechiffrier-IC", discovered with an IROX
Mete-On 3 hooked to a logger.
Without the details on the hardware, lets see the structure of
communication:
MO3 -> DCIC (82 bits at all):
-----------------------------
0-13 (14) - first data packet (minute 1, 4, 7...)
14-27 (14) - second data packet (minute 2, 5, 8...)
28-41 (14) - third data packet (minute 3, 6, 9...)
42-49 (8) - minute (bcd)
50-57 (8) - hour (bcd)
58-65 (8) - day (bcd)
66-70 (5) - month (bcd)
71-73 (3) - weekday (bcd)
74-81 (8) - year (bcd)
Time data is the actual time. The decoding begins immediately after the
last bit of the third packet received, so this is the time with the
second packet transmitted.
DCIC -> MO3 (24 bits at all):
-----------------------------
0-21 - plain weather data (as described in "DB W-Protokoll-V 1.pdf",
with a minor difference described below)
22-23 - unknown, most of the time (99%) '10', sometimes '11'
The temperature and rain data shown on the MO3 display matches exactly
to the logged data decoded with the protocol in the pdf file.
The weather icon data is decoded as follows:
transmitted - shown
1 - 1
2 - 2
3 - 3
4 - not discovered yet
5 - 11
6 - 9
7 - not discovered yet
8 - not discovered yet
9 - not discovered yet
10 - 7
11 - 8
12 - not discovered yet
13 - 10
14 - not discovered yet
15 - not discovered yet
Other data can't be verified with the MO3, because it can display
weather icon, temperature and rain forecast data only, and only for the
actual day and night.
Attached You will find a log parsed with the infos above, it will make
clear this mess.
Happy hacking,
Dexter
Hi
Ich bin neu hier.
Tag zusammen .
Das Thema interessiert mich brennend.
Vieleicht könnt ihr mit dieser Info was anfangen.
***********************************************************
Zeit (UTC): Prognose:
22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display)
04:00 - 09:59 Folgender Tag (DAY 1 im Display)
10:00 - 15:59 Darauffolgender Tag (DAY 2 im Display)
16:00 - 18:59 Darauffolgender Tag (DAY 3 im Display)
19:00 - 21:59 30 Zusatzregionen mit 2-Tages-Prognose
***********************************************************
Quelle:
http://www.wetterstationen.info/mete-on-1.php
Karl
Zunächst einmal: Klasse, dass jemand am IC mitgelogged hat.
Das ist sicher schon mal ein Schritt in die richtige Richtung.
Leider gelingt es mir nicht weitere Regelmässigkeiten zu finden.
Die Idee der XOR-Verknüpfung mit dem Ausgang eines rückgekoppelten
Schieberegisters kann man allerdings in der einfachen Form
ausschliessen:
es gibt Datensätze die decodiert identisch sind. Wenn man jeweils zwei
solche nimmt sollten die Eingangsdaten für diese XOR verknüpft
Rückschlüsse auf das Schieberegister zulassen. Dazu passen die Daten
aber nicht (oder das Schieberegister ist länger als 16 bits)
Deutlich mehr Eingangsdaten könnten ein wenig helfen.
Viel wichtiger wäre aber, dass jemand mal untersucht, wie das IC
bei veränderten Eingangsdaten reagiert. Dafür ist es nötig,
dass jemand das IC entsprechend mit modifizierten Daten ansteuert.
Damit könnte man die folgenden Fragen klären:
Es gibt 82 Eingangsbits mit bis zu 42 frei wählbaren Datenbits.
Am Ausgang sind es aber nur 24 bits. Wozu dienen die restlichen bits?
a) Fehlerkorrektur b) zusätzliche Steuerdaten c) Zufallsdaten
Dazu sollte man jeweils ein Eingangs-bit ändern: wieviele/welche bits
ändern sich in den Ausgangsdaten?
Wenn sich bei einem bit noch nichts ändert, gibt es eindeutig einen
Fehlerschutz für die Daten. Dann sollte man weitere bits ändern und das
mapping vom Eingang auf den Ausgang feststellen.
Gibt es eine Abhängigkeit von vorausgegangenen Daten oder ist jeder
3-Minuten Abschnitt einzeln decodierbar?
Dazu sollte man die Reihenfolge der Eingangsdaten verändern und
beobachten,
ob sich das auf das Decodierergebnis auswirkt.
Ein letzter Kommentar:
Aktuell gibt es widersprüchliche Angaben dazu, wann die Daten für eine
bestimmte Region übertragen werden:
Dexter:
00:00 - 02:59 Today-Day
03:00 - 05:59 Today-Night
http://www.wetterstationen.info/mete-on-1.php :
22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display)
welche sind nun die richtigen, bzw. was ist die Quelle für die Angaben
von Dexter?
Hi "noch einer Gast",
I am working now on this "data altering project": A microcontroller will
emulate the DCIC for the MO3 to send different plaintexts to discover
some weather icon codes not seen yet. The same controller will also hook
the DCIC to a PC to test different input streams:
- already received (and known as good) packets with some bits altered to
test the error detection/correction,
- simple test packets (all zeros, all ones, etc...) to analyze the
coding scheme.
The logs will be available soon(?)... :)
And the time problem:
Both times are the same, therefore right, because 22:00 - 03:59 is in
UTC. Our local time (transmitted by DCF77) is UTC+2: one hour + is the
time zone, and the another one is "daylight saving time" used in summer.
The log shows practically the local time.
Happy hackning,
Dexter
PS: Sorry for the bad english, but my deutsch is even worse, close to
nothing... :(
Hi
Möglicher Lösungsansatz : ! ?
Die Signale von der "Antenne" (Simulierte Teildaten) an ein
Anzeigegerät senden. (Z.B. nur 3 x 14 Bit alle 3 Miuten und sonst
KEINE Daten mehr.
Beabbachten was die Anzeige macht ! ?
Nur mal so mein Gedanke.
P.S. Manchmal findet auch ein Blindes Huhn ein Korn.
Vielleicht hilft es euch, ansonsten dschnell wieder vergessen.
Hallo Jungs !
Lasst uns ein Wettercode Buch erbeuten und nichts wie ab nach Bletchley.
kleiner Spass.
Aber vom Prinzip her war England im 2.WK trotz des besitzes einiger
Enigmas
nicht in der Lage ohne erbeutete Unterlagen mitzulesen.
dh. der Algor. war bekannt ,doch der war nutzlos ohne die Tages-
schlüssel.
Das Problem ist ähnlich hier:
Ich denke auch nicht ,das Keys über die Luft übetragen werden.
Die Masse an Intelligenz sitzt im IC.
Grundsätzlich muss man erstmal rausfinden ob jeweils der selbe
Input auch immer den selben Output erzeugt (an verschiedenen Uhrzeiten)
Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR)
Geber mit den Logfiles füttern und guggen was passiert.
Jetzt kann man das Logfile verändern und schaun.
und so weiter
Ich mach mit.
Gruss Andreas
Nur so mal gefragt: Hat sich das niemand patentieren lassen ? Wenn ja,
muß doch in der Patentschrift stehen, wie die ganze Sache funktioniert
oder kann man soetwas als Firma einfach 'geheim' halten ?
Selbstverständlich, kann eine Firma ein "Betriebsgeheimnis" haben, z.B.
Cola Rezept, der rühmliche "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88
C0" key, auch glaub ich nicht das die Zusammensetzung von Chanel No.5
irgendwo in einem Patent steht.
War jetzt der eigentlichen Sache nicht sonderlich dienlich, aber ich
finds irrsinnig spannend, hoffentlich knackt ihr das. ;) -wiebel
Hi
Face --> Bringt uns NICHT weiter.
Habt ihr eine "Uhr" , bei der mann Informatieonen auslesen kann.
Ich denke so an ein Uhrmodul, das damals Conrad-Elektronik für ca. 10
Euro hatte.
Da der Link nicht funktioniert, kann ich nicht schauen, was für ein
Modul es ist (nächstes Mal bitte einfach die Bestellnummer posten) aber
die Wetterbits empfängt prinzipiell jeder DCF77-Empfänger. Das Problem
ist aber nicht das Empfangen, sondern das dekodieren der
Wetterinformation.
Hallo
Habe mir aus nem AVR ne Uhr gebaut.
Wo liegen genau die Wetterbits?
von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14.
Gruss Andreas
> Wo liegen genau die Wetterbits?> von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14.
Kennst du http://www.dcf77.com/deutsch/kodierung.htm ?
Es müssten die ersten 14 Bit nach der Minutenmarke sein...
Nur zur Info:
Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende
aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo
trägt. Ist zwar nicht so schick, wie das große Vorbild aus der Schweitz,
abere dafür auch erheblich leichter zu bekommen. Kann man nur hoffen,
dass es auch mit dem fragwürdiegn Chip bestückt ist und dieser nicht
bereits integriert wurde.
Gruß, Ulrich
> Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende> aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo> trägt.
Daten gibt's hier:
http://tinyurl.com/38e5w8
Hallo
Habe mal bei Dexters Text Datei gleiche Outputs gesuchtund habe
festgestellt das nichtmal Ansatzweise die Inputs übereinstimmen.
Das wird wohl schwierig
Mfg Andreas
aber dann müsste man ja wenn man in den chip "falsche" daten
reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche
rausbekommen?! dann würde man sehen obs so ist oder nicht
@Luxx:
> aber dann müsste man ja wenn man in den chip "falsche" daten> reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche> rausbekommen?! dann würde man sehen obs so ist oder nicht
Dexter hat geschrieben, dass er's ausprobieren möchte.
@Mobifu:
> Kennt ihr das Cryptool 1.4.10
Ist das ein hint? Leider hab' ich das falsche OS installiert :-(
Das Cryptool befördert erstaunliches zu Tage.
Wenn man die Autokorrelations Funktion über einen Mitschnitt
laufen lässt der keine Uhrzeit enthält also nur die 42 Bits von ein paar
Stunden.
dann gibt es eine Periodizität mit schlüssellänge 1 ??????
Schlüssel 30 Hex
schaut mal selber .
gruss Andreas
Hi
>dann gibt es eine Periodizität mit schlüssellänge 1 ??????>Schlüssel 30 Hex
Äh, kannst du das näher erklären!
Heißt das Input + Hex 30 (-30H) ?
>schaut mal selber .
Wo ?
Fehlt da zur Vollständigkeit, und um es auch ohne Cryptool
nachvollziehen zu können, nicht noch die Information welches der 42
Input-Bits zu welchem de 24 Output-Bits gehört? Denn bei einem einfachen
XOR müßten ja input und output gleich lang sein.
Das sind doch nur statistische Betrachtungen im Bitmuster und keine
Dekodierung der Inputs. z.B tauchen in der Autokorr. Fkt. 3 Spitzen
im Abstand von 42 Bits auf. Komisch ? 1 und 8 Bit ist klar aber das
dritte?
Mfg Andreas
Ich will ja keinen entmutigen, aber die Dateien mit den Daten in ASCII
Darstellung in ein Tool zu laden und auf Wunder zu hoffen
wird wohl wenig bringen.
Bisher kommt ja auch nur das heraus was vorher schon bekannt war:
-Die verschlüsselten Daten sind 42 bit lang
-Davon sind 2 bits mit Abstand 7 konstant 0
Daraus folgt, dass die Autokorrelationsfunktion periodische hohe Peaks
im Abstand von 42 bekommt und nochmal etwa halb so hohe im Abstand von
+/-7 um die hohen Peaks herum. (daher also 3 Peaks)
Die Vigenère Analyse spricht einfach auf diese periodische Wiederholung
an. Und solange man Vigenère nur auf '0' und '1' anwendet, bleibt das
sowieso eine einfache XOR Verknüpfung. Man müsste erstmal überlegen,
wieviele bits zu einem Symbol zusammengehören, bevor das sinnvoll
anwendbar wird.
Die oben erwähnten 0x30 als XOR Schlüssel ergeben sich wohl einfach
daraus, dass '0'=0x30 das häufigste Zeichen ist, wenn man die Daten als
ASCII '0' und '1' darstellt.
Trotzdem gibt es in den ersten 14 bit noch mehr Regelmässigkeiten als
nur die beiden Werte, die konstant 0 sind. Das lässt zumindest darauf
schliessen, dass nicht alle bits perfekt verschlüsselte Daten sind.
Zum anderen läst sich nur mit den Daten aus Dexters Datei 20070716.txt
einen Analyse durchführen. Denn dort sind Cyphertext und entsprechender
Klartext vorhanden.
Aber ich würde mal abwarten bis Dexter den Dekoder-IC mit eigenen Daten
gefüttert hat. Besonderst das Ergebniss von speziellen Bitmustern wie
alles 0 und alles 1 usw. wäre hier interessant.
noch ein paar konstruktive Informationen:
Zu dem Thema gibt es zwei passende Patente bzw. Gebrauchsmuster:
DE 20 2006 017 739 U1
"Einrichtung zum Empfang verschlüsselter Informationen"
-Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet
-Beispiel: AES Verschlüsselung
-Daten und Schlüssel können bis zur Blocklänge aufgefüllt werden
-beliebige Operationen können auf die Zeitdaten angewendet werden, um
den Schlüssel zu erzeugen
DE 20 2005 019 853.6 / EP 1798612
"Datenübertragungen in langsamen Übertragungssystemen, wie durch
Zeitzeichensender"
22 Nutzbits + 20 Prüfbits = 42 bits
Übertragung in 3 Minuten
Minute n : 14 Nutzbits
Minute n+1: 8 Nutzbits + 6 Prüfbits
Minute n+2: 14 Prüfbits
Die genauere Nutzung der 22 Nutzbits zu den verschiedenen Tageszeiten
ist auch beschrieben.
Die oben beschriebene Aufteilung der Nutz und Prüfbits auf die Minuten
kann ich allerdings in den Daten bisher nicht finden.
Es würde wirklich sehr helfen, wenn jemand das IC mal mit modifizierten
Eingangsdaten füttern könnte, und die Ergebnisse berichten würde...
http://www.zorc.breitbandkatze.de/crc.html
habe ich gefunden .
wenn man bischen mit spielt könnte man vermuten die ersten acht bits
gehören zu einem CrC
meine Einst. CRC Order 8/CRC Poly 4/nächsten beiden 0.
Data länge 34/ sodas der enstehende voran gestellte Rest
vorne und hinten immer eine Null enthält.
mfg Andreas
> -Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet> -Beispiel: AES Verschlüsselung
Das kann man doch sicherlich ausschließen. Dann sollten die Daten doch
etwas mehr "rauschen" und nicht so systematisch sein, wie bereits in
anderen Postings gezeigt wurde...
Hi codebreakers,
I have done more tests with DCIC. It was feed with a data packet from an
early log, but some bits were altered to test error correction. The
results are the following:
- First of all, the meaning of the last two (22 and 23) bits of the
output data is now clear:
00 - decoding failed
10 - decoding passed
11 - decoding passed, but error correction was made
- Any single bit error in the time data used as key (bits 42 to 81 of
the input) makes the decoding impossible.
- Any single bit error in the cipher text (bits 0 to 41 of the input)
will be detected, corrected and signed in the output by DCIC.
- Double bit errors in the cipher text make the decoding impossible.
- The 0. and 7 . bits of the input data, which are always '0', are
treated a little different: One or both of them can be inverted, the
DCIC does not care about it and will decode the packet without the sign
"error correction was made". But if these don't care bits (one or both
of them) are changed with any other bit, then the DCIC will treat this
as double bit error, and will not decode the packet.
- If the decoding fails, then the output will show a fixed value of
<1000000000000000000001 00> regardless of the input, so there isn't any
chance to test the structure of the cipher algorithm with different
tricky inputs.
Happy hacking,
Dexter
> So there isn't any chance to test the structure of the cipher algorithm> with different tricky inputs.
Is there any speed limit?
So you may input a fixed time and fuzz around the weather bits -
brute-force checking for valid data.
As we know all three parts:
key: time
decoded: weather data
encoded: on air transmitted data
there must be a chance.
May be one should ask in sci.crypt for help...
With 22 data bits + 20 bits redundancy and single bit error correction:
for every valid data word there are 42 additional ones that would be
decoded with the same result (plus error correction indication).
If you just chose random data you should have a correct data word
on average every 2^20 tries i.e. one out of one Million.
If you also take the corrected into account that would be one out of
~ 25.000 tries.
Normal use could require:
5 cities 4 days 2 (day+night) = 40 decoding actions per day.
So to get one hit you would have on average an load of the decoder
equivalent to 600 days of usage. With an increased speed at least one
test every 3 seconds should be feasible.
The 3 seconds is just the value from the decoder datasheet.
This would give a hit on average every 21 hours. It would be interesting
to hear which speed can be obtained in reality.
The good news: the PIC 12F509 (this is at least the decoder
in the Mebus version of the device) to my understanding
does not have any means to permanently store any information.
There is only the program EEPROM but no data EEPROM. Correct?
After a power cycle it should all be the same as before again.
So if someone can try this, it would be interesting to get a collection
of valid input data words for the same key=timestamp.
To keep this synchronized, I would suggest to start with the first
timestamp of the Dexter trace as we than already have a known correct
data word.
Having this collection of samples should allow to understand how the
error protection is working in detail.
After that one could try different timestamps...
There are very hard time limits. The decoding itself takes 1.25 seconds,
and after every decoding (or after power up) You must wait a little more
than 30 seconds, so the overall decoding time of one packet is about 32
seconds.
Dexter
Hallo,
der PIC 12F509 hat keinen Daten EEPROM nur 1K Programm mit 41 Byte
Variablen. Also ohne Spannung kein Datenerhalt. Interessant wäre die
OSC-Beschaltung der PIN 2/3 da die Verarbeitungszeit relativ hoch ist.
Sicherlich beabsichtigt wird der Chip in den Sleep-Modus zum Strom
sparen geschickt.
MfG Chip
Chip wrote:
> [...] nur 1K Programm [...]
Hat schonmal jemand, der so eine Uhr hat, versucht, das Programm
auszulesen? Ich nehme zwar schwer an, daß die Dinger mit Code-Protection
geflasht werden, aber es schadet ja nicht, das mal zu überprüfen... ;)
> [...] da die Verarbeitungszeit relativ hoch ist.
Die Verzögerungen könnten auch bewußt eingebaut worden sein, um das
Reverse-Engineering zu erschweren.
Die lange Verzögerung dürfte definitiv dazu dienen, das Reverse
Engineering zu erschweren. 30s - so lang kann nicht mal ein PIC brauchen
um in Wallung zu kommen.
Deshalb die Frage nach dem Takt OSC-Beschaltung der PIN 2/3, es geht von
außen z.B. über den vorh. Uhrenquarz 32.. kHz oder über INTOSC intern
mit 4 MHz.
Wenn der von außen langsam getacktet ist könnte man den Pic mit max. 4
MHz takten also 125x schneller. Das würde das Reverse-Engineering enorm
beschleunigen.
Ich habe mal die Pins des 12F509 der Beschriftung der Testpunkte
auf der Platine der Wetterstation gegenüber gestellt.
Es handelt sich um die Mebus Wetterstation mit Meteotime Empfang von
Real.
IC5 ist der Decoder:
VDD 1* 8 VSS
GP5/OSC1/CLKIN TP38 2 7 TP35 GP0/ICSPDAT
GP4/OSC2 TP36 3 6 TP37 GP1/ICSPCLK
GP3/MCLR/VPP 4 5 TP39 GP2/T0CKI
alternativ könnte noch ein anderes IC bestückt werden.
Dies hätte dann folgende Beschaltung:
TP37 1 8 VDD
TP38 2 7 MCLR/VPP
TP36 3 6 TP39
TP35 4 5 VSS
Folgende Signale sind an den Testpunkten zu finden:
TP35 clock in (high ~850us, low ~30ms)
TP36 clock out
(während des Reintaktens der Daten:
wie clock in, nur einige Microsekunden verzögert
während der Datenausgabe:
invertiert zu clock in,etwas vor clock in)
TP37 data out (24 bits)
TP38 data in (82 bits)
TP39 control/status
Eingabephase: low
Ausgabephase:high
Nachher: 45s high, alle 3s für 20us low
Die Daten ändern sich jeweils wenige Mikrosekunden vor der steigenden
Flanke auf clock in.
Der MCLR/VPP Pin ist mit einem Kondensator verbunden, der an GND geht.
Da Pin 2 die Eingangsdaten bekommt, ist eine Verwendung als Takteingang
ausgeschlossen.
Signale am IC:
-MCLR/VPP hat im Betrieb den gleichen Pegel wie Vdd
(kein externer Reset im Betrieb?)
-wenn der Dekoder nicht genutzt wird, sind alle anderen Signale auf low
-alle 3 Minuten werden Daten zum Dekoder und zurück geschickt
unabhängig davon, welche Städte gewählt worden sind
Es gibt einen Testmodus (Testtaste während des Resets gedrückt halten
und dann mehrmals ^)
In diesem Testmodus lässt sich auch der Dekoder mit einem festen Muster
testen:
Eingang: 01000010100011
01101010100111
10011000011000
10100000 Minute: 5
01001000 Stunde: 12
11001000 Tag: 13
00100 Monat:4
001 Wochentag: 4
01100000 Jahr: 06
Ausgang: 01011 10010 01010 11111 1110
Generell ist das Timing etwa folgendermassen:
82 Eingangsbits mit jeweils ~31ms: 2.5s
250ms 'Denkpause'
24 Ausgangsbits mit jeweils ~31ms: 0.7s
danach schliesst sich eine Phase an, die im Normalbetrieb 45s Sekunden
dauert
In dieser 45s Phase ist TP39 noch auf High Pegel (mit kurzen
Unterbrechungen von ~20us)
Die Phase kann aber offensichtlich vorher abgebrochen werden.
Im Testmodus war eine Wiederholung alle 15s möglich, da man nicht viel
schneller durch die Punkte des Testmenüs kommt (EEPROM
lesen/schreiben...)
Mit externer Ansteuerung sollte man also schon deutlich schneller werden
können als bisher angenommen. Ob man auf die 3.5 Sekunden der
eigentlichen Datenübertragung runterkommt oder die noch abkürzen kann,
kann ich allerdings nicht sagen.
Kurze Info noch zum EEPROM auf der Platine:
es handelt sich um ein 24C512. Die 64kByte Daten werden im Wesentlichen
wohl zum Speichern der Städtenamen, Menütexte etc., der Wetterdaten und
Einstellungen für den Hauptprozessor verwendet. Programmcode des
Hauptprozessors ist hier wohl nicht zu finden.
Es werden alle Daten komplett im EEPROM gespeichert. Es wird aber nur
alle 3 Stunden ein neuer Satz geschrieben und auch die Anzeige
angepasst. Wer also vor Ablauf der 3 Stunden einen Reset auslöst oder
die Batterien entfernt, bekommt gar keine Daten angezeigt.
Die Zeiten sind aktuell 02:59:17 MESZ und dann alle 3 Stunden.
Eigentlich müssten die Zeiten UTC basiert sein (00:59:17 UTC) und sich
im Winter eine Stunde nach vorne verschieben.
Die I2C Leitungen zum EEPROM finden sich praktischerweise direkt am 16
Pin Stecker hinter der Abdeckung.
@jupp
die 12 uhr angabe ist richtig gewesen mit 010010,
auch die 0 am ende der stundenreihe ist zu streichen.
und die 00 am ende von der tagesreihe ist auch unverständlich.
die frage ist - sind die nullen tatsächlich dabei gewesen,
oder sind die versehentlich bei der abschrift dazu gekommen ?
folgend ein paar, mit meiner pc-soft aufgezeichnete pakete.
1,5v funkwecker dcf-signale am gameport abgefragt.
http://dcf.cya.de
die soft für unten stehendes paketformat ist noch nicht verfügbar.
Ich kram diesen alten Thread mal wieder nach oben. Ich habe nicht mehr
verfolgt, ob jemand das Protokoll selbst gehackt hat, aber wie ich grade
beim Einkaufen gesehen habe, steht wohl im aktuellen EAM-Magazin 7/2007
(http://www.eam-magazin.de/) ein Artikel mit der Aufschlüsselung des
Protokolls drin. Eventuell interessiert das ja noch jemanden.
Wenn du die Zeitschrifst kaufst, wirst du dich ärgern: Da steht
sinngemäß drin, dass es keine Nachbauanleitung zu einer DCF Uhr mit
Wetteranzeige geben wird. Es werden nur die bereits dekodierten Bits
beschrieben.
Das passt.
Man verprellt seine Geschäftspartner (=Lizenznehmer) nicht,
indem man ihnen die Grundlage des Geschäftsmodells nimmt.
Noch läuft die Geldmaschine und es besteht keine Veranlassung,
sie durch vorzeitige Offenlegung des Protokoll kaputt zu
machen.
Aber kauft euch mal schön alle das Heft EAM.
Die anderen Artikel sind vielleicht auch interessant. ;-)
Micha wrote:
> Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah> so aus, als wäre es komplett. Sorry für die "Falschmeldung"
Ging mir anfangs auch so. In der Mitte des Artikels ist ein Kästchen wo
relativ deutlich steht, dass die das Protokoll nicht veröffentlichen
dürfen. Es hätte mich auch gewundert, wenn die jetzt doch das Protokoll
komplett abdrucken.