Hallo Forum, ich habe hier mal eine DCF77 Uhr nun schon (fast) zur Perfektion getrieben. Sie kommt mit einem AtTiny2313 und ein paar Widerständen und Transistoren aus. Hinzu kommen natürlich noch die LED-Anzeigeelemente. Der Empfänger ist ein SAF (Signal Angepasstes Filter). Dieser integriert die letzten 200 Millisekunden des Signaleingangs. Ist das Integral unter das viertel des Maximum gefallen, so wird sowohl das Maximum als auch die dauer, für die das Maximum erreicht war, zur Entscheidung auf 0 oder 1 genutzt. Bei kurzem Imupls wird das Integral für lange zeit einen geringen Wert (Maximum) einnehmen, da der Impuls das Filter nicht gänzlich füllt: _,/`^^^^^`\,____ Bei einem langen Impuls wird der Filter genau einmal ganz ausgefüllt, so dass das Maximum groß ist aber nur kurz eingenommen wird: /`^`\ / \ _,/ \,_____ Auch bei Störungen wird sich der Ausgang nicht merklich ändern, da die integrierende Funktion des Filters Tiefpasscharakter aufweist und kurze (hochfrequente) Störungen in Form von Prellen oder kurzen Störimpulsen herausfiltert. Des weiteren braucht dieser Filter keinen Abtastzeitpunkt, der wird automatisch aus dem Signal zurückgewonnen. Lediglich um das Synchronisationsbit (fehlender Impuls) zu erkennen wird eine Zeitbasis gebraucht. Wer hat Anregungen/Lob/Kritik?! Bitte schreiben! Schöne Grüße, Clemens
Leider gibts hier immer noch keinen Code für eine Bascom Uhr. :-( Ich habe leider nicht das Wissen so ein Teil zu proggen. Meine Projekte sind eher kleiner Natur. Aber eine Bascom-DCF Auswertung wäre genial!
Grummel, schon wieder so einer mit Unix-codiertem Zeilenende.
Grummel, schon wieder so einer mit Notepad... Tipp: auf Notepad2 umstellen: http://www.flos-freeware.ch/notepad2.html
Hä? Was willst du mit dem Zeilenende? Meinst du meine Postings?
Hallo Clemens,
> Sie kommt mit einem AtTiny2313 und ein paar Widerständen und
Transistoren aus.
Heißt das, ohne das übliche Empfangsmodul? Was ist denn dann nötig, um
das Projekt zum Laufen zu bekommen?
Wäre schön, wenn Du auch ein kleines Foto vom Aufbau hier anhängst.
>>Hä? Was willst du mit dem Zeilenende? Meinst du meine Postings?
Dein Editor macht nicht das "übliche" (unter Windows) CrLf
Zeilenende.. Sondern nur Cr oder nur Lf (weiß ich grad nicht wie das
bei Unix war). Das heißt das ganze kann man nicht mit dem Notepad
lesen.
"Wer hat Anregungen/Lob/Kritik?! Bitte schreiben!" Für das fehlende CRLF habe ich Borland C++, öffnen, speichern fertig. Aber mit BRD, SCH kann keiner was anfangen, da wäre JPG, PNG oder PDF angebracht. Peter
@Simon Küppers Unter Unix (bzw. sogut wie jedem OS ausser Windows) nur LF (0x0A).
"Aber mit BRD, SCH kann keiner was anfangen, da wäre JPG, PNG oder PDF angebracht." Du schreibst einen Müll, man o mann! Wer Eagle hat, kann damit was anfangen!
Hallo @Hobbylöt "Du schreibst einen Müll, man o mann!" Vielleicht schreibst Du ja Müll, schon mal daran gedacht dass es Leute gibt die Eagel nicht verwenden und es auch nicht installieren wollen? Für diese Fälle ist JPG o.ä. die bessere Lösung. In diesem Sinne. Oli
Wenn jemand Eagle nicht mag, ist es seine Sache, aber der sollte nicht behaupten, mit BRD und SCH kann man nichts anfangen! Gruss und schönen Abend
Hallo, ich finde es sehr schön, dass hier etwas Leben rein kommt :-) Die umkodierung von Linux/Windows-Dateien sollte i.A. kein Problem darstellen, dafür gibt es Editoren, die beides können - auch für Windows ... wurde ja auch schon gesagt. Mit BRD und SCH kann vielleicht nicht jeder was anfangen, ok. Hier kommt nun alles nochmal als PNG - nur verändern kann manns dann nicht so leicht. @duundich: Natürlich wird noch das normale Empfangsmodul benötigt. Dieses ist aber leicht aus einem beliebigen 1-Zellen-Wecker zu entnehmen und hier einzusetzten. z.B. bietet Mediamarkt soche Wecker an (mein Modul ist aus einem Mediamarkt-7-eu-Wecker). Schöne Grüße, Clemens
Kannst du den Wecker mal nenen? Wäre bestimmt interesant, da ein solches Modul neu bei Reichelt 14 Euro kostet!
Bei ELV: DCF-Empfangsmodul mit 77,5-kHz-Empfangsantenne, abgeglichen, inkl. Beiblatt Artikel-Nr.: 68-352-62 9,95 Teuro
>Für diese Fälle ist JPG o.ä. die bessere Lösung.
Das ist totaler Müll !
Für Schaltpläne nie jpg nehmen, sondern immer png oder gif !
@Hobbylöt, "Wenn jemand Eagle nicht mag, ist es seine Sache," Du schreibst aber auch einen großen Müll, man o mann! Es hat überhaupt nichts mit mögen zu tun, sondern Eagle ist weder der Nabel der Welt noch irgendein Standard. Eagle ist nur ein Programm unter vielen und daher können viele die Dateien nicht lesen. Ich könnte ja auch SCH von Protel oder Orcad erzeugt reinstellen, aber ich machs nicht, weil das eben viele nicht lesen können. Also komm mal von Deinem hohen Roß runter, das hier ist kein Eagle-Forum. Peter
@Benedikt, "Das ist totaler Müll !" Jau, immer bloß auf die Kacke hauen. Ich meinte doch irgendein standardisiertes Ausgabeformat. Ich druck z.B. in eine Datei (Postscript) und jags dann durch die PS2PDF.BAT (Ghostscript). Peter
@Läubi: Das Funkmodul stammt aus einem Wecker von EUROCHRON. Dies ist ein LCD-Wecker mit Tasten rechst und links (jede Seite ist halbrund zudem). Gabs glaube ich in 2 Farben, ich hatte ihn in Grau gekauft. Das ist aber schon eine ganz schöne Weile her, ich weiss nicht mehr, wann das war. Ich denke aber, wenn man Glück hat, kriegt man auch ein anderes Alternativprodukt. Habe gehöhrt, dass die Tschibo-teile auch geeignet sein sollten (~5). Schöne Grüße, Clemens
Hat keiner mal irgendwo einen Code in Bascom zur DCF Auswertung gesehen? Gruss, uwe!
clemens - ok, ich dachte, du hättest die ultimative empfangsmodulfreie softwarelösung klammheimlich hier reingestellt, während die anderen sich noch über den empfängerbau unterhalten :-) die anderen: ihr benehmt euch hier dermaßen daneben, daß es mich so nervt, daß ich das hier schreibe. hättet ihr euch doch alles sparen können, oder?
Schau mal unter diesem Link http://www.mcselec.com/index.php?option=com_content&task=view&id=86&Itemid=57 Dieser bezieht sich auf ARV, für den 8051 gibt es auch ein Listing. Das aber nur auf Englisch Gruss Mirko
Hallo DCF-Freaks, habe letztens bei Conrad DCF77_Funkwecker für 3 Euro gesehen.
@Clemens Hi, ich bin gerade dabei auf Basis Deines Codes eine DCF77 Uhr aufzubauen. Der Code wird in cvavr erstellt, der Dekoder läuft bereits in der VMLab Simu (langsam, aber mit den NRZ files kann man das DCF-Signal genau nachbilden). Hast Du irgendwo noch was zur Theorie Deines Filters? So ganz kann ich die Funktionsweise noch nicht nachvollziehen, er funktioniert aber recht gut. LG Fried
Hallo Fried, der Filter arbeitet nach dem Prinzip eines jeden SAF (Signal Angepassten Filter). Es wird die zeitinvertierte Impulsantwort des Senders als Empfängerimpulsantwort verwendet. Der Sender sendet Rechteckimpulse, diese sind symetrisch, also ist die Impulsantwort des Empfängers auch wieder ein Rechteckimpuls (z.B. ein Halte-Glied). Das Filtern des Eingangssignal geschieht hier im Zeitbereich, es wird gefaltet. Die Faltoperation ist ein Integral aus dem Produkt der Impulsantwort und der um einen beliebigen Wert T verschobenen Version des Empfangssignals. Dies genau ist im Code implementiert. Das Ergebnis welches aus der Faltung rauskommt, ist folglich ein Dreick oder ein Trapez (zwei Rechtecke gegeneinander verschoben und miteinander multipliziert und integriert). Je nach angelegtem Sende-signal ist das Signal nun ein Dreieck oder ein Trapez. Danach wird unterschieden, ob ein 0 oder eine 1 gesendet wird. Leider habe ich keine Quelle parat, die dieses Prinzip gut erklärt, aber u.U. hilft google oder wikipedia weiter, Stichworte: SAF, Signalangepasster Filter, Faltung Schöne Grüße, Clemens
Hi, du brauchst immer noch ein Empfangsmodul. ist es nicht möglich, das Signal von DCF77 direkt zu samplen (ADC) und dann zu filtern und weiter zu verarbeiten? Grüsse Robert
Hi, rfr, Du: "st es nicht möglich, das Signal von DCF77 direkt zu samplen (ADC) und dann zu filtern und weiter zu verarbeiten?" Gibt solche Vorschläge, aber nicht für Zeitzeichenempfang, sondern Spektrumsanalyse für EMV-Meßtechnik. Problem ist nur: Um ein Signal von 3 Hz Bandbreite zu nutzen, mußt du (kleingeschrieben, weil allgemein gemeint) >150 kHz mit hoher Großsignalfestigkeit empfangen und verarbeiten - und nachher 150kHz - 3 Hz mühsam ausfilgern. Klingt so ein wenig wie "mit dem Lkw losfahren, Packung Zigaretten aus dem Automaten ziehen". Ciao Wolfgang Horn
@Wolfgang Horn > Du: "st es nicht möglich, das Signal von DCF77 direkt zu samplen (ADC) > und dann zu filtern und weiter zu verarbeiten?" > Problem ist nur: Um ein Signal von 3 Hz Bandbreite zu nutzen, mußt du > (kleingeschrieben, weil allgemein gemeint) >150 kHz mit hoher > Großsignalfestigkeit empfangen und verarbeiten - und nachher 150kHz - 3 > Hz mühsam ausfilgern. Naja, man könnte auch Undersampling machen, dann reichen theoretisch ein paar Hertz. Aber ohne (sehr) gutes analoges Frontend (=Empfangsmodul) wird das nix. Man muss schliesslich auch noch AGC und ähnliches baeachten. MFG Falk
@Clemens Hallo, vielen Dank für Deinen Code und die Erläuterungen. Der Decoder läuft jetzt auch realtime bei mir, nur mit dem Zusammenspiel tsCurrent, tsLastValid und tsSecure scheint was nicht zu stimmen. tsCurrent wird korrekt empfangen, nach dem ersten Mal auch richtig durch dcf77_putSync nach tsLastValid kopiert. Nach dem nächsten Telegramm erfolgt der Vergleich Current-Valid, ist immer falsch weil Valid eine Minute weniger hat als Current, muss auch so sein IMO? Danach wird bei korrektem Empfang tsLastValid nie wieder geändert. Habe ich was übersehen? LG Fried
Hallo Fried, schön, dass der Code bei dir läuft. Zu deinem Problem: Nach der 59. Sekunde wird dcf77_putSync vom bit_Decoder aufgerufen. Dieses kopiert den Current timestamp in den LastValid, falls LastValid noch nicht empfangen wurde. Folglich ist nach dem ersten, fehlerfreien Empfangenen Timestamp einer in LastValid drin. Hier werden die Sekunden auf 0 gesetzt, denn es wird immer die Zeit gesendet, die als nächstes kommt. In der 4. Sekunde nun - die ja danach kommt - vergleicht er beide Timestamps, falls beide vorhanden sind (putBit -> case 4:) sind sie gleich, inkrementiert er den ValidCounter, sind sie unterschiedlich inkrementiert er den InvalidCounter. In der ersten 4.Sekunde sind sie logischerweise gleich, da sie vor 4 sekunden gerade kopiert wurden. Anschließend empfängt er wieder nach Current (erster neuer Wert kommt erst in Sekunde 20). Ist dies wieder abgeschlossen, wird in putSync der Timestamp nicht kopiert - er ist ja schon da. Inzwischen wurde die "Uhr" des Dekoders >60 mal mit 1 Hz aufgerufen (dcf77_timer). Also ist der LastValid-Stand eine minute weiter und beim nächsten Vergleich von Current (der neue Stand, der empfangen wurde und deshalb wie du schon sagtest eine Minute weiter ist) und LastValid (der ja dur dcf77_timer erhöht wurde) sollte bei fehlerfreiem Empfang nun auch wieder Gleichheit liefern. Ist diese Prozedur des Empfangen und vergleichens häufig genug abgelaufen, so (mindestens 3 Mal), wird davon ausgegangen, dass die richtige Zeit empfangen wurde. Folglich wird der Timestamp nach Secure kopiert - der wiederum auch von dcf77_timer aktuell gehalten wird. Die Häufigkeit des Vergleichs ist für die Sicherheit maßgeblich... Bei mir läuft der Code seit langem sehr stabil und zeigt nie eine falsche Zeit an - auch gibt es keine Probleme die Zeit zu empfangen. Last valid wird wieder zurückgesetzt (das Statusbit in u8Status gelöscht), wenn der Vergleich häufiger fehlgeschlagen ist als er erfolgreich war. Dann ist es wahrscheinlich dass LastValid falsch ist und erneut empfangen werden muss. Grüße, Clemens
Hallo Clemens, so ich glaube jetzt den Code verstanden zu haben, läuft bei mir in der Simu soweit aber real time noch nicht ganz, die Software RTC (über den Timer1s) hängt der DCF nach (mehrere Sec), daher erfolgt kein korrektes Update von LastValid. Mal sehen woran das liegt, die DCF Telegramme kommen aber auch realtime richtig an. Die Simulation zeigt, dass das Update der lokalen RTC etwa 300msec nach der Eingangsflanke des DCF-Bits erfolgt, ich will mal schauen ob man das noch optimieren kann. Ich denke dass man den Timer1 Int noch mit der Bitflanke des DCF Signals synchronisieren muss. LG Fried
Clemens Helfmeier wrote: > Wer hat Anregungen/Lob/Kritik?! Bitte schreiben! > > Schöne Grüße, Clemens Sehr schön. Was jetzt noch fehlt ist eine Uhr, die parallel mitläuft und ihre Geschwindigkeit an die des Funksignals anpasst. Damit könnte man auch andere Zeitbasen ableiten, die auch dann stabil wären, wenn der Empfang ausfällt.
Hallo Christian, das ist eine gute Idee. Ich habe den Eindruck, dass das Quarz zwar stabil ist, aber durch die deutlichen Temperaturunterschiede bei heller und dunkler Anzeige, läuft es nicht immer exakt auf der Nennfrequenz (Der Chip verstimmt es sozusagen). Folglich müsste man hier auch noch die Helligkeit der Anzeige (=Stromverbrauch, Wärmeentwicklung) mit in die Berechnung der "wahren" Zeit einbeziehen. Vielleicht ein bisschen viel aufwand, wenn man eigentlich spätestens nach 48h wieder dcf77-empfang hat ;-) Was für eine Zeitbasis hast du dir vorgestellt? Grüße, clemens
Servus Clemens, naja, das mit dem Display kann man ja einrechnen. Das ist ja nur lineare Algebra. Im Zweifellsfall heizt man einfach den Quarzoszillator. Nunja, es ist doch relativ oft so, dass man Geräte hat, die genau auf einer bestimmten Frequenz arbeiten sollen. Beispielsweise ein Radiogerät, ein Frequenzzähler oder ein Videorekorder. Diese Geräte haben dafür in der Regel einen 1 oder 10 MHz Eingang. Wenn man nun den ATMega dazu bringen kann, ein sehr genaue Zeit zu haben, so kann man einen einfachen VCO auf die Frequenz nachregeln, die man braucht. Also in gewisser Weise ein billiges Frequenznormal.
Guten Abend, ok, zwar bin ich nicht im Besitz eines solchen gerätes, aber das ist mal ein interessantes Projekt. Ich denke aber, man darf es dann auf keinen Fall in Zusammenhang mit einer Uhr mit schöner Leuchtanzeige machen, da das den Fehler wirklich krass beeinflusst wie ich gemerkt habe. Die Sache mit der Temperatur hängt glaube ich auch nicht primär von der Temperatur des Quarzes ab, sondern viel mehr von der Temperatur des AVRs. Schließlich ändert sich ja auch die Eingangskapazität der Oszillator-Pins mit der Temperatur und wird den Quarz somit verstimmen. Mich würde wirklich mal interessieren, wie man eine derartige Regelung in einen AVR implementieren will. Angenommen du willst "nur" 100kHz genau erzeugen. Sagen wir, dein Oszillator ist auf 1% genau - von Natur aus - und du willst nun gerne "nur" 0.1% erreichen mithilfe des DCF77-Signals. Wenn du nicht gerade einen verstimmbaren Oszillator nimmst, sondern das Signal irgendwie aus dem AVR rausquetcshen willst, brauchst du schon 100kHz/0.1% = 100Mhz Taktrate für einen Zähler, damit du mit einem LSB differenz im Überlauf (1000->1001 z.B.) einen Unterschied von 0.1% erzeugen kannst. 100Mhz / 1000 = 100kHz. Nur so ein Rechenbeispiel... Wie man das ganze mit einem VCO erzeugen kann, weiss ich nicht. Dabei wär's natürlich deutlich einfacher. VCO->messen (über entsprechend langer Zeit auch entsprechend genau, da ja digital möglich) und ggf. VCO-Voltage ändern.
Natürlich würde man da dann einen externen Quarzoszillator verwenden. Den kann man gut auf Temperatur halten. Zum Oszillator ist es wichtig zu wissen, was so genau sein soll. Die Phase oder die Frequenz. Wenn die Phase so genau sein soll, dann geb ich Dir recht, dann muss die Frequenz des AVRs so hoch sein. Soll hingegen nur die Frequenz auf lange Sicht gesehen so genau sein, so kannst Du das sehr genau per DDS (Direkter Digitaler Synthese) erreichen. Das funktioniert ungefähr so. Stell Dir einen Kreis vor. Du möchtest jetzt, dass sich ein Punkt gleichmäßig auf dem Kreis bewegt. Da Du in einem zeitdiskreten System arbeitest, schiebst Du den Punkt bei jedem Taktzyklus ein paar Werte weiter. Der Durchmesser deines Kreises kann nun beispielsweise eine 128-Bit Ganzzahl sein. Da ist in Assembler auf dem AVR überhaupt kein Problem. Die Schritte speicherst Du in ebensoeiner Ganzzahl ab. OK 100kHz sind direkt mit dem AVR ein Problem. Aber rechnen wir mal mit 10 kHz und einer Schrittrate von 100 kHz. Dein Kreis hat dadurch, dass er durch einen 128 Bit Zähler gebildet wird, genau 340282366920938463463374607431768211456 Punkte.Du möchtest jetzt 10 kHz erreichen, somit gehst Du immer 1/10 Durchmesser in jedem Schritt. Das sind 34028236692093846346337460743176821145,6 pro Schritt, was natürlich nicht geht. Aber stell Dir nur mal vor in welch feinen Schritten Du die Frequenz am Ausgang jetzt einstellen kannst. Du kannst als extra natürlich auch noch die obersten 10 Bit verwenden, um einen Sinuswert in einer Tabelle nachzuschlagen und den dann auf den PWM auszugeben. Das reicht für 8 Bit am Ausgang. Diese Frequenz kannst Du wunderbar filtern und auf eine PLL geben.
Moin Christian, an DDS habe ich natürlich nicht gedacht - vielleicht auch, weil mir nicht klar war, dass auch ein "einfacher" Sinus reichen würde... Hier könnte nur schwierig werden, diesen (dann ja analogen Wert) auszugeben. Was ich bisher verstanden habe hast Du etwa folgende Idee: Eine Sinustabelle hat meinetwegen 2^16 Werte. Je schritt gehst Du nun X Werte weiter. Für eine Periode musst Du insgesamt 2^16 wert weitergehen wobei uninteressant ist, ob zwischendurch welche ausgelassen werden. Jetzt kannst Du also sehr fein einstellen, wie viel Frequenz Du haben willst. Du kannst nicht nur die Geschwindigkeit mit der Du weitergehst bestimmen sondern auch noch die Schrittweite. Mein Problem: es entsteht eine Amplitudenmodulation. Die Frequenzen müssen hier dem Nyquistkriterium genügen, damit eine einwandfreie Rekonstruktion möglich ist... Also abtastfrequenz >> Signalfrequenz*2 Und man braucht noch ein analoges Filter welches sich verstimmen lässt für ein optimales Verhalten, oder? Ich glaub das ist mal ein echt interessantes Projekt! Grüße, Clemens
Nunja, erstmal kannst Du in deine Tabelle ja auch einen Rechteck reinschreiben, da kannst Du dann sogar einfach dein hochwertigstes Bit verwenden. Klar, die Abtastfrequenz muss deutlich größer als die doppelte Signalfrequenz sein. Wobei besonders beim Sinus der Filter das schon gut rausfiltern könnte. Man müsste nur mal ausrechnen, wie das Spektrum aussieht. Wenn die Linien durch die Abtastfrequenz weit genug weg sind, so sollte das funktionieren. Variabel muss der Filter nicht sein, da wir ja nur eine Frequenz ausgeben wollen.
Also das mit dem Rechteck wird wohl nicht so recht klappen. Schließlich hat man dann ja höhere frequenzen die nicht ordentlich mitverschoben werden. Das wär ja das gleiche, als PWM auf 50% stellen und den TOP-Wert bei jedem Überlauf ändern, so dass im Mittel die sollfrequenz rauskommt. Nur dann hat man ja ne FM... ich weiss zwar nicht, wie sich das auf das gewünschte Verhalten auswirkt, aber kann mir vorstellen, dass 10Mhz nicht erst nach 1sec 10Mhz sein sollen, sondern möglichst nach spätestens 10 perioden... Hier könnte ein Schmitttrigger nach dem sinus helfen.
Naja, gut, beim Sinus hast Du den Vorteil, dass deine gewünschte Frequenz immer genau mit dabei ist, und Du nur deine Aliasing-Frequenzen wegbekommen musst. Solange die Frequenz jedoch viel kleiner als die halbe Samplingrate ist, reicht aber der Rechteck auch.
Ja, aber da liegt ja grad der Hase im Pfeffer begraben: wir haben mit einem AVR nunmal ne maximale Samplingrate von 16Mhz. Da ist nicht mehr viel mit 10Mhz... Also das mit dem Recheteck wird vermutlich schwierig.
Naja, aber man könnte ja einen Sinus mit 10 kHz ausgeben und den dann als Eingang für einen PLL verwenden. Direkt 10 MHz zu erzeugen ist natürlich utopisch.
Wie genau lässt sich den ndie pll realisieren? würde die sich nicht auch manchmal "verschlucken"? dann hat man ja auch keine 10Mhz mehr...
Naja, die PLL würde in Hardware gemacht. Du nimmst deinen Sinus aus deinem ATMega, filterst den, so dass Du wirklich nur eine Frequenz hast, dann machst Du daraus wieder ein Rechteck und gibst das an den Eingang eines XOR-Gatters. Den Ausgang Tiefpassfilterst Du dann und gibst ihn an den Eingang eines spannungsgesteuerten Oszillators. Dessen Ausgang teilst Du dann runter auf 10kHz und gibst den an den 2. Eingang des XOR-Gatters. Das regelt sich dann so ein, dass die Ausgangsfrequenz des Oszillators genau ein Vielfaches der Eingangsfrequenz ist. Man kann dann das Tiefpassfilter am Ausgang des XOR-Gatters noch optimieren, so dass die Schaltung nicht schwingt, aber trotzdem schnell einschwingt.
Christian Berger wrote: > Das regelt sich dann so ein, dass die Ausgangsfrequenz des Oszillators > genau ein Vielfaches der Eingangsfrequenz ist. Man kann dann das > Tiefpassfilter am Ausgang des XOR-Gatters noch optimieren, so dass die > Schaltung nicht schwingt, aber trotzdem schnell einschwingt. Da liegt ja das Problem, da es eine Regelschleife ist, die sich erst einschwingt, wird es nicht sehr konstant sein. also man kann nicht davon ausgehen, dass z.B. exakt alle 10us exakt 100 Schwingungen entstehen, wenn man 10Mhz einstellt. Aber genau das zeichnet ja eine qualitativ gute Frequenzreferenz aus. Sonst würde die Genauigkeit eines Quarzes wohl auch ausreichen - da bräuchte man dann keine Rechenschaltung mit AVR und DCF...
Naja, aber Du kannst sehr gut feststellen, wann sich die Regelschleife eingeschwungen hat. Und dann ist die starr verbunden. Dann läuft die einfach hochgenau auf der richtigen Frequenz. Und das Einschwingen kann man in den Bereich von deutlich weniger als einer Sekunde bringen.
Bin auf der Suche nach gescheitem DCF77 Code auf dieses interessante Projekt hier gestoßen. Verstehe den ganzen Code nicht komplett auf Anhieb dennoch hier meine Frage zum Timer0: Muss dieser zwingend mit 625 Hz getaktet sein oder darf's auch 1 KHz (1ms Takt) sein? In meiner Zielanwendung läuft T0 bereits mit 1 KHz und versorgt einen kleinen Scheduler. Bauen weitere Berechnungen auf diesen 625 Hz auf?
Hallo "No Name" [hier könnte Dein Name stehen], ich gehe fest davon aus, dass da was drauf aufbaut. Du musst u.U. auch noch gucken, ob der prozessor mit 1khz vielleicht überlastet ist... Schöne Grüße, Clemens
Wie soll ich denn "ob der prozessor mit 1khz vielleicht überlastet ist" verstehen. Mein verwendeter ATmega16 überlebt laut Datenblatt sogar 16000 KHz. Schöne Grüße, "No Name"
einfach kopf einschalten und statt "nohelp" lieber mal "help" rufen ;-)
Der Code muss mit 625Hz laufen. Ansonsten musst du die Filterlänge (Array) anpassen. Steht auch im Kommentar irgendetwas drin zur Filterlänge.
Hab zwischenzeitlich etwas Erfahrung mit dem Code gesammelt. Für die 625Hz hab ich einen weiteren Timer verwendet. Dass die Sekunden von der tatsächlichen Zeit abweichen, finde ich nicht so gut gelungen. Schon ein kleiner Frequenzdrift des Quarz sorgt nach einiger Zeit für mehr oder weniger großes "Weglaufen" von der realen Uhrzeit, die nicht neu synchronisiert wird. Vorteil des SAF ist allerdings, dass Spikes bis zu einem gewissen Grad herausgerechnet werden.
wenn die Sekunden merklich abweichen hast du a) einen kaputten quarz, oder b) den quarz nicht genutzt und läufts auf dem rc-oszi, oder c) die versorgungsspannung nicht in den spezifizierten greunzen, oder d) den temperaturbereich verlassen, oder --> e) den timer falsch eingestellt. bei mir läuft die zeit ohne abweichungen und synchronisiert sich auch nach.
Mein Atmega8 hängt am Clkout-Ausgang eines MCP2515, der mit 8 MHz getaktet wird, Vorteiler /1. Ich hab das ganze 2mal aufgebaut, das 2te mal allerdings mit ATmega16. Beide Systeme entwickeln eine Abweichung, der eine Aufbau etwas mehr als der andere. Meiner Meinung fehlt ein häufigerer Abgleich mit der Softwareuhr zum Minutenanfang.
Warum nur ... warum nur ... warum nur?! Das frugte sich "nohelp", oder nicht? Ich würd mal darüber nachdenken, warum beide unterschiedliche Abweichungen haben! Aber denken muss man leider schon :(
Hallo und zur Info, ich bin kein blutiger Anfänger, der nicht weiss, wie man die Taktversorgung organisiert. Und klar dürfte sein, dass so ziemlich jeder Quarz eine gewisse Abweichung hat. Daher nimmt man auch bei bestimmten Anwendungen (z.B. im HF-Bereich) Quarzheizungen, um wenigstens das Thema Temperaturdrift in den Griff zu bekommen. Oder eben PLL. Falls jemand einen konstruktiven Hinweis zum Quellcode hat, nur her damit. Denn dort liegt meiner Meinung nach noch ganz sicher ein Wurm drin. Ich lasse momentan als Referenz einen der beiden Mikrocontroller mit einer "herkömmlichen" DCF77 Software laufen, die ein wirklich exaktes Ergebnis liefert. Beide bekommen das selbe Empfangssignal eines einzigen DCF77-Moduls eingespeist.
No Name schrieb: > großes "Weglaufen" von der realen Uhrzeit, die nicht neu > synchronisiert wird. Dann hast du die Synchronisierung der Uhrzeit (Bits) aus dem SAF-Filter mit deiner SW-Uhr nicht richtig realisiert. Der Code funktioniert prima. Der SAF-Algorithmus hier hat allerdings den Nachteil, dass er auch bei großen Störungen meint, er hat ein gültiges Bit erkannt, also 0 oder 1. Das kann nicht sein und deshalb mußt du mindestens 2 aufeinanderfolgende Datensätze auf konsistens prüfen ehe du den letzten dann übernimmst. Das ist in dem Ursprungscode auch so realisiert. Wenn du das dann selber änderst dann weine nicht, das der Code nicht funktioniert bzw. nicht synchronisiert. Außerdem bleibt dir auch die Aufgabe auf Sekunde 0 (Minutenanfang) zu synchronisieren wenn du den Originalcode nicht verwendest. Sonst bekommst du ja auch keine gültige Uhrzeit hin. Der SAF-Filter ist das eine Ding, einen kompletten gültigen(!) Datensatz aus den Bits zu generieren, dass andere. Und Fehlererkennung ist noch wieder etwas anderes. Dein eigener KOMPLETTER Code dürfte auch aufschlussreich sein zum Fehler finden.
Ok, dann mal hier mein Programmcode, der sich mit der Uhr beschäftigt. Ich hab den ursprünglichen Code kaum verändert, allerdings die vier Dateien zu zwei zusammengeführt. Benutze INT1 als Eingang. An anderer Stelle im Programm wird dcf77_timer(); im Sekundentakt aufgerufen, was durch einen weiteren Timer (CTC Mode) geregelt wird.
Du hast den entscheidenden Teil leider vergessen: No Name schrieb: > An anderer > Stelle im Programm wird dcf77_timer(); im Sekundentakt aufgerufen, was > durch einen weiteren Timer (CTC Mode) geregelt wird. Wenn was wegläuft, ist sicher das hier schuld! Und jetzt komm nicht mit Quarz habe Abweichung ... blablah ... da will ich erst mal Deine Rechnung sehen!
Angenommen, mein Quarz ist blöd und ich bin unfähig die Formel aus dem Datenblatt richtig anzuwenden, dann müsste dennoch hin und wieder ein Abgleich zwischen davon laufender Softwareuhr und SAF-Bitstream erfolgen und dies nicht nur nach 4 Minuten korrektem Empfangs zum Programmstart. Dass die Sekunden meist 4 Sekunden nachlaufen, ist ja schon prinzipbedingt. Nach Stunden und Tagen wird es aber mehr. Die Frage, wie ich den Timer1 für den Sekundentakt programmiert habe, ist meiner Meinung nach hier nicht zielführend.
Du tönst so groß rum, dass du kein Neuling bist. Warum rechnest du dir nicht mal aus, wie groß die Abweichung ist, wenn der Quarz 10ppm von der Nennfrequenz abweicht? Bei mir kommt da raus, das nach 1 Tag die Uhr weniger als 1 Sekunden abweicht. Aber selber rechnen kannste nicht, oder? "Formel aus dem Datenblatt" klingt auch nicht gerade nach selberdenken sondern eher nach c&p, schäm dich!
So abschließend für die Quarzfraktion noch meine Timer1 Initialisierung:
1 | TCCR1B = (1<<WGM12)|0x04; |
2 | TCNT1 = 0; |
3 | OCR1A = (F_CPU/256/1)-1; // == 31249 F_CPU=8000000 |
4 | TIMSK = (1<<OCIE1A); |
5 | TIFR = (1<<OCF1A); |
Allerdings finde ich es schade, dass hier in der Codesammlung nicht über den Quellcode diskutiert werden kann, sondern eine endlose Diskussion über Quarze stattfindet. Lasst's mal gut sein, werde selber weiterforschen.
No Name schrieb: > dann müsste dennoch hin und wieder ein > Abgleich zwischen davon laufender Softwareuhr und SAF-Bitstream erfolgen Richtig. Genau dort vermute ich dein Problem. Da du aber oben in deinem geposteten Code die Synchronistation nicht enthalten ist, kann dir da auch keiner helfen. Probiere doch mal den Originalcode und teste ob es damit funktioniert. Deinen eigenen Code solltest du nochmal genau prüfen. Instrumentiere ihn, d.h. an geeigneten Stellen Ausgaben auf ein Display/UART senden um zu sehen, dass deine erwarteten Werte auch wirklich da sind. Im IRQ besser keine Ausgaben da diese dann die Laufzeit des IRQs zu stark verlängern.
Meinste nicht auch, dass die Synchronisation innerhalb meiner ISR(TIMER2_COMP_vect) geschieht? Ist im Original in main()
No Name schrieb: > Meinste nicht auch, Nein, da passiert nur die Synchronisation auf den Minutenanfang. Ob die bei dir aber auch funktioniert, hab ich nicht geprüft. > dass die Synchronisation innerhalb meiner > ISR(TIMER2_COMP_vect) geschieht? Ist im Original in main() In der Funktion dcf77_putBit() ab "case 4:" passiert die Validierung, ob ein empfangener Datensatz gültig ist. Das schaue dir mal genau an. Du kannst dir die Variablen "u8InvalidCounter" und "u8ValidCounter" mal ausgeben lassen und dir die Logik anschauen die dahintersteckt. u8Status spiegelt wieder, ob und welcher Datensatz gültig ist. Das hast du ja auch in deiner eigenen neuen Routine dcf77_getTime() schon mit eingebaut. Aber du hast im Moment keine Möglichkeit zu erkennen, ob überhaupt genügend aufeinanderfolgende gültige Datensätze erkannt werden. Das müssen 4 Stück sein. Die Ausgabe der oben vorgeschlagenen Variablen ist ja nur einmal die Minute notwendig (also stört nicht) und dann wirst du sicher erkennen, warum nicht ein gültiger DCF77-Datensatz geliefert wird mit dcf77_getTime().
Hallo Clemens Vielen Dank für deinen Code. Ich bin grad dabei den zu verstehen, ist aber ein bisschen tricky für mich. An welcher Stelle (wahrsch. in der Hauptschleife) müsste ich denn ansetzen um mir z.B. im sekunden-Takt über die serielle Schnittstelle Stunden, Minuten und Sekunden ausgeben zu lassen. Die Ausgabe über UART krieg ich selber hin ;-) Vielen Dank schon mal. Felix
Ein paar Links http://de.wikipedia.org/wiki/Optimalfilter Beitrag "DCF Digital Empfangsmodul - Korrelation - (Assembler)ATmega8" http://www.mikrocontroller.net/forum/codesammlung?filter=dcf Beitrag "DCF77 Uhr in C mit ATtiny26"
Angehängte Dateien:
...nachdem ich die Pinbelegung geändert(c1) und die unbenutzte Var. j entfernt habe, synchronisiert die Schaltung. Gute Arbeit, Clemens ! Dauerte bei mir - Nähe Demmin (meck/Vorpom) allerdings mehr als 1 Stunde. (bei trüben Wetter, teils Regen); Spricht aber für das Filter(und Deine gelungene Umsetzug), das sie es dennoch tat... p.s.: -das Bild kannst'e vergessen... hab auf 4 Digit geändert, daher DP hinter Stunden;
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.