Datum: 30.01.2007 23:15
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&a...). 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.
Datum: 30.01.2007 23:37
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
Datum: 31.01.2007 00:32
Ja, das verwendete Protokoll wäre sehr interessant...
Datum: 31.01.2007 09:02
Da gibts was näheres zum Protokoll: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf
Datum: 31.01.2007 09:51
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?
Datum: 31.01.2007 10:02
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.
Datum: 31.01.2007 10:04
@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
Datum: 31.01.2007 10:09
"Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die Bit-Numerierung in der Rosette des DCF-Protokolls." Die sind vermutlich irgendwie verscrambled, dazu braucht man noch einen Schlüssel
Autor:
Travel Rec.
(travelrec)
Datum: 31.01.2007 10:17
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.
Datum: 31.01.2007 10:21
> 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
Datum: 31.01.2007 10:22
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!
Datum: 31.01.2007 10:23
mist, The Slow war schneller... ;)
Datum: 31.01.2007 10:28
@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.
Datum: 31.01.2007 10:46
Kann man die Wetterstation von elv irgendwo anzapfen, um den dechiffrierten Datenstrom abzugreifen?
Autor:
Travel Rec.
(travelrec)
Datum: 31.01.2007 10:52
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...
Datum: 31.01.2007 10:56
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.
Datum: 31.01.2007 11:37
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.
Datum: 31.01.2007 11:58
"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?
Datum: 31.01.2007 12:03
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.
Datum: 31.01.2007 12:39
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!
Datum: 31.01.2007 18:33
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
Datum: 31.01.2007 18:38
@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! ;-)
Datum: 31.01.2007 19:01
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.
Datum: 31.01.2007 19:03
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
Datum: 31.01.2007 19:13
sach ma balu, das mit dem "hinten rauskommen" war aber net so wörtliche gemeint...
Datum: 31.01.2007 19:29
doch die idee ist von diesem ort dort hat man die besten gedanken an manchen tagen
Datum: 31.01.2007 22:06
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
Datum: 31.01.2007 22:18
Hallo, Zitat: "Die Genauigkeit und Stabilität der Trägerschwingung sowie die Parameter der Modulationen wurden unverändert belassen." Habe ich doch glatt übersehen, also ist kein neuer Empfänger nötig. Gruß Rene
Autor:
Travel Rec.
(travelrec)
Datum: 01.02.2007 08:28
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...?
Datum: 01.02.2007 08:29
@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!
Datum: 01.02.2007 08:32
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
Datum: 01.02.2007 08:40
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
Datum: 01.02.2007 08:47
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?!?
Datum: 01.02.2007 09:05
Jaja, die Weihnachts-Keksdose als 900MHz-Resonator hab ich hier irgendwo schon mal gezeigt.
Datum: 01.02.2007 09:07
Ich habs in der CQ-DL 04/06 gesehen/gelesen.
Datum: 01.02.2007 11:50
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
Datum: 02.02.2007 12:33
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
Datum: 02.02.2007 13:09
@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,
Datum: 02.02.2007 13:12
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
Datum: 05.02.2007 19:14
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
Datum: 06.02.2007 20:59
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
Datum: 07.02.2007 00:42
Vielleicht kann man ja das Wetter von www.meteotest.ch mit den Signalen vergleichen? Markus
Datum: 07.02.2007 06:39
@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,
Datum: 07.02.2007 21:21
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
Datum: 07.02.2007 21:31
@Micha, meinst du wieder für 2 Tage? Ich kann den heute Nacht um 0.00 Uhr starten und dann beliebig lange. Gruß Rolf
Datum: 08.02.2007 00:19
@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.
Datum: 08.02.2007 01:22
Hallo, hab auch was zu dem Thema. http://shop.elv.de/output/controller.aspx?cid=74&a... Gruß Jörg
Datum: 08.02.2007 08:15
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
Datum: 08.02.2007 09:11
@Jörg, jadeclaw: Da bin ich mal gespannt, ich hab hier im Umfeld auch einige DFC77 Empfänger die meinem support unterstehen, welche zumindest bis jetzt aufholzklopf keine Probleme machen... Jörg, hast du den eMail Verkehr mit ELV noch verfügbar? Oder anders gefragt, was für einen Typ PC-Uhr war das? Ich hab hier auch noch solche "Dongles" für den Game-Port, muss ich heute Abend mal intressehalber anwerfen! Vielleicht sollte man mal mit dem Problem an PTB herantreten. Denn immerhin sind das zwar bis jetzt nur kleinigkeiten, aber viele merken es evtl. garnicht das ihre Uhr nicht mehr Zeitsignal-Synchron läuft. Denn die meisten (mein Funkwecker inklusive) schalten einfach auf internen Clock um und laufen "falsch" weiter! @for_ro: Ja, einfach nochmal aufzeichnen, 1 oder 2 tage sollte mal für den Anfang wieder reichen. Aber mit der zeitinformation dabei. Also alle 59 Bits! Das wäre Klasse! Gruß Micha, PS: Meine Funkwetterstation mit DCF77 Empfänger zeigt -gerade aufgefallen- das Antennesymbol auch nicht mehr an. Muss ich mal heute Abend genauer untersuchen!
Autor:
Travel Rec.
(travelrec)
Datum: 08.02.2007 10:37
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...
Datum: 08.02.2007 10:39
@Travel Rec. >kaputt. Ich frage mich jetzt allerdings, wer für den Schaden aufkommt, >der bei älteren Industrie- oder Kirchturmuhren durch die >Protokollumstellung entsteht... Ganz zu schweigen von der Luftfahrt und >Navigation... Was für eine Protokollumstelleung? Die Paritätsbits haben immer nur die Zeit und Datumsbits abgedeckt. Bits 1..14 waren immer schon "dont care". MfG Falk
Autor:
Travel Rec.
(travelrec)
Datum: 08.02.2007 11:03
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 ;-)
Datum: 08.02.2007 11:18
@Travel Rec. >Das sag mal den älteren Uhren. Irgenwas müssen die ja mit den Nullen >gemacht haben. Daß die "Parität" sich nur auf das eigentliche Wer solchen Murks programmiert muss ihn auch auf eigene Kosten updaten. Oder er ist clever und macht einen Hype ala Y2K draus ;-) MfG Falk
Autor:
Travel Rec.
(travelrec)
Datum: 08.02.2007 11:42
Genau! Der (völlig unbeabsichtigte) DCF-Uhren Bug ;-)
Datum: 08.02.2007 12:09
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.
Datum: 08.02.2007 12:18
Mein Funkwecker ist 2x Abgestürzt diese Woche. Nicht das das was damit zu tun hat... panikmodus ein
Datum: 08.02.2007 12:34
@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! ;)
Datum: 08.02.2007 12:34
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.
Datum: 08.02.2007 12:41
Die ELV-Uhren hat nicht zufälligerweise Micros*** programmiert? ;-)
Datum: 08.02.2007 13:13
@ 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
Datum: 08.02.2007 13:31
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.
Datum: 08.02.2007 13:46
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.