Hey guys Ich bin in der Vergangenheit schon öfter mal zu verschiedenen Themen auf das Mikrocontroller.net-Forum gestoßen, habe auch einiges Interessantes gelesen. Jetzt muss ich allerdings auch selber mal eine Frage stellen. Und zwar geht es um das DCF-Signal. Der DCF77 sendet ja bei Bit 15 das sogenannte "Rufbit", um offenbar auf Störungen an der Sendeanlage hinzuweisen. Dazu möchte ich wissen: Welche Störungen/Unregelmäßigkeiten genau lösen das Rufbit aus? Ich meine bei einem Totalausfall des Senders könnte er auch kein Rufbit mehr aussenden. Der Totalausfall wäre aber auch leichter zu erkennen. Vom Rufbit merkst du mit einer handelsüblichen Funkuhr ja nicht mal was. (Jedoch sehr wohl in der PTB oder wenn du selbst irgendeine Uhr gebaut hast, die das Signal analysiert) Vielleicht kennt sich jemand aus und kann hier etwas Licht ins Dunkel bringen, auf welche Störungen der Sender mit dem Rufbit reagiert. Gruß Henrik (@letsdancer) P.S. Falls der Thread in einem anderen Bereich besser passt, bitte verschieben, bin neu hier. Danke!
Henrik S. schrieb: > Ich meine bei einem Totalausfall des Senders könnte er auch kein Rufbit > mehr aussenden. Der Totalausfall wäre aber auch leichter zu erkennen. > Vom Rufbit merkst du mit einer handelsüblichen Funkuhr ja nicht mal was. > (Jedoch sehr wohl in der PTB oder wenn du selbst irgendeine Uhr gebaut > hast, die das Signal analysiert) Ich vermute mal, eine solche, spezielle Uhr steht auch bei den für den Sender zuständigen Mitarbeitern der PTB, und würde diese vielleicht sogar aus dem Schlaf wecken. Die könnten dann andere, für den Senderbetrieb zuständige Menschen vor Ort benachrichtigen. M.W. gibt es direkt am Sender keine dauernde Besetzung mehr.
Henrik S. schrieb: > Dazu möchte ich wissen: Welche Störungen/Unregelmäßigkeiten genau lösen > das Rufbit aus? Früher hieß das "Reserveantenne", wurde wohl später geändert. Dazu sagt die PTB nur pauschal: "Seit Mitte 2003 wird nur noch die Sekundenmarke 15 ("Rufbit") verwendet, um Unregelmäßigkeiten in den Steuereinrichtungen zu signalisieren und die für DCF77 verantwortlichen Mitarbeiter der PTB in Braunschweig zu alarmieren." https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/zeitcode.html Harald W. schrieb: >> Vom Rufbit merkst du mit einer handelsüblichen Funkuhr ja nicht mal was. >> (Jedoch sehr wohl in der PTB oder wenn du selbst irgendeine Uhr gebaut >> hast, die das Signal analysiert) > > Ich vermute mal, eine solche, spezielle Uhr steht auch bei den > für den Sender zuständigen Mitarbeitern der PTB, und würde diese > vielleicht sogar aus dem Schlaf wecken. Mein alter Eigenbau zeigt es an. Ich sehe aber mehr Ausfälle mit kaputter Zeit oder ganz weg als das R-Bit.
Meine Software-Decoder zeigen Bit 15 auch an, ich habe aber noch nie einen Pegelwechsel gesehen. Ich verfolge das aber auch nicht 24/7 über Jahre.
Die Steuereinrichtungen, die die seriellen Daten und die Trägerfrequenz erzeugen, gehören der PTB. Die Sendeanlage, bestehend aus HF-Leistungsverstärker (50 kW), HF-Leitung, Abstimmhaus und Antenne, werden von T-Systems betrieben. Ob von dort noch eine Rückmeldung zu den Steuereinrichtungen erfolgt und ob das Rufbit überhaupt noch benutzt wird, kann ich nicht sagen. Senderausfall bemerkt man auch ohne Rufbit. Über das Internet kann man heute viel detailliertere Meldungen schicken. Die Anlage muss auch nicht unterbrechungsfrei laufen. Üblich sind Verfügbarkeitsvereinbarungen zwischen 99 % und knapp 100 %. Die Empfängeruhren müssen einen Tag Ausfall mit jeweils ausreichender Genauigkeit selbst überbrücken können. Bernhard
Manfred P. schrieb: > ... Dazu sagt die PTB nur pauschal: > "Seit Mitte 2003 wird nur noch die Sekundenmarke 15 ("Rufbit") > verwendet, um Unregelmäßigkeiten in den Steuereinrichtungen zu > signalisieren und die für DCF77 verantwortlichen Mitarbeiter der PTB in > Braunschweig zu alarmieren." Das ist derzeit in -stein gemeißelt. ;-) Ein Telefonat mit der PTB würde sehr wahrscheinlich auch kein weiteres/besseres Ergebnis bringen. .... > ...Mein alter Eigenbau zeigt es an..... Was bleibt ihm auch anderes übrig, als das Bit nr. 15 anzuzeigen? :-D
Dirk O. schrieb: > Meine Software-Decoder zeigen Bit 15 auch an, ich habe aber noch nie > einen Pegelwechsel gesehen. Ich verfolge das aber auch nicht 24/7 über > Jahre. Genau das, ich sitze auch nicht ständig daneben. Gelegentlich sieht man halt irgendwas und schaut dann zu https://dcf77logs.de/live, ob der die Störung auch hat. Bernhard schrieb: > Die Steuereinrichtungen, die die seriellen Daten und die Trägerfrequenz > erzeugen, gehören der PTB. Ja, sie stehen aber vollständig in Mainflingen und werden von Braunschweig aus fernüberwacht. Da gibt es natürlich eine Datenverbindung. DCF ist über 50 Jahre alt und war damals noch per Analogmodem angebunden. > Die Empfängeruhren müssen einen Tag Ausfall mit jeweils ausreichender > Genauigkeit selbst überbrücken können. Das ist Blödsinn. DCF77 ist nicht nur für die Küchenuhr gedacht, es gibt weitaus kritischere Anwendungen, wo Störungen oder Abweichungen von Interesse sind. Michael M. schrieb: >> "Seit Mitte 2003 wird nur noch die Sekundenmarke 15 ("Rufbit") >> verwendet, um Unregelmäßigkeiten in den Steuereinrichtungen zu >> signalisieren und die für DCF77 verantwortlichen Mitarbeiter der PTB in >> Braunschweig zu alarmieren." > Das ist derzeit in -stein gemeißelt. ;-) Ein Telefonat mit der PTB würde > sehr wahrscheinlich auch kein weiteres/besseres Ergebnis bringen. Das ist garnicht so sicher. Ich war früher öfter in der PTB, die haben sehr offen kommuniziert und es wäre auch heute noch einen Versuch wert. >> ...Mein alter Eigenbau zeigt es an..... > Was bleibt ihm auch anderes übrig, als das Bit nr. 15 anzuzeigen? :-D Es zu ignorieren, ebenso wie einige andere Bits. Meine Digitalwecker oder Wanduhren interessieren sich nicht dafür, aber manche zeigen zumindest an, wenn sie nicht synchronisieren konnten.
Manfred P. schrieb: > Ich war früher öfter in der PTB, die haben sehr offen kommuniziert > und es wäre auch heute noch einen Versuch wert. Passende Telefonnummern findet man auf den Internetseiten der PTB. > Manche Digitalwecker interessieren sich nicht dafür, aber manche > zeigen zumindest an, wenn sie nicht synchronisieren konnten. Ich hatte mal einen Wecker, der stündlich synchronisierte und anzeigte, wieviele Stunden es her ist, das er ein Signal empfängt. Beim Urlaub auf den Kanaren zeigte er mir an, das er Nachts um zwei oder drei Uhr ein gültiges Signal empfangen hat.
Angehängte Dateien:
Hi,
wenn man nur das Sommerzeitbit zur Anzeige SZ=Sommerzeit und
WZ=Winterzeit braucht, kann man das so machen. Und im Prinzip geht das
mit dem Rufbit genauso programmiermäßig.
dcftab: ; DCF77-Tabelle, eingehende Bits werden in
.byte 6 ; Byte 5, Bit 7 eingeschoben und alle weiteren
; Bits um eine Position weitergerueckt,
; Byte/Bit:
; 0/6-7: 0bxx000000 Zeitzone (6=1 Som,7=1 Wint)
Ist keine Raketentechnik.
Aber zurück zur Ursprungsfrage: Am besten dort (PTB) einmal anrufen.
ciao
gustav
Beitrag #7550072 wurde vom Autor gelöscht.
Habe nun auch nichts wirklich Tiefgründiges gefunden im Netz. Bezüglich Rufbit findet man nur vage Informationen wie "Unregelmäßigkeiten an den Steuereinrichtungen". Dann muss ich wohl wirklich mal eine E-Mail an die PTB schreiben. Das mit der Sommer-/Winterzeitinformation bzw. der Umstellungsinformation über Bit 16 (und wie unterschiedliche Funkuhren damit umgehen), was von einigen Usern erwähnt wurde, ist aber tatsächlich nicht minder interessant, ebenso die Schaltsekunden. Ich habe unter anderem diese ELV-Binäruhr, natürlich mit Funkmodul aufgerüstet: https://de.elv.com/elv-binaer-uhr-bu-1-komplettbausatz-mit-frontplatte-ohne-dcf-modul-084774 Diese Uhr zeigt bei der Zeitumstellung ein recht auffälliges Verhalten. Wüsste gerne mal, ob jemand von euch bei einer seiner Funkuhren etwas Ähnliches gesehen hat: Bei der Umstellung von MESZ auf MEZ (Oktober) wechselt um Mitternacht vor der Zeitumstellung die Zeitanzeige von 23:59:59 auf 01:00:00 (statt 00:00:00). Die 1-Uhr-LED bleibt dann eine ganze Minute fälschlicherweise an, bis die Zeit dann von 01:01:00 auf die korrekte Zeit von 00:01:01 wechselt. Zu dieser Zeit wird das DCF-Bit 16 jedoch noch gar nicht gesendet, sondern erst ab 2 Uhr MESZ? Die Zeitumstellung erfolgt jedenfalls korrekt (02:59:59 auf 02:00:00). Analog bei MEZ -> MESZ: Die Uhr zeigt um Mitternacht vor der Umstellung eine Minute lang 25 Uhr oder 37 Uhr statt 0 Uhr an; nach 1 Minute erscheint wieder die korrekte Zeit und die Umstellung erfolgt vorschriftsgemäß von 01:59:59 auf 03:00:00 Uhr. Ich wüsste gern, wie diese Uhr sich verhält, wenn es die EU wirklich irgendwann mal gebacken kriegt, die Zeitumstellung abzuschaffen. Da meine Binäruhr die Information zum Zeitzonenwechsel offenbar nicht aus dem DCF-Signal bezieht, sondern einfach kalender-/wochentagsbasiert ausführt, könnte ich mir vorstellen, dass sie um 2 Uhr kurzzeitig falsch anzeigt (ein paar Minuten, bis sie wieder über DCF die korrekte Zeit empfängt). Meine alte Wetterstation (billiges Technoline-Ding) hat jedenfalls das 16er-Bit nicht ausgewertet. Manuelles Starten des Empfangs, während das 16er-Bit aktiv ist, führte nicht zu einer Umstellung in der nächsten Stunde, sondern erst, wenn der Empfang nach der Umstellung erneut gestartet wurde. Die Station empfing auch immer nur um 0:00 (war dieser Versuch erfolgreich, wurde um 1:00 kein weiterer gestartet), was auch dazu führte, dass die Station die Zeitumstellung erst ab dem nächsten Tag 0:00 anzeigte, wenn man den Empfang nicht manuell startete. Bei meiner neuen Tchibo-Wetterstation erfolgt der erste Empfangsversuch um 1:00 und es erfolgt dann mehrmals stündlich ein weiterer, auch wenn die vorherigen Versuche erfolgreich waren. Ob diese Uhr sich korrekt umstellt, wenn sie das Signal mit 16er-Bit empfangen hat und bei der nächsten vollen Stunde in einem Faradayschen Käfig steckt, konnte ich noch nicht ausprobieren. Schaltsekunden gibt es zu selten; falls es irgendwann mal wieder eine gibt, schaue ich natürlich genau, ob meine Binäruhr dann xx:59:60 anzeigt. Dafür müsste diese jedoch das Zeitsignal in der Stunde vorher (Bit 19) empfangen. Da ich nicht weiß, wie oft diese Uhr sich synchronisiert, müsste ich sie in dieser Stunde aus- und wieder einstecken, um das Signal auf jeden Fall zu kriegen. Hoffentlich verpasse ich die Schaltsekunde nicht...
:
Bearbeitet durch User
Das hier: https://rn-wissen.de/wiki/index.php?title=DCF77-Decoder_als_Bascom-Library ... ist schon älter, gibt aber einen ganz guten Überblick über das DCF77 Protokoll und die Dekodierung.
Dirk O. schrieb: > ... ist schon älter, gibt aber einen ganz guten Überblick über das DCF77 > Protokoll und die Dekodierung. Einen noch besseren Überblick bringen die entsprechenden Internetseiten der PTB. :-)
Harald W. schrieb: > Einen noch besseren Überblick bringen die entsprechenden > Internetseiten der PTB. :-) Naja, auf jeden Fall nicht zur Programmierung eines Decoders.
Dirk O. schrieb: > Das hier: > https://rn-wissen.de/wiki/index.php?title=DCF77-Decoder_als_Bascom-Library > ... ist schon älter, gibt aber einen ganz guten Überblick über das DCF77 > Protokoll und die Dekodierung. Da finde ich keine Angaben zum Rufbit, nach dessen Auslösekriterien hier gefragt wurde. Dirk O. schrieb: >> Einen noch besseren Überblick bringen die entsprechenden >> Internetseiten der PTB. :-) > Naja, auf jeden Fall nicht zur Programmierung eines Decoders. Hier hat niemand gefragt, wie man einen Decoder programmiert. Da haben wir wieder die Sache mit dem Leseverständnis.
Henrik S. schrieb: > Die 1-Uhr-LED bleibt dann eine ganze Minute fälschlicherweise an, bis > die Zeit dann von 01:01:00 auf die korrekte Zeit von 00:01:01 Es wird immer die Zeit der nächsten Minute gesendet. Dazu kommt die Empfehlung, zwei aufeinander folgende Zeittelegramme miteinander zu plausibilisieren, bevor sie angezeigt werden. Ist m.E. korrekt implementiert. mfg mf
Achim M. schrieb: > Es wird immer die Zeit der nächsten Minute gesendet. Dazu kommt die > Empfehlung, zwei aufeinander folgende Zeittelegramme miteinander zu > plausibilisieren, bevor sie angezeigt werden. Das wäre dann keine Plausibilisierung, sondern eine Referenzierung. Reine Plausibilität, erbringt so lustige Dinge wie 6 Uhr Morgens "23:56:00 2064" und das nicht nur bei Zeitumstellung, sonder bei jedem plausiblen Datensatz. Ohne Beachtung der Umstellung SZ/WZ, gibts halt erst wieder die korrekte Zeit, wenn der nächste gültige Datensatz vorliegt. Kann halt a wengerl dauern aber wen störrts, wenn man nicht gerade am Bahnhof steht und auf den Zug wartet...
Manfred P. schrieb: > Hier hat niemand gefragt, wie man einen Decoder programmiert. Da haben > wir wieder die Sache mit dem Leseverständnis. Schreibt jemand der auch regelmäßig am Thema vorbei pöbelt.... Zum Thema Rufbit: meine Uhren (selbstgebaut oder nicht) zeigen es nicht an. Ich würde eine Mail an die PTB schreiben, wie auch schon vorgeschlagen. Das Bit zur Sommerzeitumstellung wird in meiner Eigenbau-Uhr auch nicht ausgewertet, da die Uhrzeit immer korrekt übertragen wird und somit von der Uhr auch korrekt angezeigt. Sie synchronisiert stündlich (was eigentlich Unsinn ist). Hab ich auch mal geprüft vor vielen Jahren.
Henrik S. schrieb: > Bei der Umstellung von MESZ auf MEZ (Oktober) wechselt um Mitternacht > vor der Zeitumstellung die Zeitanzeige von 23:59:59 auf 01:00:00 (statt > 00:00:00). Die 1-Uhr-LED bleibt dann eine ganze Minute fälschlicherweise > an, bis die Zeit dann von 01:01:00 auf die korrekte Zeit von 00:01:01 > wechselt. Ich vermute ein Fehler in der Implementierung. Bei mir passiert das nicht. Und doch eine Anzeige ist ja auch Unsinn.
900ss D. schrieb: > Das Bit zur Sommerzeitumstellung wird in meiner Eigenbau-Uhr auch nicht > ausgewertet, da die Uhrzeit immer korrekt übertragen wird und somit von > der Uhr auch korrekt angezeigt. Sie synchronisiert stündlich (was > eigentlich Unsinn ist). Hab ich auch mal geprüft vor vielen Jahren. "Immer korrekt übertragen" ja, leider nicht immer korrekt empfangen. "und somit von der Uhr auch korrekt angezeigt" ja, sowas wie oben gezeigt "23:56:00 2064 um 6 Uhr früh"... Habs vor Jahren selbst "getestet". War zu faul für Assembler und mit C hat halt nur ne Plausibilitätsprüfung in den 16F84a gepaßt. :D
Teo D. schrieb: > Plausibilitätsprüfung Klar, korrekte Auswertung vorausgesetzt bei der Anzeige dann :)
900ss D. schrieb: > Klar, korrekte Auswertung vorausgesetzt bei der Anzeige dann :) Prinzip der zunehmenden Skalenwerte n+1. Die Parities müssen auch stimmen. ciao gustav
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.