Hallo an alle, hiermit möchte ich meine Erfahrungen in Thematik DFC77-Auswertung teilen. Mein längerfristiges Ziel ist eine Nixi-Funkuhr zu bauen, deswegen war ich in letzter Zeit mit Auswertung vom DCF77-Signal beschäftigt. Bei Recherche habe ich verschiedene Methoden gefunden: integrieren, falten, Auswertung über analogen Eingang, Signal Breitenmessung, usw. Schließlich habe ich als Grundlage die Beschreibung von Autor: Volker (Gast), Datum: 27.06.2011 15:43, Beitrag "DCF77-Modul von Pollin" genommen. Ende Oktober habe ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC. Mein Vorgehen: Nach einer positiven Flanke an INT0 nehme ich 20 Samples in 10ms Abständen. Dann nehme ich Samples 1 bis 9 und 12 bis 20, zähle die „1“-er und bilde ein Byte, das bei gutem Empfang idealerweise den Wert 90 für „0“ und 99 für „1“ hat. Dabei sah ich, dass bei einem auswertbarem Signal dieses Byte nur begrenzte Anzahl an Werten liefert: 60, 70, 80, 90, 91-99. Als nächstes habe ich direkt die Samples visualisiert und festgestellt, dass beim (noch) guten Empfang es keinen (99), oder einen Übergang (<99) von 1 auf 0 gibt. Solange das Signal nicht fragmentiert ist, sieht ein „70“ so aus: 11111110000000000000, ein „92“ kommt von Samples 11111111111110000000. Ist klar, die fallende Flanke vom Signal variiert, bei 100ms mehr, bei 200ms weniger, und das ist wiederum vom Empfangsqualität des DCF77 Signals abhängig. 60 – 95 werte ich als „0“ aus, ab 96 werte ich als „1“ aus, wobei 60 und 95 schon sehr grenz-wertig sind, die Störungen sind dann stärker, nächste Phase die LED blinkt nur mehr wild herum oder gar nicht mehr, das Signal wird fragmentiert, das nächste oder übernächste Bit fällt komplett aus, die Software dadurch einen (falschen) BIT-0 Bedingung registriert und fängt von vorne an, und in diesem Fall kann man nichts vernünftiges mehr bekommen. Bei diesem Herumexperimentieren habe ich auch gesehen, dass solange das Signal nicht defragmentiert ist, man kann selbst bei zeitlich stark variierender fallender Flanke eine Stelle im Signal finden die eine gute Aussage über den empfangenen Bit liefert, und das ist der 17. Sample, oder 170ms nach dem Signal Anfang. Anders gesagt, der Sample 17 liefert direkt das empfangene Bit. Meine letzte Softwareversion wertet nur Sample 17 aus mit ganz brauchbarem Ergebnis. Ich weiß nicht, vielleicht habe ich das Rad nur neu erfunden, aber würde mich an dieser Stelle interessieren ob diese Methode auch für andere Module anwendbar ist, oder es nur mit dem Pollin Modul funktioniert? Noch zur Info: ich lebe in Wien, mein ~3.5m² Hobby Werkstatt ist am 2. Stock eines Altbau und dort kann ich genau eine Stelle finden wo ~90% der Zeit ein guter (auswertbarer) Empfang vorhanden ist.
Angehängte Dateien:
-
DCF.jpg
480 KB
Ozvald K schrieb: > Nach einer positiven Flanke an INT0 Meine Erfahrung ist, daß ein externer Interrupt zu störempfindlich ist. Ich polle daher im Timerinterrupt: Beitrag "DCF77 Uhr in C mit ATtiny26"
Hallo Peter, den Beitrag habe ich auch gefunden und es funktioniert zweifellos. Gegen Störempfindlichkeit mache ich folgendes: Ich verbiete die externen Interrupts in der Behandlungsroutine selbst, und gebe ich wieder frei im Timer Interrupt in definierten Zeitfenstern. Aber jetzt unabhängig davon möchte wissen ob alle andere Module so auswertbar sind bei 170ms wo es (höchstwahrscheinlich) keine Überlappung von gesendeten Bits existieren kann? Weil dann würde es die Auswertbarkeit ziemlich vereinfachen.
Peter D. schrieb: > Meine Erfahrung ist, daß ein externer Interrupt zu störempfindlich ist. > Ich polle daher im Timerinterrupt: Sehe ich auch so :Beitrag "[Bascom/AVR] Uhr und DCF" In meinem Progamm werden nur die Pausen in 20msec-Schritten ausgezählt, also 800msec=1, 900msec=0 und über 1,x sec=59. und fehlende sec. Auswertung des Zählerstands: Zuerst wird auf eine fehlende 59.sec geprüft. Wenn ja auswerten, wenn nein überprüfen ob eine 1 oder 0 empfangen wurde. Es genügen dadurch 2 Schwellwerte zur Dekodierung des DCF-Signals.
Ozvald K schrieb: > Meine letzte > Softwareversion wertet nur Sample 17 aus mit ganz brauchbarem Ergebnis. Nach meinen Messungen an einem Pollin- und einem Conrad-DCF-Empfänger verlängern diese (an meinem Empfangsort nahe Frankfurt) die Samples um ca. 20msec. Legt die Vermutung nahe, dass das 17. Sample die bessere Mitte zwischen einer 0 und einer 1 ist. Ob man nun auszählt oder die Mitte zwischen 0- und 1-Samples abtastet ist meiner Meinung nach egal, bzw. liefert gleich gute Ergebnisse. Bei Impulsbreiten modulierten Bitfolgen ist dieses Verfahren gebräuchlich. Die Besonderheit des DCF-Signals ist die sehr langsame Übertragung. Ansonsten wäre ein Ausmessen der Bit-Breite mit einem im Softwarezähler gar nicht möglich, d.h. das Zählverfahren gerät bei höheren Übertragungsgeschwindigkeiten schnell an seine Grenzen. Ozvald K schrieb: > Vorgehen: Nach einer positiven Flanke an INT0 nehme ich 20 Samples in > 10ms Abständen. Vorab, für diesen Lösungsansatz wären 25 Samples wahrscheinlich besser geeignet um die Impulsverlängerungen durch den DCF-Empfängers abzufangen Der Interrupt könnte aber auch durch einen Störimpuls verursacht worden sein. Eine Möglichkeit wäre zuerst zu prüfen, ob es sich um eine Störung handelt. Dazu zuerst prüfen, ob zum Beispiel in den ersten 5 Samples eine Pegeländerung am Eingang auftritt. Wenn ja, beim ersten erkennen sofort das IRQ-Programm verlassen. Der Vorteil des Abtastens per Timerinterrupt ist auch noch der sehr geringe Zeitbedarf der DCF-Empfangsroutine.
Angehängte Dateien:
Hi, das Programm ist auch praktikabel. https://s-huehn.de/elektronik/wohnuhr/wohnuhr.htm Das hierbei verwendete "Polling" bringt zwar mehr Unsicherheit bezüglich Genauigkeit, ein Programm mit den INTO etc.- Interrupts ist dagegen ziemlich störanfällig, wie @Peda oben schon richtig bemerkte. Habe ich selbst ausprobiert und bin zum ersten Programm zurückgekehrt. Mit der Genauigkeit der fallenden Flanke, ob die nun 10 Millisekunden früher oder später kommt, ist für mich ohne Belang. Abgesehen davon käme man, wenn man alle gesendeten Features vom DCF77- Signal auswerten wollte, nicht herum, die "Kreuzrelation" mit einzubeziehen. Also das komische Rauschen in den Pausen ist so eine Bitfolge. Dient in erster Linie dazu, die fallende Flanke - laienhaft ausgedrückt - noch "genauer" zu machen. ciao gustav
:
Bearbeitet durch User
Alex D. schrieb: > für diesen Lösungsansatz wären 25 Samples wahrscheinlich besser > geeignet um die Impulsverlängerungen durch den DCF-Empfängers abzufangen Das habe ich mir auch schon überlegt, nur fange ich mit der Information Impulsverlängerung später nichts an. Es sei denn aus "qualitätsrelevanten" Gründen, falls man die Samples analysiert bis 250ms um sicher zu stellen, dass nur ein Übergang von 1 auf 0 vorhanden ist. Das würde auf ein stabiles Signal deuten. Wegen INT0 Störanfälligkeit: ja, es ist störanfälliger, gebe zu. Habe ein paar mal gehabt, dass der Bitzähler ein immaginäres 59. Bit gezählt und damit einen Überlauf verursacht hat. Das habe ich dazwischen gefixt. Ich verwende den INT0 interrupt in Kombination mit Timer0. In der INT0 verbiete ich die weitere INT0 interrupts, synchronisiere den Timer0 Lauf, (RELOAD value -> TCNT0) und in der Timer Routine selbst erlaube ich wieder den INT0 in einem definierten Zeitfenster. So wirke ich den Störimpulsen entgegen. Wenn der INT0 wegen einer Störung ausgelöst wurde, dann sind die Störungen ohne dies schon derartig massiv, dass man kaum Vernünftiges mehr auswerten kann, und das Ergebnis wird weggeworfen. Kann aber auch folgendes machen: werde eine Lösung mit nur Polling Verfahren parallel laufen lassen um einen direkten Vergleich zu bekommen.
Karl B. schrieb: > Abgesehen davon käme man, wenn man alle gesendeten Features vom DCF77- > Signal auswerten wollte, nicht herum, die "Kreuzrelation" mit > einzubeziehen. Also das komische Rauschen in den Pausen ist so eine > Bitfolge. Dient in erster Linie dazu, die fallende Flanke - laienhaft > ausgedrückt - noch "genauer" zu machen. Sorry Gustav, das verstehe ich nicht ganz, besonders das mit dem komischen Rauschen. Sonst auch ein nettes Projekt, man sieht, viele Wege führen nach Rom. :-) Übrigens,bei mir läuft das ganze mit einem TINY13. Nicht, weil ich ein masochist bin, aber es hat sich so ergeben. In der Vergangenheit habe ich ein 10+ Protopack Platine für irgendein TINY13 Projekt bestellt, und habe noch ein paar Platinen übrig. Am Anfang wollte ich nur das Signal dekodieren um Erfahrung zu sammeln, aber dann ist immer mehr geworden. So ist eine minimalistische Funkuhr entstanden :-)
Eure Impulsdiagnose finde ich schon ganz gut, aber zu Verbesserung der Zuverlässigkeit sollte man schon zusätzlich einige Werte auf nacheinander vergleichen nach 17:52 darf nicht 17:51 kommen usw... Meinem System haben falsche Zeiten wie 17:$A sehr geschadet.
Ozvald K schrieb: > Übrigens,bei mir läuft das ganze mit einem TINY13. Beitrag "DCF77-Uhr mit ATTINY12"
Ozvald K schrieb: > Kann aber auch folgendes machen: werde eine Lösung mit nur Polling > Verfahren parallel laufen lassen um einen direkten Vergleich zu > bekommen. Bitte schreibe mal deine Ergebnisse. Ich habe nur Versuche mit dem CTC-Timerinterrupt unternommen. Ein Vergleich der Verfahren finde ich spannend. Nach vielen Versuchen habe ich folgende Empfangsroutine entwickelt und verwendet. Eine Möglichkeit von vielen: - Aufruf durch CTC-Timmer1 alle 20msec - Dcf_auswerten: - Der Pegel am DCf-Port-Pin wird in ein 3-Bit langes Schieberegister - geschoben (D2,D1,D0). '*** Port einlesen, DCF-Empfängerpegel einrollen Shift Dcf_input , Right Dcf_input.2 = Dcf_empfaenger - Erst wenn 3 gleiche Pegel nacheinander anliegen wird ein - Software-RS-Flip-Flop (Dcf_filter_out) entsprechend geschaltet. '*** DCF-Signal filtern, Mindestbreite 60msec If Dcf_input = &B0000_0111 Then Dcf_filter_out = 1 If Dcf_input = &B0000_0000 Then Dcf_filter_out = 0 - Schieberegister zur Flankenerkennung '*** Gefiltertes DCF-Signal einrollen zur Flankenerkennung Shift Dcf_gefiltert , Left Dcf_gefiltert.0 = Dcf_filter_out - Zeitdauer des Samples messen '*** DCF-Impulsbreite ausmessen, wenn Pegel +Us anliegt If Dcf_filter_out = 1 Then Incr Dcf_impulsdauer '*** DCF-Signal demodulieren, Breite mindestens 7*20msec = 140msec ' ... Impulsbreite bewerten (Pause 59.sec/0/1 ), ' ... und Bit ins dcf_Empfangsregister einrollen - Prüfen ob die Bit-Zeitdauer um ist. 'negative Flanke erkannt If Dcf_gefiltert = &B1111_1110 Then Incr Dcf_bitzaehler - Ins Empfangsregister schieben, DCF-D0 auf Schieberegister-D0 Die Dcf-Stunde, Minute usw. werden im nachfolgenden Programm zum richtigen Zeitpunkt zur weiteren Verarbeitung aus dem Empfangsregister kopiert. Shift Dcf_empfangsregister , Right ' DCF-Bit 0/1 einrollen If Dcf_impulsdauer < Dcf_bit_schwelle Then Set Dcf_empfangsregister.7 - einige Programmzeilen weiter: '*** Wenn alle Dcf-Daten eingesammelt sind und die 59. Sekunde ausgeblieben ' ... ist, wird ausgewertet. If Dcf_impulsdauer => Dcf_pause59 Then If Dcf_bitzaehler = 59 Then -usw.
Peter D. schrieb: > Beitrag "DCF77-Uhr mit ATTINY12" Diesen Beitrag kannte ich nicht, es sind immerhin 16! Jahre seit der Erstellung vergangen. Respekt :-) Habe mich kurz hinein gelesen (INDEX.HTM) und dabei viele Parallelen zu meinem Projekt gesehen, aber auch Unterschiede. @ Alex D: Nichts gegen Deine Lösung, aber werde ich höchstwahrscheinlich das von Peter nehmen zu testen weil Hardware schon vorhanden, eine Portierung auf tiny13 dürfte auch kein Problem sein.
Alex D. schrieb: > Ob man nun auszählt oder die Mitte zwischen 0- und 1-Samples abtastet > ist meiner Meinung nach egal, bzw. liefert gleich gute Ergebnisse. Zu TTL-Zeiten hat man ein Monoflop mit etwa 150ms Laufzeit auf die fallende Flanke getriggert und bei Ablauf geguckt, ob ein H oder L anliegt. Ein entferntes Gewitter, und vorbei war's mit der Decodierung. In dem Gebilde hatte ich etwa 50 TTL-Bausteine. Mit einem µC kann man das Signal zyklisch abtasten (pollen) und zwei Toleranzfenster für L und H bilden. Damit bringt nicht mehr jeder Blitz oder pfurzende Lichtschalter den Decoder aus dem Tritt. Wenn man synchron ist, bildet man ein Zeitfenster, in dem das Polling gesperrt wird. Klar, dass man eine mathematische Plausibilitätskontrolle drüber legen sollte. Leider hab eich die Schaltsekunde ignoriert, da gerät meine 2 Minuten lang aus dem Tritt, das Sommerzeit-Ankündigungsbit werte ich aus. Die drei Paritybits im DCF-Signal taugen zu nichts, da keine Doppelfehler auffallen. Ich schreibe das aus der Erinnerung heraus, meine letzte DCF-Decodierung habe ich 1992 auf einem 6502 in Assembler geschrieben. Inzwischen juckt es in den Fingern, das wieder mal zu tun, auf einem Aurduino. Mit den käuflichen Empfängern wird man niemals ganz genau, bei den Superhet-Bausteinen habe ich ein gehöriges Jittern gesehen, welches mein Geradeausempfänger nicht hat.
Manfred schrieb: > Mit einem µC kann man das Signal zyklisch abtasten (pollen) und zwei > Toleranzfenster für L und H bilden. Genau, und jetzt sind wir wider bei meiner anfänglichen Analyse. Nehmen wir an, es sind 20 Samples vorhanden, die so aussehen: 11111111111111100000 (15x1, 5x0) Ist das jetzt eine lang geratene 0 oder ein kurz geratener 1 ? Samples wie diese z.B. 11100111101100100000 kommt bei "normalen" Empfang gar nicht vor, und wenn es vorkommt, dann ist das Signal schon so schlecht, dass das nächste Bit komplett ausfällt und dadurch ein falscher Bit0 Zustand detektiert wird. Ursprünglich habe ich Das Vorhanden von 1-er gezählt, aber es war dadurch nicht besser, zumindest nicht mit solchen gekauften Modulen.
Ja, man kann beliebig viele Pegelabfragen über die Sekunde machen, solange es dem µC nicht zuviel wird... Von der Erfahrung her kann ich nur sagen: Bei Empfang innerhalb Deutschlands ist das viel zu viel Aufwand. Bei schlechten Empfangsbedingungen im Stahlbetonbau hilft aber auch dein Ansatz nicht. VIELLEICHT (?) hilft ein Ansatz, der aus Empfangsbruchstücken versucht, noch was mit Wahrscheinlichkeits- rechnung zusammenzufügen. - WENN Bruchstücke ankommen... Polling, oder external Interrupt ist komischerweise für manche eine Glaubensfrage! - Lass dich nicht darauf ein! Das übliche Polling funktioniert ganz gut. Wenn man Modul-unabhängig programmieren will, könnte man zu Beginn das Polling schon mal zum Herausfinden der Polarität der sekündlichen Zeitsignale nutzen: Der seltenere Signalpegel ist der Sekundentakt. External Interrupt funktioniert auch gut, wenn man danach ein Zeitfenster (z.B. +/- 50 ms) für den nächsten Interrupt setzt: Entweder es passt ab dem ersten Takt, oder es "ruckelt sich ein", wie bei RS232-Empfang. Der Interrupt setzt einen Timer auf Null, der nach 150 ms dazu auffordert den Pegel abzufragen. Derselbe Timer erlaubt erst nach 950 ms den nächsten external DCF-Interrupt. Klappt bei mittelmäßigem Empfang hervorragend! Danach ist die Auswertung der Telegramme wichtig. Parity und Plausibilität: Ist das vorige Zeittelegramm + 1 Minute = dem neuen Zeittelegramm? Vorteil beim external Interrupt: Wenn man die mittlere Verzögerung seines Empfängers kennt, kann man die Uhr mit einigen 10 ms Vorlauf noch etwas exakter auf den "echten" Sekundenwechsel synchronisieren.
Manfred schrieb: > 6502 in Assembler Hat jetzt zwar nichts mit dem Thema zu tun, aber mit guten Erinnerungen: Nostalgie ein - eine super CPU, damals ihrer Zeit weit voraus - Nostalgie aus
Jacko schrieb: > Danach ist die Auswertung der Telegramme wichtig. Parity und > Plausibilität: Ist das vorige Zeittelegramm + 1 Minute = dem neuen > Zeittelegramm? So ist es. Meine Uhr läuft schon über 30 Jahre nach dieser Methode. Geradeausempfänger + Schieberegister + sonstigen Kram + Quarzuhr. Die Quarzuhr übernimmt den Wert der Funkuhr nur dann, wenn das Funkzeittelegramm plausibel ist.
Jacko schrieb: > Das übliche Polling funktioniert ganz gut. OK, man kann eine erhöhte Störsicherheit dadurch erreichen, indem der Eingangsport für die Zeit bis zum Eintreffen des nächsten Impulses gesperrt wird. Bin drauf gekommen, weil beim MSF60 "Doppelimpulse" pro Sekunde kommen. Die müssen ausgeblendet werden. Das kann man beim DCF77-Programm als zusätzliche Störaustastung ansehen. Ein DCF77-Decoderprogramm wurde auf MSF60-Empfang umgemodelt. Programm findet man hier: Beitrag "MSF60 Dekoder AVR Teil_2" Der relevante ASM Schnipsel ist angehängt. Ozvald K schrieb: > Sorry Gustav, das verstehe ich nicht ganz, besonders das mit dem > komischen Rauschen. Zitat: "...Zusätzlich zur amplitudenmodulierten Zeitübertragung wird seit Juni 1983 diese Information über eine Phasenmodulation des Trägers mit einer Pseudozufallsfolge (PZF) in einer Länge von 512 Bit übertragen. Mittels Kreuzkorrelation kann mit dem auf Empfangsseite reproduzierten Signal der exakte Beginn der Sekundenmarken wesentlich besser ermittelt werden. Die PTB Braunschweig gibt die immer noch hinzunehmenden Ungenauigkeiten mit 6,5–25 μs an, abhängig von Tages- und Jahreszeit...." /Zitat Quelle: https://de.wikipedia.org/wiki/DCF77 Wie so ein Empfänger aussieht, der die Kreuzkorrelation ausführt, weiß ich leider nicht. Wäre vielleicht noch eine interessante Sache, das herauszufinden. ciao gustav
:
Bearbeitet durch User
Ich habe mir die Impulse meines DCF77 Empfängers angeschaut und dann in fünf Kategorien unterteilt: a) Ungültig (zu kurz) b) Low-Bit c) Ungültig (weder High noch Low) d) High-Bit e) Ungültig (zu lang) Gleiches mache ich mit den Pausen zwischen den Bits. Wobei die Schwellwerte großzügig gesetzt sind. Die konkreten Millisekunden habe ich gerade nicht verfügbar.
Hi, noch ein Filmchen zum Vergleich von DCF77 und MSF60. Der erste Durchlauf liefert natürlich bis zur Minutensynchronisation "Mist". Dann sieht man, wie der Null-Minuten-Impuls bei MSF60 (500 ms) verlängert ist. Und der 9. und 10. Impuls ist A Code low und B Code high. Ergo zwei fallende Flanken, was beim hier verwendeten DCF77-Decoderprogramm die Sekundenanzeige jeweils weiterzählen würde. Dies muss mit der Software eliminiert werden und gelingt mit dem Sperren bzw. Verodern des Ports ganz leicht. Vorher hatte ich noch mit einer Hardwarelösung mit Monoflop und Odergatter experimentiert, das läuft nicht lange stabil. Und diese Portsperre konnte ich hinterher genau so in das DCF77-Programm einbauen. Das bewirkt eine zusätzliche Sicherheit gegen Impulse, die hinter den 100 bzw. 200 ms Impulsen, also für den Rest der Sekunde eventuell auftreten können. ciao gustav
:
Bearbeitet durch User
Du zeigst hier Empfangsbeispiele: 11111110000000000000 ein "70" ??? 11111111111110000000 ein "92“ ??? 11111111111111100000 (15x1, 5x0) ??? Diese Beispiele, egal ob 300 km, 600 km (Wien), oder auch 1000 km von Mainflingen entfernt, zeigen nur: Schlechter Antennenstandpunkt, schlechte Antennenausrichtung, oder Störfeld. Sonst käme was Brauchbares aus dem Modul. Da hilft keine Erbsenzählerei, sondern nur das Vermeiden der genannten Empfangsbehinderungen. Ideal wäre bei 20 Abtastungen pro Sekunde: 100111111111111111 (0), oder 100001111111111111 (1) oder bei umgedrehter Polarität: 011000000000000000 (0), oder 011110000000000000 (1) Wegen des beliebigen Abtastzeitpunkts und Signalverschleifungen kann es auch mal eine 0, (oder 1) mehr, oder weniger sein. Daher mein schon beschriebener Vorschlag: Antenne (Modul) gut aufstellen und ausrichten, Sekundenflanke erkennen (und darauf einrasten), dann nach 150 ms den Logikpegel erfassen. Abgesehen von sehr aufwändiger Software mit Kongruenzverfahren ist es die erfolgversprechendste Methode.
Jacko schrieb: > Du zeigst hier Empfangsbeispiele: > 11111110000000000000 ein "70" ??? > 11111111111110000000 ein "92“ ??? > 11111111111111100000 (15x1, 5x0) ??? > > Diese Beispiele, egal ob 300 km, 600 km (Wien), oder auch 1000 km von > Mainflingen entfernt, zeigen nur: Schlechter Antennenstandpunkt, > schlechte Antennenausrichtung, oder Störfeld. Dein Kommentar zeigt eher "DCF schlecht verstanden". Egal wo, genau so sieht das reale Leben aus! Man kann mit geschickten Algorithmen ein Großteil der Störungen ausblenden.
Jacko schrieb: > Du zeigst hier Empfangsbeispiele: > 11111110000000000000 ein "70" ??? > 11111111111110000000 ein "92“ ??? > 11111111111111100000 (15x1, 5x0) ??? Ja, in einem Zeitfenster von 0,2 Sekunden, -> 100 Abtastungen/sec
Rolf N. schrieb: > Vielleicht auch von Interesse: > https://blog.blinkenlight.net/experiments/dcf77/ Hi, stimmt nicht ganz, was im Blog steht. Schon seit mehreren Jahren wird statt mit 25% auf 15% abgesenkt, was einer Sendeleistungserhöhung und damit verbesserter Dekodierschwelle gleich käme. (MSF60 tastet afaik dagegen schon immer mit 100% aus.) Zitat: "... wird die Amplitude für die Dauer von 0,1 s oder 0,2 s phasensynchron mit der Trägerschwingung auf etwa 15 % abgesenkt. Die Restamplitude ermöglicht die Gewinnung einer kontinuierlichen Trägerschwingung und soll die Nutzung des DCF77-Trägers als Normalfrequenzsignal erleichtern..." /Zitat Quelle: https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/amplitudenmodulation.html ciao gustav
Ozvald K schrieb: > Ende Oktober habe > ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC. Meine Erfahrung mit dem Pollin-Modul: Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das Ausgangssignal änderte sich bis zur Unbrauchbarkeit. Bitte nur als Hinweis sehen, vielleicht ist Dein Modul schon optimal angeschlossen. Das Schaltbild meiner Anschaltung ist Beitrag Beitrag "[Bascom/AVR] Uhr und DCF" dargestellt.
Alex D. schrieb: > Meine Erfahrung mit dem Pollin-Modul: > Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das > Ausgangssignal änderte sich bis zur Unbrauchbarkeit. Ozvald K schrieb: > Ende Oktober habe > ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC. Hi, könnt Ihr noch mal genau die Bestellnummer sagen. Bei Pollin finde ich mehrere Module. So wie ich das auf den ersten Blick sehe, fehlen hier wieder die Pullup-Widerstände. Die Empfängerplatinen, die man jetzt bei Pollin findet, sind nicht separat zu betrachten, sondern zusammen mit den anderen Modulen zu verwenden. Da sind dann wohl die Pullup-Widerstände dran. Dasselbe gilt für das Conrad Modul im Plan, welches ist's genau? Brauche mehr Infos, falls Tipps gewünscht werden. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > könnt Ihr noch mal genau die Bestellnummer sagen. Bei Pollin finde ich > mehrere Module. Die Bestellnummer habe ich nicht mehr, mein Pollin-Modul sieht so aus wie das aktuelle "DCF-Empfangsmodul DCF1" von Pollin. Meins ist aber schon viele Jahre alt. Noch älter sind meine Module von Conrad. Diese waren ursprünglich in einem fertigen DCF-Wecker eingebaut und sind mit einem TFK U2775B Empfangs-IC bestückt. Karl B. schrieb: > Dasselbe gilt für das Conrad Modul im Plan, welches ist's genau? > Brauche mehr Infos, falls Tipps gewünscht werden. Die Anschaltung der Module, wie in meinem Schaltplan gezeigt, funktioniert schon seit mehreren Jahren problemlos. Verbesserungvorschläge sind mir immer willkommen. Gruß Alex
Angehängte Dateien:
Hier werden ja richtige Kopfstände gemacht, um Fehlsignale auszusortieren. Ich bin der Meinung; dass man mit einer Plausibilitätsprüfung + Quarzuhr eine Uhr hat, die "immer" die richtige DCF77-Uhrzeit anzeigt. Im Anhang mal einige Diagramme zur tatsächlichen Empfangsqualität. Besonders nachts sind Störungen zu erkennen. Wie die Diagramme entstanden sind, wird unter Beitrag "Erklärung DCF 77-Empfang nachts häufiger gestört als am Tag" erklärt.
wolle g. schrieb: > Ich bin der Meinung; dass man mit einer Plausibilitätsprüfung + Quarzuhr > eine Uhr hat, die "immer" die richtige DCF77-Uhrzeit anzeigt. Wieso bist Du der Meinung, dass in allen vorhergehenden Vorschlägen keine Quarzuhr enthalten ist ? Meine Uhr z.B. läuft mit einem 12,8Mhz TCXO und wird nur nach dem Einschalten einmalig eingestellt.
Alex D. schrieb: > Meine Uhr z.B. läuft mit einem 12,8Mhz TCXO und wird nur nach dem > Einschalten einmalig eingestellt. verstehe ich nicht so richtig. Geht es hier nicht um eine DCF77-Funkuhr?
wolle g. schrieb: > Geht es hier nicht um eine DCF77-Funkuhr? Da war ich ungenau, lässt sich für einen "normalen" Quarz auch auf "ständig nachstellen" konfigurieren und wird dann zur DCF77-Funkuhr. Meiner Meinung nach ging es ursprünglich nur darum ein möglichst optimales Empfangs- und Demodulationsverfahren zu finden und nicht um die Möglichkeiten zur Weiterverarbeitung. Was ich dazu beitragen konnte, habe ich gesagt und gehe jetzt wieder in den Lesemodus. Gruß Alex
Alex D. schrieb: > Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das > Ausgangssignal änderte sich bis zur Unbrauchbarkeit. Deswegen ist bei mir vorläufig direkt an Pin von µC ohne Pull Up Aktivierung angeschlossen. Zusätzlich lasse ich eine LED über einen 2N7000 Mosfet blinken. Das ist nicht die endgültige Lösung, zu Testzwecken ist es so schnell entstanden. Gespeist wird von 5V über einen Widerstand (weiß nicht den Wert auswendig) und eine Zenerdiode (habe 3Volt drauf), dazu parallel 0.1µ C + 22µ Elko. Karl B. schrieb: > könnt Ihr noch mal genau die Bestellnummer sagen. Bitte schön: DCF-Empfangsmodul DCF1 ArtNr: 94-810054 Alex D. schrieb: > Wieso bist Du der Meinung, dass in allen vorhergehenden Vorschlägen > keine Quarzuhr enthalten ist ? Es muss nicht immer Quarz sein, wie ich es schon geschrieben habe bei mir läuft die Dekodierung auf einem tiny13 (vorläufig) ohne Quarz. Ich wollte mich ursprünglich nur in das Thema DCF77-Decodierung hinein arbeiten, aber dann ist es immer mehr gewachsen. Aber das jetzt nur als Nebensache...
Alex D. schrieb: > Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das > Ausgangssignal änderte sich bis zur Unbrauchbarkeit. Wer lesen kann, ist klar im Vorteil! Diese Module sind allesamt auf einen geringen Leistungsverbrauch gezüchtet, man kann spekulieren, dass dort Empfänger-ICs von Consumer-Uhren im Einsatz sind. Das gilt nicht nur für Pollin. "DATA ist current source/sink mit Iout > 5 µA."
Ozvald K schrieb:
> Ja, in einem Zeitfenster von 0,2 Sekunden, -> 100 Abtastungen/sec
Oha, da hab ich die 20 Abtastungen falsch interpretiert. Dachte 20/s.
Aber: Was hilft es, herauszufinden, dass manchmal das Signal aus dem
Empfangsmodul keine eindeutige "0", oder "1" (100/200 ms) ergibt?
Bestenfalls hilft es bei der Suche nach einer besseren Antennenposition.
Korrigieren kann man damit nix.
Macht man einfach eine Pegelabtastung 150 ms nach der aktiven
DCF-Flanke,
kommt dann auch ein fehlerhaftes Bit heraus.
Parity-Test + Plausibilitätskontrolle zeigen das aber bei der
Auswertung.
Hat man aber 2..3 gültige Minutentelegramme hintereinander dekodiert und
auf Plausibilität (zeitliche Abfolge) geprüft, kann man damit eine sonst
autonom auf dem µC laufende Quarzuhr (nach-)stellen.
Wer es genau braucht, kann noch überwachen, ob in den letzten x Stunden
solche gültigen Zeitsignale gekommen sind und bei Fristüberschreitung
ein Warnsignal auf dem Uhren-Display setzen...
Mehr geht ohne aufwändige Korrelationsrechnung nicht!
Jacko schrieb: > Was hilft es, herauszufinden, dass manchmal das Signal aus dem > Empfangsmodul keine eindeutige "0", oder "1" (100/200 ms) ergibt? Es ging einfach darum eine günstige Position zu finden wo man mit der größten Wahrscheinlichkeit annehmen kann ob der Sample den richtigen Wert liefert. Beim Pollin Modul diese Position ist eher bei 170ms statt 150. Jacko schrieb: > Mehr geht ohne aufwändige Korrelationsrechnung nicht! Sehe ich auch so. Zu Test- und Beobachtungszwecken lasse ich mehrere Variablen visualisieren. Eine davon ist die Anzahl der 1-er Samples die nach der, schon erklärten Methode zusammengestellt wird. Eine andere ist der Abstand zwischen zwei "Sekundenflanken". Bei gutem Empfang sind die Werte stabil und ändern sich kaum. 90 oder 99 für Samples und 100 für den Abstand (100*10ms). Abends fangen an die Werte zu "wackeln", auch der Abstand zwischen 97 und 104, und hier ist die Dekodierung schon schwierig.
Angehängte Dateien:
Jacko schrieb: > Hat man aber 2..3 gültige Minutentelegramme hintereinander dekodiert und > auf Plausibilität (zeitliche Abfolge) geprüft, kann man damit eine sonst > autonom auf dem µC laufende Quarzuhr (nach-)stellen. Hi, eine Gangreserve, so möchte ich den fortzählenden Uhrenbetrieb ohne DCF77-Signal nennen, halte ich für notwendig. Ein Quarz bringt da mehr Genauigkeit, da die Netzfrequenz als Frequenznormal ja seit dem Debakel Anfang vergangenen Jahres unter Umständen Probleme bereiten kann. Auf den Plausibilitätstest mit extra dafür reservierten SRAM-Puffern und Inhaltsvergleich nach Prinzip der Zunahme der Skalenwerte (Minuten immer n+1) habe ich verzichtet, um am Anfang nicht so lange auf eine Anzeige warten zu müssen. In einem Video wird gezeigt, wie das so in der Praxis bei gestörtem und wiedereintreffendem guten Empfang so aussehen kann. Übrigens synchronisiert sich das andere ausprobierte Programm, das mit den Interrupts arbeitet nicht mehr bei Wiedereintreffen guten Empfangs. Programm zeigt 00:00:00 und bleibt dort hängen. Mit dem Polling-Programm von S. Huehn habe ich da keine Probleme, das ist im Video zu sehen. Gleichzeitig noch akustisch mit Direktmischer die Marken als ca. 1,5 kHz Töne zu hören. Bei Störung rauscht es nur. Viel Spass! ciao gustav
:
Bearbeitet durch User
Ozvald K schrieb: > Es ging einfach darum eine günstige Position zu finden wo man mit der > größten Wahrscheinlichkeit annehmen kann ob der Sample den richtigen > Wert liefert. Beim Pollin Modul diese Position ist eher bei 170ms statt > 150. Wäre oversampling eine Option? Den optimalen Abtastpunkt zu finden ist schwierig. Wenn man Signale überabtastet kann man die Ergebnisse bewerten. Bei binären Signalen ist das auch relativ einfach. Z.B.: DCF ist ein 60 Hz Signal. 20 fach oversampling wäre dann 1200 Hz Abtastrate. 15x > 70% = high, 15 x < 30% = low.
Karl B. schrieb: > Übrigens synchronisiert sich das andere ausprobierte Programm, das mit > den Interrupts arbeitet nicht mehr bei Wiedereintreffen guten Empfangs. > Programm zeigt 00:00:00 und bleibt dort hängen. Möchte dazu nur sagen, dass das Problem hier m.M.n bei der Software liegt, und nicht beim Verfahren. Bin völlig bei Dir wie sich eine Uhr verhalten muss. Meine Lösung verwendet den "schrecklichen :-)" Interrupt, aber hat keine Probleme beim Wiedereintreffen vom Signal nach einem Ausfall. Habe 3 Zustände definiert: 0 - nach dem Einschalten, 1 - hat Bit0 Marke entdeckt und versucht das weitere Signal zu verarbeiten, und 2 - die Uhr ist synchronisiert. Bleibt jetzt das Signal mehr als 2,5 Sekunden aus, dann wechselt die Software in Zustand 0, und wartet wieder auf eine Bit0 Marke. Funktioniert gut.
HyperMario schrieb: > Wäre oversampling eine Option? Ehrlich gesagt, weiß ich nicht, habe mich mit diesem Thema (Oversampling) noch nie in Detail beschäftigt. Aber danke für den Tipp, werde mir anschauen und wenn das Aufwand/Nutzen Verhältnis entsprechend gut ausfällt, why not? Wenn das Signal gut ist, es ist egal mit welchem Verfahren man die Bits extrahiert. Mit Störungen fangen die Probleme an. Wie würde ein Oversampling beim gestörten Signal aussehen? Keine Ahnung...
HyperMario schrieb: > Z.B.: > DCF ist ein 60 Hz Signal. Das passt schon nicht, 60 Zustände pro Minute höchstens, aber 1 Bit pro Sekunde
Ozvald K. schrieb: > Das passt schon nicht, 60 Zustände pro Minute höchstens, aber 1 Bit pro > Sekunde Nee, das passt schon! Es werden zwischen 5 und 10 Zeichen übertragen pro Sekunde. 100 ms Absenkung stehen für den Wert „0“, 200 ms für „1“. Es wird nur jede Minute EIN Telegramm gesendet. Und dazwischen ist halt Pause.
Naja, okay, du hast recht, es wird nur ein Bit übertragen pro Sekunde ...
Angehängte Dateien:
-
DCFcntmode3.jpg
87 KB -
DCF77_Decoder_Schmidt.jpg
86 KB
Ozvald K. schrieb: > Möchte dazu nur sagen, dass das Problem hier m.M.n bei der Software > liegt, und nicht beim Verfahren. Hi, es war diese sophisticatete Variante: Benutzt INT für fallende und steigende Flanke, UART mit Interrupt und zwei Timer Interrupts. etc. Wake up mit UART. Ist mit Abstand wohl so das Grenzwertigste, was man in den ATtiny2313 nicht alles so reinpacken kann. Die Escape Sequenzen für die Farben am Monitor etc. Die Decodierung des Signals wird noch angepasst an die Signalqualität. http://www.avr-asm-tutorial.net/avr_de/dcf77uhr.html Irgendwo kommen die Interrupts sich in die Quere, und das Programm gibt nur noch 00:00:00 aus. Nur power cyclen hilft afaik da. LCD-Ausgabe nur über Zusatzprog. von mir und zweiten AVR ohne MAX232 UART direkt . Die Routinen passten nicht mehr rein. Und natürlich 10 MHz Takt. ciao gustav P.S.: OK, die LCD Ausgaben überschreiben sich. Ist unschön. Weiß ich. Das erste Zeichen ist auch jedesmal beim Start ein Zufallscharakter. SRAM (!)
:
Bearbeitet durch User
Ozvald K schrieb: > Es ging einfach darum eine günstige Position zu finden ... > ... Beim Pollin Modul ... eher bei 170ms ... Ist vielleicht eine gute Idee, um die Empfangssicherheit zu verbessern! Man kann das bei guten Empfangsbedingungen auch schön testen, wenn man die Antenne langsam (immer abwarten, bis die träge Empfängerregelung fertig ist) aus der optimalen Empfangsrichtung rausdreht: Bevor der Empfang aussetzt, verschieben sich die Bit-Zeiten (100/200 ms) langsam und werden schließlich immer ungenauer. Die Module von Pollin/Reichelt/Conrad sind sich da nach meiner Beobachtung ähnlich, es könnte aber sein, (habe nicht danach gesucht), dass die Zeitwerte in unterschiedliche Richtungen auswandern. Wenn der µC "nur DCF macht", hat er ja genug Reserven um sowas im Hintergrund zu erfassen. Da würde ich vorschlagen, mit einem Startwert für den Abtastzeitpunkt nach der Sekundenflanke anzufangen und ihn nur gaaaanz langsam nach den beobachteten Zeitwerten nachzuführen. Überreaktion ist eher schädlich! Habe schon mal probiert, aus dem AM-DCF-Signal ein Zeitnormal zu basteln, daher kann ich bestätigen, dass die empfangene Sekundendauer um einige ms abweichen kann. (Mit GPS-Sekundenpuls kommt man da weiter.) Bei mir (450 km von Mainflingen) habe ich aber bei allen oben genannten Modulen nur SEEEHR selten Probleme mit der DCF-Dekodierung, wenn ich die Bits 150 ms nach der Sekundenflanke erfasse.
Jacko schrieb: > Da würde ich vorschlagen, mit einem Startwert für den Abtastzeitpunkt > nach der Sekundenflanke anzufangen und ihn nur gaaaanz langsam nach den > beobachteten Zeitwerten nachzuführen. Wenn ich es richtig verstanden habe du schlägst vor die Zeitabweichungen zu erfassen und daraus eine Regelgröße zu bilden was den Zeitpunkt vom Sampling beeinflusst. Ja, die Signale werden zeitweise ungenauer, das habe ich gesehen. Ich visualisiere jetzt schon eine Variable die in 10ms Takt vom Flanke bis Flanke (1s) hochgezählt wird. der Wert ist im idealen Fall 100. (100 * 10ms = 1s). Wenn die Störungen stärker werden, dieser Wert fängt an zu "wackeln" zwischen 97 und 104. Nur, der Mittelwert bleibt trotzdem 100,weil wenn ein Wert 97 ist, wird der nächste 103. z.B. 100, 98,102,101,99,100,97,103,99,100,usw. D.h. selbst wenn ein Impluls länger wird, der nächste ist kürzer und damit der Mittelwert bleibt bei 100. Aber was ich machen könnte, 2 Funkuhren neben einander laufen zu lassen, einen mit 150ms Samplingzeit, den anderen mit 160ms z.B. und beobachten welche wird öfter synchronisiert. An Peter Dannegger: habe die Software aus Deinem Projekt Funkuhr mit TINY12 auf TINY13 portiert und an die Hardware angepasst. Meine LCD Steuerung ist anders, und habe noch geringfügige Änderungen gemacht, aber möchte dass Du sie auch noch einmal kontrollierst ob die Änderungen nicht irgendwas unabsichtlich beeinflussen. Projekt als Anhang hier. Danke!
Ah ja, alle grammatischen Fehler bitte ignorieren. Deutsche Sprache schwere Sprache :-)
Angehängte Dateien:
-
Protokol.jpg
63 KB -
S1_2.jpg
59 KB -
S2_beide.jpg
61 KB -
Datum_falsch.jpg
45 KB
Hier habe ich das Ergebnis vom Vergleich. Folgendes habe ich gemacht: die Antenne habe ich in verschiedene Positionen gebracht, so habe ich alles vom guten Signal bis zu "nur mehr Mist" gehabt. Habe von beiden Uhren ~1 Stunde lang den Status in Minutentakt notiert. (1 - nicht synchronisiert, 2 - synchronisiert). Auf den Bildern links läuft das Programm von Peter, rechts läuft meines. So habe ich auch auf den Zettel die Werte notiert. (links <--> rechts) Wie man sieht, es gibt Positionen wo beide gut laufen, es gibt Positionen wo gar nicht mehr geht, und dann findet man auch Position wo sich die linke Uhr noch synchronisieren kann, die rechte aber nicht mehr. M.M.n. es ist nicht nur die Frage ob Polling oder Interrupt, es ist eher das Gesamtkonzept was hier zieht. Peter seine Software misst die Impuls- und Pausenlängen. Hier reicht es wenn eine Größe außer Toleranz gerät, das Resultat wird schlecht. Meine Lösung dagegen geht nicht so streng mit dem Signal um, und das erwies sich in diesem Fall als leichtes Vorteil. Muss noch dazu sagen, dass ich die Grenze des Übergangs in der Software von Peter von 150 auf 170ms erhöht habe, weil davor ein paar mal das Datum falsch angezeigt hat. Die Software hat 2 lang geratene Nullen schon als 1 interpretiert, Parität stimmte aber. Damit sieht man dass die Impulslängen Modulabhängig sein können und es unter Umständen in der Auswertung berücksichtigt werden muss. Vor dieser Korrektur war die Auswertung noch schlimmer. Was Peter aber besser gelöst hat ist die Feinjustierung des Timers. Bei meiner Lösung driften die Sekunden stärker weg in nicht synchronisiertem Zustand. Eine Uhr sollte aber so wieso mit Quarz laufen.
Ozvald K. schrieb: > Wenn das Signal gut ist, es ist egal mit welchem Verfahren man die Bits > extrahiert. Mit Störungen fangen die Probleme an. Wie würde ein > Oversampling beim gestörten Signal aussehen? Keine Ahnung... Oversampling ist von Prinzip nichts anderes wie eine Entprellung bei Tastern. Du addierst mehrere Werte innerhalb des Zeitfensters und bewertest dann das Ergebnis. Beispiel positives Signal als Quiz (für jedes richtige Ergebnis bekommt der Kandidat* einen Punkt): Wenn statt 1 mal 20x abgetastet wird hätte der Kandidat im Idealfall 20 Punkte. Bei mehr als 10 Punkten kriegt er aber Kandidat immer noch den Hauptpreis. Alles andere wären Nieten**. Störungen fallen von selber raus so lange Sie kürzer sind als die hälfte des Signals. Das kann man jetzt bis ins 100 1000 fache ausdehnen, ob das Sinn macht hängt von der Art der Störung ab. DCF Telegramm sind nah an der Netzfrequenz, es macht deshalb Sinn die Messpunkte immer etwas zu verschieben. _________ *Der Kandidat ist hier die Messung eines positiven (high) bits, für die negativen gilt es natürlich genau so. **Nieten entwerten nur den Teil der Botschaft in dem Sie vorkommen. Ein Fehler im der Sekunde z.B. lässt alle anderen Daten valide.
HyperMario schrieb: > Beispiel positives Signal als Quiz (für jedes richtige Ergebnis bekommt > der Kandidat* einen Punkt): > Wenn statt 1 mal 20x abgetastet wird hätte der Kandidat im Idealfall 20 > Punkte. Bei mehr als 10 Punkten kriegt er aber Kandidat immer noch den > Hauptpreis. Alles andere wären Nieten**. Störungen fallen von selber > raus so lange Sie kürzer sind als die hälfte des Signals. Das kann man noch etwas besser Ausrücken: Beispiel: Während einer Bitlänge wird 20 x gemessen. Die Ergebnisse werden addiert. Am Ende wird mit einem Schwellwert verglichen. Der ist erstmal willkürlich. Be einem Schwellwert von 9 wären ein Zählerstand von mehr als 11 ein high bit weniger als 9 ein Lowbit. Fehler bei Werten von 9 bis 11. Den Schwellwert kann man dann leicht ändern, auch die Samplerate. Das hängt von der Art der Störungen ab. Der Trick daran: Störungen fallen von selbst raus. Wenn Sie länger als der Schwellwert sind ist das Signal wohl so oder so unbrauchbar.
HyperMario schrieb: > DCF Telegramm sind nah an der > Netzfrequenz, es macht deshalb Sinn die Messpunkte immer etwas zu > verschieben. Das verstehe ich nicht. Die Netzfrequenz ist bei uns 50 Hz. Beim DCF wird ein Bit pro Sekunde übertragen, als 1 Hz. Der Unterschied ist Faktor 50. Was wiederum sinnvoll wäre, wenn das Abtastverfahren zum Einsatzkommt: eine Abtastrate von 10, 25 oder 50 Hz zu wählen. Damit werden Einstreuungen durch das Stromnetz wirksam unterdrückt.
Das DCF77- Modul von Pollin kostet 5,45€ und der Empfang ist in manchen baulichen Situation einfach unmöglich (s.a. Schaltnetzteile). Ich benutze dafür nur noch die GPS-Module mit der kleinen Antenne (5x15mm). Das reicht eigentlich immer und man bekommt die Uhrzeit per UART.
HyperMario schrieb: > Während einer Bitlänge wird 20 x gemessen. Die Ergebnisse > werden addiert. > > Am Ende wird mit einem Schwellwert verglichen. Ah, ok, das habe ich ohne dies schon gemacht, nur das Signal aus dem Empfängermodul ist ein bisschen anders als von einem Taster. Es wird im Modul selbst schon vorbereitet. Könnte mir gut vorstellen dass es bei einem Empfänger mit analogen Ausgang so funktioniert, aber bei Billigmodulen ist das Signal entweder da (auch mit Jittern), oder kommt fragmentiert heraus aber dann schon mit Aussetzten. (nächstes Bit fehlt z.B.) Aber kürzlich ist mir die Idee gekommen wie ich den Jittern entgegen wirken könnte. Wie man auf dem Bild "falsches_Datum" sehen kann, wurden 2 Bits im Datum als 1 interpretiert. Die Software hat die Schwelle von 0 auf 1 bei 150ms gehabt. Ich habe am 28.12. kurzfristig auf LCD das Datum 08.10. gehabt. Hier wurden mit 170ms Schwelle die "kurze 1-er" als 0 interpretiert. Deswegen meine Idee: ich werde mehrere Ergebnisse bilden, ein mit Sample 15 und ein mit Sample 17 z.B, und der plausiblere Wert wird übernommen. Das lässt sich in meiner Software mit relativ geringem Mehraufwand implementieren. Nennen wir es multisample-Verfahren. Und bin jetzt am Ende meiner "Diplomarbeit"...
Ein Punkt den ich hier bisher vermisse ist auszunutzen, dass die Sekunden-pulse im festen Abstand (bis auf den fehlenden) kommen. D.h. die Zeit für den Start der Pulse müsste man nicht jedes mal messen, sondern könnte einen Mittelwert über längere Zeit nutzen. Das sollte die Fehler bei der Pulslänge reduzieren, weil man so den Start einheitlich und besser hat. Für den Start der Pulse hätte man eine Art PLL, der einen Sekundentakt erzeugt und sich am Start der Pulse anhängt. Wenn der erst einmal eingerastet ist braucht der nur sehr langsam, und wenig nachregeln. Falsche Pulse in den Pausen werden so weitgehend unterdrückt, sofern der PLL nicht darauf einrastet, was eher unwahrscheinlich ist. Bei den Pulsen wird dann nur noch das Ende (und ob überhaupt da) individuell gemessen, etwa per Abtastung alle 20 ms. Auch wenn die einfache Parität nur Fehler erkennen kann ist das schon sehr Hilfreich. Eine Minute länger messen ist deutlich besser als eine falsche Zeit.
Tim schrieb: > Das verstehe ich nicht. > Die Netzfrequenz ist bei uns 50 Hz. > Beim DCF wird ein Bit pro Sekunde übertragen, als 1 Hz. > Der Unterschied ist Faktor 50. Stimmt. Ozvald K. schrieb: > Ah, ok, das habe ich ohne dies schon gemacht, nur das Signal aus dem > Empfängermodul ist ein bisschen anders als von einem Taster. Es wird im > Modul selbst schon vorbereitet. Dann kann man oversampling wohl vergessen.
Lurchi schrieb: > Eine Minute länger messen ist deutlich besser als eine > falsche Zeit. und deshalb macht man, wie oben schon mehrfach angeführt, jede Minute eine Plausibilitätskontrolle
Lurchi schrieb: > Ein Punkt den ich hier bisher vermisse ist auszunutzen, dass die > Sekunden-pulse im festen Abstand (bis auf den fehlenden) kommen. D.h. > die Zeit für den Start der Pulse müsste man nicht jedes mal messen, > sondern könnte einen Mittelwert über längere Zeit nutzen. Jetzt wird's interessant! Wenn man das Signal per Timer-Interrupt abtastet kann man den Teilerfaktor des Timers in kleinen Schritten verstellen. Damit ist die Abtastung synchron zu DCF, auch wenn der uC-Takt (fast) beliebig ungenau ist. Ein primitiver PI-Regler kann das recht gut. Übrigens kommen die Minuten-Marken auch im festen Abstand ;) Richtig interessant wird es aber erst, wenn man eine RTC mit Batterie hat. Dann kann man nämlich die DCF-Daten für die nächste Minute vorhersagen, jedenfalls das Datum. Damit hat man 8+1+1 aufeinander folgende Bits als Minuten-Marke. Normal kann man noch Wochentag und Stunde dazu nehmen, dann kennt man die Hälfte der 60 Bits im Voraus und muss nur noch die Minuten-Bits auswerten. Der entscheidende Punkt dabei: man vertraut nur der eigenen RTC und zieht sie nur ganz langsam nach. Dafür braucht man nur die Minuten-Bits. So verliert auch die Sommerzeitumstellung ihren Schrecken, weil man nichts davon merkt.
Angehängte Dateien:
-
DCF77_MSF60_Timecode.jpg
330 KB
Bauform B. schrieb: > So verliert auch die Sommerzeitumstellung ihren Schrecken, weil man > nichts davon merkt. Hi, kann man leich zusätzlich decodieren. Man muss nur den Time-Code kennen und die Bits ins SRAM schieben und auswerten. Für logs gibt es schon eine Seite im Netz. Manchmal ist der Empfang auch gestört. Oder seltener das Rufbit gesetzt. Irgendwie muss der Decoder das ja auch decodieren und das wird IMHO am einfachsten mit dem Schieben der gewünschten Bitfolge ins SRAM gemacht. (Die Meteotime Daten interessieren hier zunächst nicht. Brauchen u.U. 24 Stunden störungsfreien Empfang, um überhaupt erst einmal etwas aufs Display zu bekommen.) https://dcf77logs.de/logs (Hatte bei "meinem" Programm den Bug, dass immer bei Datumswechsel 24:60 angezeigt wurde. Erst dann direkt 00:01 ohne 00:00. Aber das ist mit der Auswertungssoftware leicht in den Griff zu bekommen.) ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
MSF60_A_code_B_code_.jpg
89 KB
Hi, noch ein Bildchen zu den beiden Codes ( A und B)bei MSF60. Bei dem vorgestellten Programm wird (leider) nur der A Code decodiert. Das reicht zur Zeit- und Datumserfassung, hat unter anderem allerdings dann keine Paritätskontrolle, die liegt im sogenannten B-code. Aber MSF60 hat noch eine Finesse, die DCF77 nicht aufweist: Die Bitfolge in den Sekunden 52 bis 59 am Ende ist mit 01111110 festgelegt, ändert sich nicht, kann somit zur Synchronisation zusätzlich verwendet werden. Will man Paritykontrolle und noch den DUT Code, dann braucht man wohl noch einen Co-Prozessor oder ein völlig anderes Decoderprogramm, das nicht wie beim einfachen DCF77-Programm mit dem Trick des Carrybits arbeitet. ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
VOLTCRAFT159_1.gif
24 KB -
VOLTCRAFT156_3.gif
17 KB -
VOLTCRAFT159_3.gif
17 KB
Ozvald K schrieb: > Wenn der INT0 wegen einer Störung ausgelöst > wurde, dann sind die Störungen ohne dies schon derartig massiv, dass man > kaum Vernünftiges mehr auswerten kann ... Hallo Ozvald, um Störungen zu minimieren habe ich versuchsweise mal eine Art Tiefpassfilter in einen ATTiny13 programmiert. Das DCF-Signal wird 333 mal pro Sekunde in ein 30Bit-Schieberegister geschoben. Nach jeder Abtastung wird ausgewertet wie viel Einsen im Schieberegister stehen. Anhand dieses Wertes wird, unter Berücksichtigung einer kleinen Hysterese entschieden, ob eine 1 oder eine 0 ausgegeben wird. Der Tiny läuft mit 1,2MHz, die IRQ-Routine dauert unter 100usec. Das Programm ist in Bascom geschrieben Falls Du mal probieren möchtest: Der DCF-Filter wird zwischen DCF-Empfänger und die Auswerteschaltung eingefügt. PB3 ist der Filtereingang, PB4 ist der Fiterausgang, PB0 ist ein Testausgang zur Messung der IRQ-Dauer Ob es mit Filter besser oder schlechter funktioniert, kann ich nicht sagen, dazu wohne ich zu nahe an DCF-Sender.
Alex D. schrieb: > um Störungen zu minimieren habe ich versuchsweise mal eine Art > Tiefpassfilter in einen ATTiny13 programmiert. Das klingt interessant, Alex - magst Du den Quelltext dazu veröffentlichen? Viele Grüße, Dirk
Hallo Alex, danke für die Mühe, nur das Problem ist, dass ich nie ein Dauersignal aus dem Empfängermodul so herausbekomme. Ich glaube das Modul selbst macht schon eine Art Filtrierung. Bei gutem Empfang ist das Signal stabil. Bei schlechterem Empfang fangt das Signal an zu "jittern", d.h. die Sekundenflanken wackeln ~ +/- 30ms, aber keine Spikes. Bei noch schlechterem Empfang entstehen solche Spikes aber dann zusammen mit Aussetzungen. Um es zu testen bräuchte ich ein Spike verschmutztes Dauersignal von mehreren Minuten, was aber nie der Fall ist. Wo hast Du das Signal her?
Stefanus F. schrieb: > Stelle den Empfänger mal neben einen WLAN Router. Oder neben ein Steckernetzteil was getaktet ist. Beides sollte natürlich eingeschaltet sein ;)
:
Bearbeitet durch User
900ss D. schrieb: > Stefanus F. schrieb: >> Stelle den Empfänger mal neben einen WLAN Router. > > Oder neben ein Steckernetzteil was getaktet ist. > Beides sollte natürlich eingeschaltet sein ;) Gut, das werde ich machen :-)
Dirk W. schrieb: > Das klingt interessant, Alex - magst Du den Quelltext dazu > veröffentlichen? Ja, aber ich muss das Prg. vorher noch etws aufräumen. Ozvald K schrieb: > Wo hast Du > das Signal her? Die Antenne stand zufällig in einem ungüstigen Winkel zum DCF-Sender. War nicht wiederholbar. Interessant sind aber nur Störungen wie sie in der Realität vorkommen. Gruß Alex
Find ich gut, dass du mit deiner Vorgehensweise auf die spezifischen "Macken" der Empfangsmodule eingehen kannst. Auch für die Module anderer Hersteller/Lieferanten kann damit ein optimaler Abtastzeitpunkt gefunden werden, der deren typische Pulsverformungen bei normalen und schwachem Pegel berücksichtigt. - Speichert man den gefundenen Abtastzeitpunkt ist die Uhr beim nächsten Einschalten gegenüber der Standardabtastung im Vorteil. Bei echt gestörtem Empfang hilft es natürlich nicht. Bei gutem Empfang stört es sowieso nicht, wenn 130, oder 170 ms nach der aktiven Flanke abgetastet wird, aber bei schwachem Empfangspegel kann es (je nach Modultyp) helfen. Nach sorgfältig auf Plausibilität geprüften Zeittelegrammen stellt, (oder "diszipliniert") man damit eine freilaufende Quarzuhr. Ich hatte mir sogar mal die Mühe gemacht, per Software die Gang- Abweichungen so einer DCF-Quarzuhr gegenüber den DCF-Korrekturen zu erfassen, um den Quarz (oder einfacher den Vorteiler von Quarztakt auf Sekundentakt) zu korrigieren. Das ist aber erst nach tagelanger Beobachtung und Mittelwertbildung sinnvoll, da der Sekundentakt aus dem DCF-Modul einige 10 ms jittert. Beispiel: DCF-Takt mit gültigen (!) Telegrammen jittert um +/-30 ms. Maximaler Fehler: 60 ms. Erst nach 16,7 Stunden kann man mit so einem (nur langfristig hochgenauen) DCF-Signal Zeitfehler von > 1 ppm erfassen.
Angehängte Dateien:
-
AD450_.jpg
40 KB
Hi, da ich im Hause praktisch keinen durchgehend sauberen DCF77-Empfang hatte, habe ich mir den AD450 am Balkongitter montiert. Nur bei Gewitter und starken statischen atmosphärischen Störungen "spinnt" der daran angeschlossene Decoder. https://www.buerk-mobatime.de/pages/shop/shopAction/showProductDetails/id/465/produkt/Zeitfunkempf%C3%A4nger Kostenpunkt ca. 170 Euro Der Witz ist, dass eine einfache unabgeschirmte Liyy Zweidraht-(Telefon)leitung ausreicht. Die Spannungsversorgung braucht keinen Extradraht, wie bei den meisten anderen Empfangsmodulen, die im I-Net angeboten werden. Polung der Drähte spielt auch keine Rolle. Schaltungsprinzip Stromschnittstelle. ciao gustav
Karl B. schrieb: > Kostenpunkt ca. 170 Euro > > Der Witz ist, dass eine einfache unabgeschirmte Liyy > Zweidraht-(Telefon)leitung ausreicht. > Die Spannungsversorgung braucht keinen Extradraht, wie bei den meisten > anderen Empfangsmodulen, die im I-Net angeboten werden. > > Polung der Drähte spielt auch keine Rolle. > Schaltungsprinzip Stromschnittstelle. Mit einem dreiadrigem Kabel und einem DCF-Modul von Conrad oder Reichelt hättest du dir 140€ Sparen können. Und so kompliziert ist es auch nicht, drei Adern korrekt anzuschließen.
Angehängte Dateien:
-
AD450_Aussenmontage_.jpg
40 KB
John schrieb: > Mit einem dreiadrigem Kabel und einem DCF-Modul von Conrad oder Reichelt > hättest du dir 140€ Sparen können. Hi, bin mir ziemlich sicher, dass die anderen Module die klimatischen Einflüsse nicht lange mitgemacht hätten. Habe übrigens auch die genannten Module ausprobiert, auch mit Aussenmontage nach Einbau in ein passendes Gehäuse. Sie lieferten mir kein verwertbares Signal. Und wenn, dann driftete der Empfänger weg, lief vielleicht ein paar Minuten, dann kamen wieder massenhaft Spikes. War also notgedrungen gezwungen, etwas besseres auszuprobieren, bevor ich der BNetzA Bescheid gebe. Leider gibt es Gegenden, da ist der Störnebel doch so groß, dass auf dem benutzten Längstwellenbereich kein Gras mehr wächst. Da muss man eben die besseren Empfänger verwenden. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Leider gibt es Gegenden, da ist der Störnebel doch so groß, dass auf dem > benutzten Längstwellenbereich kein Gras mehr wächst. Da muss man eben > die besseren Empfänger verwenden. In solchen Fällen fällt einem natürlich GPS als Alternative ein. Aber DCF funktioniert auch noch mit Schneehaube wie im Foto (danke dafür!). Was würde ein GPS-Empfänger an der Stelle noch liefern?
Bauform B. schrieb: > Was würde ein GPS-Empfänger an der Stelle noch liefern? (M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank innen sein Bit "Stabile Zeit" nicht setzen. Im Gegensatz zu DCF muss ich mit der Antennne raus aus dem Haus, das ist lästig. Die Frage ist natürlich, wie genau es denn sein soll, eine Wohnzimmeruhr oder ein Zeitserver in Konkurrenz zum ptb per Internet.
Dirk W. schrieb: > Das klingt interessant, Alex - magst Du den Quelltext dazu > veröffentlichen? Mit Bascom 2.0.8.1 für ATTiny13a compiliert. Im Quelltext kann man mehrere Einstellungen vornehmen: Abtastrate = CTC-Timer. Zur Änderung der Abtastrate einfach in "_irq_abstand" den gewünschten Zeitwert in nsec eintragen. Der Compiler errechnet dann aus $crystal und _irq_abstand die Einstellwerte. Das Schieberegister ist 30Bit lang. Bei einer Abtastrate von 3,333 msec passen genau 100msec in das Schieberegister. Die Hysterese lässt sich ändern, voreingestellt sind 13 und 15. Zur Anzeige des Eingangssignals kann an PB2 über einen 2,2K-Widerstand eine Leuchtdiode angeschlossen werden Analog dazu an PB4 für des Ausgangssignal. PB3 ist der Filtereingang PB4 ist der Filterausgang und LED-Anschluss PB2 ist zum Anschluss einer LED zur Anzeige des Filtereingangs PB0 ist ein Testausgang zur Messung der IRQ-Dauer Ob der Tiefpassfilter in der Praxis eine Verbesserung bringt, kann ich leider nicht sagen. Gruß Alex
wie "stabil" z.B. die (Sekunden)Flanke eines DCF RX ist könnte man ja per Vergleich mit einem GPS pps Signal ermitteln, welches ja auch bei den günstigsten GPS RX mit max. ~40ns Jitter angegeben ist.
Manfred schrieb: > (M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank > innen sein Bit "Stabile Zeit" nicht setzen. Kannst du das mal in NMEA0183 ausdrücken oder wo liest du so ein Bit bei einem GPS-Empfänger ab?
Wolfgang schrieb: > wo liest du so ein Bit bei einem GPS-Empfänger ab? Ich habe dafür den RMC-Datensatz genommen. Das zweite Feld ist ein Statusbyte. Steht dort ein 'A', ist die Zeit gültig, steht dort ein 'V', ist sie nicht gültig. Die Zeit selber steht in Feld 1 in UTC, in Feld 7 steht das Datum. Fehler sind mit ',' getrennt. Der RMC- Datensatz wird auch von allen Empfängern geliefert, dass trifft nicht auf alle Datensätze zu. Zwei Beispiele mit Status 'A':
1 | $GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62 |
2 | $GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68 |
Der Status hier hat aber noch nichts mit dem Positionfix zu tun. Die Position kann noch ungültig sein obwohl der Status auf 'A' steht. Die Zeit in dem RMC-Datensatz ist dann aber gültig.
:
Bearbeitet durch User
Angehängte Dateien:
-
VOLTCRAFT9_1.gif
18 KB
Alex D. schrieb: > Ob der Tiefpassfilter in der Praxis eine Verbesserung bringt, kann ich > leider nicht sagen. Hallo Alex, habe deinen Tiefpassfilter (noch) nicht getestet, aber was anderes: habe bei gutem Empfang den Empfänger mit einem Schaltnetzteil beeinflusst. Bei zunehmender Störung wird erst gejittert, dann kommen Spikes dazu. Habe eine Position gefunden wo es nur gejittert hat ohne Spikes, aber das stark (+/- 30ms). In diesem Zustand habe ich ~ halbe Stunde getestet. Die Software von Peda ist damit überhaupt nicht mehr zu Recht gekommen, bis meine nur 2x mit Parity Error aus dem gelockten Zustand ausgefallen ist. Gehe sogar weiter, die ab und zu Spikes können auch nichts anhaben, solange in Bereich fallen wo der Interrupt verboten ist. Bei starken Störungen wie am Bild hilft das dann auch nicht mehr. Meine Prognose für Filter: Wenn der Tiefpassfilter die Jitters auch weiter reicht (und ich vermute, ja), dann würde das für die Software mit Impuls-Längenmessung auch nichts bringen, es sei denn man definiert die Grenzen "locker". Es interessiert mich aber ohne dies was bei solchen starken Störungen wie am Bild herauskommt. Noch Etwas: Ich möchte die PeDa-Software nicht schlecht machen, aber fehlen mir die Kenntnisse um sie zu finetunen, und mein Fokus liegt jetzt so wieso anderswo.
Mal eine Zwischenfrage: was meint ihr mit "Jitter"? Jittert die Vorderflanke (also die Sekunde fängt 30ms früher oder später an) oder die Impulsbreite (also 70 bis 130ms statt 100ms)?
Bauform B. schrieb: > Jittert die > Vorderflanke (also die Sekunde fängt 30ms früher oder später an) oder > die Impulsbreite (also 70 bis 130ms statt 100ms)? Beides. Wenn du die (weiter oben) angehängten Fotos mit Uhren ansiehst, siehst du vier Variablen die ausgegeben werden. "Q"ality zeigt die Anzahl der 1-er in den Samples, die mit schon beschrieben Verfahren ermittelt werden, "W"idth zeigt den Abstand (in Hexadecimal) zwischen 2 Sekundenflanken, "S"tatus zeigt den Zustand (synchronisiert/nicht synchronisiert) und "C"heck zeigt ob und wo die Konvertierungsroutine Fehler gefunden hat. Bei gutem Empfang habe ich (großteils) W64 und Q90 oder Q99 angezeigt. Wenn es jittert, dann dann habe ich W61-67 und Q60,70,80, 90-99 alles dabei.
..da ich nicht editieren kann, Nachtrag: ich habe in meinem Beitrag mit Jittern in diesem Fall die variierende Flanke gemeint, aber die Impulsbreiten variieren auch, von 60 bis über 200 ms ist alles dabei.
Karl B. schrieb: > Hi, bin mir ziemlich sicher, dass die anderen Module die klimatischen > Einflüsse nicht lange mitgemacht hätten. Das Reichelt-Modul ist für -10°C…+70°C spezifiziert: https://www.reichelt.de/dcf-77-empfaengermodul-dcf77-modul-p57772.html? Bei Reichelt gibt es auch dieses Modul (–20°…+50°C): https://www.reichelt.de/dcf-77-funkempfaenger-hm-fu20-00-p174059.html? Zwei-Draht und polaritätsunabhängig zum halben Prei (Vergleich zu Bürk). Wie ist der Temperaturbereich von deinem Bürk-Modul. Hast du ein Datenblatt. Ich kann online nichts finden.
Angehängte Dateien:
-
Bild_von_Alex.gif
17 KB
So ähnliche Störungen hatte ich auch mal, bei einer selbst gebauten Uhr mit TIL311 LED-Anzeige. Für einigermaßen störungsfreien Empfang musste der Empfänger mindestens 30…40cm von der Anzeige entfernt sein und sehr genau ausgerichtet werden. Mit einem Filter in der Versorgungsspannung (C1, R2) gab es keine Störungen mehr. Auch nicht wenn der Empfänger nur wenige cm von der Anzeige entfernt platziert wird und nur ungefähr in Richtung Mainflingen ausgerichtet ist. Empfänger siehe hier: Beitrag "Re: Reichelt DCF77-Empfänger" Gruß John
John schrieb: > Mit einem Filter in der Versorgungsspannung (C1, R2) gab es keine > Störungen mehr. Ok, dann platziere einen (Laptop) Schaltnetzteil in die Nähe vom Empfängermodul :-) Ich habe es auch so, zusätzlich parallel zu C noch eine Zenerdiode und Elko.
John schrieb: > Wie ist der Temperaturbereich von deinem Bürk-Modul. Hast du ein > Datenblatt. Ich kann online nichts finden. Hi, habe nur das an Info noch gefunden. (Das Modul hat Bauteile nach MIL-Norm eingebaut.) Beitrag "Re: Trennstufe für DCF Modul gegen Schwingen ?" Man sieht, der Empfänger ist ursprünglich für die Bahnuhren konzipiert. Die Detailinformationen und Preisanfragen sollten ausschließlich über die Kundendienstadresse laufen. https://www.buerk-mobatime.de/pages/Kontaktform/ ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
DCF.jpg
91 KB
Ozvald K schrieb: > Ok, dann platziere einen (Laptop) Schaltnetzteil in die Nähe vom > Empfängermodul :-) Ist das genug "in der Nähe"? Vorne in der Mitte ist der DCF-Empfänger. Direkt dahinter die Uhr mit LED-Multiplexanzeige. Es hat etwas über 10 Minuten gedauert, aber die Uhr hat synchronisiert. Gruß John
900ss D. schrieb: > Der Status hier hat aber noch nichts mit dem Positionfix zu tun. Die > Position kann noch ungültig sein obwohl der Status auf 'A' steht. Die > Zeit in dem RMC-Datensatz ist dann aber gültig. Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen, wenn er nicht weiss, wo er ist? Eine Aussage über die Genauigkeit liefert erst der TDOP- bzw. GDOP-Wert. Insofern ist für die Bewertung der Genauigkeit eher der GSA-Sentence geeignet.
Manfred schrieb: > "DATA ist current source/sink mit Iout > 5 µA." Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max. angegeben sein....
Wolfgang schrieb: > Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen, > wenn er nicht weiss, wo er ist? Ich wäre dafür, dass wir mit den GPS-Feinheiten umziehen: Beitrag "GPS- statt DCF77-Auswertung (ein bisschen anders)"
Bernd D. schrieb: > Manfred schrieb: > >> "DATA ist current source/sink mit Iout > 5 µA." > > Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss > der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max. > angegeben sein.... Das passiert oft, denk' dir nichts...
Dass soll heissen, dass der Ausgang mindestens mit 5µA belastbar ist. Wenn du Glück hast, funktioniert er auch mit mehr Strom.
John schrieb: > Ist das genug "in der Nähe"? ok, aber da spielen mehrere Faktoren mit. Der Filter in der Versorgung filtert den Mist aus der Versorgung aus, aber nicht die em-Strahlungen von einem Schaltnetzteil was die Ferritantenne aufnimmt. Bernd D. schrieb: > Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss > der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max. > angegeben sein.... Der Ausgang ist hochohmig und verträgt keine Belastung. Es reicht aber eine Minimalbeschaltung um Modul herum, siehe Beitrag von John. Habe kurzfristig versucht mit einem OpAmp als Impedanz- und Pegelwandler + LED Treiber, aber der LM358 ist dafür nicht geeignet, weil: 1.kann kein Rail to Rail und bei 5V Versorgung gibt keinen höheren Pegel aus was das Signal eh schon hat (3v), und 2. intern ist frequenzkompensiert, dadurch war die Anstiegszeit der Flanke am Ausgang viel schlechter. (~10µS)
John schrieb: > Direkt dahinter die Uhr mit LED-Multiplexanzeige Die schönste Uhr mit LED-Matrix im Universum ;) Super gemacht.
Wilhelm M. schrieb:) > Ich benutze dafür nur noch die GPS-Module mit der kleinen Antenne (5x15mm). > Das reicht eigentlich immer und man bekommt die Uhrzeit per UART. Hast du da einen Typ, Hersteller, Lieferanten? Danke :-)
Ozvald K schrieb: > Wenn der Tiefpassfilter die Jitters auch weiter reicht (und ich vermute, > ja) Hallo Ozvald, dass der Tiefpassfilter den Jitter verbessert, glaube ich auch nicht. Der Jitter wird eher noch größer werden, da das Signal im 3,3 msec Raster abgetastet wird. Mit dem von Dir dargestellten Signal wird der Filter sicher nicht fertig, dazu liegen die Störimpulse zu dicht am 100msec Nutzsignal. Kurze Spikes werden schon entfernt. Auch ich habe meine eigene DCF-Uhr gebaut, einfach weil es mir Spaß gemacht hat. Obwohl es genug fertige und sicher auch bessere Vorschläge gibt. Eine Rückmeldung zu meinen DCF-Programm habe ich lustigerweise mal aus .at erhalten. Dort hat es in 700km Entfernung gut funktioniert. Mein DCF-Prg. zählt einfach nur die Dauer der Pausen aus. Also 800msec, 900msec und die 1800msec bis 1900mse aus. Ist einfacher auszuwerten. Vorgeschaltet ist ein 3.stufiges Schieberegister. Erst wenn 3 gleiche Samples im Register sind, wird auf 0 oder 1 erkannt. Also Mindestbreite = 60msec. da das Signal in 20msec Abstand abgetastet wird. Interessant sind die verschiedenen Lösungsansätze, dabei kann man noch einiges lernen. Gruß Alex
Wolfgang schrieb: >> (M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank >> innen sein Bit "Stabile Zeit" nicht setzen. > Kannst du das mal in NMEA0183 ausdrücken oder wo liest du so ein Bit bei einem GPS-Empfänger ab? Lange ist's her ... ich suche jetzt nach und finde es im Datenblatt des CXD2951 auf Seite 41 "Data valid / Data invalid" oder in AN07NMEA183-010 auf Seite 23. Spielobjekt war eine GPS-Maus Navilock NL-208P mit serieller Schnittstelle.
Was ist beim DCF77 faul? Seit gut zwei Wochen sehe ich des öfteren, dass meine Uhr keinen Empfang hat. Ich gucke dann auf https://dcf77logs.de/live und sehe, dass auch dort keine Decodierung möglich ist. Der Kerl sitzt etwa 200km nördlich von mir, damit kann ich eine lokale Störung bei mir sicher ausschließen.
Meine auch, ca. 500km nördlich von Frankfurt. Ich habe abends auch oft Empfangsstörungen bei der Uhr. Ist wohl normal durch atmosphärische Störungen. Ist schon seit 12 Jahren so :) Im Sommer weniger.
:
Bearbeitet durch User
Letzte Nacht war der Sender für einige Zeit komplett aus. Ich konnte beobachten, dass er wenige Sekunden vor 23 Uhr wieder gesendet hat. In den ersten paar Minuten gab es noch einige Aussetzer. Laut PTB ist eine Ursache für längere Unterbrechungen Sturm, Eisregen und Schnee. https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/verfuegbarkeit-und-empfangsberechtigung.html „Die häufigste Ursache für diese länger andauernden Unterbrechungen war die elektrische Verstimmung des Antennenresonanzkreises durch Auslenkung der Antenne in starkem Sturm, bei Eisregen und Schnee. Bei zu großer Fehlanpassung wird die Aussendung unterbrochen.“ Gruß John
Die Beiden Signal habe ich letzte Nacht aufgenommen: DCF77_Ausfall.mp3 -> 22:50 Uhr DCF77_Auido-Signal.mp3 -> 23:05 Uhr Gruß John
Hi, kann noch ein paar ältere Direktmischer-Audioaufnahmen beisteuern. Da arbeitete noch der HBG in der Schweiz, daher zwei Differenztöne im Trägerabstand zu DCF77. Das gute Signal bringt auch noch einen Überschwinger. Das ist offensichtlich ein "Filterartefakt". Man hört auch die Extra-Zufallsbits als Rauschen. Das als schlecht bezeichnete Signal enthält die HF-Überlagerung eines Schaltnetzteils mit Lastausregelung. Hier ist keine Decodierung mehr möglich, wenngleich die Sekundenmarken als diskreter Pfeifton akustisch neben den "jitternden" Pfeif-Störungen noch wahrnehmbar bleiben. ciao gustav
Ich fasse das alles mal zusammen: - Gegen Breitbandstörer wie chinesische Schaltnetzteile ist kein Kraut gewachsen, nur gehöriger Abstand. - Wer außer dem Antennenkreis keine weitere Selektion hat, nimmt den vierfachen Abstand zum Störer. - Gegen schlechten Empfang und Rauschen ist schon ein Kraut gewachsen: ordentlich HF-Verstärkung. Wer mit einem FET im Antennenkreis (ohne Verstärkung) und einem Transistor (mit Verstärkung) was Anständiges empfangen will, kriegt halt in 500 km Entfernung nicht so arg viel HF-Signal. Was heutzutage sich so alles AM-Empfänger nennt, ist oft nicht viel mehr als ein besserer Germanium-Detektor. - In allen Diagrammen, die hier gepostet wurden, waren ganz saubere Rechtecke zu sehen. Wer da statt eines simplen INT noch (Over-)Sampling macht, hat es nicht anders verdient. Lässt man einen 16-Bit-Timer mit z.B. 1 ms Takt laufen, liest den bei jedem INT ab und setzt ihn dann wieder auf Null, der hat schon alles, was er braucht. Wenn man im INT noch alles ignoriert, was kürzer als z.B. 10 ms ist, braucht sich auch um Rauschen und spurious signals nicht mehr zu scheren. - Ist die gemessene Signaldauer irgendwo um 100 ms, ist es eine Null, ist es irgendwo bei 200 ms eine Eins, ist es zwischen 800 und 900 ms ist es ein Sekundenzwischenraum und ist es zwischen 1800 und 1900 ms lang ist es ein Minutensignal. Alles was in dieses Schema (mit etwas Toleranz nach oben und nach unten) nicht reinpasst, ist HF-Schrott. Ob das Signal high- oder low-aktiv ist, ist dann auch egal, wenn man bei jeder Flanke einen INT auslöst. - Überstehen alle eingegangenen Signale diese Prüfung ihrer Dauer, sind zum Minutenwechsel genau 59 Signale eingegangen und prüft man alle Einer ob sie nicht mehr als Neun sind, alle Zahlen ob sie nicht mehr als im zulässigen Bereich sind (beim Tag und beim Monat auch die Null) und alle Paritätsbits auf Nullsumme hat man das Signal schon hinreichend überprüft. Auf das dreimalige Abchecken, ob die Minuten genau um Eins gewachsen sind (was sie zur vollen Stunde eh nicht tun) kann man dann vollkommen verzichten? Einschalten, maximal zwei Minuten warten, und alles ist perfekt. Ich habe mir also mit einem ollen TCA440 einen Superhet mit 455 kHz ZF gestrickt (siehe http://www.avr-asm-tutorial.net/avr_de/apps/dcf77_m16/dcf77_superhet/dcf77_superhet.html), der in 50 km Entfernung zu Mainflingen selbst noch innerhalb einer Wellblechkeksdose noch genug Signal produziert und das Auswerteprinzip in einem ATmega16 umgesetzt (siehe http://www.avr-asm-tutorial.net/avr_de/apps/dcf77_m16/dcf77_uhr_m16.html) und dort auch das Auswerteverfahren detaillierter beschrieben. Seither habe ich schon in 50 cm Distanz zu meinem wild strahlenden Lenovo-Netzteil keine Aussetzer mehr. Und die Fehlermeldungen zu Signal-/Einer-/Paritäts-Fehler habe ich nur gesehen, wenn Lenovo daneben lag. Empfangsstörungen habe ich seither nur noch dann, wenn der Lautsprecher eine Weckmelodie abspielt. Gut, der ist auch nur zwei Zentimeter weit weg von der Empfangsantenne. Auf Entstörmaßnahmen der abgespielten Rechtecke habe ich wegen der Seltenheit solcher Störungen verzichten können. mfg gerd
Manfred schrieb: > Mit den käuflichen Empfängern wird man niemals ganz genau, bei den > Superhet-Bausteinen habe ich ein gehöriges Jittern gesehen, welches mein > Geradeausempfänger nicht hat. gerd schrieb: > Ich habe mir also mit einem ollen TCA440 einen Superhet mit 455 kHz ZF > gestrickt Hallo Gerd, dass du mit einer TCA440 IC besser unterwegs bist, das glaube ich gerne. Aber was sagst zu der Aussage von Manfred? Er bevorzugt den Geradeausempfänger. Hast du schon einen direkten Vergleich machen können?
Angehängte Dateien:
-
DS1Z_QuickPrint17.png
42 KB
Alex D. schrieb: > Das DCF-Signal wird 333 > mal pro Sekunde in ein 30Bit-Schieberegister geschoben. Nach jeder > Abtastung wird ausgewertet wie viel Einsen im Schieberegister stehen. > Anhand dieses Wertes wird, unter Berücksichtigung einer kleinen > Hysterese entschieden, ob eine 1 oder eine 0 ausgegeben wird. Funktioniert PeDa's Routine nicht ähnlich? Meine ich zumindest im Hinterkopf zu haben. Sieht wirklich gut aus :-) Ich habe hier ein Modul von - keine Ahnung, schon recht alt aus einer Uhr - was bei guter Ausrichtung auch gute Ergebnisse liefert. Bei sehr schlechter Ausrichtung "stottert" das Signal. Ich hebe den Pegel (etwas ungewöhnlich, habe ich irgendwo nachgemacht) mit einem TCDT 1121 und glätte mit 22 pF etwas. Ergebnis anbei (bei schlechter Ausrichtung).
Ozvald K schrieb: > dass du mit einer TCA440 IC besser unterwegs bist, das glaube ich gerne. > Aber was sagst zu der Aussage von Manfred? Er bevorzugt den > Geradeausempfänger. Hast du schon einen direkten Vergleich machen > können? Geradeausempfänger habe ich auch schon einige gebaut. Funktionieren bei der niedrigen Frequenz auch ganz brauchbar. Aber so etwa bei Verstärkung von einigen 100 ist dann definitiv Schluss. Bei mir in der Nähe von Mainflingen kann ich das DCF-Signal schon mit einigen mV im Antennenkreis sehen, da reichen 1.000 an Verstärkung schon recht gut aus. Das dürfte aber in 500 km Entfernung etwas anders aussehen. Entscheidender beim Superhet ist aber die Selektion. Wenn man keine Quarzfarm mit 77,5 kHz bauen will, hat so ein Keramikteil mit 455 kHz so seine Vorteile. Und man ist den ganzen Schrott unter 70 kHz und über 90 kHz los, den Schaltnetzteile so produzieren. mfg gsc
Hi, der "Gude" hatte im Frankfurter Raum im Display stehen "Resonanzfall". https://www.gude.info/fileadmin/user_upload/pdf/sb/steckbrief-emc3001-3011.pdf (Innen jede Menge Siferrit-Schalenkerne.) Das deutet darauf hin, dass eine Pegelanpassung je nach Standort nötig ist. Entweder erfolgt die automatisch, oder die Antenne wird "rausgedreht". Man ist ja bei Geradeausempfängern je höher die Verstärkung wird, der Gefahr der Rückkopplung ausgesetzt. Daher wurde ja auch das Superhetprinzip favorisiert. Hat aber auch Nachteile. Die Mischprodukte zum Beispiel. Das geht mit entsprechenden Filtern dann ganz gut, eine Spiegelfrequenzselektion hinzubekommen. Jedenfalls besser als gerd schrieb: > Wenn man keine > Quarzfarm mit 77,5 kHz bauen will. Gerade diese Quarze haben auch Einschwingvorgänge. Bei "normalem" Rundfunk würde das wohl nicht so viel ausmachen, hier will man möglichst saubere Schaltflanken. Bei Superhets: Nur die Frequenz des Mischer-Oszillators müsste möglichst driftfrei sein. (Quarzofen) ciao gustav
Karl B. schrieb: > Gerade diese Quarze haben auch Einschwingvorgänge. Bei "normalem" > Rundfunk würde das wohl nicht so viel ausmachen, hier will man möglichst > saubere Schaltflanken. > Bei Superhets: Nur die Frequenz des Mischer-Oszillators müsste möglichst > driftfrei sein. (Quarzofen) Für normalen Rundfunk ist ein so schmalbandiges Filter nicht zu gebrauchen. Auch der normale CW Morsecode ist eher schneller als das DCF Signal. Mit dem LO muss man es nicht übertreiben, wenn man das Signal nicht phasenstar auswertet. Wenn man das macht dann wohl um die 77,5 kHz Trägerfrequenz zu gewinnen, und dann hat den stabilen Takt für den LO, in der Regel dann wohl als VCXO. Ein normaler Quarz für den LO-Takt ist vollkommen ausreichend. Das ist immer noch stabiler als die 455 kHz ZF Filter. Um den Takt der Quarzuhr zu korrigieren würde ich nicht das Sekundensignal selber nutzen, sondern eher die Zeitkorrektur von Tag zu Tag.
Karl B. schrieb: > Man ist ja bei Geradeausempfängern je höher die Verstärkung wird, der > Gefahr der Rückkopplung ausgesetzt. Um Rückkopplungen zu vermeiden, habe ich die Feriitantenne mit dem 1.Transistor ca. 1m vom Empfänger aufgestellt und richte die Antenne mittels Oszi auf maximale Amplitude. Entfernung zum Sender: ca. 350km
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.