Hallo,
Hier mal ein neues Programm von mir für einen Atmel.
Dieses wertet ein DCF77 Signal aus und gibt es auf der seriellen
Schnittstelle aus. Die Uhr läuft auch weiter, wenn das Signal ausfällt.
Natürlich sollte das DCF 77 Modul an INT0 angeschlossen werden. Da ich
dieses für einen Mega128 geschrieben habe müssen noch die Int Register
auf den jeweiligen Prozessor angepasst werden.
Mfg Ulrich
Hallo Uli,
hab mir das *.zip-File mal angeschaut, aber noch nicht ausprobiert, da
ich erst mal mit einem ATmega16 arbeite.
Bei Durchsicht des Quellcodes ist mir in der clock.c aufgefallen, daß
Du beim manuellen Lauf der Uhr von 60 Stunden pro Tag ausgehst,
vermutlich sollte da aber auf 24 Stunden abgefragt werden.
Dirk
Wenn ich das richtig sehe, wird T1 ständig bei jedem (Stör-)Impuls
zurückgesetzt. D.h. Deine interne Zeit läuft in den Wald, sobald der
Empfang gestört ist.
Außerdem machst Du keinerlei Überprüfungen (Parity,
Impulslänge/-abstand). D.h. Du weißt nie, ob die empfangene Information
auch richtig ist (ist sie nämlich oftmals nicht), z.B. bei Gewitter,
Staubsaugen, Fernsehen.
Ich hatte mir früher mal sowas komplett mit TTL-ICs aufgebaut, das
Ergebnis war nicht berauschend.
Man muß also unbedingt die Tests machen und die interne Uhr unabhängig
laufen lassen, damit man eine zuverlässige Zeitinformation erhält.
In der Codesammlung ist ein Assemblerbespiel auf dem ATTiny12 und im
Web auch C-Beispiele von mir, wie es super funktioniert.
Peter
Auch ganz brauchbar ist http://www.fh-kl.de/~ofer/avr/avrpro.htm.
Weiss zwar nicht, ob darin saemtliche von Peter Dannegger
angesprochenen Pruefungen durchgefuehrt werden aber eine Portierung auf
den LPC2106 ARM7 funktioniert seit fast 2 Monaten ohne Probleme (ohne
"unsinnige" Zeiten). Der Code ist auch nicht ganz so optimiert wie
Peter Danneggers C-Code, war aber leichter zu portieren.
Hallo,
Das mit der Parity Prüfung ist richtig wird noch nicht ausgewertet.
Kann man aber ohne Probleme mit einbinden. Allerdings wenn nicht alle
Impulse Empfangen werden läuft die Interne Uhr weiter.
Mfg Ulrich
Hallo @peter dannegger
Hattest recht mit Störimpulsen habe mal den DCF77 Empfänger direkt
neben meinen Drucker gelegt, und die Zeit zählte und lief davon.
Also habe ich die Auswertung geändert und zusätzlich die Parity
Überprüfung eingebaut :-)
Also hier der neue SourceCode.
Mfg Ulrich
hallo
woran kann es liegen das sich die funkuhr nicht syncronisiert? ich habe
das ganze auch auf einem m128 aufgebaut. allerdings habe ich den
interrupt auf 7 geändert. als funkuhrmodul verwede ich das vom grosen
c. Über usart empfange ich nur dauernd die sekundenangabe die immer nur
hochzählt.
mfg
max
hallo
hab jetzt ein 20cm langes kabel dazwischen, ist aber auch nicht besser.
kann ich das auch ohne osziloskop mesen ob da überhaut was rauskommt?
ich hab den verdacht das das modul kaput sein könnte.
mfg
max
@Max,
einfach nur eine LED mit Vorwiderstand an den Ausgang gegen VCC, die
muß dann je s einmal blinken.
alle Monitore und PCs ausschalten
eventuell ans Fenster gehen
eventuell mit Batterie (4,5V) betreiben (falls das Netzteil
rumschweint).
Peter
Könnte mal jemand eine Hex oder Bin Datei von dem Programm erstellen ?
Ich habe leider keinen C Compile für AVR installiert.
Der erste DCF77 Dekoder ist zumindest schon auf meinen DCF Sender
reingefallen.
Ich möchte erstmal einige direkt verbundene Dekoder testen, ehe ich
einen echten Sender anschließe um mal ein paar Uhren zu verstellen...
> Der erste DCF77 Dekoder ist zumindest schon auf meinen DCF Sender> reingefallen.
Wenn der Sender sich an die Spezifikation hält, also auch die drei
Prüfbits stimmen, muß die Uhr darauf synchronisieren.
https://erlangen.ccc.de/projects/dcf77/
@Benedikt
@T29
Ob illegal oder nicht, wenn Du nur eigene DCF-Dekoder testen willst und
dabei nicht "in die Luft gehst" oder Dich zumindest in der Ausbreitung
Deiner "Fehlinformationen" räumlich beschränkst, ist das sicherlich in
Ordnung. Einen DCF-Sender zu bauen, der vorsätzlich falsche
Uhrzeitinformationen ausgibt um damit "Schaden" anzurichten (ich
trage auch so eine Uhr am Handgelenk und habe mehrere davon zu Hause)
halte ich zumindest moralisch für sehr verwerflich. Es gibt zahlreiche
Besipiele, bei denen Falschinformationen zum Chaos führen können
(Ampelanlagen!).
"Was das Gesetz nicht verbietet, verbietet der Anstand!"
Jörg
Naja, ich mache demnächst auch einen DCF77-Sender, denn DCF77Fake (
https://erlangen.ccc.de/projects/dcf77/ ) erfordert ein LCD-Display,
das ich nicht habe.
Außerdem kann ich mit RTAI-Linux bis 400 kHz (Langwelle) die
Parallelport-Pins wackeln lassen, so daß die 77 kHz kein Problem sind
und als (zusätzliche) Hardware nur eine Spule am Parallelport nötig ist
;-)
bei so was is des natürlich ned illegal ich dachte du hast was richtig
großes gebaut und willst "On Air" gehen.
https://erlangen.ccc.de/projects/dcf77/ interresiert mich jetzt auch
aber leider ist der download-link kaputt. Wenn einer das Prog noch hat
dann fände ich es nett wenn ich es per E-Mail oder neuem Link bekommen
würde :-)
Irgendwo weiter unten unter http://mazzoo.de/code.html
In Langwelle "On Air" zu gehen ist etwas schwierig, wegen der großen
Wellenlänge. Mit einer CUL-Trommel am Datenport des Parallelports komme
ich auf rund 3 m Reichweite.
Beim Programm Clock Fake 77 soll man die Funktuhr auf das LCD-Display
legen, da das Display relativ schwach strahlt. Es gibt da auch Probleme
wie daß einige Uhren nur einmal pro Stunde synchronisieren, so daß es
länger laufen sollte.
Mein Funkuhr Sender war eigentlich nur ein Test, ob es überhaupt geht.
Mein Prof in Messtechnik hatte erzählt, dass er es nicht geschafft
hätte, da musste ich es eben einfach ausprobieren...
Der Sender lief auch nur rund 10 Stunden, bis sich alle Funkuhren
umgestellt hatten. Einige brauchten nur wenige Minuten, andere 5
Stunden. Die Reichweite war erstaunlich hoch (ca. 50m bei etwa 10% der
Sendeleistung eines TDA2030)
Das Programm ebenso erstaunlich einfach und in 30 minuten geschrieben.
Seitdem sende ich wieder auf rund 9kHz, und das ist legal...
@Uli: Kann es sein, dass deine Uhr 1 sec nachgeht? Die Uhrzeit wird
nämlich schon direkt mit dem Synchronisations-Bit in der 59. Sekunde
gesetzt und ist dann zur vollen Minute schon eine Sekunde weiter als
herkömmliche Funkuhren.
Ich ziehe jetzt in der Interrupt-Routine nach dem Setzen der Uhrzeit
erstmal eine Sekunde ab.
1
...
2
//Alle 59Bits empfangen stellen der Uhr nach DCF77 Buffer
Wenn die Uhr auch ohne DCF77-Signal weiterlaufen soll, müsste man
theoretisch auch noch um 24 Uhr das Datum weiterstellen. Das müsste
dann natürlich auch bei der Remove_one_second-Funktion berücksichtigt
werden. Also um 24 Uhr erstmal einen Tag zurückspulen. Das ganze wird
dann bloß etwas komplizierter, weil man Monatswechsel (sind ja
dummerweise nicht alle gleich lang) und Schaltjahre berücksichtigen
müsste.
mfg
see4far
@see4far
" if (ss == 0000) "
Führende Nullen sollte man sich schleunigst abgewöhnen.
Unter C bedeuten sie nämlich, daß diese Zahl als Oktalzahl
interpretiert wird.
D.h. es geht nur für Zahlen <= 7 gut.
Es sei denn Du bist wirklich noch so ein Freak aus der Lochkarten-Ära,
der oktal rechnet.
Peter
g ne, bin ich nicht... ursprünglich hatte ich das auch mit "00" und
nicht mit "0000" gepostet (siehe "view plain"). sieht man mal, wo
das alles falsch interpretiert werden kann. führende nullen gehören
also jetzt bei mir der vergangenheit an. wusste ich nicht.
@see4far
"Wenn die Uhr auch ohne DCF77-Signal weiterlaufen soll, müsste man
theoretisch auch noch um 24 Uhr das Datum weiterstellen. Das müsste
dann natürlich auch bei der Remove_one_second-Funktion berücksichtigt
werden."
Wie Du siehst, wird dadurch alles nur unnötig kompliziert.
Deshalb laufen bei meiner Routine die interne Uhr und der DCF77 Dekoder
völlig getrennt voneinander.
Und nur, wenn alle Fehlertests sagen, daß die DCF77-Zeit gültig ist,
wird sie einfach in die interne Uhr übernommen.
http://home.tiscali.de/peterd/appl/soft/c51/thclock/index.htm
Peter
Hallo,
jetzt - da meine DCF77-Uhr fertig programmiert ist - finde ich diesen
Thread ... welch ein Trauerspiel.
Ich möchte dennoch meinen Code zur Verfügung stellen, vielleicht findet
ja jemand gefallen daran.
Der µC wird für folgende Zwecke "mis"braucht:
1. 5stellige 7-Segment-LED-Anzeige ansteuern (gemuxt)
2. Umgebungshelligkeit messen
3. DCF77-Signal auswerten
4. Zeit zählen (Uhr)
Ich habe mich dagegen entschlossen, den Code auf mehrere Dateien zu
verteilen, weil man dann leicht auf die Versuchung reinfällt, ihn
unbesehen in ein neues Projekt zu übernehmen und sich somit viel Mühe
mit dem Fehlersuchen machen muss.
Der DCF77-Empfangsteil arbeitet etwa wie folgt:
Bei einer Flanke am Interrupt wird dieser ausgelöst. Er löscht einen
Counter und schaltet sich selbst ab.
Nach ca. 100ms (Counter) wird angefangen, in 12ms-Abständen, den
Zustand des DCF77-Pins in ein Register zu kopieren.
Nach ca. 200ms (Counter) wird das Register an die Behandlungsroutine
(asynchron) übergeben und diese zählt die Einsen im Register und
schließt auf eine 1 oder eine 0.
Nach ca. 700ms (Counter) wird der Interrupt wieder eingeschaltet.
Nach ca. 1.6s (Counter überlauf) wird die 60. Sekunde erkannt und der
Behandlungsroutine (asynchron) gemeldet.
Die asynchrone Kommunikation geschieht über Flags in einem Register
(rStatus). Diese ist nötig, um auch die anderen Aufgaben, die der µC zu
bewältigen hat, zeitgerecht unterzubringen.
Ich hoffe, der Code ist ausreichend kommentiert. Fragen/Kritik/Fehler
höhre ich in freundlicher Wortwahl immer gerne.
Clemens
PS: der Code muss vor dem assemblieren durch den cpp ;)
Die Anzeige ist ausserdem in etwa 3900 Schritten dimmbar :))
Hallo!
Zu Ulis soeit super funktionierendem Programm habe ich eine kleine
Anmerkung. Und zwar kann mein Compiler (avr-gcc) mit der folgenden
Zeile nicht so toll umgehen:
Funktioniert zwar, aber ich habe mir mal das Ergebnis in Assembler
angeschaut und war nicht ganz so begeistert:
- Zuerst wird eine 64-bit große 1 angelegt.
- Diese wird dann einer Methode übegeben, die 64-bit Zahlen shiftet.
- Letzendlich werden dann dieses lange Ergebnis mit dem rx-Buffer
geodert.
Besser fände ich, die Adresse des entsprechenden Bytes auszurechnen und
nur dort die Operation mit 8-bit auszuführen. Sieht dann so aus:
Ok, sieht nicht so schön aus, allerdings wird bei mir damit das
Programm um gut 400 Byte kleiner und vermutlich auch schneller.
Und wenn ich schon am meckern bin :), den rx-Buffer würde nicht nicht
in einem "unsigned long long" halten, sonden dem Compiler überlassen,
wie er dieses Struct speichert.
Das war's aber jetzt! :-)
Viele Grüße
Christian
.
Sorry, daß ich diesen alten Thread nochmal hochspüle, aber ich habe
noch Fragen dazu, die mir die Beteiligeten dank Erfahrungswerten sicher
auf Anhieb beantworten können.
Als ich das hier gelesen habe:
>>Hier mal ein neues Programm von mir für einen Atmel.
Dieses wertet ein DCF77 Signal aus und gibt es auf der seriellen
Schnittstelle aus.<<
dachte ich: Perfekt, exakt was ich lange suche.
...nur leider haben mich die nachfolgenden Postings etwas verwirrt, was
die Funktionssicherheit (Störempfindlichkeit, erst nachträglich
eingebauter Paritycheck etc.) angeht.
Leider bin ich in Assembler nicht firm genug um eure Statements
nachvollziehen zu können.
Wie verhält es sich damit, existiert eine letzte Version die stabil
läuft und auch bei störenden Magnetfeldern soweit softwareseitig
abgesichert ist, daß Sie nicht losrennt?
Vielen Dank schonmal für die Antworten.
MfG
Algernon
.
@Algernon,
"Wie verhält es sich damit, existiert eine letzte Version die stabil
läuft und auch bei störenden Magnetfeldern soweit softwareseitig
abgesichert ist, daß Sie nicht losrennt?"
Also meine Versionen laufen zuverlässig seit über 10 Jahren aufm 8051.
Und die AVR-Versionen benutzen ja exakt das gleiche Prinzip.
Durch die sehr strengen Prüfungen werden wohl auch viel korrekte Pakete
weggeschmissen, aber ein Update alle 24h sollte ja dicke ausreichen.
Eine Version mit dem MAX7219 als Displaytreiber stört sich selbst
(Multiplextakt) und die Antenne wollte ich nicht extra rausführen.
Daher wird das Display um 3:17Uhr für 6min abgeschaltet, wenn innerhalb
der letzten 24h kein Empfang möglich war. Auch diese Uhr läuft seit
Jahren einwandfrei. Jeder Fehlempfang wäre nicht zu übersehen, da er ja
bis zum nächsten 3:17Uhr angezeigt würde.
Peter
.
Danke für die Antworten, ich werde mir die Programme mal ansehen.
Nur zur Erläuterung:
Die DCF77-Uhr brauche ich um Terrarien- und Brutkastensteuerungen
autarkt arbeiten zu lassen - Futterautomat, Beleuchtung, Temperatur-
und Feuchtigkeitsregelung etc.
Deshalb ist besonders wichtig, daß mir die Uhr sicher niemals über
längere Zeit ernsthaft Quark ausgibt, sonst bräuchte ich auch kein
DCF-Empfang sondern könnte das einfach mit einer kalibrierten Quarz-Uhr
machen. Besonders im Urlaub wäre ein Stromausfall und
unsynchronisiertes, zufälliges Anlaufen z.B. beim Brutkasten
verhängnisvoll - da kann schnell mal ein komplettes Gelege dahin sein.
Deshalb suche ich nach einer Lösung, bei der (aus Sicherheitsaspekten)
ein eigener Controller die Tages-Zeit über die Uart ausgibt. Diplay und
Datum sind irrelevant, nur wenn man schon einen eignen Zeit-Server-µC
dezentral dazuzieht muß der seine (eine) Aufgabe 100%ig verlässlich
erfüllen - deshalb meine kritische Nachfrage.
Außerdem ist es schön eine Fertiglösung in der Schublade zu haben, die
man bei allen möglichen Anwendungen einfach anstöpseln kann um über
Absolutzeiten zu verfügen.
Nochmal Danke für eure Antworten!
MfG
Algernon
.
Hi!
ich habe die DCF-77 Uhr von Ulrich Radig um einen "ewigen Kalender"
erweitert. Ist eigentlich nicht nötig, aber es kann ja vorkommen, dass
in der letzten Minute vor 0:00 Uhr ein Empfangsfehler auftritt und
somit das Datum nicht sofort umgestellt wird.
Im Monat Februar wird berechnet, ob es sich um ein Schaltjahr handelt
oder nicht.
Vielleicht kann es ja jemand gebrauchen.
MfG
Steffen
Guten Abend,
ich habe auch vor für meinen Seminarkurs der Schule einen DCF-77 Sender
zu bauen. (Umkreis <10m) Das Funksignal würde ich gerne mit einem DCF-77
Empfänger oder einem Oszi auswerten. Wie der Empfänger realisierbar ist,
weiß ich schon. Jetzt geht es eigentlich nur noch um den Sender. Davon
habe ich keine Ahnung und ich würde mich gerne einmal damit
auseinandersetzen.
Was für technische Geräte werden dafür benötigt und wie kann ich diesem
Sender einen Impuls geben, dass er die Zeit xlz an den Empfänger
aussendet?
Viele Grüße
Christian
Wenn Du weißt, wie ein Empfänger funktioniert, dann kannst Du auch nen
Sender programmieren.
Einfach nen Pin-Toggle auf etwa 77,5kHz programmieren und dann für
100ms/200ms austasten.
Bzw. wenn mans ganz genau machen will, die 77,5kHz durchlaufen lassen
und per Spannungsteiler mit nem anderen Pin (trisate/low) auf 25%
abschwächen.
Peter
Aha, okay, ich verstehe ehrlich gesagt nur Bahnhof. Vielleicht habe ich
mich davor auch falsch ausgedrückt. Ich kenne das Prinzip eines
Empfängers, doch selbst gebaut habe ich jenen noch nicht.
MfG
Christian
Hab das Projekt mal nachgebaut und musste feststellen das nach der
Ausgabe diverser Parameter der Rx-Counter statt bis 59 bis 75 läuft.
Interessanter weise blinkt eine zur besseren Detektierung eines Pulses
vom DCF77 Modul perfekt je Sekunde aber bei der Ausgabe am Terminal
zählt der RxCounter manchmal alle ca. 0,5 Sekunden hoch was dann in 1
Minute 75 etwa ergibt. Bei Funkuhrzeit 00 Sekunden geht das dann wieder
auf 0. Also scheint ja nicht alles schief zu laufen. Aber wie kanns sein
das der 5 statt den 59 hat?
/Edit:
Ja am Fenster
Ja auch mit Batterie
Nein kein 10kOhm weil dann keine Daten mehr kommen (egal ob gegen Masse
oder gegen +5)
Modul: Das Neue von Pollin für 5 Euro
An dem µC ist nicht anderes angeschlossen und als Quellcode sogar Deinen
1:1 schon ausprobiert. Selbst wenn ich UART weg lasse und nur eine LED
ansteuer wenn ein Sync gekommen ist passiert nichts.
Könnte es sein das das Modul vom Pollin ein unsauberes Signal liefert
wenn da so viele Ints ausgelöst werden?
Ich bin hobbymäßig als Zauberer unterwegs, und ich suche für einen Trick
eine Möglichkeit eine Wanduhr mit Ziffernblattanzeige zu manipulieren.
Das heißt ein Zuschauer nennt eine Uhrzeit ,die dann im laufe der
Vorführung auf einer Uhr ,die die ganze Zeit mit einem Tuch verdeckt
einige Meter von mir stand auftaucht. Da ich im Forum schon etwas
gelesen habe bin ich auf die Sache mit dem DCF77 Sender gestoßen hört
sich sehr Interessant an da es ja Funkuhren mit Ziffferblatt schon für
wenig Geld zu kaufen gibt. Ich muss aber noch dazu sagen ich bin auf dem
Elektronikgebiet eine Niete , also wäre ich an einer Fertiglösung
interessiert.
Vielleicht gibt es ja noch andere Ideen zu dieser Sache für Hinweise
wäre ich dankbar. !!!
Mfg
Email info@cartec-gmbh.de
...und jetzt frag dich mal selbst, ob sowas wohl legal ist und es somit
"frei verfügbar" ist?! Ich helf dir: NEIN, ist es nicht!
Zumal solche Zaubertricks eher "uns" gehören :) Du darfst nur mit
Tüchern und Hasen spielen gähn
Klaus.
Da wird deine Vorführung sehr lange dauern müssen, da viele Funkuhren
nur ein- bis zweimal pro Tag synchronisieren. Normalerweise ändert sich
die Uhrzeit ja nicht "einfach so".
Überlege auch gerade ob ich mir das Pollin modul für 5 öcken kaufen
sollte!
Wäre schön wenn jemand seine Erfahrung mit uns teilen würde, ob das
Modul mit dem Code von Uli läuft!
Abendliche Grüße :-)
Hi Jonny ...
Ich habe mir kürzlich zwei Pollin DCF Module gekauft ... für mich
persönlich ein Griff in's Kloo :(
Erster Problem: Das Pollin Modul braucht an einem Anschluß einen
Flankenweschel nach dem Stromanlegen - wenn der nicht erfolgt empfängt
das Modul nicht ... hier ist also entweder ein zusätzlich Ausgang am
Controller notwendig - oder externe Elektronik.
Zweites Problem: Das Modul ist extrem Anfällig für Störimpule - ich hab
es ehrlich gesagt nicht hinbekommen mal für 2 Minuten nen sauberen
Empfang zu haben ...
Ich habe noch ein Modul von Conrad, für 10 €, das schließt du an und
fertig ...
Von daher würde ich vom Pollin Modul abraten ...
Moin!
ich hab ein Modul von Pollin, 5 euro, und des funzt super.
Hab PON u GND verbunden, damit das Modul immer arbeitet. Im
Netzteil-Betrieb voll OK, u bei wenigen µA Strom auch für Batterie OK
denke ich.
laut Beschreibung braucht das Modul nach dem starten bis zu 20 min, um
sich auf's Signal einzupendeln.
Ich habe den Empfänger in einer Werkstatt bei der Arbeit getestet und
das Signal mit einem Datenschreiber aufgenommen, und das Ergebnis ist
perfekt.
die werkstatt is was funksignale angeht ein Graus, viele metallregane,
hunderte netzteile, diverse andere dinge, die den funkempfang stören
könnten...
aber ob das modul letztenendes funktioniert hängt angeblich auch u.a.
von der ausrichtung ab.
Greetz from Hamburg
Nach meiner Erfahrung brauchen die gängigen '(verschiedenen) Uhren 2-3
Minuten. Der Erkennungsalgorithmus scheint eher primitiv. Würde sagen:
1. Minute: Suche nach Minuten-Anfang
2. Minute: Einlesen der Uhrzeut
3. Minute: Vergleich mit 2. Minute ob gültig
Gruß -
Abdul
Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum.
Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder
läuft absolut stabil.
Wenn es fertig ist soll es die unvermeidliche Nixi-Uhr werden.
Schpäschel Fietschers:
- Der DFC77 Decoder erkent die Polarität (invertiert oder nicht) des
DCF77 Signals automagisch.
- Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.
- Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt
dessen werden sie statisch mit einer länglichen 74HCT959 Kette +
Wagenladung MPSA42 angesteuert.
- Quazuhr mit DCF77 Kalibration. Die Uhrzeit kommt von einer Quazuhr,
die bei korrektem Empfang jede Minute mit der DCF77 Zeit synchronisiert
wird. Die Qurzuhr sorgt somit auch bei gestörtem Empfang für eine
richtige Zeitanzeige. Bei konstant gutem Empfang nutzt das Programm die
DCF77 Zeit als Referenz um die Quarzuhr zu kalibrieren. Die Abweichung
wird noch im EEPROM des AVR gespeichert. Die Auflösung ist 1:64000 = ca.
16 ppm = ca. 1 Sekunde in 18 Stunden. Das kann man noch genauer machen
(siehe AVR - Die genaue Sekunde / RTC), aber da die Quarzuhr
normalerweise öfter als alle 18 Stunden auf das DCF77 Signal
synchronisiert wird, ist das mehr als genau genug.
Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an.
Es gibt noch einige Unzulänglichkeiten, z.B. eine Race-Condition beim
Hochzählen von cal_tics... Die wesentlichen Funktionen stehen aber und
vielleicht ist es ja jemandem von Nutzen.
Du meist dein Empfangsmodul mal einige Tage durchlaufen lassen.
Normalerweise findet es immer einige brauchbare Daten innerhalb 24
Stunden. Mehr kannst du von diesen Schrottteilen leider nicht erwarten.
Wenn es dir nicht zuviel Aufwand ist, einfach die Antenne abändern in
einen größeren Stab und korrekt ausrichten. Das L und C der Antenne mußt
du dann natürlich entsprechend anpassen.
Gruß -
Abdul
CHH schrieb:
[Pollin DCF77 Modul]
> Zweites Problem: Das Modul ist extrem Anfällig für Störimpule - ich hab> es ehrlich gesagt nicht hinbekommen mal für 2 Minuten nen sauberen> Empfang zu haben ...
Ich hatte die Tage auch erhebliche Probleme mit dem Pollin Modul. Es
stellte sich heraus, dass mein provisorischer Aufbau eine unsaubere
Masseführung hatte. Das hat die Versorgungsspannung mit Störimpulsen von
den TTL Keksen verseucht. Das scheint das Modul garnicht zu mögen.
Störungen auf der Versorgungsspannung schlagen offenbar voll in den
Empfänger durch und bringen ihn ins Schleudern. Auch
Abblockkondensatoren (10 uF Elko und 100 nF KerKo) direkt auf dem Modul
halfen nicht. Mit sauberer, sternförmiger Führung von Masse und
Versorgungsspannung in der ganzen Schaltung arbeitet das Modul sehr
stabil. Meine Auswertung betreibt etwas Statistik. Der Empfang läuft
jetzt seit über zwei Stunden stabil, die Low-Pulse liegen alle zwischen
100 ms und 120 ms, die High-Pulse zwischen 200 ms und 220 ms. Dabei
liegt das Modul nur ca. 30 cm neben einem 21" Röhrenmonitor auf dem
Schreibtisch.
Jochen Kunz schrieb:
> Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum.> Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder> läuft absolut stabil.
-- Richtig ausrichten
-- Keine SNT/SMPS in der Schaltung (HV für die Nixies?)
-- keine µC, geMUXte Anzeigen etc in unbittelbarer Nähe
-- möglichst keine Metallteile (Stahlbeton, ...)
Der Empfang ist bekanntermaßen tageszeit- und witterungsabhängig.
> - Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.
Eine meiner Uhren tickt in Wien, da ist die Empfangslage bekanntermaßen
übel. Ich musste die Keule auspacken, aber demit geht die Uhr ;-)
http://www.gjlay.de/pub/dcf77/konzept.html> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +> Wagenladung MPSA42 angesteuert.
Schliesst MUX ja nicht aus.
> - Quazuhr mit DCF77 Kalibration.
Wieso ne Quarzuhr? Es reicht doch der normaler Quarz, der den µC
antickt. Kalibrierung ist bei der guten Empfangslage in D nicht nötig,
da alle naselang eni Abgleich stattfindet.
> Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an.> Es gibt noch einige Unzulänglichkeiten,
fehlt zB die Tomatensosse zum Spaghetti-Code fg
Johann L. schrieb:
> Jochen Kunz schrieb:>> Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum.>> Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder>> läuft absolut stabil.> -- Richtig ausrichten
Klar. Breitseite der Antenne => FFM.
> -- Keine SNT/SMPS in der Schaltung (HV für die Nixies?)
Schnöde, altmodische 50 Hz Trafos mit Längsregler. (HV für die Nixis
macht ein "verkertherum" geschalteter Netztrafo.)
> -- keine µC, geMUXte Anzeigen etc in unbittelbarer Nähe
Ohne uC wird es schwer. Anzeige wird auch as dem Grund nicht gemuxt.
> -- möglichst keine Metallteile (Stahlbeton, ...)
Klar.
> Der Empfang ist bekanntermaßen tageszeit- und witterungsabhängig.>>> - Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.> Eine meiner Uhren tickt in Wien, da ist die Empfangslage bekanntermaßen> übel. Ich musste die Keule auspacken, aber demit geht die Uhr ;-)> http://www.gjlay.de/pub/dcf77/konzept.html
Verglichen mit dem Aufwand ist mein Kram harmlos. Aber Kaiserslautern
liegt etwas näher am Sender als Wien... :-)
>> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt>> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +>> Wagenladung MPSA42 angesteuert.> Schliesst MUX ja nicht aus.
Wenn man muxt könnte man sich aber auf Kosten eines uC mit mehr IO-Pins
die 74595 sparen...
>> - Quazuhr mit DCF77 Kalibration.> Wieso ne Quarzuhr? Es reicht doch der normaler Quarz, der den µC> antickt.
Genau das meine ich ja mit Quarzuhr.
> Kalibrierung ist bei der guten Empfangslage in D nicht nötig,> da alle naselang eni Abgleich stattfindet.
Idee: Soll die Uhr irgendwo mit schlechtem Empfang stehen läuft sie
wegen fehlender Synchronisation weg. Wenn man sie aber vorher mal einen
Tag irgendwo bei gutem Empfang stehen lässt, wird der Quarz kalibriert,
die Abweichung in EEPROM gespeichert und nach dem Ortswechsel hat man
vielleicht keine DCF77 Uhr mehr, aber immerhin eine kalibrierte
Quarzuhr.
>> Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an.>> Es gibt noch einige Unzulänglichkeiten,> fehlt zB die Tomatensosse zum Spaghetti-Code *fg*
Die Spaghetti sind ja auch noch nicht al dente. ;-)
Die von mir eingestellte, vorläufige Version hat mindestens einen Bug
beim einlesen des Bit 58 (Parity Datum).
Jochen Kunz schrieb:
> Johann L. schrieb:>> Jochen Kunz schrieb:>>> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt>>> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +>>> Wagenladung MPSA42 angesteuert.>> Schliesst MUX ja nicht aus.> Wenn man muxt könnte man sich aber auf Kosten eines uC mit mehr IO-Pins> die 74595 sparen...
Schon, aber mit Expandern hat man alle Optionen offen.
Die sind schnell genug, um auch über SPI ein Soft-MUX zu fahren. Auf
diese Weise kann man dann auch Kathoden der selben Röhre gegeneinander
MUXen um fliessende Übergänge benachbarter Zahlen/Ziffern zu
realisieren, darüber wird dann nochmal geMUXt, um die Helligkeit der Uhr
einzustellen (zB an die Umgebungshelligkeit anzupassen).
Ohne Expander hat man viel weniger Freiheiten was die Ansteuerung
angeht.
Und wie gesagt... mögen/können nicht alle Nixies auf MUX.
Johann
Die Pollin-Module sind dafür bekannt, dass sie auf der steigenden Flanke
einen überlagerten Rechteck haben. Je nach Empfindlichkeit des Eingangs,
an dem das Modul angeschlossen wird, kann das zu zusätzlich erkannten
Impulsen führen. Ein Schmitt-Trigger oder Debouncing wie bei Tasten
hilft ab.
Hallo!
Ich benutze die Sourcen von U. Radig seiner Homepage!
Also Version 1.5!
Soweit läuft alles super und Empfang habe ich auch gut (Modul vom C),
aber bei jedem Stundenwechsel zählt er eine Stunde zu weit und
nach ca. 2 min stimmt die Zeit dann wieder vom DCF.
Hatt jemand von euch schon das Problem gehabt?
Was kann ich ändern daran?
Danke
Gruß Denny
Hallo,
bei mir (mit 1MHz Takt am AVR) funktioniert die Erkennung der Pulsbreite
nicht richtig. Ich nehme an, sie funktioniert wenn man den AVR höher
taktet und damit weniger Rundungsfehler bekommt.
Das Problem liegt in dieser Zeile:
1
if(pulse_wide>(65535-(SYSCLK/1024)/100*85))
Statt SYSCLK habe ich F_CPU genommen, und das ist 1000000.
So funktioniert es bei mir:
> Das müsste dann aufs gleiche rauskommen wie deine Variante.
Nicht ganz. Meine Variante macht keinen Rundungsfehler wenn SYSCLK nicht
durch 100 teilbar ist. Zugegeben, das ist ziemlich unwahrscheinlich.
Deine Variante ist sogar besser weil da keine so großen
Zwischenergebnisse rauskommen (also gibts nicht so schnell einen
Überlauf).
sebastians schrieb:> Nicht ganz. Meine Variante macht keinen Rundungsfehler wenn SYSCLK nicht> durch 100 teilbar ist. Zugegeben, das ist ziemlich unwahrscheinlich.
Stimmt, es könnte einen Rundungsfehler geben. Dieser ist aber viel
kleiner als der Rundungsfehler den wir beim Dividieren durch 1024
machen. Im schlimmsten Fall haben wir schlussendlich statt einer
Abweichung von 1.0 eine Abweichung von 1.083. Wenn es genauer sein
müsste, könnte man noch etwas besser runden:
1
if(pulse_wide>(65535-(SYSCLK/100*85+512)/1024))
Dann hätte man eine maximale Aweichung von +-0.583.
Rolf
Hallo, ich habe den Code für einen Atmega161 angepasst, vielleicht hilft
es weiter. Jedoch habe ich eine Compiler-Meldung, die mir rätselhaft
ist. Wäre schön wenn mir diese Meldung jemand erklären könnte. Wird im
Code von Uli irgendwo Speicher zugeteilt, der aber nicht genutzt wird?
Mir ist nichts bekannt. Danke.
Thorsten
Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
c:\Programme\WinAVR-20100110\bin\avr-objcopy.exe: --change-section-lma
.eeprom=0
x00000000 never used
So the my problem is here:
TIMER1 doesn´t working.
But when I disable external interrupt, so theTIMER1 working normaly.
Test by blink LED.
So why the TIMER1 is not working?? And F_CPU is 16000000.
The critical section is here:
http://paste.ofcode.org/nvfTeaVQwPB3pMAuWB62Z3
Any idea, how this problem resolved?