Hallo, ich habe mir mit einem ATMEGA8 und einem DCF-Empfangsmodul eine Uhr gebaut. Funktioniert super. Leider ist das empfangene DCF-Signal etwas störanfällig. Hier im Forum wurden schon verschiedene Methoden zur Fehlerkorrektur vorgestellt. Ich benutze im Moment 3 "Filter": 1) Bei jedem Sekundenimpuls wird eine Pulslängenmessung durchgeführt. Weicht die mehr als 10% von 100 bzw. 200ms ab wird das gesamte Datenpaket verworfen. 2) Ich zähle alle Sekundenimpulse innerhalb einer Minute. Wenn ungleich 59 wird ebenfalls verworfen. 3) Wenn bis hierher alles ok ist teste ich das empfangene Datenpaket auf Stunden >23 und Minuten >59. Erst dann wird die Zeit übernommen. Trotzdem hatte ich schon fehlerhafte Datenpakete. Meine Uhr sprang letzte Woche mal von 21:00 auf 10:10. Oftmals wird im Forum flg. Methode vorgeschlagen: Das empfangene Datenpaket (n) wird mit dem letzten Paket (n-1) verglichen. Abweichung sollte dann nur ein Bit (nämlich die Minute) sein. Überläufe muß man extra behandeln. Trotzdem stellt sich mir die Frage: Wie soll ich (n) mit (n-1) vergleichen? Ich weiß ja auch nicht ob (n-1) stimmt. Außerdem kann der Empfang auch mal (z.B 10 min) ausfallen. Dann habe ich ein Datenpaket (n) und muß es mit (n-10) vergleichen. Hat da noch einer eine tolle Idee wie ich meinen 4. "Filter" realisiere? Danilo
Trotzdem hatte ich schon fehlerhafte Datenpakete. Meine Uhr sprang letzte Woche mal von 21:00 auf 10:10. Hallo, nach dieser Aussage denke ich das Du ein Problem mit dem schiften hast. 21:00 ist >>1 10:10 Vielleicht liegt hier ein Fehler vor?
@ Danilo (Gast) >Fehlerkorrektur vorgestellt. Ich benutze im Moment 3 "Filter": >Außerdem kann der Empfang auch mal (z.B 10 min) ausfallen. Dann habe ich >ein Datenpaket (n) und muß es mit (n-10) vergleichen. Nein, du vergleicht einfach die nächsten aufeinanderolgenden Pakete. Wenn die lückenlos aufsteigend sind, ist alles OK. >Hat da noch einer eine tolle Idee wie ich meinen 4. "Filter" realisiere? Schön und gut, aber den wichtigsten Test hast du vergessen. Den Parity Check! MfG Falk
Hallo, bei mir läuft es so ab: 1. Impulslängencheck 2. Anzahl Impulse pro Minute 3. Parity Check 4. Wenn seit dem Einschalten überhaupt noch nicht synchronisiert wurde, dann checke ich auf gültige Zeit (Std. <24 usw.). Wenn gültig werden Datum und Zeit in die interne Uhr übernommen. Das synchronisiert flag wird aber erst gesetzt, wenn eine nachfolgende Übertragung passt, also entweder die Minute um eins höher ist oder die Minute ist 0, dann muss die Stunde um eins höher sein. Falls sie nicht passt, wird die interne Uhr nicht gesetzt, läuft aber natürlich weiter, sodass ich bei der nächsten Übertragung den gleichen Test wieder gegen die interne Uhrzeit machen kann. Das hat den Vorteil, dass ich nie komplette Zeiten speichern muss. Andererseits, wenn ich die interne auf die falsche Zeit gesetzt habe, und danach kommt die richtige, dann übernehme ich die auch. So kann es nicht passieren, dass eine einmal übernommene falsche Zeit immer weiter verwendet wird. Solange das synchronisiert flag nicht gesetzt ist, sind alle Schaltfunktionen blockiert. Ist die Zeit einmal synchronisiert werden Zeiten nur übernommen, wenn sie passen, sprich wieder der Test über die geänderte Minute. Seit ich diesen aufwändigen Check mache, habe ich keine Probleme mehr. Gruß Rolf
Wenn ein empfangenes Telegramm den parity und plausibilitätscheck übersteht dann schaue ich, ob es entweder auf 15 minuten genau mit einem zuvor empfangenen Telegramm übereinstimmt oder ob es auf 15 Minuten genau mit der internen Zeit übereinstimmt - ist eines von beiden gegeben erachte ich die Zeit als korrekt. Ein Aufbereiten von nicht ganz so sauber empfangenen Daten wäre super, wüsste aber nicht wie.
@ Rogi (Gast) >Ein Aufbereiten von nicht ganz so sauber empfangenen Daten wäre super, >wüsste aber nicht wie. Geht nicht, da keinerlei Redundanz oder gar FEC enthalten ist. Das Parity erkennt auch nur einzelne Bitfehler. MfG Falk
Viele käuflich zu erwerbende Funkuhren prüfen die Uhrzeit nur 2-3 mal in der Nacht. Die restliche Zeit des Tages wird die Uhr durch den Quarz bestimmt.
Danilo wrote: > 1) Bei jedem Sekundenimpuls wird eine Pulslängenmessung durchgeführt. > Weicht die mehr als 10% von 100 bzw. 200ms ab wird das gesamte > Datenpaket verworfen. > > 2) Ich zähle alle Sekundenimpulse innerhalb einer Minute. Wenn ungleich > 59 wird ebenfalls verworfen. Da fehlt noch die wichtige Pulsabstandsmessung, Störungen sind nämlich asynchron. Die Pulsstartflanken müssen also zueinander 1s bzw. einmal 2s Abstand haben. Und die Parität sollte man auch testen, ist ja nur sehr wenig Code (bitweises EXOR). Peter
Hallo, ich danke Euch allen für die vielen Informationen. War am WE nicht online - deshalb erst jetzt mein Blick ins Forum. Danilo
Ich habe das gleich Prob wie Danilo.... nutze zZt. folgende kriterien um daten als "echt" zu erkennen. 1. Parität der Sek Stunden gesammt 2. die empfangen Zeit muss um eins höher sein als die vorherige zeit. Dies mus widerum 3 mal hintereinander passieren, bevor ich die letzte Zeit übernehme. Aber es kommt ca. 2-3 mal die Woche vor, das auch diese Selektierung versagt. was mich zu dem Schluss kommen lässt, das die Zeit dreimal falsch empfangen wurde. Ist aber eher unwahrscheinlich. rene
Rene wrote: > Aber es kommt ca. 2-3 mal die Woche vor, das auch diese Selektierung > versagt. Dann machst Du vermutlich keine Plausibilitätstests auf Bitebene (Pulsabstand, Pulsbreite, Pulsanzahl). Ich habe noch nie falsche Zeiten gehabt (4 Selbstbauuhren im jahrelangen Einsatz). Was man einmal an Informationen wegschmeißt, kann man später durch hohen Aufwand nicht mehr korrigieren. Peter
Ich würde auch nicht mit festen Zeiten (100 / 200 ms) testen, sondern die Schwelle anhand der letzten xx empfangenen Bits errechnen. Grund: viele Empfänger verschleifen das Signal deutlich (signalstärkeabhängig). Beitrag "Re: DCF Auswerte Konzept" Der ganze Thread ist recht interessant.
Hat schon jemand Erfahrungen damit gesammelt, ob der Test auf Abweichung von 100 ms / 200 ms um 10% irgend etwas bringt? Ich untersuche nur, ob die Sekundenpulse im Abstand von 985...1015 ms kommen und entscheide 150 ms nach Start des Sekundenbits, ob eine 1 oder eine Null gekommen ist. Kommt eine Pause größer als 1500 ms, habe ich fast 500 ms Zeit, das empfangene Telegramm auszuwerten: Anzahl der Sekundenbits, Parity, Pseudo-Tetraden, ist neues Telegramm = altes Telegramm plus eine Sekunde (mit Kalenderrechnung, waren Schaltsekunden oder Zeitzonenwechsel angekündigt)? Passt das neue zum vorherigen Telegramm wird angenommen, dass das neue Telegramm OK ist und eine quarzstabil freilaufende Uhr mit dem nächsten Telegrammstart (1985...2015 ms nach der 58. Sekunde) synchronisiert. Ich will ja nicht behaupten, dass dies bombensicher ist - aber bringt ein Test auf Einhalten der vorgegeben 100 ms /200 ms da noch mehr Sicherheit? Wäre neugierig, ob das mal jemand berechnet hat... Ralli
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.