Hey, aktuelle beschäftige ich mich damit das DCF77-Signal zu empfangen, zu dekodieren und bei "Plausibilität" die Zeit an eine RTC zu übertragen. Soweit klappt das alles schon ganz gut.. aber natürlich hätte ich da auch noch Fragen ;). 1. Wie kann man am geschicktesten überprüfen, ob die empfangenen und dekodierten Daten auch wirklich korrekt sind? Die Parität-Bits werden natürlich überprüft. Sollte ich ansonsten einfach nur schauen, dass die neu empfangenen Daten zu denen passen die bereits vorliegen? 2. Dienen die Bits 17 und 18, die sich auf die MEZ/MESZ beziehen, nur der Information? - ist die übertragene Uhrzeit bereits korrekt (in Deutschland geltende Zeit) oder muss ggf. eine Art Offset hinzugezogen werden? Mit freundlichen Grüßen Daniel
Daniel H. schrieb: > Sollte ich ansonsten > einfach nur schauen, dass die neu empfangenen Daten zu denen passen die > bereits vorliegen? Ja, einfach gegen die letzte empfangene Minute gegenchecken. > 2. Dienen die Bits 17 und 18, die sich auf die MEZ/MESZ beziehen, nur > der Information? Ja. > - ist die übertragene Uhrzeit bereits korrekt (in Deutschland geltende > Zeit) oder muss ggf. eine Art Offset hinzugezogen werden? Ist bereits korrekt - müsstest Du eigentlich schon selbst bemerkt haben ;-) Also ist kein Offset hinzuzurechnen.
> Wie kann man am geschicktesten überprüfen, ob die > empfangenen und dekodierten Daten auch wirklich korrekt sind? Zum einen sind da natürlich die Prüfbits. Zum Anderen solltest du die empfangene Zeit mit einer bekannten Zeit vergleichen. Ist die Abweichung mur wenige Sekunden, dann hast du warscheinlich korrekt empfangen. Ist die Abweichung >1 Minute, dann gehe einen Schritt weiter: Empfange zwei aufeinanderfolgende Telegramme, und vergleiche, um wie viele Minuten sie sich unterscheiden. Das müsste exakt eine Minute sein. Wenn das der Fall ist, kannst du diesen Wert zur Anzeige bringen. Oder (für ganz paranoide) machst du das halt dreimal oder fünf mal. jedes telegramm muss genau eine Minute weiter sein, als das von davor. Es gibt auch geschicktere Methoden, die bei heftigen Übertragungsstörungen schneller zum Erfolg führen. Doch in der Praxis bin ich sicher, dass das so ausreicht. > Dienen die Bits 17 und 18, die sich auf die MEZ/MESZ beziehen, > nur der Information? Ja. Alle Bits dienen nur der Information - genau genommen. > ist die übertragene Uhrzeit bereits korrekt Ja, die übermittelten Zahlen entspechen dem, was man auf der 7-Segemtn Anzeige sehen will. Das Sommer/Winterzeit Flag zeigen Uhren normalerweise nicht an. Du wirst es aber brauchen, wenn du die empfangenen Daten durch Vergleich mit der aktuellen uhrzeit validieren willst. Denn nach der Umstellung ist die Zeitabweichung ja nicht kleiner als 1 Minute, sondern größer als 1 Stunde.
Störungen sind asynchron zum Nutzsignal, d.h. die Pulsbreite (100ms, 200ms) oder die Pulsfolge (1000ms, 2000ms) sowie die Pulsanzahl (59) stimmen nicht mehr. Man legt also Fehlerbereiche fest, in denen die Zeiten liegen müssen.
Alles klar.. vielen Dank ;) Frank M. schrieb: > Ist bereits korrekt - müsstest Du eigentlich schon selbst bemerkt haben > ;-) Jap, mir ist wohl aufgefallen dass die Zeit zu stimmen scheint. Wollte nur sichergehen, dass die Uhrzeit auch bei der nächsten Zeitumstellung korrekt ist und ich jetzt gerade nicht einfach "Glück" hatte ;).
Stefan U. schrieb: > Empfange zwei aufeinanderfolgende Telegramme, und vergleiche, um wie > viele Minuten sie sich unterscheiden. Das müsste exakt eine Minute sein. > Wenn das der Fall ist, kannst du diesen Wert zur Anzeige bringen. Dann werde ich das mal implementieren. Stefan U. schrieb: > Ja. Alle Bits dienen nur der Information - genau genommen. Da stimmt natürlich - verzeih mir bitte die sprachliche Ungenauigkeit ;) Stefan U. schrieb: > Du wirst es aber brauchen, wenn du die > empfangenen Daten durch Vergleich mit der aktuellen uhrzeit validieren > willst. Gut, so hatte ich mir das auch gedacht. Peter D. schrieb: > Man legt also Fehlerbereiche fest, in denen die > Zeiten liegen müssen. Ich habe es momentan so gelöst, dass ich die folgenden Bereiche akzeptiere: 40 - 130ms 140 - 230ms 1500 - 2500ms Wenn nach der Synchronisations ein kürzerer oder längerer Puls liegt oder die Pulszahl zwischen 2 Synchronisationen nicht genau 59 beträgt, wird der empfangene Teil verworfen.
Daniel H. schrieb: > Ich habe es momentan so gelöst, dass ich die folgenden Bereiche > akzeptiere: > 40 - 130ms > 140 - 230ms > 1500 - 2500ms Da fehlt noch ne Zeitprüfung. Auch die Abstände der Datenpulse müssen stimmen. Ich würde die Bereiche enger setzen.
Daniel H. schrieb: > die Pulszahl zwischen 2 Synchronisationen nicht genau 59 beträgt Achtung: In manchen Fällen können es auch 60 sein und zwar immer dann, wenn es eine Schaltsekunde eingefügt werden muss. > Bei einer Minute ohne Schaltsekunde wird zur 59. Sekunde keine Sekundenmarke gesendet. Bei einer Minute mit Schaltsekunde wird zur 59. Sekunde eine „0“ und zur 60. Sekunde keine Sekundenmarke gesendet. https://de.wikipedia.org/wiki/DCF77
> Zum einen sind da natürlich die Prüfbits. Zum Anderen solltest du die > empfangene Zeit mit einer bekannten Zeit vergleichen. Wozu das. Macht nur Probleme beim Start und bei der Zeitumstellung. Ich prüfe die 100/200ms Signale auf Plausiblität, die ausfallende 59. Sekunde, die obligatorischen Einsen und die Paritätsbits. Wenn das alles stimmt, stimmt's auch. Ich habe noch nie eine falsche Uhrzeit auf meiner Uhr gesehen (seit 2-3 Jahren)
> Wozu das?
Wenn der Empfang auf diese Weise schon nach einer Minute erfolgreich
ist, kann man danach den Funkempfänger aus schalten und spart
Batteriestrom.
Ist natürlich nur bei Batteriebetrieb von Bedeutung.
Daniel H. schrieb: > 1. Wie kann man am geschicktesten überprüfen, ob die empfangenen und > dekodierten Daten auch wirklich korrekt sind? mit Verstand? gibt es 27:66 Uhr? gibt es den 30.2.Jahr?(beliebig) gibt es einen Wochentag8? das ist ja neben den Paritätsbits leicht zu prüfen. Ich hatte durch Störungen und falschen low high Grenzen solche Werte empfangen können, verschliffene Syncronsignale. ausserdem ist eine empfangene Zeit die 2-3 mal in plausiblen Abständen kommt dann vermutlich passend Zeitempfang Uhrzeit 1 5 Minuten später mit timer gezählt ergibt diese Zeit auch 5 Minuten plus und noch mal 3 Minuten später (Timer) ist es wieder 3 Minuten später Empfang, dann sollte der Empfang doch stimmen.
:
Bearbeitet durch User
> Ich hatte durch Störungen und falschen low high Grenzen solche Werte > empfangen können, verschliffene Syncronsignale. Das ist mir nie gelungen. Wenn der Empfang schlecht war (keine Seltenheit), dann scheiterte es meist schon an der 100ms-Grenze. Die Signale waren fast immer kürzer. Wenn nicht (weil man ja zwangsweise irgendwo in der Minute anfängt zu empfangen) dann scheiterte es an einem der Prüf- oder Paritätsbits. Nie beobachtet habe ich ein Scheitern an der 59. Sekunde (was die letzte Station wäre). Von daher sehe ich keinen Grund für weitere Plausibilitätsprüfungen
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.