using xbee to send a sync pulse to two arduinos

XBee & XBee Gateway XBee - 802.15.4
1

Hi,

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 series 1 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 the NewSoftSerial library 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,

Andy

2

I’ve been trying another method, which is to put all the radios in transparent mode, send a single byte to both receivers in broadcast mode 5 times a second, and trigger on the start bit.

This works quite a lot better - the jitter is down to 0.2ms instead of 2ms. However it would still be good to know if anyone knows where this jitter is coming from and if there is anything I can do about it?

Thanks,

andy baxter

3

You’d always expect a small amount of jitter, because the clocks supplying the UARTS in the two remote XBees can’t be expected to be running in sync. How much jitter would depend on the baud rate you were using. Unless you were using a particularly low rate, I wouldn’t expect it to account on its own for what you’re seeing.

There may be other mechanisms within the firmware, say if the XBees are running a loop and polling for inputs. That would introduce jitter because no two XBees would be at the same point in the loop when a signal arrived, so one would always get to it first. However, this is pure speculation on my part. I know nothing about XBee internals.

Since you haven’t had an answer so far, my suggestion would be to ask the good folks at Digi support. They are, I suspect, the only ones with enough depth of knowledge to answer this.

If you do find the answer, it’d be a kindness if you would follow up this post with the details so that anyone else with the same problem in the future can find it.

Best of luck!

4

The amount of jitter I saw was more than just clock jitter - about 4-5 bits worth at a guess from memory. (at 38400 baud)

You might be right about the polling cycle thing.

I’ll get in touch with digi support and see if they can help.

Thanks!

andy