Moin, ich habe mir heute einige DCF77-Beispielcodes angesehen. Unter anderem unterscheiden sie sich darin, dass einige das DCF-Signal als externen Interrupt verwenden und mit einem Timer dann die Impulsbreiten bestimmen, andere arbeiten mit einem Timerinterrupt alle 10ms und lesen den Datenpin dann ein. Ich finde den Artikel hier nicht mehr, meine aber gelesen zu haben, dass eine der beiden Varianten technisch gesehen nicht schön ist. Warum weiß ich leider auch nicht mehr.... Kann das jemand bestätigen oder irre ich mich da?
Das Problem mit dem externen Interrupt kommt dann, wenn dein Empfang schlecht ist. Dann flutest du den µC mit Interrupts. Aber selbst bei gutem Empfang musst du sowieso Filtermassnahmen vorsehen, denn guter Empfang bedeutet nicht notwendigerweise, dass die Rechteckspannung da reinschnurrt, wie frisch gelackt. Wenn du aber sowieso einen Timer brauchst um die Pulslänge festzustellen, dann kannst du auch gleich mit der Timer-Polling Methode arbeiten. Manchmal ist es vernünftiger, wenn man die Dinge gar nicht so genau wissen will und nicht jede einzelne Flanke mitkriegen will. DCF ist an und für sich einfach auszuwerten. Kompliziert wird es erst, wenn man auch noch mit schlechten Empfangsbedingungen klar kommen will oder muss.
Ok, das kann ich nachvollziehen :-) Danke für die Antwort! Also ist dieses: DCF77-Funkwecker mit AVR Projekt dann nicht so gut, weil es den externen Interrupt nutzt? Timer-Interrupt wird aber auch genutzt. Kann hier leider nicht 100% alles verstehen, wie das Programm arbeitet. Hier gefällt es mir aber, dass es einen Plausibilitätscheck gibt..... Kannst Du trotzdem kurz schreiben, was die Interrupts hier machen?
Hallo Mike. Welche Prog. Sprache? Natürlich sind im DCF77 „Sendepaket“ nicht nur Zeit und Datum enthalten. Die Auswertung was du benötigst, macht deine Software. Die Impulsbreiten auszuwerden ist ja auch nur eine Art Timerinterrupt. Hoffe deine Anfrage richtig verstanden zu haben. Mit freundlichen Grüßen Fred
:
Bearbeitet durch User
ich nutze PeDa (Dannegger) Tasterentprellung bulletproof im 10ms Timer, da kann ich auch gleich die DCF Pulse einsammeln, 5-12 wären eine 0 und 13-22 eine 1 die ich an PeDa DCF77 void scan_dcf77( void ) weiterleite klappt ganz gut
Mike Richard schrieb: > Also ist dieses: DCF77-Funkwecker mit AVR Projekt dann nicht so gut, > weil es den externen Interrupt nutzt? Timer-Interrupt wird aber auch > genutzt. Kann hier leider nicht 100% alles verstehen, wie das Programm > arbeitet. Dann häng dich rein. Die für den DCF Empfang wichtigen 2 Interrupt Service Routinen sind ja überschaubar kurz. Kurz: der externe Interrupt ist dafür zuständig den Anfang eines Pulses zu detektieren. Ab da beginnt die Zeit zu laufen. Mit dem Timer Interrupt wird dann in regelmässigen Abständen nachgesehen, ob der Eingang noch auf 1 liegt oder schon auf 0 abgefallen ist. Die auf diese Art festgestellte Pulslänge erlaubt dann die Aussage, ob der Puls eine logische 1 oder eine logische 0 darstellen soll. Das funktioniert soweit sicherlich, solange es keine Störungen gibt. Wie gesagt: Häng dich rein. Du willst das bauen, dann ergründe auch wie es funktioniert. So lernt man. Kümmere dich erst mal nicht darum, was die einzelnen 0-en und 1-en bedeutet. Denn erst mal musst du diese 0-en und 1-en haben. Genau darum geht es in diesen beiden ISR, die da zusammenspielen.
:
Bearbeitet durch User
Fred R. schrieb: > Welche Prog. Sprache? Hi. Ich möchte einen AVR in C programmieren. Die Lib sollte dann entsprechend auch in C sein und möglichst leicht verständlich. Ich möchte keine Arduino-Labs verwenden, ohne genau zu sehen, was passiert. Deshalb dieses Mal auch „richtige“ Programmierung eines AVR mit Atmel Studio, ohne die Arduino-IDE und Bootloader etc. Ich weiß, dass es 59 Bit gibt, wovon nur ein Teil interessiert. Das 0. Bit ist eine Pause und zeigt den Start des Signals. Da mein AVR auch eine eingebaute RTC hat, kann der Controller per Timer (wenn ich es richtig verstanden habe auch sehr genau durch die 32kHz-Zeitbasis und entsprechende Teiler) die Uhrzeit weiterzählen, wenn kein Funk-Signal vorhanden ist. Es soll ein ATmega328P werden. Später soll es dann in etwa folgende Anwendung geben: Batteriebetrieb, also möglichst viel Strom sparen, da wo es nur geht. Wenn er AVR einmal eine genaue Zeit hat, soll er einen Timer laden, so dass er um beispielsweise 16:00 Uhr aufwacht. Dann erfolgt eine neue Synchronisierung. Zwischen 17:00 Uhr und 18:00 Uhr erfolgen verschiedene Schaltvorgänge der Ausgänge zu vorher genau definierten Sekunden. Um 18:10 Uhr ist das Programm zu ende. Neuberechnung der Wartezeit bis 16:00 Uhr am nächsten Tag, Timer entsprechend laden und Tiefschlaf, bis der Timer einen Interrupt auslöst, und den AVR aufweckt. Danach wieder DCF-Synchronisierung etc. Ich hoffe, das ist einigermaßen verständlich beschrieben. Meint ihr, das ist mit dem ATmega328 ohne weiteres möglich?
Ja. Aber du solltest die Synchronisation nachts machen. Erstens ist der Empfang besser, es sind weniger Monitore, Energiesparlampen usw. in Betrieb. Außerdem passiert nachts zwischen 2 und 3 die Sommer-/Winterzeitumstellung. Wenn du kurz nach 3 Uhr synchronisierst, hast du fast lückenlos die richtige Uhrzeit.
Ok, also schicke ich den AVR in den Tiefschlaf, bis der Timer nachts um kurz nach 3 Uhr aufgeweckt wird um sich mit DCF77 zu synchronisieren. Dann geht er wieder schlafen, bis es 17 Uhr ist. Wenn er dann aber aufwacht (weil der Timer einen Interrupt ausgelöst hat), habe ich dann noch die genaue Sekunde? Ich müsste die Ticks ja weiter zählen. Der Boot-up dauert ja aber auch etwas. Ist dann nicht alles verschoben?
Hallo Mike, ein ATmega328P macht dies locker. Leider kann ich hier nicht mehr weiter helfen. Eine Lösung mit Bascom/ASM könnte ich Punkt genau anbieten. Mit freundlichen Grüßen Fred
Mike Richard schrieb: > Ok, also schicke ich den AVR in den Tiefschlaf, bis der Timer nachts um > kurz nach 3 Uhr aufgeweckt wird um sich mit DCF77 zu synchronisieren. > Dann geht er wieder schlafen, bis es 17 Uhr ist. Wenn er dann aber > aufwacht (weil der Timer einen Interrupt ausgelöst hat), habe ich dann > noch die genaue Sekunde? Ich müsste die Ticks ja weiter zählen. Der > Boot-up dauert ja aber auch etwas. Ist dann nicht alles verschoben? also ich nutze immer eine RTC DS3231 aus China unter 2,- die kann über INT und Alarmregister den Atmel aufwecken um 3:00 Uhr und um 17:00 Uhr wenn du das wünschst, spart den 32kHz Quarz, ermöglicht tiefere sleep modi am Atmel, nach dem DCF Sync kann man doch noch die RTC stellen, die DS3231 laufen auch genauer und stabiler als die DS1307 Module, die SW ist nahezu gleich, DS1307new LIB läuft, der DS3231 muss nicht gestartet werden es gibt auch kein stop command, da beide I2C Adressen gleich sind ist der Unterschied leicht festellbar, der eine hat 56Byte RAM wenn der Chip auf Adresse 0 ansprechbar ist ist einer von beiden vorhanden, der DS3231 liefert auf RAM Ende einen Fehler weil er nicht soweit reicht ohne die 56 Byte.
:
Bearbeitet durch User
eagle user schrieb: > Außerdem passiert nachts zwischen 2 und 3 die > Sommer-/Winterzeitumstellung. Wenn du kurz nach 3 Uhr synchronisierst, > hast du fast lückenlos die richtige Uhrzeit. Ja, fast. Noch besser wäre es bei Normalzeit um 1:00 Uhr, und bei Sommerzeit um 2:00 Uhr zu synchronisieren. Und ja, es wird eine Kennung mitgesendet, anhand derer man erkennen kann, ob es sich bei der ausgestrahlten Zeitinformation und Normal- bzw. Sommerzeit handelt. In der Stunde vor der Zeitumstellung wird die Umstellung durch ein entsprechendes Bit, das gesetzt wird, angekündigt. Der Empfänger hat dann eine Stunde lang Zeit, diese Information zu empfangen und kann die korrekte Zeit direkt nach der Umstellung anzeigen. Und nicht erst eine Stunde später. Joachim B. schrieb: > also ich nutze immer eine RTC DS3231 Ich halte das für etwas übertrieben: man programmiert einen µC als Uhr und hängt dann noch zusätzlich einen Uhrenbaustein an den Controller.
John schrieb: > Joachim B. schrieb: >> also ich nutze immer eine RTC DS3231 > > Ich halte das für etwas übertrieben: > man programmiert einen µC als Uhr und hängt dann noch zusätzlich einen > Uhrenbaustein an den Controller. kannst du sehen wie du willst, ich kann die Uhr auch mal vom Netz nehmen oder µC Batterie wechseln oder den µC dauerhaft schlafen schicken bei geringstem Verbrauch, die RTC kostet ja praktisch nix extra und läuft auch weiter wenn der µC pennt oder keine Versorgung hat und vereinfacht vieles in der Hardware, 32kHz Quarz, die Programmierung, das ständige Aufwecken. PS. DCF77 Empfang ist hier sowas von mies da ist man froh wenn der einmal in der Woche sich syncronisiert, es lief auch schon mal 4 Wochen ohne Sync.
:
Bearbeitet durch User
Wenn du nur eine genaue Zeit möchtest, dann gab es bei www.robotikhardware.de mal das IC ICDCFRS als Artikelnummer oder die Bezeichnung DCF-RS232-Wandler DCF-RS1. nach meinen kurzen Recherchen gibt es diesen Lieferanten leider nicht mehr, was ich schade finde. Aber das deutsche Steuerwesen killt jedes Startup-Unternehmen Dieses IC wandelt die DCF-Daten von einem DCF-Empfänger so um, dass man mit einem kleinen Bascomprogrämmchen die genaue Zeit bekommt, RTC inkusive. Falls du aus eigenem Interesse das Signal selbst auswerten möchtest, dann ist mein Posting obsolet. Möchtest du jedoch nur die genaue Zeit haben, dann google mal nach den oben genannten Artikelnummern oder Bezeichnungen. Selbst auswerten ist jedoch eine lehrreiche Herausforderung mit Lerneffekt, wie schon oben geschrieben.
Mike Richard schrieb: > Ich finde den Artikel hier nicht mehr, meine aber gelesen zu haben, dass > eine der beiden Varianten technisch gesehen nicht schön ist. Techische Sichtweisen haben keinen Bedarf an "Schönheit". Alles, was da zählt, ist Zweckmäßigkeit. Und diese Zweckmäßigkeit ergibt sich, wen wundert's, aus dem Zweck der Sache. Im konkreten Fall: Wenn der einzige Zweck die Decodierung des AM-Signals von DCF77 ist, dann ist triviales Polling mit relativ großer Abtastrate die beste und einfachste Lösung. Und alle Typen, die schon glücklich sind, so eine triviale Aufgabe (meist mit geklautem Code) gelöst bekommen zu haben, werden dir versichern, dass solche ein Polling das einzig Wahre ist. (Weil man damit auch viele Probleme umgeht, die sie völlig unfähig wären zu lösen...) Diese Typen glauben dann, "ihre" (meist geklaute) Lösung wäre "schön". Damit könnte man ja noch gut leben. Das Problem mit diesen Spassten ist allerdings: Sie halten alles andere (was sie nicht brauchen oder erst garnicht begreifen oder zumindest nicht umsetzen können) für "unschön" und tönen das dann auch noch laut heraus (weil sie sonst ja ihre ohnehin minimale Eigenleistung noch weiter entwerten würden).
Mike Richard schrieb: > Ich finde den Artikel hier nicht mehr, meine aber gelesen zu haben, dass > eine der beiden Varianten technisch gesehen nicht schön ist. Nur mit externem Interrupt wird es umständlich, d.h. man braucht eh noch den Timerinterrupt mit dazu. Und da ist es eben einfacher, gleich im Timerinterrupt abzutasten und sich den externen Interrupt ganz zu sparen. Und bei gestörtem Signal kann es schnell zu mehr als 59 Flankeninterrupts kommen, was man wieder abfangen muß oder man riskiert bei unüberlegtem Programmaufbau einen Pufferüberlauf. Auch hatten früher MCs oft nur 2 externe Interrupts, die man sich dann besser für wirklich eilige Sachen aufgespart hat.
:
Bearbeitet durch User
Je nach Empfängerschaltung kann der Externe Interrupt bei Funkstörungen sehr viele Interrupts verursachen. Oft verhidnert dies aber auch schon die Hardware im Empfänger. Man kann aber auch den externen Interrupt nutzen und dann ggf. den Interrupt abschalten, wenn man sowieso kein Signal erwartet oder haben will. Da ist polling im 10 ms Raster deutlich einfacher. Wie man am besten Auswertet hängt auch davon ab wie gut der Empfang ist, bzw. wie viel Aufwand man treiben will, um auch noch ein schlechtes Signal zu erkennen. Man kann einiges gewinnen, wenn man ausnutzt das die Pulse genau in 1 Sekunden Takt kommen. Für den Anfang der Pules kann man also eine Art Fehlertolleranten software PLL nutzen - Störpulse irgendwo dazwischen kann man so gut ignorieren.
Mike Richard schrieb: > andere arbeiten mit einem Timerinterrupt alle 10ms und lesen > den Datenpin dann ein Zur DCF-Decodierung verwende ich einen Timerinterupt von 20msec zur Abtastung des Zeitsignals. Ausgemessen werden nur die Zeiten in denen der DfC sendet, nicht aber die Austastzeiten. Das vereinfacht die Decodierung des Zeitsignals. Zur Störimpulsunterdrückung ist ein sehr einfacher Softwarefilter vorgeschaltet. Midestens 3 Abtastungen müssen gleich sein, bevor eine Änderung des DCF-Sinals erkannt wird. Funktioniert seit Jahren ohne Probleme. Allerdings ist der DCF-Sender auch nur ca. 30km von meinem Wohnort entfernt.
Alex D. schrieb: > Allerdings ist der DCF-Sender > auch nur ca. 30km von meinem Wohnort entfernt. Da reicht doch schon ein Detektor mit LED ohne Stromversorgung. Ein morsegeübter Amateurfunker kann sicherlich dann die Zeit direkt an der LED ablesen. :-)
Ein morsegeübter Amateurfunker kann sicherlich dann die Zeit direkt an der LED ablesen. :-) Stimmt fast so, allerdings geht es auch ohne Morseübung. Ohne Quatsch, wir haben es probiert und es hat geklappt!
eagle user schrieb: > Außerdem passiert nachts zwischen 2 und 3 die > Sommer-/Winterzeitumstellung. Wenn du kurz nach 3 Uhr synchronisierst, > hast du fast lückenlos die richtige Uhrzeit. Dass die Zeit umgestellt wird, weiß er aber um 16:00 auch schon. Dafür gibt es ein Bit, welches das vorher ankündigt. Wenn das gesetzt ist, weiß er, dass er in der nächsten Nacht von Sa auf So um 1:00 UTC umschalten muss. Welche Zeit (MEZ oder MESZ) aktiv ist, weiß er auch. Mike Richard schrieb: > Die Lib sollte dann > entsprechend auch in C sein und möglichst leicht verständlich. Ich > möchte keine Arduino-Labs verwenden, ohne genau zu sehen, was passiert. > Deshalb dieses Mal auch „richtige“ Programmierung eines AVR mit Atmel > Studio, ohne die Arduino-IDE und Bootloader etc. Also Du möchtest eine fertige lib benutzen, aber aus dem selben Grund möchtest Du genau den Arduino NICHT benutzen!? Wenn Du es selbst machen möchtest, wirst Du keine Lib benutzen. Das geht mit dem Arduino allerdings genau so. Mike Richard schrieb: > Das 0. Bit ist eine Pause und zeigt den Start des Signals. Eigentlich fehlt die 59. Sekunde. Die 0. Sekunde ist vorhanden und damit startet das Zeittelegramm. Mike Richard schrieb: > Timer entsprechend laden und Tiefschlaf, bis > der Timer einen Interrupt auslöst, und den AVR aufweckt. Das wirst Du mehrfach machen müssen. Ein Timerüberlauf wird nicht lang genug sein. Aber kein Problem. Du hast ja die Zeit. Mike Richard schrieb: > Meint ihr, das ist mit dem ATmega328 ohne weiteres möglich? Das ist auch mit dem ATmega48 ohne weiteres möglich. Es sei denn Du hast so viele Schaltvorgänge, dass dadurch der Programmspeicher platzt. Gruß Jobst
Jobst M. schrieb: > Dafür gibt es ein Bit, welches das vorher ankündigt. Aber nur eine Stunde lang. Wenn die Uhr um drei zurueckgestellt wird, wird das 16:00 Uhr noch nicht gesendet.
Kempra schrieb: >> Dafür gibt es ein Bit, welches das vorher ankündigt. > Aber nur eine Stunde lang. Wenn die Uhr um drei zurueckgestellt wird, > wird das 16:00 Uhr noch nicht gesendet. Oder die Uhr selbst ausrechnen lassen: Ist es März und der letzte Sonntag im Monat und 2 Uhr dann auf 3 Uhr und Sommerzeit umstellen. Ist es Oktober und der letzte Sonntag im Monat und Sommerzeit dann um 3 Uhr auf 2 Uhr und Winterzeit umstellen. Dann stimmt die Uhrzeit und es ist egal wann wieder synchronisiert wird. Gruß Alex
Jobst M. schrieb: > Also Du möchtest eine fertige lib benutzen, aber aus dem selben Grund > möchtest Du genau den Arduino NICHT benutzen!? > > Wenn Du es selbst machen möchtest, wirst Du keine Lib benutzen. Das geht > mit dem Arduino allerdings genau so. so mache ich das, Arduino und die DCF77 von Dannegger im Code, so lerne ich auch andere Wege zu sehen und zu verstehen, habe aber die DCF77 Auswertung schon vor 15 Jahren am PC programmiert auf meine Weise Alex D. schrieb: > Oder die Uhr selbst ausrechnen lassen: > > Ist es März und der letzte Sonntag im Monat und 2 Uhr dann auf 3 Uhr und > Sommerzeit umstellen. > > Ist es Oktober und der letzte Sonntag im Monat und Sommerzeit dann um 3 > Uhr auf 2 Uhr und Winterzeit umstellen. ist auch in meinem AVR NetIO Pollin in der Software und nun im Arduino wordclock
Hallo, Autor: Joachim B. schreibt. PS. DCF77 Empfang ist hier so was von mies da ist man froh wenn der einmal in der Woche sich synchronisiert, es lief auch schon mal 4 Wochen ohne Sync. Meine bescheidene Erfahrung. Es ist immer eine Aufbausache. DCF77 baue ich als ortveränderliches Modul mit nachgeschalteter Leistungsstufe auf. Sind auch Leidungslängen zum MC bis 10 Meter kein Problem. Somit ist die beste Ausrichtung zum Sender möglich. Optimum zeigt eine LED an. Autor: c-hater schreibt. Techische Sichtweisen haben keinen Bedarf an "Schönheit". Alles, was da zählt, ist Zweckmäßigkeit. Und diese Zweckmäßigkeit ergibt sich, wen wundert's, aus dem Zweck der Sache. Meinung ist OK. Hier gehst du zu weit. Das Problem mit diesen Spassten ist allerdings: Sie halten alles andere (was sie nicht brauchen oder erst garnicht begreifen oder zumindest nicht umsetzen können) für "unschön" und tönen das dann auch noch laut heraus (weil sie sonst ja ihre ohnehin minimale Eigenleistung noch weiter entwerten würden). Nicht alle die hier helfen wollen, sind Superexperten wie DU. Meine zuverlässige und bewährte Lösung ohne externem Interrupt und mit Entscheitung wann synchronisiert werden soll, wage ich nicht mehr zu Veröffentlichen, nutze eine Lib die nicht auf meinem „Mist“ gewachsen ist. Eine kleine Eigenleistung für Lösung ist schon dabei. Mit freundlichen Grüßen der Spasster Fred
Fred R. schrieb: > Meine bescheidene Erfahrung. Es ist immer eine Aufbausache. DCF77 baue > ich als ortveränderliches Modul mit nachgeschalteter Leistungsstufe auf. > Sind auch Leidungslängen zum MC bis 10 Meter kein Problem. davon habe ich genau ein Modul gebaut im extra case und dient zur Überprüfung, mein Ziel ist es trotzdem das kompakt ins Gerät zu bekommen. Bei meinem Bruder im 3ten Stock oberstes funktioniert es ja auch, nur in meinem Wohnzimmer nur mit dem abgesetzen Modul, am Gerät nicht und auch am abgesetzten Modul klappte es nicht wenn das wUSB aktiv ist. Ich forsche jetzt mal weiter auf der Stromversorgung, logisch das Batteriegeräte weniger Probleme haben.
Wenn Du Empfangsprobleme hast, lies Dir mal diesen Thread durch: Beitrag "DCF Empfang und Schaltnetzteil"
Carsten W. schrieb: > Wenn Du Empfangsprobleme hast, lies Dir danke, ich hatte zwar schon mal Filter in der VCC, aber noch nicht die Zeit dort den Oszi anzuklemmen, ich denke ich muss mich mal wirklich um den Zusammenhang VCC vs. Störungen im Signal kümmern.
Hallo Joachim B Zitat: mein Ziel ist es trotzdem das kompakt ins Gerät zu bekommen. Dies wird nie eine sichere Lösung sein. Manchmal sind nur sehr kleine Positionsänderungen nötig, um ein „sauberes Signal“ zu bekommen. Beispiel: Im Keller hatte ich kein Problem(trotz Stahlbetondecke) mit der „Güte“. Außerhalb schon. Hatte ja auch DCF im Gerät eingebaut. Gerät nur einige cm umgestellt. Signal war ausreichend aber konnte nichts mehr auf Display sehen. Ist doch Dumm oder? So kam ich auf Idee DCF77 als eigenständiges Modul aufzubauen. Nun kann ich das Modul optimal ausrichten für zuverlässigen Empfang. PS. DCF77- Modul funktioniert nun auch beim Freund in Polen. Wie bekann nicht so nah zu Frankfurt. Mit freundlichen Grüßen Fred
Du willst es nur Sekundengenau? - Dann reicht eine vernünftig programmierte Polling-Methode. Du willst Strom sparen? - Dann lass die Synchronisierung um 16:45 Uhr laufen, von 17:00 bis 18:00 wird der Fehler nicht so groß. Bei halbwegs gutem Empfang ist da auch ein Plausibilitäts- Test etc... in den 15 Minuten bis 17:00 kein Problem. Oder lass das Projekt einfach sein, wenn du nicht weißt, wie du das überhaupt bewerkstelligen kannst.
Wenn ich mit der Pollingmethode synchronisiert habe, kenne ich zwar die genaue Uhrzeit, das Weiterzählen passiert dann aber durch den 32 kHz-Takt. Ich kann da nicht beeinflussen, wann die Flanke kommt und ob sie deckungsgleich mit der detektierten 1. Sekunde (nach der Pause als Signalstart) kommt. Ich möchte aber auch den Start der neuen Sekunde möglichst genau haben. Muss ich dann zusätzlich mit dem internen Quarz arbeiten, um einen Offset oder sowas zu erstellen? Oder ist es möglich, den Uhrenquarz "anzuhalten" und mit der genauen Sekundenflanke zu synchronisieren? ICh meine nicht, da er ja auch eine Einschwingzeit hat und sich erst stabilisieren muss.
Mike Richard schrieb: > Oder ist es möglich, den Uhrenquarz "anzuhalten" nutzt dir nix Mike Richard schrieb: > und mit der genauen > Sekundenflanke zu synchronisieren? du weisst doch erst wenn du in der nächsten Sekunde bist ob die vorige 100ms oder 200ms mit 800-900ms Ruhe kam einfach nur so kann es ein Störimpuls gewesen sein
Mike Richard schrieb: > Oder ist es möglich, den Uhrenquarz "anzuhalten" und mit der genauen > Sekundenflanke zu synchronisieren? Was hast Du denn bitte vor? Den Fehler des Empfängers so gut es geht zu syncronisieren? Die Empfänger haben häufig sehr schmale Filter (~10Hz Bandbreite), damit wird der Impuls vorne und hinten sowieso um bis zu 100ms verschliffen. Um den Bruchteil von 1/32768s braucht man sich dann auch keine Gedanken mehr zu machen. Gruß Jobst
Wenn die nullte Sekunde detektiert wird (steigende Flanke nach mindestens 1.8 Sekunden Ruhe) muss der Zähler des Sekunden-Timers zurückgesetzt werden. Ich glaube, das war mit Sekundensynchronisierung gemeint.
Lumi schrieb: > (steigende Flanke nach > mindestens 1.8 Sekunden Ruhe) muss der Zähler des Sekunden-Timers > zurückgesetzt werden. Ich glaube, das war mit Sekundensynchronisierung > gemeint. das wäre aber Minutensynchonisierung für mein Verständnis ;-)
Der Timerinterrupt tastet z.B. mit 10ms ab und bildet gleichzeitig den Vorteiler 1:100 für die interne Uhr. Bei einem gültigen Paket wird der Vorteiler zurück gesetzt, d.h. der Softwarefehler beträgt <10ms. Der Fehler des Empfangsmoduls wird aber deutlich größer sein. Früher waren auch die Fernsehuhr bzw. der Piepton im Radio sehr genau. Heutzutage bei digitalem oder Kabel-Empfang gehen die aber erheblich nach. Wenn man z.B. ein UKW-Radio über Antenne oder Kabel anhört, sind da mehrere Worte Laufzeitunterschied.
Peter D. schrieb: > Der Timerinterrupt tastet z.B. mit 10ms ab und bildet gleichzeitig den > Vorteiler 1:100 für die interne Uhr. > Bei einem gültigen Paket wird der Vorteiler zurück gesetzt, d.h. der > Softwarefehler beträgt <10ms. > Der Fehler des Empfangsmoduls wird aber deutlich größer sein. Wenn die Laufzeit des Empfangsmoduls bekannt ist, lässt sich diese in etwa auch noch ausgleichen. Möchte man zum Beispiel 30msec Laufzeit kompensieren, einfach den Vorteiler auf 3 setzen.
Wenn man will, kann man auch die ICP Funktion des µC nutzen, um die Quatisierung auf die z.B. 10 ms vom Polling zu umgehen - viel nutzen wird es aber vermutlich nicht. Bei den meisten Emfpangsmodulen hat man in der Flanke oft schon Unsicherheiten von einigen 10 ms. Man kann zwar mitteln, aber der Fehler kann z.B. von der Signalstärke abhängen. Da kommt es dann auch auch auf die Empfängerschaltung an. Als ersten Schritt kann man aber schon die Syncronisation der Sekunden nicht nur an einer Flanke machen, sondern etwa über die 59 Pulse einer Minute mitteln. Wenn die den wirklich im den ms Bereich gehen will, müsste man ggf. schon die Phasenmpdulation auswerten und kann entsprechend kein einfaches Emfangsmodul mehr nutzen. Das ist dann von der Tendenz her auch keine super sparsame Schaltung mehr. Das ginge dann mehr in Richtung Software defined radio - da wird die Auswertung dann schon recht anspruchsvoll und könnte mehr als den AVR vertragen. Über den Tag bräuche man dann ggf. auch so etwas wie einen TCXO oder wenigstens ein Temperaturkompensation in Software. Abweichungen in der Absoluten Frequenz des 32 kHz Quarzes kann man in der Software berücksichtigen, etwa bei der Umrechnung Quarz-zyklen in Uhrzeit.
Mir geht es nur um die genaue Sekunde. Wenn ich Funkuhr auf einer Webseite mit meiner gekauften Hardwarefunkuhr abgleiche, stelle ich fest, dass der Sekundenwechsel gleichzeitig statt findet. Eine halbe Sekunde versatz würde ich merken, 10 Millisekunden sicherlich nicht mehr so gut. Brauche ich aber auch nicht. Ich habe nicht daran gedacht, dass ich bei jedem Timertick nur 1/32768 s weiterzähle. Hatte mir den Timertick erst sekündlich vorgestellt, was dann dazu führen würde, dass ich eben einen Hardwareversatz von bis zu einer Sekunde habe. So ist der Hardwareversatz ja nur max. 1/32768 s Bin fälschlicherweise davon ausgegangen, weil ich bei 32,768 kHz immer von der guten Teilbarkeit zu einer Sekunde gedacht habe (per Fuse-Bit-Teiler), aber das kann ja per Software gemacht werden. (Wobei ich dann vielleicht Overflow-Probleme des Timers bekomme ;-)....
Wenn es hier um Auswertemethoden geht, sollte man sich mal vor Augen halten, was physikalisch vorhanden ist und was man haben will. In den allermeisten Fällen ist es ausreichend, wenn man die Uhrzeit auf 0,1 s genau hat. Das funktioniert mit Polling im 10 ms Takt sehr gut. Zwischen 120 und 180 ms (12...18 Takte) nach der aktiven Taktflanke detektiert man den Bitwert: NULL ist nach 100 ms zu Ende, EINS erst nach 200 ms. Die Dekodierung betrachtet auch die Parity-Bits UND vergleicht jedes neue Telegramm mit dem zu erwartenden Telegramm. Dazu ist natürlich auch die SZ/WZ- und die Schaltsekunden- Ankündigung zu betrachten. Jetzt kommen hier Schlaumeier und verkünden: - Eine Laufzeit vom Sender zum Empfänger von 30 ms! Quatsch! Die Laufzeit ist max 5 ms im Empfangsbereich von 1500 km. Innerhalb Deutschlands weniger, als 3 ms. - "wird der Impuls ... um bis zu 100ms verschliffen" Quatsch! 5...15 ms bei den üblichen billigsten Empfängern. Somit ist man bei 10 ms Pollrate auf 0,03 s genau. Wer sich etwas Mühe macht und den Externen Interrupt angemessen einsetzt (Zeitfenster) und dazu einen halbwegs genauen Quuarz spendiert, kann seine DCF-Uhr auch auf wenige ms genau machen.
Angehängte Dateien:
-
DCF.png
8,2 KB
Oldie schrieb: > Jetzt kommen hier Schlaumeier und verkünden: > - "wird der Impuls ... um bis zu 100ms verschliffen" > Quatsch! 5...15 ms bei den üblichen billigsten Empfängern. Was sind bei dir die üblichen Empfänger? Hast du nachgemessen? Ich habe gerade gemessen: Kanal 1: demoduliertes DCF-Signal (700 Hz - von diskret aufgebautem Empfänger) Kanal 2: Empfänger von Reichelt Kanal 3: Empfänger von Conrad -> Reichelt: ca. 22 ms -> Conrad: ca. 25 ms Dein Bereich von 5…15ms liegt um 46…400% daneben. Zwischen den Modulen von Conrad und Reichelt existiert ein Jitter von knapp 5ms. Welches Modul diesen Jitter verursacht hab ich nicht geprüft.
P.S.: Ich möchte noch erwähnen, dass ich hier sehr guten DCF-Empfang habe, mit wenig Störungen. Bei schlechtem Empfang dürfte das Signal deutlich mehr „verschliffen“ sein.
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.