Habe mir viele DCF Decodierungen im Forum angesehen, aber eines Frage ich mich doch sehr, warum werten alle die Länge der Impulse aus? Ist es nicht umständlich immer die Event Flanke zu ändern um die Steigende oder Fallende Flanke zu ermitteln und aus der Differenz den Wert zu ermitteln. Habe mir das anders überlegt. Da die Steigende Flanke immer im null Punkt der aktuellen Sekunde ist und nur die fallende Flanke ihre Position im Bezug zu steigenen Flanke ändert, liegt es doch auf der Hand dies als Auswertekriterium zu nehmen. In der Graphik sollte das Prinzip erkennbar sein. 1. Zwei gleiche Pegellängen folgen aufeinander =1000ms 2. erst 100ms gefolgt von 200ms = 1100ms 3. erst 200ms gefolgt von 100ms = 900ms Bei jedem Interrupt wird Sek um eins erhöht, dadurch kann man die Werte der Decodierung zuordnen. man braucht nur noch auf 900ms und 1100ms (+/- 10)zu prüfen. Das sollte doch einfache sein, oder.... Ich werde das mal versuchen. Oder hat dieses Rad schon mal einer erfunden und kann Tipps geben? Bye Mobi
Angehängte Dateien:
-
DCF_Decodierung.jpg
32 KB
Stefan Winter wrote: > Habe mir viele DCF Decodierungen im Forum angesehen, aber eines Frage > ich mich doch sehr, warum werten alle die Länge der Impulse aus? Ist es > nicht umständlich immer die Event Flanke zu ändern um die Steigende oder > Fallende Flanke zu ermitteln und aus der Differenz den Wert zu > ermitteln. Was ist da drann umständlich? > > Bei jedem Interrupt wird Sek um eins erhöht, dadurch kann man die Werte > der Decodierung zuordnen. > man braucht nur noch auf 900ms und 1100ms (+/- 10)zu prüfen. > Das sollte doch einfache sein, oder.... Ich werde das mal versuchen. letztendlich musst du auch hier eine Zeit messen. Angenommen alle deine Zeitdifferenzen betragen 1000 ms. Waren das jetzt nur 0-er oder waren das nur 1-er? Ob du das nun so machst, oder ob du bei der fallenden Flanke einen Timer startest, der dir nach 150ms einen Interrupt gibt und du dann nachsiehst welchen Pegel die Leitung hat -> letztendlich läuft alles in irgendeiner Form darauf hinaus, dass die zeitliche Länge des Pulses gemessen wird. Ich würde mal sagen: Wenn ich die zeitliche Länge eines Pulses benötige (wenn auch nur sehr grob), dann ist wohl das einfachste auch genau diese Messgröße zu messen anstatt eine andere Messgröße zu messen und daraus den mich interessierenden Messwert zurückzu- rechnen. Aber lass dich nicht abhalten: Viele Wege führen nach Rom. > Ich werde das mal versuchen. Das ist die richtige Einstellung. Viel Spass dabei!
der Gedanke ist schon ganz gut. Das Problem wird der Anfang sein. Wenn ich als erstes 1000ms messe, habe ich eine 1 oder 0? mfg
>guck hier >http://avr.börke.de/DCF-Uhr.htm Der Link funktioniert nicht mehr. Neu: http://avr.xn--brke-5qa.de/DCF-Uhr.htm
es geht hier nicht um die allg. bisherige Programmierung, sondern um die neue Idee. Und da ist es schwierig, das 1. Bit zu finden. Die 1. sekunde ist kein Problem.
machs halt anders-rum: miss nur die länge der lo/pausen dann is klar, ob 1 / 0
Um jetzt totale Verwirrung zu stiften: Ich werte die steigende Flanke aus, und guck regelmäßig mal vorbei, ob der pin low geworden ist, wenn ja, dekodiere ich die Länge des Impulses ...
das ist auch wieder das übliche. Hier ging es darum, nur die Abstände zwischen gleichen Flanken zu messen. Bevor die Wetterinformationen eingeführt wurden, wäre das gegangen. Dann wären die ersten Sekunden nach dem Minutenimpuls immer 1 gewesen und von da aus hätte man weiter bestimmen können. Man kann ja mal sehen, ob sich das 1. bit irgendwann mal ändert. wenn nicht, könnte die Decodierung so funktionieren. mfg
Ich habe das mal so gemacht, wie ich dachte und habe folgendes erreicht. Die Erkennung von Sync ist einfach, weil ich ca. 1900ms nicht empfange. Warum gibt es denn probleme ... Ich habe die Wetterinfos im Stream ignoriert und nur die Daten ab der 20Sek genutzt dies ist immer 1(Startbit) nun habe ich darauf die folgenden Bits decodiert uns funktioniert zu 99%. Es scheint an meinem Stanort oder an der noch fehlenden Optimierung des Codes, bekomme ich auch noch hin. Werde die Erkenntnise hier einbringen...SCode wird dann auch folgen, wenn erwünscht. Bye Stefan
danke, code wird gewünscht, nach Möglichkeit in Assembler, sonst entsprechend gut dokumentiert, damit man das auch als Assemblerprogrammierer nachvollziehen kann und entsprechend umsetzen kann. mfg
Hallo Stefan, > >Da die Steigende Flanke immer im null Punkt der aktuellen Sekunde ist >und nur die fallende Flanke ihre Position im Bezug zu steigenen Flanke >ändert, liegt es doch auf der Hand dies als Auswertekriterium zu nehmen. Das verstehe ich nicht ganz. Die Austastung des Trägersignales in Braunschweig beginnt immer exakt am Anfang einer Sekunde. Laut deiner Zeichnung ist die steigende Flanke immer mitten in der Sekunde. (rote Markierungen). Falls der Interrupt dort ausgelöst wird, und bis zur nächsten steigenden Flanke die Zeit gemessen wird, dann hast Du immer verschieden lange "Sekunden" und auch nicht synchron zur Echtzeit. Ich gehe davon aus, dass das eine Uhr wird, die Sekundenanzeige hat; sonst wäre es wurscht, solange lediglich jede volle Minute ausgewertet wird. Laut deiner Zeichnung wird auch der erste Puls (erster von 59) nicht berücksichtigt. Gerhard
Hallo alle miteinander.... Habe es nun zur 99,9999% Perfektion gebracht. Zur übersicht... Habe einen Timer (8bit) über Interrupt zur Offlineclock verwendet. Diese wird im Normalfall aller 180Sek von der DCF-Clock Syncronisiert inkl. Sekunden. Sollte DCF ausfallen (Störrung) so geht die Offlineclock einfach weiter. Um die Gültigkeit des DCF Frames zu prüfen werden die Paritätspits der Minuten, Stunden und des Datums einzeln ausgewertet und ein Fehler entsprechend Dokumentiert (Counter). Wenn ein Frame OK war werden die Decodierten Daten gepuffert. Wenn drei aufeinander folgende Frames OK waren so wird die Offlineclock Sync... Dieses Sync wird über Counter Dokumentiert. Mit dieser Doku konnte ich feststellen, das ich innerhalb 12h ca 210 Syncs hatte und gerade mal 10 Minuten- , 5 Stunden- , und 1-2 Datumsfehler im Stream hatte. Ich finde dies reicht aus um es als Erfolg zu bezeichnen. Das Prob für mich ist nun nur das eine, diese Sache läuft in einem Kompletten Projekt und ich werde mir Mühe geben, dies aus dem ganzen zu extrahieren. Code sollte heute noch folgen...... Bye Stefan PS: > Karl heinz Buchegger > > Das ist die richtige Einstellung. Viel Spass dabei! Danke für die Motivation hat geholfen nicht den Mut zu verlieren, es mal anders zu machen. Der Erfolg gibt dem noch recht.
Stefan Winter wrote: > Ist es > nicht umständlich immer die Event Flanke zu ändern um die Steigende oder > Fallende Flanke zu ermitteln und aus der Differenz den Wert zu > ermitteln. Muß man nicht, man kann auch ganz einfach nur die Änderung detektieren. Ich taste das Signal mit nem Timerinterrupt ab. Wenn man z.B. alle 10ms abtastet, kann man prima mit einer Bitvariablen alle Timings abzählen. Ich speichere dann in 2 Variablen die Pulsdauer (10 oder 20) und den Pulsabstand (100 oder 200). Mit entsprechenden Vergleichsfenstern (8..12, 18..22, 90..110, 190..210) werden dann alle relevanten Zustände dekodiert. In der Codesammlung taste ich alle 15,6ms ab, daher die etwas anderen Fenster. Die Abtastung im Timerinterrupt hat den Vorteil, daß kurze Störimpulse weniger Fehlerkennungen verursachen. Peter
So ich habe das mal versucht zusammenzu suchen... Mir ist klar das dies kein Funktionsfähiger Code im Ganzen ist, aber die Funktion an sich sollte erkennbar sein. Bye Stefan
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.