We are working on a data collection application, where a number of nodes send regular samples back to a coordinator. The samples will be read on an msp430 controller and sent back using xbee zb modules.
It would be useful for this if we could have a network-synced clock on all the remote nodes. I’m looking into whether it’s possible to use a regular broadcast packet from the coordinator to sync the clocks on the remote devices.
The timings don’t need to be super-accurate - just enough for the remote devices to sync to the network clock when they are turned on, and to prevent clock drift over a number of days. Tens of milliseconds would be good enough.
The first question is whether there’s some way to disable retries on broadcast packets? The datasheet seems to say that this isn’t possible, but it would be nice to know for sure.
Also, I could do with more details on the timing of the radio / MAC layers of the zb firmware.
In particular, when the modem first tries to send a broadcast packet, does it try immediately and then retry later if there’s a collision, or is there a period when it’s waiting for a clear channel before the first transmission attempt? I’ve looked for a webpage covering this sort of thing but not found anything.
This will be hard with ZigBee due to the broadcast variable latency - every ‘router’ will try to repeat the broadcast up to 3 times spread over a 5 second period. Occassionally, nodes will see the same request twice.
If accuracy +/- a few seconds is fine then this might work.
Alternatively you could do a system where the remotes on some period ‘query’ the central unit for a time. Unicast when route discovery is NOT required should be pretty fast - less than 50-100 msec for a round-trip.
The way I was thinking of doing it if retries can’t be disabled is like this:
every second, the coordinator sends a broadcast packet with the number of hops set to 1 (no rebroadcasts). We are talking about quite small networks with no more than 16 devices per network, so I think that using a single hop will be OK.
the coordinator checks how many retries there actually were in the tx status response.
each packet contains a byte indicating how many retries there really were in the previous packet.
the receiving nodes know to only take their timing information from the packets with one retry - the rest are ignored.
Another way might be to have each broadcast packet include the time when the status response from the previous packet was received from the coordinator. I.e:
one broadcast packet is sent a second (with number of hops = 1)
the coordinator listens for the status response and notes the time on its internal clock.
the next packet contains the time the status response to its predecessor was received.
each receiving node adjusts its clock based on the average difference between the time packets were received, and the times shown in the received packets. (Averaging over maybe 10 clock ticks).
I know this is a bit indirect and kludgy, but do either of these sound likely to work in practice?