Time Synchronization with XBee modules?

Wireless & IoT
1

Hi,

I have a few of the xBee series 2 modules and my project requires that I have very stringent synchronization requirements, down to about 1 microsecond resolution. I have done a lot of reading on synchronization techniques (like at the following website).

http://www.cs.wustl.edu/~jain/cse574-06/time_sync.htm

They all seem to require some low-level access to the MAC layer or similar. The simplest way I can think of was using a coordinator module to send a “broadcast” to all xBee nodes. Then each node would note the time of reception and thus the nodes can be synchronized with each other (assuming transmission over the air is instantaneous, and it basically is going to be at the nanosecond level). This is basically “Reference Broadcast Synchronization” in the page above.

The problem with this is that if I use the xBee modules as is, there is all that reception time in packetizing, sending the broadcast reception through UART to my microcontroller, etc and a lot of accuracy will be lost. I need to almost know the exact time at which the physical radio wave hit the antenna. Do the xBee modules make it easy to read this time value? Does anyone have any ideas for what I could do? One paper that I read (http://www.ece.uah.edu/~milenka/docs/dc … _synch.pdf) talked about how they were using these “Telos” modules that actually would trigger a pin that could be hooked up to an interrupt, whenever the specific start of frame byte was received. Is there anything that could be done similar for xBee?

Thank you.

2

1 uSec precision synch among XBee cannot be done to my knowledge, without special hardware. But to put that precision to use, if it were obtained, would take special hardware anyway.

The MAC layer in all 802.15.4 radios is firmware. This runs on a humble microprocessor: 8051, atmel, Jennic, TI, whatever. The timing in these would jitter by tens or more microseconds, maybe miliseconds, not microseconds, nor one microsecond.

Best to use GPS and 1PPS from a $60 OEM module unless you have special hardware.

The sub-microsecond synch’d RF systems I’ve worked with do so with special hardware that follows the correlation peaks in a spread spectrum signal. This is at the bottom of the PHY.

What you CAN do is devise a way to “discipline” a low cost oscillator. Short term drift is very low in these. So an orders of magnitude slower discipline timing scheme can correct. Read up on disciplined crystal oscillators. Often using a crystal oven. But even with this, you need a way to get many disciplined oscillators synch’d. It’s not simple.

GPS is the simple answer.

Don’t forget that RF propogates at about 1 nanosecond per ft. So 1 uSec is roughly 1000 ft.

3

stevech:
1 uSec precision synch among XBee cannot be done to my knowledge, without special hardware. But to put that precision to use, if it were obtained, would take special hardware anyway.

The MAC layer in all 802.15.4 radios is firmware. This runs on a humble microprocessor: 8051, atmel, Jennic, TI, whatever. The timing in these would jitter by tens or more microseconds, maybe miliseconds, not microseconds, nor one microsecond.

Best to use GPS and 1PPS from a $60 OEM module unless you have special hardware.

The sub-microsecond synch’d RF systems I’ve worked with do so with special hardware that follows the correlation peaks in a spread spectrum signal. This is at the bottom of the PHY.

What you CAN do is devise a way to “discipline” a low cost oscillator. Short term drift is very low in these. So an orders of magnitude slower discipline timing scheme can correct. Read up on disciplined crystal oscillators. Often using a crystal oven. But even with this, you need a way to get many disciplined oscillators synch’d. It’s not simple.

GPS is the simple answer.

Don’t forget that RF propogates at about 1 nanosecond per ft. So 1 uSec is roughly 1000 ft.

In the PDF I linked to, using the Telos motes (I think they’re a new company now but they’re selling similar hardware), they were getting like 63 microsecond accuracy, and this was mainly because of the 32 KHz clock they were using. They said if they used MHz and accurate crystals they could get much better accuracy but they never tried it.

I guess it seems a bit odd to me that you couldn’t get microsecond accuracy with a straight RF signal at the MAC layer. But you seem to have had experience in dealing with these systems so maybe this isn’t the route to take. The RF propagation isn’t a problem, since all the nodes are gonna be pretty close to each other (just a few feet or even inches) but they just need to be extremely accurately synchronized. They are only going to be sampling for a few milliseconds (just a burst of data) but then they need to be synchronized to figure out that timing. I don’t know how else to do it.

I’ll look into GPS. Do you know what type of synchronization accuracy I could get from that? The main problem with GPS is that it seems like it’ll need an antenna too, it’s a big module, and where these tests are being done may not have GPS reception, etc.

Also do you have any information on these sub-microsecond RF systems you’ve worked with? This is mainly for a R&D project so I think it’s ok for me now to take an esoteric route…

4

Precision in the MAC layer: Have you written real time firmware for microprocessors? You either poll in a loop or do an interrupt that has variable latency. Polling in a two instruction loop isn’t practical, if that same microprocessor has to implement the MAC and has to do preemptive or cooperative multitasking.

Is the goal to do position estimates via time difference of arrival (TDOA)? Or a precisely timed mesh network? Or other?

TDOA products - see Aeroscout.com and Ekahau.com. Also Wherenet.com

Time synchronized meshes: see IEEE 802.15.5 (ratified summer 2009). See Dust, Inc. Digi.com for Digimesh. UCSB was the root of this, under DARPA funding for Smart Dust and low powered mesh networks, way back. Meshes are time synchronized to tens or a few hundred microseconds, to improve rendezvous between “sleeping” battery powered routers.

TOA, TDOA, multilateration.

I have recently implemented 802.15.4 broadcast containing time to a fraction of a second. Receiving nodes catch this and on occasion, update their real time date/time. Simply time broadcast, not precision synch. Too much variable latency in the receiving microprocessor’s MAC firmware to do much more than 10s or 100s of microseconds.

If you can find an 802.15.4 chip that brings out on a pin the spread spectrum code correlation match, you might do this.

5

stevech thanks for your input. yeah, basically imagine a bunch of nodes in some material and then you hit it with a hammer, you can basically estimate the position of the impact based on how long the wave takes to hit each sensor. that’s why we need time synchronization. a complicating factor is that we also want to have the nodes sleeping most of the time to save power until there is an impact. obviously it’s a complicated problem, but i just wanted to take it a step at a time. we may have to rethink how we’re approaching this…

6

Phase interferometer - acoustic, since the medium is slow?

7

i’ve done a simple experiment:

A coordinator is in API mode, using the latest ZB firmware.

I have two XBee modules using AT firmware, each connected to its own Atmega8. Baud rate is 230400. AVRs are running at 7.37 MHz.

I “broadcast” a signal using the coordinator. It’s just a character. When each Atmega8 receives the character, it turns on its own LED. (Just asserts a pin high in a polling loop).

I use an oscilloscope to measure the difference in time between each microcontroller asserting its LED. I expected about 10-100 microseconds based on what people said here but the numbers I got are about 10 milliseconds on average. I think I’ll have to go with a different approach. However, there is a curious thing:

One microcontroller would receive the signal before the other one, like 20 times in a row. Then they would switch places. Also, the numbers were about 9 or so milliseconds for a while, but then they started increasing until they were always 30-90 milliseconds and never got lower again.

Does anyone think this is an artifact of what’s going on with the Zigbee protocol? Could there be a way to “disable” some things so that I could get a little better time synchronization? I don’t need 1 microsecond just yet but the 100 microsecond level sounds at least achievable, I’m wondering why it’s so much higher.

8

If your broadcast is with CCA enabled, the absolute time will vary per CCA.

The relative time of receipt at 2+ receiving XBees would vary by how you measure this plus the latency and jitter timing of the XBee’s microprocessor that implements the MAC, plus the latency in the attached microprocessor and the method you use to do serial I/O.

“Broadcast” - to the all ones address, right?

The 802.15.4 beacon, I believe is sent without CCA. But the serial API has no support for beacon detection timing.

9

stevech:
If your broadcast is with CCA enabled, the absolute time will vary per CCA.

The relative time of receipt at 2+ receiving XBees would vary by how you measure this plus the latency and jitter timing of the XBee’s microprocessor that implements the MAC, plus the latency in the attached microprocessor and the method you use to do serial I/O.

“Broadcast” - to the all ones address, right?

The 802.15.4 beacon, I believe is sent without CCA. But the serial API has no support for beacon detection timing.

The broadcast address I use is what the datasheet said – 00 00 00 00 00 00 FF FF. Then the 16 bit address is 0xFFFE.

I only found one reference to CCA on the datasheet, in the “Zigbee Transmit Status” packet, and it’s in the delivery status as CCA Failure. I don’t know how to enable/disable this in Broadcast. Is there any way to do that?

The Broadcast section also says “All devices that receive a broadcast transmission will retransmit the packet 3 times” – does this include the end devices?

10

The Broadcast section also says “All devices that receive a broadcast transmission will retransmit the packet 3 times” – does this include the end devices?

That’s a very odd statement. I don’t believe that applies to Series 1. My knowledge of broadcast packets is that they are received, there is no MAC layer ACK, no error correction, and no assured receipt.

Delays due to CCA would apply equally to all, i.e., a broadcast transmission is simply delayed.

As stated earlier, you can’t expect the relative accuracy of what you’re doing to be better than a few mSec.

11

stevech:

The Broadcast section also says “All devices that receive a broadcast transmission will retransmit the packet 3 times” – does this include the end devices?

That’s a very odd statement. I don’t believe that applies to Series 1. My knowledge of broadcast packets is that they are received, there is no MAC layer ACK, no error correction, and no assured receipt.

Delays due to CCA would apply equally to all, i.e., a broadcast transmission is simply delayed.

As stated earlier, you can’t expect the relative accuracy of what you’re doing to be better than a few mSec.

I've switched to using one of the simple radios (KLP/Laipac 315 MHz) for time sync and XBee for the other stuff. Early results are promising, I am getting a few microseconds of delay, but I still expect there to be more once I implement a protocol with a microcontroller. But I think this is the way to go -- a very simple radio module. Thank you!
12

yes, if you eliminate all the functionality in the MAC, i.e., eliminate the MAC, things are quite different!