ich beschäftige mich gerade mit der Auswertung des DCF77-Signals (Output eines Pollin-Empfangsmoduls) durch einen Mikrocontroller (momentan ein ATmega88A).
Zur Zeit lasse ich den Controller die Dauer der Trägerabsenkungen (bzw. der Pause dazwischen, falls diese länger als 1,5 s dauert) messen und über die UART-Schnittstelle an meinen PC senden (siehe Anhang).
Dabei ist mir aufgefallen, dass die Dauer der ersten Absenkung nach einer Synchronisationspause, also die Absenkung der „Sekunde 0“, weder 100 noch 200 ms zu dauern scheint, sondern ca. 65 ms.
Jetzt frage ich mich: Ist das wirklich so, oder nur ein Fehler meines µC-Programms? Google und die Website der PTB hat mir dazu keine Antwort geliefert. Ich gehe aber davon aus, dass hier jemand Bescheid weiß, ob die Sekunde 0 tatsächlich durch eine kürzere Absenkung markiert wird oder nicht.
Dabei ist mir aufgefallen, dass die Dauer der ersten Absenkung nach
einer Synchronisationspause, also die Absenkung der „Sekunde 0“, weder
100 noch 200 ms zu dauern scheint, sondern ca. 65 ms.
Jetzt frage ich mich: Ist das wirklich so, oder nur ein Fehler meines
µC-Programms? Google und die Website der PTB hat mir dazu keine Antwort
geliefert. Ich gehe aber davon aus, dass hier jemand Bescheid weiß, ob
die Sekunde 0 tatsächlich durch eine kürzere Absenkung markiert wird
Das 59te Bit ist eine Ausnahme, da erfolgt keine Absenkung. Bei allen Anderen sind es 100ms oder 200ms, +/- der erlaubten Abweichung. Und das ist auf der Seite der PTB schon ersichtlich.
Entweder hast Du daher ein Empfangsproblem, ein Problem mit dem Modul oder mit der Software.
Ich denke, dass das ein Problem des Empfängers sein wird, Zeitkonstante
der Verstärkungsregelung zu kurz.
Ahja, das könnte natürlich sein – vorher ist ja eine längere Pause.
Vielen Dank für den Tipp.
Dann werde ich später noch einen anderen Empfänger zum Vergleich heranziehen.
Das hätte ich als erstes mal gemacht, bevor ich dafür einen Thread
eröffne;-)
Naja, ich habe leider gerade keinen anderen (ebenso, wie ich noch kein DSO habe). Und ich dachte, vielleicht ist ja der erste Puls in einer Minute wirklich kürzer, als zusätzliche Markierung zur Synchronisation ...
Sorry, falls ich den Thread umsonst eröffnet habe.
The different duration of the modulated second marks serves for binary coding of time and date: a second mark with a duration of 0.1 s correspond to a binary zero, and a second mark with a duration of 0.2 s to a binary one.
Mein Vorschlag: Kleinen Logikanalysator kaufen oder basteln/flashen. Sigrok und Pulseview installieren und den dort eingebauten DCF77 Decoder als Vergleich benutzen.
....dass die Dauer der ersten Absenkung nach
einer Synchronisationspause, also die Absenkung der „Sekunde 0“, weder
100 noch 200 ms zu dauern scheint, sondern ca. 65 ms.....
Die "gemessenen" 65ms sind (abgesehen von Funktionsfehlern in der Steuerung der PTB oder Problemen der Sendeanlage in Mainflingen) mit großer Sicherheit deinem Empfänger (Regelzeit) zuzuordnen.
Es gibt seitens PTB nur Trägerabsenkungen mit einer Dauer von 100ms oder 200ms. ;-)
Du kannst dir doch auf jedem "mobilen Endgerät", auch Smartphone, DCF77 in Twente SDR anzeigen lassen und sehen, was dein Programm aus den jeweiligen Pausen macht. Ich sehe daneben dort momentan auch sehr viele Störungen, grade in den Pausenmitten.
Als man noch mit TTL-ICs gebaut hat, war das der Standard: Mit der fallenden Flanke ein 150ms-Monoflop getriggert und bei Ablauf den Zustand ins Register geschoben.
Da gab es aber noch keine billigen Empfänger-ICs, der klassische Geradeaus liefert stabile Impulslängen.
Wenn einzelne Impulse oder Pausen in der Auswertung zu kurz sind, kann das auch an Empfangsstörungen liegen:
Wartet das Auswerteprogramm z.B. bis zum nächsten Pegelwechsel (= Ende des Impulses), kann ein kurzer "Spike" für das Programm so aussehen, dass das schon das Ende des Impulses ist. Der wird dann zu kurz gemessen.
Lösung: Die Messung der Impulslänge wird für sehr kurze Pegelwechsel nicht unterbrochen.
Wenn einzelne Impulse oder Pausen in der Auswertung zu kurz sind, kann
das auch an Empfangsstörungen liegen:
Wartet das Auswerteprogramm z.B. bis zum nächsten Pegelwechsel (= Ende
des Impulses), kann ein kurzer "Spike" für das Programm so aussehen,
dass das schon das Ende des Impulses ist. Der wird dann zu kurz
gemessen.
Lösung: Die Messung der Impulslänge wird für sehr kurze Pegelwechsel
nicht unterbrochen.
Das habe ich in meinem Programm schon berücksichtigt.
Ich habe eine einfache Filterlogik implementiert: Im Abstand von 1 ms wird das Signal vom Empfänger abgetastet, bei High-Pegel wird ein Register inkrementiert oder bei Low-Pegel dekrementiert. Geht das Register von 1 auf 0 über und ist das Filter-Output 1, wird eine fallende Flanke erkannt; ein Übergang von z.B. 15 auf 16 (einstellbar per .equ-Direktive) bei Filter-Output 0 wird als steigende Flanke gewertet.
Die dadurch entstehende Latenzzeit von 16 ms sollte in der Regel bei einer einfachen Uhren-Anwendung ja nicht stören.
Mein Microchip-Studio-Projekt (Assembler) habe ich mal angehängt, falls jemand interessiert ist.
Dabei ist mir aufgefallen, dass die Dauer der ersten Absenkung nach
einer Synchronisationspause, also die Absenkung der „Sekunde 0“, weder
100 noch 200 ms zu dauern scheint, sondern ca. 65 ms.
Das beurteilst du anhand einer Textausgabe auf einem Bildschirm?
Nimm einen Empfänger mit manueller Verstärkungsregelung und zeige den zeitlichen Verlauf des Analogsignals (vor dem Diskriminator) als Oszillogramm.
Anhand des digitalen Ausgangssignales siehst du nicht, wenn in der Black-Box Mist passiert.
Da gab es aber noch keine billigen Empfänger-ICs...
Anmerkung: "Da" (= damals, als vor 30 Jahren)
Leider nicht zutreffend:
Ein TCA440 (genauso wie TBA120) war bereits Ende der 70er Jahre als Standard-IC erhältlich, siehe Datenbuch SIEMENS 1976/77. Und unverhältnismäßig teuer war er auch nicht, wenn ich mich richtig erinnere. ;-) Ein Vergleich mit heutiger Halbleiter-Technik und -Preisen hinkt naturgemäß enorm.
Nebenbei war damals die Standard-TTL-Technik bereits bei Takt-Geschwindigkeiten von mehreren zig MHz (≈ Durchlaufzeiten von ca. 100ns oder besser). Dementsprechend waren also schon zeitkritische Anwendungen möglich (vergleiche t = 12,9 µs einer DCF-Periode).
Die grundsätzliche Unsicherheit der abfallenden AM-Trägerflanke liegt lt. PTB bei ca. +/- 25µs, in erster Linie bedingt durch die LW-typische Ausbreitung (Bodenwelle/Raumwelle sowie Tag-/Nacht-Unterschiede).
Auf der Empfangsseite muss dann noch mit zusätzlichen Verzögerungen bis zu 100 ms rechnen, je nach verwendeter Empfänger-Topologie.
Besonders ist die Durchlass-Bandbreite evtl. vorhandener Filter verantwortlich. Dadurch können schnelle AM-Flanken entweder verrundet/verschliffen werden oder sind u.U. garnicht mehr erkennbar. :-(
Genaueres Diskriminieren des Sekundenbeginns ist nur möglich, wenn man die Phasen-Umtastung (PRN, Pseudo-Zufallsrauschen) zur Auswertung heranzieht.
an Johannes Fechner:
Die (nicht interruptgesteuerte) Ausgabe macht Ärger: wenn ich die
Baudrate auf 115200 Bd hochsetze, sieht der Zeitwert für Bit 0 gut aus.
Die (nicht interruptgesteuerte) Ausgabe macht Ärger: wenn ich die
Baudrate auf 115200 Bd hochsetze, sieht der Zeitwert für Bit 0 gut aus.
Jaaaa klar, natürlich ... 🙈
Ich habe erstmal testweise die CLI/SEI-Klammer in der Main Loop entfernt, und tatsächlich ist nun das empfangene Bit Nr. 0 eine astreine '0'.
Logisch, wenn man bedenkt, dass die Polling-UART-Ausgabe des dem Bit 0 vorausgehenden Hinweises auf die Sync-Pause die Interruptverarbeitung und damit die 1-ms-Abtastung blockierte.
Also vielen vielen Dank an S. Landolt (sldt) für den Hinweis! Sie haben mir sehr weitergeholfen und viel Kopfzerbrechen erspart.
Nachtrag: Das Problem dieses Threads ist damit GELÖST.
Vielen Dank an alle für die Antworten.
Nachtrag: Das Problem dieses Threads ist damit GELÖST.
Vielen Dank an alle für die Antworten.
Trotzdem noch eine "Meinung":
Aus der Erfahrung meiner DCF77-Decoder (meinen uralten in Bascom und Assembler hatte ich oben verlinkt; weitere von mir gabs in GCC und z.B. für Fischertechnik in deren graphischer Software-Umgebung) hat es sich bewährt, nicht die Impulse, sondern die Pausen auszuwerten. Vorteil: Telegrammende ist direkt zu erfassen, "high level" Spikes stören weniger, da die Pausen eh die höchste Sendeleistung haben.
hat es sich
bewährt, nicht die Impulse, sondern die Pausen auszuwerten.
Da fällt mir aber spontan auch ein Nachteil ein: die zulässige Toleranz (Störeinflüsse auf die Übertragung, Empfänger-Verstärkungsregelung sowie Zeitbasis des Decoders etc.) müsste wesentlich geringer sein, nämlich deutlich weniger als 5,6 % (50/900 ms), wenn ich richtig denke.
Gegenüber weniger als 25 % bei der Auswertung der Puls- (Absenkungs-)längen.
Dabei ist mir aufgefallen, dass die Dauer der ersten Absenkung nach
einer Synchronisationspause, also die Absenkung der „Sekunde 0“, weder
100 noch 200 ms zu dauern scheint, sondern ca. 65 ms.
Dir ist klar, dass nach der 58. Sekunde 2s Pause ist, es gibt keine 59. Sekunde vor der Sekunde 0?
dcf77-protokoll.png
(7 KB)
