4

I am using several XBee Zigbee with some Arduino modules (or microcontrollers, Arduino is not mandatory). I configured my XBees in AT/transparent mode.

I need to broadcast information: when one module is touched, every other module must react at the same time and immediately.

Unfortunately, if I have good speed results in unicast mode, there are lots of latencies in broadcast mode. It is something known and documented, see XBee ZigBee Addressing.

No data is lost, but they are sometimes buffered for a few seconds by an XBee before being sent again or delivered to my Arduino.

It seems it is not a configuration problem, it is the way the broadcast protocol work. Any idea on how I could speed-up the process?

The only one I have would be to use the API mode, to make each Arduino keep a list of the XBee addresses, and unicast information to the list of these addresses... but I lose the comfort of the broadcasting method, and I cannot easily add a new module without updating every Arduino.

Vincent Hiribarren
  • 5,254
  • 2
  • 41
  • 65

2 Answers2

9

Transmitting data using broadcast addressing with XBee ZB modules will generally give you much, much less performance than transmitting an individual unicast to each node you want to talk to. This is because broadcasting works very differently on the XBee ZB modules than with the XBee 802.15.4 modules.

When you send a broadcast with the XBee 802.15.4 modules, a single 802.15.4 frame is transmitted to the network and all the nodes that can hear the transmission pick it up and send the information out of their serial UARTs. The 802.15.4 network is a simple star network and no implicit repeating of the broadcast is performed by any of the nodes on the network. With XBee ZB, this is different. The XBee ZB modules are acting in a mesh topology and need to repeat the information to the other nodes that are out of range of the original transmission.

When you send a broadcast with the XBee ZB modules, each node that receives the broadcast will re-broadcast it 3 times, causing a lot of data to be transmitted between nodes. Additionally, there can only be a certain number of broadcasts which are "live" on a network at any given time. This often surprises people into thinking that the network is dropping their data when in fact the XBee is rejecting the transmission request.

Unless you are sending data very infrequently--perhaps a broadcast once per minute or more slowly--it is often better to follow this procedure:

  1. Built a list of all nodes by performing a network discovery or collecting route record packets by enabling the AR feature
  2. Send a unicast to each node you wish to transmit to

If you're sending information to a nodes on a large ZB network (i.e. greater than 30 notes) you may want to read this article: Large Networks and Source Routing

Jordan
  • 986
  • 9
  • 13
2

I don't think you can optimize it much more, unless only some of the modules need to receive the message. In this case you could use a multicast (might only be available with Xbee 2) instead of a broadcast, which would bring some very minor improvement on the overall speed of your network when it grows big enough (greater than 16 nodes, i.e. the basic routing table).

Have you tried a comparison between unicast, multicast and broadcast? It may be that making a dozen unicasts is on average faster or at least more reliable, especially if you have many hops in your specific network (ex: a 12-node network with 8 hops).

With unicast you can get a confirmation or ack so you know the overall time and success of the operation, and whether you need to retry or not.

Reggie
  • 644
  • 5
  • 10