CSE 896 Embedded Systems:

Lab 1 Assignment

Christopher Assi

Dr. M.C. Vuran

Assistant Professor
Department of Computer Science and Engineering
University of Nebraska-Lincoln

February 8, 2010
I. Introduction

The goal of this lab assignment was to make acquainted with the use
of TinyOS in a Linux Environment. TinyOS is an open-source operation
system designed for wireless embedded sensor networks. It features a
component-based architecture, which enables rapid innovation and
implementation while minimizing code size. Some of the TinyOS library
components are distributed services, sensor drivers, and data
acquisition tools. TinyOS applications are usually written in nesC.

II. Blink Application

a) Blink

The First application which was used to get familiarize with was a basic
Blink program. The purpose of this blink was to blink the motes LEDs at
1HZ. At this point, understanding the code is an important step. After
running the basic blink program and familiarizing myself with the code,
it was time to get deeper. A good starting point was to change the
timer period, which changes the rate at which the LEDS blink.
The rate of the blinking had to be changed to 0.5HZ which was
basically counted every 2 seconds.
It was less complicated than I first envisioned going from one platform
to the other. To install the platform I just to change the command to
make telosb install,1 and be able to execute the application. There
weren’t too many changes to be implemented to move to another
platform.

Some of the challenges faced during that experiment were regarding

the MTS310 and its SounderC. The application was divided into 2
sections. One dealt with the LED blinking and the other on the
SounderC and the buzzer.
b) Debugging

Figure - MainC components

 Figure - PrintF components

c) Light Sensing

This application dealt with changing the blink rate of the LEDs based
on the light sensing. High light blinking rate had to be 0.5HZ, medium
light-blinking rate had to be 1.5HZ, and low light blinking rate had to
be 4HZ. The blinking periodic rate were 2000, 667, and 250
respectively.
Experiments with changing Blink timer period were successful. Along
with changing the LED blink rate, I also added ability to blink different
LEDs (choose from Red, Yellow, or Green). At this point I am more
familiar with nesC, its syntax and structuring, so I was able to start
analyzing and testing other applications. The blink application dealt
with components for the mote only, it was now time to start

The port for the TelosB platform has been completely implemented
and tested, while the port for the MicaZ platform is only minimal. Few
things which needs to be implemented on the MicaZ platform is the
implementation of sensor drivers and the hardware specific libraries
that are responsible for the communication between the computer and
the mote through a turn interface and the serial interface (SLIP) and
testing for the radio and the ELF loader. However, the current port for
MicaZ can be considered functional since it is possible to run some
applications, such as the “Blinking” program. Micaz has a smaller
memory size, therefore when implementing the code to TelosB, there
 is not too much worries on the memory size.

d) Sounder

The goal of this application was to implement the MTS310 sensor

board. On the MicaZ application the buzzer (Sounder 4.5HZ) from the
MTS310 will be activated once the counting reaches “111” and all LEDs
are ON. The sounder has to remain in that state until it reaches “100”
where it will be deactivated.
The first applications that would best show wireless communication at
its most basic and simplest lever are RfmToLeds and CntToLedsAndRfm.
With the introduction of communications, our network now requires 2
or more motes. In this network, a mote is programmed with
CntToLedsAndRfm which increases a binary counter every 1/4 Hz and
outputs its results on the LEDs and sends the counter value over the
radio. Another mote is programmed with RfmToLeds in which the counter
from the radio is output to the LEDs of the base mote attached to the
MIB510 board.
Some of the problems faced were dealing with inserting the data into
the FLASH memory. That’s when the Logwrite.nc had to be
implemented.

III.Conclusion

The lab experiment gave an overview of how resource arbitration and

mechanisms for performing power management on those resources is
provided in TinyOS. Also dealing with the use of different platforms and
their challenges. TinyOS may be a very small node regarding the
memory range wise, but has some very important library tools. Some
very important components are the temperature sensor (TempC), light
sensor (PhotoC), acoustic sensor (MicC), and the buzzer (SoundC).
Those components make tinyOS a very significant sensor network.