Paper ID #7789

Building Wireless Sensor Networks with Zigbee

Dr. Mohammad Rafiq Muqri, DeVry University, PomonaRobert Alfaro

c©American Society for Engineering Education, 2013

Page 23.263.1

Building Wireless Sensor Networks with Zigbee

The microprocessor sequence courses are among the important and challenging courses that

students take in the electronics, computer, and biomedical engineering curriculum; these courses

also lay the foundation for capstone senior projects. The practical, but abstract, programming

concepts in embedded computing tend to be difficult for beginning freshman and sophomore

students. This difficulty is reinforced by the use of cheap simulators as opposed to hands-on

microprocessor development tools. The faculty at DeVry University is developing new hands on

application-oriented laboratory exercises which can actively engage students. These laboratory

exercises will also be helpful to students who will take capstone senior project coursework.

The use of carefully crafted laboratory exercises is very important in exposing engineering

technology students to microprocessor projects. The previous assembly language laboratory

exercises were used in a two-course microprocessor sequence taught over a fourteen week

semester. The newer three-course microprocessor sequence introduced in 2008 is being taught in

an eight week session format, with two two-hour lectures, one one-hour diagnostic test, and one

three-hour laboratory session per week.

The laboratory activities start off with simple programming examples, such as interfacing with

pushbuttons, LEDs, and switches and then gradually progressing to interfacing with stepper

motors, keypad, and programmable timers. The liquid crystal display(LCD), asynchronous and

synchronous serial devices, analog to digital, and digital to analog conversion, are further

explored in this course sequence. This paper will also discuss an interesting real world

application - implementation of wireless sensor networks using Zigbee.

In order to facilitate these laboratory exercises, the faculty at DeVry has chosen to use a

Freescale, 68HC12 microcontroller board. This paper will also describe in detail the new labs

teaching module which is being developed to introduce the students to smart sensors,

transducers, and building wireless sensor networks using IEEE 1451 family of standards.

Prior to implementing these exercises, the laboratory portion of the course was predominantly

based upon assembly language programming. Beginning in 2009, the curriculum was revised to

reflect the greater use of C instead of assembly languages.

This paper provides an introduction to the various components of a ZigBee network. After a

quick overview of ZigBee, an account of high-level concepts used in wireless communication and

the specific protocols needed to implement the communication standards will be given. This will

be followed by a description of using a 68HC12-based microcontroller board and C libraries to

form a ZigBee network and the introductory labs for students. This will serve as an innovative

way to expose technology students to real world applications like building wireless smart sensor

network (WSN) with Zigbee standard and interfacing with the 68HC12 microcontroller, which

will be incorporated in a revised teaching module.

Page 23.263.2

Introduction

ZigBee, is a specification for communication in a wireless personal area network (WPAN), has

also been called the “Internet of things.” Theoretically, the ZigBee-enabled refrigerator, washing

machine, coffee maker, toaster, toys and other kitchen/home appliances can freely communicate

with each other. ZigBee applications include but are not limited to home and office automation,

industrial automation, medical monitoring, HVAC control, security, and seismologic monitoring.

ZigBee targets the application domain of low power, low duty cycle and low data rate requirement

devices. Figure 1 shown below is a block diagram of a ZigBee network with five nodes.

Figure 1 ZigBee Based Sensor Network

Typically a wireless communication system comprises of transmitters, receivers, antennas, and the

path between the transmitter and the receiver. In summary, the transmitter feeds a signal of

encoded data modulated into radio frequency waves into the antenna. The antenna radiates the

signal through the air where it is picked up by the antenna of the receiver. The receiver

demodulates the RF waves back into the encoded data stream sent by the transmitter. Wireless

network types are typically defined by size and location. A wireless personal area network

(WPAN) is meant to span a small area such as a private home or an individual workspace. It is

used to communicate over a relatively short distance and in contrast to other network types, there

is little to no need for infrastructure with a WPAN. Adhoc networking allows devices to be part

of the network temporarily; they can join and leave at will. This works well for mobile devices

like PDAs, laptops and phones.

Some of the protocols employing WPAN include Zigbee, Bluetooth, Ultra-wideband, and

infrared Data Association (IrDA).Each of these is optimized for particular applications or

domains. ZigBee, with its sleepy, battery-powered end devices, is a perfect fit for wireless

sensors. IEEE 802.15.4 is a packet-based radio protocol. It addresses the communication needs

of wireless applications that have low data rates and low power consumption requirements. It is

the foundation on which ZigBee is built. It supports star and peer-to-peer topologies. The ZigBee

specification not only supports star but also mesh and cluster tree kind of peer-to-peer

topologies.

Two types of devices can participate in a low rate LR-WPAN: a reduced function device (RFD)

Page 23.263.3

and a full function device (FFD). An RFD does not have routing capabilities. RFDs can be

configured as end nodes only. They communicate with their parent, which is the node that

allowed the RFD to join the network. An FFD has routing capabilities and can be configured as

the PAN coordinator. In a star network, all nodes communicate with the PAN coordinator only

it does not matter if they are FFDs or RFDs. In a peer-to-peer network, there is also one PAN

coordinator, but there are other FFDs which can communicate with not only the PAN

coordinator, but also with other FFDs and RFDs. There are three operating modes supported by IEEE 802.15.4: PAN coordinator, coordinator, and

end device. FFDs can be configured for any of the operating modes. In ZigBee terminology the

PAN coordinator is referred to as simply “coordinator.” The IEEE term “coordinator” is the

ZigBee term for “router.” 802.15.4 defines operation in three license-free industrial scientific

medical (ISM) frequency bands. Table 2 depicted below summarizes the properties of IEEE

802.15.4 in two of the ISM frequency bands: 915 MHz and 2.4 GHz.

Table 1 Comparison of IEEE 802.15.4 Frequency Bands

Property Description

Prescribed

Values 2.4 GHz 915 MHz

Raw data bit rate

250 kbps 40 kbps

Transmission range

Indoors: up to 30 m; Outdoors: up to 100 m

Latency 15 ms

Channels 16 channels 10 channels

Channel numbering 11 to 26 1 to 10

Channel access CSMA-CA and slotted CSMA-CA

Modulation scheme O-QPSK BPSK

IEEE 802.15.4 supports both short (16-bit) and extended (64-bit) addressing. An extended

address is assigned to every RF module that complies with the 802.15.4 specification. When a

device associates with a WPAN, it receives a 16-bit address from its parent node that is unique in

that network. Each WPAN has a 16-bit number that is used as a network identifier. It is called the

PAN ID. The PAN coordinator assigns the PAN ID when it creates the network. A device can try

and join any network or it can limit itself to a network with a particular PAN ID. ZigBee PRO

defines an extended PAN ID. It is a 64-bit number that is used as a network identifier in place of

its 16-bit predecessor.

ZigBee is built on top of the IEEE 802.15.4 standard. ZigBee provides routing and multi-hop

functions to the packet-based radio protocol. The ZigBee stack resides on a ZigBee logical

device. There are three logical device types: coordinator, router and end device. It is at the

network layer that the differences in functionality among the devices are determined. It is

Page 23.263.4

expected that in a ZigBee network the coordinator and the routers will be mains-powered and that

the end devices can be battery-powered.

Figure 2 shows a simplified ZigBee stack, which includes the two layers specified by 802.15.4

the physical (PHY) and media access control (MAC) layers. The physical layer defines the

physical and electrical characteristics of the network. The basic task of the physical layer is data

transmission and reception. At the physical/electrical level, this involves modulation and

spreading techniques that map bits of information in such a way as to allow them to travel

through the air. Specifications for receiver sensitivity and transmit output power are in the PHY

layer. The tasks of the physical layer include: enable/disable the radio transceiver, link quality

indication (LQI) for received packets, energy detection (ED) within the current channel and clear

channel assessment (CCA). The MAC layer defines how multiple 802.15.4 radios operating in the same area will share the

airwaves. This includes coordinating transceiver access to the shared radio link and the

scheduling and routing of data frames. There are network association and disassociation

functions embedded in the MAC layer. These functions support the self-configuration and

peer-to-peer communication features of a ZigBee network. The MAC layer tasks include beacon generation if device coordinating, implementing carrier

sense multiple access with collision avoidance (CSMA-CA), handling guaranteed time slot (GTS)

mechanism, and data transfer services for upper layers.

Application I Profiles

ZigBee

Application Framework Layer

Network Layer (NWK)

MAC Layer

802.15.4 Physical Layer (PHY)

Figure 2 ZigBee Stack

Page 23.263.5

In a ZigBee network there is only one coordinator per network. The number of routers and/or

end devices depends on the application requirements and the conditions of the physical site.

Within networks that support sleeping end devices, the coordinator or one of the routers must

be designated as a Primary Discovery Cache Device. These cache devices provide server

services to upload and store discovery information, as well as respond to discovery requests, on

behalf of the sleeping end devices.

As shown in Table 2, the stack layers defined by the ZigBee specification are the network and

application framework layers. The ZigBee stack is loosely based on the famous ISO/OSI seven

layer model. It implements only the functionality that is required in the intended markets. The network layer ensures the proper operation of the underlying MAC layer and provides an

interface to the application layer. The network layer supports star, tree and mesh topologies.

Among other things, this is the layer where networks are started, joined, left and discovered.

Table 2 Comparison of ZigBee Devices at the Network Layer

ZigBee Network Layer Function Coordinator

r

Router End Device

Establish a ZigBee network X

Permit other devices to join or

leave the network

X

X

Assign 16-bit network addresses X X

Discover and record paths for efficient

message delivery

X

X

Discover and record list of one-hop

neighbors

X X

Route network packets X X

Receive or send network packets X X X

Join or leave the network X X X

Enter sleep mode X

When a coordinator attempts to establish a ZigBee network, it does an energy scan to find the

best RF channel for its new network. When a channel has been chosen, the coordinator assigns

the logical network identifier, also known as the PAN ID, which will be applied to all devices

that join the network.

A node can join the network either directly or through association. To join directly, the system

designer must somehow add a node’s extended address into the neighbor table of a device. The

direct joining device will issue an orphan scan, and the node with the matching extended

address (in its neighbor table) will respond, allowing the device to join.

Page 23.263.6

The application (APS) layer is made up of several sub-layers. The APS sub-layer is

responsible for binding tables, message forwarding between bound devices, group address

definition and management, address mapping from 64-bit extended addresses to 16-bit

NWK addresses, fragmentation and reassembly of packets, and reliable data transport. The

key to interfacing devices at the need/service level is the concept of binding. Binding tables

are kept by the coordinator and all routers in the network. The binding table maps a source

address and source end- point to one or more destination addresses and endpoints. The

cluster ID for a bound set of devices will be the same.

Before joining a ZigBee network (i.e., a LR-WPAN), a device with an IEEE 802.15.4-

compliant radio has a 64-bit address. This is a globally unique number made up of an

Organizationally Unique Identifier (OUI) plus 40 bits assigned by the manufacturer of the

radio module. OUIs are obtained from IEEE to ensure global uniqueness.

When the device joins a Zigbee network, it receives a 16-bit address called the NWK

address. Either of these addresses, the 64-bit extended address or the NWK address, can be

used within the PAN to communicate with a device. The coordinator of a ZigBee network

always has a NWK address of “0.”

ZigBee provides a way to address the individual components on the device of a node through

the use of endpoint addresses. During the process of service discovery the node makes

available its endpoint numbers and the cluster IDs associated with the endpoint numbers. If a

cluster ID has more than one attribute, the command is used to pass the attribute identifier.

After a device has joined the ZigBee network, it can send commands to other devices on the

same network.

There are two ways to address a device within the ZigBee network: direct addressing and

indirect addressing. Direct addressing requires the sending device to know three kinds of

information regarding the receiving device:

1. Address

2. Endpoint Number

3. Cluster ID

After a device has joined the ZigBee network, it can send commands to other devices on the

same network.

Indirect addressing requires that the above three types of information be committed to a

binding table. The sending device only needs to know its own address, endpoint number,

and cluster ID. The binding table entry supplies the destination address(es) based on the

information about the source address.

The binding table can specify more than one destination address/endpoint for a given

source address/endpoint combination. When an indirect transmission occurs, the entire

binding table is searched for any entries where the source address/endpoint and cluster ID

matches the values of the transmission. Once a matching entry is found, the packet is sent Page 23.263.7

to the destination address/endpoint. This is repeated for each entry where the source

endpoint/address and clusterID match the transmission values.

There are two distinct levels of broadcast addresses used in a ZigBee network. One is a

broadcast packet with a MAC layer destination address of 0xFFFF. Any transceiver that is

awake will receive the packet. The packet is retransmitted three times by each device, thus

these types of broadcasts should only be used when necessary. The other broadcast address

is the use of endpoint number 0xFF to send a message to all of the endpoints on the

specified device. For group addressing, an application can assign multiple devices and

specific endpoints on those devices to a single group address. The source node would need

to provide the cluster ID, profile ID and source endpoint.

Course Protocol and Zigbee Methods

A low cost, 68HC12 microprocessor module based, laboratory intensive instruction

program was developed for common use in the newer microprocessor course ECET

365. The overall objectives of this teaching module were to:

Expose students to the engineering career field by showing them what an

engineer does, the skills required, and the exciting projects engineers work on.

Emphasize hands-on, learn by doing exercises.

Provide students engineering design, prototyping and testing skills.

Demonstrate how wireless networking is routinely used in engineering design

projects.

Provide hands-on laboratory exercises using commonly available, low cost

sensors and Zigbee-capable boards with the appropriate RF module firmware

module and encourage students to independently continue their studies beyond

the course.

For initial testing of Zigbees, an X-CTU, a Windows-based application provided by Digi,

was used. This program was initially designed to interact with the firmware files found on

Digi’s RF products and to provide a simple-to-use graphical user interface to them.

Zigbee Lab Instrument Setup

Two Dragon68HC12 boards are configured to communicate wirelessly via XBee radios. One

board will be programmed to act as a ZigBee “Node”, and the other as a ZigBee

“Coordinator”. After successful network connection is established between the wireless

sensor network devices, the ZigBee Node will read the ambient temperature and then send

the temperature value to the coordinator. The red LED will light up when the temperature

reaches a pre-defined high value. The green LED will light up when the temperature reaches

a pre-defined low value. As part of the successful communication in this sensor area network,

the ZigBee coordinator will communicate and give the command to the Zigbee Node to

either turn on the DC fan when the high temperature value is reached or turn off the DC fan

Page 23.263.8

when the low temperature value is reached. This closed loop control of temperature has been

successfully accomplished for this Wireless Sensor Network laboratory experiment by a

student who is a co-author of this paper.

The following list provides the summary of parts used for the laboratory exercises.

2x - Dragon12-Plus2-SM development boards

1x - Red LED

1x - Green LED

2x - 330Ω resistors

2x - XBee radios (Model: XBEE09P)

1x - 5V DC fan

µC-1 “Coordinator” Onboard Components / Ports

LCD display

PB0, PB1

SCI1

µC-2 “Node” Onboard Components / Ports

Temperature sensor (U14)

H-Bridge IC (U12)

Terminal Block (T4)

PB0

PWM0 (PP0)

SCI1

Jumpers

J51 - SCI1 SELECT

Connect jumper on the two rightmost vertical pins labeled “XBEE” to link XBee radio to

SCI1.

J42 - USB SEL

Connect two jumpers on the top four vertically paired pins labeled “SCI0” to link SCI0

to USB port. SCI0 is used for flash programming the dragon12 board.

“Coordinator” ONLY:

J1 - LCD_BL

Connect jumper onto both pins to enable the backlight of the LCD display.

“Node” ONLY:

J25 - MOTOR VOLT. SELECT

Connect jumper on the two leftmost pins labeled “VIN” to use onboard power source for

DC fan connected to T4.

Page 23.263.9

The following software listing provides the layout of Software Listing for the ZigBee established

Coordinator mode:

// Author: Robert Alfaro

// Date: 01/12/13

// Project: Wireless Sensor Network

// Descriptor: Coordinator

#include /* common defines and macros */

#include /* derivative information */

#pragma LINK_INFO DERIVATIVE "mc9s12dg256b"

// Function Prototypes

void init_SCI1(void);

void wait_ms(int);

void xbee_tx(unsigned char);

char xbee_rx(void);

void init_lcd4(void);

void cmdwrt_HI(char);

void cmdwrt(char); // write command code to lcd

void lcd_putchar(char); // display ascii char to lcd

void lcd_puts(char*); // display null-term ascii string to lcd

void lcd_printd(int); // display signed integer variable as decimal to lcd

// Globals

char init_commands[12] = {0x30,0x30,0x30,0x20,0x20,0x80,0x00,0x60,0x00,0xE0,0x00,0x10};

int CUR_TEMP, LOW_TEMP, HIGH_TEMP;

#define ENBL_FAN 0x0E

#define DSBL_FAN 0x0D

// MAIN

//

void main(void)

{

init_SCI1(); // Initialize SCI1

init_lcd4(); // Initialize LCD

DDRB = 0x03; // PB0, PB1 output to breadboard led

DDRJ = 0x00; // turn off onboard leds

DDRP = 0xFF; // turn off 7-seg

// WAIT FOR CONNECTION

while (CUR_TEMP == 0) {

CUR_TEMP = xbee_rx();

cmdwrt(0x80); // Clear LCD

Page 23.263.10

if (CUR_TEMP == 0)

lcd_puts("Waiting...");

else

lcd_puts("Connected!");

}

wait_ms(800); // Delay for looks...

LOW_TEMP = CUR_TEMP - 1; // Set Low Tolerance to temp-1

HIGH_TEMP = CUR_TEMP + 2; // Set High Tolerance to temp+2

cmdwrt(0x80); // Clear LCD

lcd_puts("Temp = ");

while(1)

{

CUR_TEMP = xbee_rx(); // Get data value

if (CUR_TEMP == 0) { // TIMEOUT exists?

cmdwrt(0x80);

lcd_puts("Temp = UNDF");

}

else { // Data received

cmdwrt(0x87);

lcd_printd(CUR_TEMP);

lcd_putchar(0xDF);

lcd_puts("C");

if (CUR_TEMP = HIGH_TEMP) {

PORTB = 0x02; // Turn on Red LED

xbee_tx(ENBL_FAN); // Command: Enable DC fan

}

}

wait_ms(100);

}

}

// Initialize SCI1

//

Page 23.263.11

void init_SCI1(void)

{

//The RUN mode (SW7=10) of Dragon12+ works at 8MHz.

SCI1BDH=0x00; //Serial Monitor used for LOAD works at 48MHz

SCI1BDL=26; //8MHz/2=4MHz, 4MHz/16=250,000 and 250,000/9600=26

SCI1CR1=0x00;

SCI1CR2=0x0C;

}

// Send Character to SCI1

//

void xbee_tx(unsigned char c) //SCI1 (COM1 of HCS12 chip)

{

while(!(SCI1SR1 & 0x80)); //make sure the last bit is gone before feeding next byte

SCI1DRL=c;

}

// Read Character from SCI1

//

char xbee_rx()

{

unsigned char c=0;

unsigned int timeout = 0;

while ((SCI1SR1 & 0x20) == 0){ /* Wait for received character */

if (timeout >= 10000) // TIMEOUT reached?

return 0;

else

timeout++;

}

c = SCI1DRL;

if ((SCI1SR1 & 0x0f) != 0) // Nothing received?

return 0;

return c;

}

// Delay 'time' milliseconds

//

void wait_ms(int time)

{

int i,j;

for(i=0; i

//////////////////

// LCD Routines //

//////////////////

void init_lcd4(void){ // on-board Seiko LCD in 4-bit mode, 24 MHz cpu

int i;

DDRK = 0xff; // write-only

for(i=0;i> 2) & 0x3c) | 1); // high nibble, EN = 0, RS = 1

PORTK |= 2; // EN = 1

PORTK &= 0x3d; // EN = 0

wait_ms(1);

PORTK = (((ascii

while(val){ // keep looping until Q. drops to 0

val /= 10; // 1st Q., next Q., etc.

dig[i++] = (char)(valcopy % 10); // 1st R., store it, next R.. etc.

valcopy = val; // copy of 1st Q., copy of next Q., etc.

}

while(i){ // convert & output remainders (digits), last to first

dig[--i] += 0x30; // convert to ASCII numeral and...

lcd_putchar(dig[i]); // send to lcd until dig[0] is sent out

}

}

void cmdwrt(char cmd){ // RS = 0, command write

PORTK = ((cmd >> 2) & 0x3c); // high nibble, EN = 0, RS = 0

PORTK |= 2; // EN = 1

PORTK &= 0x3c; // EN = 0

wait_ms(1);

PORTK = ((cmd > 2) & 0x3c; // high nibble only, EN = 0, RS = 0

PORTK |= 2; // EN = 1

PORTK &= 0x3c; // EN = 0

wait_ms(5); // extra delay when waking-up LCD

}

The following software listing provides the layout of Software Listing for the ZigBee established

Node mode:

// Author: Robert Alfaro

// Date: 01/12/13

// Project: Wireless Sensor Network

// Descriptor: Node

#include /* common defines and macros */

#include /* derivative information */

#pragma LINK_INFO DERIVATIVE "mc9s12dg256b"

// Function Prototypes

void init_SCI1(void);

void wait_ms(int);

void xbee_tx(unsigned char);

Page 23.263.14

char xbee_rx(void);

void init_ATD(void);

int get_temp(void);

void init_motor(void);

// Globals

int CUR_TEMP, action;

#define ENBL_FAN 0x0E

#define DSBL_FAN 0x0D

// MAIN

//

void main(void)

{

init_SCI1();

init_ATD();

init_motor();

DDRJ = 0x00; // turn off onboard leds

DDRP = 0xFF; // turn off 7-seg

while(1){

CUR_TEMP = get_temp(); // Read data value

xbee_tx((char)CUR_TEMP); // Send data

action = xbee_rx(); // Action to perform?

if (action == ENBL_FAN) // Enable DC fan

PWMDTY0 = 100;

else if (action == DSBL_FAN) // Disable DC fan

PWMDTY0 = 0;

wait_ms(100); // short delay

}

}

// DC Motor Control

//

void init_motor( ){

DDRB = 0x03; // PB1 and PB0 output

PORTB = 0x01; // Forward rotation

PWMCLK = 0x01; // Ch. 0 source: clock SA

PWMSCLA = 1; // clock SA divide by 2x1 = 2 (4Mhz/2 = 2 MHz)

PWMPOL = 0x01; // initial HIGH output (left-align) on ch. 0

PWMPER0 = 100; // period value = 50 us (2MHz/20kHz = 100)

PWMDTY0 = 0; // initial speed setting

PWME = 0x01; // turn-on PWM ch. 0

}

Page 23.263.15

// Get Temp. Value

//

int get_temp()

{

int ATDout; // holds digitizd result as it is being reduced from ATD result register

ATD0CTL5 = 0x85; // start next conversion - right, unsigned, single, Ch. 5

ATD0CTL4 = 0x05; //16bit

while((ATD0STAT0 & 0x80)==0);

ATDout = ATD0DR0;//10bit

ATDout /=2;

return(ATDout); // returns whole number (hex) volts only

}

// Initialize ATD

//

void init_ATD( ){

ATD0CTL2 = 0xC0; // 1100 0000 -- ADC On = 1, AFFC = 1, ASCIE = 0

wait_ms(1); // waits for LCD warm up (actually only needs 5 us)

ATD0CTL3 = 0x08; // 0 0001 000 -- one conversion per sequence

ATD0CTL4 = 0xCB; // %1 10 01011 -- 8-bit res., 8 A/D clks, 1 MHz conv. freq

}

// Initialize SCI1

//

void init_SCI1(void)

{

//The RUN mode (SW7=10) of Dragon12+ works at 8MHz.

SCI1BDH=0x00; //Serial Monitor used for LOAD works at 48MHz

SCI1BDL=26; //8MHz/2=4MHz, 4MHz/16=250,000 and 250,000/9600=26

SCI1CR1=0x00;

SCI1CR2=0x0C;

}

// Send Character to SCI1

//

void xbee_tx(unsigned char c) //SCI1 (COM1 of HCS12 chip)

{

while(!(SCI1SR1 & 0x80)); //make sure the last bit is gone before feeding next byte

SCI1DRL=c;

}

// Read Character from SCI1

//

Page 23.263.16

char xbee_rx()

{

unsigned char c=0;

unsigned int timeout = 0;

while ((SCI1SR1 & 0x20) == 0){ /* Wait for received character */

if (timeout >= 10000) // TIMEOUT reached?

return 0;

else

timeout++;

}

c = SCI1DRL;

if ((SCI1SR1 & 0x0f) != 0) // Nothing received?

return 0;

return c;

}

// Delay for 'time' milliseconds

//

void wait_ms(int time)

{

int i,j;

for(i=0; i

Lessons Learned

A few lessons have been learned that will help in the successful delivery of this laboratory

module.

Instructors for the course module must be comfortable in working with a wide variety of students at different cognitive levels.

Instructors should be comfortable in working with young, energetic students. They must be flexible and be willing to take time out from the scheduled lesson plan to fill in the

student knowledge gaps on an as needed basis.

It is important to keep the activities exciting and varied when teaching the program module.

Conclusions

It can be stated that with proper guidance, monitoring and diligent care the engineering

technology students can be exposed earlier to Wireless APIs and embedded C programming.

This will go a long way in motivating them, eliminating their fear, improving their understanding

and enhancing their quality of education. Highly recommend this approach to attracting and

retaining students to the embedded computing, and wireless sensor networking. All developed

curriculum material is available for use. Besides the author, the student coauthor is also very

positive about the laboratory course outcome and appreciates the enhanced understanding of

wireless sensor networks and wireless API for Bluetooth and Zigbee applications.

Bibliography

1. Muqri, M., Shakib, J., A Taste of Java-Discrete and Fast Fourier Transforms, American Society for

Engineering Education, AC 2011-451.

2. Zhuang, L. Q., Goh, K.M., and Zhang, J. B., The Wireless Sensor Networks for Factory Automation: Issues

and Challenges, Singapore 638075, 1-4244-0826-1/2007 IEEE

3. Muqri, M., Lewis, J., Objective-C versus Java for Smart Phone Applications, 119th Annual ASEE

Conference, Session: AC 2012- 3338

4. Eren, H., Wireless Sensors and Instruments, CRC Press, Taylor & Francis Group, Boca Raton, Florida, 2006.

5. Shakib, J., Muqri, M., Wireless Technologies in Industrial Automation System, 118th Annual ASEE

Conference, Session: AC 2011- 389.

6. X-CTU Configuration & Test Utility Software User’s Guide, Digi International,

http://www.digi.com/support/productdetail?pid=3352&type=utilities

7. Palmer G., Technical Java - Developing Scientific and Engineering Applications, Prentice Hall, 2003.

8. Puccinelli, D., Haenggi, M., Applications and Challenges of Ubiquitous Sensing, IEEE Circuits and Systems

Magazine, Wireless Sensor Networks:, Third Quarter 2005.

9. Allan, A., iOS Sensor Apps with Arduino - Wiring the iPhone and iPad into the Internet of Things, O’Reilly

Media, 2011.

Page 23.263.18