Hallo, 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. Gruß, Johannes
Angehängte Dateien:
-
dcf77-protokoll.png
7 KB
Johannes F. schrieb: > 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? Ich denke, dass das ein Problem des Empfängers sein wird, Zeitkonstante der Verstärkungsregelung zu kurz.
Johannes F. schrieb: > 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.
Manfred P. schrieb: > 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.
Johannes F. schrieb: > Manfred P. schrieb: >> 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. Eben, die 59te Sekunde. Damit wird die nächste Minute angekündigt. > 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;-) Hier noch 2 Links zu einer interessanten Website zum Thema DCF77: https://dcf77logs.de/ https://dcf77logs.de/live
:
Bearbeitet durch User
Jörg R. schrieb: > 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.
Angehängte Dateien:
-
DCF77Protocoldecoder.png
400 KB
Null ist laut DCF77 specs 0.1 s lang. 65ms waere am Rande der Toleranz. Vgl. https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time/dcf77/dcf77-time-code.html 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. https://sigrok.org/wiki/Protocol_decoder:Dcf77 https://github.com/dgatf/logic_analyzer_rp2040 Nur(!) 200 MHz sample rate, aber reicht allemal hier ;-) https://sigrok.org/wiki/Downloads
Johannes F. schrieb: > ....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. ;-) Hier steht alles Wissenswerte drin: https://www.ptb.de/cms/fileadmin/internet/publikationen/ptb_mitteilungen/mitt2009/Heft3/PTB-Mitteilungen_2009_Heft_3.pdf
Hast Du denn schon alle anderen Pulse mal sehen (Oszi) oder auswerten können? For 30 Jahren hab ich naiv bei 150ms diskriminiert. Den Wert müsste ich für unser Modul stark anpassen.
Bruno V. schrieb: > For 30 Jahren hab ich naiv bei 150ms diskriminiert. Den Wert müsste ich > für unser Modul stark anpassen. Ging mir ebenso. Ich musste die Toleranz-Grenzen in meinem Programm erheblich erweitern, damit es ordentlich funktionierte.
Angehängte Dateien:
-
Zwischenablage01.jpg
550 KB
Johannes F. schrieb: > Naja, ich habe leider gerade keinen anderen 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.
Bruno V. schrieb: > For 30 Jahren Autsch. > hab ich naiv bei 150ms diskriminiert. 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. Grundlagen: https://rn-wissen.de/wiki/index.php?title=DCF77-Decoder_als_Bascom-Library
:
Bearbeitet durch User
Dirk O. schrieb: > 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.
Johannes F. schrieb: > 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.
Manfred P. schrieb: > 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. Manfred P. schrieb: > ...Als man noch mit TTL-ICs gebaut hat, war das der Standard: Mit der > fallenden Flanke ein 150ms-Monoflop getriggert... Bei größerer Entfernung zum Sender ging das wohl einigermaßen sicher "in die Hose".... :-((
Beitrag #7528991 wurde vom Autor gelöscht.
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.
Angehängte Dateien:
S. L. schrieb im Beitrag #7528991: > 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.
:
Bearbeitet durch User
Michael M. schrieb: > (genauso wie TBA120) war bereits Ende der 70er Jahre Das war doch schon im Ton-Demodulator des Grundig SW-Fernsehers 1974 gekauft drin. mfg
:
Bearbeitet durch User
Johannes F. schrieb: > 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.
:
Bearbeitet durch User
Dirk O. schrieb: > 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.
Johannes F. schrieb: > 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 dekodieren | Funktionsweise einfach erklärt | Dekodier Schema | Funkuhr | Tutorial, How to https://www.youtube.com/watch?v=f_qMfuUxgJ8
Max P. schrieb: > Dir ist klar, dass nach der 58. Sekunde 2s Pause ist, es gibt keine 59. > Sekunde vor der Sekunde 0? Ja, das ist mir klar. Dieser Thread ist auch bereits gelöst, siehe oben.
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.