Hallo, ich habe ein Problem mit meinem Projekt. Ich baue mir momentan eine Binäruhr, wobei noch ein DCF-Modul von Conrad angeschlossen ist. Die Uhr zählt wunderbar im Sekundentakt hoch. Mithilfe von Tastern habe die korrekte Anzeige der Sekunden, Minuten und Stunden getestet (also ob einzelne Zahlen korrekt angezeigt werden und ob bspw. bei 60 Minuten die Minutenanzeige auf 0 zurückgesetzt und die Stundenanzeige um 1 hochgezählt wird etc.). Nun habe ich aber das Problem, dass die empfangene Zeit anscheinend nicht korrekt interpretiert wird (also wahrscheinlich ein SW-Problem). Mithilfe eines einfachen ATTiny-USB-Oszilloskops habe ich bereits ausprobiert die gesendete Zeit "per Hand" zu interpretieren und ich konnte bis auf die Minute genau die gegenwärtige Zeit "entschlüsseln". Was mich aber nun ein wenig irritiert ist die Tatsache, dass die Uhr mir sehr oft bis fast immer eine der folgenden Zeiten anzeigt: 0:48, 8:48, 9:48 Uhr...immer mit einer Uhrzeit mit 48 Minuten. Dieses Verhalten konnte ich schon zu verschiedenen Tageszeiten feststellen... Auch ist anzumerken, dass diese Uhrzeit manchmal schon gesetzt wurde, als die gegenwärtige Uhrzeit laut Atomuhr/uhrzeit.org ungefähr bei 40 Sekunden, also das DCF-Signal nicht vollständig war. Manchmal erhalte ich die korrekte Zeit, auf die Sekunde genau, wobei es auch danach noch passieren kann, dass er sich eine der oben genannten Zeiten "einfängt". Ich habe mal meinen Code angehängt, da ich davon ausgehe, dass es ein Softwarefehler ist. Verwendete Software: Atmel Studio 6.0.1843 WinAVR Kit (2010.01.10) zum Flashen Verwendete Hardware: Flasher/Programmer: USBASP Selbstbau (fischl.de) ATMega8A-PU mit 4MHz Quarzoszillator (HFuse C9/LFuse 80) und 100nF an VCC/GND (könnte es sein, dass ich "mehr" brauche??) LED-Anzeige: 7 LEDs mit einem 74LS373 (jeweils für Stunden (hier natürlich nur 6 LEDs), Minuten, Sekunden) Strom per USB am Laptop Ich hoffe ich konnte mein Problem ausführlich und verständlich beschreiben und würde mich freuen, wenn mir jemand einen Tipp bzw. am besten die Lösung des Problems geben kann. MfG Maximilian W.
Irgendwo '0' anstatt 0? Und auf welche Detenobjekte muss atomar zugegriffen werden? Auf garkeine? Unwarscheinlich wenn ich den Code so überfliege...
Dir klar, dass dein Code höchst ineffiezient ist? Du verwendest zum Speichern der DCF Bits ein char Array der Länge 60. Das sind 60 Byte. Benötigen tust du effektiv 8. Mit Single Quotes setzt du die Variable auf den Wert, welchen das Zeichen gemäß ASCII hat. 0 hat dabei den Wert 48, also den von dir oft beobachteten Wert. Verwende stattdessen die numerischen Literale 0 und 1. Schaue dir vielleicht mal ein paar entsprechende Beispiele an, welche du hier im Forum findest.
Hallo nochmal, Dopplereffekt schrieb: > Dir klar, dass dein Code höchst ineffiezient ist? Du verwendest zum > Speichern der DCF Bits ein char Array der Länge 60. Das sind 60 Byte. > Benötigen tust du effektiv 8. Hab ich mir auch schon überlegt, aber ich habe mich einfach erstmal an das Beispiel vom "DCF77-Funkwecker mit AVR"-Artikel gehalten. Dort wird auch nur ein DCF-Array der Größe 60 erstellt. Unnötig, aber es funktioniert... Johann L. schrieb: > Und auf welche Detenobjekte muss atomar zugegriffen werden? Auf > garkeine? Unwarscheinlich wenn ich den Code so überfliege... OK...hab alle unnötigen volatile Zusätze entfernt... Dopplereffekt schrieb: > Mit Single Quotes setzt du die Variable auf den Wert, welchen das > Zeichen gemäß ASCII hat. 0 hat dabei den Wert 48, also den von dir oft > beobachteten Wert. > > Verwende stattdessen die numerischen Literale 0 und 1. Stimmt...warum hab ich das nicht schon früher gesehen.... Aber das löst das Problem leider nicht...nun kriege ich ständig die Uhrzeit 0:00, 0:01, 1:00 oder 1:01... Dennoch verstehe ich nicht, woher die 48 (0)/49 (1) kamen/kommen, da ich keine Zahlen in ASCII-Form direkt mit Werten in Zeitvariablen vermische. Worauf ich nochmals hinweisen möchte, ist das Problem, dass diese Zeit manchmal auch mitten in einer Minute gestellt wird, also unabhängig vom gesendeten Signal, da ich lediglich in einer Methode die Zeit setzen lasse, und das auch nur wenn min. 1,25s kein Signal empfangen und das 59. Bit erreicht wurde (also die 59. Sekunde in einer Minute). Ich bin im Moment sehr verwirrt.... :-S Ich habe nochmals meinen momentanen Code hochgeladen. MfG Maximilian W.
nimm mal das Programm der DCF Uhr von Ulrich Radig. Findet man über Google
Maximilian W. schrieb: > Dennoch verstehe ich nicht, woher die 48 (0)/49 (1) kamen/kommen, da ich > keine Zahlen in ASCII-Form direkt mit Werten in Zeitvariablen vermische. Vermutlich doch. Entweder Du schreibst außerhalb der Arraygrenzen. Oder Du gibst Variablen aus dem Array aus. Vermutlich kann current_bit Werte >59 annehmen und Du prüfst es nicht vor dem Schreiben. Beachte, daß externe Signale gestört sein können, d.h. Du mußt sie prüfen, bevor sie was im SRAM zerstören. Meine DCF77 Routine wertet daher die Bits in "echter" Echtzeit aus und ignoriert alle Anzahlen außerhalb 59. Peter
Meine Uhr hatte das DCF Signal so oft empfangen, bis zwei Empfangsrunden zueinander plausibel sind (also genau 1 Minute Differenz). Die Paritäts-Bits alleine reichen zur Kontrolle nicht aus.
Hallo mal wieder... ich habe mittlerweile die Uhr zum Laufen bekommen. Ich lasse nun, wie Peter Dannegger gesagt hat, die DCF-Werte, sofort nachdem Empfangen der Bits, interpretieren. Zusätzlich habe ich auch einige andere Fehler ausgemerzt. Um einige dieser Fehler zu finden, habe ich nun UART zur Hilfe genommen. Ich habe einfach bei bestimmten Stellen "print"-Befehle gesetzt und konnte so genau verfolgen, wie alles genau abläuft. Das einzige Problem, das ich nun noch habe, ist die Tatsache, dass die Uhr recht lange zum Empfangen der richtigen Zeit braucht. Danach läuft sie aber problemlos und setzt auch keine falsche Zeit. Ich habe nochmals meinen Code (einmal mit UART Befehlen und einmal ohne) hochgeladen, für den Fall, dass es vielleicht jemandem hilft oder es jemanden interessiert... :) MfG Maximilian W. PS: Das Timing für die Erkennung der Einsen und Nullen des DCF-Signals kann bzw. sollte wahrscheinlich noch angepasst/verbessert werden. PPS: Danke an alle, die mir geholfen haben...
Stefan Frings schrieb: > Meine Uhr hatte das DCF Signal so oft empfangen, bis zwei Empfangsrunden > zueinander plausibel sind (also genau 1 Minute Differenz). Damit verschenkst du eine ganze Menge an Empfindlichkeit, weil jeder Datensatz, bei dem auch nur ein Bit gestört ist, sofort verworfen wird. Viel besser steht man dar, wenn man Korrelationen aufeinanderfolgender Minutentelegramme analysiert, so dass einzelne Bitfehler auf Grund fehlender Korrelation zu vorherigen Telegrammen unter den Tisch fallen. Damit läßt sich, unabhängig vom Minutenimpuls, auch der Minutenanfang anhand sich nicht ändernder Bits gut erkennen.
Michael A. schrieb: > Damit verschenkst du eine ganze Menge an Empfindlichkeit, Nö. Die üblichen Empfänger haben einen recht abrupten Übergang von störfrei zu völlig unbrauchbar. Der Gewinn an etwas größerer Reichweite durch Korrelation ist daher nur minimal und kaum merkbar. Das lohnt den ganzen SW-Aufwand nicht. Deutlich mehr Effekt hat man durch eine bessere Entstörung. Z.B. schalte ich den MAX7219 für die Multiplexanzeige jede Nacht kurz mal ab und dann ist der Empfang o.k. Mit Anzeige ist am Empfängerausgang nur wildes Geflacker der Impuls-LED. Auch hilft etwa 20cm Abstand zwischen Antenne und Anzeige, aber ich wollte beides in einem Gehäuse haben. Peter
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.