Hallo, ich habe in den Weihnachtsferien mal mein altes Pollin DCF1 Empfangsmodul ausgegraben und wollte mal wieder mit meinem Arduino spielen. Wie so vielen hier im Forum erging es mir ähnlich: Empfang extrem schlecht oder gar nicht möglich. Nachdem keines der zahlreichen Codebeispiele so recht wollte, habe ich mich auf Fehlersuche begeben und mein DSO an den Signalpin gehangen. Ich habe dabei festgestellt, dass ich in der perfekten Lage sehr wohl ein Signal empfange, dieses aber irgendwie kein richtiges Rechtecksignal ist, sondern permanent einbricht. Ich sehe also schon im Sekundenabstand ein kürzeres oder etwas längeres Rechteck (100 bzw. 200ms) aber dies ist nicht einfach nur eine Flanke sondern ein permanentes auf- und ab. Ich habe mal ein kurzes Video gemacht, indem man das genau sehen kann: https://drive.google.com/open?id=1lYz2oRW_rzeU9yF2HrZlNJzOtU81m6i9 Hat jemand eine Idee wodurch das kommen kann? Ich bin Elektronik-technisch Laie. In einem Post hatte ich gelesen, dass der C zwischen VCC und GND nötig wäre, weil die Spannung u.U. einbricht, wenn der IC das Signal ausgibt. Ist es das was ich hier beobachte? Kann man das vielleicht irgendwie "glätten", so das die schnellen Auf- und Ab gar nicht bis zum AVR durchschlagen? Wie würde man das machen? Angeschlossen ist das Modul an 3,3V vom Arduino, einn 100nF C verbinden VCC und GND Pin, PON habe ich erst auf VCC, dann nach 1000ms auf GND gelegt, damit das Modul los legt... Es ist das "neue" Modul mit verschrumpfschlauchter Spule. Arduino hing bislang am PC via USB (Stromversorgung), aber auch bei autarker Stromversorgung tritt das Problem mitunter auf. Ich habe keinen Pullup-Widerstand o.ä. verwendet, weil die Meinungen dazu divergieren und ich mir nicht sicher bin, ob dieser in meiner Version notwendig ist. Ich habe viel im Forum über die Empfangsprobleme gelesen und vermutlich ist meinem Haus ein ziemliches HF Chaos was WLAN, LEDs, Netzteile, usw. betrifft. Das der Empfang also generell mies ist, ist sehr plausibel. Das sehe ich auch am DSO. Teilweise reicht eine winzige Veränderung und ich habe nur noch ein "Dauerrauschen" im Signal, dann eine weitere winzige Veränderung und ich kriege zumindest annäherend wieder das Rechtecksignal. Wie man im Video auch sieht ist es aber abgesehen von der groben Form auch nie perfekt sondern man sieht immer mal wieder einen kurzen Spike auch zwischen den Pulsen. Ist dies ein Problem? Wenn ich das Signal mit festen Zeiten abtaste eher nicht, wenn ich es über Interrupts bei steigender Flanke mache, dann schon, oder? Danke für Eure Mühe.
Markus D schrieb: > Hat jemand eine Idee wodurch das kommen kann? Du hast Störquellen in der Nähe. Oft wird der Empfang schon sehr viel besser, wenn man den Empfänger mit einer eigenen Batterie versorgt und möglichst weit weg von anderen elektrischen Geräten aufstellt, also mindestens 2 Meter. Ja, je mehr wir uns mit Elektronik umgeben, desto schwieriger wird es, einen geeigneten Standort zu finden. > Angeschlossen ist das Modul an 3,3V vom Arduino Schon falsch. Die DCF Module brauchen eine Aal-glatte Versorgungsspannung. Ich benutze gerne eine LED mit Vorwiderstand, um stabile 2 zu erhalten. Diese dann noch mit einem 100nF Kondensator und einem 100µF Elko stabilisieren. Aber probiere das erst einmal mit einer Batterie aus. Das ist nämlich die beste Option. Verschwende keine Zeit damit, irgendwelche Peaks im Ausgangssignal zu filtern. Wenn die Stromversorgung gut ist und der Empfang ausreichend, dann kommt da ein top sauberes Rechteck-Signal raus.
Danke für den Hinweis mit der Versorgungsspannung. Dass heisst, dass ist die wahrscheinlichste Ursache für mein Problem? Weil die 3,3V im Arduino (vermutlich?) auch über eine PWM erzeugt werden? Und deswegen pulst dann auch automatisch das Ausgabesignal? Ist das so richtig verstanden? Dann probiere ich das mal mit meinem Labornetzteil aus, damit sollte es dann ja nicht mehr passieren? Ich habe mir das vor einiger Zeit zugelegt und extra auf ein linear-geregeltes Netzteil wert gelegt und nicht auf ein Schaltnetzteil. Das sollte dann genau so etwas verhindern? Wie meinst Du bitte Deinen Satz "Ich benutze gerne eine LED mit Vorwiderstand, um stabile 2 zu erhalten. Diese dann noch mit einem 100nF Kondensator und einem 100µF Elko stabilisieren.". Sprichst Du da dann doch wieder von einem Arduino oder einer ähnlichen Stromquelle? Könntest Du bitte kurz mal aufzeichnen wie Du das meinst mit dem zweiten Elko? Wo genau der hin soll usw. Vielen Dank!
Markus D schrieb: > Dann probiere ich das mal mit meinem Labornetzteil Stefan ⛄ F. schrieb: > DCF Module brauchen eine Aal-glatte > Versorgungsspannung. Dann nimm besser gleich eine Batterie wie beschrieben, um zu sehen ob es an der Spannung liegt.
Markus D schrieb: > Das der Empfang also generell mies ist, ist sehr plausibel. Vielleicht. Der Sender steht auf den sauren Wiesen am Main etwas südlich von Frankfurt. Wie weit bist du davon entfernt? Hier laufen auch ein paar solcher Geräte, aber ich kann hier in 160km Luftlinie, mit einem größeren Ferritstab, wie er in Radios verwendet wurde, das Signal des DCF77 direkt auf dem Scope sehen.
Angehängte Dateien:
So, habe nun sowohl mal mit dem Labornetztel und 2xAA Batterien getestet. In beiden Fällen hatte ich kein ständiges Auf/Ab mehr. Somit scheint dieses Fehlerbild tatsächlich an der Spannungsversorgung über den Arduino zu liegen. Vielen Dank für diesen Hinweis, das hätte ich nicht rausgefunden. Auch wenn der "normale" Rechteck jetzt sauber ist - das Signal in Gänze ist es überhaupt nicht.... Siehe Screenshots... Man kann die 1s Pulse erkennen, aber alles dazwischen sollte da ja eher nicht sein... Können das wirklich alles Störungen sein? Das ist ja beängstigend ;-)
Markus D. schrieb: > .. Können > das wirklich alles Störungen sein? Das ist ja beängstigend ;-) Warte mal die im Datenblatt erwähnten 20 Minuten ab. Vielleicht hat sich das digitale Filter dann eingeschwungen.
Markus D schrieb: > Das der Empfang also generell mies ist, ist sehr plausibel. Kann ich nicht bestätigen. Ich wohne gut 300km vom Sender entfernt. Ein Billigmodul hängt im Keller an der Wand und empfängt einwandfrei. Auch die Armbanduhr mit ihrer Miniantenne hat guten Empfang.
Markus D schrieb: > PON habe ich erst auf VCC, dann nach 1000ms auf GND Ich habe das alte Modul: Pon kann dauerhaft auf GND gelegt werden. Ein Impuls ist nicht notwendig. Das Modul reagierte allergisch auf jede Art von Belastung am Ausgang, auch auf den eingeschalteten Pullup-Widerstand vom Mikrocontrollereingang. Ansonsten wurden bei meinem Modul die Impulse bis zur Undekodierbarkeit verändert. Die von mir verwendete Anschaltung ist zu finden unter: Beitrag "[Bascom/AVR] Uhr und DCF" Das Modul braucht einige Minuten zum "einpendeln". Gruß Alex
OK, ich werde morgen nochmal einen Test machen und länger warten. Ich wohne in der Nähe von München. Grundsätzlich funktionieren natürlich auch hier Funkuhren (g). Also: Der eigentliche Anlass des ganzen Themas war, dass unsere Wetterstation TFA Nova seit einiger Zeit irgendwie so gar nix mehr anzeigt, weder Uhrzeit noch Wetter, egal ob die Batterien neu waren oder nicht. Neue Batterien waren innerhalb von 1 Woche leergelutscht. Hin und wieder hat sie auch total gesponnen und einfach alle Symbole im Display angezeigt oder ist regelrecht abgestürtzt. Zuerst habe ich geprüft, ob sie vlt. einen Schaden genommen hatte, weil sie mal vom Küchenregel gefallen war. Beim Aufschreiben war aber kein direkter Schaden erkennbar. Dann dachte ich: OK, vlt. ist der Empfang einfach inzwischen ***** aufgrund von LEDs, WLAN, Bluetooth und was man sonst noch alles im modernen Smarthome so hat ;-) Das ist, möchte ich betonen, nach wie vor immer noch meine stärkste Vermutung! Nicht, dass jemand meint, diese Konsequenz wäre mir nicht bewusst! Es ist nur so, dass sich das hier ja nicht von heute auf morgen so stark verändert hat, und die Uhren "irgendwann" immer mal sich synchronisiert haben. Auch die erwähnte Nova hat an einem 2m entfernten Aufstellort nun wieder etwas empfangen und auf einma laut Anzeige nun auch wieder am ursprünglichen Aufstellort ein gutes Signal. Mal sehen wie lange das hält! Kurzum: Ich wollte die Gegenprobe machen und habe mich erinnert, dass ich noch so ein altes DCF77 Modul rumliegen habe, welches ich auch schon mal vor einigen Jahren erfolgreich am AVR zum fliegen brachte (damals allerdings kein Arduino, sondern ein Plain ATmega8 und Batteriebetrieb, wie mir nun wieder einfällt!) Ich wollte nun einfach nur für mich sehen, quasi als kleines Weihnachtsurlaubsprojekt, ob ich das noch hinkriege mit dem Empfang und war nun also leidlich überrascht, dass es so überhaupt nicht gelingen wollte mit den eingangs erwähnten Problemen (dass auch das Rechteck selbst kein sauberes Rechteck ist, sondern eben aus 100ten von Auf und Ab "gebildet" wurde). Dieses Problem scheint nun Dank Verzicht der Spannungsversorung aus dem Arduino geklärt. Jetzt wäre einfach die Frage: Ist der Empfang WIRKLICH so grottig wie er auf den Bildern ersichtlich ist, oder kann es ggf. noch ein anderes Problem sein - - - oder muss ich einfach wirklich die 20min abwarten :-D Wie gesagt, das werde ich morgen mal checken. Noch eine Frage zu: "Das Modul reagierte allergisch auf jede Art von Belastung am Ausgang, auch auf den eingeschalteten Pullup-Widerstand vom Mikrocontrollereingang. Ansonsten wurden bei meinem Modul die Impulse bis zur Undekodierbarkeit verändert. " Das heisst, wenn ich am Arduino einfach nur D2 via pinMode(2,INPUT) als Eingang definiert habe und dort mittels digitalRead(2) zyklisch den Wert gepollt habe, könnte dies auch das Verhalten erklären? Ich habe auch Artikel gefunden, dass man noch einen 10k Pull-Up Widerstand gegen VCC schalten soll auf dem Steckbrett, der wäre aber wohl NUR bei der alten Version nötig und ich habe ja die neue mit dem Schrumpfschlauch? Zudem habe ich die letzten Versuche auch ganz ohne Arduino-Beteiligung nur mit dem Oszi gemacht...
Markus D schrieb: > Es ist nur so, dass sich das hier ja nicht von heute auf morgen so stark > verändert hat, und die Uhren "irgendwann" immer mal sich synchronisiert > haben Da reicht schon wenn das Ladegerät vom neuen Handy Mist macht und schon ist unter Umständen in mehreren Metern Umgebung Essig mit DCF77. Das geht schneller als man denkt. Ob ein Problem darauf beruht lässt sich am allereinfachsten dadurch testen das Gerät ins Auto zu packen und so weit weg von Störquellen wie mir möglich zu fahren:)
"Vielleicht hat sich das digitale Filter dann eingeschwungen." Was genau wird denn da in dem IC dann vor sich gehen? Ich vermute mal, er wird einen Wert verändern und messen, wie sich dann die Spannung ändert, und darüber selbständig versuchen das Maximum zu finden? Welchen Wert kann der IC denn aktiv (per Software) verändern? Ich hatte jetzt soweit verstanden, dass der Schwingkreis vor allem durch L und C bestimmt ist, und beides ist ja fest vorgegeben, oder?
Markus D schrieb: > Das heisst, wenn ich am Arduino einfach nur D2 via pinMode(2,INPUT) als > Eingang definiert habe und dort mittels digitalRead(2) zyklisch den Wert > gepollt habe, könnte dies auch das Verhalten erklären? Leider kann ich deine Frage nicht beantworten. Ich hatte mein Modul wegen seiner Zickerei schon in den Abfall geworfen, aber dann nochmal herausgeholt und mit der beschriebenen Anschaltung probiert. Das Modul war etwa 2 Meter vom Rest der Schaltung entfernt und zum DCF ausgerichtet, danach hat alles funktioniert. Natürlich gibt es auch andere gute Möglichkeiten der Anschaltung. Es war nur ein Vorschlag, mit meinem Modul hat es halt funktioniert.
Markus D. schrieb: > Man kann die 1s Pulse > erkennen, aber alles dazwischen sollte da ja eher nicht sein.. Dann nimm zum groben Test ein Taschenradio mit MW od. LW und laufe mal durch die Wohnung. In den letzten Jahren hat sich durch Schaltnetzteile und LED-Lampen usw. ein Haufen Störer eingeschlichen. Evtl. fällt Dir was auf? Sonst lies mal genauer das pdf der PTB dort. https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77.html
Markus D schrieb: > Das heisst, wenn ich am Arduino einfach nur D2 via pinMode(2,INPUT) als > Eingang definiert habe und dort mittels digitalRead(2) zyklisch den Wert > gepollt habe, Falsche Herangehensweise. Pollen ist in dem Fall der falsche Weg. Auch Arduino kennt interrupts ;)
Manuel X. schrieb: > Auch Arduino kennt interrupts Für den Empfang von DCF Signalen sind Interrupts weder nötig noch empfehlenswert, weil das Signal beliebig verzerrt sein kann. Schlimmstenfalls führt der µC gar keinen normalen Code mehr aus, weil er permanent mit Interrupts beschäftigt ist.
> Dass heisst, dass (Stromversorgung) ist die wahrscheinlichste Ursache für mein Problem? Ja > Weil die 3,3V im Arduino (vermutlich?) auch über eine PWM erzeugt werden? Wie kommst du darauf? Ich weiss nicht wie du die Stromversorgung deines Arduino Boardes realisiert hast. Wenn es ein Schaltnetzteil ist, hat es etwas mit Modulierten Impulsen zu tun. Das ist aber nicht die Problemursache. Die 3,3V werden durch die ganzen Verbraucher (z.B. dem Mikrocontroller) nicht gleichmäßig sondern Impulsweise belastet, daher sind sie nicht absolut stabil. > Und deswegen pulst dann auch automatisch das Ausgabesignal? Das Ausgangssignal ist mehr oder weniger Zufällig, solange der Empfang nicht funktioniert. Das Signal von der Antenne ist nur ganz schwach, weniger als 1mV. Es kann nur zuverlässig erkannt werden, wenn sämtliche Störungen (auch die der Stromversorgung) so wirksam unterdrückt werden, dass sie geringer sind, als das eigentliche Nutzsignal dass du empfangen willst. > Ich habe mir das vor einiger Zeit zugelegt und extra auf ein linear-geregeltes Netzteil wert gelegt und nicht auf ein Schaltnetzteil. Das sollte dann genau so etwas verhindern? Ich kenne die Eigenschaften von deinem Netzteil nicht. Lineare Regelung ist kein Garant für topsaubere Ausgangsspannung. Deswegen sollst du mit einer Batterie testen. > Wie meinst Du bitte Deinen Satz "Ich benutze gerne eine LED mit Vorwiderstand...
1 | Netzteil 1kΩ LED grün |
2 | 5-16V o-----[===]---+---|>|----+-----| GND |
3 | | | |
4 | +----||----+ 100nF |
5 | | | |
6 | +----||----+ 100µF |
7 | | | |
8 | o o |
9 | 2V GND |
10 | DCF Empfänger |
An der LED fällt eine fast konstante Spannugn von ca. 2V ab. Schwankungen der Spannung vom Netzteil gut unterdrückt. Die beiden Kondensatoren bilden zusammen mit dem Widerstand einen Tiefpass, der Hochfrequente Störungen heraus filtert. > Können das wirklich alles Störungen sein? Ja > Das ist ja beängstigend Finde ich nicht. Ich fürchte mich mehr vor besoffenen jungen Männern und dummen Politikern in zu mächtigen Positionen. > Es ist nur so, dass sich das hier ja nicht von heute auf morgen so stark verändert hat Es können unsichtbare Veränderungen/Defekte sein, deren Quelle direkt vor deiner Nase oder hunderte Meter entfernt ist. Funkwellen kannst du schließlich nicht spüren. > Ist der Empfang WIRKLICH so grottig wie er auf den Bildern ersichtlich ist, oder kann es ggf. noch ein anderes Problem sein Der Empfänger oder seine Antenne könnte defekt sein. Es nützt Dir aber nichts, jetzt über alle möglichen Problemursachen zu raten. Kläre die üblichen Ursachen ab: Stromversorgung und andere elektrische Geräte als Störquellen. > oder muss ich einfach wirklich die 20min abwarten Das sowieso. Der Empfänger braucht eine Weile, um sich auf das schwache Signal einzupendeln. Das ist in etwa so, als ob du im Schwimmbad jemanden belauschen willst, den du nicht sehen kannst. Auch da brauchst du eine weile, um diese eine Stimme aus den sonstigen Geräuschen heraus zu hören. > Das Modul reagierte allergisch auf jede Art von Belastung am Ausgang, > auch auf den eingeschalteten Pullup-Widerstand vom > Mikrocontrollereingang. Alle Module die ich kenne, konnten problemlos den internen Pull-Up Widerstand des AVR Mikrocontrollers antreiben. Ohne Pull-Up Widerstand können ihre Open-Kollektor Ausgänge auch gar nicht funktionieren. In der Beschreibung des Moduls sollte drin stehen, wie viele mA der Ausgang antreiben kann oder wie viel Ohm der Pull-Up Widerstand mindestens haben muss. Die internen vom AVR haben etwa 50kΩ. > Ich habe auch Artikel gefunden... Für welches DCF-77 Modul? Die sind nicht alle gleich aufgebaut! Manuel X. schrieb: > Da reicht schon wenn das Ladegerät vom neuen Handy Mist macht Oder ein verschlissener USB Stecker. > "Vielleicht hat sich das digitale Filter dann eingeschwungen." > Was genau wird denn da in dem IC dann vor sich gehen? Das ist Geheimnis des Herstellers des jeweiligen Moduls. Im Groben und Ganzen geht es darum, den Verstärker auf optimalen Pegel einzustellen und die Phasenlage des DCF-Signal zu ermitteln. Das braucht seine Zeit. Stelle Dir vor, du möchtest dem Ticken einer Wanduhr zuhören. Zuerst müssen sich deine Ohren auf feine tickende Geräusche einstellen, die man normalerweise zwischen all den anderen alltäglichen lauteren Geräuschen gar nicht wahrnehmen würde. Wenn du ein paar Ticks in Folge erkannt hast, bist du mit der Uhr Synchronisiert. Danach fällt es Dir ganz leicht, die weiteren Ticks zu hören, weil du schon vorher weißt, wann diese zu erwarten sind - vorausgesetzt dich stört niemand. In etwa das Gleiche passiert im DCF-77 Empfänger. Google nach PLL in Zusammenhang mit Radio-Empfängern, das ist ein interessantes Thema.
Manuel X. schrieb: > Falsche Herangehensweise. Pollen ist in dem Fall der falsche Weg. Hm, nee, pollen funktioniert super, es reicht sogar pollen im 20msec-Abstand. Der liebe CTC-Timer1 hilft mir dabei. Klappt seit Jahren ohne Probleme. Der Mikrocontroller hat dann noch jede Menge Zeit andere Dinge zu tun.
> Dann nimm zum groben Test ein Taschenradio mit MW od. LW und laufe mal > durch die Wohnung. In den letzten Jahren hat sich durch Schaltnetzteile Diesen Tipp habe ich in einem anderen Thread zu einem ähnlichen Thema auch bekommen. Mittelwelle geht laut Wikipedia von ca. 530 kHz bis ca. 1,7 MHz. Langwelle von 30 kHz bis 300 kHz. Wenn ich jetzt nur Mittelwelle habe - kann ich dann einfach auf z.B. das n-fache der 77,5 kHz am Radio tunen? Da gab es doch was mit den harmonischen Vielfachen einer Frequenz...? Waren das nicht die ungeraden Vielfachen der Grundfrequenz? Oder inwieweit kann mir ansonsten ein MW Radio hier helfen, wenn ddas DCF77 Signal dann ausserhalb des Frequenzbereiches ist? Einfach weil ein Störer dann auch höchstwahrscheinlich im MW Bereich ebenfalls stört, wenn er DCF77 stört? Also kein Match auf der gesuchten Frequenz, aber wenn man neben einem kaputten Netzteil steht sieht/hört man das dann trotzdem definitiv? Oder wie sonst? > Interrupts/Polling: Das mit den Interrupts war nur ein Beispiel: Ich habe viele Code-Varianten probiert, die aber alle letztendlich zum Scheitern verurteilt waren, nachdem ich mit dem Oszi gesehen habe, wie zerrupft das Signal wirklich aussah. > 3.3V Arduino, Wie kommst Du darauf?: Ehrlich gesagt, war das mit der PWM nur eine Vermutung, weil ich mir so noch am ehesten hätte erklären können, dass das High-Signal eine Folge von sehr schnellen Rechtecken war. Ich habe vorhin auch noch ein bisschen gestöbert und aber nichts weiter dazu auf den Arduino Seiten gefunden. Somit weiss ich nun nur, dass es wohl mit dem Arduino zusammenhängt, aber nicht warum dann das gesuchte Signal im Rauschnebel so aussieht, wie es aussieht (ich meinte damit, dass man die 1s-periodischen Rechtecke ja durchaus erkennen kannen, wenn man weiss wonach man sucht, sie aber im ursprünglichen Video zu diesem Post ja deutlich als schneles Auf-und Ab zu erkennen waren, was bei Batterie/Netzteil-Betrieb nicht mehr der Fall war. Das heisst, das eigentliche Problem ist, dass die Ausgangsspannung am 3.3V des Arduino aufgrund der prinzipiellen Arbeitsweise des MCs nicht ganz glatt ist und "irgendwie" führt das dann in dem DCF-Modul dazu dass der interne Signalgenerator, der das Rechteck für den TCO Pin erzeugt Amok läuft? > LED-Aufbau: Danke, das werde ich auch mal so versuchen. Das Modul braucht laut Datenblatt 3V (jedenfalls "Normal"), aber 2V sollten wohl auch gehen. Noch zu Deinem Schaubild: Du hast das Netzteil mit 5V-16V eingezeichnet. Wir sprechen hier aber von 3,3 bzw. 5V oder? Die beiden Cs machen ja aus 5-16V nicht auf einmal 2V? Zur Glattheit: Ich könnte nun also auch mal mit dem Oszi einfach an dem 3.3V Pin des MC messen und stark auf 3.3V reinzoomen. In dem Fall wäre die Erwartung, dass es dort stärker im Verhältnis zu Deinem Beispiel mit den 2V schwingt, richtig? Ist damit auch die "Restwelligkeit" gemeint, die man bei einem Netzteil in den technischen Angaben findet? >> Das ist ja beängstigend > Finde ich nicht. Ich fürchte mich mehr vor besoffenen jungen Männern und > dummen Politikern in zu mächtigen Positionen. LOL, Full ACK! :-D > 20min Wartezeit Danke für den Vergleich mit dem Schwimmbad. Das ist gut verständlich. Allerdings hätte ich jetzt vermutet, dass ich ein "besonderer" Zuhörer bin, weil ich ja ganz genau weiss wie hoch die Stimme ist (77,5 kHz). Trotzdem soweit anschaulich. Aber das heisst der IC auf dem Modul wird eine Art von Filter "über die Zeit" erstellen und versuchen selbständig die richtigen Flanken des Signals vs. Flanken des Noise zu identifizieren? Weiter unten schreibst Du nochwas bzgl. Phasenlage. Ist das damit gemeint? > Thema Pullups. Auf der Pollin-Seite (https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054) findet man aktuell auch noch das folgende Feedback: "Wenn man es endlich geschafft hat tut es gute Arbeit. Folgende Infos sind unbedingt nötig, um es zum laufen zu bekommen: - Man benötigt noch einen 10uF Elko.(nicht sicher, aber jetzt funktioniert es endlich, weshalb ich ihn nicht wieder abmache) - Man benötigt einen Comperator, zumindest softwareseitig, bei mir wurde Umin=2,58V, Umax=2,80V ausgegeben. Mein Adruino konnte das nicht als "digitalRead" verarbeiten, mit der Bib "analogComp" gings. -Der Signal-Pin (TCO) ist mit dem Signalabnehmer und einem 10K-Widerstand zu verbinden, dessen anderes Ende mit GND verbunden wird. Als ein PULL-DOWN(!!!!) Widerstand und nicht wie im Datenblatt direkt an den MCU. Bei mir hat ein Pullup nicht funktioniert. -Für besseren Empfang die Antenne "tangential" zu Frankfurt ausrichten. " Ich kann aber nicht beurteilen ob das korrekt ist. Fakt ist, ich habe bei mir einen 100nF C aus früheren Versuchen dran und das hatte ich auch gelesen, dass man den als Stützkondensator nutzen soll. Der Poster schreibt 10uF, also die 100-fache Kapazität? Komparator: Also bei mir ist es ein sauberes auf und ab zwischen 0 und VCC und nicht irgendwas zwischendrin... TCO: Also direkt an den Pin einen 10K Widerstand mit GND verbinden und dann aber auch direkt den Anschluss des MC dran? Dann muss ich im Arduino den Pullup ausschalten? > PLL: Danke, werde ich machen.
? Ich bin Elektronik-technisch Laie. In einem Post hatte ich..... Ohh jaaa.... Und viel Prosa
Markus D schrieb: > Die beiden Cs machen ja aus > 5-16V nicht auf einmal 2V? Nein, das macht die LED. Je nach Farbe liegt die Spannung zwischen 1,2V und 5V (siehe auch https://www.mikrocontroller.net/articles/LED).
Das alte Pollin Modul war dafür bekannt, das es einen sehr schwachen Ausgang hatte. Mehr als ein paar dutzend µA(!) konnte es nicht liefern. Am besten also direkt auf einen CMOS Eingang, wie z.B. den Analog Comparator und nur einen sehr hochohmigen Pullup verwenden (330k-1M)
Matthias S. schrieb: > Das alte Pollin Modul war dafür bekannt, das es einen sehr schwachen > Ausgang hatte. Mehr als ein paar dutzend µA(!) konnte es nicht liefern. > Am besten also direkt auf einen CMOS Eingang, wie z.B. den Analog > Comparator und nur einen sehr hochohmigen Pullup verwenden (330k-1M) Gibt Dir keine Mühe, habe ich heute auch schon geschrieben ... Jeder muß seine Erfahrungen selber sammeln ...
Mann, so'm Gezappel habe ich auch noch nicht auf 'nem DCF-Modul-Ausgang gesehen. Aber immerhin kann man die 100ms und 200ms Impulse sehen, nachdem das Modul anders versorgt wurde. Naja, vielleicht hilft ja Verstärker/Komparator. Das wäre aber doch mal was für das Korrelationsverfahren, oder?. Hat da Peter D. nicht mal was gepostet? War bestimmt mit vertikalen Zählern. Hi hi. :-)
Angehängte Dateien:
-
DCF-Antenne.jpg
49 KB
Hallo, ich habe einige DCF gesteuerte Uhren gebaut und zunächst auch ständig Probleme mit der Spannungsversorgung und Störungen gehabt. Ein 3,3V Spannungsregler und ein CMOS Schmitt-Trigger lösten die Empfangsprobleme. Schaltung siehe Anhang. Salu Hans
Mainflingen - Berlin sind über 400 km. Trotzdem geht hier jedes DCF-Modul - egal, ob Pollin/Conrad/Reichelt. Allerdings nicht in Stahl(beton)bauten, wegen der Abschirmung. Nahe an µC-Schaltungen gibt's Probleme wegen kräftiger Breitband- Störpegel. - Fast immer hilft der Anschluss des Moduls in >= 1 m Entfernung vom µC über ein geschirmtes Audiokabel mit 2 "Seelen". Schirm = Masse Seele 1 = V+ Seele 2 = DCF-Signal
Wenn du zu jeder Antwort so einen langen Roman schreibst mit mehreren Fragen zwischen den Zeilen, wird das Ganze hier sehr unübersichtlich. Konzentriere dich auf den kranken Baum, versuche nicht, den ganzen Wald zu untersuchen! > Wenn ich jetzt nur Mittelwelle habe - kann ich dann einfach auf z.B. das n-fache der 77,5 kHz am Radio tunen? Empfange irgendeinen Radiosender an einem Ort, wo ganz sicher keine Störungen sind. Dann gehe in deine Wohnung und höre, wo der Empfang am stärksten gestört wird. > Ich habe vorhin auch noch ein bisschen gestöbert und aber nichts weiter dazu auf den Arduino Seiten gefunden. Arduino will alles immer möglichst simpel halten, dort haben Infos zu Grundlagen keinen Platz. > Das heisst, das eigentliche Problem ist, dass die Ausgangsspannung am 3.3V des Arduino... nicht ganz glatt ist? Bis dahin ja. Beim hinteren Teil des Satzes hast du wieder phantasiert. Das Ausgangssignal des DCF-Modul stammt nicht von einem Rechteck-Generator, sondern vom Demodulator. > Du hast das Netzteil mit 5V-16V eingezeichnet. Wir sprechen hier aber von 3,3 bzw. 5V oder? Die beiden Cs machen ja aus 5-16V nicht auf einmal 2V? Erstens habe ich immer noch keine Ahnung, welche Komponenten du da verbaut hast, insbesondere was die Stromversorgung angeht. Zweitens: Schau mal in das datenblat einer grünen LED, da steht, welche Betriebsspannugn sie hat. Dann sollte Dir auch klar werden, welche Rolle der Widersdtand dabei hat. > Ist damit auch die "Restwelligkeit" gemeint, die man bei einem Netzteil in den technischen Angaben findet? Restwelligkeit ja, die kommt aber nicht nur vom Netzteil, sondern auch von den damit versorgten Bauteilen. Bedenke, dass jede Leitung einen gewissen Innenwiderstand hat (für HF sogar einen komplexen), so dass Schwankungen der Stromaufnahme Schwankungen der Spannung verursachen. Dein Mikrocontroller ist in CMOS Technologie aufgebaut, dass bedeuetet, dass er bei jeder Taktflanke Millionen Kondensatoren umlädt. Seine Stromaufnahme ist also sehr Sprunghaft. > Danke für den Vergleich mit dem Schwimmbad. Das ist gut verständlich. Allerdings hätte ich jetzt vermutet, dass ich ein "besonderer" Zuhörer bin, weil ich ja ganz genau weiss wie hoch die Stimme ist (77,5 kHz). Trotzdem soweit anschaulich. Aber im Schwimmbad befinden sich viele Personen mit ähnlicher Stimmlage, sowie zahlreiche lautere geräusche mit der gleichen Frequenz. > Auf der Pollin-Seite findet man aktuell auch noch das folgende Feedback... Das ist Quatsch, das Modul funktioniert ohne zusätzliche Beschaltung direkt an einem AVR Mikrocontroller - wenn die Spannungsversorgung stabil genug ist. > Ich kann aber nicht beurteilen ob das korrekt ist. Du hast doch ein Oszilloskop! Nurze es zum Messen. Das Modul braucht zwangsläufig einen Pull-Up Widerstand am Ausgang, weil der Ausgang Open-Kollektor ist (google danach). Du kannst mit dem Oszilloskop sowohl das Ausgangssignal als auch die Spannungsversorgung prüfen. Die Kapazität der Kondensatoren sind nur grob geschätzt (wie soll man auch exakt berechnen, ohne deine Schaltung zu kennen?), lieber mehr als zu wenig. > Also direkt an den Pin einen 10K Widerstand mit GND verbinden und dann aber auch direkt den Anschluss des MC dran? Dann geht gar nichts mehr. Wie gesagt brauchst du einen Pull-Up Widerstand. Der interne im AVR Mikrocontroller passt schon.
Alex D. schrieb: >> Am besten also direkt auf einen CMOS Eingang, wie z.B. den Analog >> Comparator und nur einen sehr hochohmigen Pullup verwenden (330k-1M) > > Gibt Dir keine Mühe, habe ich heute auch schon geschrieben ... > Jeder muß seine Erfahrungen selber sammeln ... Oh, das hatte ich übersehen. Naja, vllt. hält doppelt gemoppelt besser als nur einmal geschlumpft. Stefan ⛄ F. schrieb: > Wie gesagt brauchst du einen Pull-Up > Widerstand. Der interne im AVR Mikrocontroller passt schon. Da, schon wieder einer. Neien, der interne Pullup vom AVR ist viel zu niedrig.
:
Bearbeitet durch User
Matthias S. schrieb: > Da, schon wieder einer. Neien, der interne Pullup vom AVR ist viel zu > niedrig. Ich habe es doch mit genau diesem Produkt ausprobiert! Meine Uhr funktioniert und liefert top saubere Logikpegel unter Verwendung des internen Pull-Up Widerstandes vom AVR.
Stefan ⛄ F. schrieb: > Ich habe es doch mit genau diesem Produkt ausprobiert! Meine Uhr > funktioniert und liefert top saubere Logikpegel unter Verwendung des > internen Pull-Up Widerstandes vom AVR. Das kann ich so nicht bestätigen. Um "top sauberes" Signal zu bekommen ich habe den internen Pull-Up abschalten müssen. Kann es sein, dass DCF1 nicht gleich DCF1 ist? Ich habe das Modul 11/2018 bei Pollin gekauft.
Ozvald K. schrieb: > Kann es sein, dass DCF1 nicht gleich DCF1 ist? Bei Pollin würde das nicht ausschließen wollen. > Ich habe das Modul 11/2018 bei Pollin gekauft. Meine sind von November 2017. Sehen aus wie das Foto im Online-Katalog, aber die beiden Drähte von der Antenne zur Platine sind nur einfacher Kupferlackdraht.
Angehängte Dateien:
-
dcf1.jpg
100 KB
Stefan ⛄ F. schrieb: > die beiden Drähte von der Antenne zur Platine sind nur einfacher > Kupferlackdraht. Hier am Foto ist mein Modul zu sehen. Passt zu Deiner Beschreibung. (Nicht auf Design zu schauen, war nur "provisorisch" gemacht :-) )
Einen guten Rutsch ins Neue Jahr und alles Gute für alle ...
Ozvald K. schrieb: > Hier am Foto ist mein Modul zu sehen. Passt zu Deiner Beschreibung. Ja, sieht auch fast genau so aus - bei meinen ist die Spule mit Kleber statt Schrumpfschlauch fixiert.
Mir ist noch ein Unterschied aufgefallen: Bei meinem Modul baumelt oben drauf kein Quarz. Es sieht wie von Pollin dargestellt aus: https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054 Bis auf den klitze-kleinen Unterschied, dass das rote und schwarze Kabel bei mir einfacher Kupferlackdraht ist. Dieses Modul kann man definitiv direkt an AVR anschließen, unter Verwendung des internen Pull-Up Widerstandes im AVR.
Angehängte Dateien:
... keine Ahnung was jetzt auf einmal anders ist... Modul nochmal verkabelt. 2xAAA Batterie als Stromversorgung, 100nF zwischen VCC und GND. PON+GND von Anfang an verbunden. Am TCO PIN lediglich mein Oszi angeschlossen. Sofot nach dem Verbinden/Starten der Oszi-SW folgendes Signal glasklar am Oszi... Modul ist ja 1m vom Notebook mit aktivem WLAN und Bluetooth entfernt. WLAN Radio spielt fröhlich vor sich hin und auch ansonsten sind nicht wirklich weniger/andere Verbraucher aktiv als die letzten Tage... Sehr merkwürdig. Nun ja. Nun kann ich a) Meine Spielereien mit dem Arduino weitertreiben, b) Mich intensiver mit den vorgeschlagenen Analyze-Möglichkeiten bzgl. Signalempfang beschäftigen... Vielen Dank an alle für die hilfreichen Hinweise.
Markus D. schrieb: > keine Ahnung was jetzt auf einmal anders ist So soll es aussehen. Wie du siehst, sind komplexe Filter in Software überflüssig, wenn der Rest drumherum stimmt.
Markus D. schrieb: > ... keine Ahnung was jetzt auf einmal anders ist... > Modul nochmal verkabelt. 2xAAA Batterie als Stromversorgung, Anders ist die Stromversorgung, vorher 3.3V vom Arduino, jetzt an AAA-Batterien. Ein entscheidender Unterschied! Hatte man nicht mehrfach gesagt, dass die Stromversorgung perfekt sein muss?
Wenn ein DCF-Empfänger mit einem nicht geerdetem Schaltnetzteil versorgt wird, dann gibt das fast immer Ärger. Die Entstörbauteile im SNT sorgen meist dafür, dass sekundär alles schön mit 115Vss schwingt. Mit Batterieversorgung ist das alles weg und es läuft bzw. empfängt wie gold. Häufig reicht es, den ganzen Aufbau zu erden. Schaltungs GND hart an Steckdosen Schutzleiter.
Angehängte Dateien:
Carsten W. schrieb: > Wenn ein DCF-Empfänger mit einem nicht geerdetem Schaltnetzteil versorgt > wird, dann gibt das fast immer Ärger. Die Entstörbauteile im SNT sorgen > meist dafür, dass sekundär alles schön mit 115Vss schwingt. Mit > Batterieversorgung ist das alles weg und es läuft bzw. empfängt wie > gold. Häufig reicht es, den ganzen Aufbau zu erden. Schaltungs GND hart > an Steckdosen Schutzleiter. Full ack, sogar offizielle Bestätigung von Herstellerseite: ciao gustav
Matthias S. schrieb: > Das alte Pollin Modul war dafür bekannt, das es einen sehr schwachen > Ausgang hatte. Mehr als ein paar dutzend µA(!) konnte es nicht liefern. Auch die aktuellen Pollin-Module sind da nicht anders, auch die haben allesamt strommäßig wenig ergiebige PushPull-Ausgänge. Was sich gegenüber den alten geändert hat (allerdings schon vor etlichen Jahren) ist die Anschlussbelegung und die Tatsache, dass die Toleranz für 5V-Versorgung "verloren gegangen" ist, die die ganz alten Module noch hatten. > Am besten also direkt auf einen CMOS Eingang, wie z.B. den Analog > Comparator und nur einen sehr hochohmigen Pullup verwenden (330k-1M) Pullup braucht man garnicht, jedenfalls nicht für einen AVR-Eingang, selbst dann nicht, wenn der AVR mit 5V versorgt ist. Der High-Pegel der Pollin-Module genügt auch dann, um den ansonsten unbelasteteten AVR-Pin sicher auf High zu ziehen. Das gilt auch dann, wenn PON des Moduls High sieht. Der Ausgang bleibt in diesem Fall dauerhaft aktiv-High.
c-hater schrieb: > Auch die aktuellen Pollin-Module sind da nicht anders, auch die > haben allesamt strommäßig wenig ergiebige PushPull-Ausgänge. Auf dem gedruckten Waschzettel steht "sink / source >5µA", in dem von P* ladbaren pdf fehlt der Hinweis. Da das Modul also auch source sein kann, heißt das für mich, dass man es an einen 5V-µC nicht direkt anklemmen sollte. > Was sich gegenüber den alten geändert hat [..] > ist [..] dass die Toleranz für > 5V-Versorgung "verloren gegangen" ist, Jou: "Min. 1,2V / Typ. 3V / Max. 3,5V"
c-hater schrieb: > Pullup braucht man garnicht, jedenfalls nicht für einen AVR-Eingang, > selbst dann nicht, wenn der AVR mit 5V versorgt ist Ich finde alles was du geschrieben hast gut und richtig. Nur ein Punkt, die Spannung am nicht notwendigem Pull-Up Widerstand darf nicht über der Versorgunsspannung des Pollin-DCF liegen. Übrigens versorge ich meine Schaltung mit einem Schaltnetzteil, psst, leise, nichts laut sagen, bisher funktioniert es ohne Probleme.
Wenn man das DCF Modul mit weniger Spannung versorgt, als den Mikrocontroller, sollte ein simpler NPN Transistor dazwischen genügen.
Alex D., Markus D, Ozvald K. Ich muss mich bei euch entschuldigen, habe gerade einen knallroten Kopf. Und zwar habe ich oben mehrmals darauf bestanden, dass das Pollin Modul den Internen Pull-Up Widerstand des AVR antreiben kann und muss, weil es einen Open-Kollektor Ausgang hat. Das war ein Irrtum! Mein Gedächtnis hat mir einen Streich gespielt. Ich habe nochmal in den alten Quelltext der Uhr rein geschaut und muss zu meiner Schande gestehen, dass ich keinen Pull-Up verwendet habe. Beim Prototypen hatte ich das DCF Modul und den AVR beide mit 3,3V versorgt. Im finalen Aufbau hatte ich das Modul aber mit 2,2V versorgt. Wenn der AVR mit 5V versorgt wird, braucht man mit Sicherheit einen Levelshifter (z.B. NPN Transistor).
Nachdem ich gestern dann unten mit Batterie alles sauber am Empfang hatte, habe ich testhalber VCC nochmal an den Arduino gehangen (3,3V) und - ich verstehe es auch nicht - aber es ging immer noch alles perfekt. Signal war Rock Solid am Oszi zu sehen. Arduino war ca. 15cm vom Modul entfernt und ca. 70cm vom Notebook. Dann das Handy daneben gelegt - weiterhin perfekter Empfang. Schließlich habe ich oben im "Bastelzimmer" wo PC, WLAN, Homematic & Co durch die Gegend funken nochmal alles aufgebaut und... es hat weiterhin stabil funktioniert, dann und wann mal ein kurzer Zwischenpeak... Als ich dann aber mir mit den verschiedenen Arduino Sketches mir den Zustand auf UART ausgeben lies und das mit Putty vom PC zur Anzeige gebracht habe, hatte ich ab dem Moment wo sich Putty aufgeschalten hat auf dem Oszi nur noch Noise... Aha, also eine Störung durch den UART?! Bisschen das Modul gedreht, wurde marginal besser. Arduino abgesteckt, neu angesteckt... Ausgabe auf UART und auf einmal auch hier wieder sehr guter Empfang... Es bleibt irgendwie ein bisschen mysteriös. Wenn die Rätsels Lösung nun die Batterieversorgung gewesen wäre - alles klar, was gelernt, kann man sich merken... Aber nun geht es auch am Arduino und selbst dort wo es vorher nur Störungen gab... Trotzdem halte ich jetzt nochmal fest, wie am Ende das Modul zum Laufen gebracht wurde. Mein Modul dürfte übrigens von ca. 2010 sein. Zusammenfassung: Typ: Das "neue" DCF1 Modul (Antenne mit Schrumpfschlauch) Stromversorgung: 3V über AAA oder notfalls über 3,3V von Arduino Uno Stützkondensator: 100 nF zwischen VCC und GND direkt am Modul Aktivierung: PON wird dauerhaft auf GND gelegt. Es ist nicht notwendig erst PON auf VCC zu legen und dann auf GND Signal/Pullup: Der TCO PIN kann direkt mit einem Digital In PIN des Arduino verbunden werden (die meisten Programme im Web nutzen dafür Pin 2) Es ist kein extra Pullup Widerstand notwendig am Arduino. Der Pin wird via "pinMode(2,IN)" als Eingangspin konfiguriert. Wartezeit: Das Signal liegt sofort an, es scheint KEINE Einschwingzeit von bis zu 20min notwendig zu sein Ausrichtung der Antenne: 90° Richtung Sender, wie generell für Ferritantennen
Mikrocontroller versauen die Stromversorgung, und jede I/O Aktivität belastet die Stromversorgung und strahlt HF durch die Leitungen ab. Deswegen haben viele Mikrocontroller einen speziellen Betriebsmodus für analoge Messungen, wo genau diese Seiteneffekte während der Messung vermieden werden.
Angehängte Dateien:
-
MSF60_Zeit.jpg
80 KB
Markus D. schrieb: > Das Signal liegt sofort an, es scheint KEINE Einschwingzeit > von bis zu 20min notwendig zu sein Hi, das ist die Zeit, die eine Decodierung mit Plausibilitätskontrolle und diversen weiteren softwaremäßigen Checks in manchen Fällen benötigt. Die meisten Funkuhren im Handel nutzen das Prinzip der zunehmenden Skalenwerte zum check aus. Das heißt, die Zeit Minute 1 wird mit Zeit Minute 1+1 und mit Zeit Minute 1+2 verglichen und muss immer um eine Minute mehr anzeigen. Ist jetzt ein Störimpuls bereits im zweiten Check da, fängt die Kontrolle wieder von vorne an, bis wirklich drei Minuten hintereinander absolut störungsfreier Empfang möglich war. Das ist oft eben nicht so. Deswegen verzichtete ich bei meinem MSF60-Decoder ganz auf diese Kontrolle, sonst sehe ich mämlich unter Umständen stundenlang nichts. Nach einer Minute ist dann die Anzeige da. Allerdings nicht hundertprozentig korrekt. Das kann man als Funkuhrbesitzer nicht akzeptieren. Höchstens als Bastler. (Die in Code B gesendeten Paritybits können in meinem Programm bewusst nicht decodiert werden.) Der Begriff Einschwingzeit ist also in dem Datenblatt oben irgendwie unglücklich gewählt. Ein Quarzoszillator schwingt ein. Ein Oszillator beim µP bekommt ein paar ms zur Ausgabe eines sauberen in Amplitude und Phase stabilen Taktsignals spendiert. Da könnte man besser von "Einschwingzeit" sprechen. Wer hat das Datenblatt verfasst? An wen sendet man Verbesserungsvorschläge? Das mit den 3,3 Volt Versorgungsspannung hatte ich auch gelesen. Der Conrad Empfänger hat da einen Widerstand und eine Z-Diode für Betrieb an 5V. Das heißt, das eigentliche Modul läuft auch beim Conrad Empfänger mit nur 3 V. Hat aber Open Collector Transistoren am Ausgang. Wie das beim Pollin-Modul realisiert ist, kann ich nicht beurteilen, daher habe ich bislang meinen Senf dazu in der Tube belassen. ciao gustav P.S: Scheint ja auf Anhieb geklappt zu haben. Britische Zeit MEZ minus 1
:
Bearbeitet durch User
Karl B. schrieb: > ... Ist jetzt ein Störimpuls bereits im zweiten Check da, fängt die > Kontrolle wieder von vorne an, bis wirklich drei Minuten hintereinander > absolut störungsfreier Empfang möglich war. > Das ist oft eben nicht so. > Deswegen verzichtete ich bei meinem MSF60-Decoder ganz auf diese > Kontrolle, sonst sehe ich mämlich unter Umständen stundenlang nichts. > Nach einer Minute ist dann die Anzeige da. Allerdings nicht > hundertprozentig korrekt. Das kann man als Funkuhrbesitzer nicht > akzeptieren. Höchstens als Bastler. Wenn die Bitfehlerrate so hoch ist, dass der störungsfreie Empfang vollständiger Datentelegramme praktisch nicht statt findet, ist es vielleicht einmal Zeit, die Strategie der Auswertung zu ändern. Auf Grund des Telegrammaufbaus und der Ähnlichkeit aufeinander folgender Telegramme ist es doch gar kein Problem, statistische Methoden zur Erkennung von Bitfehlern zu nutzen und damit auch gestörte Telegramme sinnvoll auszuwerten. Vom Sender übertragenen Information von der Auswertung auszuschließen, kann dabei die Qualität der Auswertung nur verschlechtern. Oder geht es dir gar nicht um die bestmögliche Auswertung der übertragenen Information?
c-hater schrieb: > Der High-Pegel der > Pollin-Module genügt auch dann, um den ansonsten unbelasteteten AVR-Pin > sicher auf High zu ziehen. Bei mir auch.(Vcc=5,2V) Weil unsere AVRs besser als ihr Datenblatt sind. High >= 0,6 Vcc was bei 3 V grenzwertig ist. Markus D. schrieb: > eine Störung durch den UART?! Eine Masseschleife? Oder gleich die ganze Stromversorgung vom USB2TTL Modul dazugekommen?
:
Bearbeitet durch User
Angehängte Dateien:
-
DCF77_MSF60_Codes.png
17 KB -
MSF60_A_B_Codes.png
21 KB
Wolfgang schrieb: > Oder geht es dir gar nicht um die bestmögliche Auswertung der > übertragenen Information? Hi, der von mir verwendete MSF60-Decoder ist ein auf das primitivste umgestrickter DCF77-Decoder. Der MSF60-Sender strahlt ein Telegramm aus, das mehrere Unterschiede zum DCF77-Telegramm aufweist, das nach einem etwas aufwendigeren Decoderprogramm verlangt. Bei der Programmsuche im Internet hatte ich unter Stichwort "MSF60 in ASM" kaum etwas für mich wirklich Brauchbares gefunden. Entweder arbeiten die Programme nicht mehr auf der Attiny-Basis oder verlangen nach Interrupts und so weiter und so fort. Mit nur "einer" Flankenerkennung geht es nicht. Da bekommt man nur den A-Code decodiert. Und das habe ich gemacht. Mehr brauche ich nicht. War so wie so ein von vorne herein mit großem Fragezeichen versehenes Unterfangen, einen ca. 800 km entfernten Sender mit dazu noch geringerer Sendeleistung als DCF77 überhaupt in Decodierqualität empfangen zu können. Würde ich in England wohnen, wäre das schon eine ganz andere Geschichte. ciao gustav
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Wenn der AVR mit 5V versorgt wird, braucht man mit Sicherheit einen > Levelshifter (z.B. NPN Transistor). Man schließt ihn einfach an den analogen Komparator an, der vergleicht mit den 1,1V Band-Gap. Ein ADC-Eingang geht natürlich auch.
Karl B. schrieb: > Der MSF60-Sender strahlt ein Telegramm aus, das mehrere Unterschiede zum > DCF77-Telegramm aufweist, Und odd parity statt even. ciao gustav
Karl B. schrieb: > Der MSF60-Sender strahlt ein Telegramm aus, das mehrere Unter- > schiede zum DCF77-Telegramm aufweist, das nach einem etwas > aufwendigeren Decoderprogramm verlangt. Hat die Verwendung des MSF60-Senders denn irgendwelche Vorteile gegenüber dem DCF77, wenn man nicht in GB wohnt?
Es ist ein guter Brauch, jeder sollte mal ein DCF-Programm geschrieben haben. Mein Prog. zählt nur die Pausen aus. Der Zählerstand zeigt dann an, war es eine 1 (800msec), eine 0 (900msec) oder eine Pause (>1600msec). Vorgeschaltet ist ein einfacher "Filter" der eine Mindest-Impulsbreite verlangt. Getaktet wird das Empfangsprogramm mit einem auf 20msec eingestellten CTC-Timer. Dieser sorgt auch dafür, dass die Uhr bei Empfangsausfällen weiterläuft.
Harald W. schrieb: > Hat die Verwendung des MSF60-Senders denn irgendwelche Vorteile > gegenüber dem DCF77, wenn man nicht in GB wohnt? Just for fun. Why not? ciao gustav
Wolfgang schrieb: > Wenn die Bitfehlerrate so hoch ist, dass der störungsfreie Empfang > vollständiger Datentelegramme praktisch nicht statt findet, ist es > vielleicht einmal Zeit, die Strategie der Auswertung zu ändern. Ich würde eher dafür sorgen, dass der Empfang richtig funktioniert. Eine komplexe Fehlerkorrektur per Software funktioniert nur in einem ganz schmalen Bereich zwischen "geht" und "geht nicht".
Ich habe bei mir alle DCF77 Empfänger durch billige uBlox GPS Empfänger Nachbauten ersetzt. Wesentlich zuverlässiger und problemloser. Die mit der kleinen 5x10mm Antenne reichen dafür vollkommen.
Wilhelm M. schrieb: > Wesentlich zuverlässiger und problemloser Wenn du uns nun noch erklärst, wie das in Innenräumen funktioniert, sind wir glücklich.
Georg G. schrieb: > Wilhelm M. schrieb: >> Wesentlich zuverlässiger und problemloser > > Wenn du uns nun noch erklärst, wie das in Innenräumen funktioniert, sind > wir glücklich. Es geht einfach - wohl auch nur mit einem Satelliten ab und zu mal.
Allu schrieb: > Es ist ein guter Brauch, jeder sollte mal > ein DCF-Programm geschrieben haben. Schon lange her, sollte ich mal wieder tun :-) Stefan ⛄ F. schrieb: > Eine komplexe Fehlerkorrektur per Software > funktioniert nur in einem ganz schmalen Bereich > zwischen "geht" und "geht nicht". Man kann das Signal mit z.B. 5ms pollen und dann nach größer / kleiner entscheiden, ob high oder low. Danach verriegelt man für etwa 750ms, in dem Fenster hat nichts zu kommen. Hat sich bewährt, dass Schaltknackser und entfernte Gewitter nicht sofort zu Fehlauswertungen führen. Die Paritybits nimmt man mit, obwohl sie wenig taugen, man erkennt keine Doppelfehler. Am Ende eine mathematische Prüfung auf Minute = Minute + 1, dabei aber den Überlauf 59 -> 0 nicht vergessen und bei dem zusätzlich auf Stunde + 1 gucken. Um das perfekt zu machen, darf man noch auf die Ankündigungsbits für Sommerzeit und Schaktsekunde gucken. Ich stimme Dir aber zu, dass eine Korrektur zweifelhaft und kaum machbar ist. Wenn hier ein Fehler erkannt wird, zeige ich "Error" an und laufe frei weiter.
Stefan ⛄ F. schrieb: > Eine > komplexe Fehlerkorrektur per Software funktioniert nur in einem ganz > schmalen Bereich zwischen "geht" und "geht nicht". Das ist auch meine Erfahrung. Der erhebliche Mehraufwand an Software lohnt sich einfach nicht.
Wilhelm M. schrieb: > Georg G. schrieb: >> Wilhelm M. schrieb: >>> Wesentlich zuverlässiger und problemloser >> >> Wenn du uns nun noch erklärst, wie das in Innenräumen funktioniert, sind >> wir glücklich. > > Es geht einfach - wohl auch nur mit einem Satelliten ab und zu mal. Hier klebt eine GPS-Maus mit Magnet an der Unterseite von einem Etagenverteiler mit Switches und einem kleinen Server drin, in der hintersten Ecke mehr als 4 Meter vom Fenster, unter einem Blechdach. Geht einwandfrei. Ich glaube, es ist ein ublox-6 drin.
Karl B. schrieb: > Mit nur "einer" Flankenerkennung geht es nicht. Natürlich nicht. Die Daten bestehen jeweils aus zwei Bits mit Startbit und Stopbit, übertragen mit 10Bd. Bei DCF77 ist es nur ein Datenbit. Die Flanke des Startbits markiert den Sekundenanfang. > Bei der Programmsuche im Internet hatte ich unter Stichwort "MSF60 in > ASM" kaum etwas für mich wirklich Brauchbares gefunden. Dann muss man vielleicht mal selber eine Algorithmus in Code umsetzen.
Angehängte Dateien:
Wolfgang schrieb: > Dann muss man vielleicht mal selber eine Algorithmus in Code umsetzen. Ja, bin schon gespannt, wie Deine Lösung aussieht. Hoffentlich bist Du dann so nett, und hältst damit nicht hinter dem Berge. Manfred schrieb: > Man kann das Signal mit z.B. 5ms pollen und dann nach größer / kleiner > entscheiden, ob high oder low. Danach verriegelt man für etwa 750ms, in > dem Fenster hat nichts zu kommen. Hat sich bewährt, dass Schaltknackser > und entfernte Gewitter nicht sofort zu Fehlauswertungen führen. Die "Störaustastung" ist schon drin, allein schon deswegen, um die "Doppelflanken" bei A Code Low B Code High wegzubekommen. Sonst habe ich plötzlich Sekunde 63 in der Anzeige. Kann aber dann auch bei DCF77-Decodierung zur zusätzlichen Störaustastung dienen. Beitrag "MSF60 Dekoder AVR Teil_2" Und: Copyright bei Scott Falk Huehn. Habe Genehmigung des Autors zur Modifikation schriftlich eingeholt ciao gustav P.S.:Ist nicht die letzte Version. Manfred schrieb: > Wenn hier ein Fehler erkannt wird, zeige ich "Error" an und > laufe frei weiter. Bei mir bleiben dann die Sekunden stehen, das zeigt dann "keine Synchronisation mit DCF77"an (beim DCF77-Decoderprogramm, bei MSF60 ist das noch nicht drin, kann noch nachgeliefert werden, bin aber zu faul dazu jetzt.) Intern läuft Uhr auf dem Quarztakt weiter. Wilhelm M. schrieb: >> >> Wenn du uns nun noch erklärst, wie das in Innenräumen funktioniert, sind >> wir glücklich. > > Es geht einfach - wohl auch nur mit einem Satelliten ab und zu mal. Auch bei Schnee?
:
Bearbeitet durch User
Peter D. schrieb: > Stefan ⛄ F. schrieb: >> Eine >> komplexe Fehlerkorrektur per Software funktioniert nur in einem ganz >> schmalen Bereich zwischen "geht" und "geht nicht". > > Das ist auch meine Erfahrung. Ebenso bei mir. > Der erhebliche Mehraufwand an Software > lohnt sich einfach nicht. Das allerdings sehe ich ganz anders. Wenn zwei unglücklich gekippte Bits dafür sorgen, dass man auch nur ein einziges Mal im Jahr z.B. morgens um 2 (anstatt um 6) aus dem Schlaf geweckt wird, dann war das für mich eine absolut hinreichende Motivation, dem Teil eine sinnvolle "temporale Fehlerkorrektur" zu spendieren. Und wenn die sich wirklich darauf beschränkt, einige (sehr wenige) Bitfehler korrigieren zu können, ist der Programmieraufwand auch sehr überschaubar. Das einzig unschöne, was den Einsatz der fertigen Lösung gelegentlich doch verhindert, ist der RAM-Bedarf. Bei einer Lösung für einen kleinen Tiny tun halt auch schon 18 zusätzlich benötigte Bytes RAM manchmal sehr weh... Der Haupt-Trick ist übrigens: wähle die Zeit der Neusynchronisierung so, dass der Code zur Fehlerkorrektur sich normalerweise nicht mit einer Änderung jenseits der Einer-Stelle der Minuten rumschlagen muss. Dann wird der Code dermaßen simpel, dass der Codespace dafür kaum erwähnenswert ist.
c-hater schrieb: > Der Haupt-Trick ist übrigens: wähle die Zeit der Neusynchronisierung so, > dass der Code zur Fehlerkorrektur sich normalerweise nicht mit einer > Änderung jenseits der Einer-Stelle der Minuten rumschlagen muss. Dann > wird der Code dermaßen simpel, dass der Codespace dafür kaum > erwähnenswert ist. ...du sprichst über Neusynchronisierung. Wenn ich es richtig verstehe, dann nimmst du die lokale Zeit als Master und vergleichst sie mit der empfangenen Zeit. Wenn die empfangene Zeit nicht plausibel ist, dann übernimmst du die lokale Zeit als gültig mit entsprechender Korrektur in Minutenbereich. Ist die Annahme so korrekt? Rein theoretisch für eine Neusynchronisierung braucht man die empfangene Zeit gar nicht aus zu werten. Wenn man davon ausgeht, dass die Zeit zwischen 2 Synchronisierungen nur in Sekundenbereich abweicht (<30), dann würde es reichen nach 58 erfolgreich empfangenen Bits die Nullmarke zu detektieren. Bei Sekundenstand >= 30 inkrementiert man die Minuten und nulliert die Sekunden, bei < 30 nulliert man nur die Sekunden. Wenn aber die Uhr ohne RTC Backup gerade eingeschaltet wird, dann ist m.M.n die beste Methode 2 hintereinander empfangene Zeiten miteinander zu vergleichen. Wenn Zeit2 = Zeit1 + 1 ist, dann kann man davon ausgehen, dass die Zeit praktisch 100% korrekt ist. Dieses Vorgehen deckt dann beide Fälle, egal ob Neusync oder neu Einschalten.
Ozvald K. schrieb: > Wenn man davon ausgeht, dass die Zeit > zwischen 2 Synchronisierungen nur in Sekundenbereich abweicht (<30), > dann würde es reichen nach 58 erfolgreich empfangenen Bits die Nullmarke > zu detektieren. Wenn du eine dermaßen stabile RTC hast... Wenn nicht, ist die Anzeige auch mal um mehrere Minuten daneben, das aber auf Millisekunden genau :) Vor allem ist deine Uhr überzeugt, das sie Recht hat. Also so geht es nicht. Dann lieber eine kaputte Uhr mit Zeigern - die geht immerhin zweimal am Tag richtig. Wenn du tatsächlich von <30s ausgehst, kennst du ja fast die kompletten Daten im voraus (bis auf die Wetterbits). Warum willst du die nicht zur Synchronisierung nutzen? Ein Kompromiss wäre, Jahr, Monat und Tag zu nutzen. Das sind ca. 20mal so viele Bits wie eine einzelne Minutenmarke, entsprechend besser sollte der Störabstand sein. Trotzdem würde es auch mit einer schlechten RTC mit ein paar Monaten Funkloch funktionieren.
Bauform B. schrieb: > Wenn du eine dermaßen stabile RTC hast... Mein RTC mit DS1307 eilt ~1sec/Tag. Wäre es schwer eine solche Uhr vorzustellen die sich täglich einmal synchronisiert? Übrigens, habe ich nicht geschrieben dass ich es auch so praktiziere, darum auch "theoretisch". Aber vielleicht kannst du erklären wie die Fehlerkorrektur von c-hater funktioniert?
Ozvald K. schrieb: > ...du sprichst über Neusynchronisierung. Wenn ich es richtig verstehe, > dann nimmst du die lokale Zeit als Master und vergleichst sie mit der > empfangenen Zeit. Nein. Die lokale Zeit ist irrelevant. Ich empfange einfach mehrere (3) Pakete und spiele mit denen rum. Nur wenn mir die Ergebnisse hinreichend zuverlässig erscheinen, wird das Ergebnis zur lokalen Zeit.
c-hater schrieb: > Ich empfange einfach mehrere (3) > Pakete und spiele mit denen rum. ok, jetzt verstehe ich. War mir unklar womit du die empfangene Zeit vergleichst
Ozvald K. schrieb: > ok, jetzt verstehe ich. War mir unklar womit du die empfangene Zeit > vergleichst Mit sich selbst. Bzw. mit den nächsten zwei Inkarnation von sich selbst. Deshalb drei Telegramme.
Stefan ⛄ F. schrieb: > Für den Empfang von DCF Signalen sind Interrupts weder nötig noch > empfehlenswert, weil das Signal beliebig verzerrt sein kann. > Schlimmstenfalls führt der µC gar keinen normalen Code mehr aus, weil er > permanent mit Interrupts beschäftigt ist. Du quasselst Mist. Ich habe auch Pollin Module u. ebenfalls die oben geschilderten Empfangsprobleme. Conrad hatte mal welche, zur Zeit aber anscheinend nichts mehr im Online Shop. Welches andere Modul wäre denn empfehlenswert ? ELV, Reichelt ...?
73 schrieb: > Du quasselst Mist (über Interrupts) > Ich habe auch Pollin Module u. ebenfalls die oben geschilderten > Empfangsprobleme. Empfangsprobleme haben mit Interrupts nichts zu tun.
Angehängte Dateien:
-
Buerk_AD450_.jpg
58 KB
73 schrieb: > Welches andere Modul wäre denn empfehlenswert ? Hi, Bürk Mobatime. https://onlineshop.buerk-mobatime.de/analoguhren/sporthallenuhren/215/dcf-77-funkempfaenger-ad-fzd1 Kostet aber. Oder: ehemals HKWs Module für alle möglichen Zeit- und Wetterdatensender. https://www.hkw-elektronik.de/produkte/empfangstechnik-am/empfaenger-module/ https://www.hkw-elektronik.de/produkte/empfangstechnik-am/funkuhr-und-steuermodule/ ciao gustav
:
Bearbeitet durch User
Armin K. schrieb: > Für 76€ erwarte ich aber ein Bild. Soviel wäre doch möglich. Hi, die Frage ist sehr berechtigt. Details werden nur auf Anfrage geliefert. Bürk will wissen, wo die Geräte verbaut werden. Haben alle eine Seriennummer. Bei Einzelteilverkauf bekommt man die Sachen zwar, aber keinen Service. Den nur bei Komplettsystemkauf. Man muss eben deren Marketingstrategie nachvollziehen können, denn China-Fakes sind afaik davon noch nicht aufgetaucht. Ich bin aber sehr zufrieden mit dem AD450 mit Schwundregelung. Alle anderen, (ja ich habe die Conrad-Dinger auch) geben bei nur mäßigem Störpegel (z.B. in der Nähe von alten Röhrenfernsehern) ihren Geist auf. Der "Mobatime" liefert dann noch decodierbare Signale. ciao gustav
Angehängte Dateien:
-
DCF77_1.jpg
83 KB -
DCF77_2.jpg
68 KB
Ich hab mir für das Pollin-Modul mal diese Platine gebaut und keine Probleme. Hab zwischen der Platine und meinen Zielschaltungen aber immer 2m Kabel. FET ist z.B. ein AO3418 oder FDN335N (N-Kanal der bei 1.5V einigermaßen leitet).
Crazy H. schrieb: > Ich hab mir für das Pollin-Modul mal diese Platine gebaut Was ist da drauf? Lass mich raten: Spannungsregler Transistor als Pegelwandler CMOS Gatter als Leitungstreiber - oder als Schmitt Trigger?
Stefan ⛄ F. schrieb: > Empfangsprobleme haben mit Interrupts nichts zu tun. Das stimmt natürlich, aber andersrum muß man natürlich "Interruptprobleme" beim Konzept des Empfangs durchaus einbeziehen. Jedenfalls, wenn man interruptbasiert empfängt und das möglicherweise gestörte Signal die Quelle dieser Interrupts ist. Das fiese bei fremdinduzierten Interrupts ist halt: sie treten unvorhersehbar auf, wenn das induzierende Signal gestört ist. Und mindestens bei allem, was über Funk läuft, muß man immer und unter allen Umständen davon ausgehen, dass das Signal gestört sein könnte.
Karl B. schrieb: > Bürk will wissen, wo die Geräte verbaut werden. Sonst noch Wünsche ? Darf ich so auf´s Klo gehen oder muss ich erst Bürk fragen ?
Angehängte Dateien:
-
Montage_AD450.jpg
160 KB
Hi, bei den anderen Empfängern brauche ich mindestens 3 Drähte. Einen zur Spannungsversorgung, einen zum Abgriff des DCF77- High/Low-Sekundenmarken-Signals, eine Masse bzw. Rückführung der Spannungsversorgung. Und nach Möglichkeit abgeschirmtes Kabel. Beim AD450 kommt man mit unabgeschirmter Telefonlitze aus. Zweiadrig. Und Polung ist gleichgültig. Erleichtert die Montage nicht unerheblich. c-hater schrieb: > Das fiese bei fremdinduzierten Interrupts ist halt: sie treten > unvorhersehbar auf, wenn das induzierende Signal gestört ist. Wenn beispielsweise INTO etc. als Flankenerkennung genutzt wird, feuern diese im Störungsfall und bringen das System aus dem Takt. Man muss eine Fehlerkorrektur vorsehen. Sonst stürzt Software ab und fängt sich nicht mehr, auch wenn sauberes Signal wieder da ist. Ein Programm mit dieser Art Interruptskonflikten findet man zum Beispiel in der alten Version: http://www.avr-asm-tutorial.net/avr_de/dcf77uhr.html (C)2001 by Gerhard Schmidt ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > c-hater schrieb: >> Das fiese bei fremdinduzierten Interrupts ist halt: sie treten >> unvorhersehbar auf, wenn das induzierende Signal gestört ist. > > Wenn beispielsweise INTO etc. als Flankenerkennung genutzt wird, feuern > diese im Störungsfall > und bringen das System aus dem Takt. Bevor die Interrupt Lösung zum Teufel geschickt wird, hier eine Lösungsansatz: 1.Man verbietet als erstes die weitere Interrupts in der Interrupt Routine selbst. 2. Man startet einen Timer, der nach einem Zeitfester (950ms z.B.) die externe Interrupt wieder freigibt. 3.Für die fehlende 59. Sekunde: Man verbietet im Timer die externe Interrupt bei 1050ms, und gibt sie wieder frei bei 1950ms. So läuft es bei mir seit ~20 Monaten, ohne Absturz. Modul von Pollin, µC ATTINY13, Signal auf INT0, flankengesteuert.
Ozvald K schrieb: > Bevor die Interrupt Lösung zum Teufel geschickt wird, hier eine > Lösungsansatz: Schon ziemlich kompliziert, oder? Aber für den Obfuscated C Code Contest reicht es trotzdem nicht ;) Aber dann mag ich auch mal: ein Tiefpass (und notfalls ein Schmitt-Trigger) vor dem Interrupt-Pin. Damit begrenzt man die Zahl der Interrupts bei Störungen, bekommt kleine Aussetzer garnicht erst mit und hat trotzdem noch die maximal mögliche Zeitauflösung für die Flanke. Man muss nur die Verzögerung durch den Tiefpass einrechnen. Das würde ich als Ausrede durchgehen lassen. Ansonsten gibt es nur einen vernünftigen Grund für die Interrupt Lösung: wenn alle anderen Pins belegt sind und der uC den Interrupt-Pin nicht abfragen kann.
Bauform B. schrieb: > Schon ziemlich kompliziert, oder? Aber für den Obfuscated C Code Contest > reicht es trotzdem nicht ;) Würde leider nicht durchgehen, weil in Assembler. Aber, jedem seine Religion :-)
Ozvald K schrieb: > Bevor die Interrupt Lösung zum Teufel geschickt wird, hier eine > Lösungsansatz: Natürlich geht auch ein externer Interrupt, wenn man es richtig macht. Nur ist das deutlich aufwendiger, als wenn man einfach den Pin im 10ms Timerinterrupt abfragt und auswertet. 10ms Raster reichen bequem aus, um die 100/200ms bzw. 1000/2000ms zu unterscheiden. Das ergibt den geringsten Codeverbrauch und 10ms Interruptrate bewirken auch keine merkbare CPU-Last. Die Interruptrate steigt auch bei Störungen nicht unkontrolliert an, sondern bleibt konstant.
Peter D. schrieb: > 10ms Raster reichen bequem aus, um die 100/200ms bzw. 1000/2000ms zu > unterscheiden. > Das ergibt den geringsten Codeverbrauch und 10ms Interruptrate bewirken > auch keine merkbare CPU-Last. Und man kann Port sperren für den Rest der Sekunde. Alles, was nach den 200 ms kommt an Spikes, wird für die verbleibenden 800 ms schlichtweg ignoriert. Das erhöht die Störsicherheit. ciao gustav
Karl B. schrieb: > Und man kann Port sperren für den Rest der Sekunde. Meine Erfahrung ist, daß die üblichen Empfänger bei Störungen schnell kein auswertbares Signal mehr liefern. Die Störungen überdecken das Signal. Auch werden die Pulse zuerst gestört, da Signalabsenkung. Ob man da nun Zeitfenster ausblendet, bringt so gut wie nichts. Es macht allerdings den Start komplizierter. Man muß ja erstmal synchron sein, ehe man was ausblenden kann.
Stefan ⛄ F. schrieb: > Was ist da drauf? Lass mich raten: Ich bin mir fast sicher, daß du lesen kannst :-D
Angehängte Dateien:
-
MSF60_Channel_Code.png
44 KB
Peter D. schrieb: > Ob man da nun Zeitfenster ausblendet, bringt so gut wie nichts Hi, bei MSF60 geht es bei der Auswertung lediglich des A-Codes nicht anders (unter Verwendung der der 10ms-Timerinterrupt-Methode). A Code Null und B Code Eins ergibt zwei Absenkungen innerhalb des 200 ms Intervalls. Bzw. 300 ms. Beitrag "MSF60 Dekoder AVR Teil_2" Solch ein Ausblenden kann man im Analogieschluss auch auf DCF77 anwenden. Ob es da nötig ist, jedenfalls schaden kann es nicht. ciao gustav
:
Bearbeitet durch User
Peter D. schrieb: > Meine Erfahrung ist, daß die üblichen Empfänger bei Störungen schnell > kein auswertbares Signal mehr liefern. Deshalb wird bei einer Funkuhr die Uhr auch nur regelmäßig synchronisiert und läuft nicht ausschließlich auf Funk. In diesem Thread haben einige anscheinend das Pollin Modul. Das Bild auf der Homepage ist relativ schlecht. Ist das (3. oder 4. Minute) das Pollin Modul? https://www.youtube.com/watch?v=f_qMfuUxgJ8
Peter D. schrieb: > Nur ist das deutlich aufwendiger, als wenn man einfach den Pin im 10ms > Timerinterrupt abfragt und auswertet. kann man prima in deiner Tasten Entprellroutine nutzen, so mache ich das. Es gibt ja nur die Möglichkeit das Bit ist sauber zwischen 70-120ms oder zwischen 160-220ms, die Lücke >950ms. Wenn man das auch noch in deine DCF77 Routine schickt hat man die Parität und Prüfbits gleich mit abgehakt
:
Bearbeitet durch User
Karl B. schrieb: > in der alten Version: > http://www.avr-asm-tutorial.net/avr_de/dcf77uhr.html > (C)2001 by Gerhard Schmidt findet man sogar noch eine "dynamische" Anpassung der Auswertezeiten. Und im Menü noch Auflistung der tatsächlichen "Messwerte". ciao gustav
Guten Tag zusammen, ich hoffe der Thread lebt auch noch im Jahre 2020. Mein Thema passt hier nämlich sehr gut zu "Empfangsprobleme anderer Art". Was mich wundert ist, dass an meinem Signal ziemlich viel passt. Jedoch passen die Pulsweiten der Flanken nicht. Das soll heißen, dass mein 0-Signal bzw. mein 1-Signal nicht die typischen 100ms bzw 200ms hat. Ich habe mal ein kleines Programm geschrieben, siehe unteren Code, um die Zeiten der Flanken auszuwerten. Hier mal eine Ausgabe: 448ms für 0-Signal 551ms für 1-Signal --> Anmerkung: Dauer 999ms 381ms für 0-Signal 619ms für 1-Signal --> Anmerkung: Dauer 1000ms 469ms für 0-Signal 531ms für 1-Signal --> Anmerkung: Dauer 1000ms 332ms für 0-Signal 665ms für 1-Signal --> Anmerkung: Dauer 997ms 503ms für 0-Signal 498ms für 1-Signal --> Anmerkung: Dauer 1001ms 396ms für 0-Signal Folgende Sachen wundern mich: 1. Addiere ich beide Zeitsignale, so sind dies ziemlich genau 1s. So wie es sein soll. 2. Messe ich mit dem Oszilloskop das Signal nach, so flackert es nicht. Ich habe ein durchgängiges 1-Signal und ein durchgängiges 0-Signal. 3. An dem Ort, an welchem ich die Tests gemacht habe, habe ich eine fertig gekaufte Funkuhr aufgestellt. Dies findet das Signal nach spätestens 3 Minuten. Schlechten Empfang schließe ich also aus. Folgendes habe ich probiert: 1. Antenne in verschiedenen Variationen angeordnet. 2. Einen Akku als Spannungsquelle ausprobiert. 3. Die Schaltung abseits der Zivilisation aufgebaut um Störeinflüsse zu vermeiden. Ich selbst finde es schon sehr seltsam. Die Zeit beider Pulsweiten gibt eine Sekunde. Nur die einzelnen Pulsweiten sind halt nicht 100ms bzw. 200ms. Oder anderst herum 800ms bzw. 900ms. Hat einer eine Idee an was es liegen kann. Hier mein Programm zum Testen:
1 | void setup() {
|
2 | Serial.begin(9600); |
3 | pinMode(2,INPUT); |
4 | pinMode(13,OUTPUT); |
5 | } |
6 | |
7 | |
8 | unsigned long tempZeit = 0; |
9 | bool alterZustand = false; |
10 | void loop() {
|
11 | bool ZustandPin = digitalRead(2); //Nutze Pin2 als Eingang des DCF-Signals |
12 | digitalWrite(13,ZustandPin); //Nutze Pin13 als Ausgang, zum Blinken des DCF-Signals |
13 | |
14 | if (ZustandPin != alterZustand) |
15 | { unsigned long aktuelleZeit = millis();
|
16 | Serial.print(aktuelleZeit-tempZeit); |
17 | Serial.print("ms ");
|
18 | Serial.print(" für ");
|
19 | Serial.print(!ZustandPin); |
20 | Serial.println("-Signal");
|
21 | tempZeit = aktuelleZeit; |
22 | alterZustand = ZustandPin; |
23 | } |
24 | } |
Quiddi Q. schrieb: > Was mich wundert ist, dass an meinem Signal ziemlich viel passt. Jedoch > passen die Pulsweiten der Flanken nicht. Das soll heißen, dass mein > 0-Signal bzw. mein 1-Signal nicht die typischen 100ms bzw 200ms hat. Das Problem hatte ich auch bei meinem ersten Aufbau. Deswegen habe ich den DCF Empfänger mal mit Batterien versorgt und ans Oszilloskop gehängt, da sah dann plötzlich alles perfekt aus. Letztendlich lag es bei mir an der Stromversorgung. Ich habe den Empfänger daraufhin nicht mehr an 3,3V angeschlossen, sondern an die grüne Power-LED, welche schön stabile 2 Volt hatte. Damit lief es dann gut. Außerdem ist es (so blöd es aussehen mag) immer vorteilhaft, den DCF Empfänger mit 2 Meter Kabel und einem eigenen Gehäuse abzusetzen. Dann hat man nämlich die notwendige Freiheit, ihn von Störquellen weit genug entfernt aufzustellen und man kann die Antenne auch problemlos richtig ausrichten.
Falls es ein Pollinmodul ist, könnte der Ausgang zu "stark" belastet sein. Mein Vorschlag, nur den Oszi anschliessen, sonst nichts, und dann die Impusbreiten nochmal anschauen.
Hallo nochmal, erst einmal Danke für eure Antworten. 1. Zu starke Belastung: Ich habe das Signal mit einem Transistor verstärkt. Und ja, es handelt sich um das Pollinmodul. Wie viel darf man denn da an Strom am Signalausgang ziehen. Ich zeihe gerade 3mA. Das steht nämlich nicht im Datenblatt. 2. Ich habe genau 3,3V als Spannung anliegen. Also 2V wären besser? Schönen Gruß und Danke.
Quiddi Q. schrieb: > Ich ziehe gerade 3mA. Mein altes Datenblatt finde ich gerade nicht. Ich meine es wären max. 5µA gewesen. Meine Anschaltung ist hier dargestellt: Beitrag "[Bascom/AVR] Uhr und DCF" Gruß Alex
:
Bearbeitet durch User
Quiddi Q. schrieb: > Ich habe das Signal mit einem Transistor verstärkt. Hi, ...und damit womöglich unter Verwendung einer Emitterschaltung invertiert. Ist die Decoderauswertesoftware dafür richtig eingestellt? ciao gustav
Quiddi Q. schrieb: > 1. Zu starke Belastung: > Ich habe das Signal mit einem Transistor verstärkt. Und ja, es handelt > sich um das Pollinmodul. Wie viel darf man denn da an Strom am > Signalausgang ziehen. Ich zeihe gerade 3mA. Das steht nämlich nicht im > Datenblatt. Das ist sehr viel. Wenn du mit dem gepufferten Signal auf einen CMOS-Eingang willst, dann reichen da 10-30µA! Also: 100k Basiswiderstand mit meinetwegen 10k (oder mehr) als Pullup am Kollektor sollten passen. Schlimmstenfalls sind die schon zu viel - Alex. D hat nur 5µA in Erinnerung, aber es gab wohl mehrere Versionen von Pollin. > 2. Ich habe genau 3,3V als Spannung anliegen. Also 2V wären besser? Die vorhandene Beschreibung auf der Pollin-Webseite ist zwar mehr als dürftig, immerhin steht drin, das 3.3V der Maximalwert sind, nominal sollten es 3V sein, minimal 1.2V. Ja, 2V wären besser, aber warum nicht die nominalen 3V nehmen? Dann könnte der Transistor auch ein LL-MOSFET sein und du brauchst dir über die Belastung keine Gedanken machen. Und, es steht auch drin, dass man die Versorgung mit 10µF puffern soll. Auch bei wenigen Angaben im Datenblatt sollte man die vorhandenen wenigstens beachten. Besser wäre auch, wenn du eine Skizze der Verschaltung angehängt hättest. So glaubt der eine, du verwendest eine Emitterschaltung, der andere geht von einer Kollektorschaltung aus. Das führt ggf. zu falschen Antworten.
Quiddi Q. schrieb: > Wie viel darf man denn da an Strom am Signalausgang ziehen. So viel, dass deine Spannung noch eindeutige HIGH/LOW ist. Diese Detail ändert sich immer wieder, so wie auch andere Details an Modul. Meine 5 Jahre alten Erfahrungswerte werden wir wenig nützen. Die Spannungspegel kannst du am besten mit einem Oszilloskop prüfen. > Ich ziehe gerade 3mA. Das wäre bei meinem Modul unmöglich gewesen. > 2. Ich habe genau 3,3V als Spannung anliegen. Also 2V wären besser? Es geht nicht um die Höhe der Spannung. Klar muss die die in einem zugelassenen Bereich liegen. Für den Empfang ist wichtig, dass die Spannung stabil ist. So Aal-glatt wie aus einer Batterie. Auch das kannst du am besten mit einem Oszilloskop prüfen. Wenn es am Geld scheitert, dann kauf dir wenigstens ein NF Spielzeug-Oszilloskop vom Typ DSO138 oder DSO150. Das würde für diesen Zweck schon reichen und dir auch an vielen andere Stellen nützlich sein.
Klaus C. schrieb: > Ist das (3. oder 4. Minute) das Pollin Modul? > > https://www.youtube.com/watch?v=f_qMfuUxgJ8 Mein Pollin Modul sieht genauso aus und die Sache mit der Lötbrücke im Video hat damit funktioniert. Das Modul ist zickig bei der Spannungsversorgung, ansonsten kann ich nicht klagen. Der Dcf 77 Geber hat mir gute Dienste geleistet. Das Beste ist der Schluss mit dem AM "Sender". https://www.youtube.com/watch?v=SUkYBwpVHA8
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.