DCF77

A

Alex Loipführer

Guest
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
 
"Alex Loipführer" <Loipe@t-online.de> schrieb im Newsbeitrag
news:bl8oal$k1$06$1@news.t-online.com...
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
Click to expand...
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
 
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.
Click to expand...
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.
 
Alex Loipführer schrieb:

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.
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
Franz Hornung schrieb:

und dann z.B. mittels einen Mikrocontroller das Datum und die Uhrzeit
ausgelesen werden können.

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.
Click to expand...
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 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?
Click to expand...
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 noch etwas Fehlertoleranz
Click to expand...
Vielleicht ist gut<g> "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.

einpflanzen. Die programmierung irgendeiner herstellerspezifischen
"DCF77-Schnittstelle" scheint mir da komplizierter.
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
In article <bl90s5$7a5av$1@ID-3981.news.uni-berlin.de>,
Wolfgang Gerber <nichtfuerspam@gmx.de> wrote:
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.
Click to expand...
Naja - "permanent laufen lassen" ist es ja nicht, ein Interrupt pro Sekunde
(wenn ein Timer zur Verfügung steht) ist nicht soo wild.

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.
Click to expand...
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).

Vielleicht ist gut<g> "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.
Click to expand...
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
 
Michael Schwingen 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.

Naja - "permanent laufen lassen" ist es ja nicht, ein Interrupt pro Sekunde
(wenn ein Timer zur Verfügung steht) ist nicht soo wild.
Click to expand...
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.

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.

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).
Click to expand...
Wenn es sich nicht lohnen würde, dann gäbe es das nicht.

Vielleicht ist gut<g> "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.

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:
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
In article <bl9r8c$a2c3f$2@ID-3981.news.uni-berlin.de>,
Wolfgang Gerber <nichtfuerspam@gmx.de> wrote:
2 Interrupts pro Sekunde bitte! Oder willst du nach der Anfangsflanke
per Softwareloop auf die Endflanke warten?
Click to expand...
Stimmt. Die Last, die das selbst auf einem 8MHz-8051 verursacht, dürfte aber
trotzdem zu vernachlässigen sein.

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.
Click to expand...
"permanent laufen" heißt für mich, daß die Software permanent Ressourcen,
insbesondere CPU-Zeit braucht - das ist hier wohl eher nicht der Fall.

Allein das ist schon eine "Menge". Nämlich das ganze Empfangen und
"Einsortieren" in die richtigen Register bzw. sammeln als
Kompletttelegramm.
Click to expand...
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
 
Hallo,
Von Atmel (ehemals Temic) gibt es IC's die die Uhrzeit seriell mit ca.
150 Baud als 59 Bit Datenwort ausgeben ;-)

Gruss Jochen
 
Wolfgang Berger wrote:
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.


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.
Click to expand...
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 <16C84.H>
#fuses HS,NOPROTECT,NOWDT
#include <CTYPE.H>

#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<=3; i++) in=0;
while(!sync){ // 1001 -> sync
pulseout();
shift_left(&slo,1,input(dcf_in));
if ((slo & 0x0f)== 0b00000110) // inverted
sync=1;
};
for (i=5; i<=32; i++){
pulseout();
shift_left(&in[0],3,!input(dcf_in));
};
swap(in[0]);swap(in[1]);swap(in[2]);
}

main(){
while(true){
get_time();
printf("%x %x %x\n", in[0],in[1],in[2]);
};
}
 
Michael Schwingen schrieb:

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

Stimmt. Die Last, die das selbst auf einem 8MHz-8051 verursacht, dürfte aber
trotzdem zu vernachlässigen sein.
Click to expand...
Die Last ist relativ gering. Sie ist aber permanent da. Genauso wie
der Speicherverbrauch der Software.

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.

"permanent laufen" heißt für mich, daß die Software permanent Ressourcen,
insbesondere CPU-Zeit braucht - das ist hier wohl eher nicht der Fall.
Click to expand...
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.

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

Wie gesagt: geschätzt ein paar 100 Bytes Assembler -
Click to expand...
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!

kann man mit etwas
Fleiß problemlos selber machen
Click to expand...
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.

und rechtfertigt daher IMHO nicht das
Zukaufen eines Spezialchips.
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
In article <blb5g0$a2vsc$3@ID-3981.news.uni-berlin.de>,
Wolfgang Gerber <nichtfuerspam@gmx.de> wrote:
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.
Click to expand...
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.

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!
Click to expand...
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.

kann man mit etwas
Fleiß problemlos selber machen

Du hast das noch nie gemacht! Ich schon! Mein erster "Dekoder" lief
unter Basic auf einem Z80
Click to expand...
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).

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.
Click to expand...
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?

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.
Click to expand...
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.

Da ein residenter Treiber

1: stören kann
2: auch genauso gestört werden kann
3: stark hardwareabhängig ist,
Click to expand...
Und auf den Treiber für den Spezialchip trifft das nicht zu?

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.
Click to expand...
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.

Allerdings ist die interne Software dieser Conraduhr ziemlicher Murks!
Click to expand...
Das Risiko hättest Du auch bei dem chip. Wenn man es selber programmiert,
hat man auch die Chance, Fehler zu beheben.

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
Click to expand...
Ich denke, residente Treiber sind prinzipiell unzuverlässig und
störanfällig und deshalb abzulehnen?

cu
Michael
 
Hallo Michael,

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
Click to expand...
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.

- 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).
Click to expand...
Ist natürlich handgefeilter Assembler-Code. :eek:)

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
 
Alex Loipführer wrote:
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.
Click to expand...
Guckst Du hier im Mustershop:

www.hkw-elektronik.de

Artikel FBD06001

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

--
Olav Wölfelschneider usenet03q04@wosch.teratronik.com
 
Hallo Wolfgang,

Wolfgang Gerber schrieb:
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.
Click to expand...
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
 
Martin Schoenbeck schrieb:

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.

Die 'MouseClock' liefert aber keine decodiertes DCF Telegramm,
Click to expand...
das habe ich auch nirgends behauptet!

sondern
schlicht und einfach das DCF-Signal selbst. Die Decodierung läuft auf
dem PC.
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
Hallo Wolfgang,

Wolfgang Gerber schrieb:
Martin Schoenbeck schrieb:

Die 'MouseClock' liefert aber keine decodiertes DCF Telegramm,

das habe ich auch nirgends behauptet!
Click to expand...
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.
sondern
schlicht und einfach das DCF-Signal selbst. Die Decodierung läuft auf
dem PC.

genau das habe ich gesagt.
Click to expand...
Nein, über die MouseClock hast Du das genau nirgends gesagt.

Lerne bitte lesen! Und verstehen was ein DOS-TSR ist.
Click to expand...
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
 
Martin Schoenbeck schrieb:

Die 'MouseClock' liefert aber keine decodiertes DCF Telegramm,

das habe ich auch nirgends behauptet!

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.
Click to expand...
Vermuten heist aber nichts wissen oder nichts verstanden zu haben<g>

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.
Click to expand...
Es ist nicht "mein" TSR, sonder vom Hersterller der Mouseclock. Das
nur nebenbei.

sondern
schlicht und einfach das DCF-Signal selbst. Die Decodierung läuft auf
dem PC.

genau das habe ich gesagt.

Nein, über die MouseClock hast Du das genau nirgends gesagt.
Click to expand...
Ok - nicht ganz konkret. Gebe ich zu.

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

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.
Click to expand...
Wenn ich meine Uhr automatisch aktualisieren will dann ja.

Wenn ich Deine Äußerungen jetzt also richtig interpretiere, dann wertet
Dein TSR die MouseClock aus.
Click to expand...
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.

Dafür sind 12 kB dann aber wirklich heftig
viel.
Click to expand...
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.

In 12 kB packt man ganze Betriebssystemkerne.
Click to expand...
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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.
 
Hallo Wolfgang,

Wolfgang Gerber schrieb:
Martin Schoenbeck schrieb:

Die 'MouseClock' liefert aber keine decodiertes DCF Telegramm,

das habe ich auch nirgends behauptet!

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.

Vermuten heist aber nichts wissen oder nichts verstanden zu haben<g
Click to expand...
Und deshalb habe ich auch nicht behauptet, daß Du behauptet hättest, die
MouseClock liefere ein decodiertes Programm. So what.

Es ist nicht "mein" TSR, sonder vom Hersterller der Mouseclock. Das
nur nebenbei.
Click to expand...
Tja, daß es Dein TSR sei, schriebst Du nun aber nachlesbar.

Wenn ich meine Uhr automatisch aktualisieren will dann ja.
Click to expand...
Sonst brauche ich ja keine Echtzeituhr.

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.

Dafür sind 12 kB dann aber wirklich heftig
viel.

Wenn du das aus der Ferne beurteilen kannst was da alles drin steckt,
finde ich das toll.
Click to expand...
Ich könnte natürlich mal die Diskette von meiner MouseClock suchen. Aber
nee, das muß jetzt nicht sein.

In 12 kB packt man ganze Betriebssystemkerne.

Klar - fragts ich nur wie groß der Kern defniert ist.
Click to expand...
Alles, was im Kern sein _muß_, und nichts darüber hinaus.

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.
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top