XBee Configuration: Coordinator and Router (Circle Network)

Posted on Monday, 7 January 2013 | No Comments

After trying a point to point network, and a point to multipoint network, it was decided that a circle network would be implemented. 

Circle network

For this, one XBee needed to be set up as a coordinator and two XBees needed to be set up as routers. 

WHICH ONE TO BE THE COORDINATOR?

For this circle network, the XBees were configured several times until the network worked. Trial and error was used, changing which robot or games master should be a coordinator or router. In order to test the system, a simple test was done by sending integers around the circle, which were read and retransmitted by the correct XBees. Eventually, the setup that worked was:

Coordinater - Robot 2

Router 1 - Games Master

Router 2 - Robot 1

Coordinator and Router Setup for Circle Network

CONFIGURING XBEE TO BE A COORDINATOR

First, the XBee shield was connected to an Arduino with an empty sketch (void setup(){} void loop(){}), with the XBee jumpers in the USB position. The Arduino was then connected to the computer and the X-CTU software was started. 

In the PC settings tab, the COM port that the Arduino was connected to was selected and then select the "Test/Query" button. A window popped up stating the the connection was fine. Next, the Modem Configuration tab was selected and the "Read" button was selected, which then read the parameters and firmware settings from the XBee. Some of these parameters need to be changed to set up the XBee as a coordinator. Thissite helped with which parameters needed changing. Since the coordinator is robot 2, the XBee needs to received from router 2, and transmit to router 1. 

Firstly, to set up the XBee to be a coordinator,in the Modem Configuration tab, Function Set is selected and the ZNET 2.5 COORDINATOR AT firmware was found and selected. Below is a list of parameters and what they were changed to:

PAN ID: 1234
SC: 1FFE
SH: 13A200
SL: 4032075A
DH: 13A200
DL: 4031F56F

The DL is the destination address of the Games Master, as this is what Robot 2 will be communicating with.

This can also be seen in the following screenshot. 

Robot 2 XBee Setup

CONFIGURING XBEE TO BE A ROUTER

Again, the XBee shield was connected to an Arduino with an empty sketch, with the XBee jumpers in the USB position. A different XBee radio was put into the shield and then the Arduino was connected to the computer and X-CTU was started up.

The Arduino port was selected and the connection was tested, before selecting the Modem Configuration tab and reading the parameters from the XBee. Some of these parameters need to be changed to set up the XBee as a router. 

ROUTER 1

For router 1, it is the Games Master therefore it needs to transmit to router 2 and receive from the coordinator. 

Firstly, to set up the XBee to be a router,in the Modem Configuration tab, Function Set is selected and the ZNET 2.5 ROUTER/END DEVICE AT firmware was found and selected. Below is a list of parameters and what they were changed to:

PAN ID: 1234
SC: 1FFE
SH: 13A200
SL: 4031F56F
DH: 13A200
DL: 4031F55E

The DL is the destination address of Robot 1, as this is what the Games Master will be communicating with.

Below is a screenshot of the parameters:

Games Module XBee Setup

ROUTER 2

For router 2, it is robot 1, so it needs to transmit to the coordinator, and receive from router 1. 

The XBee was set up as a router in the same way as router 1 above and the parameters were changed to the following:

PAN ID: 1234
SC: 1FFE
SH: 13A200
SL: 4031F55E
DH: 13A200
DL: 4032075A

The DL is the destination address of Robot 2, as this is what Robot 1 will be communicating with.


Again, a screenshot below shows the parameters:

Robot 1 XBee Setup

That is the XBees set up to talk in a circle network (Games Master talks to Robot 1, Robot 1 talks to Robot 2, Robot 2 talks to Games Master). All that needs to be done now is to change the Arduino code to deal with this network setup. 

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.

Point to Point Xbee Network Testing

Posted on Friday, 4 January 2013 | No Comments

Xbees are wireless modules which interface radio transmissions with standard serial input output.  All transmission issues are taken care of by the Zigbee protocol (which is the protocol that Xbee Series 2 modules use).  This ease of use means Xbees are often used as drop in replacements for a serial cable as can be seen in the diagram below.  In this configuration the module's default settings mean that a link can be set up quickly and easily.

Xbees in Unicast mode

This is called 'uni-cast', when a module knows the address of it's recipient, and sends data directly to it.  In this example, the second module also knows the address of the first Xbee, and therefore can reply back to it.

Xbee Shields

In this project, shields are used to interface the Xbee module with the Arduino Uno on the robots.  The main component on these shields is a voltage regulator to convert the Arduino's 5V logic to the Xbee's 3.3V. Without this the Xbee module could be damaged.

There are two jumpers on the Xbee shield in order to set whether the Arduino uses the USB port for serial output as normal, or sends it's data to the Xbee.  If flashing a board with a Xbee module connected, the jumpers need to be in the USB setting, if the Arduino needs to connect to the Xbee, the jumpers need to be in the Xbee setting.  It is also worth noting that the Arduino can be connected to a computer via the USB cable in order to monitor what the Xbee is receiving with the jumpers in the Xbee setting.  This is due to the Rx channel being connected to both the Arduino and the USB port.  The diagrams below show the shields on top of the Arduino, with the jumpers in both positions.

Another possible configuration is to have the jumpers in the USB position, but having the Arduino chip removed.  This can be done by carefully inserting a flat headed screwdriver underneath the chip and slowly lifting it up without bending any pins.  Take note of which way up the chip goes so that it can be reinserted later!  This configuration allows the Arduino board to act as an interface to the Xbee module, meaning that the computer can send serial data to be sent over the Zigbee network.  This configuration is used later in the project so that Processing can communicate with the two robots.

Testing an Xbee Network

Most communication examples use the 'Physical Pixel' example sketch.  This bundled example can be found in the Arduino IDE in Examples>Communication>Physical Pixel.  The code can also be seen below.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

/*   Physical Pixel     An example of using the Arduino board to receive data from the  computer.  In this case, the Arduino boards turns on an LED when  it receives the character 'H', and turns off the LED when it  receives the character 'L'.     The data can be sent from the Arduino serial monitor, or another  program like Processing (see code below), Flash (via a serial-net  proxy), PD, or Max/MSP.     The circuit:  * LED connected from digital pin 13 to ground     created 2006  by David A. Mellis  modified 30 Aug 2011  by Tom Igoe and Scott Fitzgerald     This example code is in the public domain.    http://www.arduino.cc/en/Tutorial/PhysicalPixel  */   const int ledPin = 13; // the pin that the LED is attached to int incomingByte;      // a variable to read incoming serial data into   void setup() {   // initialize serial communication:   Serial.begin(9600);   // initialize the LED pin as an output:   pinMode(ledPin, OUTPUT); }   void loop() {   // see if there's incoming serial data:   if (Serial.available() > 0) {     // read the oldest byte in the serial buffer:     incomingByte = Serial.read();     // if it's a capital H (ASCII 72), turn on the LED:     if (incomingByte == 'H') {       digitalWrite(ledPin, HIGH);     }     // if it's an L (ASCII 76) turn off the LED:     if (incomingByte == 'L') {       digitalWrite(ledPin, LOW);     }   } }

This reads an available byte from the Arduino's serial buffer, and if it is the character 'H', turns on the LED hardwired onto pin 13.  If it is an 'L', it turns the LED off.  In order to test this sketch, code needs to be written to send the characters. This is done simply by writing the required character to the serial port, which the Xbee then picks up and transmits to its partner.  This code can be seen below.

?

1 2 3 4 5 6 7 8 9 10 11

void setup() {   // initialize serial communication:   Serial.begin(9600); }   void loop() {   Serial.print('H');   delay(500);   Serial.print('L');   delay(500); }

The result of this is to see the LED on pin 13 on the receiving Arduino flashing on and off every second, therefore confirming the two Xbees are connected.  It has been found if a connection is not found, performing a hard reset of the two devices simultaneously forces a re-setup of the network, and allows the two devices to find each other.

The actual network required for this project is a point to multipoint network, which is much more complex, and will be covered in a separate post.