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?
Thread beobachten
Seitenaufteilung abschalten