www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DCF77 Welches Modul taugt was


Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Löwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Malte M. (maltem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-(

Autor: jliegner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: Peter Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe auch das Modul von Conrad und bin sehr zufrieden damit.
Günstig und gut....

Autor: maxi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Joachim B. (jojo84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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ß

Autor: maxi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Löwe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>@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 ;)

Autor: Thomas Kiss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe schon ca. 5 ELV Module verbaut, direkt an Atmega dran,,sehr 
zufrieden damit !!. Uhr ist ca nach 1 Minute Syncron ( Nähe Stuttgart =

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver Ju. (skriptkiddy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++;
      }
    }
  }
}

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es vergeht eine Sekunde zwischen den einzelnen Bits, falls das hilft.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, mein Fehler.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist das Statusbyte 15? 14 ist ja MEZ  MESZ  usw.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis Brenzel (danrulz81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@HC Zimmerer:
O.k. Danke, das hab ich nicht gewusst.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.