synchronization sensing


Does the Xbee can do the synchronization less than 1ms ?

I have bought several Xbee-Pros (802.15.4 S1).
I don’t know how to synchronization all xbee.
I have .net MF devices that connect with Xbee and accelerometer.
I want logging accelerometer data synchronously.

Does xbee can fit my need?

Thank you very much.


You didn’t say what you mean by ‘synchronized’? Do you means samples within 1 second of each other, or 100 microseconds?

The 802.15.4 support broadcast, so one node could broadcast a ‘sample’ request, and X other nodes could take an instant sample (snapshot) at that point. They obviously cannot return those samples at the same time, so each node will have to select a small random (or predefined) backoff to allow each node some clear radio-frequency time to return its value.

Thanks for your reply.

I want use an Xbee broadcast a packet to other Xbees.
Ideally, the other xbees will receive the packet simultaneously then start sensing. I want all sensing nodes start sensing simultaneously.
However, they may have many synchronization errors such as Send Time
Access Time, Interrupt Handling Time, Transmission and Reception Time:
Propagation Time, Encoding and Decoding Time, Byte Alignment Time
Receive Time. So what is the synchronization time error for Xbee to receive the broadcast? For my application, the sampling time is 200HZ to 1000HZ. If the time error more than 1ms, it will be a problem.
Does anyone use the Xbee to do some synchronization protocol such as RBS, TSPN, FTSP ?

Thank you very much.

I would be very suprised if any ZigBee system can provide synchronisation to that level in terms of sending a broadcast and expecting all devices to trigger off of it.

In the first instance they would need to be guarenteed to be in reception range of the signal in a single hop.

In the second instance, if they are end devices the time of reception depends on when they poll the nearest router (as far as I understand it).

Thirdly, the handling of the incoming packet probably depends on whether there are other packets queued, what other tasks the particular device is performing etc.

One might be able to synchronise the time on the devices in some fashion to the required accuracy and kick off timed events but I don’t see any obvious mechanism for guaranteeing tightly synchronised action from an externally applied trigger over the air.


802.15.4 is better than ZigBee, since it doesn’t ‘hop’ and broadcasts aren’t repeated (etc). Every node needs to see all others RF line-of-sight.

The best time-promise I’ve seen via an 802.15.4 customer is about 50msec or less latency node-to-node.

You migth want to consider using a second radio - an ultra-dumb (perhaps 125Khz or 433Mhz) transmitter/receiver that would allow one node to ‘sync’ all the others once per second external to the 802.15.4 communication channel. The master would have a transmitters, and each node just a receiver. It’s the kind of thing you can buy for $5 or $10 & is used in toy cars, wireless fan control, or RFID tags.

Thanks for your fast reply.
@ Peter
You said that it is hard to use the externally applied trigger over the air.

  1. How about using the GPS?
  2. Many clock synchronization protocols depend on exchanging MAC level timestamps. Does Xbee can get the MAC level timestamp?

@ lynnl

Yes, I am just thinking to use other RF like 433Mhz.
But in your experience, does this trigger mechanism can reach the 1ms synchronization level?


GPS works because the ONLY transmitters are in orbit & tightly controlled by the monopoly!:slight_smile:

Using 433 will only work if you have 1 transmitter and X receivers. So changing to use 433Mhz instead of 802.15.4 won’t help you IF you also allow your devices to transmit/send data on the same frequency.

It is the ‘carrier-sense&backoff-if-busy’ behavior of 802.15.4 which will prevent your 1msec time sync. What if the host/time-sync source detects that one of your nodes is talking when it wants to send a time syn? Then it must back-off and wait a few msec.

So you will need 2 radios to do what you want. One very simplistic frequency purely for the time-sync (so 1 and only 1 transmitter) and a second frequency with complex 802.15.4 peer behavior for the data transmission.

The best you can hope for with GPS is to allow precisely timed operation. So for example if you know your worst case latency is 100ms, you could have the trigger device send a request for the triggered event to happen simultaneously some time later than 100ms from the current time e.g. switch state in t+150ms.

This does not provide a way of say, having an external stimulus fed into the master device triggering an event in the slaves with less than 100ms latency.


Time synchronization using RF has been succesfully demonstrated through WiFi (using WiFi enabled Digi Embedded modules running Linux). The accuracy is better than 0,1msec and the mechanism uses the WiFi Access Point Beaconing with a flywheel principle on the clients to be synchronized.

Downside is that the radios (using WiFi) are more expensive and complex.