A few days back I mentioned the SYNC message mechanism in CANopen, and how it can have about 150 µs jitter when sent out on a CAN bus running at 1 Mbit/s.
Here’s the basic idea of sending out SYNC packets at a pre-defined fixed rate:
Once you have such a mechanism, you can do things like send out commands which all devices need to perform on the next sync for example. Nice for controlling the X, Y, and Z axis of of a CNC machine with the accuracy needed to make them all move exactly in sync.
The SYNC message has a very very high priority on the CAN bus, but even so, it can be delayed if it wants to send while some other transmission is taking place. So even though it will probably be first one to go out, it still has to wait for the bus to become available:
As a result, that SYNC pulse we wanted to arrive on time T ended up coming in at T + X. With X being under 200 µs when the bus is running at 1 MHz, but still.
Can we do better?
Yes, and no. We can’t avoid the jitter in that SYNC packet. But while the master sending out that SYNC packet cannot time it more precisely, it does know when the packet actually went out. So it does in fact know what T + X ended up being for that transmission.
And here’s the clever bit: the master can now send out a second (slightly lower priority) packet with a time stamp in it, i.e. containing that “T + X” value, down to the microsecond in fact. The arrival time of that time stamp packet is not so important. What matters is that each slave tracks exactly when the sync came in, and then uses the time stamp to adjust for any difference or drift that may be taking place.
This won’t help make the SYNC pulses come in more accurately, but it will let each slave know exactly what the time of that pulse was, and hence how accurately their own clocks are running. With this mechanism, all clocks can safely be assumed to run within 1..2 µs of each other, and therefore all future commands can now be tied to specific times which are known to be matched up between all slaves with two orders of magnitude better accuracy.
Ingenious, that CAN bus, eh?
Very interesting. This seems similar to PTP for Ethernet.
I’d really like it if there was some way for nodes in the field to have some indication of the wall clock time, but it’s hard to reconcile that with wanting to be asleep most of the time.
The only useful idea I’ve come up with so far is that the timestamp gets piggybacked on an ACK packet. But this requires the server JeeNode to have an accurate clock on hand, which is often not the case.
Now, what I suppose you could do is have a command in the rf12demo where you give it the current time, and the node tries to track the wall clock time from that, sending it in any ACKs it sends. Not ideal, but it should stop nodes getting too far off track…