Development of a General Purpose XBee Series-2 APIMode Communication Library for LabVIEW

Michael Schell1 Mustafa G. Guvench2

Abstract The design project detailed in this paper focuses on the development of a modular toolset for working
with the XBee RF module from within the LabVIEW programming environment. The lack of generic LabVIEW
libraries for working with the popular XBee series-2 RF radio module makes wireless network software
development using this technology cumbersome and time-consuming. The outcome of this project is an efficient,
easy-to-use general purpose XBee communication library that allows LabVIEW developers to incorporate the
feature-rich API-mode operation of XBee RF modules into any network project with only a minimal amount of code
overhead.
Keywords: XBee, LabVIEW, API, Wireless, VISA

INTRODUCTION
At present, LabVIEW[1] provides no general purpose library of tools for working with one of the most popular
commercially available hardware solutions for building small-scale, low-power wireless networks Digi
Internationals XBee series-2 RF radio module[2]. This discovery was made by the author while working to redesign
wireless network hardware for a LabVIEW-based MEMS accelerometer test system developed by Dr. Mustafa
Guvench and his students at the University of Southern Maine[3]. One goal of this system redesign was replacement
of the existing wireless-USB network hardware with low-cost XBee Series 2B RF modules. A search of the
available LabVIEW XBee resources on the National Instruments Developer Zone website[4] (using XBee and
API search terms) returned only a handful of Virtual Instruments (VIs) created for working with XBee RF
modules. All of the available VIs were either too application specific to make code reuse feasible, and/or designed to
work only with the feature-limited XBee AT-mode.
The creation of control and measurement software designed to work with hardware-specific wireless networks is a
task well-suited to the hardware-oriented development environment of National Instruments (NI) LabVIEW
programming suite. Thus, failure to find suitable libraries for this test system redesign prompted the author to
develop a library of LabVIEW VIs to facilitate working with XBee RF modules. Although the development of these
VIs was undertaken with a specific project application in mind, the intent from the outset was to design for
maximum code reuse and generality. This paper outlines the design and development of this library.

TECHNOLOGY OVERVIEW
The following sections provide a brief background of the relevant aspects of Digi Internationals XBee wireless RF
module technology and National Instruments LabVIEW development suite.
XBee API Mode Operation [5]
Every XBee Series-2 radio module can operate in one of two interfacing modes AT mode or API mode. These
modes determine how the XBee RF module communicates with local hardware through the on-board UART. AT
mode (also called transparent mode) is a feature-limited mode that simplifies the interface between the XBee radio
and the hardware device at the expense of some local level control. In this mode, the XBee UART transmits and
receives all traffic as a simple serial byte stream. Escape characters can be used to issue basic commands, but
support for additional functionality such as multiple-radio addressing, I/O-pin sampling and remote configuration is

University of Southern Maine, Gorham, Maine 04038, mcschell@maine.rr.com

University of Southern Maine, Gorham, Maine 04038, guvench@usm.maine.edu

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

disabled. To enable these features an XBee module must be operating in API mode. In API mode, all data and
commands transmitted and received through the XBee UART are packaged as API frames. Each XBee API frame
follows a basic format and contains, at a minimum, a start delimiter, a frame type, a frame size, a 1-byte checksum
and the frame payload (data). This basic frame format is shown in Figure 1.

Figure 1: Basic XBee API frame structure[1]

The XBee API frame specification currently supports 19 distinct frame types. These frame types identify the specific
data contained within a frames payload section. Common frame types are serial transmit and receive frames, I/Opin sample frames, local & remote command request frames, and command acknowledgement frames.
Because API mode enables full control and configuration of the wireless network from a single XBee module, this
mode is typically used with an XBee coordinator radio. Every XBee network must contain one radio designated as a
coordinator. The coordinator radio acts as the network hub, managing all radio nodes and network traffic. This radio
is typically connected to a PC via a serial or USB port.
The LabVIEW VISA Standard[6]
When working with PC-connected hardware, National Instruments LabVIEW software suite is a popular choice for
developers. The LabVIEW environment provides developers with a data-flow oriented graphical programming
language designed specifically for hardware control and measurement applications. Applications are built using a
diagrammatic approach, with functional blocks interconnected by software wires. A graphical-user-interface for
each application can be created using a WYSIWYG editor, where various interface elements are positioned on a
front panel and then connected to functional blocks on the programming diagram. Taken together, the block diagram
code and the front panel GUI form a Virtual Instrument the code unit in LabVIEW (similar to a function in
traditional languages like C).
Among the tools available in LabVIEW for working with hardware devices is the Virtual Instrument Software
Architecture (VISA) library. The NI-VISA standard facilitates communication with a large variety of hardware
devices through high-level abstraction. This standard presents application developers with a common hardware
programming interface regardless of the underlying hardware interface (USB, GPIB, serial, etc.). Since the XBee RF
modules UART can be connected to the PC via a variety of hardware interfaces, the NI-VISA standard is wellsuited to the development of XBee-based network applications. This hardware interface flexibility was a motivating
factor in the selection of the LabVIEW design environment for this project. The rapid application development
nature of the LabVIEW IDE was another significant factor. Such factors make the utility of an easy-to-use, general
purpose LabVIEW XBee communication library obvious.

DEVELOPMENT OF THE XBEE COMMUNICATION LIBRARY

The XBee Communication Library developed in this project is comprised of a set of 22 Virtual Instruments. Two
VIs, the Serial TX and Serial RX Frame Processor VIs, provide the bulk of the librarys functionality. Nineteen
XBee API-frame- specific VIs are provided as supplementary libraries to aid top-level LabVIEW applications in the
construction and processing of frame-specific data. A final VI, the XBee Connection Manager VI, is provided as an
optional application. This VI can be used to simplify setup of generic XBee networks. The design and function of
each of these VIs is detailed in the following sections.
The Serial TX/RX Frame Processor VIs
The core functionality of the XBee API library is contained within only two of the librarys VIs: the Serial Receive
(RX) Frame Processor and the Serial Transmit (TX) Frame Processor. These VIs are designed to run in parallel,
both with one another and with the top-level user application. A basic diagram of the data flow for these VIs is
shown in Figure 2.

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

Figure 2: XBee Communication Library structure and data-flow

The Serial TX/RX Frame Processors handle all frame traffic between the user application and the XBee coordinator
radio. These two VIs are designed to be used conjunction with one or more of the frame-specific reader and builder
VIs provided for use within the top-level user applications these VIs simplify the process of building and reading
the specific API frames used by the XBee standard (see next section).
As shown in the diagram of Figure 2, the Serial RX Frame Processor VI intercepts all incoming serial traffic from
the XBee coordinator radio (via a PC hardware port). The purpose of this VI is to scan the serial input data stream
for API frame structures, processing these frames as they are found and then adding them to the RX Frame Queue.
Both the TX and RX Serial Frame Processor VIs are designed around a producer/consumer parallel loop
architecture. The LabVIEW block diagram code for the Serial RX Frame Processor is shown in Figure 3.

Figure 3:Block-diagram for the Serial RX Frame Processor VI

For the RX Processor VI, the producer loop (top of Figure 3) handles all incoming serial traffic by polling the serial
port and spooling all available data into a receive data queue. The consumer loop (bottom of Figure 3) executes in
parallel, waiting for data to be placed into the receive data queue by the producer loop. As receive data becomes
available to the consumer loop, the data is scanned for XBee API frames start delimiters (0x7E). Once a frame start
delimiter is found and verified, the frame data is transferred into a LabVIEW cluster variable (similar to the struct
custom data type in C). This cluster variable is defined using a structure matching that of the basic XBee API frame

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

layout shown in Figure 1, containing a field for the frame size, a field for the frame type, a byte array containing the
frame payload, and a boolean field indicating the checksum pass/fail condition. After each of these frame clusters
has been built by the consumer loop it is added to the RX Frame Queue. Other than error-flow outputs, the RX
Frame Queue is the only output exposed to the top-level user application.
The primary benefit of this producer-consumer parallel loop structure is that it allows the processing of frame data to
occur at a rate slower than the serial receive rate for a short period of time. This can be an important in large
networks where it is possible for many API frames to arrive at the hardware port nearly simultaneously. In such a
situation, timely processing of the available serial data is necessary to ensure that no overflow occurs at the
hardware port buffer. By using the producer loop to spool incoming serial data into a simple byte queue, the
consumer loop can process the frame data from this queue using more time-intensive code (e.g. checksum
calculation). In many XBee applications network activity will occur in bursts. Ideally, this should allow the
consumer loop to eventually empty the receive data queue during periods of low network activity. This buffering,
combined with the typical buffering that already exists at the OS-hardware level, should suffice for most XBee
network applications. If more (or less) buffering is required, users can adjust the default size of the Serial RX Frame
Processor VIs internal receive data queue to suit the needs of the specific application.
The Serial TX Frame Processor VI is functionally similar to the receive processor VI, except the data flow is
reversed (from application to serial port refer to the flow diagram of Figure 2). As with the receive processor, a
producer-consumer loop structure is employed to decouple processing of basic frame data from serial data
transmission. Here, however, a TX Frame Queue is exposed to the top-level user application. As frame clusters to be
transmitted to the XBee coordinator radio are placed into the TX Frame Queue by the user application they are
flattened into byte arrays and spooled into a transmit data queue by the producer loop. The consumer loop then
streams these bytes to the hardware port as they become available. As with the Serial RX Frame Processor, this
parallel architecture allows a mismatch of frame processing and hardware transmission rates to occur; however, this
situation is less common on the transmit side as only one device is sending frames through the XBee coordinator
radios UART.
With both the TX and RX Frame Processors, the serial port data processing and frame assembly routines are fully
encapsulated. Only the RX and TX Frame Queues are exposed to the top-level user application. After the user has
supplied the frame processor VIs with a valid hardware port reference (i.e. a port connected to the coordinator
radio), the Frame Processor VIs will manage all traffic to and from that port. To transmit a frame the user
application simply adds the frame cluster to the TX Frame Queue. Likewise, to read a frame from the network the
user simply monitors the RX Frame Queue for new frame clusters.
As detailed earlier, all frames placed into the TX and RX Frame Queues are LabVIEW clusters based on the generic
XBee API frame structures containing only fields for frame type, frame size, checksum status, and a byte array of
raw frame data. Detailed processing of specific API frame types is not handled by the TX and RX Frame Processor
VIs. In most XBee applications, only a handful of the 19 currently defined frame types are regularly used; transmit
and receive data frames, local and remote command frames, I/O-pin sample frames and command response frames
are the most commonly used XBee API frame types. By processing only the essential elements of every incoming
XBee API frame i.e. length, type and checksum and leaving frame payload data in its raw, unprocessed form, the
RX Frame Processor VI can remain small, fast and efficient. When the user application queries the frame type field
of a frame cluster present in the RX Frame Queue a decision can then be made whether to discard the frame or
process its data payload (to extract frame specific data of interest to the particular application). For similar reasons,
the TX Frame Processor VI assumes that all frames in the TX Frame Queue are formatted as generic frame clusters
i.e. that each frame has been packed prior to being added to the queue. This allows the VI to handle each frame
identically with no case-specific processing. The next section details how top-level applications can use the XBee
Communication Librarys supplementary VIs to handle processing of specific frame payloads.
Frame Builder VIs & Frame Reader VIs
To assist users in working with specific frame types, a set of supplementary Frame Builders VIs and Frame Reader
VIs were also developed as part of the XBee Communication Library. Frame Builder VIs are used to generate the
various transmission frame types (e.g. remote command requests, serial TX data, etc.), while Frame Reader VIs are
used to extract data from the various receive frame types (e.g. command acknowledgements, I/O-pin samples, serial
RX data, etc.). These VIs are used in conjunction with the TX/RX Frame Queues exposed to the top-level
application by the Serial TX/RX Frame Processor VIs. When a user application finds a frame of interest in the RX
Frame Queue the frame cluster can be removed from the queue and passed to a Frame Reader VI. These reader VIs

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

will unpack the payload data for a given frame type and make each element available, in the appropriate data format,
at the output terminals of the VI. Frame Builder VIs function in the opposite fashion here the user application
supplies the VIs input terminals with all individual data elements required for a particular frame type. The VI will
then pack the elements into the payload format for the specific frame type, generate the frame header and checksum
and make the generic frame cluster available at the VIs output terminal. This frame cluster can then be added to the
TX Frame Queue for automatic transmission to the XBee coordinator radio.
The LabVIEW block diagram code of a simple Frame Builder VI is shown in Figure 4. This specific Frame Builder
VI builds Local Command Request frames (API frame type 0x08). The top-level user application supplies the input
terminals of this VI (left side of diagram) with a frame ID, an AT command string (two character op-code), and a
parameter value for the AT command. The Frame Builder VI packages these inputs into a frame cluster according to
the XBee API Frame specification for this frame type and calculates the checksum for this generated frame. The
output terminal of this VI (right side of diagram) will provide the assembled frame cluster to the top-level
application. This frame cluster can then be added directly to the TX Frame Queue (for transmission).

Figure 4: Block-diagram for a Frame Builder VI (0x08 Local Command Frame)

XBee Serial Connection Manager VI

The final portion of XBee Communication Library is the XBee Serial Connection Manager VI. This VI is an
optional component designed to aid user applications in establishing an XBee network from within LabVIEW. This
VI is also the only component in the library to utilize a front-panel graphical-user-interface (GUI). The GUI for this
VI is shown in Figure 5.

Figure 5: XBee Serial Connection Manager Front

Panel

2012 ASEE Northeast Section Conference

Reviewed Paper

Figure 6: Flow Diagram for XBee Connection Manager

University of Massachusetts Lowell

April 27-28, 2012

The connection manager handles five network connection tasks, illustrated in Figure 6 and detailed below.
1. Hardware Port Initialization Using the serial connection information provided by the user (on the front panel)
the VI attempts to open a VISA serial connection to the specified hardware port using the provided serial connection
settings.
2. Start TX and RX Frame Processors With a hardware port connection established, the connection manager
passes the VISA hardware reference to the TX and RX Frame Processor VIs to enable the XBee TX/RX Frame
Queues and start hardware port traffic monitoring and processing.
3. Coordinator Radio Reset and Verification After successfully opening the serial port and starting the Serial
TX/RX Frame Processors, the VI sends a Local Command frame (0x08) containing the XBee Software Reset
command (FR) to the serial port and waits for reset acknowledgement from the XBee coordinator radio.
4. Ping Network Radios After the coordinator has successfully reset, a second AT Local Command frame is sent
containing the Node Discovery command (ND). This command requests an identifier response from every radio
on the XBee network including the coordinator. Once the Node Discovery command has been issued, the connection
manager will idle. The application continues to monitor the input serial stream for radio identifier frames (frame
type 0x88). As each identifier frame is received, radio information is added to a network list array.
5. Hand-off Control to User Application When the user presses the Start Application button the connection
manager passes control to the user specified VI. Along with execution control the connection manager passes a
VISA reference to the hardware port connection and references to the TX/RX Frame Queues. Also passed is an
array of network radio information, containing the name, type and address of all radios found on the network.
Although the XBee Serial Connection Manager VI contains a GUI that can be used as the starting point for any user
application, all necessary front-panel controls and indicators for this VI are also connected to input and output
terminals for the VIs function block. This allows users to invoke the connection manager from a top-level
application without displaying the GUI instead using the input terminals to pass in front-panel control values (e.g.
for automated network setup).

EXAMPLE APPLICATION OF THE XBEE COMMUNICATION LIBRARY

In this section, two simplified LabVIEW block diagram code examples are provided to illustrate ways in which the
XBee Communication Library can be integrated into a top-level user application. The first example gives a typical
structure for working with received XBee API frames. The second example gives a typical structure for transmitting
XBee API frames.
Example 1 Working with Received XBee API Frames
Figure 7 shows a simplified LabVIEW structure for working with received API frames using the XBee
Communication Library.

Figure 7: Example 1 simplified block-diagram for a typical receive frame structure

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

To the left of the while-loop structure in the diagram, the Serial RX Frame Processor VI has been provided with two
inputs a reference to the RX Frame Queue and a valid reference to the XBee coordinator radios hardware port.
This is all that is required from the user application to begin receiving frames from the XBee network. Note that the
Serial RX Frame Processor is not placed in-line with the XBee RX Frame Queue data line. This ensures that the
frame processor VI will execute in parallel with the user application (preventing blocking due to LabVIEWs dataflow execution format).
The while-loop structure is used to create a simple frame listener. In this loop the RX Frame Queue is polled. If no
frame is present in the RX Frame Queue the Dequeue function block will timeout after 500 milliseconds and the
loop will repeat. If a frame cluster is successfully Dequeued from the RX Frame Queue the clusters Frame Type
field is checked by a case structure. In the example code above, the code for case 0x88 is shown this frame type
corresponds to a Command Response Frame. When a matching frame type is found in the RX Frame Queue the
code for this case will execute. Here, a Frame Reader VI (for frame type 0x88) is used to break the command
response frame into its constituent parts (Frame ID, AT Command, etc.) In a practical example these frame
elements would be further processed according to the specific function of the application. Additional cases for other
frame types can be added to the case structure as well, allowing the case structure to individually process any and all
receive frame types of importance to the given application.
Example 2 Working with XBee Transmit API Frames
Figure 8 shows a simplified LabVIEW structure for working with transmit API frames using the XBee
Communication Library.

Figure 8: Example 2 simplified block-diagram for a typical transmit frame structure

In this example, setup for the Serial TX Frame Processor VI is identical to the setup of the Serial RX Frame
Processor Inputs to the Serial TX Processor VI are a reference to the TX Frame Queue and a valid reference to the
XBee coordinator radios hardware port. This is all that is required from the user application to begin transmitting
frames to the XBee coordinator. As with the RX processor, the Serial TX Frame Processor is not placed in-line with
the XBee TX Frame Queue data line. Once the Serial TX Processor has been started it will monitor the TX Frame
Queue for frame clusters and transmit them to the hardware port (i.e. network) as they are added to the queue. For
this example, a Local Command Request frame (0x08) has been built with supplied user data and the appropriate
Frame Builder VI. This output frame cluster is then added to the TX Frame Queue for transmission.

CONCLUSION
The XBee Communication Library developed in this design project provides an easy to use, general purpose set of
tools for building XBee API-based network applications using NIs LabVIEW development software. By employing
the simple TX/RX queue-based approach used in this library, LabVIEW developers can add XBee wireless network
functionality to their hardware control and measurement projects without incurring the significant overhead
previously required to integrate this technology into the LabVIEW design environment. This frees designers to focus
on the particulars of their XBee-based application without getting bogged down in the details of the underlying
XBee network and software/hardware interfacing. The modular approach of breaking-out frame specific processing
code into a set of targeted VIs also keeps the core functionality of this library simple and efficient making it suitable
for applications where speed and reliability are a concern. Finally, by building these tools within the LabVIEW
environment itself, every part of the XBee Communication Library is easy to access and fully customizable by the
user for integration into any application specific XBee-based LabVIEW project.

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012

ACKNOWLEDGEMENTS
Funding for this project was generously provided in part by NASA and the Maine Space Grant Consortium. Testing
and development of the communication library for this project were made possible by University of Southern Maine
alumni Greg Mitchell and Steve Coleman, who developed the original accelerometer hardware test platform that
formed the basis for this redesign project [4]. Upgrades to this hardware platform, including a PC-based rotational
control system, were completed by current engineering student David Carlson. These upgrades made accurate and
timely testing of this projects communication library possible.

REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]

What Is NI LabVIEW, http://www.ni.com/labview/whatis/, National Instruments, 2012.

XBee & XBee PRO ZB, http://www.digi.com/pdf/ds_xbeezbmodules.pdf, Digi International, 2011.
Coleman, Steve, Greg Mitchell and M.G. Guvench, PC Controlled Testing Platform for MEMS Capacitance
and Acceleration Sensing Abstracts of ASEE New England Conference, Bridgeport, Conn., 2008.
NI Developer Zone, http://zone.ni.com/dzhp/app/main, National Instruments, 2012.
API Operation, XBee/XBee-PRO ZB RF Modules, Digi International, 2010, 99.
NI VISA Help, National Instruments, 2011.

Michael Schell
Michael Schell is an undergraduate student majoring in Electrical Engineering at the University of Southern Maine.
While at the University of Southern Maine he has worked as an independent research assistant aiding Professor
Mustafa G. Guvench with his research into the testing and development of high-frequency, MEMS-based vibration
sensors for ultrasonic leak-detection on NASA inflatable lunar structures. Michaels undergraduate concentration is
in the area of computer engineering, with a focus on embedded systems and algorithm design. In the fall of 2012
Michael will be continuing his academic coursework as a graduate student at the University of Maine studying under
Dr. Ali Abedi of the Electrical and Computer Engineering department. Michael can be reached at
mcschell@maine.rr.com.
Dr. Mustafa G. Guvench
Dr. Guvench received M.S. and Ph.D. degrees in Electrical Engineering and Applied Physics from Case Western
Reserve University. He is currently a full professor of Electrical Engineering at the University of Southern Maine.
Prior to joining U.S.M. he served on the faculties of the University of Pittsburgh and M.E.T.U., Ankara, Turkey. His
research interests and publications span the field of microelectronics including I.C. design, MEMS and
semiconductor technology and its application in sensor development, finite element and analytical modeling of
semiconductor devices and sensors, and electronic instrumentation and measurement. He can be reached at
guvench@usm.maine.edu.

2012 ASEE Northeast Section Conference

Reviewed Paper

University of Massachusetts Lowell

April 27-28, 2012