AVR-Chat

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?

On Mar 20, 2013, at 4:58 PM, Chuck Hackett <egroupscdh@up844.us> wrote:

> 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.

That sounds like an opportunity for a disaster of a packet flood on your net.

Spend some time studying the design and protocol for ntp. You don't seem to need anything as complex or precise but ntp can sync to better than 20 ms on non-realtime systems over nondeterministic network, world wide.

timed is another Unix utility predating ntpd. Has a smaller computational footprint. Works very well on systems the size you describe.
http://osr507doc.sco.com/en/NetAdminG/tspC.how.html

A scanned document from 1985: http://www.eecs.berkeley.edu/Pubs/TechRpts/1985/CSD-85-250.pdf

Modern timed source code:
http://svnweb.freebsd.org/base/head/usr.sbin/timed/timed/

--
David Kelly N4HHE, dkelly@HiWAAY.net
============================================================
Whom computers would destroy, they must first drive mad.



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

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]

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]