Hallo, Ich bin auf der SUche nach einer Library für den ESp8266 und dem DCF77 Signal. Bis jetzt habe ich leider noch keine passende Library gefunden die funktioniert. Wenn ich folgende nehme https://playground.arduino.cc/Code/DCF77 Dann bekomme ich folgende Fehlermeldung "#error Unsupported controller architecture" Sprich die Library ist für den controller ungeeignet. Auch diverse andere Librarys konnte ich leider nicht verwenden. Hat jemand von euch eine?
Zwar am Thema vorbei: Aber wieso DCF77 und nicht einfach einen NTP-Server kontaktieren, wenn man doch eh am Netzwerk hängt?
Thomas F. schrieb: > Zwar am Thema vorbei: Aber wieso DCF77 und nicht einfach einen > NTP-Server kontaktieren, wenn man doch eh am Netzwerk hängt? ja das Klingt soweit ganz gut, aber ich wollte beide sachen bei mir implementieren. Wenn kein Wlan vorhanden ist dann DCF77 oder andersherum
Espler schrieb: > Sprich die Library ist für den controller ungeeignet. Korrekt! Die ist ja auch für einen Arduino gedacht. Welches DCF77-Modul hast du denn zuhause? Würde es eventuell funktionieren wenn du einen Arduino mit einem RTC-Modul verbindest und dann den ESP dazu benutzt die Zeit auf Atomzeituhr-Niveau zu synchronisieren? So alle paar Stunden...der olle Grieche Chronos schwört heute noch darauf! MFG Beast
Espler schrieb: > Ich bin auf der SUche nach einer Library für den ESp8266 und dem DCF77 > Signal. Dann schau Dir doch die Bibliothek an und schreibe diese für den ESP8266 um. So schwer ist das nicht und man lernt eine Menge dabei. Der Compiler unterstützt einen dabei durch Fehlermeldungen ;-)
BeastyK schrieb: > Espler schrieb: >> Sprich die Library ist für den controller ungeeignet. > > Korrekt! Die ist ja auch für einen Arduino gedacht. Welches DCF77-Modul > hast du denn zuhause? > > Würde es eventuell funktionieren wenn du einen Arduino mit einem > RTC-Modul verbindest und dann den ESP dazu benutzt die Zeit auf > Atomzeituhr-Niveau zu synchronisieren? So alle paar Stunden...der olle > Grieche Chronos schwört heute noch darauf! > > MFG Ich habe das DCF77 Modul von Pollin geholt, dahinter ein Impedanzwandler geschaltet und das SIgnal soll der uC bekommen. Um die FUnktion des DCF SIgnals zu testen habe ich am Ausgang des OPVs eine Led geschaltet. Soweit so gut klappt auch alles nur das Programm fehlt mir noch. Ich dachte nur das es schon eine Lib für den uC gibt.
Die Verarbeitung des Signals (fachlich) kannst Du ja aus den vorhandenen Libs extrahieren. Nur das GPIO Handling (technisch) musst Du anpassen.
Huhu, ich möchte nicht als Rumnörgler in die Geschichte eingehen, aber es gibt auf dem Forum genug Threads die arg mit dem Pollin Modul gekämpft haben. Wie schnell und gut das funktioniert hängt davon ab wo du dich befindet (Sender -> Empfänger) und so weiter...kann gut gehen, muß aber nicht! Wozu dient das denn am Ende? Gruß Beast
Das Modul von ELV ist auch nicht besser. Ich hatte beide wochenlang nebeneinander liegen.
Also das von Elv ist mir noch nicht in die Finger gefallen. Der TO hat wohl genug umme Ohren. Das war bei den Pollinboards aber kein I2C oder SPI...war einfach nur ein Pin wo dann was ankam was man noch interpretieren mußte, oder? Wurden da nicht auch noch Wetterdaten mit verschickt, is ewig her das ich die Threads verfolgt hab... Gutes Nächtle Beast
BeastyK schrieb: > Huhu, ich möchte nicht als Rumnörgler in die Geschichte eingehen, aber > es gibt auf dem Forum genug Threads die arg mit dem Pollin Modul > gekämpft haben. Wie schnell und gut das funktioniert hängt davon ab wo > du dich befindet (Sender -> Empfänger) und so weiter...kann gut gehen, > muß aber nicht! Es hängt vor allem von den Störquellen im Nahfeld ab, ob so ein Modul funktioniert und wie gut es das tut. Dabei ist ziemlich egal, ob von Pollin, ELV, Reichelt oder aus einem geschlachteten Funk-Wecker. Was die Dinger allesamt garnicht mögen ist: - (billige) Schaltnetzteile als Stromversorgung - Verbraucher, die häufig hohe Stromgradienten produzieren (z.B. Servos oder Schrittmotore und natürlich PWM-gesteuerte LEDs) All dieses Zeug sendet so laut und breitbandig, dass nur eins wirklich hilft: mehr Abstand zwischen DCF-Modul und der Quelle des Übels. > Das war bei den Pollinboards aber kein I2C oder SPI...war einfach nur > ein Pin wo dann was ankam was man noch interpretieren mußte, oder? So sind die relativ preiswerten Dinger eigentlich alle gestrickt. Ist aber kein Problem, für das "Interpretieren" gibt's wahrscheinlich hunderte Codebeispiele. Das Problem ist halt nur: mit einem starken Störer in der Nähe sondern diese Module schlicht garnix mehr ab, da hilft dann auch der beste Auswertungcode nix. Aus einem Dauerstrich am Eingang kann auch der keine Information entnehmen.
c-hater schrieb: > Was die Dinger allesamt garnicht mögen ist: > > - (billige) Schaltnetzteile als Stromversorgung > - Verbraucher, die häufig hohe Stromgradienten produzieren (z.B. Servos > oder Schrittmotore und natürlich PWM-gesteuerte LEDs) - falsche Position der Ferritantenne Hatte vor einiger Zeit mit dem Pollin-Modul mal rumgetestet - horizontal stabiler Betrieb auf Breadboard im Keller; je mehr man in die Vertikale verdrehte, desto schlechter der Empfang. In der Vertikalen dann praktisch null... Funktechnisch sicherlich 'normal' und erklärbar, im Eifer des Bastelns achtet man da aber oft nicht drauf...
SO Leute, ich habe gestern abend noch einmal etwas herum programmiert und zwar kann ich die folgende LIB https://github.com/PaulStoffregen/Time jetzt einbinden. Was habe ich getan. Die lib heruntergeladen. Den Ordner unter einem anderen namen abgespeichert und dann mit "TimeLIb.h" eingebunden.(es kommt keine Fehlermeldung mehr) Nun möchte ich folgende LIb verwenden https://playground.arduino.cc/Code/DCF77 nur leider funktioniert das Programm immernoch nicht in den folgenden zeilen
1 | #define DCF_PIN 2 // Connection pin to DCF 77 device
|
2 | #define DCF_INTERRUPT 0 // Interrupt number associated with pin
|
Habe ich mein Pollin DCF Modul an Pin D0 angeschlossen d.h. im Programmcode ist DCF_PIN D0 Hatte einer von euch schon einmal ein ähnliches Problem und konnte es beheben oder einen Hinweis wesewegen die LIB immernoch nicht funktioniert
PD0 und PD1 sind in der regel mit dem seriellen Port verbunden und dadurch bereits intern belegt. Du solltest zuerst einfach mal den Pin einlesen und auf eine LED ausgeben (per Software!), um zu prüfen, ob die Hardware überhaupt funktioniert.
1 | void setup() |
2 | {
|
3 | DDRD |= 8; // PD3 = LED Ausgang |
4 | }
|
5 | |
6 | void loop() |
7 | {
|
8 | |
9 | if (PIND & 4) // PD2 = DCF Signal Eingang |
10 | {
|
11 | PORTD |= 8; |
12 | }
|
13 | else
|
14 | {
|
15 | PORTD &= ~8; |
16 | }
|
17 | }
|
Stefan U. schrieb: > Du solltest zuerst einfach mal den Pin einlesen und auf eine LED > ausgeben (per Software!), um zu prüfen, ob die Hardware überhaupt > funktioniert. Vielen Dank erst einmal hierfür. Die Hardware an sich funktioniert. Ich habe das Signal mit einem Oszilloskop gegengeprüft und ich habe parallel dazu am Ausgang des DCF moduls ein Impedanzwandler geschaltet der aktuell eine LED und den uC Pin treibt. Das Signal wird wiederrum vom uC verabreitet und der schaltet die LED auf dem ESP8266 Board an und aus. -> das Klappt Stefan U. schrieb: > PD0 und PD1 sind in der regel mit dem seriellen Port verbunden und > dadurch bereits intern belegt. SPrich ich kann einen beliebig anderen Pin nehmen, bis auf PD0 und PD1?
> ich kann einen beliebig anderen Pin nehmen, bis auf PD0 und PD1? Nur die Pins, die nicht schon anders belegt sind. Ein Blick in den Schaltplan deines konkreten Moduls kann dabei hilfreich sein. > leider funktioniert das Programm immer noch nicht Was ist denn nun dein konkretes Problem? "Funktioniert nicht" ist ein bisschen mager formuliert. PS: Warum weiß ich das eigentlich auswendig, obwohl ich AVR's noch nie mit Arduino programmiert habe?
Stefan U. schrieb: > PS: Warum weiß ich das eigentlich auswendig, obwohl ich AVR's noch nie > mit Arduino programmiert habe? Weil du schon andere uC programmiert hast und es immer ähnlich verläuft. Die PICs sind doch auch so: Schalte die Peripherie aus, Definiere den Pin als Ausgang/Eingang, was ist mit den Fuse-Bits. Geht was nicht dann blockiert oft etwas. Gruß Beast
:
Bearbeitet durch User
> Weil du schon andere uC programmiert hast und es immer ähnlich verläuft.
Das auch, aber vor allem, weil ich die Datenblätter der Chips lese,
bevor ich sie benutze.
Stefan U. schrieb: >> leider funktioniert das Programm immer noch nicht > > Was ist denn nun dein konkretes Problem? "Funktioniert nicht" ist ein > bisschen mager formuliert. So ich habe gerade eben noch einmal den Programmcode ausprobiert. Hier ist er vorab schon einmal
1 | /*
|
2 | * DCFBinaryStream.ino
|
3 | * example code illustrating time synced from a DCF77 receiver
|
4 | * Thijs Elenbaas, 2012
|
5 | * This example code is in the public domain.
|
6 |
|
7 | This example shows the binary stream generated by the
|
8 | pulse train coming from the DCF decoder and the resulting
|
9 | time
|
10 | In order for this example to give output from the DCF library,
|
11 | make sure that logging is turned on in the DCF library. You can
|
12 | do this by adding the #define VERBOSE_DEBUG 1 in Utils.cpp.
|
13 |
|
14 | NOTE: If you used a package manager to download the DCF77 library,
|
15 | make sure have also fetched these libraries:
|
16 | |
17 | * Time
|
18 | |
19 | A package that includes all referenced libraries can be found at:
|
20 | https://github.com/thijse/Zipballs/blob/master/DCF77/DCF77.zip?raw=true
|
21 |
|
22 | */
|
23 | |
24 | |
25 | #include <DCF77.h> //https://github.com/thijse/Arduino-Libraries/downloads |
26 | #include <TimeLib.h> |
27 | //#include <Time.h> //http://www.arduino.cc/playground/Code/Time
|
28 | |
29 | |
30 | #define DCF_PIN D3 // Connection pin to DCF 77 device
|
31 | #define DCF_INTERRUPT 2 // Interrupt number associated with pin
|
32 | |
33 | time_t time; |
34 | |
35 | DCF77 DCF = DCF77((DCF_PIN),DCF_INTERRUPT); |
36 | |
37 | void setup() { |
38 | Serial.begin(9600); |
39 | Serial.println("1 - binary 1 corresponding to long pulse"); |
40 | Serial.println("0 - binary 0 corresponding to short pulse"); |
41 | Serial.println("BF - Buffer is full at end of time-sequence. This is good"); |
42 | Serial.println("EoB - Buffer is full before at end of time-sequence"); |
43 | Serial.println("EoM - Buffer is not yet full at end of time-sequence"); |
44 | DCF.Start(); |
45 | }
|
46 | |
47 | void loop() { |
48 | delay(1000); |
49 | time_t DCFtime = DCF.getTime(); |
50 | if (DCFtime!=0) { |
51 | digitalClockDisplay(DCFtime); |
52 | }
|
53 | }
|
54 | |
55 | void digitalClockDisplay(time_t _time){ |
56 | tmElements_t tm; |
57 | breakTime(_time, tm); |
58 | |
59 | Serial.println(""); |
60 | Serial.print("Time: "); |
61 | Serial.print(tm.Hour); |
62 | Serial.print(":"); |
63 | printDigits(tm.Minute); |
64 | Serial.print(":"); |
65 | printDigits(tm.Second); |
66 | Serial.print(" Date: "); |
67 | Serial.print(tm.Day); |
68 | Serial.print("."); |
69 | Serial.print(tm.Month); |
70 | Serial.print("."); |
71 | Serial.println(tm.Year+1970); |
72 | }
|
73 | |
74 | void printDigits(int digits){ |
75 | // utility function for digital clock display: prints preceding colon and leading 0
|
76 | Serial.print(":"); |
77 | if(digits < 10) |
78 | Serial.print('0'); |
79 | Serial.print(digits); |
80 | }
|
Ich habe das DCF SIgnal an den jeweiligen Pin angeschlossen. Der uC detektiert dieses auch richtig und schaltet auf dem uC Board die LED an und aaus. Das Programm an sich liefert keine Zeit, Datums oder ähnliche Parameter. Lediglich die SeriellAusgaben vom "Setup" werden ausgegeben. Hardwaremäßig würde daher den Fehler nicht sehen sondern in der Software. ... Hast du bzw. ihr denn noch tipps um den Fehler weiter lokalisieren?
D3 ist zumindest beim NodeMCU der Pin GPIO0. Dieser Pin steuert beim Starten den Bootloader. Da würde ich keine Sachen dranhängen, die beim Start einen zufälligen Signalpegel abgeben. Um Irritationen zu vermeiden rate ich dazu, keine D-Nummern zu benutzen. Verwende lieber einfache Integer Zahlen, diese entsprechen den GPIO Nummern des ESP Chips. Ich habe auf dem ESP8266 noch nie mit Interrupts gearbeitet. Aber ein kurzer Blick in die Quelltexte des ESP8266 core sagt mir, dass du die gleiche Pin Nummer auch für Interrupts angeben musst. Um zu kontrollieren, ob die Interrupts funktionieren, kannst du innerhalb des Interrupthandlers einfach mal eine LED blitzen lassen oder eine Meldung auf dem Seriellen Port ausgeben. Ziel ist es, nachzuvollziehen, welche Teile des Programmes durchlaufen werden, und welche nicht. Prinzipiell halte ich die Methode, hier Interrupts zu verwenden, für fragwürdig. Das DCF Signal kann wild flackern, wenn der Empfang schlecht ist, und dadurch dein ganzes ESP-Modul lahm legen.
delay(1000) oder andere delays sind bei ESP8266 ganz schlecht bzw. tabu.
> delay(1000) oder andere delays sind bei ESP8266 ganz schlecht bzw. tabu.
Das ist nicht richtig. Der Delay Befehl enthält eine Schleife, in der so
oft yield() aufgerufen wird, bis die gewünschte Anzahl von Systicks
erreicht wurden.
Die yield() Prozedur wiederum ruft den lwIp Stack auf.
delayMicroseconds() hingegen macht das nicht. Da muss man aufpassen.
Dennoch rate ich auch dazu, Programme so zu schreiben, dass sie ohne
delay() auskommen. Das kann man mit Zustandsautomaten machen und so auch
mehrere Threads parallel abarbeiten.
Ich bin verwundert, dass gerade im Arduino Umfeld so selten von dieser
Technik Gebrauch gemacht wird. Denn das Framework ist dafür gerade ideal
geeignet, ebenso der IP-Stack vom ESP8266.
Pete K. schrieb: > delay(1000) oder andere delays sind bei ESP8266 ganz schlecht bzw. tabu. Meine Frage zu der Delay Funktion im Programm. Wie genau ist die ? Wenn ich zum beispiel die Uhr nach einer gewissen Betriebslaufzeit X immernoch über DCF 77 laufen habe, kann es dann sein das die die Funktion das Signal zu falschen Zeitpunkten abtastet, so dass die aktuelle Uhrzeit nicht mehr gelesen werden kann? Schließlich könnte die delay funktion ja nicht genau sein.
> Meine Frage zu der Delay Funktion im Programm. Wie genau ist die ?
Es wird ein Systemtimer verwendet, der Quarz-genaue Millisekunden zählt.
Allerdings wird innerhalb der Schleife mit yield() Zeit an den IP-Stack
abgegeben. Und wie lange der braucht, um fertig zu werden, weiss man
nie.
Das heisst in der Praxis, der Delay ist immer mindestens genau so lange,
wie angefordert. Er kann aber beliebig länger dauern. Das ist bei
Windows übrigens auch so.
Ich denke, in deiner konkreten Anwendung ist das egal. Denn niemand
fordert, dass du die Uhr im Sekundentakt ausliest. Es kann aber unter
Umständen passieren, dass die Anzeige ein paar Sekunden lang einfriert
weil der IP-Stack intern beschäftigt ist. Danach "springt" die Anzeige
dann auf die richtige Zeit.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.