Sync multiple ds3231

Hi, is it possible to sync multiple (x2) ds3231 so the times are exact?
I have 2 aquariums with identical pcb's and sketches that control the lighting on/off/fading times using a nano. Atm im wild syncing them so the lights behave the same but there is always a difference, annoying. Ive searched around online and havent had much luck.
Any Ideas?

You'd anyway have to connect the two circuits with either a wired connection or a radio connection to synchronise them. If you have a wireless LAN the easiest would be to synchronise with an NTP server using an ESP32 (or similar). Obtaining the time with an ESP32 is only a few lines of code. Keep the DS3231 as a backup and update it regularly.

1 Like

See what @6v6gt suggested above; this would be the easiest solution if you want to keep both aquarium systems separated. Alternatively, especially if you envision expanding this setup, it could make sense to somehow link them together. You could either do this physically with a wired connection (UART or CANBUS, for instance) or with an RF connection (using NRF24 modules, or something like ESPNOW, or even WiFi+TCP or HTTP). Make one device the master and have it control the timings of the other 'subject' device, so that the subject switches whenever the master tells it to. You could also use the master only as a time source for the subject(s), although in that case I'd fall back on NTP sync over WiFi instead.

hmmm. So im guessing its not a simple as connecting both i2c and allocating addresses then setting time. bugger.

No, you'd create the situation where you would have two master devices on the I2C bus. The bus isn't designed to do that. To 'hijack' the RTC connected to another Arduino you would have to engage in a fairly complex dance that first alerts the 'subject' Arduino that the RTC will become unavailable (any I2C transactions would need to be finished properly), then the I2C lines would have to be disconnected from the subject Arduino and connected to the master Arduino, then the master Arduino can set the time on the subject's RTC module, and then the module could be reconnected back to the subject Arduino, and the latter being signaled that the RTC can be reconnected. This would also require hot-swappable I2C which is not necessarily possible on all platforms. There's also the risk of the whole procedure affecting other devices on the same two I2C buses (displays etc.)

So it might seem like a simple way to do it, but in reality, it's kind of complex and any of the options suggested earlier would be much simpler.

I understand that it is feasible to create a hardware/wired connection between both systems. I'd suggest to simply ditch one of both Arduinos and have the remaining one control both aquariums. Much simpler, always in sync.

Problem with that idea is that DS3231 has no choice of addresses on the i2c bus, so you can't connect more than one on a bus at the same time.

If you use an i2c multiplexer, you could do it, but that seems overkill just to synchronise 2 RTC. You would connect the 2x RTC to different channels of the multiplexer and connect the multiplexer to a single Arduino. Then write a sketch to set the same time on both RTC.

Even if you did that, the 2x RTC would eventually get out of sync. Genuine DS3231 will drift apart by several minutes over a year. Clone ones probably worse.

And even then, you'd still not have two Arduinos each using their own RTC. Which is what the question originally was, if I'm not mistaken.

hmmmm, hard wired isnt an option i like. I have a bypass switch so the led bars can be turned on outside the timers. Not to mention the thought of running an o/p to the second aquarium sounds ugly. Guess ill just stick to wild syncing.
I appreciate everyones input. legends as always.
Rob.

The DS3231 has an Aging register that lets you fine-tune the timekeeping. With the right value selected, the RTC can stay within a few seconds a year. If all of your RTCs were calibrated that way, you would probably still have to sync them manually, but far less often.

I have a Github repo with an Arduino sketch that makes the adjustment. It requires a GPS module that provides a PPS signal, which is extremely accurate.

https://github.com/gbhug5a/DS3231-Aging-GPS

The question was

It didn't specify that the 2x RTC must be connected to 2x Arduino at the moment they are synchronised. As long as each RTC remains connected to its own button cell, they will retain the time while they are disconnected from the single Arduino with the i2c multiplexer and connected to the 2x separate Arduino.

1 Like

... or ...

Use the SoftWire library to make a second i2c port on an Arduino. Connect one RTC to that and the other to the hardware i2c port. Then run a sketch to set the same time on both RTC. Finally, connect each RTC to its own Arduino.

1 Like

....or ...optical:

Use IR emitter on one Nano and IR receiver on the second. The second Nano would not even need an RTC. Every minute, the Nano with the RTC could transmit the time to the second Nano over IR.

Plug all the lights into 1 lead......

That's correct. But given the choice to solve the literal question asked regardless if it's relevant, or focusing on the likely situation OP is dealing with, I generally opt for the latter.

OK, but how does that relate to your earlier idea of using I2C? That's a wired connection, too.

In a microcontroller system, you generally have that switch signal the microcontroller so it overrides its program. Which is the 'right' way to do it anyway, because it enables the microcontroller to pick the program back up when/if you forget to put the manual override back after some time.

Depends on the physical setup I suppose, but again, if running wires for I2C was an option, I would assume that running wires for lights, pumps etc. would also be feasible.

Anyway, if you don't want to wire things up (understandably, too), I'd stick with the earlier recommendation to do a wireless sync between both systems as outlined in #2 and #3.

Duh ??

I2C is designed to support multi-master. I have no idea how well it works in general and how well the Arduino implementation of the protocol will handle it.

I stand corrected. Indeed, how well it works, remains to be seen. But maybe this would have been an option if a wired connection would have been feasible. I understand from OP's additional description it's not desirable, and likely would involve wire lengths that exceed what's wise for I2C anyway.

I've posted a relatively detailed explanation of my method of synchronizing the clocks on multiple stand alone RTC's with a Neo6M GPS and an UNO. We needed this for mult-sensor clusters in caves:

With that UNO test rig, SN's can usually be set within 50 microseconds of the GPS pulse, but the -M chips usually set about 1 millisecond before to the time-sync pulse. I have not yet figured out where that negative offset comes from. But some of the RTC's have significant drift rates if you leave the age register set at the default and you can visually detect this within a couple of days based on the timing of LED blinks. So there is not much point in synchronizing that precisely unless you also run ShermanP's Age Register test to get the default drift rate under control. With both precise time-sync and a well adjusted Aging offset, you should be able to get less than a millisecond of drift per day indoors.

Also worth mentioning that HeyPete had no trouble setting a breadboard full of these RTCs via the same I2C bus transaction, or you could try an I2C multiplexer like the TCA9548.

I don't see any sense in all those posts, except for the first answer from @6v6gt.

Replace the Nanos with ESP32 boards, and sync with NTP.
An ESP32 could drift 50ms per hour (default hourly NTP update), which you likely can't see.
Re-sync just before the dimming sequence if you think you need millisecond accuracy.
Leo..

Ah!!!! It's Ed Mallon, whose most excellent Cave Pearl Project was my intital exposure to the DS3231, and in particular the fact that it's a power hog when running on Vcc (as opposed to running on Vbat). Well, I see that you've made use of my Aging register optimization method. I'm pleased to see that.

You've lost me. What is this about?

In my sync code, the difference between the RTC and the GPS pulses is shown as a simple subtraction of Tclock - Tgps. If the RTC SQW ends after the GPS the number is positive, but if the RTC square wave ends before the GPS pulse the number is negative. On SN chips the number is a very small positive but on the -M chips the number ends up being about 1msec negative. For that to happen the first square wave out of the RTC after time sync must be slightly short, and I have no idea why that is.

And thank you very much for sharing your age register utility SP. There are now far more -M chips floating around and they really are not that useable without this kind of tweaking. On the Uno rig I can just let that chug away in the background.

To Wawa: Network access is not available at most research field sites on anything like a reasonable battery operated power budget. Heck, the utility electric goes out once a week in many parts of the world. And even when you do have network access I suspect there are a lot of extra hoops to jump through before an NTP sync actually delivers microsecond level accuracy. This is why takes several days to do an RTC drift test using NTP, while it can be done in as little as 30 minutes with a GPS.