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
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
