Implementción de XBee Serie 2 API en LabView

8/10/2019 Implementcin de XBee Serie 2 API en LabView

1/8

2012 ASEE Nor theast Section Conference Un iversity of Massachusetts Lowell

Reviewed Paper Apr i l 27-28, 2012

Development of a General Purpose XBee Series-2 API-

Mode Communication Library for LabVIEWMichael Schell

1 Mustafa G. Guvench

2

AbstractThe design project detailed in this paper focuses on the development of a modular toolset for workingwith 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 networksDigi

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 atask 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. ATmode (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

1University of Southern Maine, Gorham, Maine 04038,[email protected] of Southern Maine, Gorham, Maine 04038,[email protected]
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/8



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 framespayload section. Common frame types are serial transmit and receive frames, I/O-

pin 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 radiois 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 interconnectedby 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 well-

suited 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 theconstruction 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.


3/8



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


4/8



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 asituation, 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 VIsinternal 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 portrefer 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 areflattened 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

radiosUART.

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 hardwareport 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 genericXBee API frame structurescontaining 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 framei.e. length, type and checksumand 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 VIsto 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


5/8



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 terminalswith 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 VIsoutput 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 BuilderVI 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 anoptional 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

Figure 6: Flow Diagram for XBee Connection Manager


6/8



The connection manager handles five network connection tasks, illustrated in Figure 6 and detailed below.

1. Hardware Port InitializationUsing 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 ProcessorsWith 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 VerificationAfter 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 RadiosAfter 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 ApplicationWhen the user presses the Start Applicationbutton 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 anarray 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 GUIinstead 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 1Working 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 1simplified block-diagram for a typical receive frame structure


7/8



To the left of the while-loop structure in the diagram, the Serial RX Frame Processor VI has been provided with two

inputsa 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 data-

flow execution format).

The while-loop structure is used to create a simple frame listener. In this loop the RX Frame Queue is polled. If noframe 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 clustersFrame Type

field is checked by a case structure. In the example code above, the code for case 0x88 is shownthis 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 2Working 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 structureIn this example, setup for the Serial TX Frame Processor VI is identical to the setup of the Serial RX Frame

ProcessorInputs 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 employingthe 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.


8/8



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] What Is NI LabVIEW,http://www.ni.com/labview/whatis/,National Instruments, 2012.

[2] XBee & XBee PRO ZB,http://www.digi.com/pdf/ds_xbeezbmodules.pdf,Digi International, 2011.

[3] Coleman, Steve, Greg Mitchell and M.G. Guvench, PC Controlled Testing Platform for MEMS Capacitance

and Acceleration SensingAbstracts of ASEE New England Conference, Bridgeport, Conn., 2008.

[4] NI Developer Zone,http://zone.ni.com/dzhp/app/main,National Instruments, 2012.

[5] API Operation,XBee/XBee-PRO ZB RF Modules, Digi International, 2010, 99.

[6] 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. Michaelsundergraduate 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

[email protected].

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 andsemiconductor 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

[email protected].
http://www.ni.com/labview/whatis/http://www.ni.com/labview/whatis/http://www.ni.com/labview/whatis/http://www.digi.com/pdf/ds_xbeezbmodules.pdfhttp://www.digi.com/pdf/ds_xbeezbmodules.pdfhttp://www.digi.com/pdf/ds_xbeezbmodules.pdfhttp://zone.ni.com/dzhp/app/mainhttp://zone.ni.com/dzhp/app/mainhttp://zone.ni.com/dzhp/app/mainmailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://zone.ni.com/dzhp/app/mainhttp://www.digi.com/pdf/ds_xbeezbmodules.pdfhttp://www.ni.com/labview/whatis/

Documents

Implementción de XBee Serie 2 API en LabView