Point to Multipoint - Broadcast Network Design

Posted on Monday, 7 January 2013 | No Comments

This method for configuring Xbees ended up being too slow for this projects requirements, due to the Zigbee protocol's requirement for delays to be in place to allow packets to propogate through the whole network.

A simple solution could be to simply use another Xbee, and have a separate channel for each robot, however this would require another shield and Arduino as an interface.  The budget and hardware is not available for this.  Instead a 'circle' network configuration was devised to allow all devices to communicate at rate that was suitable.

In a broadcast network, one module is set as the 'master'.  This sends out all it's messages to all devices on the network.  The devices can then check an ID that is sent as part of the message, and then decide whether they need to act upon it or not.  This sounded suitable for this project, as both robots could then receive all messages, and only carry out the instructions if the ID matched the number of the robot.  They can then reply to the master if they are hit, or as required through a uni-cast connection which is configured in their modules. This configuration is illustrated below.

Broadcast configuration for an Xbee network

This is not as simple as the standard uni-cast point to point network with two modules that is often employed with Xbees so direct configuration of the Xbee's firmware was required.

Using X-CTU

X-CTU is Digi International's configuration software for Xbee modules. It runs on any machine using Windows. There are alternatives for Mac OSX and for Linux based machines.  The download for this software is here.

In order to flash the firmware of the Xbee module, it needs to be connected to an Xbee shield with the jumpers in the USB position.  The shield should be on top of an Arduino running an empty sketch (so just void setup(){}; void loop(){};).  The Arduino can then be connected to the PC, and the X-CTU software started.

The first screen is the PC settings tab, with a large menu showing visible COM ports.  Select the one that the Arduino is connected to (this can be tested by disconnecting and seeing which COM port disappears).  The serial settings should be left as default, with the baud rate at 9600.

Under the Modem Configuration tab, at the top left is a button labeled Read.  When clicked, this reads the parameters and firmware settings from the radio.  Clicking on these settings gives the options to edit the values.  Once finished editing, clicking write flashes the firmware of the radio.  This screen is shown below.

X-CTU Modem Configuration Screen

Xbees have four main parameters:

ID - Network Identity, this identifies which radios can talk to each other, radios with the same ID can talk to each other.  

MY - Individual Identity, this is the address of an individual radio. This should be unique within the network.

DL/DH - Destination Address, this parameter defines which radios receive messages from this module.  DL (destination low) should be set to match another radios MY, and for the most part DH (destination high) should be set to 0.

To send and receive data between two radios, the MY and DL should be set identically.

Broadcast Configuration and Issues

When a module's DL parameter is set to 'FFFF', it is set to broadcast mode.  In this mode, all messages sent  from the module are sent to all modules on the network, ignoring any MY/DL pairings.  This seemed perfect for this project, as all packets could be sent, and the robots could respond to an ID character within the packet.

However when testing using Physical Pixel, the LEDs on both test Arduinos would flash - indicating that packets were being received, but they did not flash at a constant rate. To begin with, it was not known why this was happening, and it was decided that any delay would not be noticeable when driving the robots.

Once the full robot was built, and the USB cable was substituted for the Xbee pair configured in broadcast mode, the bigger issue was discovered. The robot would respond to the first three commands sent, pause for 2/3 seconds, and then carry out the rest of the instructions.  This was difficult to diagnose through the servo movement, as they receive so many instructions so quickly, however the robot drive would respond, and then pause.

Further investigation online led to the discovery that the Zigbee protocol specifies pauses to allow modules to rebroadcast any received packets, so that the message can propogate across the whole (unknown size) network.  This forum reply suggested that the delays built into the module only allow for three broadcasts every four seconds.  These figures were very similar to the delays experienced during testing, so a solution was sought.

The proposed solution was to design a circle network, as covered in a later post.