Datum:
Angehängte Dateien: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
Datum:
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
Datum:
Hallo, Also habe noch die 24Stunden geändert. Weitere Infos bzw. neuer SourceCode auf meiner Homepage. Mfg Uli
Datum:
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
Datum:
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.
Datum:
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
Datum:
Angehängte Dateien:Hallo, So habe noch die Berechnung geändert. Parity werde ich evt. auch noch einarbeiten habe mir dazu was ausgedacht. Bis dahin..... Mfg Uli
Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
@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
Datum:
Machne Module haben ein invertiertes Datensignal! Das sollte mit dem Oszi rausgemessen werden und ggf. in der Routine geändert werden. Stefan
Datum:
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...
Datum:
Hallo ? Gehts noch ? was soll da bitte illegal sein ? Wie war das noch ? wer keine Ahnung hat sollte lieber ruhig sein ?
Datum:
> 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/
Datum:
@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
Datum:
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 ;-)
Datum:
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 :-)
Datum:
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.
Datum:
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...
Datum:
Eine 25m Rolle 5x1,5mm² Kabel, die mit einem Kondensator auf Resonanz abgestimmt wurde.
Datum:
Die Spannung an der Spule steigt bei richtiger Abstimmung auf über 200Veff an, wenn man etwa 5-10Veff einspeist.
Datum:
Also ein Kondensator in Reihe zur Spule und den Kondensator an den Verstärker-Ausgang angeschlossen, oder?
Datum:
danke erstmal. gibt es davon auch ne kompilierte version weil ich hab keine Ahnung davon???
Datum:
@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.
...
//Alle 59Bits empfangen stellen der Uhr nach DCF77 Buffer
{
//Berechnung der Minuten BCD to HEX
mm = rx_buffer->Min-((rx_buffer->Min/16)*6);
//Berechnung der Stunden BCD to HEX
hh = rx_buffer->Hour-((rx_buffer->Hour/16)*6);
//Berechnung des Tages BCD to HEX
day= rx_buffer->Day-((rx_buffer->Day/16)*6);
//Berechnung des Monats BCD to HEX
mon= rx_buffer->Month-((rx_buffer->Month/16)*6);
//Berechnung des Jahres BCD to HEX
year= 2000 + rx_buffer->Year-((rx_buffer->Year/16)*6);
//Sekunden werden auf 0 zurückgesetzt
ss = 0;
Remove_one_Second();
flags.dcf_sync = 1;
}
...
|
Hier die Funktion dazu.
//############################################################################ //Zieht 1 Sekunde ab void Remove_one_Second (void) //############################################################################ { if (ss == 00) { ss = 59; if (mm == 00) { mm = 59; if (hh == 00) { hh = 23; } else hh--;//1 Stunde abziehen } else mm--;//1 Minute abziehen } else ss--;//1 Sekunde abziehen }; |
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
Datum:
@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
Datum:
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.
Datum:
@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/thcloc... Peter
Datum:
Angehängte Dateien: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 :))
Datum:
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:
dcf_rx_buffer = dcf_rx_buffer | ((unsigned long long) 1 << rx_bit_counter); |
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:
((uint8_t *)&dcf_rx_buffer)[rx_bit_counter >> 3] |= (uint8_t)(1 << (rx_bit_counter % 8)); |
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
Datum:
.
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
.
Datum:
@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
Datum:
. 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 .
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Autor:
Ulrich Radig
(radiguli)
Datum:
Hallo, Ich gehe mal von zu vielen Interrupts aus. Die Anzeige wechselt bei dem auslösen eines Interrupts. Gruß Uli
Datum:
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?
Datum:
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
Datum:
...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.
Datum:
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".
Datum:
Hat jemand schon einmal das Programm mit dem Pollin-Modul getestet ? Sind Änderungen notwendig ?
Datum:
Ü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 :-)
Datum:
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
Datum:
@ Gast (Gast) >laut Beschreibung braucht das Modul nach dem starten bis zu 20 min, um >sich auf's Signal einzupendeln. Eher 20s.
Autor:
Abdul K.
(ehydra)
Datum:
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
Datum:
Angehängte Dateien: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.
Autor:
Abdul K.
(ehydra)
Datum:
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
Datum:
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.
Datum:
>30 cm neben einem 21" Röhrenmonitor
Du wohnst doch wohl nicht in Mainflingen? :) Z8
Autor:
Johann L.
(gjlayde)
Datum:
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
Datum:
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).
Autor:
Johann L.
(gjlayde)
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
Datum:
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.
Datum:
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
Datum:
Hi, gibs dazu auch eine Anleitung für doofe ? Ich würde gern die DCF77 Zeit an RS232 senden. Da bin ich hier doch richtig oder ? ;-)
Datum:
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:
if (pulse_wide > (65535 - (SYSCLK / 1024)/100*85)) |
Statt SYSCLK habe ich F_CPU genommen, und das ist 1000000. So funktioniert es bei mir:
static const uint16_t pulse_compare = 65535 - (uint32_t)F_CPU*85UL/(1024UL*100); // 64705 for F_CPU=1000000 ... if (pulse_wide > pulse_compare) |
Der 32-bit-Wert läuft irgendwo um die 50MHz CPU-Takt über - ab da gehts so nicht mehr.
Datum:
sebastians schrieb: > Das Problem liegt in dieser Zeile: >
if (pulse_wide > (65535 - (SYSCLK / 1024)/100*85)) |
Die einten Klammern sind eh überflüssig: if (pulse_wide > (65535 - SYSCLK/1024/100*85)) jetzt noch die Division mit 1024 an den Schluss nehmen:
if (pulse_wide > (65535 - SYSCLK/100*85/1024)) |
Das müsste dann aufs gleiche rauskommen wie deine Variante. Rolf
Datum:
> 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).
Datum:
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:
if (pulse_wide > (65535 - (SYSCLK/100*85+512)/1024)) |
Dann hätte man eine maximale Aweichung von +-0.583. Rolf
Datum:
Hallo zusammen, hat jemand hier den code von Uli auf ein Atmega8 umgeschrieben, bitte posten Sie es. David
Datum:
Angehängte Dateien: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
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten