I am working on a system where we need two arduinos to do something at the same time, to an accuracy of around 200 microseconds or better. At least one and ideally both of the boards needs to be wireless.
The way I'm trying to do this is as follows:
- We have 3 arduinos with xbee modules attached.
- 5 times a second, the 'sync' board transmits a remote AT command request to the xbee broadcast address on PAN ID 4321, channel C. The AT command being broadcast is to set pin D0 high.
- After about 1ms, another command is sent to set D0 low again.
- The other two ('receiver') modules are set up on the same PAN ID and channel.
- the arduino firmware on the receivers uses a pin change interrupt to detect when the pin goes high on the module.
This is working to the point that both receivers get the command and pulse their pins, but there is a problem with the timing - one of the boards sets its pin high between 0-2ms later than the other (as measured on an oscilloscope at the xbee module's pin D0; the amount of delay varies)
Does anyone know why this would be happening? I was hoping that by broadcasting from one board to two others like this, I would avoid any problems with timing delays / jitter, but it doesn't seem to be working the way I hoped. The digi.com knowledge base page at http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=3065
says that broadcast packets don't expect any acknowledgement, so I don't see where the timing error is coming in. That page describes the best and worst case delay for a broadcast packet, which can be up to 9ms, but the delay is all in waiting for the channel to become clear, i.e. before the packet is sent, so it shouldn't cause a delay between the two receivers.
The other problem I'm having, which is annoying but not so critical, is that every 20-30 packets the arduino on the sync board fails to get a reply from the xbee module to its remote AT request (using the example code, it prints 'no response from radio'). It's possible that this could be because I hacked the xbee library to use NewSoftSerial instead of hardware serial for talking to the module, but I don't think it's this because I was pretty careful about the way I changed the code.
Thanks for any help,