Hallo, Ich möchte mir gern eine Funkuhr mit einem ATmega8 bauen und hab ein Problem bezüglich der Umsetzung. Eine normale Uhr mit LCD-Ausgabe und Zeitstellmöglichkeit habe ich mir schon programmiert und sie funzt auch recht genau, jetzt stehe ich vor dem Problem, wie ich das DCF-Signal auswerten soll. Hier mal meine Gedanken: Eigentlich hatte ich gedacht, nach dem Takt des normalen Uhr-Timers das DCF-Signal abzufragen, also wenn der Timer sagt, dass eine Sekunde rum ist, dann den DCF-Signal-Eingang abfragen und über einen Zähler etc. "ausmessen", wob es 0,1 oder 0,2s dauert oder grad 59 ist. Aber wie synchronisiere ich dann den internen Timer mit dem DCF-Signal und wie bekomme ich es hin, dass das DCF-Signal dann geprüft wird, wenn es auf High geht? Ich will kein fertiges Programm, denn die Kunst besteht ja darin, es selbst zu machen, aber für einen kleinen Gedankenanstoß über das WIE? wäre ich dankbar.
Guck' mal hier, vielleicht hilft's. http://www.mikrocontroller.net/articles/DCF77-Funkwecker_mit_AVR
Mit welcher Sprache Programmieren wir denn ,ist von vorteil das zu wissen. Benutze mal die Suche und du bekommst einige Beiträge zur Auswertung des DCF77 - Signals.Habe damit meine Uhr auch hinbekommen,suchen,lesen, suchen,lesen.Sich gedanken machen und umsetzten,bin übrigens ein Bascom programmierer, ist zwar nicht das Non Plus Ultra.Aber für micht reichts allemal.
DCF-Signal fortlaufend abtasten (als Samplingintervall ist 10 ms gut geeignet) und mit dem Bitstrom eine DCF-Signal-Decodier-Zustandsmaschine füttern.
Ich habs einfach mit einem Input-Capture gelöst. Dann kriegste automatisch nen Interrupt, wenn ein Impuls durchgetastet wurde, ganz praktisch also. Und die Länge wird auch automatisch schon ins Register gespeichert -- brauchst nur auszulesen.
>Ich habs einfach mit einem Input-Capture gelöst
Habe ich auch, bin sehr zufrieden damit. Viele hier schwören auf die
10ms-Polling-Methode, habe mir da schon viel anhören müssen, darum sage
ich's nicht gerne laut, sonst geht der Hickhack von vorne los. :)
Du brauchst 2 Taktzäher, einen um die Dauer eines Impulses zu messen und einen um die Periodendauer zu messen. Die Impulsdauer sagt Dir, ob 0/1 empfangen und die Periodendauer sagt Dir, ob ein Minutenanfang erkannt wurde, die Periode ist dann 2 Sekunden. So ungefähr so: DCF: ___|-----------------|__________________________|-----...--|__ Abt: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! .....! !.... Evt: X0 X1 X2 DCF = Empfangssignal Abt = Abtastung mit 10ms Evt = Events Events: X0 = steigende Flanke erkannt, beide Taktzähler starten X1 = fallende Flanke erkannt, Taktzähler für Impuls stoppen (dann Impulsdauer auswerten) X2 = steigende Flanke erkannt, Taktzähler für Periodendauer stoppen, Wert merken und wieder starten (dann Periodendauer auswerten mit dem gespeicherten Zählerwert) Grober Ablauf 1) Warte auf Minuten wechsel (Periodendauer = 2 Sek.) Sekundenzähler auf 0 setzen. Wenn Periodendauer nicht 2 Sekunden +- Toleranz von 20-30ms dann gehe zu 1 (Empfangsfehler). 2) Warte auf fallende Flanke und werte die Impulsdauer aus (0/1 empfangen). Wenn Impulsdauer nicht 100ms oder 200ms +- Toleranz von 20ms dann gehe zu 1 (Empfangsfehler). 59 mal die Bits auswerten(für 59 Sekunden) und wertest dann auch die 59 Bits aus und hast dann Deine Uhrzeit. 3) Gehe zu 1 Mit dem Input-Capture geht es sicher auch, aber braucht eine Resource (Timer). Wenn Du aber sowieso schon einen 10ms Takt am laufen hast (den kann man ja auch zum Tastenabfragen nutzen), dann geht es so ganz gut.
Thilo M. wrote: >>Ich habs einfach mit einem Input-Capture gelöst > > Habe ich auch, bin sehr zufrieden damit. Viele hier schwören auf die > 10ms-Polling-Methode Die 10ms Polling Methode ist einfacher. Alle Zeitabstände passen in ein Byte, man muß also nur Bytevergleiche machen. Und man kann leichter ein Ausbleiben von Impulsen erkennen (Zähler erreicht 255). Beim ICP merkt man aber den Überlauf nicht. Auch geht der Timer nicht für andere Sachen verloren, z.B. für PWM-Ausgänge. Auch braucht man meistens eh nen 10ms Interrupt für andere Sachen. Z.B. fürs Tasten entprellen und für die interne Uhr, wenn das Signal gestört ist. Die ICP-Methode geht natürlich, aber ich wüßte nichts, was dafür spricht. Sie hat keinerlei Vorteile. Peter
>Sie hat keinerlei Vorteile.
Siehste? :)
Aber auch keine Nachteile!
Kann Peter nur zustimmen. Danke Peter, habe Deinen Code aus Deiner DCF-Uhr geklaut und bei mir etwas verändert verwendet. War auch von der Idee der Statecodierung in der Tabelle ganz begeistet :-) Demnächst werde ich evtl. noch eine "Fenster" einbauen, dass nur die DCF-Impulse auswertet, wenn Sie auch sein sollen, also alle 1000ms. Dadurch filtere ich eventuelle Störspikes auch aus, die sonst immer gleich zu einem Fehler führen. Mal sehen, was es bringt.
Thilo M. wrote: >>Sie hat keinerlei Vorteile. > > Siehste? :) > > Aber auch keine Nachteile! Die Nachteile hatte Peter doch gut beschrieben. Hast sie nicht verstanden!?
>Hast sie nicht verstanden!?
Bitte nicht nochmal!
1. der Timer geht keinesfalls für andere Sachen verloren,
2. kann ein Überlauf excellent auch mit ICP detektiert werden.
Möchte diese Diskussion nicht nochmal aufwärmen, bei mir läuft die
ICP-Methode seit Dezember 2007 im Heizungsregler fehlerfrei , dabei
wird der Timer1 als ICP (DFF77), interne Uhr und PWM genutzt.
Also lasst bitte anderen Methoden auch ihre Berechtigung, es geht auch
so.
Thilo M. wrote: >>Hast sie nicht verstanden!? > > Bitte nicht nochmal! > 1. der Timer geht keinesfalls für andere Sachen verloren, > 2. kann ein Überlauf excellent auch mit ICP detektiert werden. > > Möchte diese Diskussion nicht nochmal aufwärmen, bei mir läuft die > ICP-Methode seit Dezember 2007 im Heizungsregler fehlerfrei , dabei > wird der Timer1 als ICP (DFF77), interne Uhr und PWM genutzt. > Also lasst bitte anderen Methoden auch ihre Berechtigung, es geht auch > so. Sorry, ich habe oben geschrieben, dass die ICP-Methode auch (und ganz sicher) funktioniert. Da steht nichts anderes und keiner will sie Dir ausreden. Es gibt nur bei beiden Methoden Vor- und Nachteile und die wurden erwähnt. Mehr nicht! Wenn Du der Meinung bist, dass die ICP Methode die beste ist, dann ist sie das erstmal für dich, ich darf aber doch anderer Meinung sein :-) Im übrigen finde ich es auch immer wieder interessant, wie andere es lösen, weil da eben auch oft ganz andere Methoden bei rauskommen, die ich mir gerne ansehe.
>Im übrigen finde ich es auch immer wieder interessant, wie andere es >lösen, weil da eben auch oft ganz andere Methoden bei rauskommen, die >ich mir gerne ansehe. Ich auch. Poste die/deine ICP-Methode doch mal in der Codesammlung.
>Du brauchst 2 Taktzäher, einen um die Dauer eines Impulses zu messen und >einen um die Periodendauer zu messen. Man braucht nur einen Zähler. Immer, wenn vom Signal ein neues Sample genommen wird, d. h. alle 10 ms, zählt er eins rauf. Außer im Fall einer steigenden Signalflanke - dann wird er auf Null zurückgesetzt. Ferner muss man ihm ein Limit. z. B. 250 setzen, damit er nicht von 255 auf 0 überläuft. Also vor dem Raufzählen prüfen, ob er noch unterhalb des Limits ist. Im Fall einer fallenden Signalflanke muss man sich nur den Stand dieses Zählers angucken; er entspricht der Pulsdauer, die beim DCF-Signal stets entweder 100 ms oder 200 ms beträgt. Einen weiteren Zähler braucht man für die Pulse selbst; dieser Zähler wird bei jeder steigenden Signalflanke eins raufgezählt. Und resettet vor Beginn der neuen DFC-Minute, erkennbar an der Sync-Pause. Das ist dann praktisch schon die halbe Decodier-Zustandsmaschine. Was noch fehlt, ist die Auswertung der Datenbits.
@ 900ss D.: Haste schon Recht, ich finde ja auch dass beide Methoden ihre Berechtigung haben, je nach Anwendung ist mal die Eine, mal die Andere besser geeignet. Da sind eben die Vorlieben des Programmierers und die Anforderungen führend. Ich finde die Pollig-Methode übrigens auch prima. War nicht negativ gemeint! ;)
AVRFan wrote:
> Man braucht nur einen Zähler. Immer, wenn vom Signal ein neues Sample
OK, geht auch, hast Recht. Ich finde es mit zweien übersichtlicher :-)
Thilo M. wrote: > Möchte diese Diskussion nicht nochmal aufwärmen, bei mir läuft die > ICP-Methode seit Dezember 2007 im Heizungsregler fehlerfrei , dabei > wird der Timer1 als ICP (DFF77), interne Uhr und PWM genutzt. Da würde mich mal sehr der Code interessieren, wie Du das gemacht hast. Um die Fehlsekunde zu erkennen, muß ja der Zählumfang mindestens 2s betragen. Damit noch ne PWM zu machen, scheint mir unmöglich, das wird bestenfalls eine langsame Blink-LED mit variabler Leuchtdauer. Interne Uhr wird auch ziemlich tricky, Clear on Compare scheidet ja aus, sonst stimmt der ICP-Wert nicht mehr. Und der nötige Vorteiler 1024 kann auch Rundungsfehler verursachen, die dann wieder rausgerechnet werden müssen. Peter
Hi Peter, den Code stell' ich mal in die Codesammlung, heute aber nicht mehr. Der Timer1 bedient die Uhr (CTC-Mode, OCR) und den ICP, passt mit dem Vorteiler prima zusammen. Der PWM steuert die Display-Hintergrundbeleuchtung (nicht Phasenkorrekt).
Hallo, erstmal Danke für die vielen Antworten! War sehr hilfreich, denn Rest werde ich hoffentlich schaffen :-) Gesucht und gelesen hab ich schon, aber über die wirklichen Grundlagen hab ich nix gefunden - zumindest nicht in C - und das programmier ich - beziehungsweise versuch es :-) Ich nehm dazu AVR-Studio. Also wenn ich das richtig verstanden habe wird durch das 10ms-Polling der Gangunterschied der "normalen" Uhr auf diese 10ms begrenzt. Wenn ich nun ICP verwende, was passiert, wenn z.B. mal ein Fehlimpuls reinkommt, dann hab ich, wenn's schlecht läuft doch ein Byte zu viel, oder? Bei der 10ms Methode werden die ja sozusagen "rausgemittelt". Naja, ich werde das ganze mal ausprobieren, wenn mal nebenbei noch Zeit ist. Micha
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.