Go Down

Topic: Sync multiple arduino-based clocks (Read 3943 times) previous topic - next topic


I am about to embark on what i am sure is to be a slipperly slope of clock building.  I am working on a variation of the word clock, and then will probably make one of the pong clocks, and who knows where it will go from there.  What i would like to do from the getgo is design a means to keep the clocks all in sync with each other.  Suggestions on where to start with a way to at minimum sync them, and preferrably even set them appropriately.  How could you leverage a gps module, or network shield to keep multiple arduino-based clocks in sync?

Clocks will likely be in basement, not sure how well a gps module will work.  Thoughts?

Thanks and regards,



Man with one clock always knows the time, many with two clocks never quite sure.  ;)

Time keeping and high accuracy time standards can be a hobby that can go to absurd measures in costs and efforts, some of them are just outright freaks about the whole subject of frequency standards. I am in awe of what kind of accuracy some can come up with, but there is no room in my retirement life for any need of time measurements shorter then seasonal around here.  ;)



You will need to figure out a way for them to communicate with each other.

After that, you will need to figure out how to synchronize. The easiest would be a master + slaves solution: the slaves call home periodically to set its time to the master's.

Those 2.4g modules will be fairly handy for this. You can for example implement an i2c over those modules, except that in this case, the masters initiate the communications.

Jack Christensen

I use XBees. One node is the base station and also has an Ethernet interface, its clock is synchronized to an NTP server. The other nodes sync their clocks with the base station's. I didn't go through a lot of pains to make it super accurate, but it passes the eyeball test quite well and that's good enough for me, I'm not managing satellites or cell towers.

I have a lower-tech approach for some other devices. Each has an RTC that plugs in as a daughter board but no communication ability. I have an "RTC calibrator" with an XBee that uses the above network to set the RTCs, then I sneaker-net them around the house. Right now they have DS1307s which as many have observed, can drift a bit. The RTC daughter board has the same pin configuration as the Chronodot, so I could use those as well. I've also been playing with MCP79412 RTCs which have a calibration register (as well as other neat features) and they can be trimmed pretty close. Part of what the RTC calibrator does is to store the time the RTC was set in the RTC's SRAM (for DS1307s and MCP79412s), so that at a later time, the drift in PPM can be calculated. Right now I have some MCP79412s that have been running over a month, and they're within a second near as I can tell with my well-calibrated eyeball.


Dec 05, 2012, 02:31 pm Last Edit: Dec 05, 2012, 02:33 pm by snooprob Reason: 1
Thanks for the dialog thus far everyone.  I am not trying to synchronize nuclear launch codes here - if they stay within 30 seconds of each other I will be happy.  Well, honestly that is reason number 1; reason number 2 is most of the clocks examples online are pretty much baked and ready to go.  I wanted to add a little 'something'.

The wireless is very appealing, as the clocks could be in different rooms etc.  Xbee seems to be a bit overkill for the job.  Would something cheaper such as these wireless modules do the trick?
I don't see any need for them to be speedy.  I like Jacks idea of the master with the NPT server access, and it could transmit a clock signal, and everyone else could just recieve.

To that point isn't there a super low frequency clock signal generated in the US that you can receive?  Any insight what it would take to do that?  Thanks, and I am enjoying the dialog.



One low-cost wireless approach would be to use the 433MHz  send/receive modules and the VirtualWire library to send an occasional sync signal.

Available many places, including Sparkfun: https://www.sparkfun.com/products/10534


Jack Christensen

XBees may be overkill for this purpose alone, my clocks are actually part of a sensor network and their main mission is not just telling time. Although I may build a few that do just that.

The NIST runs a station called WWVB that transmits time code on longwave, 60kHz. This is the signal that a lot of the radio-controlled consumer clocks and such use. I've seen receiver modules around, don't remember exactly where ATM.

I just became aware that WWVB recently started broadcasting a new phase modulation time code to improve reception. Their signal is pretty weak on the East coast, and not great here in Michigan, it's usually only usable at night.


@Jack, thanks so much.  The magic word was 'wwvb' which got me a hit on another forum topic.  I am going to go that route i think.




Dec 07, 2012, 02:37 am Last Edit: Dec 07, 2012, 02:48 am by stoopkid Reason: 1
Just a thought: maybe have the master clock always be whichever one was updated most recently? That way you can set any clock and have them all synchronize instead of having to set one in particular each time. Not that that would be a big deal, it would just be cool to be able to set any clock and have them all obey.

Another idea would be to set them all up to receive and use the Ethernet shield to periodically get the correct time and transmit from the web so that you never have to touch anything.

I would imagine there must be some sites out there that provide very simply-to-parse time info, which would be perfect for the Ethernet shield.

NRF24L01 I've never used one of these but they're cheap and send/receive so they might be the answer.

Go Up