DCF77-Decoder in VHDL - Any Hints?

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

Reply to
Florian E. Teply
Loading thread data ...

Florian E. Teply schrieb:

Mit einem externen Takt den Eingang Samplen, durch den externen Takt hast du eine Zeitbasis.

Reply to
Heiko Lechner

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
Reply to
Gernot Fink

Florian E. Teply schrieb:

Ja - schon seit bestimmt über 25 Jahren. Damals noch in Basic auf dem PET

ACK

doch - viel mehr als du dir denkst

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.

Kinderspiel

Kinderspiel

Kinderspiel

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!

ja und?

Nö - siehe oben.

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.

Vergiss das mit dem Schieberegister - das gibt nur Müll!

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:

formatting link

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.
Reply to
Wolfgang Gerber

Heiko Lechner schrieb:

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.
Reply to
Wolfgang Gerber

Wolfgang Gerber schrieb:

Ja und wie bekommt er einen Timer ohne externen Takt und Zählern?

Reply to
Heiko Lechner

Das h=F6rt sich zwar einfach an und wird m=F6glicherweise auch funktionieren. Es ist aber immer besser eine Pegelauswertung statt einer Flankenauswertung zu machen. Das heisst, du tastest das Eingangssignal z=2EB. alle paar ms ab, und machst die Aussage, ob das Signal H oder L ist =FCber einen "Mehrheitsentscheid". So kannst Du problemlos kurze St=F6rimpulse auswerten.

Klar, eine Taktfrequenz brauchst Du schon, aber die kann ziemlich ungenau sein, sodas vermutlich schon ein RC-Glied reicht

Ich w=FCrde trotzdem eine normale Uhr mitlaufen lassen und jeweils vergleichen, ob sie mit der DCF-Zeit synchron l=E4uft (Plausibilit=E4tskontrolle) Gruss Harald

Reply to
Harald Wilhelms

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.

Is mir soweit auch klar, was mir fehlt ist ne Implementierungsidee für einen solchen Monoflop auf nem FPGA ohne externe Zusatzbeschaltung.

Grünau, äh richtig.

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.

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.

Muss sie ja nicht, s.o.

Gruß Florian

Reply to
Florian E. Teply

Florian E. Teply schrieb:

Dazu muss aber trotzdem fast "alles" ausgewertet werden um den oder die Fehler zu erkennen.

Um überhaupt so weit zu kommen muss sehr vieles ausgewertet werden!

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.

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.

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. 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.
Reply to
Wolfgang Gerber

Wolfgang Gerber schrieb:

[...]

Ließ doch bitte nochmal Florians zweiten Satz aus dem Anfangsposting, dann wird dir auffallen, dass er dir keine Uhr verkaufen will.

Reply to
Heiko Lechner

Heiko Lechner schrieb:

Du sollst das natürlich lesen und nicht sein lassen...

Reply to
Heiko Lechner

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...

s.o.

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.

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...

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

Reply to
Florian E. Teply

|> 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, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias
Reply to
Georg Acher

mit

Ausgang

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

Reply to
Florian E. Teply

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