Hallo zusammen, ich wollte meiner Frau eine Funkuhr auf Weihnachten schenken. Diese möchte ich natürlich selber bauen. Jetzt meine Frage: Welches Modul taugt effektiv etwas? Conrad, Reichelt oder Pollin? Ich hab schon viele Threads darüber gelesen, nur in keinen wird eine klare Aussage gemacht. Das von Reichelt und Pollin scheint ja ähnlich zu sein, beide könnte ich direkt an den Eingang meines Mega88-20 PU hängen ohne Pullup, beim Conrad mit Pullup. Alldings hab ich auch Threads gefunden, bei denen das Signal entstört werden muss. Betreiben möchte ich es mit einem 12 V DC Netzteil.
Moin, bis jetzt habe ich mit dem Conrad-Modul die besten Erfahrungen gemacht. Das Modul von Reichelt ist teurer und wesentlich empfindlicher auf alle möglichen Störungen. Außerdem ist das Ausgangssignal kaum belastbar. Derzeit habe ich das Conrad-Modul ~2cm von einem Atmega eingebaut, ohne nennenswerte Empfangsprobleme. Die Versorgungsspannung habe ich über eine Diode, Spule, Kerko und Elko noch etwas weiter geglättet, dann lässt sich das Modul ohne Murren auch aus einem China-Schaltnetzteil betreiben.
Dennis Brenzel schrieb: > Welches Modul taugt effektiv etwas? Wenn Du etwas RICHTIG vernünftiges suchen solltest: http://www.hkw-elektronik.de/shop/artikel/FUM-DCF.php Keine Angst, trotz der internen (sehr zuverlässigen) Dekodierung gibt es bis Weihnachten noch genug zu tun/programmieren...
Harald schrieb: > Dennis Brenzel schrieb: >> Welches Modul taugt effektiv etwas? > > Wenn Du etwas RICHTIG vernünftiges suchen solltest: > http://www.hkw-elektronik.de/shop/artikel/FUM-DCF.php > > Keine Angst, trotz der internen (sehr zuverlässigen) Dekodierung gibt es > bis Weihnachten noch genug zu tun/programmieren... Dieses Modul sieht sehr interessant aus, allerdings kenn ich mich mit Serial Interface garnicht aus (ist das SPI)? Ich programmiere in Bascom, dort wollte ich die vorhanden DCF77 Funktion verwenden. Hast du dieses Modul schon in Betrieb? Erfahrungen? @Löwe: Betreibst du dein Modul direkt am µC oder hast du noch eine Schaltung davor? Falls ja, könntets du mal deine Schaltung posten, wenn du eine Zeichnung zur Hand hast?
Abraten kann man auf jeden Fall vom Pollin-Modul: Das ist nicht preiswert, sodern einfach nur billig. Zum einen ist es etwas pienzig was die Versorgung betrifft, zum andern ist der Empfang sehr mäßig. Zudem hat Pollin irgendwann mal die Hardware geändert, ohne das Datenblatt zu überarbeiten, so das man beim Anschließen raten darf.
Malte M. schrieb: > Abraten kann man auf jeden Fall vom Pollin-Modul: Das ist nicht > preiswert, sodern einfach nur billig. > Zum einen ist es etwas pienzig was die Versorgung betrifft, zum andern > ist der Empfang sehr mäßig. Zudem hat Pollin irgendwann mal die Hardware > geändert Der Meinung kann ich mich nur anschließen. Ich hatte diesbezüglich mal bei Pollin angefragt, ob man die alte Hardwareversion (die deutlich besseren Empfang hatte) nicht wieder ins Lieferprogramm aufnehmen kann. Antwort: Nein. :-(
Es gibt auch von ELV ein Modul (DCF-2) für knapp 10€. Da ist im Gegensatz zu dem von Reichelt und Pollin noch was zur Siebung der Versorgungsspannung und ein Transistor für den Ausgang mit auf der Platine. Da es auch noch billiger ist als das von Reichelt sicherlich die bessere Wahl. Zum Empfang kann ich nichts sagen. http://www.elv-downloads.de/Assets/Produkte/9/916/91610/Downloads/91610_DCF_Empfangsmodul_DCF_2_DS.pdf
Hat denn jemand hier schon praktische Erfahrungen mit den HKW-Modulen sammeln können und kann davon berichten? Bislang habe ich immer nur gelesen, dass sie gut sein SOLLEN (nach dem Motto: ich hab mal gehört, dass...)
Habe auch das Modul von Conrad und bin sehr zufrieden damit. Günstig und gut....
Hallo Fachleute, habe ein DSO 062 von jyetech.com und möchte dieses erweitern, denn auf der Platine ist J7 mit 2 OP´s vorbereitet damit das Oszi auch Analoge Signale ausgeben kann. Hat jemand Infos wo ich die Werte für die Widerstände finden kann, denn auf dem Schaltplan sind die Werte nicht ersichtlich. Hat schon jemand diesen Port J7 genutzt?
@maxi: warum postest du 2x ? Es geht ja um dieses Thema: Beitrag "Oszilloskop erweitern" @Dennis: also ich muß zugeben, daß ich noch keinen Vergleich mit anderen DCF-Modulen treffen kann. Aber ich hab die Dinger von Pollin jeweils (alte und neue HW-Version) erfolgreich in Betrieb nehmen können. Filtern mußt du das Signal eh, per SW oder HW. Und außerdem gibt es doch schon seit geraumer Zeit das aktuelle Datenblatt von Pollin. Zumindest habe ich hier zwei verschiedene... Daß sich die Module etwas seltsam verhalten (überlagertes Sägezahnsignal auf den steigenden Flanken z.B.) ist natürlich unumstritten ;) ... Aber ist eben nur "Alles eine Frage der Technik!" ... Gruß
Joachim B. schrieb: > @maxi: > warum postest du 2x ? Es geht ja um dieses Thema: > Beitrag "Oszilloskop erweitern" Sorry, aber ich habe mich vertan und weis auch nicht in welchem Forum ich Hife bekommen kann, denn es gibt kein Forum indem sich die Fachleute mit dem DSO 062 befassen. vieleicht kennt jemand ein Forum indem dieses OSzi behandelt wurde oder wird. Beim Googeln habe ich nichts gefunden. Danke Maxi
Joachim B. schrieb: > Daß sich die Module etwas seltsam > verhalten (überlagertes Sägezahnsignal auf den steigenden Flanken z.B.) > ist natürlich unumstritten ;) ... Aber ist eben nur "Alles eine Frage > der Technik!" ... Es sollte so einfach wie möglich sein, da meine elktronischen Kenntnisse auf das nötigste beschränken (Ohmschesgesetz, Was ist ist ein...Transistor, Kondensator, Diode,...). Als Eingang der Betriebsspannung wollte ich den Aufbau des AVR-Tutorials verwenden. Ist dieser schon genügend entstört?
Ich lese erst jetzt wieder mit: Ich habe tatsächlich Erfahrungen mit dem HKW-Modul gesammelt. Es hat eine serielle Schnittstelle mit 300 Baud, die Zeit und das Datum, Wochentag und Status kommen als normale serielle Zeichen heraus. Die Zeit wird nachts empfangen (eben dann wenn der LW-Empfang gut bzw. überhaupt brauchbar funktioniert), der Rest des Tages wird mit der internen Quarz-Uhr weitergearbeitet. Das macht das Modul sehr sparsam und eignet sich somit auch für Batteriebetrieb. So macht das übrigens jede handelsübliche Funkuhr. Beim Anlegen der Betriebsspannung wird natürlich sofort ein Empfangsversuch gemacht, unabhängig von der Uhrzeit (klaro). Näheres kann man dem Datenblatt entnehmen. http://www.hkw-elektronik.de/pdfdeutsch/FUM-dcf.pdf www.hkw-elektronik.de/pdf/fmd01001_sd.pdf Jedenfalls sind die Module sehr empfangszuverlässig und bieten am Ausgang verifizierte Daten. Der Mehrpreis von ein paar Euros erspart eine Menge Frust (siehe x tausend Beiträge hier im Forum). Die Schnittstelle ist invertiert, d.h. man kann zum Test direkt auf den Eingang einer RS232 gehen. Der Pegel von 3V reicht meist gerade so aus.
Die invertierte Schnittstelle bietet noch einen Vorteil bei der Pegelkonvertierung (das Modul kann autark mit Batterien vorsorgt werden, evtl. sogar als abgesetzte Einheit). Einfach die Basis eines simplen NPN-Transistor über einen Widerstand an den Ausgang des Moduls. Emitter auf GND und den Kollektor an den RX-Portpin des µCs (bei diesem den internen Pullup aktivieren). Fertig ist die stets passende Pegelkonvertierung vom Modul zum µC unabhängig von der Höhe der µC Spannungsversorgung.
Hallo Harald, das Datenblatt hatte ich auf der Seite nicht gefunden. Wie ich diesem entnehmen kann, muss ich selber eine Antenne anschließen. Was brauch ich dazu? Wie hast du das realisiert?
Hallo Dennis, ich empfehle eine der auf der HKW-Seite angebotenen Antennen, z.B. diese hier: http://www.hkw-elektronik.de/pdfdeutsch/AFET60-DCF.pdf Die Datenblätter sind in der Tat versteckt, ich suche sie immer in Google, indem ich die HKW-Artikelnummer eingebe und die Suche auf die Extension PDF beschränke, also z.B. so "FTD02011R ext:pdf" Ich habe die 10x60mm Version genommen, die kleinere geht natürlich auch, allerdings dürfte die Empfindlichkeit darunter leiden. Es düften aber auch andere DCF-Spulen+Kondensator funktionieren.
Hallo Harald, super, vielen Dank, du hast mir echt weiter geholfen. Jetzt hätte ich nur noch eine kleine Frage: > Es hat eine serielle Schnittstelle mit 300 Baud, die Zeit und das Datum, > Wochentag und Status kommen als normale serielle Zeichen heraus. Wird das Byteweise mit bestimmten Pausen gesendet, oder als ganzes? Ich programmiere ja in Bascom, und UART-Empfang ist für mich absolutes Neuland. Das DCF Signal besteht ja aus 38 Binären Zeichen. Das wird ja dann in Hex umgewandelt und seriell ausgegeben, oder bin ich da auf dem Holzweg? Mir stellt sich halt die Frage, wie ich das Softwaretechnisch umsetzen kann, zumal ich nicht genau weiß, ob ich immer nur ein Byte bzw. den ganzen Code aufeinmal in eine Variable speichern kann.
Angehängte Dateien:
-
DCF_VCC.png
3,7 KB
>@Löwe: >Betreibst du dein Modul direkt am µC oder hast du noch eine Schaltung >davor? Falls ja, könntets du mal deine Schaltung posten, wenn du eine >Zeichnung zur Hand hast? Moin, am Modul nutze ich den nicht invertierten Ausgang. An diesem Pin befindet sich ein 10k Pullup, sonst nichts. Anschlossen habe ich das ganze am Int0-Pin von einem Atmega 8, im Atmega sind keine Pullups etc. aktiviert. Als Anhang mal die Stromversorgung vom Modul, damit habe ich bis jetzt sehr gute Erfahrungen gemacht. Schaltungstechnisch mag das Blödsinn sein, aber es funktioniert ;)
Habe schon ca. 5 ELV Module verbaut, direkt an Atmega dran,,sehr zufrieden damit !!. Uhr ist ca nach 1 Minute Syncron ( Nähe Stuttgart =
Stuttgart ist aber um einiges näher am DCF77 empfänger, als Schopfheim, wo ich wohne. Das ist 20 km nordöstlich von Basel(Schweiz).
Dennis Brenzel schrieb: > Wird das Byteweise mit bestimmten Pausen gesendet, oder als ganzes? Ich > programmiere ja in Bascom, und UART-Empfang ist für mich absolutes > Neuland. Das DCF Signal besteht ja aus 38 Binären Zeichen. Das wird ja > dann in Hex umgewandelt und seriell ausgegeben, oder bin ich da auf dem > Holzweg? Mir stellt sich halt die Frage, wie ich das Softwaretechnisch > umsetzen kann, zumal ich nicht genau weiß, ob ich immer nur ein Byte > bzw. den ganzen Code aufeinmal in eine Variable speichern kann. > Du bekommst richtig die Uhrzeit als fertigen ASCII String, das hat mit dem ursprünglichen DCF-Signal nichts mehr zu tun. Die Ziffern 0..9 sind als Hex-Zahl 0x30..0x39. Du brauchst also nur 0x30 abziehen, wenn Du die Stunden in Minuten "einzeln" als rohe Zahl haben möchtest. Am Ende einer Sendung kommt noch ein 0x0D (CR bzw. Enter) hinterher, daran kann man die Trennung der sich wiederholenden Zeichenketten klarmachen. Einfach den Modulausgang X4 (RS232 out) an Pin 2 einer SUB-D 9pol. Buchse (Pin 5 der SUBD-9 an Masse) und schon könntest Du mittels Hyperterminal am PC die Uhrzeit in Klartext sehen. Wenn Du z.B. ein stinknormales Zeichendisplay am µC hast (z.B. so ein 2x16Zeichen-Ding), könntest Du die Bytes vom Modul direkt ohne Bearbeitung zum Display senden und Du würdest bereits die Uhrzeit und Datum sehen. Ein solches Zeichendisplay arbeitet ja auch mit normalen ASCII Zeichen. Klar, man müsste den String noch etwas mit Doppelpunkten und Punkten aufhübschen.
Harald schrieb: > Du brauchst also nur 0x30 abziehen, wenn Du die > Stunden in Minuten "einzeln" als rohe Zahl haben möchtest. Ich meinte natürlich: Wenn Du die Stunden UND Minuten (und Sekunde, Tag, Monat und Jahr und Wochentag) als rohe Zahl haben möchtest, ziehst Du von der übertragenen Zahl jeweils 0x30 ab.
Meine Meinung zu den Pollin-Modulen: Finger Weg - die bereiten nur unnötige Probleme. Ist wirklich so. Es mag zwar hunderte Sachen geben, mit denen man bei Pollin ein Schnäppchen machen kann, aber diese billgigen DCF77-Module gehören meiner Meinung nach nicht zu den Schnäppchen. Das was diese Teile empfangen haben, das war kein Signal, sondern ein Zittern. Gruß Skriptkiddy
Das mit dem String hab ich schon verstanden, doch ich kann im UDR Register ja nur 1 Byte speichern. Wenn das schon in Hex decodierte Signal übertragen wird, wird ja immer nur ein Byte im UDR abgelegt, welches ich dann in eine Variable speichern muss, die ich dann auf dem Display ausgebe.
Dennis Brenzel schrieb: > doch ich kann im UDR Register ja nur 1 Byte speichern. Das reicht doch. > Wenn das schon in Hex decodierte Signal übertragen wird, > wird ja immer nur ein Byte im UDR abgelegt, welches ich > dann in eine Variable speichern muss, die ich dann auf dem > Display ausgebe. Korrekt. Ascii-Zeichen läuft ein, auslesen und ab aufs Display. Oder wenn noch nachbearbeitet werden soll, vorher in einen Bereich im SRAM ablegen. In Assembler einfach, der AVR hat dafür Befehle schon drin, in C (WinAVR) gibt es eine Reihe von Stringfunktionen. Gruß Jadeclaw.
oder man baut sich die das DCF77-Modul selbst. Mit dem CME6005 hatte ich sehr gute Ergebnisse. Der CME8000 macht die Dekotierung selbst und die Daten können dann seriell gelesen werden. Die Teile gibt es bei Digikey ( 2,95 EUR kostet der CME6005 ). http://www.c-max-time.com/products/productsOverview.php?catID=1
Jadeclaw Dinosaur schrieb: >> Wenn das schon in Hex decodierte Signal übertragen wird, >> wird ja immer nur ein Byte im UDR abgelegt, welches ich >> dann in eine Variable speichern muss, die ich dann auf dem >> Display ausgebe. > Korrekt. Ascii-Zeichen läuft ein, auslesen und ab aufs Display. > Oder wenn noch nachbearbeitet werden soll, vorher in einen Bereich > im SRAM ablegen. In Assembler einfach, der AVR hat dafür Befehle schon > drin, in C (WinAVR) gibt es eine Reihe von Stringfunktionen. Es laufen ja aber nacheinander mehrere ASCII-Zeichen ein. Ich muss ja das erste ASCII-Zeichen speichern, dann das zweite usw. Bis ich alle gespeichert habe, liegt ja kein Signal mehr an, das in das UDR des µC geschrieben werden kann, oder hab ich da etwas falsch verstanden.
Dennis Brenzel schrieb: > Es laufen ja aber nacheinander mehrere ASCII-Zeichen ein. Irgendwie ist dein Problem gerade ein anderes. Bei einem nackten DCF-Signal kommen die Signale auch ja nacheinander ohne das Du etwas dagegen tun könntest. Zwischenspeichern kann man in jeder Programmiersprache und mit jedem Controller, das ist ja quasi eine DER Standardaufgaben für einen µC. Ich möchte Dir nicht zu nahe treten, aber mit diesem Kenntnisstand wuerde ich Dir bis Weihnachten sogar ganz dringend den Rat zum HKW-Modul geben, die Dekodierung zu Fuß würdest Du bis Weihnachten wahrscheinlich nicht schaffen... Mit welcher Programmiersprache möchtest Du das realisieren? In einer generischen Beschreibung sieht das ungefähr so aus int8 buffer[8]; int8 ptr=0; while (FOREVER) { if (NEUES_ZEICHEN_IM_UDR) { if (UDR == 0x0D) { ... NEUER_STRING_VOLLSTAENDIG_IM_BUFFER BUFFER_VERARBEITEN_-->DISPLAY? ptr = 0; } else { buffer[ptr] = UDR; if (ptr < 8) { ptr++; } } } }
Habe es gerade noch einmal ueberfolgen, so geht es nicht.
Aber so (ungefähr):
int8 buffer[8];
int8 ptr=0;
int8 zeichen;
while (FOREVER)
{
if (NEUES_ZEICHEN_IM_UDR)
{
zeichen = UDR;
if (zeihen == 0x0D)
{
...
NEUER_STRING_VOLLSTAENDIG_IM_BUFFER
BUFFER_VERARBEITEN_-->DISPLAY?
ptr = 0;
}
else
{
buffer[ptr] = zeichen;
if (ptr < 8)
{
ptr++;
}
}
}
}
Man darf den UDR nämlich nicht doppelt auslesen, was das Problem des
ersten Vorschlags war.
Hallo Harald, stimmt, genau, dort werden ja die Zeiten als Nullen und Einsen intepretiert. Ich dachte halt, dass das Modul den Code empfängt, komplett in eine String umwandelt und den String sendet. Ich wollte es mit Bascom machen, da es dort unter anderem ein DCF - Funktion gibt, die das decodieren übernimmt. Weißt du grad, wieviel Zeit zwischen den einzelnen Bytes vergeht?
Es vergeht eine Sekunde zwischen den einzelnen Bits, falls das hilft.
Dennis Brenzel schrieb: > Ich dachte halt, dass das Modul den Code empfängt, > komplett in eine String umwandelt und den String sendet. Aber genau das macht es doch. Wo liegt das Missverständnis? Dennis Brenzel schrieb: > Weißt du grad, wieviel Zeit > zwischen den einzelnen Bytes vergeht? Das Modul sendet die x Bytes direkt nacheinander, bei 300 Baud bleibt natürlich noch sehr viel Zeit um den Wert zu speichern. Nach den x Bytes gibt es eine längere Lücke, bevor der nächste Frame in der nächsten Sekunde losgeht.
Steffen schrieb: > oder man baut sich die das DCF77-Modul selbst. Mit dem CME6005 hatte ich > sehr gute Ergebnisse. Der CME8000 macht die Dekotierung selbst und die > Daten können dann seriell gelesen werden. > Die Teile gibt es bei Digikey ( 2,95 EUR kostet der CME6005 ). > > http://www.c-max-time.com/products/productsOvervie... Die ICs finde ich persönlich hochinteressant, allerdings dürfte das das Projekt von Dennis sprengen.
Das DCF77-Impulsdiagramm hat Ihr bestimmt schon gefunden? http://de.wikipedia.org/wiki/DCF77 Bei ungünstigem Empfang sollte man die Antenne möglichst weit vom störfreudigem LED-Display anordnen und die Zeit nachts kurz NACH 3:00 Uhr holen damit es keiner merkt, wenn das Display während des Empfangs kurz ausgeschaltet werden muß. Da Sommer/Winterumstellung 3:00 Uhr erfolgt wäre das Holen der Zeit nach 3:00 Uhr günstig, da die Uhr sonst einen Tag falsch geht. Eine Plausibilitätsprüfung der Werte wäre vor der Übernahme auch sehr nützlich um solche Zeiten wie 73 Uhr 65 zu vermeiden.
Okay, Mißverständnis. Beim direkten, undecodierten DCF-Empfänger kommt ein Bit in der Sekunde an. Beim HKW-Modul ist das natürlich anders, da kommen Bytes, wie von Harald richtig erklärt.
Dennis Brenzel schrieb: > Hallo Harald, > stimmt, genau, dort werden ja die Zeiten als Nullen und Einsen > intepretiert. Ich dachte halt, dass das Modul den Code empfängt, > komplett in eine String umwandelt und den String sendet. Macht es ja, das jeweilige Zeichen kann dann im UDR abgeholt werden. Es gibt im UCSRA-Register ein Bit(7), das wird gesetzt, wenn ein Byte komplett empfangen wurde, wird das Byte aus dem UDR gelesen, wird dieses Bit zurückgesetzt. Das nächste einlaufende Byte überschreibt den Inhalt vom UDR und setzt eben wieder das Bit7 im UCSRA-Register. Grundsätzlich wird der Inhalt vom UDR überschrieben, wenn neue Daten einlaufen. 30 Zeichen pro Sekunde sollten auch in Bascom kein Problem darstellen. > Ich wollte es mit Bascom machen, da es dort unter anderem ein DCF - > Funktion gibt, die das decodieren übernimmt. Weißt du grad, wieviel Zeit > zwischen den einzelnen Bytes vergeht? Die DCF-Funktion erwartet einen nackten DCF-Empfänger, der die Impulsfolge, so wie sie vom Sender empfangen wurde, auch hinten wieder herausgibt. Sprich, die unterschiedlich langen Sekunden-Impulse. Das HKW-Modul übernimmt die Dekodierung, dafür geht die DCF-Funktion nicht. Gruß Jadeclaw.
oszi40 schrieb: > Da Sommer/Winterumstellung 3:00 Uhr erfolgt wäre das Holen der Zeit nach > 3:00 Uhr günstig, da die Uhr sonst einen Tag falsch geht. > Das wurde bei der Auslegung des DCF-Protokolls berücksichtigt. Dafür gibt es "Ankündigungsbit" für die geplante Umstellung. In dieser Situation prüft der intelligente Empfänger (wie z.B. die Module von HKW) die Zeit zum richtigen "Zeitpunkt" um jederzeit die richtige Zeit anzuzeigen. > Eine Plausibilitätsprüfung der Werte wäre vor der Übernahme auch sehr > nützlich um solche Zeiten wie 73 Uhr 65 zu vermeiden. > Auch das wird vom HKW-Modul gemacht. Es wird (habe ich aus einem Gespräch erfahren) aufeinanderfolgende Minuten miteinander verglichen, um die Plausibilität zu gewährleisten. Daher haben handelsübliche Uhren auch erst nach 2..3 Minuten eine gültige Zeit, obwohl das ja worst-case theoretisch schon nach 1:59min möglich wäre.
Bevor hier der falsche Eindruck entsteht: Ich habe nichts mit der Firma HKW zu tun! Ich finde die Module einfach nur gut, da sie genau das bereits berücksichtigen, was man zu Fuß nach dem ersten Erfolgselebnis (Dekodierung läuft) mühsam durch Beobachtung und Debugging erlernen muss. Viele Probleme erkennt man auch erst nach Wochen oder Monaten.
Jadeclaw Dinosaur schrieb: > Dennis Brenzel schrieb: > Die DCF-Funktion erwartet einen nackten DCF-Empfänger, der die > Impulsfolge, so wie sie vom Sender empfangen wurde, auch hinten wieder > herausgibt. Sprich, die unterschiedlich langen Sekunden-Impulse. Das > HKW-Modul übernimmt die Dekodierung, dafür geht die DCF-Funktion nicht. Ja, das habe ich schon verstanden. Jetzt nur als Beispiel: Es ist 14:05:13 Uhr. Dann sendet das Modul ja erst ein ein 0E, das UDR in Variable a schreiben, UCSRA Bit 7 = 0, dann nach 0,033 Sekunden (30 Zeichen pro Sekunde = 1 Zeichen alle 0,033 Sekunden), ein 05, UDR ins Variable B schreiben, UCSRA Bit 7 = 0, 0,033 s Pause, dann ein 0D, in Variable c schreiben, UCSRA Bit 7 = 0. Dann a:b:c auf dem Display ausgeben. Oder habe ich das falsch verstanden?
Dennis Brenzel schrieb: > Oder habe ich das falsch verstanden? Ja! Das Modul sendet im Falle 14:05:13 0x31 0x34 0x30 0x05 0x31 0x33 Dein Beispiel hinkt aber etwas, weil das Modul folgendes sendet: 1. Stundenzehner 2. Stundeneiner 3. Minutenzehner 4. Minuteneiner 5. Sekundenzehner 6. Sekundeneiner 7. Wochentag 1 (Montag) ... 7 (Sonntag) 8. Tageszehner 9. Tageseiner 10. Monatszehner 11. Monatseiner 12. Jahreszehner 13. Jahreseiner 14. Bits 16 ... 19 des DCF77-Protokolls 15. Status 16. 0x0D Das ist also ungefähr folgender String für 15:34:21 Uhr am 03.12.2010 (Freitag=Tag5) 0x31 0x35 0x33 0x34 0x22 0x21 0x35 0x30 0x33 0x31 0x32 0x31 0x10 0x3n 0x3m 0x0D wobei n=Bits aus DCF-Byte 14 und m=Bits aus Status Byte 15
Fehler, es muss lauten: 0x31 0x35 0x33 0x34 0x32 0x31 0x35 0x30 0x33 0x31 0x32 0x31 0x10 0x3n 0x3m 0x0D 0x30 ... 0x39 sind übrigens die ASCII-Codes für die Zahlen 0..9
O.k. abgesehen davon, dass ich nicht weiß, was mit dem Statuybyte übertragen wird, hab ich noch eine Frage: Sobald ich etwas im UDR empfangen habe, geht das UDRE Register auf 0. Dann muss ich das UDR speichern. Bei UDRE=0 sollte am besten ein Interrupt auftreten, der mir UDR speichert. Muss ich dann das UDR mit null beschreiben, oder wird das automatisch geleert? Und wie läuft das analog mit UDRE? geht das automatisch wieder auf 1, wenn UDR leer ist?
Hallo Dennis, ich kann nicht ganz nachvollziehen, warum Du ausgerechnet das Statusbyte 15 nicht deuten kannst. Die Belegung steht doch haarklein im Protokoll (Link s.o.) beschrieben. OK, ich machs: 15. Status Bit7 Parität Bit6 immer 0 Bit5 immer 1 Bit4 immer 1 Bit3 =1 wenn Batteriespannung zu niedrig Bit2 =1 wenn ein Funkempfang erfolglos abgebrochen wurde und noch keine gültige Zeitinformation vorliegt. Das kann nach Reset bei schlechten Empfangsbedingungen vorkommen. Dieses Bit wird beim ersten erfolgreichen Empfang rückgesetzt und bleibt dann 0. Bit1 =1 wenn der vorhergehende Empfangsversuch erfolgreich war =0 wenn der vorhergehende Empfangsversuch nicht erfolgreich war Bit0 =1 wenn eine gültige Zeitinformation vorliegt Dieses Bit ist nach Reset =0 und wird mit dem ersten erfolgreichen Empfangsversuch gesetzt. --- Ich kann im Thread leider nicht entdecken, in welcher Sprache Du programmierst. Mit dem Auslesen von UDR wird UDRE automatisch behandelt, darum muss man sich nicht kümmern. Auf keinen Fall versuchen, den Inhalt von UDR mehr als einmal auszulesen, das kann (wird) schiefgehen. Falls man es im Verlauf mehrere Male benötigt, den Inhalt in einer temporären Variable speichern. Interrupts siehe Tutorials deiner bevorzugten Programmiersprache. Egal ob C, Assembler oder BASCOM, davon gibt es im Netz haufenweise Zeug.
Hallo Harald, Danke nochmals für die Erklärung. Ich hab nicht im Protokoll des Moduls geschaut, sondern hab versucht, das aus der Codierung fürs DCF Signal herauszufinden. Ich weiß nicht, welcher Gaul mich da geritten hat. Programmieren tu ich in BASCOM, mit Interrupts komm ich zurecht. Das mit dem mehr als einmal auslesen hab ich aus deinem Code schon herauslesen können, aber danke nochmals für den Hinweis. Und danke auch für die Registererklärung.
Dennis Brenzel schrieb: > Sobald ich etwas im UDR empfangen habe, geht das UDRE Register auf 0. Nein. UDRE ist fürs Senden zuständig, siehe Datenblatt. Das Registerbit RXC ist es, das Dir mitteilt, dass Du UDR auslesen solltest, und zwar bitteschön bevor das nächste Zeichen fertig eingetrudelt ist.
Haste Recht, ich hatte mir die Flags lange nicht mehr angeschaut da ich mich auf langjährig getestete C-Libs verlasse. Ich hatte mich einfach auf die Angaben von Dennis konzentriert.
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.