AVR-Chat

Hi Chuck,

 

Why not just have one device that is the master clock send the time
periodically over the CAN bus. Because CAN is multi-master and if you use a
high priority ID, all the devices will receive at the same time and they
will then update their internal clocks to match this one.

 

This is what I did years ago with a home automation system and currently
looking to do with a design I am working on just now.

 

You would only need to send this time sync every so often. Of course, this
all depends on how much drift each clock is currently showing but if you are
using a real time clock IC on each board, they are pretty good at holding
time. Even down to just 1 or 2 times a day at the most would be enough times
to sync them

 

Dave.

 

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
Sent: 21 March 2013 04:58
To: AVR-Chat
Subject: [AVR-Chat] Keeping time accross multiple boards

 

  

In my application I have many (>20) ATMega1284p based controller boards
connected by a long (over 2,000') CAN data bus.

Up until now I have not needed to coordinate time across the boards but I am
now implementing logic where I need that ability.

I think my needs are served if I can coordinate the clocks to within a
second of each other.

I was thinking of having a controller (picked by an algorithm) periodically
(interval set by drift results I see in the field) send a time message which
all other controllers would (should) receive.

Upon receiving the time message the controller would compare it to its
internal clock. If its time is less than the received time I would have it
send its time out on the bus. If its time was greater than or equal to the
received time it would set its internal time equal to the received time and
send no time message on the bus. This would continue until no more time
messages were sent.

In this way all controllers would have their clocks (re)set to match the
controller with the slowest clock. Hopefully this reset would be kept to
sub-second adjustments, if not I would either decrease the adjustment
interval or go a different route ...

I realize that I will have to implement the sending of the bus time messages
to avoid as much latency as possible (avoid all queuing as much as possible
including the CAN controller transmit buffers and assign the highest
possible CAN bus message priority).

I used "slowest time" in an attempt to allow for the inevitable latency that
will occur in message sending (since any latency will tend to make the local
clock seem fast).

Does this sound reasonable? Other approaches?



[Non-text portions of this message have been removed]