# Xbee series 2 - router or end device firmware?

I am using multiple XBee Series 2 nodes in my home automation setup, however, I seem to be seeing unusual delays in packet delivery (around 1 or 2s). I have a single coordinator module and multiple routers in the network.

I was wondering, how well does the mesh protocol work? If multiple of the routers are in close proximity, does it actually slow the mesh down? (by close proximity I mean between 3-5m). My rationale was to use router firmware for all my devices as they are not power-constrained and I thought it would be better to have routers - is that the case?

Shall I have the router firmware only on the nodes that really need to be used as routers and flash the rest as end devices even if they are plugged into the wall?

Lastly, the delay has slightly increased when I enabled encryption.

UPDATE

System details:
Room 1 - Xbee coordinator conncted to Raspberry PI via 56700 link
Room 1 - Xbee router used for direct actuation
Room 2 - Xbee router used to communicate with arduino @ 9600 link
(commands fit into a single packet)


I am not using any broadcasts, all of the routers are AT and have DH/DL set to communicate with the coordinator and the coordinator using API mode to communicate to the main controlling software.

Lastly, is there any time needed for the mesh to initialise? Or is it done ad-hoc? Is that information stored on Xbee reboot?

• I had lots of packet delivery issues when I was playing with series 2 xBees. I wound up just switching to series 1 devices. – Connor Wolf Dec 11 '12 at 23:50
• @FakeName That is not a very good option for me as I already own a few of the modules – petr Dec 12 '12 at 12:01

I don't think the router or end device firmware makes a difference. I always use the router firmware, since I have enough power available, and never had such delays as you are experiencing.

• Are you maybe using them in an area with lots of interference?
• Are you using broadcasts to send data? Broadcasts can cause an overload of the network that could easily create those delays and even more.
• How big are the packets you are sending? An XBee packet has a relatively small size. If your data needs to be split, then any delays due to other factors will be multiplied.
• Are your microcontrollers/data sources set to the same serial speed and parity etc. as the XBees?

As a first step I suggest to enable acknowledgements for the packets you send and see how many retries were needed (can be done in API mode). Then you'll know better what to exclude.

• Thanks, I will try the acknowledgements - I wanted to make use of them in my software for a while now anyway. – petr Dec 12 '12 at 12:02
• Also, do you have any idea how long does it take for the Xbee to form a mesh? And how dynamic is it? Could I possibly be in a "dynamic equilibrium" between multiple mesh configs and the constant re-configuration is slowing things down? – petr Dec 12 '12 at 12:03
• reconfiguration would only happen if the XBees lose connection to each other, but at 3-5 m this is improbable. To put it another way, if they lose connection at 3-5 m distance, the 2 second delay is the least of your problems ;) I've had cases where it took up to 2 minutes for the XBees to find each other. However, once they find each other, they usually remember the settings even if power is turned off and the next connection is then much faster. I'm at a loss at this point, can't think of any reason why you should be facing these delays. Do they happen with a two-XBee net as well? – Erion Dec 13 '12 at 0:46
• Thank you for the feedback! It now looks that Xbee's may not be at fault - one of the changes I've introduced was increase of communication speed on the end that sends command - maybe the client is not able to process all the messages due to slower speed. Will try to upgrade them both to same comm speeds and see. – petr Dec 13 '12 at 17:37