Real time clock for keeping accurate timing between two arduinos

I'm making some very sophisticated stopwatch for racing and I need two arduinos to maintain precisely the same time. By word precise I mean less than about 20 milliseconds per 24h.
I've searched for some real time clocks compatible with arduino, and can't find accuracy of those cheap modules based on DS1307. What is more, they give resolution of only 1Hz, but I think I can overcome this by updating arduinos clock every second with value from RTC.

Maybe someone has checked what is the accuracy of those modules or could advice on some other not very expensive solutions?

In my opinion, you're only going to get that level of accuracy by synchronizing with a GPS every hour or so, maybe more often than that. You can easily obtain measurements to the microsecond.

I can synchronize even every few seconds, thats not a problem. It just has to be precise :slight_smile:

Use a radio transmitter so the two Arduinos can synchronize to each other...?

If I did the maths correctly, that's about 200 parts per billion. That's at least 100 times more precise than a DS1307. For design purposes, I'd try to exceed the requirement by an order of magnitude, so 20ppb. Synchronizing hourly wouldn't come close if timing in between syncs is important, as a typical Uno with a ceramic resonator is only good for about ±0.5%; typical crystal oscillators are only 20-30ppm. I'd look at GPS or these surplus Rubidium frequency standards, there's an active thread now where the person used one to build a clock.

I figured it went without saying that using the internal oscillator would be completely out of the question. You would also likely want to clock both micros with the same clock source, perhaps from a TCXO or a rubidium oscillator.

afremont:
I figured it went without saying that using the internal oscillator would be completely out of the question.

Indeed. Guess I was thinking external RTC.

And what about DS3231? It is sayd 2ppm on ebay, for only 6$, looks a lot cheaper than gps, and I think it will consume much less power than gps module.
Rubidium also look like quite an expensive solution...

About radio synchronizing - it should work even if there is quite a long distance between arduinos. I'm using xbees which are told to carry up to 40km over free air, but when I tested it (with some trees between xbees) it lasted for about 1.5km, nothing near 40 :)) By the way, maybe xbee has some clock that is more or less precise?

PS.to Jack Christensen: Oh wait, are you saying I need 0.02ppm (20ppb)? :fearful:

The chronodot thingy is fairly accurate, I believe it's 2ppm. Still not as accurate as the OP wants though. I do think that with GPS syncing on the second ticks, it could meet the OP's requirements. Even though the local crystal would be off, the error would be calculable given that the GPS ticks could be assumed to be perfectly spaced. The micro would then be able to calculate an adjustment multiplier so that microsecond level accuracy of the time could be achieved when the time is read by upper level code. That's my story, and I'm stickin' to it. :wink:

BTW, I've been able to get a PIC within 1ppm by tweaking the caps. Obviously only valid at a constant temperature, but still completely usable by measuring against a digital watch with a known error and assembling in the error adjustment.

When you want to measure things with this level of accuracy, you have to use the Input Capture Facility of Timer1. The hardware takes the timer snapshot with very predictable delay from the time the pin changes value. You can't use things like pin change interrupts to measure pulses with any real accuracy unless you have no other interrupt sources active.

jarik:
PS.to Jack Christensen: Oh wait, are you saying I need 0.02ppm (20ppb)? :fearful:

Yes, 20 parts per billion. :fearful: I know!

20ms = 0.02s
86,400 sec/day

0.02 / 86400 = 231.5 x 10-9

That's the basic requirement, then I'd want to design to exceed that by a fair amount, so I'd probably shoot for 20-40ppb.

Use a servo to press a button on one of these: http://www.ebay.es/itm/230984839208

The arduinos can sync to the signal.

Forget the accuracy requirement for now. What is it that you are timing and how do the two Arduinos accomplish that? Once that's known, then the accuracy requirement can be worked into the solution.

Pete

This would work:

Might want to massage the output into a larger amplitude square-wave by using a comparator.

el_supremo:
Forget the accuracy requirement for now. What is it that you are timing and how do the two Arduinos accomplish that? Once that's known, then the accuracy requirement can be worked into the solution.

Pete

I need to count time of racers. Now the systems works a follows:
Arduino #1 is synchronizes its time over USB or xbee with computer #1. Then it catches every racer that starts race and sends that time to computer #1.
Arduino #2 is synchronizes its time over USB or xbee with computer #2. It catches every racer that passes it on the finish line and sends that time to computer #2.

The system should work with high enough precision at least 8-12hours.

At first I tried to synchronize arduinos with computers only in the morning and then they counted time on their own. But there was a difference in the speed of two arduinos so after few hours time difference drifted a few seconds.
Now I started to synchronize both arduinos after every racer passes gate. I think this should be OK when working via USB connected PC, but when using xbee I believe there can be some differences in how fast communication goes over the air and additional error can appear. What is more even two PCs can have slightly different time, so it would be better to synchronize arduinos with one computer one time before event, so both arduinos would have as close their time values as possible.

PS. Synchronization with computer works as follows:
save millis value 1,
ask for time,
receive time,
save millis value 2
new millis value = received value + ( (millis 2 - millis 1) / 2 )

FWIW, I do time syncs OTA with XBees and it's more than adequate for my low-precision needs (eyeball accuracy) but it does take 25-30 ms for the exchange, and occasionally there is a flier that could be 6-8 times as long. I might have the synchronization algorithm average several round-trips.