Chapter21 XBee shield

From SainSmart Wiki
Jump to: navigation, search

What’s XBee shield?

The Arduino XBee shield (an Expansion Board without XBee module) is a compliant solution designed to meet low-cost, low-power wireless sensor networks with special needs. The module is easy to use, low power consumption, and the provision of critical data between devices reliable transmission. As the innovative design, XBee-PRO can be in the range 2-3 times beyond the standard ZigBee modules. XBee-PRO modules work in the ISM 2.4 GHz frequency band. The MaxStream's XBee (1 mW) Zigbee module is pin-compatible.

E211.jpg

The Xbee module is widely used in the United States, Canada, Australia, Israel and Europe. The establishment of RF communication does not require any configuration and the module's default configuration supports a wide range of data system applications. You can also use a simple AT command to advanced configuration. An OEM developer is now XBee code development package. It is self-developed in collaboration with the MaxStream ZigBee/802.15.4 RF module code.

Example

You should be able to get two SainSmart boards with XBee shields talking to each other without any configuration, using just the standard SainSmart serial commands. To upload a sketch to an SainSmart board with a XBee shield, you'll need to put both jumpers on the shield to the "USB" setting (i.e. place them on the two pins closest to the edge of the board) or remove them completely (but be sure not to lose them!). Then, you can upload a sketch normally from the SainSmart environment. In this case, upload the Communication | Physical Pixel sketch to one of the boards. This sketch instructs the board to turn on the LED attached to pin 13 whenever it receives an 'H' over its serial connection, and turn the LED off when it gets an 'L'. You can test it by connecting to the board with the SainSmart serial monitor (be sure it's set at 9600 baud), typing an H, and pressing enter (or clicking send). The LED should turn on. Send an L and the LED should turn off. If nothing happens, you may have an SainSmart board that doesn't have a built-in LED on pin 13. Once you've uploaded the Physical Pixel sketch and made sure that it's working, unplug the first SainSmart board from the computer. Switch the jumpers to the XBee setting (i.e. place each on the center pin and the pin farthest from the edge of the board). Now, you need to upload a sketch to the other board. Make sure its jumpers are in the USB setting. Then upload the following sketch to the board:

void setup()
{
Serial.begin(9600);
}
void loop()
{
Serial.print('H');
delay(1000);
Serial.print('L');
delay(1000);
}

When it's finished uploading, you can check that it's working with the SainSmart serial monitor. You should see H's and L's arriving one a second. Turn off the serial monitor and unplug the board. Switch the jumpers to the XBee setting. Now connect both boards to the computer. After a few seconds, you should see the LED on the first board turn on and off, once a second. (This is the LED on the SainSmart board itself, not the one on the XBee shield, which conveys information about the state of the XBee module.) If so, congratulations, your SainSmart boards are communicating wirelessly. This may not seem that exciting when both boards are connected to the same computer, but if you connect them to different computers (or power them with an external power supply - being sure to switch the power jumper on the SainSmart board), they should still be able to communicate.

Addressing

There are multiple parameters that need to be configured correctly for two modules to talk to each other (although with the default settings, all modules should be able to talk to each other). They need to be on the same network, as set by the ID parameter (see "Configuration" below for more details on the parameters). The modules need to be on the same channel, as set by the CH parameter. Finally, a module's destination address (DH and DL parameters) determine which modules on its network and channel will receive the data it transmits. This can happen in a few ways:

  • If a module's DH is 0 and its DL is less than 0xFFFF (i.e. 16 bits), data transmitted by that

module will be received by any module whose 16-bit address MY parameter equals DL.

  • If DH is 0 and DL equals 0xFFFF, the module's transmissions will be received by all modules.
  • If DH is non-zero or DL is greater than 0xFFFF, the transmission will only be received by the

module whose serial number equals the transmitting module's destination address (i.e. whose SH equals the transmitting module's DH and whose SL equals its DL).

Again, this address matching will only happen between modules on the same network and channel. If two modules are on different networks or channels, they can't communicate regardless of their addresses.

Configuring the XBee module You can configure the XBee module from code running on the SainSmart board or from software on the computer. To configure it from the SainSmart board, you'll need to have the jumpers in the Xbee position. To configure it from the computer, you'll need to have the jumpers in the USB configuration and have removed the microncontroller from your SainSmart board. To get the module into configuration mode, you need to send it three plus signs: +++ and there needs to be at least one second before and after during which you send no other character to the module. Note that this includes newlines or carriage return characters. Thus, if you're trying to configure the module from the computer, you need to make sure your terminal software is configured to send characters as you type them, without waiting for you to press enter. Otherwise, it will send the plus signs immediately followed by a newline (i.e. you won't get the needed one second delay after the +++). If you successfully enter configuration mode, the module will send back the two characters 'OK', followed by a carriage return.

Send Command Expected Response
+++ OK<CR>

Once in configuration mode, you can send AT commands to the module. Command strings have the form ATxx (where xx is the name of a setting). To read the current value of the setting, send the command string followed by a carriage return. To write a new value to the setting, send the command string, immediately followed by the new setting (with no spaces or newlines in-between), followed by a carriage return. For example, to read the network ID of the module (which determines which other XBee modules it will communicate with), use the 'ATID command:

Send Command Expected Response
ATID<enter> 3332<CR>

To change the network ID of the module:

Send Command Expected Response
ATID3331<enter> OK<CR>

Now, check that the setting has taken effect:

Send Command Expected Response
ATID<enter> 3331<CR>

Unless you tell the module to write the changes to non-volatile (long-term) memory, they will only be in effect until the module loses power. To save the changes permanently (until you explicitly modify them again), use the ATWR command:

Send Command Expected Response
ATWR<enter> OK<CR>

To reset the module to the factory settings, use the ATRE command:

Send Command Expected Response
ATWR<enter> OK<CR>

Note that like the other commands, the reset will not be permanent unless you follow it with the ATWR command.

Here are some of the more useful parameters for configuring your XBee module.

E212.jpg

Note: although the valid and default values in the table above are written with a prefix of "0x" (to indicate that they are hexadecimal numbers), the module will not include the "0x" when reporting the value of a parameter, and you should omit it when setting values.

Here are a couple more useful commands for configuring the Xbee module (you'll need to prepend AT to these too).

Command Description
RE Restore factory default settings (note that like parameter changes, this is not permanent unless followed by the WR command).
WR Write newly configured parameter values to non-volatile (long-term) storage. Otherwise,they will only last until the module loses power.
CN Exit command mode now. (If you don't send any commands to the module for a few seconds, command mode will timeout

and exit even without a CN command.)

API mode

As an alternative to Transparent Operation, API (Application Programming Interface) Operations are available. API operation requires that communication with the module be done through a structured interface (data is communicated in frames in a defined order). The API specifies how commands, command responses and module status messages are sent and received from the module using a UART Data Frame.

Jumper setting

The XBee shield has two jumpers (the small removable plastic sleeves that each fit onto two of the three pins labelled Xbee/USB). These determine how the XBee's serial communication connects to the serial communication between the microcontroller (ATmega8 or ATmega168) and FTDI USB-to-serial chip on the SainSmart board.

With the jumpers in the XBee position (i.e. on the two pins towards the interior of the board), the DOUT pin of the XBee module is connected to the RX pin of the microcontroller; and DIN is connected to TX. Note that the RX and TX pins of the microcontroller are still connected to the TX and RX pins (respectively) of the FTDI chip - data sent from the microcontroller will be transmitted to the computer via USB as well as being sent wirelessly by the XBee module. The microcontroller, however, will only be able to receive data from the XBee module, not over USB from the computer.

With the jumpers in the USB position (i.e. on the two pins nearest the edge of the board), the DOUT pin the XBee module is connected to the RX pin of the FTDI chip, and DIN on the XBee module is connected to the TX pin of the FTDI chip. This means that the XBee module can communicate directly with the computer - however, this only works if the microcontroller has been removed from the SainSmart board. If the microcontroller is left in the SainSmart board, it will be able to talk to the computer normally via USB, but neither the computer nor the microcontroller will be able to talk to the XBee module. Read the manual if you are going to use the API mode.

Using Series 2 ZB XBee’s Series 2 XBee's (ZigBee protocol) are quite different to 802.15.4 ones. ZigBee networks are called personal area networks or PANs. Each network is defined with a unique PAN identifier (PAN ID). XBee ZB supports both a 64-bit (extended) PAN ID and a 16-bit PAN ID. The 16-bit PAN ID is used in all data transmissions. The 64-bit PAN ID is used during joining, and to resolve 16-bit PAN ID conflicts that may occur. ZigBee defines three different device types: coordinator, router, and end devices.

E213.jpg

Coordinator

Selects a channel and PAN ID (both 64-bit and 16-bit) to start the network Can allow routers and end devices to join the network Can assist in routing data Cannot sleep--should be mains powered.

Router

Must join a ZigBee PAN before it can transmit, receive, or route data After joining, can allow routers and end devices to join the network After joining, can assist in routing data Cannot sleep--should be mains powered.

End device

Must join a ZigBee PAN before it can transmit or receive data Cannot allow devices to join the network Must always transmit and receive RF data through its parent. Cannot route data. Can enter low power modes to conserve power and can be battery-powered.

In ZigBee networks, the coordinator must select a PAN ID (64-bit and 16-bit) and channel to start a network. After that, it behaves essentially like a router. The coordinator and routers can allow other devices to join the network and can route data. After an end device joins a router or coordinator, it must be able to transmit or receive RF data through that router or coordinator. The router or coordinator that allowed an end device to join becomes the "parent" of the end device. Since the end device can sleep, the parent must be able to buffer or retain incoming data packets destined for the end device until the end device is able to wake and receive the data.