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.
Gast
#487592
Hier gibts Infos... http://www.ptb.de/de/aktuelles/archiv/presseinfos/pi2006/pitext/pi061212.htm
Gast
#487601
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
Gast
#487635
Ja, das verwendete Protokoll wäre sehr interessant...
Gast
#487724
Da gibts was näheres zum Protokoll: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf
abo
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?
Gast
#487756
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.
Gast
#487762
@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
Gast
#487767
"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.
Gast
#487779
> 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!
mist, The Slow war schneller... ;)
Gast
#487786
@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.
Gast
#487798
Kann man die Wetterstation von elv irgendwo anzapfen, um den dechiffrierten Datenstrom abzugreifen?
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...
Gast
#487812
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.
Gast
#487862
"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!
Gast
#488214
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! ;-)
Gast
#488227
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.
Gast
#488229
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
sach ma balu, das mit dem "hinten rauskommen" war aber net so wörtliche gemeint...
Gast
#488261
doch die idee ist von diesem ort dort hat man die besten gedanken an manchen tagen
Gast
#488346
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
Gast
#488358
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
abo
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
Gast
#488489
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?!?
Gast
#488512
Jaja, die Weihnachts-Keksdose als 900MHz-Resonator hab ich hier irgendwo schon mal gezeigt.
Ich habs in der CQ-DL 04/06 gesehen/gelesen.
Gast
#488516
da wars, unter "Ingenieurskunst": Beitrag "Re: Ingenieurskunst"
Gast
#488685
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
Gast
#492646
Hallo zusammen Beiliegend noch ein Auszug aus http://www.metas.ch/de/metINFO/2006/METinfo_3_06.pdf Mit Informationen zu Meteotime. Hilft aber bei der Decodierung auch nicht weiter. Gruss Konrad
abo
Vielleicht kann man ja das Wetter von www.meteotest.ch mit den Signalen vergleichen? Markus
@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,
Gast
#493613
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
@Micha, meinst du wieder für 2 Tage? Ich kann den heute Nacht um 0.00 Uhr starten und dann beliebig lange. Gruß Rolf
@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.
Gast
#493749
Hallo, hab auch was zu dem Thema. http://shop.elv.de/output/controller.aspx?cid=74&detail=10&detail2=16794&refid=702A1 Gruß Jörg
abo
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...
Gast
#493891
@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 ;-)
Gast
#493934
@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
Genau! Der (völlig unbeabsichtigte) DCF-Uhren Bug ;-)
Gast
#493988
http://www.heise.de/ct/schlagseite/99/23/gross.jpg die Y1K - Umstellung
Gast
#493997
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.
Gast
#494005
Mein Funkwecker ist 2x Abgestürzt diese Woche. Nicht das das was damit zu tun hat... panikmodus ein
@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! ;)
Gast
#494017
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.
Die ELV-Uhren hat nicht zufälligerweise Micros*** programmiert? ;-)
Gast
#494056
@ 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
Gast
#494074
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.
Gast
#494095
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.
Gast
#495115
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
many thanks! Gleich mal nächste Woche drüber herfallen... Gruß Micha,
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.
Gast
#495826
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
Wenn es denn so wäre, wie oft würden gleiche Bitfolgen (gleiche 14 Bitblöcke) bei solch einer Verschlüsselung vorkommen? (verteilt über die Zeit)
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.
Gast
#495920
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.
Wie im Wiki beschrieben kann man für den CBC Mode auch ein TimeStamp verwenden, und bei einer Zeitübertragung ist das doch ne super möglichkeit :)
Gast
#495967
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.
Gast
#496057
was drinn ist und mit welcher "genauigkeit" habe ich (oder wie es alle können auf der website lesen) aufgeschlüsselt und zusammengefasst
@kbuchegg IMHO sagt man auch heute noch Wetterfrösche zu den Meteoro-logen ;-)
Gast
#496107
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)
Gast
#496114
Hi, Christoph Kessler hat doch ganz oben im Thread den Link zur PDF geschickt: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf Da ist doch alles haarklein aufgeschlüsselt.
@Sonic DANKE!!! LG Michael
Gast
#496122
bei der beschreibung handelt es sich aber um die decheff version oder lese ich gerade was falsch
Gast
#496123
Was meinst du mit 'decheff'? Das Protokoll ist genau dasselbe wie beim Rest der Bits, also 'Quasi-BCD', bzw. Binär.
Gast
#496125
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 )
Gast
#496140
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
Gast
#496145
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
Gast
#496163
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
Gast
#496181
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
Gast
#496246
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?!
hmm, aber wenn es da nen keychange geben sollte, wie bekommen es nacher eingeschaltete stationen mit?
Gast
#496639
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
Gast
#496670
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
Gast
#496693
>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.
Gast
#496745
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
Gast
#496771
Kann dem Decodier IC eigentlich egal sein. Aber das kann man dann sicher mit der Nummer, die auch in dem pdf gedruckt ist einstellen.
Gast
#496782
@stefen du hast es überlesen es kommen alle regionen du stellst lokal ein was du willst die elv uhr kann 4 (5) regionen
Gast
#496783
ehm wieso von der stunde den wehcselnden schlüssel abhängig machen geht doch auch der tag die woche das jahr
Gast
#496802
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
Gast
#497645
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
und wenn die die daten doppelt senden. z.b. das jeder block um einen datensatz verschoben noch mal gesendet wird?
Gast
#497764
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
Gast
#497776
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 :)
Gast
#498587
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
Gast
#498588
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
Gast
#498591
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!
Gast
#499307
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.
Gast
#500298
@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
Gast
#500680
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...
Gast
#500696
@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
Gast
#500832
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.
Gast
#500911
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 ;)
Gast
#501031
> 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
Gast
#501117
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)
Gast
#501434
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?
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?
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 ;)
Gast
#501718
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
Gast
#501828
>> 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/
hmmm... das müsste man sich mal etwas genauer anschaun, das könnte durchaus sinn machen
Hy Ich finde das auch gerage interessant. mal eine frage: laut http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf ist das empfänger-modul ein UE6015. http://www.hkw-elektronik.de/deutsch/produkte/bauteile.php ist das ein standart modul wie das von reichelt/conrad? weil da ja noch signale zum modul gehen. pon ist klar, nur mit dem hld kann ich garnichts anfangen. mfg
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.
Gast
#503549
http://www.elv-downloads.de/newsletter/indexnewsletter2007_02c.htm Die nächsten, die was vom Kuchen abhaben wollen, ohne die ersten 14Sekunden gekauft zu haben. Konkurenz belebt eben das Geschäft.
@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?
Gast
#503558
JAHaa
>ohne die ersten 14Sekunden gekauft zu haben.
Wollte ich damit sagen.
Ob das stimmt?
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.
Gast
#503604
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
Hab mal nen bischen gegoogled: Hier ein paar Links: Protokoll / Frequenzen etc. http://de.wikipedia.org/wiki/POCSAG Skyper etc. : http://de.wikipedia.org/wiki/Skyper_%28Pager%29 vielleicht hilft das hier auch weiter http://funkmeldesystem.de/ Ach und übrigens: Die von e skyper und wetter.de wollen auch was vom Kuchen. Guckst du: http://www.emessage.de/de/skyper/index.html
Gast
#503616
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 ;)
Gast
#503735
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
<OT> Zitat wird nicht grün, weil das '>' nicht das erste Zeichen in der Zeile ist. </OT> Gruss Jadeclaw.
Gast
#503746
<OT> ...ist ihm nicht die Röhre verreckt!? </OT> d.
Gast
#503807
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
Christoph Kessler (db1uq) wrote:
> Einen POCSAG-Decoder für die Soundkarte gibts hier:
Danke für die Info.
Gruss
Jadeclaw.
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
Gast
#504174
16:44 Uhr - DCF-77 ist auf Sendung
Gast
#504559
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.
466,23 MHz ist Scall. Wird nur noch teilweise benutzt.
Gast
#504796
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.
Gast
#509448
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.
Auch wenn's nervt: abo
Gast
#509535
Andreas, abo ist nicht mehr nötig. Du kannst auf den Link "Email-Benachrichtigung aktivieren" klicken, das hat denselben Effekt. mfg, Stefan.
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
Gast
#510135
>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?
> -> Um welche Uhr geht es?
um die oben gepostete...
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
Gast
#510279
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
Gast
#511499
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! ;)
Definition eines Hobbys: Mit möglichst maximalen Aufwand den geringsten Nutzen erzielen ;)
Gast
#512803
Das Gehäuse ist mit 6 Schrauben verschlossen. Lässt sich ohne Garantieverschleiß öffnen. Die Drähte an das IC sind Messleitungen.
> Die Drähte an das IC sind Messleitungen.
An welchen Pin des IC liegen welche Signale an?
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
Gast
#514043
> Die Drähte an das IC sind Messleitungen.
Und - was hast du gemessen?
Gast
#518022
Ich schaue gerade den neuen elv-Sommerkatalog 2007 durch, da sind die beiden DFC77-Geräte Mete-on 1 und 3 sowie das Pager-Gerät (die Bezeichung WD 4000 sehe ich allerdings nirgends) drin. Hab mal gegoogled, hier unterhalten sich auch einige zum Thema "elv WD 4000" : http://www.wetterstationen.info/phpBB/viewtopic.php?t=10424&start=45&sid=b042423f83f049c3a4548d1f8480322c Zitat: "Wer noch den alten Scall-Dienst kennt: die Funkzonen sind mit denen von Scall identisch, habe gerade die Karten miteinander verglichen. Sowohl Zoneneinteilung als auch Nummerierung stimmen exakt überein." zu Scall gibts noch die Karte: http://www.wetterstationen.info/phpBB/download.php?id=3517&sid=e3c666ffdfe18d829e3d2f0c552c3249
Gast
#518031
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
Gast
#519371
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?
Gast
#519440
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
Gast
#520075
> 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?