DCF77 library for Arduino - synchronize with atomic clock

Hi,

Thanks for the suggestion! Indeed, the Conrad receiver really is not all that stable. But then again, many receivers seem to have that problem.
Nevertheless, my Conrad receiver has not given me that many false flanks during a pulse, so I never saw the need to implement this kind of rejection.

It seems like a good idea, though! I've added it to the library, together with some minor fixes. It can still be downloaded here:
http://thijs.elenbaas.net/downloads/?did=1

Let me know what if it works for you!

Ps. I'm part of the other 50%: I'm building a Word-Clock instead of a Nixie Clock. :slight_smile:

I can change the pin and therefore the interrupt?
because I would use 2 pins for other purposes and to "read" the signal DCF77 use pin 18 with interrupt 5.
but I think it does not work.
I have to change something?

thanks

P.S. I use arduino mega 2560

Yes, you can initialize the library with any pin and interrupt number. You need to use one of the latest versions, there used to be a bug in this part of the code. According to this page, you can use the following pin/interrupt combinations on the Arduino Mega:

Pin 2 - interrupt 0
Pin 3 - interrupt 1
Pin 18 - interrupt 5
Pin 19 - interrupt 4
Pin 20 - interrupt 3
Pin 21 - interrupt 2

When using, for example, pin 18, you can start your code with

#define DCF_PIN 18	         // Connection pin to DCF 77 device
#define DCF_INTERRUPT 5		 // Interrupt number associated with pin

DCF77 DCF = DCF77(DCF_PIN,DCF_INTERRUPT);

I'm using the DCF-2 module from ELV, and the DCF77 library at first did not work for me.
The problem is solved now, but here are the symptoms I had, for others using the same hardware ( http://www.elv.de/dcf-empfangsmodul-dcf-2.html ).

  • The hardware seems to work; the sketch "DCFSignal" shows received data
    in the expected 1000ms intervals.

  • The pulse length seems to be wrong: the "DCFPulseLength" sketch shows that a pulse is not around 100ms and 200ms long, but nearer 800ms or 900ms instead.

  • Since a pulse longer than 180ms is considered "1", the "DCFBinaryStream" sketch shows received "1"s exclusively. The buffer is filled with the "1", and afterwards the parity is wrong.

After much debugging the reason for this behaviour became clear: the ELV "DCF77-2" module (which only has one signal output) delivers an inverted signal.

The following code change solved the problem: DCF77.cpp 0.9.7, line 95:

        int sensorValue = digitalRead(dCF77Pin);

to

        int sensorValue = !digitalRead(dCF77Pin);

(Note the exclamation mark before digitalRead() used to convert each "0" to a "1" and vice versa).

If somebody pointed me to the right direction (mrTee?) I could provide (hopefully) more elegant changes which also fix all warnings that compilation using Arduino 1.0.1 currently cause.

Hi,

That was thorough bug hunting! I had a look at the specs, and I could not find any mention on outputting an inverted signal. I've send you a test version of the library with a small change that should make it able to deal with inverted signals. If it works I will publish it (after my holiday).

Where there any warnings while compiling the library before making changes? I checked, but in Arduino 1.0.1 with verbose logging turned on, I do not see any warnings.

A little later than expected, the library now supports inverted pulses as input.

The constructor now has an optional parameter OnRisingFlank:

DCF77(DCF77Pin, DCFinterrupt, OnRisingFlank)

If OnRisingFlank set to false, the algorithm will trigger on falling edge.

Hi!

I wired a cheap DCF77 receiver from Pollin to an Arduino Uno: DCF 77 Empfangsmodul DCF1 online kaufen | Pollin.de

It works out of the box. No extra components were necessary.

Then I ran the examples bundled with the DCF77 library. It turns out that SyncProvider is one minute ahead at the first sync. InternalClockSync works as expected.

Please find the output of InternalClockSync at Output of InternalClockSync - Pastebin.com

The output of SyncProvider is here: Output of SyncProvider - Pastebin.com
In line 4 of the output of SyncProvider it’s 12:01:00 actually. After the next sync the time is corrected (line 126).

Another output is here: Output of SyncProvider 2 - Pastebin.com

I enabled VERBOSE_DEBUG and recorded a video of the output:
http://dl.dropbox.com/u/87685034/SyncProvider_3_converted.avi

I tried both examples a couple of times. The DCF77 signal is quite clear.

Any idea what’s going wrong?

Best regards
Franz

I implemented a DCF77 clock with an additional exponential filter in order to improve noise tolerance. You can find the experiment here: Binary DCF77 Clock | Blinkenlight. This is actually part of a larger project where I intend to push the noise tolerance quite a lot further: DCF77 Project | Blinkenlight.

I am trying this module to get to work. According the example DCFSignal, the module seems to work, but the pulses seem to be to short so that the library cant interpret it (see attached screenshot). Does anyone have a clue how to fix that issue?

How did you connect this module to your Arduino? This is a 3.3V module with very limited driving capability. In doubt I would say you are overloading the module.

I connected the GND and the Vcc of the module with GND and the 5V-pin of the arduino. I tried connecting the signal pin with D2 of the arduino with and without a 10k pull up resistor. With the resistor, the signal on D2 stays at hi. Without the resistor the signal shows the behaviour seen in my attachment. The modules datasheet clearly states a supply voltage range from 1.2 V to 5 V, so there should be no overloading. The datasheet also states a maximum ripple of 10 mVeff. Maybe thats the problem. Does anyone know the ripple of the 5V supply voltage while arduino is connected to my PCs USB-port?

The datasheet says maximum current 5uA. With a 10k pullup you draw 500uA. You are overloading it. You should try a 1M resistor.

Actually the datasheets states an output current > 5µA, but i will try a 1M resistor. Maybe it works. It won't hurt anyway :smiley:

Yes, but it also says current consumption <100uA. Obviously the >5uA gives you a hint about the capabilities of the module. If it could drive 500uA they would have written it. This kind of module is designed to go into a clock --> low current consumption is a design goal, extended driving capability is not. --> I would be very suprised if it would be able to drive 500uA. This is the reason why I bought one with additional driver transistors.

The 1M resistor does part of the trick. The signal doesn't stay at high with the 1M resistor connected, but it shows the same signal sequence as without any resistor, so the signal peaks are still much shorter than stated in the spec :frowning:

Maybe you already killed the module. I am using this one: http://www.voelkner.de/products/162756/Dcf-Empfaengerplatine.html

Seems to be the same as this one. Maybe i drop by at the big blue C tomorrow to get it.

Conrad and Völkner are different brands of the same company. They just address different market segments. See here: Conrad Electronic – Wikipedia

Didn't know that. Anyway the price is the same.

mrTee:
A little later than expected, the library now supports inverted pulses as input.

The constructor now has an optional parameter OnRisingFlank:

DCF77(DCF77Pin, DCFinterrupt, OnRisingFlank)

If OnRisingFlank set to false, the algorithm will trigger on falling edge.

Hello,

I think I have the same problem with the inverted signal, thank you for your hint.

But I don't know where in the code I put "false" in and which Version of the code did you use?

Thank you for help.

Kind Regards
Enam