Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Paper ID #7789
Building Wireless Sensor Networks with Zigbee
Dr. Mohammad Rafiq Muqri, DeVry University, PomonaRobert Alfaro
c©American Society for Engineering Education, 2013
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.
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)
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
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
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.
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
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
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.
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 <hidef.h> /* common defines and macros */
#include <mc9s12dg256.h> /* 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
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 <= LOW_TEMP)
PORTB = 0x01; // Turn on Green LED
xbee_tx(DSBL_FAN); // Command: Disable DC fan
else if (CUR_TEMP >= HIGH_TEMP)
PORTB = 0x02; // Turn on Red LED
xbee_tx(ENBL_FAN); // Command: Enable DC fan
wait_ms(100);
// 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
//
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<time; i++)
for(j=0; j<2000; j++);
//////////////////
// 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<12;i++)
cmdwrt_HI(init_commands[i]); // send commands to lcd, one-by-one
void lcd_puts(char *ptr) // string write
while(*ptr != 0)
lcd_putchar(*ptr);
ptr++;
void lcd_putchar(char ascii) // RS = 1, character write
PORTK = (((ascii >> 2) & 0x3c) | 1); // high nibble, EN = 0, RS = 1
PORTK |= 2; // EN = 1
PORTK &= 0x3d; // EN = 0
wait_ms(1);
PORTK = (((ascii << 2) & 0x3c) | 1); // low nibble, EN = 0, RS = 1
PORTK |= 2; // EN = 1
PORTK &= 0x3d; // EN = 0
wait_ms(1);
void lcd_printd(int val) // displays hex integer as decimal to lcd
int valcopy; // abbreviations: R. = remainder, Q. = quotient
char dig[5] = 0; // storage for R.'s
int i = 0; // index into array called dig[ ]
if(val == 0)
lcd_putchar('0'); // statements below do nothing if val==0
if(val < 0)
val = ((~val)+1); // get hex magnitude if negative and...
lcd_putchar('-'); // ...display minus sign in front
valcopy = val; // successive /10 to generate R.'s
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); // low nibble, EN = 0, RS = 0
PORTK |= 2; // EN = 1
PORTK &= 0x3c; // EN = 0
wait_ms(1);
void cmdwrt_HI(char initcmd) // use for LCD initialization only
PORTK = (initcmd >> 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 <hidef.h> /* common defines and macros */
#include <mc9s12dg256.h> /* 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_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
// 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
//
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<time; i++)
for(j=0; j<2000; j++);
Results
This series of modular, laboratory exercises were used for the three course microprocesspor
sequence. No data was collected to quantify if this laboratory module result in a student’s
decision to pursue Wireless smart sensor network track within the ECET program. This was not
the specific intent. The goal was to attract and expose students to emerging new careers in
science and engineering.
Overall students critiques are quite positive across the program. Here is a representative
sample of student critiques:
“ I learnt a great deal about sensors.
“ I had no clue about wireless smart sensor networks and now I feel more comfortable
than before.
“Although the course heavily emphasized laboratory work, the student critiques indicated
students wanted even more laboratory work.
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.