I know that resonators aren’t the most accurate there is. I can rig up two bare 328p on a breadboard and have them run the Blink sketch and watch them get in sync, out of sync and in sync again. I know, the resonators are slightly off, nature of the beast. So the question now is, what can I do to get them as close as possible. I don’t need GPS accurate numbers, or 5 digits after the period … But I would like them to stay close.
Would using crystals and capacitors be better, or are those also susceptible variations just like resonators? What else can I do, short from trying to figure out how to use an RTC to drive the 328p’s clock?
Oh no, I don’t want them linked to the same crystal. I’m building several stand alone modules. I would just like them to be close enough, so maybe a half a second off every hour, I’m happy with that. I just want to figure out what would be better than using resonators … because these things are wildly different …
And what would the ultimate “accurate” scenario be? Have the clocks driven by an RTC’s square wave output?
All oscillators have an inherent accuracy of the stated frequency, plus there are temperature dependent and independent drifts in that frequency. The more you pay, the more accurate the oscillator. Your specification of one half second per hour is roughly 1 part in 7,000, which is somewhat less than typical for the watch crystals (32678 Hz) used by an RTC. You can buy higher frequency crystals for MPUs with similar specifications. For more accuracy you need temperature-controlled crystal oscillators.
They’re all linked together for I2C communication (and no longer than 20 feet apart, from the first to the last node, though they’re not equally spaced). Basically, if a master sends out a “blink an LED” command to all the modules, I want them all to blink at the same frequency and not get out of sync over time.
However, I just realized something else. I2C may be fast, however it can only communicate with all the nodes “so fast” and the last node will be receiving a command at a slight delay compared to the first one. 20 feet might not be much, but if there are a lot of nodes, that’s a lot of loop cycles to go through communicating with all of them. So, perhaps my idea of having things synced isn’t going to work as well as I thought.
Unless I stick an RTC on each module and have the master I2C send a time frame with the command, something that translates into ‘in 1 second, start to blink’. I think …
kirash4:
Unless I stick an RTC on each module and have the master I2C send a time frame with the command, something that translates into ‘in 1 second, start to blink’. I think …
Why an RTC ? Why not have the master tell all the nodes that a blink is too happen in XX usecs from this message. While the XX will be interpreted differently from node to node, if the XX is small enough, the error should be small enough that a human can’t notice the error. Any fixed delays can be compensated for if each node knows it’s propagation time.
Mee_n_Mac:
Any fixed delays can be compensated for if each node knows it’s propagation time.
How would each node figure that out? Bounce a proverbial ping-pong ball (read: signal) between the master and slave and time it? And yes, I do agree that the delay may very well be imperceptible ...
My first thought is that the master sends the message, the message has a time delay in it, that delay specifying the time between the receipt of the message to the blink time. The message also has a node count in it. If the message is relayed from node to node to node to node ..., each node will increment the count before relaying the message to the next node.
While each node’s internal clock will run differently from any others, over a short delay (<1 sec) I doubt any difference would be noticeable by a human. The delay only need to be large enough to guarantee that the message have been received and decoded by all the nodes before the delay time expires. Having a node count means each node can reduce it’s delay time by the count * fixed increment. You could measure or calculate that increment and have it as a constant stored at each node. This way the path from master to each node need not be known ahead of time, nor even the same from message to message. The clocks only need to be matched well enough to be ~the same for the short delay time. Each node does need to be reasonably deterministic in it’s receipt to resending of the message.
