Xbee serial communication

Question

I'm building a mesh network with xbees, arduinos and sensors.

Right now I have 2 Xbee routers and 1 coordinator. Each xbee module has an arduino attached. To communicate from the router to the coordinator, I use the Serial.println() function. Is it possible that when 2 routers communicates via serial to the coordinator, the data overlaps? For example if from Router 1 I'm sending "HELLO" and from router 2 "World", is it possible that the coordinator will receive both of them at the same time and will output "HELworlLOd"? Or does the coordinator just takes 1 "data package" at a time? If so, what happens if the coordinator is receiving some data from router 1, and at the same time router 2 sends a package? Does it get lost? Does the zigbee protocol takes care of that and makes sure that the router sends it again? Do I have to implement this in my code?

Thanks!

Answer 1

The data transmitted by the radios in 'transparent' mode gets packetized after a configurable packetization timeout (RO). There may be a way to force packetization and transmission before this timeout. The default delay for the XBee/XBee Pro (XB24-A.../XBP24-A...) is 3 character times. So long as you send your string with the characters 'back to back' (don't pause while sending data), it should end up as a single packet. Note that there is a limit on the packet length (100 bytes for the XBee/XBee Pro) - if your message is too long, it will get split into more than one packet. This should not be an issue if you are sending, say, 64 byte packets once per second. Also, XBee modules should be using CSMA to limit collisions, making it less likely for two nodes in range of each other to try to transmit at the same time. XBee modules also support retransmitting when operating in unicast mode (single destination address) so if a packet is not ACK'd by the receiver then the transmitter will try sending it again. The retransmit delay and count appear to be fixed by the MAC implementation and are not configurable, though ACKs and retransmits can be disabled completely.

Depending on what you are doing, it might be worth looking in to using the radios in API mode. With API mode, you can queue up explicit packets to send that are guaranteed to be 'atomic' and not split up. It's also the only simple way to manage networks that are more complicated than simple point-to-point as you can specify destination address on a per-packet basis as well as extract the source address from received packets. It is also possible to get status reports on transmitted packets to see if they have been ACK'd or not by the receiver.