This manual describes the operation of the XBee® Wi-Fi RF module, which consists of 802.11 bgn firmware loaded
onto XBee® hardware. The XBee® Wi-Fi RF Modules are designed to operate within the 802.11 protocol and
support the unique needs of low-cost, low-power wireless sensor networks. The modules require minimal power
and provide reliable delivery of data between remote devices and wireless 802.11 b, g or n access points and
routers. The modules operate within the ISM 2.4 GHz frequency band.
Digi International Inc.
11001 Bren Road East
Minnetonka, MN 55343 877 912-3444 or 952 912-3444
No part of the contents of this manual may be transmitted or reproduced in
any form or by any means without the written permission of Digi
International, Inc.
XBee® is a registered trademark of Digi International, Inc.
Technical Support Phone: (866) 765-9885 toll-free U.S.A. & Canada
(801) 765-9885 Worldwide
8:00 am - 5:00 pm [U.S. Mountain Time]
Online Support: http://www.digi.com/support/eservice/login.jsp
Email: rf-experts@digi.com
7. API Operation ................................................................................................................................... 42
API Frame Specifications .................................................................................................................. 42
API UART and SPI Exchanges ............................................................................................................ 45
AT Commands ............................................................................................................................... 45
Transmitting and Receiving RF Data ............................................................................................. 45
Remote AT commands ................................................................................................................. 46
The XBee® Wi-Fi RF module provides wireless connectivity to end-point devices in 802.11 bgn
networks. Utilizing the 802.11 feature set, these modules are interoperable with other 802.11
bgn devices, including devices from other vendors. With XBee, users can have their 802.11 bgn
network up-and running in a matter of minutes.
The XBee® Wi-Fi modules are compatible with other devices that use 802.11 bgn technology.
These include Digi external 802.11x devices like the ConnectPort and the Digi Connect Wi-SP, as
well as embedded products like the ConnectCore series and Digi Connect series of products.
More information on these Digi products can be found at:
The XBee Wi-Fi RF modules support both UART (Universal Asynchronous Receiver/Transmitter)
and SPI (Serial Peripheral Interface, in master or slave mode) serial connections.
UART
More information on UART operation is found in the UART section in chapter 2.
SPI
The SC2 (Serial Communication Port 2) of the module is connected to the SPI port.
SPI Pin Assignments
XBee® Wi-Fi RF Modules
For more information on SPI operation see the SPI section in chapter 2.
0.5 mA drive strength and load
capacitance CL=12.5-25pF.
20+0.1CL
250
ns
2 mA drive strength and load
capacitance CL=350-600pF.
20+0.1CL
250
ns
I/O pin hysteresis (VIOTHR+ Viothr-)
VDD=3 to 3.6V
0.1VDD
V
Pulse width of pulses to be
removed by the glitch
suppression filter
10 50
ns
GPIO Specifications
The XBee Wi-Fi modules have 14 GPIO (General Purpose Input Output) ports available. Those
available will depend on the module configuration as some GPIO’s are consumed by serial
communication, etc.
See GPIO section for more information on configuring and using GPIO ports
The XBee modules do not specifically require any external circuitry or specific connections for
proper operation. However, there are some general design guidelines that are recommended
for help in troubleshooting and building a robust design.
Power Supply
Poor power supply can lead to poor radio performance especially if the supply voltage is not
kept within tolerance or is excessively noisy. To help reduce noise a 1uF and 8.2pF capacitor
are recommended to be placed as near to pin 1 on the PCB as possible. If using a switching
regulator for your power supply, switching frequencies above 500 kHz are preferred. Power
supply ripple should be limited to a maximum 50mV peak to peak.
Typical start up current for the module is shown in the graph below:
Due to the fast nature of the current peaks, it is recommended that at least a 500uF capacitor
be placed on the VCC line. This will enable the XBee to start up with an acceptable voltage
slump in the power supply.
Recommended Pin Connections
The only required pin connections are VCC, GND, and either DOUT and DIN or SPI_CLK,
SPI_SSEL, SPI_MOSI, and SPI MISO. To support serial firmware updates, VCC, GND,
DOUT, DIN, RTS, and DTR should be connected.
All unused pins should be left disconnected. All inputs on the radio can be pulled high
with 30k internal pull-up resistors using the PR software command. No specific
treatment is needed for unused outputs.
The radios are also designed to be self sufficient and work with the integrated and
XBee® Wi-Fi RF Modules
For applications that need to ensure the lowest sleep current, inputs should never be
left floating. Use internal or external pull-up or pull-down resistors, or set the unused
I/O lines to outputs.
Other pins may be connected to external circuitry for convenience of operation
including the Associate pin (pin 15) and the On_nSLEEP pin (pin 13) will change level or
behavior based on the state of the module.
XBee modules do not have any specific sensitivity to nearby processors, crystals or other
PCB components. Other than mechanical considerations, no special PCB placement is
required for integrating XBee radios except for those with integral antennas. In general,
Power and GND traces should be thicker than signal traces and be able to comfortably
support the maximum currents.
external antennas without the need for additional ground planes on the host PCB.
However, considerations should be taken on the choice of antenna and antenna
location. Metal objects that are near an antenna cause reflections and may reduce the
ability for an antenna to efficiently radiate. Using an integral antenna in an enclosed
metal box will greatly reduce the range of a radio. For this type of application an
external antenna would be a better choice.
External antennas should be positioned away from metal objects as much as possible.
Metal objects next to the antenna or between transmitting and receiving antennas can
often block or reduce the transmission distance. Some objects that are often overlooked
are metal poles, metal studs or beams in structures, concrete (it is usually reinforced
with metal rods), metal enclosures, vehicles, elevators, ventilation ducts, refrigerators
and microwave ovens.
Antennas should reside above or away from any metal objects like batteries, tall
electrolytic capacitors or metal enclosures. Antenna elements radiate perpendicular to
the direction they point. Thus a vertical antenna emits across the horizon.
PCB Antennas should not have any ground planes or metal objects above or below the
module at the antenna location. For best results the module should be in a plastic
enclosure, instead of metal one. It should be placed at the edge of the PCB to which it is
mounted. The ground, power and signal planes should be vacant immediately below the
antenna section (See drawing for recommended keep out area).
XBee modules were designed to mount into a receptacle (socket) and therefore do not require
any soldering when mounting to a board. The XBee Wi-Fi Development Kits contain 2 USB
interface boards which use two 10-pin receptacles to receive modules.
The receptacles used on Digi development boards are manufactured by Century Interconnect.
Several other manufacturers provide comparable mounting solutions; however, Digi currently
uses the following receptacles:
Surface-mount single-row receptacles - Samtec P/N: SMM-110-02-SM-S
Digi also recommends printing an outline of the module on the board to indicate the
The XBee RF Modules interface to a host device through a logic-level asynchronous serial port, or
a Serial Peripheral Interface (SPI) port. Through its serial ports, the module can communicate
with any logic and voltage compatible UART or SPI; or through a level translator to any serial
device (for example: through a RS-232 or USB interface board).
UART Communications
UART Data Flow
Devices that have a UART interface can connect directly to the pins of the RF module as shown in
the figure below.
UART Serial Data
Data enters the module UART through the DIN (pin 3) as an asynchronous serial signal. The signal
should idle high when no data is being transmitted.
Each data byte consists of a start bit (low), 8 data bits (least significant bit first) and a stop bit
(high). The following figure illustrates the serial bit pattern of data passing through the module.
Serial communications depend on the two UARTs (the microcontroller's and the RF module's) to
be configured with compatible settings (baud rate, parity, start bits, stop bits, data bits).
The UART baud rate, parity, and stop bits settings on the XBee module can be configured with
the BD, NB, and SB commands respectively. See the command table in chapter 10 for details.
The XBee Wi-Fi module supports SPI communications in the slave mode. Slave mode receives the clock signal
and data from the master and returns data to the master. The SPI port uses the following signals on the XBee:
SPI_MOSI (Master Out, Slave In) – inputs serial data from the master
SPI_MISO (Master In, Slave Out) – outputs serial data to the master
SPI_SCLK (Serial Clock) – clocks data transfers on MOSI and MISO
SPI_nSSEL (Slave Select) – enables serial communication with the slave
SPI_nATTN(Attention) – Alerts the master that slave has data queued to send. The XBee module will
assert this pin as soon as data is available to send to the SPI master and it will remain asserted until
the SPI master has clocked out all available data.
In this mode the following apply:
SPI Clock rates up to 3.5MHz are possible.
Data is MSB first
Frame Format mode 0 is used. This means CPOL=0 (idle clock is low) and CPHA=0 (data is sampled on
the clock’s leading edge). Mode 0 is diagramed below.
SPI port is setup for API mode and is equivalent to AP=1.
Frame Format for SPI communications
SPI mode is chip to chip communication. Digi does not supply SPI communication option on the Device
Development Evaluation Boards.
SPI mode is enabled by holding DOUT/DIO13 (pin 2) low while resetting the module until SPI_nATTN
asserts. By this means, the XBee Wi-Fi module will disable the UART and go straight into SPI
communication mode. Once configuration is completed, a modem status frame is queued by the module
to the SPI port which will cause the SPI_nATTN line to assert. The host can use this to determine that the
SPI port has been configured properly. This method internally forces the configuration for the AP, D2, D3,
D4, D9, and P2 commands as needed for SPI operations. As long as a WR command is not issued, these
configuration values will revert back to previous values after a power on reset. If, on the other hand, a
WR command is issued while in SPI mode, these same parameters will be written to flash. It is then the
user’s responsibility to set these parameters as appropriate
When the slave select (SPI_nSSEL) signal is asserted by the master, SPI transmit data is driven to the
output pin SPI_MISO, and SPI data is received from the input pin SPI_MOSI. The SPI_nSSEL pin has to be
asserted to enable the transmit serializer to drive data to the output signal SPI_MISO. A falling edge on
SPI_nSSEL causes the SPI_MISO line to be tri-stated such that another slave device can drive it, if so
desired..
If the output buffer is empty, the SPI serializer transmits the last valid bit repeatedly, which may be either
high or low. Otherwise, the module formats all output in API mode 1 format, as described in chapter 7.
The attached host is expected to ignore all data that is not part of a formatted API frame.
Serial Buffers
The XBee modules maintain buffers to collect received serial and RF data, which is illustrated in the figure
below. The serial receive buffer collects incoming serial characters and holds them until they can be
processed. The serial transmit buffer collects data that is received via the RF link that will be transmitted out
the UART or SPI port
Serial Receive Buffer
When serial data enters the RF module through the DIN Pin (or the MOSI pin), the data is stored in the
serial receive buffer until it can be processed. Under certain conditions, the module may not be able to
process data in the serial receive buffer immediately. If large amounts of serial data are sent to the
module such that the serial receive buffer would overflow, then the new data will be discarded. If the
UART is in use, this can be avoided by the host side honoring CTS flow control.
Serial Transmit Buffer
When RF data is received, the data is moved into the serial transmit buffer and sent out the UART or SPI
port. If the serial transmit buffer becomes full and system buffers are also full, then the entire RF data
packet is dropped. Whenever data is received faster than it can be processed and transmitted out the
serial port, there is a potential of dropping data, even in TCP mode.
UART Flow Control
The nRTS and nCTS module pins can be used to provide RTS and/or CTS flow control. CTS flow control
provides an indication to the host to stop sending serial data to the module. RTS flow control allows the
host to signal the module to not send data in the serial transmit buffer out the UAR. RTS and CTS flow
control are enabled using the D6 and D7 commands.
The FT command allows the user to specify how many bytes of data can be queued up in the serial
transmit buffer before the module asserts CTS low. The serial receive buffer can hold up the 2100 bytes,
but FT cannot be set any larger than 2083 bytes, leaving 17 bytes that can be sent by the host before the
data is dropped.
By default, FT is 2035 (0x7F3), which allows the host to send 65 bytes to the module after the module
asserts CTS before the data is dropped.
In either case, CTS will not be re-asserted until the serial receive buffer has FT-17 or less bytes in use.
nRTS Flow Control
If RTS flow control is enabled (D6 command), data in the serial transmit buffer will not be sent out the
DOUT pin as long as nRTS is de-asserted (set high). The host device should not de-assert nRTS for long
periods of time to avoid filling the serial transmit buffer. If an RF data packet is received, and the serial
transmit buffer does not have enough space for all of the data bytes, the entire RF data packet will be
discarded.
Note: If RTS flow control is enabled and the XBee is sending data out the UART when nRTS is de-asserted
(set high), the XBee could send up to 4 characters out the UART to clear its FIFO after nRTS is de-asserted.
This implies that the user needs to de-assert nRTS by the time its receive capacity is within 4 bytes of full.
Serial Interface Protocols
The XBee modules support both transparent and API (Application Programming Interface) serial
interfaces.
Transparent Operation
When operating in transparent mode, the modules act as a serial line replacement. All UART
data received is queued up for RF transmission. When RF data is received, the data is sent out
through the UART. The module configuration parameters are configured using the AT command
mode interface. Please note that transparent operation is not an option when using SPI.
Data is buffered in the serial receive buffer until one of the following causes the data to be
packetized and transmitted:
No serial characters are received for the amount of time determined by the RO
parameter. If RO is zero, data is packetized as soon as it is received, without delay.
If RO is non-zero, the data is packetized after RO character times of no transitions
on the DIN pin. However, if the time required for RO characters is less than 100
microseconds, then DIN must still be idle for at least 100 microseconds, which is the
minimal idle time required for packetizing packets at any baud rate.
The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in
the serial receive buffer before the sequence is packetized and transmitted before
command mode is entered.
The maximum number of characters that will fit in an RF packet is received.
All received serial data is transmitted unless the module is in command mode.
Easy to support
It is easier for an application to support transparent operation and command mode.
API Operation Features
Easy to manage data
transmissions to multiple
destinations
Transmitting RF data to multiple remotes only requires changing the address in the
API frame. This Process is much faster than transparent operation where the
application must enter AT command mode, change the address, exit command mode,
and then transmit data. Each API transmission can return a transmit status frame
indicating the success or reason for failure
Received data frames
indicate the sender's
address
All received RF data API frames indicate the source address.
Advanced Networking
diagnostics
API frames can provide indication of IO samples from remote devices, transmission
status messages, and local radio status messages.
API Operation
API operation is an alternative to transparent operation. The frame-based API extends the level
to which a host application can interact with the networking capabilities of the module. When in
API mode, all data entering and leaving the UART or SPI is contained in frames that define
operations or events within the module.
Transmit Data Frames (received through the DIN pin (pin 3) or SPI_MOSI (pin 11 )) include:
RF Transmit Data Frame
Local commands (equivalent to AT commands)
Remote commands to be sent to another radio
Receive Data Frames (sent out the DOUT pin (pin 2) or SPI_MISO (pin 4 )) include:
RF-received data frames
Local command responses
Remote command responses
I/O samples from a remote radio
Event notifications such as transmission status, reset, associate, disassociate, etc.
The API provides an alternative means of configuring modules and of routing data at the local
host application layer. A local host application can send data frames to the module that contain
address and payload information instead of using command mode to modify addresses. The
module will send data frames to the application containing status packets; as well as source, and
payload information from received data packets. The API operation option facilitates many
operations such as the examples cited below:
Transmitting data to multiple destinations without entering Command Mode
Receive success/failure status of each transmitted RF packet
Identify the source address of each received packet
A Comparison of Transparent and API Operation
The following table compares the advantages of transparent and API modes of operation:
Set/read configuration commands can be sent to remote devices to configure them
as needed using the API.
As a general rule of thumb, API firmware is recommended when a device:
If the above conditions do not apply, (e.g. in a sensor node, or a simple application) then
transparent operation might be suitable. It is acceptable to use a mixture of devices
running API mode and transparent mode in a network.
Modes of Operation
Idle Mode
When not receiving or transmitting data, the RF module is in Idle Mode. The module
shifts into the other modes of operation under the following conditions:
XBee® Wi-Fi RF Modules
sends RF data to multiple destinations
sends remote configuration commands to manage devices in the network
receives IO samples from remote devices
receives RF data packets from multiple devices, and the application needs to
know which device sent which packet
Transmit Mode (Serial data in the serial receive buffer is ready to be packetized)
Receive Mode (Valid RF data is received through the antenna)
Sleep Mode
Command Mode (Command Mode Sequence is issued)
Transmit Mode
When serial data is received and is ready to be packetized, the RF module will exit Idle
Mode and attempt to transmit the data. The destination address determines which
node(s) will receive the data.
Receive Mode
If a valid RF packet is received, the data is transferred to the serial transmit buffer.
Command Mode
To modify or read RF Module parameters, the module must first enter into Command
Mode - a state in which incoming serial characters are interpreted as commands. Refer
to the API Operation chapter for an alternate means of configuring modules, which is
the only method available for SPI mode. (Command mode is unavailable when using the
SPI interface.)
AT Command Mode
To Enter AT Command Mode:
Send the 3-character command sequence “+++” and observe guard times before and
after the command characters. [Refer to the “Default AT Command Mode Sequence”
below.]