DCF77

Hallo,

gibt es eigentlich einen IC, der die Signale vom DCF77 Empfänger auswertet, und dann z.B. mittels einen Mikrocontroller das Datum und die Uhrzeit ausgelesen werden können.

MfG Alex

Reply to
Alex Loipführer
Loading thread data ...

"Alex Loipführer" schrieb im Newsbeitrag news:bl8oal$k1$06$ snipped-for-privacy@news.t-online.com...

auswertet,

Da du dann ohnehin Software für diese "DCF77-Schnittstelle" schreiben müsstest, kannst du auch gleich das demodulierte, serielle DCF77-Signal an den Controller hängen und eine Auswertesoftware schreiben. Aus diesem Grund wirds wohl so ein DCF77-IC wie von dir gewünscht, nicht geben.

Was ist dabei, 59 Bits in ein Register/Speicher einzulesen und die sowieso schon BCD-codierten Daten dann auf eine Anzeige zu bringen, oder sie in ein anderes gewünschtes Format umzuwandeln? Vielleicht noch etwas Fehlertoleranz einpflanzen. Die programmierung irgendeiner herstellerspezifischen "DCF77-Schnittstelle" scheint mir da komplizierter.

Servus Franz

Reply to
Franz Hornung

auswertet,

So furchtbar kompliziert ist das DCF77 Protokoll ja nicht. Wenn du sowieso einen Mikrocontroller verwendest kann dieser doch gleich die Dekodierung mit übernehmen. Im Netz finden sich viele fertige Programme, die das erledigen. Dieses dann in das eigene Projekt einzubinden sollte möglich sein.

Reply to
Wolfgang Berger

Alex Loipführer schrieb:

Sicher - z.B. hat Conrad so eine DCF-Funkuhr für den Parallelport. Da dürfte so ein Chip drin sein. Dast Teil läuft selbständig per Batterie und wird vom PC bei Bedarf nur ausgelesen.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Franz Hornung schrieb:

Es ist wohl ein riesen Unterschied nur gelegentlich und "bei Bedarf" eine handvoll Bytes für Datum und Uhrzeit abzurufen als permanent eine Dekodiersoftware laufen zu lassen.

Was dabei ist? Hast du schon mal so eine Software geschrieben? Kennst du überhaupt das minimal nötige Flußdiagramm um ein DCF-Telegramm auszuwerten? Schau mal in eine alte Elektor von ca. 1985! Oder schau mal bei Google rein. Es gibt genug Listings.

Vielleicht ist gut "Ohne" eine sehr intelligente Programmierung wirst du mit einem Standardflussdiagramm, wie z.B. der oben erwähnten Elektorsache, am PC kein einziges Telegramm fehlerfrei reinbekommen. Ich habe hier eine "mittelintelligente" Software als DOS-TSR laufen. Die schafft bei mittlerer PC-Auslastung zwischen 0 und 5 Synchronisationen in der Stunde. Im PC-Ruhezustand schafft sie ca. jede 2te bis 3te Minute zu syncen. Manchmal sogar jede Minute. Je nach Wetter (Empfang). Die Windowssoftware vom gleichen Hersteller schafft das Synchronisieren noch wesentlich seltener.

LOL! 3-4 mal OUT und entsprechend IN am Port und die fertige Datums-Zeitinfo ist da!

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Naja - "permanent laufen lassen" ist es ja nicht, ein Interrupt pro Sekunde (wenn ein Timer zur Verfügung steht) ist nicht soo wild.

Eben. Ein paar hundert Bytes Assemblercode würde ich mal schätzen - also in den meisten Designs locker ohne Mehraufwand mit unterzubringen, daher lohnt es kaum, dafür einen Spezialchip zu entwickeln (der dann vermutlich auch nur aus einem passend programmierten Controller bestehen würde).

Ich habe einen leicht gepatchten dcfd, der die Signale eines Aldi-Funkweckers auswertet - da ist keine besondere Logik drin außer der üblichen Vergleiche zwischen mehreren Telegrammen, um den Müll auszufiltern:

Sep 28 17:51:00 a-tuin dcfd[351]: receiving DCF77 Sep 28 18:11:00 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 28 18:13:00 a-tuin dcfd[351]: receiving DCF77 Sep 28 18:57:00 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 28 18:59:00 a-tuin dcfd[351]: receiving DCF77 Sep 28 22:10:41 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 28 22:13:00 a-tuin dcfd[351]: receiving DCF77 Sep 28 22:17:00 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 28 22:19:00 a-tuin dcfd[351]: receiving DCF77 Sep 28 22:47:00 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 28 22:49:00 a-tuin dcfd[351]: receiving DCF77 Sep 29 08:59:00 a-tuin dcfd[351]: DCF77 reception lost (bad data) Sep 29 09:01:00 a-tuin dcfd[351]: receiving DCF77

Das reicht in der Praxis dicke und produziert keinen besonderen Programmieraufwand, und der Aldi-Wecker ist bestimmt auch nicht das beste, was man an DCF77-Empfängertechnik aufbieten kann ...

cu Michael

Reply to
Michael Schwingen

Michael Schwingen schrieb:

2 Interrupts pro Sekunde bitte! Oder willst du nach der Anfangsflanke per Softwareloop auf die Endflanke warten?

Und um diese Interrupts auszuwerten muss schon ein Software "permanent" laufen. Zumindest im Speicher stehen und per Interupt jeweils starten. D.h. es muss dazu ein Treiber geladen werden.

Wenn es sich nicht lohnen würde, dann gäbe es das nicht.

Allein das ist schon eine "Menge". Nämlich das ganze Empfangen und "Einsortieren" in die richtigen Register bzw. sammeln als Kompletttelegramm.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Stimmt. Die Last, die das selbst auf einem 8MHz-8051 verursacht, dürfte aber trotzdem zu vernachlässigen sein.

"permanent laufen" heißt für mich, daß die Software permanent Ressourcen, insbesondere CPU-Zeit braucht - das ist hier wohl eher nicht der Fall.

Wie gesagt: geschätzt ein paar 100 Bytes Assembler - kann man mit etwas Fleiß problemlos selber machen und rechtfertigt daher IMHO nicht das Zukaufen eines Spezialchips.

cu Michael

Reply to
Michael Schwingen

Hallo, Von Atmel (ehemals Temic) gibt es IC's die die Uhrzeit seriell mit ca.

150 Baud als 59 Bit Datenwort ausgeben ;-)

Gruss Jochen

Reply to
jochen rapp

Hier eine funktionierende Lösung für den PIC16C84 von Microchip, allerdings wird nur die Uhrzeit ausgewertet. Den DCF77-Empfänger gab's mal bei Conrad, er wird aber, so viel ich weiß, nicht mehr angeboten.

Gruß Rudi

///////////////////////////////////////////////////////////////////////// // DCF77 decoder // // clock open drain A4 (10k to +12V // input 100k serial res. // ///////////////////////////////////////////////////////////////////////// #include #fuses HS,NOPROTECT,NOWDT #include

#use delay(clock=10000000) #use rs232(baud=300, xmit=PIN_B0, rcv=PIN_B1, INVERT) #use standard_io(A)

#define dcf_in pin_b4 #define dcf_clklow output_low(pin_a4); // a4 with pullup #define dcf_clkhi output_high(pin_a4); #define pulse 10 #define CLS printf("%c", 12)

int in[4];

void pulseout(){ delay_ms(pulse); dcf_clkhi; delay_ms(pulse); dcf_clklow; delay_us(10); }

void get_time() { int i, sync, slo; dcf_clklow; sync=0; slo=0; for (i=0; i sync pulseout(); shift_left(&slo,1,input(dcf_in)); if ((slo & 0x0f)== 0b00000110) // inverted sync=1; }; for (i=5; i

Reply to
Rudi Hofer

Michael Schwingen schrieb:

Die Last ist relativ gering. Sie ist aber permanent da. Genauso wie der Speicherverbrauch der Software.

Das ist natürlich nur bei jedem Interrupt kurz der Fall. Das Programm belegt aber Speicher und muss 2 mal pro Sekunde einige Aktivitäten machen. Im einfachsten Fall nur einen Zeitstempel. Dazwischen je nach erkannten Teilmengen der Information entsprechende Routinen und einmal pro Minute den kompletten Abschluss eines Zyklus. Eventuell mit Nachstellen der PC-Uhr.

LOL! Mein Treiber (DOS-TSR) hat 10kb! Davon geht ein Teil nach dem Laden weg, weil er nur zum Laden des TSR-Teiles dient. Wieviel noch tatsächlich übrig ist, weiß ich nicht. Ich schätze mal so ca. 8-9 kb. mehr als 1 kb braucht es garantiert nicht zum Laden. Im Speicher belegt es laut MEM ca. 12 kb. Werden wohl einige reservierte Bereiche für die gesammelten Infos sein. Ich habe jezt keine Lust mir den Code genauer anzuschauen.

Tatsache ist, daß man mit ein paar hundert Bytes keinen vernünftigen und garantiert "sicheren" Empfang bekommt!

Du hast das noch nie gemacht! Ich schon! Mein erster "Dekoder" lief unter Basic auf einem Z80

Ich kenne auch das Listing meiner Elektor-Funkuhr und diverse andere Assemler-Listings für Z80/8080 und PC. Wenn du ein "paar hundert Bytes" gegen ein "paar tausend Bytes" ersetzt, dann stimmt das wenn man man einen brauchbaren Treiber haben will.

Mit ein paar hundert Bytes bekommts du höchstens ein "lineares" Ablaufprogramm was im besten Fall die Prüfbits noch checkt. So wie das meiner Elektor-Uhr. Das ist simpelste Programierung. (8035 - ca. 500 Bytes) Mehr ist nicht.

Da ein residenter Treiber

1: stören kann 2: auch genauso gestört werden kann 3: stark hardwareabhängig ist,

lohnt sich so ein Spezialchip, den man nur mit einer "handvoll" Bytes bei Bedarf abfragen kann, auf jeden Fall. Siehe Conrad-Parallportuhr oder spezielle DCF-Uhrenkarten.

Allerdings ist die interne Software dieser Conraduhr ziemlicher Murks! Genauso wie die Übernahmesoftware für den PC. Die Uhr selbst hat keinerlei Plausibilitätscheck und verstellt sich bei Funkstörungen teilweise gewaltig. Sprünge von Minuten bis zu Jahren! Und die Übernahmesoftware übernimmt in ihrer Dummheit jeden noch so unmöglichen Wert. Typisch Conrad eben.

Im Gegensatz zu meiner "MouseClock". Die läuft bei mir schon seit DOS-Zeiten (1992!) über Win 3.x, WIN95 und jetzt bei WIN98SE brav als DOS-TSR und hat noch was Falsches in die PC-Uhr geschrieben. Im Gegensatz zur Conrad-Uhr, die mir 2-3 mal die Woche den PC um bis zu Jahrzehnte verstellt hat.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Und? In den meisten uC-Applikationen dürfte das noch problemlos reinpassen - notfalls braucht man halt einen größeren/schnelleren Controller. Im Vergleich zu einem DCF77-Spezial-IC ist fraglich, ob jenes wirklich billiger ist.

Das möchte ich bezweifeln. Vielleicht nicht perfekt und "garantiert sicher" (aber das kann das Spezial-IC auch nicht - DCF-77 *ist* störanfällig), aber auf jeden Fall "gut genug", um in akzeptabler Zeit eine Synchronisation hinzubekommen.

Woher willst Du das wissen?

Ich habe es bisher nur in C gemacht, und jetzt keine Lust, das bloß zum Beweis für Dich in 8051-Assembler zu kodieren, aber 10K ist bei weitem zu viel - vielleicht, wenn man einen C-Compiler für den 8051 nimmt und die falschen Optionen für den Codegenerator nimmt - das dann rauakommt, kann schrecklich aussehen (BTST).

Wozu braucht man einen Treiber? Wir reden doch von einer uC-Anwendung, oder? Also etwas, das typischerweise aus einer Applikation besteht, die nackt und ohne Betriebssystem auf dem Controller läuft?

Dann ist mit dem doppelten Aufwand auch was brauchbares machbar - ich will jetzt nicht um Bytes feilschen, aber 900 Bytes aind auch noch "ein paar Hundert" ;-)

Wie gesagt: wenn das nicht paßt, heißt es halt größerer Controller gegen Spezialchip.

Und auf den Treiber für den Spezialchip trifft das nicht zu?

Kann - das "auf jeden Fall" möchte ich bezweifeln. Anscheinend bin ich nicht der einzige, den das Angebot dieser Chips scheint der Nachfrage entsprechend eher gering zu sein.

Das Risiko hättest Du auch bei dem chip. Wenn man es selber programmiert, hat man auch die Chance, Fehler zu beheben.

Ich denke, residente Treiber sind prinzipiell unzuverlässig und störanfällig und deshalb abzulehnen?

cu Michael

Reply to
Michael Schwingen

Hallo Michael,

ich habe genau das gemacht und brauche 1134 Bytes für ein komplettes Funkuhr-System auf dem 89C2051 mit Datenübertragung auf die RS232-PC-Schnittstelle - also etwa ein Kilobyte, wenn man die Leerstellen zwischen den Interruptvektoren herausrechnet. ;o) Mehrfache Fehlerkontrolle und mitlaufende "Quarzuhr" im uC sind da mit drin und in einem Jahr Betrieb hat mir das Ding den PC nicht einmal fehlerhaft gestellt.

Ist natürlich handgefeilter Assembler-Code. :o)

Auf dem PC wäre der gleiche Code allerdings mindestens 2 bis 4 mal größer, weil die Assembler-Befehle und Adressen aus mehr Bytes bestehen

- aber auf dem PC interessiert es mich auch nicht, ob ein Programm 10 kB oder 100 kB groß ist...

Gruß,

Ed

Reply to
Edzard Egberts

Guckst Du hier im Mustershop:

formatting link

Artikel FBD06001

Die haben übrigens auch den T4227 bzw. UE6005 verbrochen und verkaufen sie sogar...

--
Olav Wölfelschneider                 usenet03q04@wosch.teratronik.com
Reply to
=?ISO-8859-1?Q?Olav_W=F6lfelsc

Hallo Wolfgang,

Wolfgang Gerber schrieb:

Die 'MouseClock' liefert aber keine decodiertes DCF Telegramm, sondern schlicht und einfach das DCF-Signal selbst. Die Decodierung läuft auf dem PC.

Gruß Martin

--
Softwarepatente? Nein, danke. Hier eintragen:
http://petition.eurolinux.org/index_html
Reply to
Martin Schoenbeck

Martin Schoenbeck schrieb:

das habe ich auch nirgends behauptet!

genau das habe ich gesagt.

Lerne bitte lesen! Und verstehen was ein DOS-TSR ist.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Hallo Wolfgang,

Wolfgang Gerber schrieb:

Nein, aber mit im Zusammenhang mit Deinen Äußerungen über das Conrad Teil und darüber, daß dieses besser läuft, konnte man das zumindest vermuten. Deine Äußerungen über Dein TSR habe ich nicht in Verbindung mit dem MouseClock TSR gebracht, weil Du da auch keine Verbindung hergestellt hast. Aber vielleicht hast Du das gemeint.

Nein, über die MouseClock hast Du das genau nirgends gesagt.

Lesen kann ich, aber meine Glaskugel ist im Eimer. Und ein TSR brauchst Du unter DOS auch, wenn die Uhr fertig aufbereitete Daten liefert, falls Du Deine Rechneruhr aktuell halten willst.

Wenn ich Deine Äußerungen jetzt also richtig interpretiere, dann wertet Dein TSR die MouseClock aus. Dafür sind 12 kB dann aber wirklich heftig viel. In 12 kB packt man ganze Betriebssystemkerne.

Gruß Martin

--
Softwarepatente? Nein, danke. Hier eintragen:
http://petition.eurolinux.org/index_html
Reply to
Martin Schoenbeck

Martin Schoenbeck schrieb:

Vermuten heist aber nichts wissen oder nichts verstanden zu haben

Es ist nicht "mein" TSR, sonder vom Hersterller der Mouseclock. Das nur nebenbei.

Ok - nicht ganz konkret. Gebe ich zu.

Wenn ich meine Uhr automatisch aktualisieren will dann ja.

Wie gesagt, es ist nicht "mein" TSR, sondern vom Hersteller. Anosonsten stimmt das. Die Mouseclock liefert nur digitale Pulse, die dem analogen DCF-Signal entsprechen. Die komplette Auswertung macht das TSR.

Wenn du das aus der Ferne beurteilen kannst was da alles drin steckt, finde ich das toll.

Es geht garantiert auch mit weniger. Nur nicht so gut! Ich habe schon so Minimaltreiber gehabt. Und nichts wie Ärger damit.

Klar - fragts ich nur wie groß der Kern defniert ist.

Und hier steckt in dem Treiber eben so viel Zeug drin wie nötig ist um einen absolut problemlosen und fehlerfreien Betrieb unter DOS und Windows zu ermöglichen. Da halte ich 12 K nicht für wesentlich zu hoch.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
 Click to see the full signature
Reply to
Wolfgang Gerber

Hallo Wolfgang,

Wolfgang Gerber schrieb:

Und deshalb habe ich auch nicht behauptet, daß Du behauptet hättest, die MouseClock liefere ein decodiertes Programm. So what.

Tja, daß es Dein TSR sei, schriebst Du nun aber nachlesbar.

Sonst brauche ich ja keine Echtzeituhr.

Ich könnte natürlich mal die Diskette von meiner MouseClock suchen. Aber nee, das muß jetzt nicht sein.

Alles, was im Kern sein _muß_, und nichts darüber hinaus.

War zu der Zeit, als die MouseClock rauskam, ja auch nicht wirklich mehr kritisch.

Gruß Martin

--
Softwarepatente? Nein, danke. Hier eintragen:
http://petition.eurolinux.org/index_html
Reply to
Martin Schoenbeck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.