Wie teuer ist eigentlich ein billiges DCF77-Modul (bei einer Abnahme von 30.000 Stk./Jahr) und braucht man dafür einen USART oder reichen ein paar Digitaleingänge?
Was hast Du denn damit vor? Zur Zeit entwickle ich gerade ein DCF77-Anwendung mit einem Atmel. Der Atmel decodiert das Signal und gibt dann die Zeit als lesbaren ASCII-String an der seriellen Schnittstelle aus. Mit z.B. Hyperterminal kann man dann die Zeit auslesen. Zudem wird die Zeit parallel über Portpins ausgegeben. Das Datum kann sich dann eine andere Anwendung(Prozessor) abholen und weiterverarbeiten. Also ein kompletter DCF77-Empfänger mit Ausgabeschnittstellen. Grüße Oliver
Ok, danke. Ein Modul müsste dann unter 10 EUR/Stk. kosten. Ich hoffe mal, dass die DCF77-Empfänger nicht durch die Pulse von Brustpuls-Gurten gestört werden.
Für den Empfang brauchst Du nur einen digitalen Eingang. Der Empfänger gibt die Pulse schnarchlahm mit 1Baud aus. D.h. den Rechenaufwand kann jede CPU spielend mitübernehmen. Ein extra Kontroller nur zum dekodieren ist absoluter Overkill. Du brauchst nur etwa 300 Byte Programmspeicher zum Dekodieren (8051 in C programmiert). Peter
Ok, aber der Empfänger ist doch ein Microcontroller oder ähnlicher IC, der die DCF77-Funkwellen in Digitalpulse dekodiert; den braucht man doch sicherlich immer. Weil das Modul an einen MC soll, der noch einen USART frei hat, werde ich natürlich möglichst den nehmen.
Ja und da liegt das eigentlich Problem, ich finde es einfach unverständlich, warum jeder das Rad immer wieder neu erfinden muß. Zu kaufen gibt es immer nur den Demodulator. Aus dem digitalen Signal muß dann das Datum gebastelt werden. Ich verstehe einfach nicht, warum es keinen Empfängerchip gibt, der diese (kleine)Arbeit gleich mit übernimmt. Vor Jahren haben wir mal eine Meinberg(oder Weinberg, keine Ahnung mehr...)-Uhr verwendet. Das Ding bestand aus einer fetten Antenne und einem Kontroller, bei dem man sich das Datum seriell abholen konnte. Der Hammer war der Preis: 800 Mark!!! Die Bauteile für so einen autonomen DCF-Empfänger mit Datenschnittstelle sind doch nicht der Rede Wert. Hey! Moment mal,..., vielleicht tut sich da ein Markt auf? ... Grüße Oliver
Wie gesagt, der Aufwand ist ja nicht der Rede wert. Einen Pin, den man 1-mal in der Sekunde pollen muß, verkraftet jede Software. Die UART dagegen ist meistens schon für andere Sachen belegt und eine 2. UART in Software ist schon erheblich rechenzeitintensiver. Wenn man dann noch den String wieder mühsam auseinanderklamüsern und in Binärzahlen wandeln muß, sind die 300 Byte auch wieder schnell überschritten. Wenns denn aber unbedingt seriell sein muß, dann tuts auf alle Fälle ein ATTINY12. Der kann dann auch als Gangreserve dienen, wenn der Empfang mal gestört ist. Je nachdem, wie genau diese Gangreserve sein soll muß man dann aber mit einem externen Quarz arbeiten. Ansonsten tuts der interne RC voll. Man kann ihn ja mit den 1s-Impulsen des DCF-77 abgleichen. Eine schon etwas ältere Beispielroutine ist hier zu finden: http://www.specs.de/users/danni/avr/soft/dcf77/index.htm Ist mein 1. Versuch gewesen, d.h. nicht gerade gut optimierter Code. Peter
Also ich benutze einen MSP430F149, bei dem der zweite U(S)ART ungenutzt ist; dafür gibt es doch garantiert passende DCF77-Module, die die Daten seriell rüberschieben. Die Schaltpläne, die ich über Google gefunden habe, sahen zumindest so aus. Das Zerlegen der Bytes sollte doch kein großer Aufwand sein um die schon vorhandene Echtzeituhr zu synchronisieren, indem z. B. die Zeitdifferenz jeweils halbiert wird (der ntpd macht es ungefähr so bei PCs).
@nobody Ja, wenn man eine 2. UART hat, kann man diese verwenden. Bei den AVRs und 8051-ern hat aber nicht jedes Derivat eine 2.UART, d.h. man würde sich da stark in der Auswahl einschränken. Ist natürlich jedem selbst überlassen, ob er dafür einen extra Controller und die 2.UART ver(sch)wenden will. Ich finde es jedenfalls einfacher, die DCF-77-Routine direkt einzubinden. Vorteil, man hat alles direkt im RAM in einer Struktur verfügbar (s, min, h, day, weekday, month, year). Z.B. in C: http://www.specs.de/users/danni/appl/soft/c51/thclock/dcf77.c51 Ich nehme mal großzügig 100 Zyklen/s Rechenzeit an, das ist dann eine zusätzliche CPU-Belastung von 0,01% bei 12Mhz (AT89C2051). Peter
Ja, aber dafür braucht man doch das DCF77-Signal digitalisiert, ausser vielleicht man kann einen AD-Wander (oder Comparator) an die Antenne hängen. Weil der AD-Wandler schon belegt ist, brauche ich ein Modul das Digitalpulse ausgibt, denn dafür wäre der brachliegende UART ganz passend.
Du brauchst ein billiges Demodulator IC einen 77,5 khz Quarz als Filter (in anderen Ländern 60khz Bzw. 40khz, eine Antenne und wenn es hoch kommt noch ein paar Bauteile. Die Signale die da rauskommen sind digital, aber viel zu langsam um sie mit einem USART zu verarbeiten (wurde hier schon mehrmals geschrieben). Hier findest du, was dann hinten rauskommt. http://www.heret.de/funkuhr/index.htm Gruß Bernhard
Hier kriegst du alles was du brauchst. Wenn es denn unbedingt ein serielles Modul sein muss auch das. http://www.hkw-elektronik.de/produkte/Baugruppen___Sub_-_assembly/baugruppen___sub_-_assembly.html Gruß Bernhard
Danke sowas habe ich gesucht und sowas ähnliches habe ich schon seit Jahren an meinen PCs. Ohne UART brächte man doch deutlich mehr Code um Rechteckimpulse auszumessen, oder?
Wo bekomm ich den so ein verdammtes DCF Modul her? Demodulator mit Antennchen. Bei Konrad will ichs net kaufen, das sind Verbrecher, bei Reichelt und Stammelektrodealer vor Ort nix gefunden.
Hi
> Wo bekomm ich den so ein verdammtes DCF Modul her?
Conrad 12,76 EUR
Artikel-Nr.: 190691 - 62
Da scheint keine Antenne bei zu sein oder seh ich das falsch.
ELV 9,95
Artikel-Nr.: 68-352-62
Antenne dabei und funktioniert sehr gut. Auch kein Schnäppchen geht aber
grad noch.
Gruss Carsten
nobody0, wenn du das DCF77 mit Fehlerkorrektur auswerten willst, wirst du wahrscheinlich etwas mehr code brauchen als wenn du es über einen Usart einliest. Ich habe die seriellen Module von HKW aber noch nie selber in den Händen gehabt. Ich kann dir daher auch nicht sagen, ob oder wie, die die Daten nicht nur decodieren sondern (wie sie behaupten) auch überprüfen. Wenn die das halbwegs gut machen (was ich ihnen zutraue), kann das natürlich schon zu einer erheblichen Entlastung des benötigtem Codes auf deiner Seite führen (kostet dafür aber Geld und Strom). Gruß Bernhard
Der DCF-77-Code ermöglicht keine Fehlerkorrektur sondern nur Fehlererkennung. Das ist aber in meiner obigen Routine schon drin und besteht in folgenden einfachen Tests: - stimmt das Parity-Bit ? - sind es genau 59 Impulse ? - sind die Impulse etwa 100ms bzw. 200ms ? - sind die Pulsabstände etwa 1s bzw. 2s ? Jeder dieser Fehler bewirkt ein Verwerfen des Datenpakets und damit ist mir noch keine unkorrekte Zeit durchgeschlüpft. Eine quasi Fehlerkorrektur ist nur dadurch möglich, daß man eine RTC mitlaufen läßt, die mindestens schon einmal durch eine korrekte Zeit synchronisiert wurde. Im einfachsten Fall ist diese RTC durch einen der CPU-Timer realisiert. Es stimmt natürlich, daß sich viele in kommerziellen Geräten solche einfachen Routinen über Gebühr teuer bezahlen lassen. Der Aufwand bei Empfang über die UART ist dagegen recht erheblich. Man muß ja einen interruptgesteuerte UART-Empfangsroutine installieren, die entweder ständig einen RAM-Puffer für ein komplettes Datenpaket reserviert oder die Umsetzung in Zahlen direkt im Interrupthandler ausführt, was aber zu Verzögerungen anderer Interrupts führen kann. Außerdem kann eine UART-Übertragung auch fehlerbehaftet sein (z.B. kann ein anderer Interrupt soviel Zeit belegt haben, daß ein Byte verloren wurde). Deshalb wird bei serieller Übertragung oft noch eine 16-Bit-CRC übertragen die allein schon eine 512 Byte große CRC-Tabelle benötigt. Also, wer lieber den steinigen Weg gehen will, nehme die UART. Peter
Dann ist wohl das Beste einen eigenen Empfänger zu bauen mit sowas wie MSP430F149, denn der kann ja die Daten über einen UART rausschieben oder auch einfach auf Anfrage Datum und Uhrzeit ausgeben. Das Problem ist dann noch die Antenne ranzubekommen. Da reicht der AD-Wander wohl nicht aus, oder?
Hat der Junge das denn immer noch nicht kapiert? Das Demodulator-IC übernimmt die Demodulation des Signals, dass die Antenne in Braunschweig (stimmt das?) abstrahlt. Raus kommt ein digitales Signal, dass jede Sekunde nen Impuls von entweder 100ms (entspricht ner logischen 0) oder von 200ms (=1) und zwar 59 mal. Die 59.te Sekunde wird dabei weggelassen, um eine Synchonisation auf ne volle Minute zu bekommen. (Soweit richtig? Falls nicht, bitte korrigieren!) Und genau dieses Signal mußt du mit nem µController auswerten, um deine Zeit und dein Datum zu bekommen. (Wie genau die Impulse kodiert sind, also welche Sekunde was bedeutet, findest du zuhauf im Internet.) Bis denn, ERDI - Soft.
Hallo Zusammen, hier mal etwas zum dekodieren des DCF-Signals. Am einfachsten geht es mit einem UART. Die Baudrate wird auf ungefaehr 200 ms / 9 eingestellt mit folgender Idee: Mit beginn des Sekundenimpuls startet der Uart den Empfang eines zeichens. Nach 100 ms sind das Startbit und 4 Datenbit vergangen, nach 200 ms 8 Datenbit. Somit liefert der UART bei einem 100 ms - Impuls ein 00F und bei 200 ms ein 0FF (oder 0F0 und 0FF). Also dekodierung übernimmt UART, Auswertung kinderleicht. Ein Empfänger nach diesem Prinzip wurde vor Jahren in der Fachzeitung Elektor veröffentlicht. Ein kleiner Wehrmutstropfen: Das Verfahren hat sich ein Herr Gude, Köln, patentieren lassen.... Ein Elektor Leser.
Aha. Na genaugenommen ist das kein Problem, denn als Privatperson hat man keinerlei Patent-Restiktionen und notfalls kann man das Verfahren so abzuändern, dass es keine Kollision gibt; die Frauenhofer-Gesellschaft bietet das als Dienstleistung an und hat eine eigene Arbeitsgruppe dafür. In welcher Elektor-Zeitschrift ist der Artikel denn erschienen?
Hallo @Elektor - Leser In Deiner Beschreiung kommt das so rüber ob der Herr Gude die Elektor gelesen hätte und dann das Verfahren zum Patent angemeldet hätte. Sucht nicht Elektor ständig Autoren für Ihre Artikel?! IHMO hat sich das Verfahren ausgedacht, patentieren lassen,und dann erst Elektor den Artikel geschickt.... MfG Rainer
Hallo! Wie störempfindlich ist denn der Empfang dieser DCF- Signale? Oder andersherum gefragt, was kann das Signal stören? Ich bräuchte so einen Empfänger in einer Maschinenhalle, in der einige Frequenzumrichter für ca. 100kw- Motoren stehen. Ich hab mal gehört, das dort Funkuhren nicht empfangen können. Stimmt das? Matthias
DCF wird auf 77,5 kHz gesendet, und wenn in der Halle heftiger "Störnebel" in dem Frequenzbereich ist, klappt's natürlich nicht mit dem Empfang.
Ich würde sagen: Probieren geht über studieren, oder wie ging der Spruch? Ich probiers einfach mal mit einem Funkwecker aus, bevor ich mir was bastel! Matthias
Aber dran denken, die meisten Funkwenker empfangen nicht permanent. Sondern nur einmal direkt nach dem einschalten und je nach Modell wird das DCF77 nur zu synchronisation der internen Quarz-Uhr einmal am Tag meistens nachts zwischen 3 und 4 ausgewertet.
Nun hat also der Patentunsinn auch bei uns amerikanische Verhältnisse erreicht. Ich kann mir aber nicht vorstellen, daß sowas offensichtliches im Streitfall Bestand hat. Die Methode, Impulslängen mit einem Schieberegister zu erkennen, ist quasi genauso alt wie das Schieberegister selbst. Ich erinnere mich, sowas schonmal in einer Uralt-Schaltungssammlung mit dem D195 (DDR-Version des 7495) gesehen zu haben. Patentieren kann man leider alles und jedes. Peter
@ERSI-SOFT: >Hat der Junge das denn immer noch nicht kapiert? Das Demodulator-IC >übernimmt die Demodulation des Signals, dass die Antenne in >Braunschweig (stimmt das?) abstrahlt Die PTB und somit die Atomuhr steht in Braunschweig, die Antenne ist bei Mainflingen bei Frankfurt. Zum Namen DCF77: D steht für Deutschland, C für Langwelle, F für Frankfurt, 77 für 77,5kHz. Nebenbei als Info :-) Armin
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.