Aufbauend auf folgenden Thread Beitrag "DCF-Fehlerkorrektur im Streßtest" würde es mich interessieren wie das Problem gelöst wurde das dass Signal aus dem Fenster läuft? Mit Fenster meine ich den Bereich wo gefaltet wird. z.Bsp 1sec. Nehmen wir an wir ermitteln das Maximum für 1sec. und den Index dazu. Da der µP nicht synchron läuft und der Takt je nach Board nicht genau die 10ms trifft wandert das Signal mehr oder weniger schnell aus dem Fenster. An den Rändern wird das Signal dann geteilt und ist somit nicht mehr auswertbar. Bei 1sec. Faltung kann man dem Signal hinterher laufen, also immer wieder den Index wo gefaltet werden soll ermitteln. Wenn ich es aber richtig verstanden haben wird später ausschließlich mit einen 200ms großen Fenster gefaltet. Somit kann man sich nicht mehr am Index orientieren da dieser ja gleich bleibt. Wenn das ganze nicht auseinander driftet. Das führt eben dazu das die Maxima geringer werden bis das Signal aus dem Fenster gerutscht ist. Es ist nötig den Timer so anzupassen das er möglichst genau ist. Damit das Signal auch im Fenster bleibt. Ein Regeln auf das Maxima wäre möglich aber gestaltet sich relativ schwierig. Wer hat die Auswertung nach dem oben genannten Thread realisiert und wie wurde das weglaufen verhindert ? Bei mir läuft es jetzt so das ich beim Start das Signal erst mal in der Mitte des 1sec Fensters schiebe. Dann schaue in welche Richtung es läuft und dann den Timer CC anpasse. Nach der Umschaltung auf 200msec habe ich noch keine Lösung das Signal im Fenster zu halten. Es reicht aber aus das DCF Signal auszuwerten. Danach muss wieder auf 1sec geschaltet werden um den Index neu zu ermitteln.
:
Verschoben durch User
Klassisches vorgehen, kein adj. vom Timer usw.
jede ms wird der Eingang geprüft, high = 16ms high ohne Unterbrechung,
, low = 32ms low ohne Unterbrechung.
0) 1 Sek kein Signal
1) warten auf Signal 50-150ms , Sekunde+ms auf 0 setzen, weiter mit
state3
2) warten auf Signal 50-250ms , wenn Sekunde==0 dann Fehler ignorieren,
ansonsten gehe zu state 0
3) 750ms kein input sampling
4) Signal start muss innerhalb von 200ms starten, ansonsten state 0
5) Wenn sek=59 dann Auswertung der Daten
6) 1700ms kein input sampling, weiter mit state 2
Time Adjust, alle 5 oder 50 Minuten beim Quarz, ansonten alle 1 und 10
Minuten.
Gibt es nach 5 Minuten eine Abweichung >= 1ms dann wird korrigiert,
ansonsten wird weitergezählt auf 50 bis 254 Minuten hochgezählt und dann
korriegiert sobald das erste korrekte Datensatz kommt.
Ab 50 Minuten 1ms, ab 100 2ms, ab 150 3ms Abweichung usw, darunter wird
nicht korrigiert.
Mit time Adjust kann man engere Tolleranzen vorsehen.
Das Problem ist das zumindest bei dem von mir verwendeten Board die Differenz recht groß ist. 8MHZ Takt teilt auf 1MHZ -> CC 10000 = 10ms Der Fehler beträgt 50µS auf 10ms bezogen. Für eine 1Sec läuft das ganze 100 mal ab. Macht einen Fehler pro Sekunde 5ms nach 3 Sekunden sind es dann schon 15ms. Der Index des Maximums schiebt sich also langsam raus. Wenn man auf 200ms das Fenster setzt ist das Signal nach <10sec nicht mehr auswertbar. Da mit 50ms das ganze schon halb raus gelaufen ist. Folgendes wurde Probiert. Gültige Bits einsortieren und Referenz setzen. Nach x Sec Differenz ermitteln und ausrechnen. Timer anpassen. Neue Referenz setzen. wieder warten und berechnen. Zum Teil lässt sich damit das Problem kompensieren. Nach dem Umschalten steht aber das Fenster von 1sec nicht mehr zur Verfügung. Man Faltet ja eben genau an der Stelle wo man das Signal vermutet. Man könnte auf das Maxima dann regeln. Das muss ich noch probieren ob das überhaupt was bringt, da es zu stark Abhängig vom Signal ist. Bzw. man müsste das Stellsignal prüfen bevor man stellt. Als besser hat sich erwiesen die Differenz zu ermitteln und dann den CC nur mit einen Fixen Wert zu tippen. Also je nach dem ob sie positiv/negativ ist 10µS hoch oder runter. Dies erwies sich als Stabiler. Bleibt aber das Problem worauf Regeln bei 200ms. Man muss das Signal Fangen bevor aus an die äußeren Bereiche kommt. Sonst muss man es wieder da hin schieben. Das macht auch nichts da wenn alles richtig läuft es wieder genau dort auftaucht wo man es haben möchte ;) So kann man die Signal hinterher Tracken ohne ein Bit zu verlieren. Aber man muss eben mit 1sec Falten. Die Aufgabe bestand aber drin nur alle 200ms zu Falten und genau an der Stelle wo das Signal ist.
:
Bearbeitet durch User
Nein, du hast es nicht verstanden. 55ms Signal , 750ms Pause, 200ms Signal start. Nach dem Signalende ist immer 750ms pause, der Fehler ist nicht kumulativ. Die 5ms Fehler, auch 20ms sind kein Problem für den Empfang. Dies funktioniert auch mit internem RC OSC. Minutenanfang ist immer, das Startbit der Sekunde. Man speichert sich den Wert des ms Zählers am Minutenanfang, bevor man diesen auf 0 setzt. Wenn er mehr als 1100 hat, dann speichert man 100, ansonsten ms-900 in eine Byte Variable. Wenn dann nach 59 Sekunden alles decodiert ist, und man sich sicher ist, dass der Empfang fehlerfrei war, korrigiert man bei Bedarf den Fehler, und gibt ihn als Debug Wert auch aus. Könnte es sein, dass anstelle von 1000 ms für eine Sekunde dein uC bis 1024 zählt, sowie zusammen mit einem Resonator oder internem RC OSC, diese Ungenauigkeit daraus resultiert ?
Ok jetzt habe ich es verstanden. Man lässt ihn nicht frei laufen sondern synchronisiert ihn zum Minuten Anfang bzw. auf das Signal. Du prüft ob der Pin 1 ist wenn ja ließt du ihn so lange ein bis er 0 ist und wartet dann. Ich glaube aber das wir hier von zwei unterschiedlichen Verfahren reden zu den Bits zu gelangen. Der Zähler löst bei mir alle 10ms einen Interrupt aus der den Port einließt und in einen Doppel Buffer das Ergebnis speichert. Nach 100 Samples dreht sich der um und ich bewerte 100 Werte. Ich bilde wie in den oben genannten Thread die Summe und wo das Maxima lag für 1sec 100ms 200ms . Dadurch entsteht ein sogenanntes Fenster hier von 100 Werten a 10ms = 1sec. Der Unterschied ist eben das selbst eine Störung das Maxima nur gering beeinflusst. Anders als wenn man es zur Bedingung macht das der Port Wert gleich ist. Liegen die Maxima dicht bei einander etc. lassen sich die Bits daraus ableiten. Im Prinzip kann man jetzt das DCF Signal schon auswerten aber ich will jetzt da Falten wo das Signal ist. Also mach ich das Fenster nur 200ms groß und lese die Werte nur dort wo ich das Signal anhand des Index berechnet habe. Die Problematik ist jetzt das ganze synchron zu halten. Hmm in der Tat ist der Interne 8MHZ RC Takt nicht sehr genau aber es sollte möglich sein die Drift auszugleichen. Ich werde aber trotzdem mal Probieren den Timer an eine andere Quelle zu legen. Allerdings dürfte der Fehler nicht besser werden da die Teilungsfaktoren bei 32768HZ nicht besser sind.
War schon klar, du sprachst ja von Faltung. Ich benutze z.b. 13 bytes um die sekunde Abzubilden. 4x70ms und 9x80ms. Der Decoder ist ja derselbe, und dieser kann Auch parallel laufen. Weites solltest du keine 10ms sondern 50ms für die Faltung verwenden, und nur byte. Auch kann es vorteilhaft sein anstelle von 5min nur 2 oder eine Minute, auch nur 30 sek zu falten, Und erst wenn man den drift wegsyncronisiert hat auf mehr syncen.
wenn du deinen Sourcecode posten willst, kann ich mal drueberschauen.
Danke mit den Hinweisen kann ich was Anfangen. Mit der Problematik bin ich nicht alleine ;) Hmm eigentlich ist das Ergebnis schon ganz ok auch wenn man auf 1sec Faltet. Nach 2-3 Min habe ich eine gültige Uhrzeit. Auch die Drift lässt sich gut kompensieren in dem man das Fenster wieder in die Mitte des Signals schiebt. Mich würde Interessieren in wie weit sich weiterer Aufwand wirklich lohnt ? Der Code ist schon relativ Umfangreich. Vorher habe ich das Signal auch immer mit der üblichen Art aufgelesen. Ging eigentlich auch mehr oder weniger gut.
Was interessant ist, sofern ein gültiges Signal da ist, die 60bits zu shiften, damit man nach etwas mehr als einer Minute schon ein gültigen Datensatz hat. Nur das Minutensignal ist Zeitsyncron, die restlichen haben 30ppm Fehler von einer Sekunde auf die andere. Eventuell kann es vorteilhaft sein, 8 bits zu integrieren, für Stunden .... , die bits für SchaltSekunden sowie Schaltstunde ist auch vorteilhaft wenn dies beachtet wird. Und natürlich Daten nicht blind übernehmen sondern gegenchecken. Wenn der uC eine möglichkeit hat, die Temperatur zu messen, sei es auch nur mit WDT, so kann man über einen temperaturkompensierten OSC nachdenken,wo die Timerkorrekturen im EEprom gespeichert werden, wenn der Taktgeber genau sein soll, auch ohne DCF77.
Die Anfänge der Sekunden kommen in festen Takt. Da kann man so eine PLL laufen lassen, um immer den Anfang der Sekunde zu synchronisieren. Auch wenn das nicht so super genau ist, reicht es für die Wahl der Fenster zur Pulserkennung aus - etwas mehr als die 200 ms sollten es schon sein, so etwa 400 ms sollten aber in der Regel ausreichen um sicher den ganzen Puls drin zu haben.
Hier wird ja sehr abgehoben versucht, das DCF-Signal mit RC-Oszillator-Timing zu entschlüsseln - natürlich fehlerfrei in 61 Sekunden! Schrecklich, dass da Faltungen (oder habt ihr in Altsprech nur neudeutsche "wrap-arounds" gemeint?) auftreten können. Neusprech ist leider kein Rezept für gute Algorithmen! Menno, wenn man sich (parallel zur Bit-Aufzeichnung) den Abstand der aktiven Flanken des DCF-Signals (mit einem Fenster, das dem zu erwartenden RC-Oszillator-Fehler entspricht) herausfischt, kann man den RC-Oszillator schon mal mit großer Sicherheit auf ein brauchbares Vielfaches von 1 Hz ziehen. Dazu gibt es das OSCCAL-Register. - Wenn es dann passt, kann man auch das Fenster verkleinern, denn der zu erwartende Fehler ist nun (unerwarteter-weise?) auch geringer... :-) Das Fenster für LOW und HIGH ist dann schon mal NULL Problem. Vorteil: Man kann die (damit vielleicht sogar schneller) erkannte DCF-Zeit auch ohne Quarz bei temporären Empfangsproblemen etliche Minuten weiterführen. Nachteil: Das ist euch zu blöd. Gähn!
Das Problem ist das dass Signal nicht sehr eindeutig ist wie es von einer anderen Quelle z.Bsp Lichtschranke wäre. Weder die Flanken noch die Länge des Signals sind eindeutig und ganz schlimm sie differieren je nach Empfang. Das driften lässt sich zu mindestens bei größeren Fenstern deutlich verkleinern. Meine Routine gleicht das ja aus in dem es bei einer Abweichung den Timer um 10µ hoch bzw runter tippt. Läuft es aus dem Fenster schiebt ein delay das Fenster wieder zurück. Das geht sehr einfach in dem man das Abtasten um x Zyklen verzögert. So taucht das Signal an der richtigen Stelle wieder auf. Der Timerwert bleibt erhalten das spiel beginnt von vorne. Bis es gering genug ist um auf 200ms zu schalten. Bei einen 200ms ist die Sache schwieriger. Da ich kleinen Punkt gefunden habe der brauchbar wäre um das Driften zu beobachten. Außer dem Maxima, daran könnte man das erkennen und auch in welcher Richtung es läuft. Problemtisch ist nur ob der Stellwert auch den Effekt hat den man sich vorstellt. Ich vermute das die Reglung das ganze noch schlimmer aus dem Fenster schiebt. Durch Störungen etc. Ich werde die Lösung das Fenster zu schieben auch bei 200ms anwenden, orientiert an dem Maxima. Das Maxima kann man beobachten und dann relativ vom Index 10ms zurück schieben. Man muss sich das Vorstellen wie eine 1sec lange Leine. Wenn der Hund zu weit gelaufen ist zieht man ihm zur richtigen Position wieder zurück bzw. er bleibt kurz stehen ;)
:
Bearbeitet durch User
Vor den 200ms Impuls gibt es mehr Rauschen als im Durchschnitt. Die 100ms sind ein 1er Impuls. Es gibt mehr 0bits als 1bits. Man hat normales Rauschen, erhöhtes rauschen vor und nach dem Impuls, sowie die ersten 100ms (50/77mm) sind eine Eins, und danach gibt es Rauschen und eine 75% Schwelle von eins Bits. Wenn ein sauberes Signal da ist, 50-250ms, dann wird dies hergenommen, ansonsten wird anhand des integriertem Signals der Pegel ausgewerted. Die Schwellen werden so gewählt, dass ein Sync verlust automatisch auch Fehler hervorruft, also mehr 0 als 1 produziert, wenn man nach rechts drifted, oder der Rauschabstand sich unter dem Level bewegt, wenn man nach links abdrifted. Op man da jetzt shifted, oder prinzipiell von neu anfang, design Entscheidung. Man hat eine gültige Zeit, jede neue DCF77 wird mit der aktuellen Systemzeit verglichen, und erst wenn 8 gültige DCF77 Telegramme da sind, wird diese Zeit verwendet. Dass dem Benutzer vorher schon eine Zeit angezeigt werden kann, ist eine andere Sache. Es gibt eigentlich nur Schaltjahre, Schaltsekunden/Stunden welche einen jump ergeben, und letztere werden eine Stunde vorher angekündigt und passieren nur an definierten Zeiten, wie auch Schaltjahre mit dem Datum. Was passieren kann ist das MF60 Signal empfangen wird, weil das Modul zwei Quarze 77.5 und 60khz hat.
Danke, genau das ist der Ansatz den ich brauchte.
Tja also es hilft nichts. Mit der zur Verfügung stehenden Hardware läuft das Signal immer wieder aus dem Fenster. Es lässt sich nicht wirklich gut halten. Es funktioniert nur mit 1sec großen Fenster. Bei 200ms läuft es früher oder später raus.
:
Bearbeitet durch User
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.