Lib für ESp8266 und DCF77

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

Das Modul von Pollin kannst du ruhig direkt an den µC anschließen.

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.

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

> 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.

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.