Hi, ich hab folgendes Problem bei der DCF77 signal auswertung. Hab 2 Lösungen für DCF77 Signalauswertung. a) Ich werte das DCF77 signal per Externen Interrupt aus, und polle das Signal im Interrupt und Prüfe wie lang es war. 100ms oder 200ms. Und in der 1,5 sekunden Sendepause schreib ich das Signal im normal Interrupt (5ms) an die Anzeige raus. Doch wenn die Pause ist, ist das Signal doch schon wieder veraltet. D.h. ich habe alle ~59sek einen sprung meiner Sekundenanzeige. Ich könnte die Sekunden, Minuten, Stunde dann rausschreiben wenn ich Sie empfange, doch selbst da, hab ich einen gewissen "Offset" drin. b) Ich werte das Signal im normalen Interrupt (5ms) aus und schreib es da raus... doch da hab ich auch wieder das Problem mit "veraltetes" Signal usw. ==================================== Die Sekunden zähl ich im "normalen Interrupt (5ms)" weiter, als RTC. So.. etz brauch ich ne lösung für das "Veraltete Signal" Vielen Dank schonmal für die Lösung im vorraus MFG Christopher Schirner
Hallo, wo ich mal ein DCF77 Signal ausgewertet habe,lief im Hintergrund eine Uhr per Software, die per DCF77 nur aktualisiert wurde. Wenn man diese ständig aktualisiert, kann die ruhig etwas ungenau sein. Jogibär
Kann ich mal den auswertungscode sehen? Bzw. was heißt "etwas" ungenau. Wenn ich das Signal erst rausschreibe in der "Pause" ist das signal schon min 20 sekunden alt!
Hallo, Achtung !! Der Code ist uralt! Wenn ich den mal wieder brauche, werde ich den komplett umstricken. (damals habe ich noch wild herumprogrammiert ;-) ) Im Prinzip ist die Sache einfach. Du mußt nur in der 59. Sekunde die Referenzmarke erkennen. Dann ist deine Uhr syncron. Dann kannst du bei jedem neuen Impuls die Softwareuhr syncronisieren. Dann läuft diese zwar ca. 200 ms nach, weil erst dannach die Auswertung fertig ist, aber das sollte doch reichen. Jogibär
ich seh grad das sekunden garnet gesendet werden, nur minuten stunden und anderes. Ich bekomm aber n signal wenn ne neue minute anfängt, das sollte das zeichen sein "starte deine RTC!"
Hallo, natürlich werden indirekt die Sekunden gesendet. Exact jede Sekunde bekommst Du ein neues Signal. Entweder 100ms oder 200ms ->neuer Interrupt. Damit kannst Du ganz genau Zählen. Syncronisation mit der 59. Sekunde. Jogibär
Hi, Christopher, ja, das Synchronisationsproblem. Beim Zeitsignal - mach Deine eigene, interne Uhr. Die schreibt in die Anzeige. Das DCF-Signal verwende nur zum Start und zur Synchronisation. Deine interne Uhr sagt Dir, wann die Sekunde hätte vorbei sein müssen - und die Sekundenmarke prüfst Du nur zur Bestätigung Deiner Voraussage, und gegebenenfalls zur Korrektur Deiner internen Uhr. Ciao Wolfgang Horn
letztere idee hat mir eigentlich gut gefallen... :) mal schaun welche ich umsetz -> man glaubts kaum, konnte aber deswegen kaum einschlafen gestern. . zuviele ideen im kopf
Es wird immer die Zeit für die nächste Minute gesendet. Du mußt also die komplette Zeit speichern und zur 0. Sekunde des nächsten Pakets ausgeben. Sonst geht Deine Uhr immer vor. Allerdings kann das Signal oft gestört sein (Staubsaugen, Fernsehen, Gewitter). Daher haben alle DCF77 Uhren eine interne Uhr, die nur bei korrekt empfangenen Daten synchronisiert wird. Diese Uhr macht nebenbei die fehlende Sekunde. Den externen Interrutp zu nehmen, ist keine gute Idee, da die Empfänger oft kurze Störimpulse ausgeben. Besser ist ein Timerinterrupt, der z.B. alle 10ms abfragt, damit hat man dann eine Störunterdrückung. Schau mal in die Codesammlung, da sind Beispiele von mir. Peter
Hatte das ding gerade am Osszi und hab gesehen das im 5ms takt plötzlich signale kamen und dachte mir zuerst was das soll. nachdem ich mit den finger an die antenne gelangt habe, war das signal wieder OK.... also anscheinend hat hier irgendwas im raum gestört. wie prüfe ich ob eine übertragung korrekt ist? Es gibt parity bits, ja hm :P HM...... :P HMMMMMMMMMM! :) naja man überlegen
>Daher haben alle DCF77 Uhren eine interne Uhr, die nur bei korrekt >empfangenen Daten synchronisiert wird. Diese Uhr macht nebenbei >die fehlende Sekunde. Die hier im Forum genannte günstige Conrad-Uhr hat nach einem (kurzen?) Spannungsverlust 3 Stunden lang munter die falsche Zeit angezeigt, trotz Empfang. Erst nach einem Warmstart hat sie die richtige Zeit wiedergefunden.
Hab das ding hier gerade im testbetrieb laufen, bei einer umgebung mit 5 computern, einer laufenden pumpe, und ein netzteil in betrieb nebenan, leifert das ding laut oszi und muter blinkender LED am invertierten eingang ein sauberes signal... mal schaun wie lang :)
Wie Peter D. schon sagte: die Zeitinformation für die nächste Sekunde 'Zusammenbauen' und die im Hintergrund laufende RTC zur Sekunde 0 synchronisieren. @ Peter D.: Ich benutze den ICP - Interrupt zum Messen der Impulse, hatte noch keine Störungen drauf, das Teil synchronisiert sich jede Minute richtig.
> die Zeitinformation für die nächste Sekunde 'Zusammenbauen'
Eher für die nächste Minute :)
Ups.. richtig, Minute! Nachtrag: den ICP nehme ich weil er einen Noise-Canceller hat.
>Die hier im Forum genannte günstige Conrad-Uhr hat nach einem (kurzen?) >Spannungsverlust 3 Stunden lang munter die falsche Zeit angezeigt, trotz >Empfang. >Erst nach einem Warmstart hat sie die richtige Zeit wiedergefunden. Ich hab' auch so 'ne "Uhr" von Conrad als Wecker. Die stellt nicht mal selbst auf Sommer-/Winterzeit um, ob das Signal nun da ist oder nicht...
Apropos Sommer/Winterzeit.... Sendet der Frankfurter Turm die Sommer und Winterzeit auch richtig, oder nur das Flag, und ich darfs selbst zuaddieren/abziehen?
Hi, mit dem Modul von Conrad (Also nicht die komplette Uhr, sonder dieses DFC-77-Modul auf Platine) hatte ich da auch so meine Probleme, meins gibt bei manchen Warmstarts Doppel-Impulse anstatt durchgehender Impulse raus. Wenn man da keine Monitor-LED für den Empfang dranhat, merkt man so etwas unter umständen später gar nicht, weil der Teil schon längst verlötet ist und wundert sich dann über die gelegentlichen Fehlfunktion. Viele der gekauften Uhren gehen übrigens nicht Synchron, finde ich bei einer Funkuhr eigentlich einen Grund, sie umzutauschen. Da wird mit der genauigkeit einer Atomuhr geworben und dann geht das Ding 1 Sekunde vor oder nach, weil die nur ein mal pro Tag einen Abgleich machen und der interne OSzillator schon nach Stunden krasse Abweichungen verursacht (habe das anhand meiner synchron gehenden Uhr mit diversen Funkuhren getestet). @Christopher Schirner: Die Zeit wirt natürlich korrekt gesendet, Du wirst also stets genau die korrekte Zeit für die jeweils nächste Minute empfangen. Mfg, Worf
> Die Zeit wirt natürlich korrekt gesendet, Du wirst also stets genau > die korrekte Zeit für die jeweils nächste Minute empfangen. und zusätzlich noch ein Flag. Soweit ich weiß gibt es noch ein Flag, das einen bevorstehenden Sommer/Winterzeitwechsel ankündigt.
Hab etz eh die Ideale lösung :) Das DCF werte ich trotzdem per ext. Interrupt aus. Und zwar soll der ausgelöst werden bei steigernder und fallender flanke Bei der steigenden stell ich nen variablenwert auf 0, dieser wird im 1ms interrupt hochgezählt. bei der fallenden schau ich obs 100 oder 200ms sind... dann wirds ins array geklopft... Parität wird am ende des signals während der pause geprüft, und das "paket" als gültig oder nichtig markiert. und störungen sollen ruhig kommen! paritätsprüfung FTW! :PPP
@Christopher: die umgesetzte Lösung kann ich dir geben. @unsichtbarer WM-Rahul (Gast): icp = inductive coupled plasma ?!?
Oh je. Mit ICP? Und wenn kleine Störungen im Signal sind? (Wurde glaube ich schon weiter oben erwähnt)
Dann sind halt Störungen im Signal. Die kommen durch Impulslängenbestimmung bzw. Paritätsprüfung raus, und dann erfolgt halt kein Abgleich der Uhr.
is net weiter schlimm... hab extra n uhrequarz drauf, damit sollte es sogar reichen das ding einmal am tag... oder weniger abzugleichen... ich mein die muss ja etz ne prezise sekundenweise was steuern... wird nur ne röhrenuhr :)
>Bei der steigenden stell ich nen variablenwert auf 0, dieser wird im 1ms >interrupt hochgezählt. >bei der fallenden schau ich obs 100 oder 200ms sind... dann wirds ins >array geklopft... Bei dieser Vorgehensweise wird es aber problematisch alle 59 Bits einwandfrei zu empfangen. >bei der fallenden schau ich obs 100 oder 200ms sind... dann wirds ins >array geklopft... und wenn es nur 50ms waren (da Störung)? Beim nächsten Flankenwechsel wird die Zählvariable doch wieder auf null gesetzt. Gruß, Martin
Zu vermutung 1: warum sollte es da probleme geben? zu vermutung 2: Soll doch ne störung kommen... wenn die parität meint das stimmt net, kann mir die sequenz am a*+* vorbeigehen :PPP
@schinken: zu Vermutung 1: Ergibt sich aus Vermutung 2: >Soll doch ne störung kommen... wenn die parität meint das stimmt net, >kann mir die sequenz am a*+* vorbeigehen Eine Sequenz dauert immerhin 60 Sekunden.... Gruß, Martin PS: ich muß jetzt weg, schaue später noch mal rein.
Hab heute meine Auswertung programmiert. Funktioniert erste Sahne :) Erkennt auch ohne probleme fehler bei der übertragung...... andere frage, konnte nichts dazu finden, welches BIT gibt an, das ein minutenwechsel stattfindet? Und wenn das auftritt, muss ich sofort beim empfang darauf reagieren, oder erst am ende der sequenz?
Naja nach irgendwas muss ich ja meine sekunden synchronisieren, und ich glaub mich daran erinnern zu können das es ein bit gibt, das einen minutenwechsel ... also sekunde 59 auf 00 signalisiert. jetzt ist die frage ob ich direkt beim empfang des bits reagieren muss, oder am ende der sequenz...
Hallo, Du hättest vielleicht doch die Beschreibung des DCF77-Formates zu Ende leden sollen... ;) Der Beginn der neuen Minute ist der erste Sekundenimpuls. Der erste Sekundenimpuls ist der nach dem FEHLENDEN 59. Sekundenimpuls... Übertragen wird jeweils die folgende Minute, Du mußt also Deine Uhr mit Beginn der neuen Sequenz auf die schon übertragene Zeit setzem. Gruß aus Berlin Michael
Was hat denn die Variable "iDCFSequenz" für eine Funktion? Wird die jede Millisekunde hochgezählt?
Michael U. Also wenn ich den ersten impuls empfang, stell ich meine Sekunden auf null, und meine Minute +1? Martin: Ja die wird im Millisekundenbereich hochgezählt, und dann beim ende der sequenz geprüft wie groß die zahl ist... dadurch wird 1 und 0 entschieden :)
> Ja die wird im Millisekundenbereich hochgezählt, und dann beim ende der > sequenz geprüft wie groß die zahl ist... dadurch wird 1 und 0 > entschieden :) Diese Entscheidung wird doch mit "iSignalLength" gefällt?
Hallo, @Schinken: Du kiest (wie auch immer) die Impulse ein und wertest aus. Beginn der Impulsfolge ist ja der erste Impuls nach dem fehlenden 59. Impuls. Wenn alle 59 Impulse richtig empfangen wurden und dekodiert wurden und alle Prüfungen ok sagen, dann ist der nächste Impuls die 0te Sekunde und die empfangenen Daten enthalten Tag/Datum/Stunde/Minute, die eben da beginnt. Also Sekunde (und evtl. Vorteiler) auf 0 und die dekodierte Minute und Stunde in die Uhrzeit. Gruß aus Berlin Michael
Michael U. ich verstehe ^^ mit-einbau Martin Kreiner: ja, bei 200ms ist es eine 1, bei 100ms eine 0. Ich hab die Entscheidung mit <150 gefällt, da es durch die erkennung etc. leicht variieren kann (is aber an sich egaaal :))
Zur DCF77-Uhrenanwendung kann ich euch noch ein paar Tipps geben. Man hat praktisch zwei Uhren im System: eine RTC und eine DCF77. Beide führen ihre Zeitdaten vorzugsweise in je einer Struktur vom gleichen Typ. Die RTC baut man so auf, daß sie im Sekundentakt oder im Minutentakt aufgerufen werden kann, mit ihrer Zeitstruktur als Parameter. Die DCF77 schreibt ihre Zeitdaten nach jeder Minute auch in ihre (eigene) Zeitstruktur (Sekunden sind 0). Das Synchronisieren sollte man wie folgt machen: man benötigt eine Funktion, die die Zeitdifferenz zwischen zwei solchen Strukturen berechnet, in Sekunden. Dann läßt man bei jeder vollen Minute der DCF77 diese Differenz ausrechnen; wenn die Abweichung größer als ein Schwellenwert ist (z.B. größer als 2 Sekunden - soviel sollte man tolerieren), läßt man - gesteuert über Flags - die RTC schneller oder langsamer laufen, und zwar für soviele Timer-Ticks, wie die Abweichung ergeben hat - das kann man ja vorher schon ausrechnen (man kann z.B. die Timer-Ticks doppelt so schnell oder halb so schnell laufen lassen, je nach Richtung der Abweichung). Nach dieser vorausberechneten Zahl von Timer-Ticks ist die Abweichung exakt ausgeglichen. Das ist ein großer Vorteil gegenüber der Primitiv-Synchronisierung durch Kopieren der DCF77-Zeitstruktur auf die RTC-Zeitstruktur, und zwar aus folgendem Grund: oftmals will man ja eine Funkuhr auch als Schaltuhr verwenden. Dabei hat man dann eine Zeittabelle, in der die Schaltzeiten stehen (u.U. sekundengenau aufgelöst) und die bei jedem Timer-Tick (also bei jeder vollen Sekunde) komplett durchgearbeitet wird. Bei Gleichheit wird ein Schaltvorgang ausgelöst. Wenn man die Primitiv-Synchro verwendet, könnte es theoretisch passieren, daß durch Überschreiben der RTC-Zeitstruktur eine Tabelleneintragung der Alarmtabelle überhaupt nicht "drankommt", weil ihre Zeit übersprungen wird, oder sie wird doppelt ausgeführt (wenn die RTC nämlich zu schnell geht, dann würde sie ja zurückgesetzt werden). Bei der von mir beschriebenen Methode des Schneller- oder Langsamer-Laufenlassens kommt jedoch "jede Zeit dran", nichts wird übersprungen oder doppelt ausgeführt (ist halt aufwendiger). Das Problem der Störungen der DCF77 kann man wie folgt lösen: Man sollte die RTC als Funktion programmieren, die als Parameter einen Zeiger auf eine Zeitstruktur übergeben bekommt, und die pro Aufruf die angepeilte Zeitstruktur um eine Sekunde oder um eine Minute erhöht, gesteuert durch einen zusätzlichen Parameter (bei Erhöhung um eine Minute setzt sie die Sekunde auf 0). Dann kann man diese RTC-Funktion immer dann, wenn die DCF77 eine volle Minute meldet, auf eine Kopie der DCF77-Zeitstruktur vom vorigen Mal anwenden (mit der Minuten-Inkrementierung), danach muß sie die gleiche Zeit wie die der DCF77 führen, wenn die DCF77 das richtige empfangen hat (d.h. man überprüft, ob die DCF77 nach jedem Minutenempfang auch wirklich eine um genau eine Minute erhöhte Zeit ausweist). Das muß die DCF77 z.B. 10-mal hintereinander ohne Unterbrechung bringen (Zähler setzen!). Gibt es eine Störung und ein Empfang fällt aus (das merkt man am Vergleich sofort), so fängt der Vorgang wieder von vorne an. Erst dann, wenn die DCF77 10-mal in Folge eine korrekte (d.h. um immer genau eine Minute erhöhte) Zeit hervorgebracht hat, wird nach dem 10. Mal diese Zeit als "gültig" erachtet und die RTC dann erstmals durch Kopieren der Zeitstrukturen gesetzt (nach dem Einschalten des Systems), und ein Gültigkeitsflag wird gesetzt, sodaß frühestens jetzt Schaltuhrfunktionen laufen. Ab diesem Zeitpunkt kann nun die DCF77 wieder ausfallen - die 10-Mal-Regel läuft aber immer mit und bewirkt, daß Resynchronisationen nur laufen, wenn die DCF77-Zeit 10-fach richtig war, siehe oben. (Nebenbei: wird bei einem Zeitvergleich eine zu große Abweichung festgestellt, dann wird ausnahmsweise doch kopiert statt der Schneller/Langsamer-Methode, unter Inkaufnahme ausgefallener Schaltvorgänge.) Parallel dazu läuft ein zweiter Zähler, der zählt, wie lange die DCF77 ausgefallen war und aufgrund von Störungen keine gültige Zeit erbracht hat. Bei meinen Systemen habe ich diesen Zähler auf äquivalent 10 Stunden gesetzt; d.h. wenn 10 Stunden lang die DCF77-Zeit nicht synchronisiertauglich war (nach der obigen 10-Mal-Regel), wird das Gültigkeitsflag wieder heruntergeschraubt und kritische Schaltuhrfunktionen werden u.U. verhindert - aber das muß man von Anwendung zu Anwendung entscheiden, ob soetwas sinnvoll ist. Das Gültigkeitsflag steuere ich so: nach dem Einschalten (die RTC-Zeitstruktur steht dann auf 0,0,0,0...) ist das Gültigkeitsflag '0'. Sobald der erste Empfang der DCF77 eintrifft, wird durch Kopieren die RTC gesetzt und das Gültigkeitsflag auf '1'; nun kann die Zeit bereits am Display angezeigt werden, ist aber noch nicht 100%-ig zuverlässing, und Schaltfunktionen finden noch nicht statt. Erst nach dem 10. gültigen Empfang (siehe oben) wird das Gültigkeitsflag auf '2' gesetzt und Schaltfunktionen können stattfinden sowie Synchronisationen mit der Schneller/Langsamer-Methode. Wenn 10 Stunden lang kein DCF77-Empfang nach der 10-Mal-Regel stattfand, wird das Gültigkeitsflag wieder auf '1' zurückgesetzt (ein Indikator im Display weist das aus). Noch ein Wort zu der Zeittoleranz von 2 Sekunden oder so: ich finde, man sollte von einer Funkuhr keine "Atomgenauigkeit" fordern. Ihr Vorteil liegt doch ganz woanders, nämlich darin, daß sie unbeachtet und bedienerlos nach dem Einschalten (oder einem Wieder-Einschalten nach einem Stromausfall) automatisch wieder ihre Zeit (und das Datum!) findet. Ob sie 2 Sekunden vor- oder nachgeht, ist doch meistens bedeutungslos. Das sind meine Gedanken, und meine Erfahrungen, zum Umgang mit DCF77-Systemen (klar, es gäbe noch mehr zu sagen). Günter
> > Dabei hat man dann eine Zeittabelle, in der die Schaltzeiten > stehen (u.U. sekundengenau aufgelöst) und die bei jedem Timer-Tick (also > bei jeder vollen Sekunde) komplett durchgearbeitet wird. Bei Gleichheit > wird ein Schaltvorgang ausgelöst. Wenn man die Primitiv-Synchro > verwendet, könnte es theoretisch passieren, daß durch Überschreiben der > RTC-Zeitstruktur eine Tabelleneintragung der Alarmtabelle überhaupt > nicht "drankommt", weil ihre Zeit übersprungen wird, oder sie wird > doppelt ausgeführt (wenn die RTC nämlich zu schnell geht, dann würde sie > ja zurückgesetzt werden). Bei der von mir beschriebenen Methode des > Schneller- oder Langsamer-Laufenlassens kommt jedoch "jede Zeit dran", > nichts wird übersprungen oder doppelt ausgeführt (ist halt aufwendiger). Oder aber man speichert sich beim Zeiteintrag ein zusätzliches Flag mit der Bedeutung: wurde schon abgearbeitet und vergleicht die Zeiten nicht auf Gleichheit, sondern auf Größer. Nachts um Mitternacht, wenn die bereits DCF korrigierte Zeit 00:00 anzeigt, werden alle Flags zurückgesetzt. Dann braucht man nicht mehr diese 'komplizierte' Synchronisierung und kann zu jeder vollen Minute die RTC mit der DCF korrigieren. Rein Interessehalber: Wie funktioniert dein Schema eigentlich in der Nacht der Sommerzeitumstellung? Wie lange braucht die RTC bis sie den Gangunterschied von 1 Stunde ausgeglichen hat?
> Nebenbei: wird bei einem Zeitvergleich eine zu große Abweichung > festgestellt, dann wird ausnahmsweise doch kopiert statt der > Schneller/Langsamer-Methode, unter Inkaufnahme ausgefallener > Schaltvorgänge.) Das beantwortet dann meine Frage. Hatte vorhin noch nicht soweit gelesen.
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.