The XBee is a wireless transciever produced by Digi International. There are multiple different versions of the XBee and they each serve a unique purpose. XBees are built to communicate over a specific type of network, such as WiFi or Digi's own ZigBee protocol. Our lab primarily uses Series 2 XBees that use the ZigBee protocol. Any references to XBees in this guide will be references to Series 2 XBees using the ZigBee protocol.

XBees have two modes of operation, AT and API. AT mode is synonymous with “transparent” mode. When you write a payload (the data you want to send, ie sensor readings) to the serial line, the XBee will immediately send that payload to the corresponding XBee. If you read from the serial line connected to the receiving XBee you should see that same payload that you wrote initially.

AT mode is simple and easy to use. Unfortunately, there are some downsides to AT mode. One issue is that there is no way to confirm whether or not data was received successfully. Once the payload is transmitted, the transmitting XBee will not know if the corresponding XBee received the complete payload, or even if it received any data at all. Likewise, the XBee that was supposed to receive the payload will not know if the payload it receives is correct. Another shortcoming of AT mode is that XBees may only engage in 1 to 1 communication. A network with more than 2 nodes cannot be established in AT mode.

API mode is not as simple as AT mode, but it is much more powerful. By using API mode, XBees can automatically verify that data has been received successfully, and they will attempt to re-transmit data if a transmission was unsuccessful. XBees using API mode can also be used in networks with several nodes. After they are appropriately configured, the XBees will automatically create and maintain a network. Details on XBee configuration will be discussed in a later section. Other details on API mode and how it works are described in the datasheet.

To transmit a payload in API mode, the payload must be wrapped in a frame with network and packet information. Received packets are also read in as an API frame which includes network and packet information surrounding the payload. Details regarding the frame structure are found in the datasheet. Fortunately, there are pre-existing libraries for the Arduino, as well as Python and other languages, which make the use of API mode much simpler.

Read here for a brief overview of XBee node types: http://ftp1.digi.com/support/documentation/html/90001399/90001399_A/Files/XBee-concepts.html#_Toc384719513 Refer to the datasheet for more information.

Each network requires at least one coordinator to maintain the network. Other nodes on the network can either be routers or end devices. In our lab, the coordinator is connected to the server/base station, while the data-collection nodes (eg. weatherboxes) are typically routers.

XBees transmit and receive data through a serial bus, so they can communicate with both computers and microcontrollers. To use XBees with a computer members of our lab typically use a XBee USB explorer board or an XBee adapter board that is compatible with an FTDI to USB converter. To use an XBee with a microcontroller you must connect the XBee to its UART lines(Tx and Rx) as well as power and ground. XBees typically require 3.3V, and although some do tolerate up to 5V, that is not always the case. Make sure that the voltage you supply is acceptable.

Note that the Arduino requires Tx and Rx when it is being programmed through USB. The XBee cannot be connected to the hardware serial lines when the Arduino is being programmed.

X-CTU is a software application which allows the user to configure the XBees, send/receive data, and more.

baud rate, serial port

node type, addressing, pan id

reset, save/load

serial monitor

X-CTU Download
Using X-CTU

acknowledgement packets, buffer size, packet size, sleep mode, io pins,

Datasheet

Contributing authors:

Created by zdorman on 2016/03/03 00:13.