Hallo Forianer,
ich möchte gern einen DCF Empfänger mit PIC-Controller lösen.
Nach einiger Suche hier im Forum habe ich zwar relativ oft dieses Thema
gefunden, jedoch meist nur mit AVR spezifischen ASM-Beispielen.
Ich programmiere (hobbymässig) leider nur in C und bin deswegen des ASM
nicht so mächtig.
Jedoch habe ich zur Umsetzung eines DCF77 Empfängers mit MC noch einige
Grundsatzfragen.
1) wie löst ihr die Anbindung des DCF Modules an den MC? Nutzt Ihr
dabei Interrupteingänge mit Flankenerkennung oder Pin-Change und
entsprechende ISR's?
2) Wie syncronisiert man am sinnvollsten das DCF Signal mit den eignen
Routinen auf den Minutenstarttakt? ..eigentlich bleibt da ja nur das
59'igste (nicht gesendete) Bit, oder?
3) welche Möglichkeiten zur Fehlererkennung nutzt Ihr?
Für grundlegende, verständliche Informationen wäre ich sehr dankbar.
Ich brauche keine konkreten Codebeispiele, jedoch wäre, im Grundsatz,
verständlicher Pseudocode sehr hilfreich.
beste Grüße
http://www.mikrocontroller.net/forum/read-1-181962.html#235281
Für den Anfang würde ich es einfacher machen, damit sich
Erfolgserlebnisse einstellen.
ja, die fehlende 59. Sekunde ist am einfachsten zu finden, dann die
Sekunden mitzählen.
Die Herausforderung für mich war damals, möglichst schnell Information
zu bekommen, ich warte also nicht erst die 59. Sekunde ab und fange
dann zu zählen / dekodieren an, sondern speichere die Bits in einen
Ringpuffer und prüfe nach jeder Sekunde, ob das Telegramm gültig ist
(Parität und Plausibilität).
So habe ich im Idealfall nach 40, spätestens nach 60 Sekunden, die
komplette Info.
Bei schlechtem Empfang verwerte ich nur die korrekten Daten.
Wenn z.B. in der ersten Minute nur die Zeit korrekt war, in der zweiten
nur das Datum, lasse ich dasjenige gelten und habe nach diesen 2 Minuten
(trotz Empfangsfehlern) die vollständige Info.
Man könnte das sogar noch erweitern, indem man das falsche Bit
isoliert, habe ich aber nicht gemacht.
Mit welchem Prozessor Du das machst... geht mit einem PIC genauso gut.
Es ist so gut wie keine Rechenleistung erforderlich.
danke Euch für die Infos, damit wird die Sache schon ein bisschen
klarer.
@P. Dannegger:
interessanter, compakter Code..jedoch verstehe ich Ihn noch nicht so
wirklich komplett :(
Könntest Du evtl. die Funktionsweise nochmal grob erläutern?
Wie ist das eigentlich mit dem Parity-Bit?
1
parity^=pulse;// calculate parity
2
..
3
..
4
if(parity)
5
dcf77error=1;
6
..
Du gehst scheinbar davon aus, das wenn das Parity Bit nicht gesetzt ist
ein Fehler vorliegt? Ist das Parity-Bit denn immer logisch 1 wunder?
beste Grüße
D.h. Parity wird immer nur dort ausgewertet, wo in der Aktion-Tabelle
ein 0xFF drinsteht.
Die Tabelleneinträge bedeuten entweder, es wird Wert x an Adresse y
addiert oder es wird das Paritybit geprüft.
Mir war das einfach zuviel Schreibarbeit, Unmengen an cases in eine
switch-Anweisung zu schreiben, deshalb die Steuerung der Auswertung
über eine Tabelle.
Peter
Hallo zusammen,
[werbung]
Die Funkuhrsoftware für meine Nixie-Uhr hab ich auch selbst
geschrieben, nach Anregungen hier im Forum (vor allem von Peter und
seiner Methode der Auswertung zweier aufeinanderfolgener Datensätze).
Eine Beschreibung der Uhr gibt's auf meiner HP, den Quellcode
(Testversion für ein 2x16-LCD) häng ich euch mit ran (bitte nicht
wundern, das war mein erstes größeres Projekt und vielleicht noch etwas
rookie-mäßig - aber es funktioniert bestens).
[/werbung]
Grüße, Mario
Danke
..das mit der Tabelle war mir soweit klar.
Was das Parity-Bit betrifft, stand wohl jemand auf meiner Leitung.
Die Parity Auswertung muss man schon im Zusammenhang mit allen
auszuwertenden Bits sehen, dann klappts auch mit dem Nachbarn, ähm
Verständniss :)
nochmals danke, Ihr habt mir sehr geholfen
