udoklein / dcf77 Goto Github PK

This is an issue that was noticed by @nameoftherose in the discussion of issue #31. The library sometimes transitions from synced directly to free although it should not.

Simple_Clock

Simple_Clock.ino: In function 'void setup()':
Simple_Clock.ino:59:21: error: 'Clock' is not a namespace-name
Simple_Clock.ino:59:26: error: expected namespace-name before ';' token
Simple_Clock.ino:89:26: error: 'Clock' has not been declared
Simple_Clock.ino:90:18: error: 'Clock' has not been declared
Simple_Clock.ino:90:45: error: 'Clock' has not been declared
Simple_Clock.ino:94:9: error: 'Clock' has not been declared
Simple_Clock.ino:94:23: error: expected ';' before 'now'
Simple_Clock.ino:95:39: error: 'now' was not declared in this scope
Simple_Clock.ino: In function 'void loop()':
Simple_Clock.ino:114:5: error: 'Clock' has not been declared
Simple_Clock.ino:114:19: error: expected ';' before 'now'
Simple_Clock.ino:116:35: error: 'now' was not declared in this scope
Simple_Clock.ino:119:18: error: 'Clock' has not been declared
Simple_Clock.ino:120:18: error: 'Clock' has not been declared
Simple_Clock.ino:121:18: error: 'Clock' has not been declared
Simple_Clock.ino:122:18: error: 'Clock' has not been declared

The_Clock

The_Clock.ino:91:31: error: 'Clock' does not name a type
The_Clock.ino:91:45: error: expected unqualified-id before '&' token
The_Clock.ino:91:45: error: expected ')' before '&' token
The_Clock.ino:91:46: error: expected initializer before 'decoded_time'
The_Clock.ino: In function 'void MaxTicks::setup()':
The_Clock.ino:120:41: error: 'output_handler' was not declared in this scope
The_Clock.ino: At global scope:
The_Clock.ino:125:31: error: 'Clock' does not name a type
The_Clock.ino:125:45: error: expected unqualified-id before '&' token
The_Clock.ino:125:45: error: expected ')' before '&' token
The_Clock.ino:125:46: error: expected initializer before 'decoded_time'
The_Clock.ino: In function 'void Ticks::setup()':
The_Clock.ino:150:41: error: 'output_handler' was not declared in this scope
The_Clock.ino: At global scope:
The_Clock.ino:155:31: error: 'Clock' does not name a type
The_Clock.ino:155:45: error: expected unqualified-id before '&' token
The_Clock.ino:155:45: error: expected ')' before '&' token
The_Clock.ino:155:46: error: expected initializer before 'decoded_time'
The_Clock.ino:385:1: error: expected '}' at end of input

EDIT
IDE information: Arduino 1.6.0 from arduino.cc

EDIT2
added markdown for code sections

Logfiles found here:
https://github.com/nameoftherose/dcf77-leonardo_support/tree/master/logfiles

indicate that the clock has major issues of syncing after prolonged periods of signal fading. The issue is caused as follows: the decoder chain processes data no matter what the signal is. This is in order to get rid of noise. However faded signals are not noise. Thus the decoder chain assumes this is a noisy signal which consists basically of 0s. In particular the year decoder will then collect this and decode (the valid result) 00. One a (possibly noisy) kicks in again the year decoder may take more than an our to get rid of the 00 data. If the signal is not available for such a long period of time this prevents the clock from acquiring any lock at all.

The Issue was reported by Uli Fuchs here: http://blog.blinkenlight.net/experiments/dcf77/super-filter/#comment-52182

Is it possible to compile this code on ESP8266?
Can someone suggest what changes do I need to do in order to make it work?
I bought the module and want to make a Wifi clock server in an area where no internet connection is allowed.
Thanks in advance.

Hallo,

was genau sagt monitor_pin aus?
Heißt das nur das irgendwas vom DCF77 Modul kommt oder bedeutet es das das Signal wird empfangen?

Die Meinberg Empfänger haben eine LED für Feldstärke.
Desto heller sie leuchtet, desto höher ist die Feldstärke.
Ist das vergleichbar mit prediction_match?

The current code works properly for AVR based Arduinos because digitalWrite will enable the pullup. This once used to be the proper way but nowadays pinMode can be used to enable the pullups. This is supposed to be the semantically superior approach as it will (hopefully) also work for all non AVR based Arduinos.

~/s/B/0/B/d/examples (master)> grep dcf77_pull_up -r *
DCF77_Scope/DCF77_Scope.ino:const uint8_t dcf77_pull_up = 1;
DCF77_Scope/DCF77_Scope.ino:const uint8_t dcf77_pull_up = 1;
DCF77_Scope/DCF77_Scope.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
MB_Emulator/MB_Emulator.ino:const uint8_t dcf77_pull_up = 1;
MB_Emulator/MB_Emulator.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
Simple_Clock/Simple_Clock.ino:const uint8_t dcf77_pull_up = 1;
Simple_Clock/Simple_Clock.ino:const uint8_t dcf77_pull_up = 1;
Simple_Clock/Simple_Clock.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
Simple_Clock_with_Timezone_Support/Simple_Clock_with_Timezone_Support.ino:const uint8_t dcf77_pull_up = 1;
Simple_Clock_with_Timezone_Support/Simple_Clock_with_Timezone_Support.ino:const uint8_t dcf77_pull_up = 1;
Simple_Clock_with_Timezone_Support/Simple_Clock_with_Timezone_Support.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
Superfilter/Superfilter.ino:const uint8_t dcf77_pull_up = 1;
Superfilter/Superfilter.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
Swiss_Army_Debug_Helper/Swiss_Army_Debug_Helper.ino:const uint8_t dcf77_pull_up = 1;
Swiss_Army_Debug_Helper/Swiss_Army_Debug_Helper.ino:const uint8_t dcf77_pull_up = 1;
Swiss_Army_Debug_Helper/Swiss_Army_Debug_Helper.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
The_Clock/The_Clock.ino:const uint8_t dcf77_pull_up = 1;
The_Clock/The_Clock.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);
Time_Switch/Time_Switch.ino:const uint8_t dcf77_pull_up = 1;
Time_Switch/Time_Switch.ino: digitalWrite(dcf77_sample_pin, dcf77_pull_up);

--> Modify the examples accordingly.

It seems to me that lines 2118 - 2120 in dcf77.h are redundant as function BCD::bcd_t DCF77_Encoder::get_bcd_weekday() (line 800 dcf77.cpp) has already adjusted weekday.val.
But I am be missing something and anyway it is without consequences.

Two examples fail to compile for library version 3.1.4.
This bug was reported by Emmanuel A. Neonakis on my blog: https://blog.blinkenlight.net/2015/10/01/improving-quality/#comment-56039. I will fix it.

I noticed that the Local_Clock is not initialized, its setup method (dcf77.h line 1323) is never being executed.
Is there a reason for that?

Whilst investigating poor lock performance of the MSF implementation I can see that the binning does not behave exactly as expected.

Consider the decoding of minutes (although it does not matter which measure is being considered)...
an incorrect value should be replaced with a correct value after a period of time so consider...

receiving 11001001 five times... this is a representation of 13 with a paritiy bit and subsequently receiving the value 00101000 ten times which is the representation of 14 with parity. After ten good receptions the good value should have replaced the bad value but this behaviour is not seen with BCD binning

Joachim Grimm reported, that void adjust(...) fails to recompute the weekday. The issue affects the examples simple_clock_with_timezone_support as well as the swiss_army_debug_helper.

Hello,

I'm running the library on an ARM STM32F103C8T6 and this works very well, but now I've noticed a strange behaviour.

After power-on the first received time if (clock_state >= Clock::free) is always valid and accurate but after some hours (or days) the time starts to drift away and sometimes also the date is wrong allthough the inaccuracy should be below 200 ms according to the comment in dcf77.h. This seems to happen especially in a quite noisy environment.

I assume this problem is related to: #27

Because I use this library to synchronize my ARM built-in realtime-clock I need a reliable time only once in a while. So my idea is to reset the library everytime a valid time is received (clock_state >= Clock::free).
My C++ knowledge is quite limited but I've managed to add a reset-function which calls DCF77_Clock::setup() and DCF77_Local_Clock::setup() and I call this reset-function everytime a valid time is received.

I'm currently running a test for about 24h and this seems to work well.

Do you think this is the right approach for my problem and is the reset-function correctly implemented ?

Thanks and best regards,
lakeroe

Hi Udo/Gavin,

I have been testing the MSF60 code in the development branch and find that it can take several days to lock on to an MSF signal. I initially tested the signal using DCF Scope and found that the MSF signal I receive is almost perfect. However, when testing MSF60 using the Simple Clock code (with dcf77_inverted_samples=0) I find that the clock can take several days to lock onto the MSF signal and then decodes the wrong time.

Regards,
Aido

Results at first: Udos DCF77-library works as expected. If not, have a look on your hardware.

Hello Udo, you remember that I have a little trouble working with your DCF77-library (based on your 'Simple_Clock with Timezone support'). So I see in my project, with very bad DCF77-signals on a 'MiniPro with 16 MHz-crystal', wrong dates and times (e.g. 09:xx:yy -> 03:xx:yy or Di., 08.10.2002 and Sa., 15.08.2054). And I ask me, what goes wrong?

So I added a little status-information to my OLED-display to see the filter-quality-state. And I saw, after the first 'synced', at best 'locked' only; sometimes after some minutes or, in better cases, after some hours.

Stripping down my project to minimize using other libraries and save ram space and variables doesn't solve the problem.
So I took a second, absolute identical, crystal-based MiniPro, loading your 'Simple_Clock with Timezone support', add some digitalwrites and a LED to see the status 'unlocked' and lower, 'locked' and 'synced' and connected the DCF-input to the same DCF77-receiver parallel.
To my surprise ;) - I see 'synced' on this second MiniPro and parallel 'locked' only on the first used MiniPro.

To verify this result, I transposed the two MiniPro's against each other and loaded my whole project to the second MiniPro.
The result is now, that the (second) MiniPro with my project is over days in 'synced' mode; the first MiniPro parallel with your Clock example and the Status-LED is, at the same time, in 'locked'-mode only.
In result I have a good MiniPro and a bad MiniPro. Unfortunately I don't know, if the good one (2nd MiniPro) or the bad one (1st MiniPro) is the normal; I can't find differences.

Summary: Your DCF77-library works fine. Thank you.

According to library.properties "arm" is a supported architecture. Although the library supports the Arduino Due the label is wrong. The proper label is "sam".

I really like the effort you are putting into this library. The results look amazing and it seems that you are the only game in town when it comes to filtering DCF77 data in a sophisticated way. However, I think the "packaging" of the library might be improved in several ways, to make the library more attractive:

• First of all the source should be split into a couple modules. Right now everything resides in a single file, which is somewhat of 3000+ lines of code. Splitting it into several modules would make it more easy to get an overview and maintain the code.
• Although there are quite a few comments describing specific steps, personally I miss more general comments describing the functions itself. I think Doxygen might be a great option for this.
• Make the library more generic: I don't see any Arduino specific stuff within the source code, so I don't see a reason why the README is referring to this as an Arduino library. In my book it should be usable for pretty much any AVR. Maybe it could be made even more generic with some additional options, so that other devices (PICs, STM32, etc) could benefit from this, too.
• Makefile support: Right now you need to compile the library by hand, or import it into your IDE. It might be a good idea to ship along a Makefile.

The Link in dcf77.h

https://gcc.gnu.org/onlinedocs/cpp/Stringification.html

has changed to

https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html

...Rolf

I found that the repository name dcf77_library somehow sucks as anybody else names their libraries just dcf77. This I renamed the repository today.

To avoid confusion I suggest that contributors to my library change their remote settings as indicated below.

Check if the URL is old or new:
git config --get remote.origin.url

Set new URL:
git remote set-url origin https://github.com/udoklein/dcf77

In dcf77.h lines 2232 -2239 you define structure DCF77_Encoder now; and partly initialize it, then in line 2240 you call now.debug(); which also uses the uninitialized members uses_summertime, leap_second_scheduled and timezone_change_scheduled producing misleading output. I think the following three lines should be inserted after line 2239:

now.uses_summertime=Flag_Decoder.get_uses_summertime();
now.leap_second_scheduled=Flag_Decoder.get_leap_second_scheduled();
now.timezone_change_scheduled=Flag_Decoder.get_timezone_change_scheduled();

In the switch (DCF77_Clock::get_clock_state()) { statements on lines 780 and 806 case Clock::unlocked: Serial.println(F("unlocked")); break; is missing.

Hi Udo!
Do we need to convert time to wintertime if uses_summertime is false?
Does DCF77 send CET time durring summer and CEST time durring winter?
It is unclear for me.

Some parts of the library will print the timezone as MEZ / MESZ, others as CET / CEST.

E.g. dcf77.cpp implements sprint(F(" MESZ ")); but later it implements sprint(F(" CEST "));

A typo in the project title, it is resilient not resilent.

Hi, In my dcf77 alarm clock scetch I use the following code:
void sound_Alarm() {
tone(ALARM, 2000);
delay(50);
noTone(ALARM);
if (digitalRead(panic_Pin)) alarm = LOW;
delay(50);
}

The tone command though seems incompatible with the dcf77 library. I get this when I compile.Any idea. Thanks for your great work.

C:\Users\MARKUS~1\AppData\Local\Temp\build1c605204d1f6abd64fba3c74d60f8a93.tmp/core\core.a(Tone.cpp.o): In function `__vector_7':

C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Tone.cpp:539: multiple definition of `__vector_7'

C:\Users\MARKUS~1\AppData\Local\Temp\build1c605204d1f6abd64fba3c74d60f8a93.tmp\libraries\dcf77\dcf77.cpp.o:C:\Users\Markus Rohner\Documents\Arduino\libraries\dcf77/dcf77.cpp:2474: first defined here

collect2.exe: error: ld returned 1 exit status

Using library dcf77 in folder: C:\Users\Markus Rohner\Documents\Arduino\libraries\dcf77 (legacy)
Using library Adafruit_NeoPixel in folder: C:\Users\Markus Rohner\Documents\Arduino\libraries\Adafruit_NeoPixel (legacy)
Using library SimpleTimer in folder: C:\Users\Markus Rohner\Documents\Arduino\libraries\SimpleTimer (legacy)
Using library EEPROM at version 2.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\EEPROM
exit status 1
Error compiling.

Hello,
I would like to thank you for your work on DCF77 libraries. They work brilliantly! I have replaced resonator on my Arduino Uno board with an oscillator, tweaked yours examples and it is working perfectly.

In my hobby project I am trying to make a VFD clock. There would be additional features like showing temperature and humidity. To that I am using DHT22 sensor based on one-wire communication.

From what I have noticed, after starting DCF77 decoding process, delay() function (and more timebase) change it's actual execution time.
I was trying to use this library https://github.com/niesteszeck/idDHTLib and other one which can be found inside Adruino IDE.

Could you guide me a little into the solution? I think I have tried anything, but I cannot overcome time based problems :/

Best regards and thank you for your time,
Avien169

DCF77_Scope.ino (bug)

The variable declared here:

boolean samples_pending = false;

is set in an ISR and used in the loop().
It should be declared additionally as volatile.

I discovered this while debugging the sketch on an ATtiny1614. I'm guessing, that in this case, the compiler has done some aggressive optimisation and kept the value in a register in the loop() code so it always behaves as if the value is false.

I'm attempting to run the library on an STM32 "black pill". I see #defines in the code, and a couple of closed issues here, indicating at least one other person has made this work. There are two issues:

1. The Arduino IDE places the dcf77_xtal examples under an INCOMPATIBLE submenu, indicating the "Generic STM32F103C series" board's architecture isn't supported. I think fixing this is just a matter of adding "arm" to the architectures list in library.properties?

2. In any case when I select one of the examples (like DCF77_Scope) and change the pin assignments for my board, it compiles and uploads fine but doesn't run. I don't get any output in the serial monitor and the LED doesn't flash. I've made both of those things work independently with other sketches uploaded by the same method so I'm pretty sure the board itself works fine.

Any idea what I could try to debug this?

Hi Udo,

I am considering using you most excellent DCF77 library as a basis for an MSF library.

However, there are a few differences between the DCF77 and MSF protocols.

DCF77

• The last second of the minute is always a 1000 ms low period. This is also known as 'the sync mark'.
• The other 59 (or, exceptionally, 60 or 58) seconds of the minute always begin with at least 100 ms high period, followed by a single data bit of 100 ms, and end with at least 800 ms low period.
  • Data bit is transmitted from 100 to 200 ms after the second
• If each second is considered as ten 100 ms pieces, the minute marker is transmitted as 0000000000, while all other seconds are transmitted as 1D00000000.

MSF

• The first second of the minute begins with a 500 ms low period, to serve as a minute marker.
• The other 59 (or, exceptionally, 60 or 58) seconds of the minute always begin with at least 100 ms low period, followed by two data bits of 100 ms each, and end with at least 700 ms high period.
  • Data bit A is transmitted from 100 to 200 ms after the second
  • Data bit B is transmitted from 200 to 300 ms after the second
• If each second is considered as ten 100 ms pieces of negative polarity bit signalling, the minute marker is transmitted as 1111100000, while all other seconds are transmitted as 1AB0000000.

https://en.wikipedia.org/wiki/Time_from_NPL#Protocol

Do you think these differences make your DCF77 library impractical to use as the basis of an MSF library?

Thanks in advance for your response.

Hi,
I have a little problem with the Libraries v.3.0.0 and before on my Arduino Nanos (IDE 1.6.11). ;-)

E.g. "Simple_Clock" will not synchronize; so I see "Initializing..." and a lot of '.' only.

Because my Nanos with Conrad-DCF77-receiver are working (https://arduino-hannover.de/2012/06/14/dcf77-empfanger-mit-arduino-betreiben/) with synchronization normally within 2 - 3 minutes), ...

Looking at the output from "DCF77_Scope", I think, I found the reason: the output drifts to the right side within 1.000 seconds round about 340 ms.

    1, +---------+---------+---------+---------+---------+---------+---------+---------+---------+---------
    2, +---------+---------+---------+---------+----9XXXXXXXXXXX---+---------+---------+---------+---------
    3, +---------+---------+---------+---------+----9XXXXXXXXXXXXXXXXXXXXX9--+---------+---------+---------
    4, +---------+---------+---------+---------+----7XXXXXXXXXXXXXXXXXXXXX3--+---------+---------+---------
    5, +---------+---------+---------+---------+----9XXXXXXXXXXXX--+---------+---------+---------+---------

  995, +---------+---------+---------+---------+---------+---------+---------+--------7XXXXXXXXXXXXXXXXXXXX
  996, XX--------+---------+---------+---------+---------+---------+---------+--------3XXXXXXXXXXXX5-------
  997, +---------+---------+---------+---------+---------+---------+---------+--------2XXXXXXXXXXXX6-------
  998, +---------+---------+---------+---------+---------+---------+---------+--------3XXXXXXXXXXXXXXXXXXXX
  999, X8--------+---------+---------+---------+---------+---------+---------+--------2XXXXXXXXXXXXXXXXXXXX
 1000, XX3-------+---------+---------+---------+---------+---------+---------+--------2XXXXXXXXXXX8-------- 

This result I get with my best Nano (with the lowest drift)! (I have 3 Nanos from 2 different manufacturers tested.)

Is my suggestion correct that the 'no-synchronize'-problem is based on this drift?

Can you say, how high is, based on your filter-algorithm, the maximum drift per unit of time / or the max. tolerable divergences of the 16-MHz oscillator in Hz or in ppm?
Are they any variables available to solve the problem in software?

Thank you for help.

Best regards, Joachim.