DCF-Encoder mit ATTiny2313

Hallo,

wir kennen das ja alle, manchmal ist der DCF-77-Zeitzeichensender nicht so gut zu empfangen. Das passiert meistens gerade dann, wenn man seine gerade fertiggestellte Selbstbau-DCF-Funkuhr testen möchte.

Deswegen möchte ich heute ein kleines DCF-Decoder-Testprogramm mit der AVR MCU ATTiny2313 vorstellen.

Das folgende Programm umgeht diese Empfangs-Schwierigkeiten und bietet jederzeit die Möglichkeit, eine Decodierschaltung auf einwandfreie Erkennung der Sekundenmarken auf Low- und High-Pegel hin zu testen, indem es das DCF-Signal mit sauberen Flanken simuliert.

Dazu wurden (zunächst) die Sekundenmarken-Werte von ein paar Minuten eines tatsächlich zugrundeliegenden Längstwellenempfangsprotokolls auf Tonbandcassette in ein Array programmiert, worauf hernach darauf zugegriffen wird, bzw. was noch selbst leicht erweitert werden kann, wenn die Zusammenhänge des DCF-Codes besser bekannt sind.

Es liegt ein allerseits bekanntes Uhrenprogramm mit Interruptserviceroutine und Jobflags zugrunde.

Die Werte, also Nullen und Einsen eines Pointerregisters (nicht nullterminiert, daher Besonderheit!)
werden zu jeder Sekunde nach Durchlaufen einer Mehrfachverzweigung einem Ausgabeport für die Dauer der Zeitschleifen (ca. 100 bzw. 200 Millisekunden lang) übergeben.
(Hier Registerwerte ca. 126 bis 127 für logisch "Null" und 248 bis 249 für logisch "Eins". Auch die trickreichen Paritybits entsprechen dem verwendeten Originaltonbandmitschnitt des Direktmischer-Empfängers, der mit einem Pfeifton von ca. 2 kHz den Sender hörbar machte. Siehe auch Bild "DCF-Oszillogramm", wo man die unterschiedlich breiten Austastlücken und die ausgelassene 59. Sekundenmarke am rechten Bildrand gut erkennen kann. Leider ist diese Empfängerschaltung thermisch nicht so stabil, daß der Sekundentakt daraus über einen längeren Zeitraum direkt abgeleitet werden könnte. Diesbezügliche Experimente auch mit Pufferstufen liefen nur wenige Minuten, funktionierten im Prinzip aber, dazu gibt es auch ein kleines Video.)

Damit werden dann auf INTO und INT1 die Flankeninterrupts zur Triggerung der Zeitauswertung bei der angeschlossenen Decodierschaltung ausgelöst. ( Ja, die hier verwendete Decodierschaltung benutzt beide Interrupts, die beiden Ports (PD2 und PD3) müssen über "Entkoppelwiderstände" von ca. 180 Ohm mit dem Empfangsmodul verbunden werden, nur ein einziger Eingang an der MCU reicht hier nicht.)

Simultan dazu kann man das Hochzählen der Sekunden und die Bit-Werte des DCF-Telegramms auf einem LCDisplay ablesen. Dazu wird der Z-Pointer-Adressen-Increment-Registerwert und nicht der Wert des Sekundenregisters der Uhrenschaltung verwendet.
Für die ausgelassene 59. Marke wird eine "3" ins Array programmiert, die dann im Vergleichsdurchlauf ein "x" auf das Display zaubert.

Nach Ablauf der gesamten im Array gespeicherten Werte wird das Display
gelöscht (- ausnahmsweise mit "Display Clear" der LCD-Initialisierungsroutine - ), und der Vorgang beginnt von vorne.

Bei einer hier auch noch verwendeten DCF-Decodierschaltung -
selbstredend auch mit dem ATTiny2313 - kommt man so tatsächlich bis zur Synchronisation und Übernahme der vorprogrammierten DCF-Zeit.

Diese beginnt dann mit Datumsangabe nach den abgelaufenen zwei Minuten natürlich wieder von vorne.

Auf den angehängten Textfiles, die vom Hyperterminal abkopiert worden sind, erkennt man zunächst den "Counter"-Zustand, dann erfolgt nach einigen zu ignorierenden Fehlermeldungen der String "Synchronisation". Daran kann gesehen werden, daß tatsächlich dann die Uhrzeit des DCF-Telegramms übernommen wurde.


Viel Spaß!
Euer Oskar01

P.S.:
Die Decodierschaltung von ((C)2001 by Gerhard Schmidt * report bugs to info@avr-asm-tutorial.net * ) läuft trotz grenzwertiger Verwendung des ATTiny2313 mit 10-MHz-CPU-Takt und fast 100-prozentiger Speicherplatzausnutzung auch außerhalb des STK-500-Boardes im Testaufbaus zusammen mit dem MAX232 auf Anhieb.
Nachteil dabei, man benötigt zur Einstellung der Features die serielle Schnittstelle und ein Terminalprogramm.


Demnächst mehr, falls gewünscht......

Hallo @Dino....,
ok.
Gehe davon aus, daß man zunächst völlig im Dunkeln tappt, was den speziellen Code des DCF-Telegramms angeht.
In Wirklichkeit sind nämlich im Originalmitschnitt in den Sekunden vor 20 auch noch etliche "High" Bits, die habe ich hier absichtlich rausgelassen.
Die meisten Decoderschaltungen triggern erst ab Sekunde 20.
Da könnte es zu einiger Verwirrung kommen.
Im Dateianhang noch die Excelliste, aus der man entnehmen kann, wie und welche Bits zur Parity-Generierung herangezogen werden.
Also: Zur Ergänzung auf gerade Anzahl von "Einsen".


Gruß von Oskar01

Der praktische Aufbau

Hallo,
hier noch ein paar Ergänzungen.
Die Billigcam ist doch ziemlich verwackelungsanfällig, glaube aber doch, auf den Bildchen ist das Wesentliche zu erkennen...

Da hatte ich gestern noch rumgehext mit der seriellen Schnittstelle, bis ich merkte, daß ich ja nicht DTE-spezifiziertes Kabel (Data Terminal Equipment / Datenendgerät), sondern DCE-konfiguriertes Pinout (Data Communications Equipment / Datenübertragungsgerät) benötige. Zu allem Übel hatte ich in der Bastelkiste nur noch einen 25-poligen Steckverbinder.
Da hatte ich das Loopen und Pinout völlig vergessen schon.
Das serielle STK500-Board-Kabel ist ja auch ungekreuzt, da hat man sich schon so daran gewöhnt, daß es einem jetzt erst auffiel, daß es ja nicht der Standard ist bei End-zu-End-Geräten, wie hier. Ob die Kreuzung nun an der Buchse schon erfolgt oder am Kabel, spielt eigentlich keine Rolle. Also kreuzen wir an der Buchse.
Das nur am Rande.

Im angehängten File "capture5.txt", das wieder 'mal vom Hyperterminal eins zu eins abkopiert wurde, ist die ganze Sequenz vom "Power on" über manuelle Eingabe von aktueller Uhrzeit und Datum bis hin zur tatsächlich irgendwann einmal erfolgenden Synchronisation mit der ge-"fake"-ten DCF77 Zeit zu sehen. (Hab's auch gesehen, einige Sekundenangaben werden verschluckt, ist aber wohl nicht weiter tragisch.)

Das Decodierprogramm ist - aber hallo - ziemlich "ausgekügelt", das merkt man schon daran, daß das Hyperterminal "umemuliert" wird per Software, oder sollte, klappt wohl nicht immer....
Das erinnert mich noch so vage an die DOS-Zeiten mit den Escape-Sequenzen in der Autoexec.bat ....oder war's die Config.sys ? Plötzlich wird das Terminalfenster nämlich farbig.

Viel Spaß noch !

Gruß von Oskar01

Ein DCF77-Empfänger und Außenantenne

Hallo,
noch zur Ergänzung die dem Test zugrundeliegende Empfangsanordnung hier.

Viel Spaß !

Gruß von Oskar01


P.S.:
Herr Dirk Piester war so freundlich und hat prompt die von mir per E-Mail an die PTB gerichteten Fragen nach dem DCF-Code beantwortet.
Es gibt tatsächlich vor Sekunde 14 auch noch "High"-Bits. Das waren demnach keine Artefakte im vorgestellen Telegramm, sie wurden also tatsächlich gesendet.
Für die Decodierung der aktuellen Zeitinformation reicht es auch völlig aus, erst ab Sekunde 20 damit zu starten. Ob nun das Sommerzeitbit vorhanden ist oder nicht, die Decodierung in der Minute n zeigt immer die aktuelle Zeit für die Minute n+1.

In der zugemailten Info ist auch davon die Rede, daß die häufigste Störungsursache die 5. Oberwelle der Zeilenfrequenz von der Zeilenoszillatorstufe (Hochspannung) eines Fernsehers in der unmittelbaren Umgebung eines Empfängers ist.

Empfänger ...und LCD-Ausgabe

Hallo,
um die Empfangsmöglichkeit des DCF77-Zeitzeichensenders hier vor Ort besser beurteilen zu können, verwende ich nun ein Empfangsmodul der Fa. Conrad.
Hier stellte es sich heraus, daß damit fast 24 Stunden am Tag der Empfang einwandfrei ist.

Nun ging es an die Aufgabe, das Decodierprogramm von Günther Schmidt auf seine Praktikabilität hin zu testen.

Das Programm arbeitet ja mit dem ATTiny2313 und stellt eine Kommunikation lediglich über die serielle Schnittstelle und ein PC-Win-Terminalprogramm zur Verfügung.

Die Aufgabe bestand nun darin, eine Ausgabe auf ein LCDisplay hinzuzaubern.
Für die LCD-Routinen ist nämlich zu wenig Speicherplatz beim Decodierprogramm übriggeblieben, so daß ein zweiter ATTiny2313 diese Task nun übernehmen sollte.

Dazu ist zu bemerken, daß generell das Problem mit der Begrenzung der Stellenzahl auf 16 pro Zeile bei einem hier verwendeten 16x2-Display aufkommt, der Datenstrom aber für Datum und Uhrzeit mehr Stellen benötigt. Ein Zeilenumbruch bzw. eine Positionierung funktioniert nicht problemlos, weil dann die Pufferung des seriellen Datenstroms zunächst abreißt.

Dies wird im folgenden Programm nun aufgezeigt.
Eine serielle Übertragung des Datums und der Uhrzeit erfolgt bekanntermaßen sekündlich, das LCD kommt mit der Darstellung so nicht mehr hinterher, auch scrollt die Anzeige zunächst.

Erst nach Eingabe von bestimmten Zeichenfolgen im Menü startet die Datums- und Zeit-Ausgabe.
Dann erfolgt nach einer gewissen Zeit auch selbständig die Synchronisation mit dem DCF-Telegramm.
Nach dem Einschalten sieht man sonst nämlich garnichts, auf dem Hyperterminal lediglich den blinkenden Cursor.

Das folgende Programm sendet am Anfang auch die sonst per Tastatureingabe zu erfolgen habenden Menü-Einträge selbständig, so daß man ohne PC und Hyperterminal auskommt.
Eine Umformung nur für die Ausgabe von Ziffern und Doppelpunkten zwischen den Angaben entfällt, da ja schon von vorne herein im ASCII-Code gearbeitet wird. Nur, man möchte auch die Meldungen anzeigen lassen, dazu habe ich das Programm erst einmal nur im reinen Receive-Modus laufen lassen.

Das Ergebnis kann man auf den Videoclips anschauen.

http://www.kbra01.de/DCF_LCD2.mpg

und

http://www.kbra01.de/DCF1.mpg


Viel Spaß,

Euer Oskar01

P.S.: Der Schnittstellenkonverter MAX232 ist hier nicht in Funktion, kann also entfallen.
Die ganze Anordnung mit der zusätzlichen Pufferstufe hätte dann auf einer Miniplatine Platz.
Wichtig: RXD und TXD müssen zwischen ATTiny1 und ATTiny2 natürlich über Kreuz verdrahtet werden, es ist ja sozusagen eine echte Peer-to-Peer-Connection. Also DTE.

Kleine Programmänderung

Hallo,
da das DCF77-Decodierprogramm ursprünglich für die ausschließliche Kommunikation mit dem PC über ein Terminalprogramm (z. B. Hyperterminal) angedacht war, konnte man schon in etwa davon ausgehen, daß es beim "Umstricken" auf LCD-Ausgabe gewisse Schwierigkeiten geben würde.

Der erste Test lieferte ja - wie beschrieben - keine feststehende Anzeige von Datum und Uhrzeit, sondern diese "scrollten" immer durch.

Die Experimente gingen nun in diese Richtung.

Dabei stellte sich heraus, daß das Programm - wenn es mit den zweiten ATTiny2313 zur LCD-Ausgabe angesteuert wird, bei der DCF77-Synchronisation bisweilen nur die Anzeige
Datum:00:00:2000 und
Uhrzeit 00:00:00 lieferte.

Wurde die serielle Schnittstelle über den MAX232 und das PC-Hyperterminal benutzt, funktionierte das Programm hingegen einwandfrei.

Lösung:

Da das Decodierprogramm selbständig die Terminalemulation abändert nach der ersten Eingabe, die das Kommando-Menü aufrufen soll, müssen die folgenden Eingaben zusätzlich mit "Linefeeds" abgeschlossen werden, obwohl genau das bei der ersten Steuerzeichenangabe dazu führt, daß das Programm überhaut nicht startet. Man sieht dann nur das zurückgeechote Fragezeichen auf dem LCD.

Ferner wurde nun das folgende Programm mit definierten Positionierungsangaben für das LCD versehen, damit man nun - endlich - eine stehende Anzeige erzielt.

Die Steuerzeichenangabe erfolgt nun auch über Pointer. Ebenso wurden 'mal die LCD-Routinen
als Einzelunterprogrammaufrufe gestaltet, damit einzelne Initialisierungs-Abschnitte - für später - auch aus dem laufenden Programm heraus aufgerufen werden könnten. Das führt zwar zur Vergrößerung des Speicherplatzbedarfs, funktioniert aber.

Soviel als kurzer Erfahrungsbericht.

Viel Spaß noch,
Euer Oskar01

P.S.: Video wurde aktualisiert:

http://www.kbra01.de/DCF_LCD2.mpg

Fehlfunktionen im Dauerbetrieb

Hallo,
das Programm zeigt im Dauertest folgende Eigenschaften:
Zunächst einmal, wenn Steuersignale zum Aufruf des Menüs und der Menüfeatures per UART übertragen wurden:

Default-Zeit und Datum (im Programm hinterlegt)
Messages "Count too short" für Beginn/Progress der DCF-Signalauswertung
DCF Synchronisation und Übernahme von DCF-Zeit/Datum.
Fällt Empfang aus, läuft (recht ungenaue) Timer-Zeit/Datum weiter.

Manchmal kommt es direkt bei der Synchronisation zur Anzeige von Nullen.
Nur die Sekundenanzeige läuft DCF-synchron. D.h. 59 Sekunde wird auch dargestellt, also bis dahin klappt es mit der Decodierung dann.

Dann resettet sich die Anzeige bei jedem Minutenanfang wieder.
Das ist dann wohl ein Fehler im Programm bzw. der Programmausführung.


Nach längerem Test konnte auch festgestellt werden, daß trotz vorheriger
Synchronisation dann plötzlich wieder die "Default"-Zeit hochgezählt wird.
Das aber vor allem bei stark gestörtem Empfang.



Das zum Test.

Werde mir also mal den Programmcode genauer ansehen.
Meine Vermutung:
Es sind zu viele Interrupts am Werke.
Der Externe Interrupt wird bei gestörtem Empfang ja im Rhythmus der
Störimpulse extrem beansprucht, da ist schon einmal ein Ansatzpunkt.

Bis dann

Gruß Euer Oskar01

alternative Programmsuche für DCF77-Decoder

Hallo,
habe mal im Net gestöbert.
IMHO ist aber das hier verwendete Prog.

http://avr-asm-tutorial.net/avr_de/dcf77uhr.html

noch das ausgefuchsteste.
Bleibe also erst einmal dabei.

Gruß von Oskar01

Dauertest

Hallo,
also, die DCF77-Uhr läuft nun im Dauertest.
Dabei zeigt sie manchmal irgendeine Zufallszeit und ein Zufallsdatum an,
nach einigen Stunden läuft sie aber wieder korrekt, ohne, daß ich etwas resetten mußte.
Die fehlerhafte Anzeige rührt von gestörtem Empfang her.
Da flackert die Kontrol-Led, direkt hinter der Pufferstufe zwischen Empfangsplatinen-Ausgang und Interrupt-Eingängen ganz wild und auch bei der akustischen Kontrolle mit dem separaten Direktmischer gibt nur einen kontinuierlichen Pfeifton ab, ohne, daß irgendwelche Sekundenmarken erkennbar wären.
Da diese Störungen so ziemlich erst nach Eintritt der Dämmerung auftreten, nehme ich an, daß noch ein anderer Langwellensender hier Überreichweiten produziert, auch ist eine Pegelschwankung, bedingt durch den Raumwellenanteil festzustellen. Könnte auch sein, daß ein Flugfunk-NDB des Kölner Flughafens hier am Werke ist.

Es konnte des weiteren auch mit dem durchstimmbaren Digital-Kurzwellenempfänger festgestellt werden, daß die Quarzfrequenz der Decodierschaltung im Sekundenrhythmus leicht verreißt, also um wenige Hertz
mit dem BFO wahrnehmbar. Die Frequenz sitzt exakt auf 10004 Kilohertz und schwankt während der Sekundenmarken um etwa 20 Hz dann. Dieses Phänomen ist bei dem Quarzoszilator des STK500-Boardes, wo der Ansteuerchip noch sitzt, nicht festzustellen. Hier beträgt die Frequenz ziemlich konstant 4001 Kilohertz.

Übrigens sind diese Oszillator-"Störstrahlungen" so schwach, daß ich sie nur dann wahrnehmen kann, wenn ich die Antenne des KW-Empfängers mit einem Draht direkt mit dem Gehäuse des jeweiligen Quarzes verbinde.

Das LCD produziert auch ganz schwache Geräusche im Bereich um 250 kHz im Langwellenbereich, also das ist wohl schon die erste Oberwelle.
Auch nur, wenn ich sehr nahe an den Empfänger komme damit.

In dem fliegenden Aufbau hier hätte ich eigentlich eine höhere Störstrahlung erwartet.

Gruß von Oskar01

Stör-Problematik

Hallo,
die beste Lösung der Decodierprobleme ist ein sauberer, und ungestörter Empfang des Zeitzeichensenders.
Da gerade diese Längstwellenfrequenzen in besonderer Weise EMV-Problematiken aufweisen, gerade im Zuge der massenhaften Einführung von weiteren Störergruppen, wie Energiesparlampen etc., ist es hier einmal an der Zeit, diese Dinge zu thematisieren.

Meine Aldi-Uhr stellte sich beispielsweise nicht von Sommerzeit auf Winterzeit um. Man sollte meinen, es handelte sich hierbei um ausgereifte Schaltungskonzepte und Software.

Was Wunder, daß die "Selbstbauuhren" erst recht mit ähnlichen Problemen zu kämpfen haben.

Fortsetzung folgt.


Beste Grüße Euer Oskar01