AVR-Chat

I've not actually implemented any of them in any of my projects, but there
are several interesting clock synchronization protocols that have been
designed specifically for CAN.  A google search for "Controller Area
Network Clock Synchronization" will land upon quite a number of papers that
could give some ideas.  Because of CANs particular error handling system (
resend, etc. ), it really requires a different protocol ( at least packet
structure ) than the standard network time protocols.  But, it's been a
while since I've looked into the specifics.  Long and short of it is -
synchronization down to roughly one bit time is possible.  One second
synchronization should be a walk in the park.

Martin Jay McKee

On Wed, Mar 20, 2013 at 9:34 PM, Dave McLaughlin <
dave_mclaughlin@nerdshack.com> wrote:

> **
>
>
> 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]
>
>  
>


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