sth77:
Hallo, ich bin fleißiger Mitleser, allerdings beruflich bedingt noch nicht viel zum Testen meiner DCF-Module (von Pollin und Conrad) gekommen. Ein 2-Kanal-50MHz-Oszilloskop hätte ich, wenn es konkrete Signalverläufe (z.B. beide Module an jeweils einem Kanal) darzustellen gilt, könnte ich die wohl auch liefern.
Meine damaligen Erkenntnisse habe ich hier festgehalten: sth77 | Arduino Blog: Projekt Analoguhr - Teil 3 Auf den viel zu kleinen Bildern erkennt man den Signalverlauf nicht besonders gut, das Video im Vollbildmodus scheint mir da besser geeignet.
Hallo, danke fürs Posten! Die von Dir gezeigten Signalverläufe passen eher zu dem, was mein Conrad-Modul auch liefert:
-
Einschwingfehler bzw. "Prellen": Beim Wechsel des Pegels kann es sein, dass ganz kurze Zeit danach der Pegel noch ein- oder mehrmals ganz kurz zurückschwingt und den Pegel mehrmals wechselt, bevor der Pegelwechsel endgültig vollzogen ist.
-
Spikes: Kurze, oft nur einzelne Störungen während ein Pegel gesetzt ist, die nach wenigen Millisekunden wieder verschwinden
Das von Udo in Bild http://blinkenlightblog.files.wordpress.com/2012/11/c05_simple_pulse_train_noise_60_1000.png gezeigte Störverhalten, mit ständigen und extrem kurzfristigen Pegelwechseln als ein dem Signal überlagertes "stochastisches Rauschen mit hoher Frequenz" kann ich für keines meiner Module nachvollziehen.
Anyway, wer selber Testen möchte, für den habe ich mein DCF-Modul-Testprogramm nochmal etwas weiter aufgebohrt.
Mit demselben Sketch kann man nun durch Setzen eines #define Statements sowohl zwei DCF-Module anschließen und deren Signale gegeneinander vergleichen. Oder man kann ein DCF-Signal vom DCF-Modul gegen das per Softwarefilter gefilterte Signal vergleichen.
Folgende Daten werden angezeigt (erste vier Spalten):
A/B: Signale der beiden DCF-Module, oder ein DCF-Modul und dessen gefiltertes Signal
0/1: Es wurde ein 0-Bit oder 1-Bit erkannt
xxx: Zahl zwischen 50 und 250 mit der erkannten Dauer des Bits
Die vierte Spalte gibt die Anzahl der fehlerhaften (<50ms) Impulse an, die zuvor seit dem letzten gültigen Bit aufaddiert wurden
Folgende Fehler im Signalverlauf werden angezeigt:
- Summe der kurzen Pegelfehler (<50ms Pegelwechsel) zwischen zwei korrekten Impulsen (50 ... 250 ms)
- Bitfehler '#': Derselbe Eingang liefert zwei Bits nacheinander, das Bit des anderen Eingangs fehlt dazwischen
- Bitfehler '*': Ein Eingang liefert innerhalb von weniger als 500ms ein anderes Bit als der andere Eingang
(wobei aber nicht sicher ist, dass der mit * gekennzeichnete Eingang tatsächlich das falsche Bit geliefert hat)
- SYNC-Fehler: Ein Eingang liefert für mehr als 1500 ms überhaupt kein Bit (normal beim Minuten-Marker zur vollen Minute)
Die fünfstellige Zahl sind die letzten fünf Ziffern des millis() Timers
Beispiel:
B 0 124 0 24197
A 0 139 0 25168
B 1 178 0 25257*
A 1 218 1 26236
A 0 122 8 27148#
B 0 121 0 27197 SYNC
A 0 128 0 28149
B 0 129 0 28199
Erklärung:
In Sekunde 25xxx hat das B-Modul ein 1-Bit geliefert, aber das A-Modul ein 0-Bit, daher Bitfehler *
Bei Timer 27148 hat das A-Modul zweimal hintereinander gefeuert, daher Bitfehler #
Bei Timer 27197 tritt ein Sync-Fehler an Modul B auf, da das vorherige Bit von Modul B älter als 1500ms ist
(Modul B hatte davor zuletzt bei Timer 25257 gefeuert, und in Sekunde 26xxx gar nicht)
Na ja, das ist das beste, was ich als Auswertung herausholen konnte. Die Messung und Ausgabe der Werte verfälscht natürlich immer etwas das, was eigentlich genauestens vermessen werden soll. So dauert die Formatierung mit "printf" recht lange, Pegelwechsel werden also automatisch etwas "entprellt", ohne dass dies gewollt ist. Dadurch sieht das Signal des Conrad-Moduls etwas besser aus als es tatsächlich ist.
So wie das Programm unten einkopiert ist, dient es zum Testen von Udos Exponentialfilter.
Einfach DCF-Modul an Pin-2 hängen und Sketch laufen lassen mit Ausgabe über den seriellen Monitor.
Was man deutlich sieht: Der Exponentialfilter verzögert das DCF-Signal am gefilterten (B) Ausgang um ca. 50 ms.
Eine Verbesserung des Signals durch den Filter kann ich allerdings nicht feststellen, weder an einem mittelstark noch an einem stark gestörten Signal. Sobald der Störpegel hoch genug ist, dass die "High"-Pegel von Störsignalen zerhackt werden, so dass das Conrad-Modul keine einwandfreien Signale mehr liefert, ist auch das gefilterte Signal fehlerhaft (Sync-Fehler beim ungefilterten und beim gefilterten Signal in derselben Sekunde).
Nur sehr selten läßt sich durch das Filter eine gute Fehlerkorrektur erkennen wie hier:
A 0 70 1 68087
B 0 70 0 68137
A 0 51 0 69069
A 0 108 0 69186#
B 1 165 0 69233*
A 0 89 0 70087
B 0 90 0 70138
In Sekunde 69xxx feuert das Conrad-Modul zwei gültige Bits (51 und 108ms lang) in derselben Sekunde (Bitfehler #), aber das gefilterte Signal gibt nur ein einziges Bit aus, und zwar ein langes 1-Bit statt zweier kurzer 0-Bits, daher Bitfehler * angezeigt. Da man weiß, dass im DCF-Protokoll nur ein Bit pro Sekunde übertragen wird, kann man also davon ausgehen, dass das am gefilterten Ausgang(B) gelieferte 1-Bit korrekt ist und die zwei davor am A-Ausgang signalisierten 0-Bits falsch.
Im Schnitt ist auf dem gefilterten Signal zwar weniger Gezappel durch weniger Flankenwechsel, aber dabei gehen praktisch genau so viele Bits von Sekundenpulsen verloren wie bei der Auswertung des ungefilterten Signals. Denn das Gezappel durch Flankenwechsel tritt bei gestörtem Signal nicht gleichverteilt über das gesamte Signal auf, sondern bevorzugt um die Zeit herum, um die tatsächlich ein Flankenwechsel stattfindet. Und das läßt sich eigentlich auch durch ein einfaches Entprellen des Signals von wenigen ms gut herausfiltern.
Was ergeben Eure Tests?
Also meine anfängliche Euphorie über den Exponentialfilter und dass damit das Signal viel besser aussieht, konnte ich durch meine Messungen nun nicht mehr bestätigen. Zwar sind gefilterte Signale immer mindestens 50 ms lang, während ungefilterte Signale oft sehr zappelig sein können, aber da die Zappeligkeit fast nur um den eigentlichen Flankenwechsel herum auftritt, ist eigentlich auch das Originalsignal gut auswertbar.