Morning all! I am looking at using the dcf77_xtal library by udoklein for an application where it will provide a time source to synchronise a pendulum clock. The clock used to sync itself to a telegraph time pulse but that has been unavailable for decades, and the mechanism that adjusted the pendulum rate is now not functioning. The actual time is displayed on an electromechanical slave clock stepping every 30s, from a counter implemented on an Arduino Due. We have provided a GPS time source that has a DCF77-format current loop output and I wish to decode this to provide accurate time in the Arduino. The Arduino will also handle counting the pendulum swings and driving the dial, inserting or deleting occasional corrections of an integral number of seconds.
My question relates to the internal working of the library. I plan to monitor the pendulum sensor input by digital reads and reacting to negative edges by triggering actions to supply an impulse to the pendulum and increment the counter, as well as comparing "pendulum time" with dcf time.
Are there potential interactions between my code and the library that I need to be aware of? For example, I will not use any delay() statements that would block the processor, but are there other issues?
I intend to use the millis() function in my code - can I assume that the dcf library does not interfere with this?
The "official" DCF77 signal format uses the first 16 bits for civil warnings, but the GPS time source uses them for other purposes which are irrelevant to my application. It does provide Z1 and Z2. Can I assume that the library code also ignores the first 16 bits?
I'm sure there are other things I should have asked! Help on the above would be much appreciated.
It sounds an interesting project keeping a mechanical clock synchronised to an external time source.
Is it so that your primary time source will still be GPS and, from that GPS source, you will generate a DCF77 like radio signal (some how) ? If so, you have to at least generate correctly all the time relevant parts of the signal including check digits etc. If you haven't already got one, there is an example of such a generator here: DCF77 Generator | Blinkenlight . I believe you can ignore the parts of the data stream which are not relevant to time/date/timezone but you can easily test this. If you are doing it like this, maybe also explain why you are using a combination of GPS and DCF77 and not one or the other.
The DCF77 library (in conjunction with a DCF77 receiver module) effectively keeps an internal oscillator trimmed (the mechanism is slightly different between the AVR e.g. Uno boards and the ARM boards e.g. Due) but anyway you may be able to derive synchronisation pulses from that or, if you simply need one pulse on the change of each second, derive the pulse from the time presentation.
There is a "discussion forum" for the DCF77 library here: Discussions · udoklein/dcf77 · GitHub . You may be able to attract the authors's attention by posting something there.
Thanks for the pointer to the discussion forum! It seems to be very quiet but I can start the ball rolling there!
The DCF77 signal comes from a GPS device (Mobatime GHSS4500) mounted on the building with a clear view of the sky, which is designed to drive a long cable with a current loop interface to a range of master clocks that also need a DCF signal. Where the clock is located is deep in the building and VLF time signals are very unreliable. Hence the use of a separate off the shelf time source.
Ultimately we want the clock to be able to set itself to the correct time and maintain it with no human intervention so we do need the complete time signal. On the other hand the dial has no seconds hand so absolute precision is not needed.
That is clear enough. Maybe just start by acquiring a DCF77 receiver module then install the DCF77 library on your Arduino (Due?) and get that working. Hopefully there will be no conflict between the "real" DCF77 transmissions and the local "DCF77-like" transmissions from your Mobatime device.
Once you have got that far, you can then start to work out how to generate the pulses that the synchronised clocks need. A once every 30 seconds pulse is easy enough to generate but how are daylight saving time changes handled ?
Just to be clear, the Mobatime generates DCF-like logic pulses, not an RF signal, no need for an additional module just a suitable current-loop interface. Which can be a resistor!
I could only find "sales" information for the Mobatime so this part is still not clear to me.
If that Mobatime GHSS4500 device is compatible with normal (unmodified) DCF77 clocks, then the signal must, as far as I can see, modulate a carrier of 77.5kHz. That would appear then to require a demodulator of some sort before the signal was suitable for processing by a DCF77 library. Maybe a software demodulator running on the same board infront of the DCF77 library could work to condition the signal because 77.5kHz is really quite slow.
If however, the Mobatime delivers timed DC pulses, say 3.3 volts (one pulse per second in a 60 second cycle, the width of which indicates either a '0' or a '1' exactly as the demodulated DCF77 signal ) then that could be directly compatible with an Arduino library.
They are not normal clocks - transmitting a local 77.5 kHz signal would be illegal as the frequency is dedicated for standard time transmissions. The GNSS4500 has a current loop output to drive long cables.
OK. If the output is then similar to the demodulated output from a DCF77 module, you can use this tool to examine it without the need to install a full library: DCF77 Scope | Blinkenlight . Ensure that your Arduino can tolerate the signal voltage and maybe use a capacitor for DC isolation.
OK. Then just use the simple "scope" software (referenced in post #8) to give you a visual indication of the received data. If that shows that in each second a reasonable "0" or "1" is delivered, then you should be able to use the full DCF77 library to interpret the data. You'll also get an indication of whether your hardware is appropriate for the library because factors like crystal frequency drift are made visible.
Returning to the original question.... From the discussion it is clear that nobody can answer your three main questions directly, although everyone has been offering helpful suggestions. Presumably nobody here has actually used the library.
I suggest you just go ahead and try it. Build a very simple application first, and experiment by changing it, adding new functionality, and so on. Also, I bet the author of the library will respond to direct questions and advise you on things to avoid, or the best way to do things.
The DCF77 signal has an extremely low data rate, so in theory it shouldn't be particularly demanding of the processor. The author's efforts to build in noise resilience may increase the processor load and timing requirements, but we can't really know that without trying it.
So, go ahead and give it a go. See how you get on, ask questions of the author or his discussion forum. It would be great if you could report back on progress and success/failure, as it will be very helpful for fellow travellers in the future.
Thanks for the suggestion Steve. Actually since I have a very clean DCF77 logic signal Udo advised that his library is drastic overkill and so I'm using the Thijs one instead. Making some progress...