mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Das Leidige Thema DCF77 mal eine Detailfrage zum Dekodieren


Autor: Stefan Winter (mobi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Düsentrieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guck hier
http://avr.börke.de/DCF-Uhr.htm

der Anfang: >1,5s kein puls -> start=sekunde 0

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Düsentrieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
machs halt anders-rum: miss nur die länge der lo/pausen
dann is klar, ob 1 / 0

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
...

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Winter (mobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard Günzel (ibilzh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Winter (mobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Winter (mobi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.