Hello.
I would like to make 1 arduino "update" the time on other arduinos.
The reason being is that i only have 1 arduino with an attached RTC, while i have several arduinos.
I was thinking something like a command send on the serial line (all arduinos are connected through wireless serial like Xbee)
Is that possible, and if so, how would i go about it ?
Sincerely
Raphael /// Skunky
Is that possible
Yes.
how would i go about it ?
Seems to me you have that figured out. Send each Arduino the time, from the one that knows the time. Have the other Arduinos parse the time string, and set the time appropriately.
Without a RTC, how do the other Arduinos keep the time?
Without a RTC, how do the other Arduinos keep the time?
Tick-tock. They have crystals. There is no problem tracking when millis() changes, and updating time accordingly.
It's not all that accurate. Hence the need for periodic synchronization.
@PaulS
Thanks for the help.
Could you point me to an example which shows how to use/parse the time strings ?
I bet this is rather simple, i just can't see the solution -.-
Snippet from the set time DS1307:
uint8_t seconds = 00; // Initialization time
uint8_t minutes = 51;
uint8_t hours = 10;
uint8_t week = 50;
uint8_t days = 16;
uint8_t months = 12;
uint16_t Year = 12;
Essentially, from the UNO that has the DS1307 (etc.) attached, send the other UNOs the variables over some communication path. They are all numeric, so you could just send them as ASCII values and convert after receiving.
Remember to design the sketches on your 'slave' Arduinos to support the type of date/time adjustments that your clock sync mechanism will perform. For example, making step adjustments (just setting the clock to the correct time) is easiest to implement but means your sketch must deal with time making arbitrary jumps backwards and forwards. Skew adjustments are easier for the sketch to deal with but harder to implement. The sketch would need to be coded to work correctly too (you can no longer assume that the difference between two wallclock times is the same as the difference between two readings of millis()).
you can no longer assume that the difference between two wallclock times is the same as the difference between two readings of millis()).
An absolutely critical statement and "on steroids" IF logging to an SD card is implemented... Downstream analysis of the logs rarely are written to permit timestamp discrepancies... That is, out-of-order sequencing.
Ray
Another way to sync is to provide a pulse from the master clock every (milli)second which is received by the slaves in an interrupt.
Furthermore, it might be easier/faster to send the time as a binary number (seconds since 2000) as that would take less time to communicate and the receiving slave can decode that quite fast.
You might want to consider if you need to handle daylight saving time. If you do then once a year you will have a gap of an hour, and once a year an hour will happen twice. Much better to avoid daylight saving if you can.
I love Unix timestamps. Internally, all you deal with is the number of seconds since the Epoch in GMT and no mucking about with timezones or DST. All you have to keep track of is one simple unsigned long rather than a messy array of year, month, day, hour, minute, second. This means that doing things like calculating differences or offsets is stupid simple arithmetic. For example, want something to happen 24 hours from now? = epoch + (60 * 60 * 24).
Then you just have a couple little functions to convert to/from Gregorian strictly for human interface.
tylernt:
I love Unix timestamps. Internally, all you deal with is the number of seconds since the Epoch in GMT and no mucking about with timezones or DST. All you have to keep track of is one simple unsigned long rather than a messy array of year, month, day, hour, minute, second. This means that doing things like calculating differences or offsets is stupid simple arithmetic. For example, want something to happen 24 hours from now? = epoch + (60 * 60 * 24).
Though potentially you would have a problem with things like leap seconds.
Also, multi-core implementations can have problems since the internal clock each core keeps may not be synchronized across all of the cores in the chip, let alone multiple chips that together constitute the computer.
tylernt:
I love Unix timestamps.
That's a common representation of a wallclock time, and there are plenty of other similar formats that have the same characteristics. However you represent it, you still have to deal with the fact that wallclock time is not the same as real time and can speed up, slow down, jump backwards and forwards.