Discussion:
DCF77-Decoder in VHDL - Any Hints?
(zu alt für eine Antwort)
Florian E. Teply
2007-05-03 17:30:33 UTC
Permalink
Moinsen Elektroniker,

Ich hab gerade die Aufgabe bekommen, nen DCF77-Decoder in VHDL auf nem
FPGA (Xilinx Spartan 3 falls das interessiert) zu implementieren. Dem
einen oder anderen wird das sicher bekannt vorkommen, ist ja ne beliebte
Projektaufgabe für den Entwurf digitaler Systeme an Hochschulen... ;-)

Ein paar Gedanken hab ich mir dazu schon gemacht. Ich bekomme das
demodulierte DCF77-Signal als Logiklevel angeliefert und darf das dann
mit dem FPGA auswerten und auf ner vierstelligen 7-Segment-Anzeige
wahlweise als Datum oder Uhrzeit ausgeben. Die Dekodierung ist soweit ja
auch kein großes Problem, die nötigen Ziffern liegen ja im Signal schon
BCD-kodiert und mit nem Paritätsbit an definierter Stelle vor. Was mir
momentan Schwierigkeiten bereitet, ist die Synchronisation, a) auf den
Sekundentakt der Trägerabsenkung und b) auf die ausbleibende Absenkung
in der 59. Sekunde als Minutenmarke und Startsignal für die nächste
vollständige Übertragung sowie c) die Auswertung der Länge der
Absenkungen (die ja der Informationsträger ist).
Zu a) müsste man ja quasi nur die fallende Flanke als Taktsignal
"missbrauchen" und intern die fehlende 60. Flanke generieren.
Für b) und c) bräuchte man allerdings ne Zeitmessung, bei b) für die
Dauer zwischen zwei fallenden Flanken und bei c) für die Dauer zwischen
fallender und darauffolgender steigender Flanke.
Die eigentliche Dekodierung ist dann ja eher nur noch ne Fingerübung,
die anfallenden Daten in ein Schieberegister schieben und bei dem
Minutensignal passend auf die Ausgabepins schicken (evtl. vorher noch
durch nen BCD-zu-7-Segment-Dekoder), vereinfacht ausgedrückt.

Hat vielleicht jemand von euch nen Tip für die angesprochene
Synchronisation bzw. für das Timing??

Gruß
Florian
Heiko Lechner
2007-05-03 18:47:12 UTC
Permalink
Post by Florian E. Teply
Hat vielleicht jemand von euch nen Tip für die angesprochene
Synchronisation bzw. für das Timing??
Mit einem externen Takt den Eingang Samplen, durch den externen Takt
hast du eine Zeitbasis.
Wolfgang Gerber
2007-05-03 21:08:43 UTC
Permalink
Post by Heiko Lechner
Post by Florian E. Teply
Hat vielleicht jemand von euch nen Tip für die angesprochene
Synchronisation bzw. für das Timing??
Mit einem externen Takt den Eingang Samplen, durch den externen Takt
hast du eine Zeitbasis.
Und? Was soll das? Er braucht keine Zeitbasis! Die hat er mit dem
DCF-Signal. Wenn er es gefiltert hat. Er muss dazu erst mal die
Impulse sammeln und auswerten. Dazu reichen einfache Monos oder Timer.

Das richtige Dekodieren und die intelligente Fehlerbehandlung sind die
Aufgabe!


Gruss Wolfgang
--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.
Heiko Lechner
2007-05-04 06:53:23 UTC
Permalink
Post by Wolfgang Gerber
Er braucht keine Zeitbasis!
Dazu reichen einfache Monos oder Timer.
Ja und wie bekommt er einen Timer ohne externen Takt und Zählern?
Gernot Fink
2007-05-03 20:54:24 UTC
Permalink
Post by Florian E. Teply
Moinsen Elektroniker,
momentan Schwierigkeiten bereitet, ist die Synchronisation, a) auf den
Sekundentakt der Trägerabsenkung und b) auf die ausbleibende Absenkung
in der 59. Sekunde als Minutenmarke und Startsignal für die nächste
vollständige Übertragung sowie c) die Auswertung der Länge der
Absenkungen (die ja der Informationsträger ist).
Nimm einen Zähler der jede sekunde überläuft.
Wenn der DCF-Puls kommt resette den Timer.
wenn er geht vergleiche den Zähler mit 0.15 sec -> das ist ein Datenbit.
wenn das vorderste bit deines Zählers auf 1 springt ohne dass ein
DCF-puls da war setze den bitpointer auf 59.
wenn das vorderste bit deines Zählers auf 0 springt zähle den bitpointer
hoch.
wenn alle datenbits korrekt empfangen sind kopiere die daten in einen
Zeitdatensatz.
wenn das vorderste bit deines Zählers auf 0 springt zähle 1 sekunde.
--
MFG g.fink
Wolfgang Gerber
2007-05-03 21:08:05 UTC
Permalink
Post by Florian E. Teply
Ich hab gerade die Aufgabe bekommen, nen DCF77-Decoder in VHDL auf nem
FPGA (Xilinx Spartan 3 falls das interessiert) zu implementieren. Dem
einen oder anderen wird das sicher bekannt vorkommen, ist ja ne beliebte
Projektaufgabe für den Entwurf digitaler Systeme an Hochschulen... ;-)
Ja - schon seit bestimmt über 25 Jahren. Damals noch in Basic auf dem
PET <g>
Post by Florian E. Teply
Ein paar Gedanken hab ich mir dazu schon gemacht. Ich bekomme das
demodulierte DCF77-Signal als Logiklevel angeliefert und darf das dann
mit dem FPGA auswerten und auf ner vierstelligen 7-Segment-Anzeige
wahlweise als Datum oder Uhrzeit ausgeben.
ACK
Post by Florian E. Teply
Die Dekodierung ist soweit ja
auch kein großes Problem,
doch - viel mehr als du dir denkst
Post by Florian E. Teply
die nötigen Ziffern liegen ja im Signal schon
BCD-kodiert und mit nem Paritätsbit an definierter Stelle vor.
Schön wäre es wenn es so einfach wäre. Theoretisch ist es das. Du
musst aber mit allen möglichen Fehlern rechnen und das alles
berücksichtigen. Und dann wird es doch ziemlich aufwendig. Wenn ich an
meine altes Flussdiagramm meiner Elektor-Uhr denke wird mir jetzt noch
anders.
Post by Florian E. Teply
Was mir
momentan Schwierigkeiten bereitet, ist die Synchronisation, a) auf den
Sekundentakt der Trägerabsenkung
Kinderspiel
Post by Florian E. Teply
und b) auf die ausbleibende Absenkung
in der 59. Sekunde als Minutenmarke und Startsignal für die nächste
vollständige Übertragung
Kinderspiel
Post by Florian E. Teply
sowie c) die Auswertung der Länge der
Absenkungen (die ja der Informationsträger ist).
Kinderspiel
Post by Florian E. Teply
Zu a) müsste man ja quasi nur die fallende Flanke als Taktsignal
"missbrauchen" und intern die fehlende 60. Flanke generieren.
genau - mit jeder fallenden Flanke werden mehrere Monos bzw. Timer
getriggert.

z.B. eines mit 0,15 Sekunden

Kommt die steigende Flanke vor dem Ablauf, dann war es ein kurzer
Puls. Kommt sie danach war es ein langer Puls

ein weteres für den Minutenpuls.

Kommt die steigende Flanke nach > 1,5 Sekunden ist es der
0-Minutenpuls

Wahrscheinlich - kann aber auch eine Empfangsstärung sein.

Wobei wir beim Thema sind!
Post by Florian E. Teply
Für b) und c) bräuchte man allerdings ne Zeitmessung,
ja und?
Post by Florian E. Teply
bei b) für die
Dauer zwischen zwei fallenden Flanken und bei c) für die Dauer zwischen
fallender und darauffolgender steigender Flanke.
Nö - siehe oben.
Post by Florian E. Teply
Die eigentliche Dekodierung ist dann ja eher nur noch ne Fingerübung,
Nö - das erkennen der Pulse und längen ist einfach. Also das, was
bisher war.

Jetzt erst wird es richtig happig. Zumindest wenn die Uhr immer
richtig anzeigen soll.
Post by Florian E. Teply
die anfallenden Daten in ein Schieberegister schieben und bei dem
Minutensignal passend auf die Ausgabepins schicken (evtl. vorher noch
durch nen BCD-zu-7-Segment-Dekoder), vereinfacht ausgedrückt.
Vergiss das mit dem Schieberegister - das gibt nur Müll!
Post by Florian E. Teply
Hat vielleicht jemand von euch nen Tip für die angesprochene
Synchronisation bzw. für das Timing??
Das wurde schon mindestens 100 mal diskutiert. Und es gibt mindestens
genaso viele Abhandlungen darüber bis hin zu kompletten
Flussdiagrammen und Listings.

Du siehst die Aufgabe als viel zu einfach. Und sie wäre es, wenn das
alles saubere Signale wären. Sind es aber nicht. Was da aus der Luft
kommt ist "Müll". Oder zumindest immer wieder mit Müll gespickt.

Du brauchst etwa 10 mal soviel Code für die Fehlererkennung und
Korrektur wie für die einfache Dekodierung. Mindestens 10 mal!

Ich kann mich noch gut an meine damaligen Experimente erinnern. Die
erste Uhr war ein reines TTL-Grab nur mit logischen Verknüpfungen,
Monos, Zählern und Registern. Etwas größer als ein DIN-A$-Blatt. Voll
gepackt. Dann folgten Experimente in Assembler und basic. und dann mit
Mikroproz

Mal zum angewöhnen eine Listing einer Simpel-Uhr in Basic:

http://www.mcselec.com/index.php?option=com_content&task=view&id=86&Itemid=57

Die ist aber noch nicht sonderlich intelligent!

Und lies dich mal durch diese Diskssion. Eher gegen Ende. Da steckt
viel wissenswerte Info drin.

Ansonsten mal selber googlen mit passenden Stichworten. Es gibt
tausende Artikel zum Thema DCF77


Gruss Wolfgang
--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.
Florian E. Teply
2007-05-05 09:00:12 UTC
Permalink
Post by Wolfgang Gerber
Post by Florian E. Teply
Die Dekodierung ist soweit ja
auch kein großes Problem,
doch - viel mehr als du dir denkst
Naja, nach der konkreten Aufgabenstellung ist es kein großes Problem:
Sekunden werden nicht gezählt, und fehlerhafte Daten müssen nicht
korrigiert werden sondern nur ne LED "invalid data" leuchten lassen.
Post by Wolfgang Gerber
Post by Florian E. Teply
die nötigen Ziffern liegen ja im Signal schon
BCD-kodiert und mit nem Paritätsbit an definierter Stelle vor.
Schön wäre es wenn es so einfach wäre. Theoretisch ist es das. Du
musst aber mit allen möglichen Fehlern rechnen und das alles
berücksichtigen. Und dann wird es doch ziemlich aufwendig. Wenn ich an
meine altes Flussdiagramm meiner Elektor-Uhr denke wird mir jetzt noch
anders.
Post by Florian E. Teply
Was mir
momentan Schwierigkeiten bereitet, ist die Synchronisation, a) auf den
Sekundentakt der Trägerabsenkung
Kinderspiel
Post by Florian E. Teply
und b) auf die ausbleibende Absenkung
in der 59. Sekunde als Minutenmarke und Startsignal für die nächste
vollständige Übertragung
Kinderspiel
Post by Florian E. Teply
sowie c) die Auswertung der Länge der
Absenkungen (die ja der Informationsträger ist).
Kinderspiel
Post by Florian E. Teply
Zu a) müsste man ja quasi nur die fallende Flanke als Taktsignal
"missbrauchen" und intern die fehlende 60. Flanke generieren.
genau - mit jeder fallenden Flanke werden mehrere Monos bzw. Timer
getriggert.
z.B. eines mit 0,15 Sekunden
Is mir soweit auch klar, was mir fehlt ist ne Implementierungsidee für
einen solchen Monoflop auf nem FPGA ohne externe Zusatzbeschaltung.
Post by Wolfgang Gerber
Kommt die steigende Flanke vor dem Ablauf, dann war es ein kurzer
Puls. Kommt sie danach war es ein langer Puls
ein weiteres für den Minutenpuls.
Grünau, äh richtig.
Post by Wolfgang Gerber
Kommt die steigende Flanke nach > 1,5 Sekunden ist es der
0-Minutenpuls
Wahrscheinlich - kann aber auch eine Empfangsstärung sein.
Wenn man erstmal vernünftig synchronisiert hat, kann man das ja
erkennen, da der Minutenpuls ja nur alle 60 Sekunden auftauchen sollte
;-) Wenn zwischendrin was fehlt: je nach Position ignorieren oder
invalid Data anzeigen.
Post by Wolfgang Gerber
Wobei wir beim Thema sind!
Post by Florian E. Teply
Für b) und c) bräuchte man allerdings ne Zeitmessung,
ja und?
Post by Florian E. Teply
bei b) für die
Dauer zwischen zwei fallenden Flanken und bei c) für die Dauer zwischen
fallender und darauffolgender steigender Flanke.
Nö - siehe oben.
Post by Florian E. Teply
Die eigentliche Dekodierung ist dann ja eher nur noch ne Fingerübung,
Nö - das erkennen der Pulse und längen ist einfach. Also das, was
bisher war.
Naja, die Zukunft kann man ja eh nicht vorhersagen ;-)
Klar, auf der Basis der letzten korrekt empfangenen Minute könnte man in
ner Art free-run-mode schätzen, aber das wäre dann die Kür...
Wichtiger ist erstmal die Pflichtübung.
Post by Wolfgang Gerber
Jetzt erst wird es richtig happig. Zumindest wenn die Uhr immer
richtig anzeigen soll.
Muss sie ja nicht, s.o.

Gruß
Florian
Wolfgang Gerber
2007-05-05 10:29:28 UTC
Permalink
Post by Florian E. Teply
Post by Wolfgang Gerber
doch - viel mehr als du dir denkst
Sekunden werden nicht gezählt, und fehlerhafte Daten müssen nicht
korrigiert werden sondern nur ne LED "invalid data" leuchten lassen.
Dazu muss aber trotzdem fast "alles" ausgewertet werden um den oder
die Fehler zu erkennen.

<-->
Post by Florian E. Teply
Post by Wolfgang Gerber
Kommt die steigende Flanke nach > 1,5 Sekunden ist es der
0-Minutenpuls
Wahrscheinlich - kann aber auch eine Empfangsstärung sein.
Wenn man erstmal vernünftig synchronisiert hat, kann man das ja
erkennen, da der Minutenpuls ja nur alle 60 Sekunden auftauchen sollte
;-) Wenn zwischendrin was fehlt: je nach Position ignorieren oder
invalid Data anzeigen.
Um überhaupt so weit zu kommen muss sehr vieles ausgewertet werden!
Post by Florian E. Teply
Post by Wolfgang Gerber
Nö - das erkennen der Pulse und längen ist einfach. Also das, was
bisher war.
Naja, die Zukunft kann man ja eh nicht vorhersagen ;-)
Klar, auf der Basis der letzten korrekt empfangenen Minute könnte man in
ner Art free-run-mode schätzen, aber das wäre dann die Kür...
Die muss praktisch sein. Sonst ist die ganze Uhr sinnlos.

Je nach Tageszeit, Sonne oder sonstigen Umwelteinflüssen wie nahe oder
ferne Gewitter und sonstige elektrische Störungen im Nahbereich, z.B.
Fernseher, kann es ein daß man nur vielleicht einmal in der Stunde
oder gar weniger ein gültiges Telegramm erhält. Ohne Freerun würde
deine Uhr u.U. 90% des Tages oder mehr nix oder Schrott anzeigen.
Post by Florian E. Teply
Wichtiger ist erstmal die Pflichtübung.
Und dazu gehören minimale Anforderungen.

Lies dich doch bitte erst einmal durch die passende Literatur bevor du
weiter sinnlos in der Gegend herumexperimentierts oder mit
überflüssigen Fragen nervst weil die schon hundert mal diskutiert
wurden. Das wurde alles schon bis zum Erbrechen und immer wieder
durchgekaut.
Post by Florian E. Teply
Post by Wolfgang Gerber
Jetzt erst wird es richtig happig. Zumindest wenn die Uhr immer
richtig anzeigen soll.
Muss sie ja nicht, s.o.
Wozu dann das Ganze? Was soll eine DCF-Uhr, die womöglich nie oder nur
selten mal was Sinnvolles anzeigt?

Sowas kannst/konntest du z.B. bei Conrad kaufen. Eine externe DCF-Uhr
im Kabel für den Parallelport. Die hat die meiste Zeit auch nur
Schrott geliefert.

Die wurde wohl von genauso jemand wie du gebaut. <g> Einfach eine
Grundforderung implementiert. Aber keinerlei sinnvollen
Plausibiltätscheck.

Und so kam es öfters vor daß die meine PC-Zeit um bis zu Jahre
verstellt hat. Was mir einige Datenverluste eingebracht hat. Also ab
zum Müll.


Gruss Wolfgang
--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.
Heiko Lechner
2007-05-05 12:07:18 UTC
Permalink
Wolfgang Gerber schrieb:

[...]

Ließ doch bitte nochmal Florians zweiten Satz aus dem Anfangsposting,
dann wird dir auffallen, dass er dir keine Uhr verkaufen will.
Heiko Lechner
2007-05-05 12:24:33 UTC
Permalink
Ließ
Du sollst das natürlich lesen und nicht sein lassen...
Florian E. Teply
2007-05-06 22:03:48 UTC
Permalink
Post by Wolfgang Gerber
Post by Florian E. Teply
Post by Wolfgang Gerber
doch - viel mehr als du dir denkst
Sekunden werden nicht gezählt, und fehlerhafte Daten müssen nicht
korrigiert werden sondern nur ne LED "invalid data" leuchten lassen.
Dazu muss aber trotzdem fast "alles" ausgewertet werden um den oder
die Fehler zu erkennen.
<-->
Ja, genau. Es müssen, die Stunden und Minuten sowie das Datum inkl. der
jeweiligen Paritätsbits ausgewertet werden, dazu kommt noch das
Minutensignal und gut ist. Klar, die Zeitinformation macht den größten
Teil des Signals aus (zeitlich gesehen). Warum ich es mir so einfach
mache? Siehe unten...
Post by Wolfgang Gerber
Post by Florian E. Teply
Post by Wolfgang Gerber
Kommt die steigende Flanke nach > 1,5 Sekunden ist es der
0-Minutenpuls
Wahrscheinlich - kann aber auch eine Empfangsstärung sein.
Wenn man erstmal vernünftig synchronisiert hat, kann man das ja
erkennen, da der Minutenpuls ja nur alle 60 Sekunden auftauchen sollte
;-) Wenn zwischendrin was fehlt: je nach Position ignorieren oder
invalid Data anzeigen.
Um überhaupt so weit zu kommen muss sehr vieles ausgewertet werden!
s.o.
Post by Wolfgang Gerber
Post by Florian E. Teply
Post by Wolfgang Gerber
Nö - das erkennen der Pulse und längen ist einfach. Also das, was
bisher war.
Naja, die Zukunft kann man ja eh nicht vorhersagen ;-)
Klar, auf der Basis der letzten korrekt empfangenen Minute könnte man in
ner Art free-run-mode schätzen, aber das wäre dann die Kür...
Die muss praktisch sein. Sonst ist die ganze Uhr sinnlos.
Je nach Tageszeit, Sonne oder sonstigen Umwelteinflüssen wie nahe oder
ferne Gewitter und sonstige elektrische Störungen im Nahbereich, z.B.
Fernseher, kann es ein daß man nur vielleicht einmal in der Stunde
oder gar weniger ein gültiges Telegramm erhält. Ohne Freerun würde
deine Uhr u.U. 90% des Tages oder mehr nix oder Schrott anzeigen.
Um den fehlenden Gebrauchswert zu streiten ist hier sinnlos, da mir
selber auch klar ist, daß eine Uhr, die nur gelegentlich und wenn keiner
hinschaut sinnvolle Daten anzeigt, im Alltag komplett nutzlos ist.
Post by Wolfgang Gerber
Post by Florian E. Teply
Wichtiger ist erstmal die Pflichtübung.
Und dazu gehören minimale Anforderungen.
Lies dich doch bitte erst einmal durch die passende Literatur bevor du
weiter sinnlos in der Gegend herumexperimentierts oder mit
überflüssigen Fragen nervst weil die schon hundert mal diskutiert
wurden. Das wurde alles schon bis zum Erbrechen und immer wieder
durchgekaut.
Wie ich schon erwähnt hatte: ne DCF-Uhr ist ein beliebtes Übungsobjekt
im Studium...
Das impliziert, daß gerne mal das Rad neu erfunden wird. Aber da Du
gerade die Literatur ansprichst: vielleicht hast Du ja ne vernünftige
Quellenangabe, mit der ich mich schlau machen kann...
Post by Wolfgang Gerber
Post by Florian E. Teply
Post by Wolfgang Gerber
Jetzt erst wird es richtig happig. Zumindest wenn die Uhr immer
richtig anzeigen soll.
Muss sie ja nicht, s.o.
Wozu dann das Ganze? Was soll eine DCF-Uhr, die womöglich nie oder nur
selten mal was Sinnvolles anzeigt?
Sowas kannst/konntest du z.B. bei Conrad kaufen. Eine externe DCF-Uhr
im Kabel für den Parallelport. Die hat die meiste Zeit auch nur
Schrott geliefert.
Ich erkläre es Dir gerne nochmal, wozu das Ganze dienen soll. Wie Heiko
richtig erkannt hat, geht es nicht um ein marktfähiges Produkt, sondern
darum, eine Projektaufgabe (lies: Übung im Studium) unter gegebenen
Rahmenbedingungen erfolgreich zu absolvieren. Im Allgemeinen kommt dabei
üblicherweise KEIN marktfähiges Produkt heraus, sondern ein gewisses
Verständnis für die Möglichkeiten (und Grenzen) der verfügbaren Technik.
Die genannten Rahmenbedingungen sind nunmal diese: ich bekomme ein
demoduliertes DCF-Signal (das entweder aus irgendeinem Rechner kommt
oder aus der realen Welt) und soll daraus eine Uhrzeit (Stunde.Minute)
oder ein Datum (Tag.Monat.) basteln.

Also zurück zu den konkreten Fragen: kann man ein Monoflop
sinnvollerweise auf nem FPGA implementieren??

Gruß
Florian
Georg Acher
2007-05-06 22:26:14 UTC
Permalink
In article <4vv1h4-***@teply.info>,
"Florian E. Teply" <***@teply.info> writes:

|> Also zurück zu den konkreten Fragen: kann man ein Monoflop
|> sinnvollerweise auf nem FPGA implementieren??

Zähler mit Auslösesignal auf bestimmten Wert setzen, Ausgang aktiv machen, mit
jedem Takt runterzählen. Bei Zählerstand 0 mit dem Zählen anhalten und Ausgang
inaktiv machen. Alles in allem weniger als 10 Zeilen VHDL.
--
Georg Acher, ***@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Florian E. Teply
2007-05-07 22:12:13 UTC
Permalink
|> Also zur�ck zu den konkreten Fragen: kann man ein Monoflop
|> sinnvollerweise auf nem FPGA implementieren??
Z�hler mit Ausl�sesignal auf bestimmten Wert setzen, Ausgang aktiv machen, mit
jedem Takt runterz�hlen. Bei Z�hlerstand 0 mit dem Z�hlen anhalten und Ausgang
inaktiv machen. Alles in allem weniger als 10 Zeilen VHDL.
Stümmt, die Idee ist garnicht schlecht. Ich mach mich jetzt mal schlau,
welche Taktvarianten ich hab und überlege mir, wie ich dann die Zähler
implementiere...

Gruß
Florian

Harald Wilhelms
2007-05-04 06:58:29 UTC
Permalink
Post by Florian E. Teply
Zu a) müsste man ja quasi nur die fallende Flanke als Taktsignal
"missbrauchen" und intern die fehlende 60. Flanke generieren.
Das hört sich zwar einfach an und wird möglicherweise
auch funktionieren. Es ist aber immer besser eine
Pegelauswertung statt einer Flankenauswertung zu
machen. Das heisst, du tastest das Eingangssignal
z.B. alle paar ms ab, und machst die Aussage, ob das
Signal H oder L ist über einen "Mehrheitsentscheid".
So kannst Du problemlos kurze Störimpulse auswerten.
Post by Florian E. Teply
Für b) und c) bräuchte man allerdings ne Zeitmessung, bei b) für die
Dauer zwischen zwei fallenden Flanken und bei c) für die Dauer zwischen
fallender und darauffolgender steigender Flanke.
Klar, eine Taktfrequenz brauchst Du schon, aber die kann
ziemlich ungenau sein, sodas vermutlich schon ein RC-Glied reicht
Post by Florian E. Teply
Die eigentliche Dekodierung ist dann ja eher nur noch ne Fingerübung,
die anfallenden Daten in ein Schieberegister schieben und bei dem
Minutensignal passend auf die Ausgabepins schicken (evtl. vorher noch
durch nen BCD-zu-7-Segment-Dekoder), vereinfacht ausgedrückt.
Ich würde trotzdem eine normale Uhr mitlaufen lassen
und jeweils vergleichen, ob sie mit der DCF-Zeit
synchron läuft (Plausibilitätskontrolle)
Gruss
Harald
Loading...