mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Störanfälliger DCF-Empfang


Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie Falk schon schrieb:
was ist mit Bits 28, 35 und 58?

Autor: for_ro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rogi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich danke Euch allen für die vielen Informationen. War am WE nicht 
online - deshalb erst jetzt mein Blick ins Forum.

Danilo

Autor: Rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.