Hi folks,
I'm starting development of a musical/audio project where I would like to have multiple arduinos clock synchronized close enough for basic music rhythms. Probably within +/- 0.01 seconds would be OK. I was thinking a master "heartbeat" arduino that pull the slaves into sync about once a minute might work, though I have no idea how to go about it...
I have done sensing and LED control w/ Arduino before, so maybe a pointer in the right direction be enough to get me started.
Longer project description -------
Gallery installation, with
Multiple "music boxes" [about 6x6x12"], each containing:
Sensor for viewer proximity [basic "anyone standing here yes/no"]
Triggering device for plucking/striking one resonator [acoustic, similar to a xylophone]
LED lighting control [probably writing to one or two "MegaBrite" modules]
Aesthetically, it's important to me that these boxes (between 6 and 24 of them) have no visible connections, so a wireless connection is preferred. Is this even feasible (assuming I can solve the battery power requirements)?
cheers and thanks for any tips/suggestions,
Jeff B.
Sync multiple Arduinos via wireless?
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- adafruit_support_bill
- Posts: 88154
- Joined: Sat Feb 07, 2009 10:11 am
Re: Sync multiple Arduinos via wireless?
Check out the XBee wireless modules.
These are somewhat battery hungry. But you can put them to sleep had have them wake up periodically to sync to save power.
These are somewhat battery hungry. But you can put them to sleep had have them wake up periodically to sync to save power.
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Sync multiple Arduinos via wireless?
+/- 10ms might be a little tricky. The way I would do it would be to use a ChronoDot, which is a temperature-compensated real-time clock. Put one of those on every arduino, and update the arduino system clock from there once every minute or so.
The wireless sync will be the tricky part. For that, I would adapt the Network Time Protocol (NTP) that computers use for syncing current time of day. NTP is designed to compensate for transmission delays, and the algorithm is pretty simple. On a closed XBee network, it should be able to get all of the ChronoDots synced to within 10ms.
The ChronoDot spec claims +/-2ppm accuracy, which is something like 160ms/day. So, you could do your wireless sync maybe once per hour. I would expect that the clock sync, by its nature, would introduce artifacts into the musical timing, so the less frequently you do it, the better.
I pulled the following nugget out of the SNTP (Simple NTP) RFC (available here), which succinctly describes the basic messaging and algorithm:
The wireless sync will be the tricky part. For that, I would adapt the Network Time Protocol (NTP) that computers use for syncing current time of day. NTP is designed to compensate for transmission delays, and the algorithm is pretty simple. On a closed XBee network, it should be able to get all of the ChronoDots synced to within 10ms.
The ChronoDot spec claims +/-2ppm accuracy, which is something like 160ms/day. So, you could do your wireless sync maybe once per hour. I would expect that the clock sync, by its nature, would introduce artifacts into the musical timing, so the less frequently you do it, the better.
I pulled the following nugget out of the SNTP (Simple NTP) RFC (available here), which succinctly describes the basic messaging and algorithm:
So, what that gives you is the offset between your time and the server time. You adjust your clock by that offset to synchronize.To calculate the roundtrip delay d and local clock offset t relative
to the server, the client sets the transmit timestamp in the request
to the time of day according to the client clock in NTP timestamp
format. The server copies this field to the originate timestamp in
the reply and sets the receive timestamp and transmit timestamp to
the time of day according to the server clock in NTP timestamp
format.
When the server reply is received, the client determines a
Destination Timestamp variable as the time of arrival according to
its clock in NTP timestamp format. The following table summarizes the
four timestamps.
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client
The roundtrip delay d and local clock offset t are defined as
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
Please be positive and constructive with your questions and comments.