VIBE:

A Body Area Sensor Networked Human Motion Analysis Platform

by

Corey Provencher

A Graduate Paper Submitted

in

Partial Fulfillment

of the

Requirements for the Degree of

MASTER OF SCIENCE

in

Electrical Engineering

Approved by: PROF.

(Graduate Paper Advisor’s Name, Printed) PROF.

(Department Head’s Name, Printed)

DEPARTMENT OF ELECTRICAL AND MICROELECTRONIC ENGINEERING

KATE GLEASON COLLEGE OF ENGINEERING

ROCHESTER INSTITUTE OF TECHNOLOGY

ROCHESTER, NEW YORK

August, 2010

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Theoretical Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Motion Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Body Area Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Wireless Body Area Sensor Network Research . . . . . . . . . . . . . . . . . 13

3.2 Human Motion Analysis Research . . . . . . . . . . . . . . . . . . . . . . . 14

4 Concept Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Wearability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Sensing Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Data Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 Data Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.6 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.7 Battery Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Design Aesthetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Power Management Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1 Hardware Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.2 SimpliciTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2

7.3 uC/OS-II Real-Time Operating System . . . . . . . . . . . . . . . . . . . . 39

7.4 Vibe Application Programming Interface . . . . . . . . . . . . . . . . . . . 40

7.5 User Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 Hardware Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.1 Vibe Development Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.2 Vibe 1.0 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9 Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

10 Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

11 Future Work & Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

1 Appendix A: Concept Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2 Appendix B: Vibe API Function List . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.1 General API Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.2 Real-Time Clock (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.3 Input/Output Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.4 External Flash Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.5 Triaxial Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

2.6 Triaxial Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2.7 Digital Compass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3

Acknowledgements

I offer my sincerest gratitude to my advisor, Dr. Daniel Phillips, for his constant support and

guidance through the Vibe project. His support and insight has made my graduate experience one

of educational growth and enjoyment. His knowledge and wealth of resources have helped bring

the Vibe project to fruition. I am thankful for the opportunity to partake in research under his

guidance.

I would like to thank the Industrial Design Department at RIT for their support of the Vibe

project and in particular two of their students, Tony Chiang and Sandra Turner for their work in

the design and aesthetics of the Vibe project. I would also like to thank their advisor, Alex Lobos

for selecting the right students for the project.

Thanks to Jeffrey Robble for his dedicated work in application development and wireless net-

working. His software expertise brought dynamic, proof-of-concept applications that were invalu-

able to the project.

Lastly, I thank my parents and my partner for their support and understanding through my

work on this project and throughout my college education. Their support has pushed me to reach

goals unforeseeable at the beginning of this journey.

Thank You.

Abstract

Real-time human body motion tracking is a task demanded by many applications. Accurate real-

time motion tracking typically requires expensive, obtrusive machinery due to the dynamic range

of the human joints. This paper proposes a low-power, low-cost platform for tracking human body

motion. A network of small, portable sensors create a Body Area Sensor Network that senses

and relays joint motion to other nodes worn on the body. Emphasis is placed on wearability

and battery lifetime of the device to provide an unobtrusive system with a long battery life. A

large array of motion sensors provides accurate motion tracking capabilities with both relative

and absolute motion sensing capabilities. The Vibe platform hardware has been designed and

prototypes successfully built and tested. Basic proof-of-concept motion tracking applications have

been developed and the ability to track human motion has been realized. It is anticipated that

Vibe will provide great facility to applications in the fields of physical therapy, gait analysis and

body tremor research.

1 Introduction

Real-time human body motion capture and analysis capability caters to many fields that currently

lack a simple and efficient way to do so. The applications are both profound and abundant.

In the area of gait analysis, for example, the ability to objectively track changes in the gait of

a patient over time and report this data to a physical therapist provides great advantages over

keeping subjective records.Vibe is a motion sensor platform that was developed to address these

applications.

Vibe is a wireless human body motion data acquisition and processing platform. The goal of

Vibe was to develop wearable, unobtrusive motion sensors that can network to collectively record

human motion data. This collective network of sensors on the body is referred to as a Body Area

Sensor Network (BASN). Each sensor contains a 6-axis Inertial Motion Unit (IMU) consisting

of an accelerometer, gyroscope and compass for both relative and absolute positioning. Up to 6

devices can be worn on the body to create a wireless BASN. The BASN allows for localized sensing

of motion and multiple channels of data to be processed simultaneously. In addition, each node

contains a substantial amount of processing capabilities thanks to the integrated microprocessor.

The goal of this project originally stems from a clinical case. A teenage boy with a severe

form of Epilepsy required a parent to sleep with him in order to respond to the onset of a seizure

and administer medicine. The neurologist approached RIT with a proposal for a device that could

monitor the patient for seizures and wirelessly alert a parent in another room in case of the onset of

a seizure. This beginning phase of a seizure is marked by rhythmic tremors in the body’s muscles.

Vibe was originally created with the intent of solving this problem. It has since grown into a

platform, allowing researchers to develop motion analysis applications to address their needs. Vibe

provides both the hardware, processing capability and low-level software to bring these applications

to fruition.

Vibe is primarily aimed at researchers and physicians/therapists with applications that require

accurate and efficient body motion data acquisition and analysis. This includes applications in

the area of gait analysis, tremor analysis, fitness (e.g. pedometry), and even local positioning

within a confined area. Vibe abstracts the lower-level tediousness and complexity of the hard-

ware, sensor interface and wireless protocols to provide the user with a rich set of simple APIs

1

that facilitate application development. The application programming interface (API) assumes no

advanced knowledge of embedded software or hardware. A pure software background is sufficient

for developing applications on the Vibe platform.

This paper discusses the design process and architecture of the Vibe platform. The paper is

organized as follows. Section 1 has introduced the Vibe platform. Section 2 describes the theoretical

development supporting the platform. This includes how human body motion data can be acquired

and efficiently processed. Section 3 analyzes previous work in real-time human motion analysis and

describes what advantages the Vibe platform has over current commercial solutions, at the time

of writing. Section 4 describes the concept selection process that led to the design decisions made

and how the system was devised. Section 5 details the design aesthetic of the wearable sensors

and discusses the manufacturing process employed to to produce the devices. Section 6 details the

hardware architecture of Vibe. Section 7 discusses the software stack, including the user APIs for

Vibe application development. Section 8 details the hardware development process and testing of

Vibe hardware. Section 10 describes applications for motion tracking that have been developed

for proof-of-concept and testing purposes. Lastly, Section 11 concludes the paper and discusses

future work and possible improvements that can be made to the Vibe platform. In addition,

Section 11 provides a reflection on the academic growth that is a product of being involved in the

Vibe project. This work is being conducted as a Master’s graduate project and the goal of Vibe

was to gain further knowledge in the field of Embedded Systems and more generally in Electrical

Engineering.

2 Theoretical Development

The goal of Vibe was to provide a platform that gives an application developer the tools necessary

to accurately track human body motion. To achieve this functionality, a sensing node must contain

a significant amount of sensing and data processing capabilities. In addition, a single sensing node

can not accurately capture all ranges of motion that the human body is capable of, due to the

extensive number of joints and degrees of freedom in each joint. This section describes the elements

necessary to accurately record human motion.

2

2.1 Motion Sensors

Motion sensors are used extensively in robotics to allow a robot to interact and become aware of

its environment. Modern motion sensors are based on many different technologies such as infra-

red, ultrasonic waves and Microelectromechanical Systems (MEMS), to name a few. Vibe makes

extensive use of MEMS sensors to sense the motion of the joint it is attached to.

Accelerometer

The first of these devices is known as an accelerometer. Accelerometers appear in many appli-

cations, including vehicle airbag deployment systems. If a vehicle is involved in a collision, the

vehicle will experience a sudden deceleration which is sensed by the accelerometer and allows the

vehicle to inflate the airbags. Accelerometers have also been very popular in gaming and mobile

devices. Currently, many mobile phones use accelerometers as orientation sensors to readjust the

screen between landscape and portrait mode.

Acceleration can be measured by employing Newton’s second law of motion, simply stated in

Equation (2.1).

F = m ∗A (1)

That is, the force experienced on an object is the product of its mass and acceleration. There

are various technologies employed for sensing acceleration using this known principle. One such

example structure is shown in Figure 1. A structure with a known mass, referred to as a proof mass,

has a projection that extends within finger-like structures. The finger-like structures are parallel

to the projection such that they form a parallel plate capacitor. The proof mass is attached to a

set of polysilicon springs so that it is allowed to move in multiple dimensions. As the proof mass

moves, the spacing between the mass’ projection and and the finger-like structure changes. This

change in parallel plate distance translates to a change in capacitance. The change in capacitance

corresponds to a force being applied to the mass. Since the mass of the proof mass structure is

known, the acceleration can be deduced.

In motion applications, an accelerometer is a versatile sensor as it allows for not only sensing

dynamic movement in the form of a body under acceleration, but it also can be used to measure

static inclination. This uses the fact that objects on earth constantly experience approximately

3

Proof Mass

Fixed Plates Movable Plate

Figure 1: Mechanical Structure of a MEMS Accelerometer

1 g-force or 9.8m/s2 of acceleration due to the natural gravitational force. Note that the term

“g-force” is actually a misnomer, since it represents an acceleration and not a force. If a single

axis, for example the z-axis, of a device with an accelerometer experiences a static acceleration

of 1 g-force, it is known that this device is oriented with the z-axis pointing upward against the

direction of gravitational force. Extending this idea, if the static acceleration of the x, y & z-axes

are known, a vector calculus problem can be solved to determine the exact orientation of the object

in space. Figure 2 shows an accelerometer with a static inclination in each axis. The angles of

inclination are marked α, β and γ, representing angular displacements from the x, y and z axes,

respectively as shown.

Z

Y Xβ

γ

α

Figure 2: Determining Static Inclination using an Accelerometer

Using the data from the accelerometer, the tilt angles can be calculated as shown in (2) -

(4) [14].

α = arcsin

(axg

)(2)

4

β = arcsin

(ayg

)(3)

γ = arccos

(azg

)(4)

In order to distinguish inclination from dynamic acceleration, filtering methods such as a low-

pass filter will be employed to filter out dynamic accelerations. Some accelerometers provide this

capability built-in for inclination measurement or conversely a high-pass filter for detection of

dynamic motion.

In addition an accelerometer can also be used to roughly estimate linear displacement in a 3D

environment. Acceleration is defined as the change in velocity over time. Velocity is the change in

displacement over time, and thus acceleration is the second derivative of displacement with respect

to time. This is shown in Equation (2.1), where x is the displacement of an object in the x-axis.

Acceleration =δv

δt=

δ

δt(δx

δt) =

δ2x

δt2(5)

Thus, in order to trace back to a displacement from a known acceleration, the second integral of

acquired data must be extracted. Note that the integration process is lossy, since it acts to average

the signal and therefore only an estimate of linear displacement can be calculated. This process

can be repeated for each axis of motion in order to determine the three-dimensional displacement

of an object over time.

A simpler, less-accurate method of measuring linear displacement using an accelerometer is

commonly employed by many modern pedometers. The pedometer uses the accelerometer to

determine steps based on matching profiles to the accelerometer data. A single step appears as a

high frequency pulse to the accelerometer. The pedometer then counts the steps and multiplies it

by an average step distance to calculate a linear displacement. Some more advanced pedometers

figure in user height and age to determine the average step size. Their results are at best an

estimation.

The high resolution and sensitivity of the accelerometer allows it to sense the slightest vi-

brations. For this reason, seismologists use accelerometers inserted into the ground to measure

seismic activity such as earthquakes and volcanic eruptions. The ability to measure vibrations is

a beneficial feature to the Vibe platform. It was previously stated that the original intent of this

system was to measure epileptic tremors in the body to determine the onset of a seizure. Tremors

5

in the body are typically highly rhythmic. Turner et al. report that normal physiological tremors

usually have a frequency of 8 to 12 Hz, whereas pathological tremors usually occur in the 4 to 7 Hz

range [17]. In order to detect these tremors, the system must first be able to distinguish rhythmic

from arhythmic vibrations. Secondly the system must be able to detect the frequency of the vibra-

tions to distinguish between normal and pathological tremors. In the signal processing field this

is typically done using a discrete Fourier transform. The Fourier transform converts time domain

represented data and gives a representation of the data in the frequency domain. This allows the

system to determine the dominant frequencies present in the acquired data. The Fourier transform

is a quite computationally intensive task, especially for a mobile, constrained-resource system. For

this reason a simplification of the Fourier Transform, known as a Fast Fourier Transform (FFT)

is typically utilized. An FFT significantly cuts down on the number of operations required to

determine the frequency domain representation of the data.

Gyroscope

Another integrated MEMS motion sensor that is commercially available is a gyroscope. Unlike an

accelerometer, a gyroscope measures angular velocity. These movements were referred to in flight

dynamics as roll, pitch and yaw. Roll is a rotational movement about the x-axis of an object,

where the x-axis corresponds to direction of overall motion of the object (line of flight). Pitch is

rotation about the y-axis and finally yaw is rotation about the z-axis. Figure 3 shows a visual

representation of the roll, pitch and yaw movements.

Yaw

Z

YX

PitchRoll

Figure 3: Roll Pitch and Yaw Motion

6

One common type of MEMS microgyroscope is known as the vibrating structure gyroscope [18].

In these devices, similar to an accelerometer, a known mass is suspended by polysilicon springs.

When the mass experiences a rotational movement a Coriolis force is exerted on the mass. The

Coriolis force is the product of the mass and the Coriolis acceleration (following Newton’s second

law). The acceleration gives a value that is proportional to the rotational velocity. However, in

order to determine the rotational rate, the mass must oscillate at a known frequency. In addition,

the oscillation velocity must remain stable throughout the rotational motion. Xie et al. introduce

the mechanics required to calculate the rotational rate given the Coriolis acceleration and the

vibration velocity shown in Equation (2.1) [18].

~Ω =~ac2~v

(6)

Where ~Ω is the vector rotational motion, ~ac is the Coriolis acceleration and ~v is the vibration

stimulus velocity. Similar to the accelerometer, the Coriolis force is typically measured as a change

in capacitance between the drive comb fingers and the sense comb fingers [7].

The inclusion of a gyroscope in a human body motion platform has many benefits over a

system with solely an accelerometer. Firstly, using the accelerometer to determine distance gives

a linear displacement in the x,y & z axes. The gyroscope gives rotational rate and thus allows for

determining angular displacement in all three axes. On the human body, this allows for a better

understanding of movements about a joint. Also, since the data reported from the gyroscope is a

velocity, a rotational displacement can be calculated with only a single integral of the rotational

velocity. This provides better accuracy over the accelerometer. The integral is a very simple

process in a discrete system. The sampling rate of the gyroscope is configured by the user so the

time interval between each sample, ∆t, is known. The sample spacing multiplied by the measured

value provides the displacement over that small period of time. This is shown in Figure 4.

If the sample spacing (∆t) is 10ms, for example, and the gyroscope reports an angular rate in

the yaw axis of a 100 degrees/second (dps), the angular displacement (Θ) can be determined by

multiplying ∆t by the angular rate (Ω) measured (7).

~Θ = ∆t ∗ ~Ω (7)

Summing this operation over all N data points sampled, gives the final relative angular displace-

7

Δt

pn

pn+1

t

v

Figure 4: Discrete Integral of Gyroscopic Motion Data

ment(8).

Ωfinal =

N∑i

∆t ∗ ~Ωi (8)

Equation (8) corresponds to the definition of a continuous integral, when ∆t is made infinitesimally

small.

The combination of the accelerometer and gyroscope in a single system is commonly referred

to as an Inertial Motion Unit or IMU. Utilizing a three-axis accelerometer (x,y,z) and a three-axis

gyroscope (roll,pitch,yaw) provides a total of six degrees of freedom for motion sensing. With

proper sensor fusion algorithms, this can provide a great deal of information about the movement

of a single joint.

Digital Compass (Magnetometer)

So far, the motion sensors introduced provide data that is relative to the reference frame of the

object. That is to say, there is no absolute positioning with respect to earth, with exception to the

static inclination data from the accelerometer. The accelerometer can only provide the inclination

when the device is relatively static. Dynamic motions disrupt the ability to determine the inclina-

tion as the user is adding acceleration to the system. Devices such as a global positioning system

(GPS) provide a global reference to the device irrelevant of dynamic motions being experienced

by the system. The caveat of a GPS system is that it relies entirely on satellite communication,

which is easily obstructed by bad weather or indoor environments. For this reason, GPS is not

deemed reliable for body motion sensing systems, which may be predominantly used indoors.

8

Another form of absolute positioning is global compassing. Currently, MEMS compasses exist

to determine the heading a device, similar to an analog compass. The inclusion of a compass in

a body motion sensing platform enables for greater accuracy in dead-reckoning algorithms. Dead-

reckoning is the process of integrating motion data over time to determine the relative position

of a person or object from a starting position. Using the heading in combination with linear and

angular displacements from the IMU, the system can estimate the relative displacement from a

reference position. The compass, while not reliant on satellite communication is not impervious to

all environmental conditions. Similar to an analog compass, the MEMS compass orients itself based

on the magnetic field of the earth’s poles. If a strong magnet is within close proximity to the device,

the compass will be affected by its magnetic field. The sensitivity of the HMC5843, for example,

starts to degrade when an external magnetic field of 20 gauss or larger is experienced [9]. To put

this into perspective, a small bar magnet, about 3 grams in weight, may exert a magnetic field

intensity of over 250 gauss at the surface of the magnet [13]. The earth’s magnetic is approximately

0.5 gauss. This sensitivity is considered a more acceptable tradeoff than a GPS system which is

inoperable indoors. In addition, integrated GPS systems require large antennas and consume a

greater amount of power over a digital MEMS compass. This imposes a great constraint on a

small, wearable sensing device.

2.2 Body Area Sensor Networks

So far, viable sensors for a single, wearable device have been described. The human body contains

a large number of joints and is capable of complex motion. If an application requires an accurate

description of full body motion, a single device will not be able to report such complexity. Each

sensing node can be thought of as a single point in space. If, for example, a single device were

placed on the wrist, that device would not be able to describe the complex motions in both the

elbow and shoulder joint. If multiple nodes are placed on the body (e.g. an additional node on the

upper arm), a greater deal of accuracy is possible. Extending this idea over the entire body, one can

imagine a network of devices sensing motion and communicating to depict full body motion. This

network of devices is known as a Body Area Sensor Network (BASN). Currently much research is

being done in utilizing body area sensor networks in hospital patients to relay ECG, blood glucose

9

and other vital information to a central node automatically [15].

Similar to traditional computer networking, there are many considerations in creating BASNs.

Network topology is one of those considerations that is important in efficiently relaying data

throughout the network. The topology is typically driven by the end application. For example,

an application that is only measuring vibrations in the hand may only consist of one or two

nodes attached to the hand that directly communicate in a peer-to-peer style for signal processing

operations such as a data correlation. In a larger system, where full body tremors are being sensed,

and hence more nodes are present, a peer-to-peer topology may be inefficient. One commonly used

topology is the star topology, depicted in Figure 5.

CN

LN

LN

LN

Figure 5: Star Topology Body Area Sensor Network

Note that all nodes have a wireless connection to a central node (CN). The central node may

serve as a sensing node as well, or may simply process incoming data from leaf nodes (LN). The

central node may also contain a wireless connection to a home base station or a cellular network

connection to relay data to a central server. This is particularly useful for applications where a

10

physician or researcher wishes to store data for post-processing or diagnosis.

In addition, a caretaker node (CTN) may be wirelessly linked to a body area sensor network

to receive status updates, when in range of the body area sensor network (see Figure 6). This

is particularly useful for the application that inspired the Vibe motion sensing platform. If the

teenage boy mentioned, was outfitted with a body area sensor network that was monitoring for

epileptic tremors, the parent could wear a caretaker device that would receive a wireless alert if a

serious condition was detected by the body area sensor network.

LN

LN

LN

CN CTN

Figure 6: Caretaker Node Attached to Body Area Sensor Network

Security

Another concern in any networking environment is security. The motion sensing platform being

proposed is not in control of any bodily functions, but in order to respect individual privacy and

disallow external entities from monitoring private user data, proper security need to be in place.

Many encryption technologies currently exist to securely transmit data from one node on a net-

work to another node. The Advanced Encryption Standard (AES) is a commonly used encryption

methodology based on a symmetric-key. Both the sending and receiving nodes use the same key of

a standard bit-width to encrypt outgoing plaintext messages into cipher-text and decrypt incom-

ing cipher-text into the original plaintext. In a small constrained device, these operations can be

relatively taxing. Thus, direct hardware encryption/decryption support is desired to both increase

11

the performance and lower the power cost associated with encryption and decryption.

The need for security arises from the fact that the radios contained in the body area sensor

network radiate data into the environment, allowing intruders in proximity to detect the radio

signal. Currently work is being done by Tsouri et al. to construct wireless radios that propagate

radio waves over the surface of the body and not out into free space [16]. The waves that propagate

the wireless signal are known as creeping waves. This is not only advantageous from a security per-

spective, but also has implications for lower-power systems. The body heavily attenuates wireless

signals and thus communication between nodes in front of the body and in the rear of the body

may require a higher output power using traditional radios.

Constructing a body area sensor network topology alone is not enough to realize efficient data

processing over the network. The application developer must decide how to deal with incoming

data efficiently. For example, a less-capable node may simply sense data and relay all sensed data

to a central processing node to process the data. Streaming raw data to the central node will

require frequent wireless communication and may not be efficient. In addition, the network may

not scale well as multiple sensing nodes are added. Relaying all raw data to a single, central node

will require that the central node has the bandwidth necessary to receive and process all incoming

data from leaf nodes. The Vibe motion sensing platform provides the ability to stream raw data

to a central node, but strong emphasis is placed on pre-processing data in the leaf node before

communicating to the central node. All nodes have significant processing capabilities to allow for

pre-processing. In addition, large storage capabilities allow for leaf nodes to log data quietly for

long periods of time before relaying data in “burst-mode” to a central node. This is a more efficient

method for systems that do not require real-time response to motion data, but store data later for

a physician or researcher to post-process or use for diagnosis purposes.

3 Previous Work

Currently much work is being done in the field of body area sensor networks and motion analysis.

This section reviews some of the work previously reported in these fields. This section helps

researchers understand the tradeoffs of different designs and better understand how Vibe differs

from previous art.

12

3.1 Wireless Body Area Sensor Network Research

Many researchers in the field of wireless body area sensor networks utilize commercially available

systems such as the Crossbow Motes (http://www.xbow.com/). These systems were originally

developed with the intention of creating mesh networks of environmental sensors that sense data

and relay it through other motes to a central node where processing occurs. The challenge in using

devices like the Crossbow Motes is that the form factor and wireless protocols are not well-suited

for body area sensor networks. Each mote is powered from AA batteries and occupies a large

volume that makes it difficult to wear on the body. Additionally, each mote has a cost of around

$150.00 that makes it expensive to create body area sensor networks with up to 6 nodes.

Currently a research group led by Kristofer S. J. Pister at University of California Berkley is

working on Smartdust motes with a size of a cubic millimeter [12]. There are significant benefits

to a device that size, however there are current technology barriers that must be broken to realize

a device of that size. Katz et al. note some of the challenges faced by the system, including the

requirement of line-of-sight optical communication between nodes for low-power networking. A

node on the leg, for example, may not always have line of sight communication to a node on the

wrist, and thus optical communication may not be well-suited for body area sensor networks. Sig-

nificant breakthroughs in the area of energy harvesting are also necessary to power the Smartdust.

Current solar cell technology still has a power conversion efficiency of less that 25% with current

records reported of 24.2% by Sunpower Corp. in San Jose [3].

Jovanov et al. propose a wireless body area sensor network architecture, but still they use

commercially available nodes from a company Telos that are large in volume and not discretely

wearable [15]. Another feature of their architecture is utilizing a wireless link to a mobile device

with a more powerful radio such as a WiFi radio or a cellular radio to relay data to a remote server.

This requires the user to carry a separate mobile device to relay information over the internet.

Additionally it imposes compatibility issues as the mobile device must support an interface for the

body area sensor network to communicate with. One of the goals of Vibe was not to require the

user to carry any devices other than the sensor devices that make up the Vibe body area sensor

network. Also in most applications the need for an ”always-on” connection to a remote server is

questionable. If the application requires that logged data be pushed to a remote server for post-

13

processing, the need for frequent upload can be mediated through cheap, large internal storage

where motion data is stored until a connection to the remote server is convenient (e.g. through a

base station in the home).

3.2 Human Motion Analysis Research

Gavrila et al. report great success in using computer vision to accurately track human motion [6].

Vision systems have an advantage in that they have an external view of the body to which they can

match patterns to determine body motion. Many movie producers use Motion Capture systems

where markers are placed over the body and actors are filmed. The video is then processed and

the motion is extracted from the movement of the markers. These systems require a large amount

of specialized hardware and are far too expensive for frequent clinical use. Vision-based systems

also require that users stay within the visual field of the cameras capturing the motion. Obviously

this is not practical for a user who may wear a system throughout their normal daily tasks.

Fontaine et al. constructed a human body motion analysis platform solely using accelerometers

and compasses to track motion [5]. They note accurate tracking of the full range of body motion is

difficult given that the human body has over 200 degrees of freedom (DOF). Each sensing node in

their system is physically large which is attributed to the lack of 3-axis accelerometers at the time

of writing. Today, three axis accelerometers, gyroscopes and compasses are available commercially

in integrated packages making single planar devices possible. The lack of wireless communication

also requires that conductive thread be routed through clothing to connect the devices. This is

inconvenient for mass clinical use as the type of clothing worn will have to be specialized to allow

for multiple node connectivity. Vibe addresses this issue with a full wireless system.

Farella et al. developed a wireless human posture tracking system for human computer in-

terfacing (HCI) [4]. Their setup uses tri-axial accelerometers only to detect body motion. The

disadvantages of an accelerometer-only based system were explained in the Theoretical Develop-

ment section (2). Their prototype system was not designed for wearability and is physically large.

In addition to posture, they also report their research on gait analysis. They describe algorithms

developed to distinguish between discrete gait profiles such as walking up stairs, walking in place

and walking forward rapidly. Despite only having an accelerometer-based system they report

14

success in achieving their objectives.

As it is seen, there is a significant amount of work in both the body area sensor network and

human motion analysis fields. Vibe addresses some of the issues noted in these fields including

design for wearability and removing the need for external mobile devices or specialized clothing to

operate as designed.

4 Concept Selection

In designing the Vibe platform, the highest priority was wearability and battery lifetime. Even with

a very sophisticated system capable of intensive data processing operations, the system would not

serve its function if it could not be worn discretely on multiple areas of the body. In addition each

device must possess enough charge capacity to perform its function over a long period time and

reduce the time a device spends in a charging mode. These elements largely drove the constrains

of the system in terms of user interface, processing capability and sensing capability. However,

Vibe certainly doesn’t lack in its core functionality and manages to fit a large amount of sensing

and data processing capability in a small volume.

During the system design phase of Vibe, a commercial market analysis was conducted. Eight

commercially available devices were surveyed and compared based on certain aspects such as

sensing capability, battery life, form factor, data storage, ability to network multiple nodes and

the ability to create custom applications. Figure 25 in Appendix A: Concept Development provides

an analysis of how each of these eight devices compares to the specifications developed for Vibe.

This analysis gave a starting ground for realizing a feature set that was feasible for a device of the

targeted volume. The prominent feature set selected for Vibe is described in this section.

4.1 Wearability

One of the highest priority features was the wearability of Vibe. Vibe has the ability to create

dynamic body area sensor networks composed of up to 6 nodes. In order for a system of this

magnitude to be feasible, each node must be able to be worn on the body without discomfort or

obstruction to daily activity. In addition, Vibe will not be composed of any materials that are

hazardous, sharp or could cause an allergic reaction. Each device will be intimately worn on the

15

body and it is vital that the user is perturbed as little as possible. Lastly, each node will be durable

enough to withstand normal wear and tear throughout daily activity for at least five years.

4.2 Sensing Capabilities

The sensing capability of Vibe is crucial to fulfilling its intended purpose. Small space constraints

and a low-power budget make some sensors such as GPS impractical. It was desired that each

node have a rich set of motion sensing capabilities. Also, both relative and absolute positioning

sensors were desired to allow each device to report its orientation and motion accurately. A 6-

axis IMU consisting of a gyroscope and accelerometer was chosen for this purpose. In addition, a

digital compass was chosen for absolute positioning. The fusion of this sensor data provides a rich

understanding of motion experienced by a sensor node. The sampling rate specification for a single

sensor was set at 50Hz to accommodate for physiological parameters with relatively large margins.

In addition the dynamic range of each sensor was taken into careful consideration to determine the

suitability.

In profiling body motion, other body parameters such as body temperature may be useful. For

example, if a gait analysis algorithm is trying to determine if a user is running, it may compare

the body temperature to the ambient temperature to determine if the user’s body temperature

is elevated due to physical activity. Thus, it was desired that Vibe incorporate an ambient and

body temperature sensor. Lastly, it was desired that the wireless front-end allow for an interface

with external sensors, such as heart rate monitors, in the event that additional sensory information

not contained in each node was necessary. This capability gives great flexibility to the application

developer.

4.3 Data Processing

Motion data processing requires a substantial amount of computational ability that can be difficult

to achieve in such a small volume with a low-power budget.Each sensing node will at a minimum

of capabilities, be able to retrieve raw sensor data and convert the data into the respective working

unit. For example, if an analog signal proportional to acceleration in the z-axis of the device is read

by the processor, the processor will be able to retrieve the digital conversion and map the data

16

to an acceleration in the form of unit g-force. In addition, it is desirable that each node possess

the ability to perform basic signal processing functions such as a Fast Fourier Transform (FFT)

or discrete integral of data over time. The application of both of these techniques was introduced

in the Theoretical Development section (2.1).

4.4 Data Logging

In order to maximize the battery life of Vibe, the platform emphasizes heavy use of data logging

as a means of saving data to be pushed to a server or processed over the body area sensor network

at a later time. Frequently powering up the radio to push data over the body area sensor network

or to a remote server will quickly degrade battery life. Data logging is an internal means of storing

data that can be later pushed to another node in the body area sensor network or a remote server

in a “burst” fashion. Given many sensors operating at a high sampling rate, data logging can

quickly consume a large amount of storage that cannot be found in small mobile processors. For

this reason, a large internal storage is desired to be able to hold data logs for a relatively long

period of time (e.g. a days worth of data logging). Obviously for some applications streaming data

constantly is necessary, but this will be at the expense of a reduced battery life. The logs will be

maintained automatically by the system and give the application developer simple tools to start,

stop, edit and retrieve logs from the body area sensor network.

4.5 Sensor Network

Each node will have a low-power, wireless interface that allows for a dynamic body area sensor

network to be configured easily. There will be a distinction between a master node and leaf nodes,

as found in a star topology network. The application developer, for example, may wish to make all

transfers initiated by the central or master node to avoid data collisions. Peer-to-peer connections

will also be possible, in the case, for example, that two nodes are performing a data correlation

operation, looking for certain motion profile matches. Each node will be able to maintain a reliable

wireless link to any node in the body area sensor network. The human body can severely attenuate

a wireless signal and thus some control on the output power will be available. In addition, there

will be a simple addressing scheme that allows a node to direct a wireless message to a specific

17

node and identify the sender of an incoming node.

Security was also mentioned as an important feature for a body area sensor network. Since

wireless radios using creeping waves [16] are currently not commercially available, and radios

radiate signals into the environment, some form of cryptographic security will be present. Ideally,

the security system will be hardware accelerated to improve the performance and reduce system

overhead. A standard security protocol such as AES will be used to leverage the robustness of

modern security protocols.

In addition, it would be beneficial if the radios provided an automatic or manual interface

for channel hopping, to reduce the impact of wireless interference. Many commercially available

radios operate in the unlicensed Industrial, Science Medical (ISM) research bands of the frequency

spectrum. The abundance of wireless devices operating in this band makes robust communication

difficult. Channel hopping or frequency agility is one technique for dealing with this issue.

The baudrate of the wireless communication between nodes will be high enough to support the

transport of motion data efficiently, while still maintaining a low-power budget. Given the number

of sensors described in this section with the specified sampling rate, a baudrate of 100kbps is found

to be substantial for streaming applications.

In the Previous Work section it was noted that many researchers had constructed body area

sensor networks that maintained a connection to a third-party device such as a mobile phone or a

PDA. That third-party device also maintained a WiFi or cellular network connection to relay body

area sensor network information over the internet. Vibe takes a different approach to this problem.

A connection to a remote server allows the body area sensor network to push data to the server to

be stored and post-processed. The scarcity of truly open WiFi networks makes it quite rare that a

WiFi connection will be readily present. Most WiFi networks, including “open” networks in cafes

and hotels, require some password or agreeance to a terms of use policy before the network may be

utilized. This is a cumbersome process for a user from a small mobile device. A cellular network

connection, such as a 3G network connection, is much more abundant and consistent, however it

requires that a user maintain a specific type of cell phone that has an interface to the body area

sensor network. In addition, if the user is not a normal subscriber to a cellular network plan, it

requires that they pay a monthly fee to enable this connectivity for the body area sensor network.

18

The end result is a system that is not user-friendly or simple to use. The goal of Vibe is to make

all wireless transactions transparent to the user. It is presumed that with a large internal storage

capable of logging data for an entire day or longer, a constant connection with a remote server is

unnecessary. Vibe will have the ability to communicate with an internet connected base station

residing in the user’s home or the physician, researcher’s office. When the user returns home,

the base station automatically discovers the body area sensor network and initiates a transaction

with the base station. The body area sensor network may then upload all logged data to the base

station to be written to the remote server for a researcher or physician to post-process. In addition,

the body area sensor network devices will have the ability to be wirelessly updated, so if a new

firmware version is available on the remote server, the base station may push this image to the

body area sensor network to update all devices. While the user is away from home and out of

range of the base station, the body area sensor network continues to log data quietly and conserve

more power compared to a system that is constantly connected to a remote server. This model

provides the convenience of a remote server connection while respecting the low-power nature of

the body area sensor network and freeing the user from the cumbersome task of linking the body

area sensor network to a WiFi or cellular network connection.

4.6 User Interface

The central node of the body area sensor network may periodically need input from the user

depending on the application. Additionally, a node may serve an auxiliary function such as a

timekeeping function for nodes worn on the wrist. To accommodate for these situations, Vibe will

provide simple user input/output capabilities.

Vibe will have two user input buttons for general input. This may be used to select functions

described in an application or even for auxiliary functions, such as setting the time on a node

that provides timekeeping capabilities. Two buttons is considered sufficient since one button can

perform a scrolling function (e.g. scrolling through the hours to set the time) while the other

button provides a confirmation function (e.g. setting the hour). Additionally, Vibe will have a

port for a charging cable that will allow the user to charge the internal battery. The port will be

standard (e.g. a microUSB port) so that charging is accessible.

19

Vibe will also have a small display to report information to the user or perform an auxiliary

function. Even though a device that is worn the upper thigh, for example, does not need a display,

a small display was chosen to be integrated in all devices to keep the hardware uniform and reduce

the development cycle time. It is extremely important that the display’s power consumption be

carefully managed. This includes adjusting the brightness of the display, turning it off during

periods of inactivity and selecting a display technology that is appropriate for the specified power

budget.

4.7 Battery Life

Perhaps one of the most important features of the system is the battery life. Many power man-

agement techniques have already been described, such as internally logging data and performing

burst wireless transfers between nodes or to a central base station. These and many other power

management techniques will be employed to maximize the battery life of Vibe while not hindering

its core functionality. In fact, an extended battery life enhances the functionality of Vibe. A

battery life of 2-4 weeks is desired for typical applications so that devices spend most of their time

performing their intended function and not out of service charging. The Vibe developer applica-

tion programming interface or API, should provide many of these power management techniques

transparent to the developer and give the developer the tools necessary to further optimize the

battery life of their applications in order manage power efficiently. The API does not presume

advanced knowledge of power management techniques, but basic principles such as the frequency

of powering up the radio and other peripherals should be understood in order to maximize battery

life.

All of these specifications and device capabilities were derived from customer needs developed

during the evaluation of a tremor sensing application. Those customer needs can be seen in

Appendix A: Concept Development in Figure 27.

5 Design Aesthetic

In order for the Vibe body area sensor network to be feasible, each sensor device must be designed

with wearability in mind. To achieve this, a collaboration was setup with the Industrial Design

20

department at RIT. The hardware engineer worked hand-in-hand with two design students to

design a form factor that was wearable. In addition, it was desired that only a single form factor

be produced to reduce the number of pieces to manufacture. Each Vibe sensor node was designed

to be equally capable and versatile. There is no wrong sensor to place on any part of the body.

Any sensor can be placed in any position and the Vibe sensor network will adjust to accommodate

this configuration. This provides increased convenience to the user but is challenging from a design

perspective. It’s challenging to design a device that is easily wearable on the wrist, but can also

be worn just as comfortable on the upper arm, for example.

The Vibe sensor node was designed with the goal of being as unobtrusive as possible. This

not only means being comfortable and seemingly non-existent when worn, but also being discrete.

If the system were conspicuous, this would potentially expose a physical condition to others,

similar to someone who must carry an oxygen tank to assist breathing. This can be a stressful or

embarrassing social situation.

To achieve the goals outlined, it was decided that all of the hardware would be housed in a

compact form referred to as a pebble. The pebble would provide a common connection interface

that could easily be attached to a proper fitting to be worn on the body. For example, the pebble

could be attached to a wristwatch band to be worn on the wrist or fit into an elastic band to be

worn on the upper thigh. This keeps the hardware consistent over each device, while allowing a

custom fitting to be designed that best fits the application area. In addition, each fitting will keep

the device discrete. So a device that is worn on the wrist will look like a wristwatch or a bracelet.

Providing the auxiliary function of a timepiece, a device worn on the wrist can be indistinguishable

from a watch, even though it is performing a clinical function. The design of the body is shown in

Figure 7

An alternate view is shown in Figure 8 with the microUSB charging adapter port visible on

the side of the device. This port also functions as a debug port for hardware testing and initial

programming.

On the bottom of the device, there is a rectangular, anodized aluminum plate. There are two

main purposes for this metal plate. The first is to conduct heat from the skin of the user, internal

to the device for temperature measurement. Additionally, the plate provides a surface upon which

21

User Buttons

Display

Band Lug

Polycarbonate Faceplate

A

B

Figure 7: Pebble Design Housing Vibe Sensing Node Hardware

Figure 8: Pebble Design Housing with microUSB Charging Port Shown

the piezoelectric buzzer may resonate. The plate is shown in the bottom view of the pebble in

Figure 9.

On each end of the pebble, there is a housing for the band lugs. A small “spring bar” is

threaded through a loop at each end of the fitting band and press-fits into the pebble lug housing

(see Figure 10).

This requires a minimal interface on the fitting band, in the form of a small loop to thread the

spring bar through. One side of the pebble houses two buttons for user input. The opposite side

reveals a microUSB connector for charging the internal battery. The top the of pebble is encased

in a clear polycarbonate revealing the display to the user. The display makes up most of the face

22

Figure 9: Bottom View of Vibe Pebble

Fitting Band

Spring Bar

Spring Bar Pin

Vibe Device Body

Band Lug Housing

Figure 10: Fitting Band Interface to Vibe Device

of the device allowing for a rich user interface. On the bottom of the pebble is a small square metal

plate mounted flush with the body frame. The purpose of this plate is two-fold. First it provides

a plate for the piezoelectric speaker to resonate sound out of the device and also couples heat from

the body to the internal temperature sensor that measures the temperature of the skin. This in

conjunction with an ambient temperature sensor allows for the system to better understand the

physical state of the user.

The device is completely assembled from the top and the entire body frame, except for the

metal plate is composed of a single piece. First, the metal plate is mounted in the frame opening

using a small amount of adhesive. Next, the temperature sensor board and piezoelectric speaker

23

are mounted on the metal plate and concealed with adhesive film. This isolates the sensor from

the rest of the device and ensures that the speaker lay flush with the metal plate to keep the

resonating surface area uniform. Next, the battery and main logic board, housing all of the

electronic components and the display are lowered into the housing. The buttons and the microUSB

port should align properly with their ports. Lastly a black film is applied to the top of the main

logic board to reveal only the active area of the display to the user. The polycarbonate lens fits

over the top of the display and film to seal the unit. It is adhered to the unit using a small amount

of adhesive around the inner ridge of the device. This top-loading method provides an easy way

to assemble the devices rapidly.

Figure 11 shows an exploded view of the pebble assembly. Note how the device is loaded from

the top, as previously stated. The button assembly is shown outside of the device for clarity. When

assembled, it is side-loaded into the housing from the inside of the body.

Display Faceplate

Display Bezel Film

OLED Display

Main Logic Board

Lithium-Polymer Battery

Aluminum Plate

Pebble Body Shell

Buttons

Set Screws

Figure 11: Exploded View of Pebble Assembly

The body of the device was created using a stereolithographic process (STL) performed locally

24

at RIT, in cooperation with the Brinkman Lab facility in the Industrial Systems Engineering

Department. The STL process (aka 3D printing) allows for both the buttons and the body of the

device to be produced simultaneously. A single device can be prototyped in under an hour allowing

for rapid prototyping. The polycarbonate lens was machined locally in Rochester from a single

sheet of LexanTM 1. The metal plate housing the temperature sensor and piezoelectric buzzer was

also machined locally using a computer numerically controlled (CNC) machine.

6 System Architecture

One of the first challenges in developing Vibe was defining the system architecture. The system

architecture includes the architecture of the hardware and software. It describes, at a high-level

abstraction, the logical interconnection of hardware and software components. Creating a well-

defined system architecture before the first hardware iteration has proved to be a valuable tool for

ensuring that the original intent of the device is fulfilled as the design iterates. The system archi-

tecture is also very useful for the application developer. Without in-depth knowledge of embedded

systems or low-level firmware, a developer can understand the functionality and composition of a

system from a high-level perspective.

6.1 Hardware Architecture

The first architectural design task was to pinpoint the set of hardware to perform the desired

motion tracking and wireless capabilities, while maintaining tight space constraints and a low-

power budget. The goal was to design the system with a rich set of features utilizing as little

hardware as possible. Minimizing the Bill of Materials or BOM in terms of component quantity

and cost means that devices can be made cheaper and faster. With the possibility of up to six

devices worn on the body at any given point, it was vital that these devices be relatively inexpensive.

The goal was to keep each device less than $80 for prototype units and hopefully a fraction of that

cost if production quantities were to be produced.

The hardware architectural block diagram can be seen in Figure 12. Each functional block in

the hardware architecture is described and design choices explained in this section.

1LexanTM is a trademark of SABIC Innovative Plastics

25

65K Color OLED DIsplay CC430 Wireless SoC PMU

Regulator

Battery Charger

6-axis IMU

Compass

Ambient Temp Sensor

Body Skin Temp Sensor

External Flash

Power Plane

Wireless Front-End

Sensor Array

Figure 12: Commercially Available Device Comparison Matrix

CC430 Processor & Wireless Front-end

At the heart of the architecture is the CC430 wireless system-on-chip (SoC). One of the main

concerns in building Vibe, originally, was the amount of area a wireless front end would consume on

the PCB. At the time the architecture was designed, there were a small number of microcontrollers

that integrated a wireless radio. The CC430 from Texas Instruments and the STM32W from ST

Microelectronics were the two major contenders. An analysis of the two processors for the Vibe

platform gave evidence that the CC430 was the strongest contender. Figure 26 in Appendix

A: Concept Development shows a comparison of the two microcontrollers with their prominent

features compared.

The CC430 was chosen for its superior power capabilities, large set of auxiliary peripherals

such as a Real-Time Clock (RTC) and increased wireless data baud rate. In addition, physical

samples of the CC430 were available sooner than the STM32W. The CC430 is a 16-bit microcon-

troller from Texas Instruments, integrating an ultra-low power MSP430TM 1 processor core and

a wireless, low-power sub-gigahertz RF transceiver module in the same package. In addition, the

CC430 includes many valuable features for Vibe including 128-bit hardware accelerated AES en-

1MSP430TM is a trademark of Texas Instruments Incorporated.

26

cryption for encrypting/decrypting wireless data transmissions, two independent serial peripherals

for sensor communication, a dedicated DMA useful for data logging to flash and a 32-bit hard-

ware multiplier useful for data processing functions such as an FFT. In addition, the developers

were very familiar with Texas Instrument’s development tools and MSP430TM family of micro-

controllers. The STM32W did have an advantage of being a 32-bit ARM based processor with

built-in 64-bit multiplier, but at the expense of a larger power consumption and lower wireless

data baudrate, which were two important requirements. The CC430 also offered a few options

for package size, allowing the size of the device to be scaled between development iterations and

final prototype iterations. Another attractive feature of the CC430 is the relatively low number of

passive components necessary to match the impedance of the antenna. Texas Instruments offers

various antenna design application notes which are useful for ensuring that the antenna is properly

tuned for maximum range and efficiency.

Power-consumption is of paramount importance in a battery-powered, mobile device. The

CC430 microprocessor core consumes just 180µA per MHz CPU clock speed. The maximum clock

speed of the CC430 is 24MHz, for a total core consumption of only 4.3mA at maximum clock

speed. The clock speed of the processor can be adjusted accordingly to accommodate speed, while

respecting power consumption constraints. The CC430 also contains multiple power-down modes

with various degrees of power scaling. The standby mode (LPM3) retains RAM, pin states and

keeps the RTC active at only 1.7µA. The lowest power mode, LPM4, retains RAM only, with a

1.0µA current consumption. In addition, the CC430 can wake from standby mode in only 5µs.

This means that the CC430 can be placed in a standby mode very frequently to reduce power

consumption. The user APIs will provide provisions for managing low-power modes while the

device is idle. In addition, API calls will be available for the user to manually place the device in

a lower-power mode.

The CC430F5137 and CC430F6137 devices contain 32KB of flash for application and data

storage. The executable code and user’s static data exist in the same memory space on the MSP430

family. There is an additional 512 bytes of storage in flash to be used for a bootstrap loader. Vibe

utilizes this space to implement a wireless boot strap loader. When queued, the device will enter

the boot strap loader section of flash, where it will search the field for a base station or console

27

device wishing to transfer a new firmware image. If a link is successfully made within the timeout

period, the device will begin downloading the firmware image. The image is verified with the host

to ensure successful reception. If the image passes verification, it is then loaded into the system

flash. An automatic reset starts the device executing the newly downloaded firmware image.

The CC430 is available in a 9x9x1mm, 64-pin package (CC430F6137) and a 7x7x1mm, 48-

pin package (CC430F5137). Besides offering an increased pin-count, the only difference between

the CC430F6137 and CC430F5137 devices is the inclusion of a dedicated LCD driver in the

CC430F6137. Since a static LCD is not being used, the LCD module is unnecessary and the

pin count and space constraints alone drove the size of the device in the final implementation.

Motion Sensors

The Vibe platform achieves accurate tracking capabilities thanks to a rich set of motion sensors.

The three motion sensors that were decided on for the platform are an accelerometer, gyroscope

and digital compass. The application of each of these sensors was described in the Theoretical

Development section and the reasons for which these three were chosen was explained in the

Concept Selection section. The accelerometer selected, the CMA-3000-D01 from VTI Technologies,

is currently the smallest triple-axis accelerometer available on the market at the time of writing.

It is housed in a 2x2x0.95mm wafer level package. In addition, the current consumption is also the

lowest on the market with only a 11µA current consumption at a 40Hz sampling rate and a 1.7V

operating voltage. The accelerometer has the capability of measuring acceleration at a sampling

rate of up to 400Hz. This is well above the necessary sampling rate of physiological activity. The

initial target sampling rate was 50Hz for each sensor. In addition the sensor offers a flexible serial

interface of either inter-IC (I2C) or serial peripheral interface (SPI). Both of these protocols are

supported by the CC430.

The gyroscope was initially a two-chip solution consisting of a dual-axis (roll, pitch) and single-

axis (yaw) analog gyroscopes. This solution was implemented on the development board, but has

been recently superseded by a digital triple-axis microgyroscope in a single 4x4x1mm package, the

ITG-3200 from InvenSense Incorporated. The ITG-3200 not only has the advantage of being a

single-chip solution but it also provides a digital interface which reduces the amount of raw data

processing necessary to convert to working units. With an analog sensor, the voltage must first be

28

sampled, digitized and then mapped to a working unit (e.g. degrees per second for a gyroscope).

The ITG-3200 reports roll, pitch and yaw motions in degrees per second and is accessed over an

I2C interface.

The combination of the accelerometer and gyroscope produces a six-axis inertial motion unit

(IMU) used for accurate motion tracking. As previously stated, these sensors primarily report

sensor data that is relative to the frame of the device. To achieve absolute positioning for a

better understanding of human body motion, a digital compass was selected. The compass, the

HMC5843, is a triple-axis digital magnetometer from Honeywell International Inc. The sensor

was chosen for its small package size of 4x4x1.3mm and high sensitivity. Many dual-axis digital

compasses perform poorly when the device is not held in a level state, but the HMC5843’s third

axis allows for the directional heading measurement to be compensated when the device is tilted.

The inclusion of the compass will allow the developer to write applications that are aware of not

only motion relative to the device, but also relative to the environment.

Temperature Sensors

In addition to the array of motion sensors that the architecture includes, Vibe also supports two

temperature sensors; an ambient and skin temperature sensor. The motivation for including these

sensors was to enhance the ability to match motion profiles to incoming motion data. For example,

to determine if a user is running, the developer may attempt to match a profile of running motion

to sensor data while checking for elevation in body temperature. This allows the developer to more

accurately distinguish between certain activities.

To measure temperature, the Texas Instruments TMP112 digital temperature sensor was cho-

sen for both the ambient and the skin temperature sensors. The sensors were chosen for their

high-accuracy over the desired range. This range includes -20 to 45 degrees celsius for ambient

temperatures and 30 to 38 degrees celsius for skin temperatures. In addition, the TMP112 commu-

nicates over a digital I2C interface that integrates easily into the existing sensor interconnection.

Both the gyroscope and the compass also utilize the I2C bus to communicate with the CC430. The

TMP112 also allows the user to specify the least-significant bit of the sensor’s slave I2C address,

so two temperature sensors can be placed on the same I2C bus. This is important since both the

ambient and skin temperature sensors are TMP112 devices. The digital sensor also provides the

29

convenience of directly representing the temperature in degrees celsius. This is advantageous over

an analog sensor whose output voltage must be mapped to a voltage through internal computation.

In addition the analog signal is more susceptible to board-level noise affecting the accuracy of the

temperature sensor reading.

Each TMP112 consumes only 10µA maximum and is thus a good choice for a battery-powered

application. The resolution of the temperature reading is 12 bits, with a resolution of 0.0625 degrees

Celsius. An extended temperature mode is also possible, but this is only useful for measuring

temperatures above 128 degrees Celsius.

External Flash

The CC430 microcontroller provides a flash memory resource that is primarily used to store the

user-application code. While the capacity is sufficient for these purposes, the space could easily be

consumed by sensor data logs, user display bitmaps and other system information. Vibe emphasizes

data logging as a good application development practice. Sending data in burst transfers to other

nodes or a base station minimizes the amount of time spent transmitting over the radio and the

number of times the radio is cycled. The data logs, however, consume a significant amount of space,

especially when logging data from sensors set at a high sampling rate. To address these issues,

a large external flash is present in each Vibe node. The term “external” refers to the fact that

the large flash storage is not contained within the microprocessor package. The flash is, however,

internal to the device and not physically removable.

Naturally, there is a strong correlation between memory capacity and overall IC size. In order

to preserve a small form factor, a trade-off between device size and memory capacity had to be

made. In order to understand what was a reasonably sized memory device, the amount of space

that data logs and other user bitmaps consume had to be understood. Table 1 shows an estimation

of different data objects and their estimated impact on memory. The customer specification for

data logging was a single working day (8 hours) of consistent time-stamped data logging of all

Vibe motion sensors at a sampling rate that accommodates most physiological parameters. With

a base station in the user’s home, periodically offloading data from the body area sensor network

nodes, 8-hours of logging capabilities was determined to be sufficient.

The memory impact of the data logging specification was calculated using the typical logging

30

Data Structure Sizes in Memory (B = bytes)

Data Structure Size in Memory

Sensor Data Logging (8 Hours) 1.72 MB

16-bit Color Fullscreen Bitmap 12.3 KB

8-bit Color Fullscreen Bitmap 6.1 KB

Single Display Font Set 5.8 KB

System Information 10 KB

Table 1: Data Structure Sizes in Memory

scheme implemented in the Vibe API. A data log may consist of any combination of sensor data,

a timestamp and user-defined data. For a typical data log, logging the accelerometer, gyroscope

and compass data with a timestamp, each log entry will be 12 bytes in length. This employs a

Unix style 32-bit timestamp, triaxial accelerometer and gyroscope data, and a heading from the

compass. The data is assumed to be acquired at a sampling rate of 5Hz, which is a modest rate

for motion sensing data. The result over the full 8 hours is a 1.72 megabyte data log. Users may

optimize the data log to include data only from a subset of available sensors, a timestamp only at

the beginning of the log or many other optimized formats, but the 1.72 MB file size calculated is

determined to be a representative size for the time period specified.

The CC430’s internal flash storage area is 32 kilobytes. That must be shared between user data

and application code. Note that with the sensor data log specification alone, there is not enough

memory capacity internally. In addition, a single 16-bit color bitmap alone would consume almost

40% of the CC430’s internal storage. Obviously another solution is necessary.

Taking in consideration the constraints presented in Table 1. A 16 Mbit external flash chip

from Silicon Storage Technology, Inc. (now acquired by Microchip, Inc.), the SST25VF016B,

was chosen. This provides enough storage to meet the data logging specification and modestly

accommodate the other memory requirements. The SST25VF016B is a low-power, single voltage

flash memory with a SPI digital interface. The SPI interface is shared with the accelerometer. The

compass, gyroscope and temperature sensors utilize the I2C bus as previously mentioned. This

separation helps reduce any possible bottlenecks that could occur on a single serial bus.

31

The SST25VF016B is organized in uniform sectors of 4 kilobytes. This is the basic unit of

chip erasure. For writing operations, the memory is dual-byte addressable, meaning single bytes

may be written to flash, but starting at locations with an even address. In addition, the user

may erase 16 and 64 kilobyte overlay blocks consisting of 4 and 16 single sectors, respectively.

An entire chip erasure is also possible with a single command. An entire chip erasure takes 35

milliseconds. The SST25VF016B also implements write protection policies to prevent writing and

erasing certain areas of memory. This is useful from the perspective of the frameworks developer.

Vibe reserves the upper 1/32 or 64 kilobytes of flash memory for internal system storage. This

includes system-implemented font sets, bitmaps, encryption keys and diagnostic data. If the user

attempts a full-chip erasure, the contents of the protected areas are preserved. In addition, any

write to the protected area in flash is disallowed without first properly changing the protection

policy. The policy for the upper 1/32 area of flash is not accessible through the Vibe user APIs.

The system information stored in this area is loaded when the device is initially programmed. The

API however, does allow the user to change the policy of lower data blocks, so that the developer

may protect stored data during writes and erasure operations. This logical separation of memory

is shown in Figure 13.

.

.

.

Protected System-Level Data

User Data

User Data

User Data

0x1F0000-0x1FFFFF

0x1E0000-0x1EFFFF

0x000000-0x00FFFF

0x010000-0x01FFFF

Figure 13: Flash Memory Allocation

Note that while the specification for memory capacity is met with the 16MBit flash, Vibe

application developers requiring more storage may opt for the SST25VF032B 32MBit flash chip.

This chip is pin-for-pin compatible with the current flash chip and will work with the existing

32

APIs. This chip was not initially chosen to keep the cost low on the overall device. The price

of the 32 Mbit chip is about 1.5 times that of the 16 Mbit chip ($1.63 vs. $2.56) and is thus a

good choice for developers requiring additional storage for their application. The SST25VF032B

internally generates the 12V Vpp necessary for programming the memory cells, using a charge-pump

regulator. Thus, it is recommended that the user keep a small buffer of data in the internal RAM

of the CC430 and write to flash in burst mode, when possible.

User Display

To give developers the ability to create applications that interact with the user, Vibe includes a

small set of input and output peripherals. The primary output device is an organic light emitting

diode (OLED) display. Even though devices worn on areas other than the wrist may make no

use of a user display, the Design Aesthetic section explains why all nodes were created with equal

processing and input/output capabilities. For a user, it provides a greater convenience of having the

ability to place any device in any location on the body without regard to the capability of a device.

In addition, keeping the hardware consistent throughout all nodes simplifies the development effort

and manufacturing.

The goal was to include a low-power display that was easy to interface to and matched the

dimension constraints of a wearable node. Initially a single-color, 96x64 resolution, 0.95” OLED

display manufactured by Densitron Technologies was chosen, but due to an inability to acquire a

significant quantity of the display, the device was ultimately not selected. A similarly sized, 16-bit

color RGB display, the CFAL9664B, was chosen from CrystalFontz, Inc. This display is also a

0.95” diagonal display with a resolution of 96x64 pixels. The power consumption is slightly higher

than the Densitron display, due to the full-color capabilities of the device, but is manufactured in

the United States and is readily available in large quantities.

The CFAL9664B includes a chip-on glass COG display controller, the SSD1332 from Solomon

Systech. The OLED display controller also includes internal RAM, which is referred to as Graphics

Display Data RAM (GDDRAM) to hold the contents of the frame in the display. Updating the

GDDRAM is all that is necessary to change the image displayed. The user is required to self-time

updates to the display to perform any desired animation effects. Since the display for Vibe is

mostly static, in the sense that it is not imagined that the display will be used to display video or

33

full-frame animation, the amount of CPU resources consumed by the display is relatively low. The

interface to the controller is a parallel “8080-style” interface. This interface is shown in Figure 14.

Figure 14: SSD1332 Display Controller Interface

The chip select pin (/CS) is used to select the OLED display controller to monitor communica-

tions on the bus. The reset pin (/RST ) is active-low and must be high during all communication.

Bringing the reset signal low causes the controller to enter a reset state. The contents of GDDRAM

are maintained while in the reset state, but the contents of the system-level registers, such as pixel-

brightness are not maintained. The GDDRAM contents are both readable and writable over the

parallel interface. During a write, data is placed on the parallel data port (DB7-DB0). The

data/command (D/C#) signal allows the user to specify whether the current transaction is a

command to the display driver or data to be written to a register or GDDRAM. Commands are

quick methods of setting a certain state on the display, such as ON/OFF status, pixel brightness

intensity, and others. After the setup time of data on the parallel port is accounted for, the user

strobes the /WR or /RD pins to perform the desired transaction. The CFAL9664B also supports

a serial SPI interface, but the parallel interface was chosen to maintain a large bandwidth on the

serial buses for the external flash and motion sensors.

The CFAL9664B is a 96x64 pixel display with a maximum 16-bit resolution for each pixel.

This allows up to 64,000 different colors to be displayed. Colors red and blue each have 5-bits of

resolution and green has a 6-bit resolution for a total of 16-bits per pixel. The display also supports

an 8-bit, 256 color mode with 3-bits for red and green colors and 2-bits for blue. The 8-bit color

mode is preferred for user interfaces that are not graphically intensive as the memory required to

34

implement user bitmaps is reduced.

6.2 Power Management Unit

A small power management unit (PMU) was developed to support the operating voltages of each

component as well as allow for charging capabilities of the battery and other peripheral functions.

The PMU consists of two major blocks. The first block is the linear regulator which generates the

necessary voltage to supply both core and logic supplies for each integrated circuit, The second

major block is the battery charging circuitry. The battery is a rechargeable lithium-polymer single

cell battery. The battery is rechargeable over USB through the microUSB port on the body of

the device. The battery charger also provides simple monitoring functions such as notifying the

processor when an external charging voltage is applied to Vibe via the USB port. In addition, the

charger also indicates when the battery is fully-charged. The charger is an integrated solution that

respects the charging profile recommended for single-cell lithium-polymer batteries. For testing

purposes, the device can also be operated without a battery. When a battery is not applied to the

device, but the device is plugged into a USB port, the charger will supply 4.2 volts to the linear

regulator which generates the main rail voltage of the Vibe system.

7 Software Architecture

The goal of Vibe was to allow for rapid application development by constructing a software archi-

tecture that took full advantage of the hardware and provided a simple user interface for sensor

and peripheral interaction. Vibe employs a layered software architecture to create an application

development environment that is easy to use. In addition, each layer relies only on lower layers

in the layered-stack and employs a defined interface to allow a lower-level to be easily updated.

Figure 15 shows the software architecture layers of Vibe.

Throughout this section certain terminology is used to describe the interaction of software and

hardware and also human interaction with Vibe. The system refers to the network of Vibe devices

on the body. The user is the host of the Vibe BASN, or a person who is wearing a caretaker

node. An application is a piece of software executed by Vibe to perform some task. A driver

is a hardware-specific segment of code that deals with low-level hardware communication and

35

Figure 15: Layered-Software Architecture

maintenance. Essentially, the driver abstracts the interface of the hardware to the system.

The hardware drivers (HW Drivers) provide low-level access to the Vibe sensors and other

hardware. The end-user application, written by the developer, exists in the application layer

(Apps) and interacts with Vibe’s Application Programming Interface (Vibe API) to leverage the

hardware in a controlled manner. The layer directly above the hardware driver layer consists of

two parts labeled µC/OS − II and SimpliciTI. µC/OS − IIis the real-time operating system or

RTOS, managing the developer’s applications. SimpliciTI handles all low-level wireless functions,

which are accessible through the Vibe API. This section discusses each layer and its contribution

to the overall architecture.

7.1 Hardware Drivers

The hardware drivers provide an abstraction of the low-level inter-IC communications and timing.

Each sensor has dedicated code that provides elementary read and write operations between the

CC430 microcontroller and the peripheral device. In addition, bus-oriented sensors, such as the

gyroscope and compass which reside on an I2C bus, utilize a communications driver, in this case,

composed of the I2C driver functions. The I2C driver, for example, provides elementary functions

for reading and writing to registers of a device on the I2C bus. In addition, it is responsible for all

error checking and diagnostic features to make sensor communication more robust over all sensors.

The re-use of common code between many different sensors for low-level communication functions

also reduces the memory footprint of the overall software architecture. This is similar to the idea

36

of standard libraries that are shared by resources in a personal computer operating system.

Since the code for each device is implemented in a separate source file, following a defined

coding style, the system is very extensible. If, for example, a developer wishes to add a new

sensor that uses an existing communication standard with driver support on Vibe, they just need

to devise a sensor interface using the lower-level communication functions. In addition, when a

communication function is called, the success or failure of that operation is reported to the user

as a return value of the function to allow the user to perform higher-level diagnostic functions and

monitor the status of an active sensor.

Each device implements an initialization function which initializes the necessary inputs and

outputs and sets the peripheral into a known state, typically in sleep or shutdown mode. This

function is called by the main initialization function in the Vibe API. After proceeding through

all peripheral initialization functions, the Vibe device is set to a known state where applications

can execute from. The additional functions required are device-specific.For example, a low-level

driver function is implemented for the accelerometer to read triaxial acceleration data from the

accelerometer and store the read data in a specified data structure. In addition, a low-level function

is implemented to convert the raw data into the proper workable unit (e.g. milligravs). These

functions are not accessible directly through the Vibe API but are called by the API through

user-level functions. Just as depicted in Figure 15, the hardware driver functions are not accessible

from the application layer and should be written to provide isolation from direct user access.

7.2 SimpliciTI

Texas Instruments developed the CC430 to leverage their wireless protocol stack known as Sim-

pliciTI. SimpliciTI is intended for low-power sensing nodes in fields of industrial and environmental

monitoring and health care fields. SimpliciTI was developed prior to the CC430 to support their

product line of wireless integrated radios. SimpliciTI utilizes low-level radio drivers in the hard-

ware drivers layer to interact with the physical medium. This provides good portability over the

range of SimpliciTI devices that TI manufactures.

SimpliciTI defines three device types; access-point, range-extender and end-device. An access-

point is typically a convergence point for data and a central medium between multiple wireless

37

networks. It is similar to a central node in a star topology network. A range-extender is analogous

to a network repeater device. It relays wireless data from one node to another extending the overall

range of the network. It typically does not perform amy data acquisition or processing functions.

Lastly, an end-device is analogous to a leaf node in a star topology. These devices typically sense

environmental data, perform some data processing task and return a result to the central node.

Vibe utilizes only the end-device and access-point device types. Since the distance between sensors

is relatively low on the body compared to remote environment sensors, a range extender was not

deemed to be necessary. Note, however, that due to the natural attenuation of wireless broadcast

signals by the human body, the output power of each device may need to be scaled to create a

robust wireless link. Figure 16 shows an example of a SimpliciTI network topology. The device

types are indicated in the legend. Note the dynamic topologies that can be created. A peer-to-

peer link may exist between two end-nodes where one communicates to an access point directly or

through a range-extender.

Access Point

Range-Extender

End-Device

SimpliciTI Network Topology

CN

LN LN

LN

Figure 16: Example Simpliciti Network Topology. Adapted from [11]

The entire SimpliciTI stack is accessible through seven user API functions. These functions

are detailed in [10]. To create a network topology, a link is requested by either an end-device or

an access point by broadcasting a “link join” packet. If a node responds to the link request it

returns a unique link ID that is further used to direct messages to that specific node, analogous

to an IP address with devices connected to the internet. The requester may then accept the link

38

and finalize the virtual link or send a not acknowledge (NACK) to abort the link process. Once a

link is setup, messages can be sent bi-directionally across nodes by using the appropriate link ID.

Each packet contains the link ID in the header of the packet. The payload is variable from 3 to

28 bytes in length. A length byte specifies the length of the payload. Additionally, each packet is

sent with a 32-bit cyclic redundancy check (CRC) for error detection. If the CRC received does not

match the calculated CRC, the node may NACK the packet for a resend. Additionally, SimpliciTI

provides optional modules, such as a frequency agility module that can increase the functionality

of the core wireless stack at the expense of a larger RAM/ROM footprint. If a CRC is incorrectly

received after a certain number of tries, a node may broadcast a channel switching packet and

hop to another channel within the frequency bandwidth to avoid interference. The frequency

agility module also improves robustness when multiple SimpliciTI devices are transmitting within

a confined area.

Another optional module which is provided by SimpliciTI is an encryption module. The CC430

microcontroller includes a hardware-accelerated AES 128-bit encryption module. This frees the

processor from computation-intensive operations to support encryption. All outbound data may

be encrypted and incoming messages decrypted, using a shared-key method. The programmer

provides each device in the network with a common, shared key or broadcasts a non-encrypted

key at startup that is used as the encryption/decryption key. Security of wireless networks is

paramount in medical applications and SimpliciTI supports that necessity with a standard, widely-

used encryption technology.

7.3 uC/OS-II Real-Time Operating System

Vibe is intended to be used as a real-time human motion data acquisition platform. To support

multiple tasks running on a single device and provide resources that application developers are

familiar with on personal computer operating systems and embedded operating systems, a real-

time operating system (RTOS) was chosen. A basic (RTOS) gives the user the ability to run

multiple tasks with a given priority that are scheduled for execution with the RTOS’s scheduler. A

development environment using an RTOS is also more familiar to developers who are accustomed

to writing applications on personal computers and sophisticated embedded systems.

39

The RTOS that was chosen for Vibe was µC/OS − II V2.90 from Micrium. µC/OS − II is a

ROM-able, scalable RTOS with a small memory footprint and multi-tasking capability. µC/OS−II

uses a priority-based scheduler that schedules the highest priority task ready to run for execution

until that task finishes or blocks. One large factor in choosing µC/OS − II was the scalability

of the operating system. The kernel itself requires only five kilobytes of ROM and less than one

kilobyte of RAM. Additional modules such as a memory management module may be purchased

from Micrium and added to the RTOS build for additional features.

Another benefit of µC/OS − II is the unobtrusive nature of the kernel in the hardware.

µC/OS − II requires only a single timer to implement the system tick Interrupt Service Rou-

tine (ISR). The tick timer is the “heartbeat” of the RTOS, providing a time-base for the RTOS.

On each tick, the task queue is evaluated and if another process with a higher priority is ready to

run, the operating system provides a context switch, saving the current task’s stack and CPU status

registers before switching to the new task. The tick ISR can be implemented at any frequency but

typically a frequency of 10-100Hz is recommended as a compromise between task responsiveness

and time spent switching task contexts.

While not required to run user-applications, the RTOS provides a convenient way of managing

multiple tasks, meeting real-time deadlines and managing processor resources efficiently.

7.4 Vibe Application Programming Interface

The layer that the application developer directly interacts with is the Vibe application programming

interface (API). The Vibe API layer provides controlled access to hardware resources to free the

user from dealing with the intricacies of sensor communication and interface. Each function name

in the Vibe API set is prefixed with VIBE to differentiate it from user-defined APIs. All applications

begin by calling the VIBEInitializeDevice( ) function. This places the device in a known state

by proceeding through internal settings and external peripheral settings, placing the device in a

low-power state with all sensors deactivated and pins initialized to their appropriate state and

function.

The Vibe API provides an interface to the sensor hardware and other peripheral hardware such

as the Flash memory and display. This section describes the API layer logically segmented into

40

sensor API functions, peripheral APIs and the rudimentary graphics library included. All Vibe

API functions are described in more detail in Appendix B: Vibe API Function List

Sensor APIs

Each sensor API provides a standardized interface. The first API function called by the user to

activate a sensor is the VIBEStart...( ) function, where “...” is replaced with the name of the

sensor. For example, to activate the accelerometer, the user calls VIBEStartAccelerometer( ).

The arguments of the function are device specific, but typically the full-scale range and sampling

rate are supplied. A lower sampling rate will result in a lower power consumption, but at the

expense of less-frequent data. Once the sensor is initialized the senor is automatically initialized

and periodically read as determined by the sampling frequency. Each sensor result is automatically

placed in a data structure specific to the sensor. The accelerometer, for example, updates the

vAccel data structure which holds the last read triaxial acceleration in both raw data and unit

appropriate formats. Interpretation of the raw sensor data is device specific, but is provided as it

is usually a more compact bit width than the processed workable unit value. The raw acceleration

data, for example, is an 8-bit byte for each axis, but the processed data in units milligravs is a

16-bit signed integer. When new data is written to the data structure, a flag is set indicating new

data is available. The user is responsible for clearing the flag.

In addition to updating the appropriate data structure periodically, an interrupt service routine

(ISR) hook is included for each device. When the low-level ISR is called for a given sensor to retrieve

new data, the user ISR hook is called after new data has been retrieved. This removes the need to

poll the “new data” flag in the sensor data structure for new data. The user is able to process each

sensor result as it becomes available from the sensor. The hook is called within the context of the

device ISR and should thus be kept relatively short to ensure efficient execution of system ISRs.

Calling multiple functions from the ISR hook is discouraged. All ISR hooks are implemented in

the hooks.c source file.

In addition to automatic sensor data updating and an ISR hook, each sensor API includes a

function to request data from the sensor. VIBEGetGyroData( ), for example, requests new data

from the gyroscope immediately. The function takes one argument which is a gyro type data

structure to place read data in. This allows the user to retrieve data “a-la-carte” and implement

41

arbitrary sampling frequencies. Of course, the maximum sampling frequency of the sensor may

not be exceeded or the sensor will return previous results.

Currently, VIBE implements sensor APIs for the accelerometer, gyroscope, magnetic compass

and temperature sensors. See Appendix B: Vibe API Function List for a detailed explanation of

each API function and its usage.

Peripheral APIs

In addition to API functions to interface with Vibe’s array of sensors, Vibe includes an API to

utilize the external flash storage and the internal real-time clock.

The external flash is a 16 Mbit storage device capable of storing custom user data and sensor

data logs. The upper 1/32 section of the total available flash memory (512kbit) is reserved for use

by Vibe system-level functions. There is no strict file management system implemented by the

Vibe API. The user may implement a file management system, by utilizing lower-level read and

write user API functions. The flash API provides 16-bit word access to the entire address space,

except for the system reserved space. An attempted write or read to or from a protected system

address will result in a failure. The flash API provides lower-level read, write functions as well as

the ability to set user-level block policies. This allows the user to protect an area in flash when the

chip erase API function is invoked. In addition to a full chip-erase of unprotected flash blocks, the

flash API also provides the ability to selectively erase blocks of flash. The flash block segmentation

is shown in Figure 13 in section 6.

The Vibe API also includes utility functions for logging sensor data. The VIBEStartDataLog()

is a useful command for automatically creating data logs of sensor data and user-custom data. The

user can specify the contents of the log such as a timestamp from the real-time clock, the specific

sensors that should be logged and the frequency at which logs are created. When data logging is

enabled, the system automatically caches a small amount of sensor data in RAM, and writes the

buffer to flash when the RAM buffer is filled. This reduces the number of writes to flash which

is an expensive operation from a power-consumption perspective. The starting address and the

current ending address of the data logs are also maintained and updated via the data logger API so

the user may avoid overwriting log data. The user specifies the starting address of the data log. If

the last user-addressable byte of flash is exceeded, the logger rolls over to the first user-addressable

42

byte and cyclically continues the data log.

Vibe also maintains a real-time clock useful for synchronizing events. The real-time clock is

driven by an external low-power 32.768kHz oscillator and is kept active even in the lowest-power

mode. The user may set and read the current time using the appropriate Vibe API functions.

The vTime struct type holds a specified date with millisecond resolution including year, date, day

of the week, hours, minutes, seconds and milliseconds. The real-time clock provides automatic

compensation for leap-years.

In addition to core time-keeping abilities the real-time clock also includes alarm functionality.

The user may set a single or reoccurring alarm using the VIBESetRTCAlarm() function. This

allows the user to set periodic system reminders and extend alarm functionality to the user if the

user-interface requires such a feature. An user ISR hook is called when an alarm expires.

Lastly, the real-time clock provides low-level timing interrupts accessed via user ISR hooks.

The timer frequencies are 64Hz, 32Hz, 16Hz, 8Hz, 4Hz, 2Hz, 1Hz and 0.5Hz respective to the

appropriate ISR hook in hooks.c. This is useful because it provides a wide-range of timer periods

without dedicated use of a generic system timer, of which only two are available for use. If an

exact period is not necessary, the user is encouraged to use the RTC ISR hooks for general purpose

event timing.

User I/O APIs

Vibe provides a small set of input/output peripherals including two user buttons and an OLED

display. Each device has dedicated API functions for interfacing with the user application.

The user button API is relatively simple. The user may check the status of a button using the

VIBEGetButtonStatus( ). The return value is the current state of both buttons. In addition, user

ISR hooks are called on both a button press and release so that the user may easily keep track of

the button statuses without polling the button API. Button de-bouncing is already implemented

in the Vibe frameworks for the user.

The OLED display API provides a large-range of functionality including a rudimentary API

function to write raw pixel data to the GDDRAM of the OLED display and more advanced

functions to draw user bitmaps, for example.

The display API defines several types that are useful in interfacing with the OLED display.

43

These include the pixelColor and pixelCoord data structures. The pixelColor structure holds

either an 8-bit or 16-bit color value used for drawing single pixels, displaying fonts and other

operations. The pixelCoord data structure holds a single pixel coordinate. In the graphics library

API function for drawing a line, for example, the user specifies the starting and ending pixel

coordinates using the pixelCoord data structure as well as the line color using the pixelColor

data structure.

Vibe includes a small graphic library for rendering simple graphics on the display. This includes

but is not limited to, the ability to draw bitmaps, display strings/characters, draw lines, circles,

boxes and single pixels. In addition, the user may copy a rectangular area of the display and paste

it to another area of the display. Many of these commands are accelerated by the OLED display

driver and thus are much more efficient than manually rendering graphics by plotting single pixels.

A useful feature of Vibe is the standardization of the font system. Utilizing an application

from 4D Systems, Inc. [Sydney,Australia], the user may generate a font set in any desired font

of any size and load the font into the flash of Vibe for use in string printing [8]. The program

can automatically generate the header file that needs to be included with the application build or

written to external flash. The application is licensed as freeware. Figure 17 shows a screenshot of

the application for generating a font set usable with Vibe.

Figure 17: 4D Systems Font Generation Tool

44

By default, the Arial font set is included in font size 8 and 16. Since font sets tend to be large,

the user is encouraged to load only the font sets required and remove unnecessary characters from

the font set.

Similar to the sensors, the display is started with the VIBEStartDisplay( ) API function.

API functions are also available for display control included clearing the display (all pixels set to

black or OFF), changing the pixel brightness intensity, switching between 8-bit and 16-bit color

modes and waking/sleeping the display. Because the display consumes a significant amount of

power compared to many of the components Vibe incorporates, the user is urged to use the display

efficiently, similar to how a modern cellphone manages the amount of time a display is left on.

For a more detailed description of the graphics library APIs see section 2.3 in Appendix B:

Vibe API Function List.

Vibe also includes a rechargeable battery and recharging circuitry. The device may be charged

via the microUSB port located on the side of the device. The Vibe API also handles user power

input and battery charging functions. When power is applied externally, via the USB port, a

user ISR hook, VIBEPowerAppliedHook( ) is invoked. This is useful if the user wishes to dis-

play status information to the user that the device is charging. In addition, the user ISR hook

VIBEChargingStartedHook( ) is called if power is applied and the battery is not already full.

This is invoked after VIBEPowerAppliedHook( ). Battery charging is conducted automatically

until the battery is fully charged at which point the VIBEChargingCompletedHook( ) is invoked.

The user should place any tasks or set any flags necessary to update the user in these hooks.

In addition to the interrupt-driven hooks, the user may check the status of the battery at

any point, while the battery is not charging, by monitoring the batteryStatus field of the

VIBEStatusReg data structure. This register provides a percentage based representation of the

charge status of the battery. While charging, the battery charge status is not available due to the

architecture of the PMU.

7.5 User Applications

The top-most layer of the Vibe software stack is the User Application or Apps layer. This layer is

written by the user utilizing the Vibe API functions to interact with the hardware. The inclusion

45

of µC/OS − II in the software architecture allows the user to write their application as a series of

independent tasks that run at a certain priority. The user may wish to implement their application

in as little as one single task, or up to 256 individual tasks. All tasks must be given separate

priorities. The RTOS does not handle multiple tasks with the same priority setting. A task is

analogous to a thread running in a desktop environment. Many of the same features found in a

desktop operating system are also available, such as semaphores. The user is encouraged to use

tasks efficiently, blocking a task whenever possible to allow the RTOS to schedule the next task or

sleep if idle.

Every Vibe application starts by calling the VIBEInitializeDevice( ) function call. This

places the Vibe device in a known, default state from which user code and API code can execute.

After the device is initialized the user creates their task by calling the OSTaskCreate( ) µC/OS−

II function. This function takes the task’s function name, priority level, argument to pass whenever

the task is executed and a pointer to the tasks’s memory stack. Each task must have an associated

stack that is saved and restored during context switches and serves as memory local to the respective

task. The size of the stack is left up to the user, and should be large enough to accommodate the

task’s memory requirements. Each task is implemented as a C-function. Task functions may call

other functions, but should not call another task function directly. The user passes the name of

the task function to the OSTaskCreate( ) function as an argument to register the task. When all

tasks are created, the user starts their application by calling OSStart( ). At that point, the task

with the highest priority is executed first.

Power is managed automatically for the user, except for peripheral status. The user must

manually shutdown unused peripherals and manage the display before their tasks exit. An efficient

way to manage peripheral power is to create a task with the lowest priority setting possible, that

manages the peripherals and turns off unnecessary items. This way, whenever the user’s application

tasks block, right before the device enters the idle task, the peripheral management task is invoked

and the peripherals are suspended. The idle task is automatically entered when all user tasks block

and there is nothing left to schedule. The idle task places the Vibe device in a low-power mode.

The real-time clock, RAM contents and pin states are maintained throughout low-power mode,

but the CPU and serial peripherals are suspended.

46

8 Hardware Development

Vibe was produced in two hardware iterations. The first iteration was a development board used

to test the functionality of the hardware architecture. Once the hardware architecture was verified

and demonstrated to be functional the second iteration was the form-factor board that would fit in

the hardware pebble designed in conjunction with the Industrial Design department. This section

details the development process of both of these hardware iterations, the testing conducted to

ensure stability and functional correctness and their results.

8.1 Vibe Development Board

The first iteration of Vibe hardware was the Vibe development board. The purpose of the de-

velopment board was to prove the functionality of the hardware architecture. Additionally, the

development board provides pin access to all hardware on the board to facilitate low-level debug-

ging. This is a luxury that is not possible for the board in the intended form-factor size. The Vibe

development board is pictured in Figure 18.

CC430

16Mbit Flash 6-Axis IMU

65k OLED

PMM

Figure 18: Vibe Development Board

The major blocks of the hardware architecture are highlighted. The development board im-

plemented all feature sets described in the architecture except for the digital compass which was

47

added after the development of the first hardware iteration.

The development board uses a two-chip solution for the triaxial gyroscope and single chip for

the triaxial accelerometer; a three-chip solution for a six-axis IMU. At the time of development

there was not a commercially available triaxial gyroscope in a single package. In addition, the two

gyroscope ICs provide an analog output, so post-processing was necessary to convert the voltage

into a rotational velocity.

The development board also housed a CC430F6137 in a 64-pin QFN package, which is the

largest package size available. The CC430 is available in both 64-pin and 48-pin packages with

an area of 81mm2 and 49mm2 respectively. The larger package was chosen to allow additional

features to be implemented, if necessary. The end goal was to use the smallest package possible

that accommodated the feature set desired. One benefit of the CC430 family is that all devices

are fully-compatible across the family allowing the same code to execute on any CC430 core as

long as non-existent peripherals are not used. The difference between each device is the number

of general purpose input/output (GPIO) pins available, and the amount of RAM/ROM that each

device includes. Additionally, the 64-pin CC430F6137 includes a static LCD driver which is not

necessary to support the Vibe hardware.

Additional features which were not intended for the final form factor board were also included

for debugging purposes. The Vibe development board includes three debug LEDs in the top left

corner of the board. These are useful for simple “Hello World” style testing and simple binary

result reporting. In addition an FTDI FT232R USB-to-serial converter was implemented to allow

serial console debugging. The FT232R provides a serial UART interface to a small first-in, first-out

(FIFO) buffer. The buffer, when filled or after an expiration period, is transmitted over USB to

the host. This provides a very simple way to print diagnostic information to a host console for

testing. The FT232R interfaces to the host through the micro USB connector that also serves to

charge the device.

The development board also includes additional user switches for placing the device in a boot-

strap mode to load new firmware and a reset switch to reset the processor. Both of these switches

do not appear in the final form factor design as bootloader entry and reset conditions will be

triggered solely in software or from a power-on-reset (POR) condition in the event of a loss of

48

power.

The development board houses a Spy-Bi-Wire connector for serial programming and debugging.

This is a reduced pin-count connector over the traditional JTAG connector used to program the

MSP430 family of devices. All pins of the CC430 are also broken out to 0.1” pin headers for easy

access with an oscilloscope or logic analyzer for debugging. Jumpers were also placed to allow the

board to be powered directly from USB power, bypassing the battery charger and also allowing the

input to the OLED panel boost converter to be selected to test efficiency with the battery voltage

input and the main 2.7V voltage rail input.

The schematic for the Vibe development board hardware is available in Appendix A: Concept

Development.

Development Board PCB Design

The development board was developed using Cadsoft’s Eagle PCB Cad Editor [1]. The board

was built in 4 layers, with the inner layers being ground and power supply planes and the outer

layers used for general routing purposes. Figure 19 shows the layout of the outer two layers of the

development board.

Figure 19: Vibe Development Board PCB Layout

The routing was spacious as there were no size restrictions on the development board. The

overall dimensions of the board are 3.9”x2.4”, which is fairly compact given the additional features

and pins added to facilitate debugging.

The board was fabricated using a prototype spec from Advanced Circuits [2]. The board

49

thickness is 0.062” with a 10mil trace spacing, 1 oz. copper and green solder mask. There were no

special impedance matching requirements, microvias or other custom requirements, making board

fabrication relatively easy and inexpensive.

Development Board Testing

Three fabricated boards were received from Advanced Circuits and populated by hand in the

Center for Electronics Manufacturing & Assembly (CEMA) facility at the Rochester Institute of

Technology. The board population process was lengthy, with each board taking roughly five hours

to populate by hand. Since the quantity was small, manual board population was justified.

A test plan was developed to test low-level hardware functionality and the ability to program

and execute code on the development board. This testing plan is shown in Appendix A: Concept

Development. The test plan covers very basic tests such as the presence of the 2.7V rail from the

LDO and more advanced testing such as characterizing voltage ripple on the output of the LDO.

The results of all tests are recorded in the test plan results in Appendix A: Concept Development.

Without any rework, the development board passed most testing procedures. One minor issue

was a debug LED was lit too dimly. This could be fixed by simply replacing the series resistor with

a lower resistance value, but was did not directly affect the functionality of the device. The rail

voltages were found to be stable at 2.696V, only 4 millivolts from the target 2.700V rail voltage, well

within the 20mV tolerance. In addition all sensors and peripherals were functional and successfully

interfaced with the CC430. The display interface was successfully implemented and test patterns

were successfully realized on the display. The most significant issue was the use of the wrong boost

converter which had a lower current limit than required by the display. The result was that the

panel voltage dropped below the required 13 volts to 7.5 volts as the current limit of the boost

converter was exceeded. This did not seem to affect the functionality of the display however. The

issue was resolved in further hardware revisions, where the correct boost regulator was purchased

and utilized.

The results of the hardware testing were promising and proved that the hardware implemen-

tation accurately reflects the hardware architecture diagram. Further software testing would be

necessary to prove that the hardware architecture effectively supports the desired applications.

50

8.2 Vibe 1.0 Hardware

After developing the Vibe development board to support hardware and software testing, the next

iteration was to develop hardware for the Vibe “pebble” form factor. Vibe hardware developed

at form-factor size, with the intention of incorporation in the final design, is versioned starting

with version 1.0. Development hardware contains the “dev” tag to distinguish it from finalized

hardware.

Vibe 1.0 hardware was the first iteration of form-factor sized hardware. It implements most of

the hardware found in the development board excluding additional hardware included for testing

purposes and breakout headers for signal probing. Beyond this there are a few architectural changes

that have allowed the hardware to fit in the confined design space.

Firstly, as previously stated, additional debugging hardware from the development board was

not included. This includes the FTDI FT232R USB-to-serial converter for console debugging,

jumpers, breakout headers and debug LEDs. The “reset” and “boot” pushbuttons were also

excluded as these features will be accessed via software. The exclusion of the FT232R IC leaves

the microUSB header solely for charging the battery. That is, the device will not enumerate over

USB for serial communication with a host. The data pins on the USB connector, however, were

repurposed to breakout the Spy-Bi-Wire pins for programming. Since a programming header could

not be accommodated, the USB connector was used for this purpose. A special programming cable

breaks out the necessary pins to a header that can be used with the Spy-Bi-Wire programming

dongle. This additionally allows the user to have physical access to reprogram the device from the

outside of the device without taking the final design apart to access the main logic board. Because

a wireless bootloader will be used to reprogram the device under normal circumstances however,

this is not deemed to be a severe tradeoff.

The IMU was also improved, reducing the gyroscope from a two-chip solution to a single-

chip solution integrating all three-axes. The ITG-3200 was introduced after the design of the Vibe

development board and provides better resolution, sampling rates and sensitivity than the previous

two-chip solution. In addition, the gyroscope is digital and can be accessed over an I2C bus. The

ITG-3200 also has additional features which are beneficial such as the ability to digitally filter the

results using a bandpass or low pass filter with programmable center frequency and bandwidth.

51

The single chip solution significantly reduces the PCB area required to implement the full IMU

and the processor resources necessary to read data and convert it to a rotational velocity for use

by the application developer.

The Vibe development board also utilizes two analog temperature sensors for ambient and

skin temperatures. Again, the analog interface requires that the voltage be internally mapped

to a temperature and processed before relaying to the user. The Vibe 1.0 hardware includes a

digital temperature sensor, the Texas Instruments TMP112, that is accessible over an I2C bus and

provides direct reading of temperature results. The range and sensitivity of the digital temperature

sensor is identical to the analog temperature sensor, but the digital interface also helps in signal

routing as an analog sensor output signal requires careful routing to ensure noise is not introduced,

corrupting the sensor results.

The CC430 device was also changed from the CC430F6137 to the CC430F5137. The ’F5137

variant includes the same amount of internal RAM and flash, but in a smaller 48-pin package

that consumes about half the area of the 64-pin package. Once the hardware was finalized on the

development board and the pin requirements settled for each peripheral it was determined that

the 48-pin package variant accommodated the feature set required. This was facilitated by moving

many of the sensors to the system I2C bus which significantly reduced the pin count for each

device.

Lastly, with the space savings achieved over the development board, an additional sensor is

accommodated in the Vibe 1.0 hardware. This sensor is a triaxial digital compass, the HMC5843

from Honeywell. The utility of the digital compass in human motion analysis was reported in the

Theoretical Development section. The HMC5843 also resides on the system I2C bus and provides

absolute positioning in the form of a heading relative to the earth’s magnetic field.

Vibe 1.0 Board PCB Design

The space available for the final device is very constrained, presenting a challenge in designing

the form-factor PCB and miniaturizing the hardware from the development board. The overall

dimensions specified by the Vibe pebble design were 0.94”x1.20” with a finished thickness of 32

mils (0.032”) for the PCB panel and 1.2 mm height on the component side for components.

The hardware described was successfully placed in the defined space requirements. Front and

52

rear views of the finalized Vibe 1.0 hardware main logic board and satellite temperature sensor

board can be seen in Figure 20. The final size of the board is 0.94”x1.20” as required by the

mechanical design of the pebble housing.

Figure 20: Vibe 1.0 Main Logic Board and Satellite Temperature Sensor Board

The board was manufactured by Gold Phoenix (http://www.goldphoenixpcb.biz), a PCB

manufacturer based in China. The custom specifications required, including a 32 mil panel width,

black solder mask to match industrial design aesthetics, and less than a 1” length in the x-dimension

made previous PCB manufacturing sources too expensive. Fifty boards were purchased from Gold

Phoenix at less than eight dollars a board. To further save cost, the dual-board design of the

device, including the main logic board and a satellite board to house the temperature sensor at

the metal plate and the circuitry to drive the piezo buzzer were combined in a single board. The

satellite board is separated from the main logic board after population.

The final PCB is a 4-layer PCB with a similar stack-up to the development board. The inner

layers provide a ground and supply plane and the outer layers are used for general purpose routing.

A copper thickness of 1 oz. with ROHS-compliant pad plating was selected. White silkscreen was

used on both sides of the board to help ease the population process for boards stuffed by hand.

In addition, fiducial marks were included to make the board compatible with automated pick and

place machine requirements. Component placement was more critical in the final PCB than in

the development board. Besides ensuring correct orientation of the sensors to match the reference

plane of the device, the height of the compass’ IC package exceeded the specification and thus it

was placed below the USB connector where additional clearance allowed for the compass to be

53

accommodated. In addition, the antenna presented a challenge, as a rear-mounted antenna would

be affected by the presence of the metallic battery residing beneath it. To resolve this, the antenna

was mounted to the front of the board below the OLED display, so that it would reside at the

surface of the device. The supply and ground planes were restricted from the antenna area to

minimize antenna detuning affects. The USB connector and user buttons also had to be placed

carefully to match the mechanical drawings. The display had to be placed on the front of the

board and no additional components could be placed beneath the display. The display imposed

the largest size restriction throughout both the mechanical and PCB design. The exclusion of

the display would allow the electronics to be housed in a significantly smaller “pebble” and would

reduce the size of the battery required to power the device as the display consumes a significant

portion of the power budget. Figure 21 shows the top and bottom layer component placement

and signal routing. The board is very dense, pushing the limits of the specification to house the

required electronics.

Figure 21: Vibe 1.0 PCB Top and Bottom Layer Routing

Initially, 25 boards were populated manually. This process was extremely time consuming but

was chosen over an automated process for the first batch to save cost.

Vibe 1.0 Testing

Testing the Vibe 1.0 board is very challenging due to the lack of test points and the small size of

the board. The first two boards were populated in segments allowing incremental testing as new

components were added to the board. A similar test plan to the development board test plan was

54

used and modified for the additional hardware included in the Vibe 1.0 board.

First, the PMU was populated and tested. All power circuitry functioned correctly with a rail

voltage of 2.701 volts, well within the 20 millivolt tolerance. The battery charging circuitry was

also functional and successfully charged a connected lithium -polymer battery when connected to a

power source via USB. The OLED panel voltage was also operational. In this iteration the correct

boost regulator was purchased and used, so the current limit was not exceeded as seen previously

in the development board. The panel voltage was steady at 13.0 volts both with and without a

load.

Next, the MCU circuitry was populated and the ability to program and execute code was

tested. This was successful using the custom programming cable developed to interface with the

Spy-Bi-Wire pins over the USB connector.

Communication with all peripherals was also successful. The largest hardware bug discovered

was the omission of I2C pull-up resistors resulting in a floating bus. This was resolved with a small

amount of rework adding two additional resistors to pull the I2C bus high. All sensors were found

to be operational and functioning correctly. The display and user buttons were also tested and

found to be operational. Vibe 1.0 actually reduces the component count by removing the external

pull-up resistors. The internal pull-up feature of the CC430 was used to interface with the buttons.

Another bug discovered in the Vibe 1.0 hardware was a POR condition resulting when the

device is plugged into USB power. This is because the MCU reset signal is required by the Spy-Bi-

Wire programmer. When plugged into USB power, the USB controller of the host grounds the line

and causes the MCU to enter a reset state. Currently no fix, other than severing the reset trace to

the USB connector after the bootloader is burned into the ROM, has been developed. Switching

the pins on the USB connector may be a possible solution, but this is not yet tested.

The Vibe 1.0 hardware testing produced very promising results. All hardware is functional with

work-arounds devised for existing bugs. These bugs are slated to be fixed in the next hardware

iteration.

55

9 Software Development

The architecture of the Vibe software stack was already described in the Software Architecture

section. The full-stack was developed in the C language. During initial development the stack was

developed and debugged using the Code Composer Studio integrated development environment

(IDE). CCS includes a full C compiler and hardware debugger toolchain for rapid development.

The free version of CCS is limited to 16kB compiled code. For this reason the software stack

was ported to the open-source MSPGCC compiler, based on the widely-used GNU C Compiler

(GCC). MSPGCC provides no code limit and is freely available and maintained by the open

source community. To support device programming over Spy-Bi-Wire, GDG was utilized. This

is also an open-source tool that allows an output .ELF binary from the MSPGCC compiler to

be downloaded to a target device. These two applications were integrated in Eclipse to create a

fully-open source and free integrated development environment for the Vibe platform. Currently,

debug support is not available over Spy-Bi-Wire for CC430 devices using open-source tools and

is thus not implemented in the custom Eclipse toolchain. Users requiring single-step debugging

and additional debug features should purchase CCS from Texas Instruments. The frameworks

developed are directly compatible with CCS without any modification.

The lack of single-step debugging capabilities is not a major issue to the Vibe development

platform. The preferred method of programming a Vibe device is using the developed wireless

bootstrap loader, or bootloader for short. The bootloader allows wireless update of devices. Once

the bootloader is burned into the ROM of the CC430, the Vibe device may be updated by plac-

ing the device in the bootloader mode. This is achieved by pressing and holding both the user

A and B buttons simultaneously for 10 seconds. User application code should be careful not to

require this combination as it is reserved for bootloader entry. The developer may add an ad-

ditional way to invoke the bootloader. From the application developer’s perspective, a call to

the VIBEBootloaderEntry( ) function enters the bootloader mode. While in bootloader mode,

the device looks for a wireless access point attempting to transmit a firmware image and displays

“BOOT” on the OLED display. The bootloader may be exited at this point by pressing the ‘B’

user-button. The bootloader application is invoked on the host computer with an .ELF binary file

as an argument to the application. The wireless dongle must be connected to the host computer

56

or else the bootloader application will exit on failure. The download status of the firmware image

is displayed as a percentage on the OLED display and the user console of the host computer. Low-

level wireless packet handling, error checking and other functions are handled by the bootloader

automatically. When the firmware image is successfully received, the device will reset and begin

executing the newly programmed firmware image. If reception is unsuccessful, the bootloader will

exit and the previous firmware image will be executed from a reset condition. The bootloader is

only useful for programming Vibe devices. A device may not be debugged over a wireless interface.

The user has many resources for debugging their application code including a wireless serial console

and the OLED display to print diagnostic information to.

The entire toolchain is supported on Linux machines. The toolchain was tested on Ubuntu but

should run successfully on other Linux platforms. Instructions for installing the toolchain can be

found in the Vibe documentation, separate to this document.

Software Testing and Results

Exhaustive testing of many aspects of the Vibe software architecture is not possible due to the

complexity of the platform and interaction of multiple sub-units. In order to test the software

thoroughly, many test cases were developed for situational failure. For example, each sensor was

not only tested individually but also tested with all other sensors activated at the highest sampling

rate possible. Sensor testing consists mainly of two parts. The first test is to verify that the sensor

is calibrated and producing accurate results. With motion sensors this can be done fairly easily

testing with static stimuli. The accelerometer, for example should produce 1-gravity force on a

single axis and zero gravity force on the other two axes when the device is positioned with exactly

one axes oriented upward. Any deviance from this is compensated for in software as a calibration

constant or in hardware at the device-level if possible.

Most of the Vibe application framework was tested by writing sample, small utility applications.

The wireless interface was tested, for example, by creating an application that plots triaxial motion

data streaming from the device. The open-air range of the device at full-power output was found

to be 100 meters. Although this may seem more than necessary for a body area sensor network,

attenuation of the RF signal through the human body reduces this range severely.

To the best of the knowledge of the engineer, a port for µC/OS − II on the CC430 was not

57

available at the time of development. Since a port was already available for the 500-series MSP430

devices, which contains an identical core CPU, a port of µC/OS − II was tested on an MSP430

Experimenter’s Board. The Experimenter’s Board includes a 500-series MSP430. The port of

µC/OS − II was successfully realized on the Experimenter’s Board and tasks were successfully

setup and executed with varying priorities. The port to the CC430, however, was not successful.

Although the core CPU is identical to the 500-series CPU, the tick ISR caused the device to branch

to an illegal address causing the processor to hang. This issue has not yet been resolved and is

still being investigated. As a result, the current revision of the Vibe software architecture does

not support the µC/OS − II RTOS. This does complicate the application development process,

but applications can still be written effectively utilizing the Vibe API frameworks until a fix is

deployed.

With exception to the RTOS, the other layers of the software architecture were successfully

implemented and tested. SimpliciTI was successfully ported to the Vibe development board and

tested. All Vibe API functions listed in Appendix B: Vibe API Function List were also implemented

and tested for correct functionality.

10 Application Development

In order to test the Vibe platform and provide coding examples to application developers, multiple

small applications were developed.

The first application that was developed streamed accelerometer and gyroscope data to a host

PC using the SimpliciTI protocol. A host-side application from Texas Instruments was used to

visualize the data. The data was graphed by the host application and displayed to the user.

Figure 22 shows a screenshot of the application graphing acceleration data. This provides a quick

means of testing that both motion sensors and the wireless interface are functional.

Although this application is useful for testing purposes it does not convey the meaning of the

motion data very well. To address this, an application was developed to use a single device to

manipulate a 3D cube in space. The application was developed by Jeffrey Robble, while a student

at the Rochester Institute of Technology. Figure 23 shows a screenshot of the application. The

user interface is implemented using OpenGL to render the 3D graphics. The application uses both

58

Figure 22: Motion Data Graphing Application

acceleration and gyroscope data to track the motion of the connected device. When the user moves

the device, the cube tracks the motion of the user’s Vibe device.

Figure 23: 3D Cube Manipulation Application

The previous application provides an example of how to use motion data to manipulate objects

59

and track motion, but only with a single device. The advantage of Vibe is the ability to track human

motion by creating a body area sensor network. The previous application does not incorporate

information from multiple nodes and track motion. To address this, an application was developed

to track human motion with up to four nodes. This application was also developed by Jeffrey

Robble. Figure 24 shows a screenshot of the application.

Figure 24: Human Motion Tracking Application

The user starts from a default, known position. The stick-figure on the display shows this

default position when the application is started. After the body area sensor network is initialized

and successfully connected to the host computer, the application tracks motion from the default

position for all four nodes. The application could be extended to use more nodes, but this provides

an example for interfacing with multiple nodes and converging motion data to manipulate a single

object.

The code for all these applications as well as other “mini-applications” that demonstrate the

use of certain device APIs can be found in the Vibe documentation, separate from this document.

60

11 Future Work & Lessons Learned

While most of the features described in the architecture description have been successfully imple-

mented and tested, there is additional work identified to improve the functionality of the platform.

That work is outlined in this section. Additionally, lessons learned during the development process

are reviewed.

The first aspect of the platform that requires further development was mentioned in the Software

Development section. The port of the µC/OS−II RTOS is currently not functional on the CC430

and is thus not implemented in the current software revision. The RTOS provides the utility of

a priority-based operating system, allowing a developer to create application tasks and assign a

priority to each task. Priority-based task scheduling allows the user to manage the application by

segmenting the application into logical sub-blocks and ensure the responsiveness of the application

by assigning highest priority to the most critical tasks. Currently the tick ISR is causing the

processor to fetch an illegal address. The exact cause is unknown, but since the core CPU between

the CC430 and the 500-series MSP430 (which successfully runs the µC/OS−II port) are identical,

it is speculated that a device-specific errata is the cause of the bug. Further investigation is required.

The current toolchain only allows devices to be programmed from a host computer using the

wireless bootloader. Ideally, when a body area sensor network is created, the network identifies

the firmware version of each device in the body area sensor network and self-updates any devices

with an older revision of the firmware. This could be performed by storing a clean image of the

firmware in flash and modifying the bootloader code to check firmware versions of devices in the

body area sensor network. This functionality would prevent incompatibility issues that may arise

if all devices are not updated prior to use.

Motion data analysis is facilitated with certain DSP techniques. One of those techniques

is known as a Fast Fourier Transform (FFT). The FFT was described in more detail in the

Theoretical Development section. Currently, the Vibe API does not provide a DSP library to the

user for use in motion analysis. Developing a small DSP library would simplify the requirements

of the user application.

From a hardware perspective there are a few bug fixes that should be addressed. Currently,

workarounds are in place to deal with major bugs, but their resolution would strengthen the

61

platform. The first bug mentioned was the omission of pull-up resistors on the system I2C bus.

Simply adding these to the hardware build will fix this issue. Currently, rework is required to add

the pull-up resistors to the current boards. The other major bug is the POR condition that results

from plugging the device into external power via the USB connector. A resolution for this issue

is not yet developed however a simple switch of the two Spy-Bi-Wire pins may provide a working

solution. This is not yet verified. Additionally. the reset trace may be severed after the bootloader

is burned into the ROM. This is an easy fix that requires no additional hardware revisions.

During the development process of Vibe it was decided to develop a single device that im-

plements the entire functionality of the platform in every device worn on the body. Keeping the

hardware identical also streamlines the hardware development process and makes it easier to man-

age prototype builds. The disadvantage of this approach is that the size of each device is larger

than necessary. Devices worn on areas of the body that are not easily visible by the user (e.g. the

thigh), do not require a display. The exclusion of the display was already stated to allow for a

smaller logic board, battery and overall housing. This means that devices can be made smaller and

more wearable. It is estimated that the exclusion of the display can reduce the volume by more

than 50%. This is a significant reduction and would increase the wearability of the device. If an

additional device were produced, further work would be necessary to ensure multiple build config-

urations are possible in the Vibe API. A build for a device with a display and a build for a device

without a display would have to be present. This further complicates the software development

process as well.

Additionally, the wireless interface of Vibe allows external sensors to be connected to the body

area sensor network without the need to build the sensor internally into each Vibe device. One

example mentioned is a heart rate strap. A compatible heart rate breast strap from BM Innovations

was identified, however the software support has not been implemented to interface with it. Having

additional information about the user such as the heart rate may increase the accuracy of profiling

and motion tracking in the human body.

Lastly, Vibe was developed to log motion data to the external flash for later upload to a base

station. Currently, no base station hardware or software support for base station communication

has been implemented in the Vibe APIs leaving the task to the user application layer. The

62

development of standard base station hardware and a communication protocol would simplify the

task of off-loading data from a body area sensor network and storing the data in a central location.

Vibe has provided the opportunity to exercise knowledge in hardware and low-level software,

comprehensively covering many aspects of the Electrical Engineering curriculum at RIT. Vibe

includes both analog and digital hardware design. Although many of the components are digital,

PCB design is inherently analog and good analog design techniques must be utilized to develop a

robust system.

Software design techniques were also studied throughout the development of Vibe. Developing

a framework that others will use to write applications is a challenging task. One must ensure their

code is compact, to maximize room for user application code, and robust, so that the debugging

process may be isolated to user code. Additionally the project needs to be well-documented so

that application development does not require an unnecessarily long learning curve. These are all

design techniques that the development of Vibe has reinforced.

Lastly, Vibe provided a great opportunity to work across multiple disciplines. A collaboration

was fostered with Industrial Design students to develop the design and aesthetic of the device. The

Mechanical Engineering department at RIT also helped to verify the manufacturability and produce

the body of the device. Work with many various manufacturers was necessary to secure components

and discuss design feasibility. The opportunity to work with many different disciplines is a very

rewarding experience and will be useful in the transition into industry, where multi-disciplinary

work is required on a daily basis.

Vibe was developed from concept to functional prototype throughout the scope of the project.

The opportunity to develop a device from start to finish is truly rewarding and brings an un-

derstanding of integrated design. Although an engineer may be responsible for a certain aspect

of a project, the ability to visualize the system as a whole and understand how personal design

decisions affect the entire system is vital. These aspects were reinforced through working on Vibe.

63

1 Appendix A: Concept Development

Figure 25 presents a market comparison of commercially available devices.

!!"#

$%#&'(

")*+,+-+&.'

/01

"'233"-'

4"1

5'

2-)%1

")"6'7+,.'

815",0#

3"'

9"0)':-;

<'=.6+'

70))"6.'>%?"'

8#)"#

,",'

@;65+$"'

A$"6'8BC

'D0)0'

!)+60&"'233"$$')+'D0)0'

72!/E'

:+61':03)+6'

"#$#%&'(!

)*%+,$!-.*/.01!

!!*!

*!*!

!!/*2!3##4$!

5&#6

7&8!97:,7;!

<;%=>$,$!?

=%:@7&6!

/*,;AB:!CB::7;$8!DEF

!G;:#&;%=!H=%$(!

I,&#=#$$!

J>;'8!KJL!

?%&%==#=!

?&7'#$$,;1!MBA!:7!N!F#O,'#$P!

I&,$:*3

%:'(!@7&6

!/QR!+!/QS!+!TQS!

'6!

U<9!E7%'(!

!!*!

*!*!

*!*!

E"/S)/!

!T!>#%&!

?#V76

#:#&8!E%=7&,'!

W+A#;V,:B&#!

2*,;AB:!CB::7;$8!DEF

!X!

KJL!F7'4!

*!D%&1#!3

%,$:*'=,A!V#O,'#!

L7V>!9

#V,%Y!Z7!I

#%&!H,:!)*%+,$!-.*/1!

/SQS!:7!2SQS!E!

*!RN4[

!:7!/S9

[!

S!*)SSI

.6/!

*!D,*A7=>!R*\!V%>$!

H,:;#$$!97;,:7&,;18!"#$#%&'(!?=%:@7&6

!

I,&#=#$$!3

%:'(!V,$A=%>8!K

$#&!LB::7;!

T2!V%>$!7@!=711,;1!

KJL!

*!<&6C%;V!

RQ/!+!NQ/!+!TQ)!'6!

G9!J>$:#6

$!<':,:&%'!

/*%+,$!2S]

^!*!

*!*!

*!*!

/S4!(&$!]B6

%;.<;,6

%=!<':,O,:>!9

7;,:7&!97V#!CB::7;!

T/0U!H=%$(!

00!V%>$!7@!=711,;1!MXP!

?&7A&,#:%&>!E%C=#!

*!I&,$:*3

%:'(!!TQ/!7^!

5&,:&%'!"

)F!

)*%+,$!T]^!

*!*!

*!*!

*!T+<

<<!

)S!V%>$!E%=7&,'!

W+A#;V,:B&#!

/*,;AB:!CB::7;$8!?%1#&!DEF

!

)!(&$!_!

T]^!

\!V%>$!_!

QS/!]^!

KJL!F7'4!

*!I%,$:*'=,A!A%1#&!!\QT!+!RQN!+!/Q0!

'6!

?(,==,A$!

F,&#':!D,@#!

)*%+,$!*!

*!*!

*!*!

)!3##4$!

F%,=>!#+#&',$#!

67;,:7&8!E%=7&,'!W+A#;V,:B&#!

T*,;AB:!CB::7;8!DWF!A&71&#$$!

C%&!1&%A(!X!

KJL!

*!H,:$!,;!A7'4#:!7&!%$!;#'4=%'#!A#;V%;:!

E=#O#6#V!

U,;#:,$#;$#!

!!

!!

!!

!!

!!

!!

!

5G*E(&7;7$!W`2)S!

)*%+,$!!-.*/.01!

*)S!:7!0R!E!

)S*TRS!4?%!

TQRA<!&#$Q!

MTS'6P!

*!*!

*!TQR!6

:($!F#O#=7A6

#;:!?=%:@7&6

8!D,;4!3,:(!L

&#%$:!L%;V!

R!,;AB:*CB::7;$8!J5a!DEF

!

G;:#&;%=!H=%$(!M04L

P!

I,&#=#$$!

J>;'8!KJL!

EB$:76!

F#O#=7A6

#;:!3,:(!

J,6A=,',5

G!

I&,$:*3

%:'(!@7&6

!

J6%&:I

%:'(!!

!!

!!

!!

!!

!L=B#:77:(!:#:(#&,;1!

!!

!"#$%&'"()*+#

,-.&$-/0(,&%-12

(,34&5&#&/-12

(,3&(6&.718981*&:(/81(,0&(;-,.18/<&8/&0(:

-&7((,)8/.18(/=&

!

Figure 25: Commercially Available Device Comparison Matrix

64

Figure 26 presents a comparison of the major microcontrollers that were selected for Vibe.

Ultimately the CC430 was chosen for its higher degree of support, wireless capabilities and the

developer’s familiarity with the MSP430 platform among others.

Pro

ceso

rB

us W

idth

Co

reM

ax. C

lock

S

peed

Oscilla

tor

Pack

ag

eC

ore

V

olta

ge

Perip

hera

l V

olta

ge

Active

Cu

rren

tS

tby C

urre

nt

Int. Fla

shIn

t. SR

AM

AD

CU

SA

RT

US

BG

PIO

STM

32

W3

2-b

itARM

Cortex M

324 M

Hz

Sin

gle 2

4 M

hz

Crystal

QFN

40

6x6

Q

FN4

8 7

x7

Intern

al 1.2

5-

1.8

V reg

s2.1

-3.6

V9 m

A @

24 M

Hz

40

0-8

00

nA

12

8kB

8kB

12-b

it 23 ksp

s

2-U

SARTs

I2C, S

PI, U

ART, IrD

AN

o24

STM

32

32-b

itARM

Cortex M

37

2 M

Hz

Sin

gle 2

4 M

hz

Crystal

QFN

40

6x6

Q

FN4

8 7

x7

Intern

al 1.2

5-

1.8

V reg

s2.1

-3.6

V17m

A @

24M

Hz

37m

A @

72M

hz

40

0-8

00

nA

12

8kB

8kB

12-b

it 23 ksp

s

2-U

SARTs

I2C, S

PI, U

ART, IrD

AYes

24

CC

43

016-b

itM

SP

27 M

Hz

Sin

gle 2

6-2

7

MH

z Crystal

QFN

64 9

x9

QFN

48 7

x71.8

V-3

.6V

1.8

-3.6

V

(2.2

for fu

ll d

ata

rate

)1

60

uA

/M

hz

1.0

uA (1

.7uA

with

RTC

)32kB

4kB

8-C

han

nel 1

2-

bit (sam

ple

rate?)

2-U

SARTs

I2C, S

PI, U

ART, IrD

AN

o4

0

Pro

ceso

rTim

ers

DM

AFS

MC

Zig

Bee

Tx C

urre

nt

(w/

CP

U)

Rx C

urre

nt

(w/

CP

U)

Data

rate

En

cryptio

nH

W C

RC

Gen

Ded

icate

d

HW

DS

P Lib

Wie

less

Sta

ckFla

sh

Pro

gra

mR

TO

S

STM

32

W2x1

6-b

it, No

RTC

6-C

H Fu

ll-Duplex

No

2.4

GH

z32m

A27m

A>

250kb

ps?

AES128

YesIn

tegrated

LD

O H

W

Mult/D

ivN

oR4FC

EJTA

G: 5

pin

s Serial W

ire: 2uCLin

ux

STM

32

2x1

6-b

it, No

RTC

6-C

H Fu

ll-Duplex

No

--

--

-N

oIn

tegrated

LD

O H

W

Mult/D

ivN

o-

JTAG

: 5 p

ins

Serial W

ire: 2uCLin

ux

CC

43

02

x1

6-

bit+

HW

RTC

3-C

H (Fu

ll/Half?)

Duplex

No

<1G

Hz

17

.9 m

A1

9.2

mA

(2

50

kb

ps)

50

0kb

ps

AES128

Yes32-b

it HW

M

ult R

TCN

oSim

pliciT

I (<

8kB

typ.

~4kB

)

JTAG

: 5 p

ins

Serial W

ire: 2Tin

yOS,

uC/O

S-II

Figure 26: Analysis of Microcontroller Contenders

Figure 27 presents a list of the customer needs generated for the original tremor sensing appli-

cation that inspired the Vibe platform.

Figure 28 presents a list of the engineering specifications generated for the original tremor

65

Revision A BASNCustomer Need # Description

Biometric Data Acquisition/ProcessingCN1 Shall detect body vibrations over whole tremor vibration frequency rangeCN2 Shall sense other body parameters of interest (e.g. body temperature) and correlate

it in real-time with vibration data CN3 Shall alert user to oncoming body tremors as determined by tremor detection algorithmCN4 Shall alert caretaker/physician monitor, in-range, of a critical conditionCN5 Shall log critical conditions on local, non-volatile storageCN6 Each sensor shall locally store its own sensor informationCN7 Sensor device should perform all data analysis locally, no realtime streaming to base station

SafetyCN8 No sharp edges or harmful protrusionsCN9 Comfortable, non-obtrusive form-factorCN10 30m water-resistant (splash proof)CN11 Strap suitable for wrist and ankle wearabilityCN12 Device shall cause no harm to user under normal useCN13 Immunity to light amounts of dustCN14 Over-current, ESD protection

User InterfaceCN15 User-input buttons for function setting, general interactivityCN16 Low-power, lit display for user feedbackCN17 Internal speaker/buzzer for audible alarm to userCN18 Real-time-keeping standby application for auxiliary function as a watch

Sensor NetworkCN19 Scalable Body Area Sensor Network (BASN) for localized sensing of tremorsCN20 Standard wireless protocol for ease of development, rapid developmentCN21 Fast, local communication between BASN connected devicesCN22 Wireless network should not interfere with other standard wireless devicesCN23 Automatic arbitration of network node structure (zero configuration networking)CN24 Shall serve rudimentary functions even under a single node "network" (i.e. single-worn

device, no BASN)CN25 Automatic upload of logged data to storage server via a home access point when user

is within range of home deviceCN26 Automatic, wireless firmware upgradability when user is within range of home access pointCN27 Shall allow caretaker to remotely log into webserver for latest logged patient data and ability

to upload latest firmware to be pushed to devicesCN28 Device shall have a monitor mode, whereby a device outside the BASN (and in monitor

mode) can wirelessly monitor the status of an in-range BASN with permission from userCN29 Report strength of connection to wireless base station when in-range

Access to Biometric DataCN30 Web interface for physicians/user to access logged dataCN31 Secure access to logged dataCN32 Shall allow physician to view multiple patientsCN33 Shall be able to remotely upload new firmware to push to devices

Lifetime (Battery/Device Lifetime)CN34 2-4 week battery life under moderate, "normal" useCN35 Low-power wireless communication for extended battery lifeCN36 Rechargeable battery with quick charge time and sufficient recharge cyclesCN37 5+ year device lifetime

ExpandabilityCN38 Interface to connect to external biomedical sensorsCN39 Shall be able to log and include peripheral sensor data in tremor analysis

GeneralCN40 Overall device shall be low-cost to manufacture, sustain.CN41 Wrist watch-like form factor, for wearabilityCN42 All devices equal in ability (i.e. no "master" device always required to be worn)

Application PlatformCN43 Hardware/Firmware should provide low-level APIs to allow high-level app development

Figure 27: Customer Needs Developed From Tremor Sensing Application

sensing application that inspired the Vibe platform.

66

Revision A

Engr. S

pec. #

Importance

Source

Specification (description)

Unit of M

easureM

arginal ValueIdeal Value

Com

ments/S

tatus

Biom

etric Data A

cquisition/ProcessingE

S1

CN

13-axis accelerom

eter with ±2/8 g range

g (force)N

/AE

S2

CN

1H

W FFT or sufficient D

SP capability for FFT data analysis @

40kHz

ES

3C

N2

2-axis digital gyroscope with …

rangeg (force)

N/A

accelerometer + gyroscope for com

plete IMU

ES

4C

N2

Digital tem

perature sensor with 30-40˚C

range˚C

(centigrade)±0.5˚C

senses local body temperature

ES

5C

N2

Digital tem

perature sensor with -25-40˚C

range˚C

(centigrade)±0.5˚C

senses ambient tem

perature to contrast with body tem

peratureE

S6

CN

3P

iezo buzzer diaphragmdB

kHz

buzzer to alert user of any critical conditions (e.g. tremors)

ES

7C

N4

Wireless heartbeat w

ith BA

SN

status report to monitoring device @

1Hz

Hz

-1

notify caretaker of any critical conditions, in/out range of BA

SN

ES

8C

N5

16Mb external flash for data logging

Mb

!16used for logging tim

estamped, processed biom

etric dataE

S9

CN

5C

yclic data logging of normal activity (oldest data overw

ritten if notuploaded to basestation before log is full)

ES

10C

N5

The critical data log records critical conditions and takes precedence oversize of norm

al data log dynamically changes based on the

normal activity log (both share external flash)

growing size of critical data log as critical events are sensed

ES

11Safety

ES

12C

N8

custom designed C

NC

-cut smooth exterior case void of pointed edges

ES

13C

N8

durable plastic construction bodyE

S14

CN

9com

pact, ultra-thin device profile (dim. ## x ## x ## m

m)

ES

15C

N10

10cm w

ater-resistant construction with attached U

SB

port plugw

ork towards IS

O2281 standard com

plianceE

S16

CN

10Li-poly non-rem

ovable internal rechargeable batterym

AH

250+E

S17

CN

10sealed button diaphragm

s over user-input switches

ES

18C

N11

detachable standard watch strap for w

rist wear

ES

19C

N11

detachable velcro strap for ankle & other appendange w

earE

S20

CN

13JIS

Grade 5 dust ingress resistance (IE

C 529)

ES

21C

N14

fast-acting fused charging circuitrym

A500

ES

22C

N14

overcharge protection built into internal rechargeable batteryE

S23

CN

14H

uman-body m

odel ("1kV) external E

SD

protectionkV

1000E

S24

CN

14E

SD

supressors on micro-U

SB

data/charging portU

ser InterfaceE

S25

CN

152 side-facing norm

ally open SP

ST sm

d tactile switches

user interactivity (function selection, time-setting, general use)

ES

26C

N16

0.6" diagonal, white O

LED

displaydots (pixels)

0.6", 128x96U

I display. Chosen for low

-power, self-backlit, low

-cost solutionE

S27

CN

17Thin piezo buzzer diaphragm

mm

(thickness)<0.3

ES

28C

N18

Crystal tuning fork for real-tim

e clock oscillator drivingkH

z± 20 ppm

32.768Sensor N

etwork

ES

29C

N19

Star netw

ork topology with variable num

ber of leaf nodes and one conduitthis topology is sim

ple and easily scalableE

S30

CN

19U

p to 5 leaf-node devices, for a maxim

um B

AS

N of 6 devices

max. 5 leaf nodes and 1 conduit device

ES

31C

N20

Standard 802.15.4 (ZigB

ee) wireless com

munication

also covers CN

22, standard protocol reduces interference with

other devices utilizing standardized wireless protocols

ES

32C

N25

periodic ping from basestation to discover BASN

s in range for data uploadH

z (ping freq)1

ES

33C

N25

master node (conduit) coordinates data upload from

all leaf nodesE

S34

CN

26m

aster downloads firm

ware update and coordinates update of all leaf

nodesE

S35

CN

27PH

P+MySQ

L webserver to support user login front-end

ES

36C

N28

selectable "monitor m

ode" for monitoring status of a nearby B

AS

NE

S37

CN

28approval required from

BA

SN

to allow a m

onitor device to connect

ES

38C

N28

periodic status update to monitoring device(s)

Hz (update freq)

1

ES

39C

N29

RSSI reading capability (to m

easure strength of wireless connection

to home basestation

Figure 28: Technical Specifications Developed From Tremor Sensing Application

67

2 Appendix B: Vibe API Function List

This section introduces the Vibe API functions for application development on the Vibe platform.

Each function is categorized by API type (e.g. motion sensor APIs). The API prototype, the

source file the function appears and a description are provided for each API function. In addition,

the function arguments and return value are explained.

2.1 General API Functions

+ void VIBEInitializeDevice( void ) File: system.c

Main initialization function. Must be called at the beginning of user’s application. Sets the Vibe

device in a default state. Failure to call this function before start of application will result in

unknown behavior.

Arguments

none

Return Value

none

Errata

No known errata.

2.2 Real-Time Clock (RTC)

+ void VIBEStartRTC( date t * date ) File: time.c

Starts the Real-Time Clock (RTC) with the date specified in the supplied date t * date data

structure. RTC is active immediately after function call. RTC remains active through sleep mode.

Arguments

date t * date Pointer to date t structure containing date information

Return Value none

Errata: No known errata.

+ void VIBEStopRTC( void ) File: time.c

Stops the internal RTC. Must call VIBEStartRTC in order to restart the RTC.

68

Arguments

none

Return Value none

Errata: No known errata.

+ uint8 t VIBEReturnCurrentDate( date t * current ) File: time.c

Returns the current time in Roman, 24-hour format in the date t struct specified.

Arguments

date t * current Pointer to date t structure to fill with current date information

Return Value

Success (’1’) or Failure (’0’) to read date status. If consecutive failure to reads occur, the user

should restart the real-time clock, using VIBEStartRTC( )

Errata: No known errata.

+ void VIBESetRTCAlarm( date t date, uint8 t recurStatus ) File: time.c

Sets the RTC alarm function to the date specified in date t date. Set flags appropriately in

recurStatus to enable reocurring alarms.

Arguments

date t * date date t structure containing alarm information in Roman, 24-hour mode. Alarms

are triggered whenever the RTC registers are equal to the date fields set. For example, setting the

hour field in date t date to 11, queues an alarm whenever the RTC hour counter reaches 11.

recurStatus Setting the following flags enables reoccurring alarms for the respective. For

example, setting the RTC hour to 11 and setting the RTC HOUR RECUR flag sets an alarm

everyday for 11:00.

Possible Flags:

RTC DAY RECUR: Alarm is reoccurring according to the day of the month.

RTC DOW RECUR: Alarm is reoccurring according to the day of the week.

RTC HOUR RECUR: Alarm is reoccurring according to the hour.

RTC MIN RECUR: Alarm is reoccurring according to the minute.

Return Value

69

none

Errata: No known errata.

+ void VIBEClearRTCAlarm( void ) File: time.c

Clears any instantiated RTC alarm.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBERTCAlarmHook( void ) File: hooks.c

User-implemented ISR hook. This function is called whenever an RTC alarm is triggered.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBERTCAlarmHook( void ) File: hooks.c

User-implemented ISR hook. This function is called whenever an RTC alarm is triggered.

Arguments

none

Return Value

none

Errata: No known errata.

2.3 Input/Output Peripherals

+ uint8 t VIBEGetButtonStatus( void ) File: buttons.c

Returns the status of user buttons A&B.

70

Arguments

none

Return Value

Status of the buttons (pressed, depressed) is returned. Bit 0 indicates current status of button

A (’0’ depressed, ’1’ pressed). Bit 1 indicates the current status of button B.

Errata: No known errata.

+ void VIBEButtonEventHook( void ) File: hooks.c

User-implemented ISR hook. This function is called in the event of a user-button status change

(either a press or depress). The user may check the current status of the buttons using VIBEGet-

ButtonStatus( ) to determine the appropriate action.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBEStartOLED( void ) File: display.c

Releases the display from reset state and initializes the display to default setting of all pixels

cleared. Call VIBEStopOLED to place the display back in a reset, low-power state.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBESleepOLED( void ) File: display.c

Places the display in a low-power, sleep state. The contents of GDDRAM (graphics data RAM)

are saved through sleep mode.

Arguments

71

none

Return Value

none

Errata: No known errata.

+ void VIBEWakeOLED( void ) File: display.c

Wakes the display from a low-power sleep mode. Contents of GDDRAM (graphics display data

RAM) are held through sleep mode and restored to the display upon waking.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBEGraphicsClearDisplay( void ) File: hooks.c

Resets the contents of GDDRAM setting all display pixels to black.

Arguments

none

Return Value

none

Errata: No known errata.

+ void VIBEGraphicsClearArea( void ) File: display.c

Clears a rectangular area of the display, setting the pixels black.

Arguments

pixelCoord t start

Bottom left coordinate of rectangular area to be cleared.

pixelCoord t end

Top right coordinate of rectangular area to be cleared.

Return Value

72

none

Errata: No known errata.

+ void VIBEGraphicsDrawPixel( pixelCoord t pixel, pixelColor8 t color ) File: display.c

Draws a single pixel on the display with the specified color. Note that this function is inefficient

for a large number of pixels. Use the VIBEGraphicsDrawBitmap( ) function for drawing bitmaps

on the display.

Arguments

pixelCoord t pixel

pixelCoord t data structure holding x,y coordinates of single pixel.

pixelColor8 t color

8-bit color of pixel to be displayed

Return Value

none

Errata: 16-bit color mode is currently not supported.

+ void VIBEGraphicsDrawLine( pixelCoord t start, pixelCoord t end, pixelColor8 t lineColor

) File: display.c

Draws a single line on the display with the specified color and starting/ending coordinates.

Arguments

pixelCoord t start

pixelCoord t data structure holding x,y coordinates of line starting pixel

pixelCoord t end

pixelCoord t data structure holding x,y coordinates of line ending pixel

pixelColor8 t color

8-bit color of the line to be displayed.

Return Value

none

Errata: Currently roll-over of line coordinates is not support. Ensure that starting and

ending coordinates are within the bounds of the display and that the starting coordinate of the

73

line is left to the ending coordinate.

+void VIBEGraphicsDrawRectangle( pixelCoord t start, pixelCoord t end, pixelColor8 t*

lineColor, pixelColor8 t* fillColor ) File: display.c

Draws a filled, rectangular area on the display with the specified color and starting/ending coor-

dinates.

Arguments

pixelCoord t start

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the rectangular

area.

pixelCoord t end

pixelCoord t data structure holding x,y coordinates of the top right pixel of the rectangular

area.

pixelColor8 t lineColor

8-bit color of the line bordering the rectangular area.

pixelColor8 t fillColor

8-bit color of the rectangular area fill.

Return Value

none

Errata: Currently only 8-bit mode is supported.

+ void VIBEGraphicsCopyArea( pixelCoord t startCopy, pixelCoord t endCopy, pixelCoord t

startPaste ) File: display.c

Copies a specified rectangular area of the display and pastes it to another location on the display.

Arguments

pixelCoord t startCopy

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the rectangular

area to be copied.

pixelCoord t endCopy

74

pixelCoord t data structure holding x,y coordinates of the top right pixel of the rectangular

area to be copied.

pixelCoord t startPaste

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the location to

paste the copied rectangular area.

Return Value

none

Errata: Currently roll-over the rectangular area is not supported. Ensure that starting pixel

of the rectangular area to copy is to the left of the ending pixel and that the area to be pasted to

is large enough to paste the copied area without going out-of-bounds of the display.

+ void VIBEGraphicsMoveArea( pixelCoord t startCopy, pixelCoord t endCopy, pixelCoord t

startMove ) File: display.c

Moves a specified rectangular area of the display to another location. The pixels of the previous

location are reset to black.

Arguments

pixelCoord t startCopy

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the rectangular

area to be copied.

pixelCoord t endCopy

pixelCoord t data structure holding x,y coordinates of the top right pixel of the rectangular

area to be copied.

pixelCoord t startMove

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the location to

draw the rectangular area being moved.

Return Value

none

Errata: Currently roll-over the rectangular area is not supported. Ensure that starting pixel

of the rectangular area to copy is to the left of the ending pixel and that the area to be pasted to

is large enough to paste the copied area without going out-of-bounds of the display.

75

+ void VIBEGraphicsPutChar( pixelCoord t charCoord, pixelColor8 t charColor, char ch,

const font t * font ) File: display.c

Writes a single character to the display with the given font set and character color.

Arguments

pixelCoord t charCoord

pixelCoord t data structure holding x,y coordinates of top left pixel of the character.

pixelColor8 t charColor

pixelColor8 t data structure containing 8-bit color information of character to be drawn to the

display.

char ch

ASCII representation of the character to be drawn to the display.

font t * font

Pointer to data structure holding font information for the desired character set.

Return Value

none

Errata: Currently, only 8-bit color mode is supported.

+ void VIBEGraphicsPutStr( pixelCoord t charCoord, pixelColor8 t charColor, char *

str, const font t * font ) File: display.c

Writes a string of characters to the display with the given font set and character color.

Arguments

pixelCoord t charCoord

pixelCoord t data structure holding x,y coordinates of top left pixel of the first character.

pixelColor8 t charColor

pixelColor8 t data structure containing 8-bit color information of the string to be drawn to the

display.

char * str

Pointer to the first ASCII character of the string to be drawn to the display. All strings must

be null-terminated.

76

font t * font

Pointer to data structure holding font information for the desired character set.

Return Value

none

Errata: Currently, only 8-bit color mode is supported.

+ void VIBEGraphicsDrawBitmap( pixelCoord t start, uint8 t bitmapHeight, uint8 t bitmapWidth,

uint8 t * bitmap ) File: display.c

Draws a user specified bitmap to the display.

Arguments

pixelCoord t start

pixelCoord t data structure holding x,y coordinates of the bottom left pixel of the bitmap to

be drawn to the display

uint8 t bitmapHeight

Specifies the number of pixel rows spanned by the bitmap.

uint8 t bitmapWidth

Specifies the number of columns spanned by the bitmap.

uint8 t * bitmap

Pointer to the data array containing bitmap data.

Return Value

none

Errata: Currently roll-over the rectangular area is not supported. Ensure that starting pixel

of the bitmap area to display keeps the bitmap within the bounds of the display.

2.4 External Flash Storage

+ uint8 t VIBEFlashChipErase( void ) File: flash.c

Erases all flash data except for areas restricted by the system and by the user, using VIBESetFlashProtection(

). The erasure process may take up to 35 ms.

Arguments

77

none

Return Value

Success status of flash erasure process. A non-zero value indicates a successful erasure and a

zero value indicates a failure.

Errata: No known errata.

+ uint8 t VIBEFlashRead( uint8 t *address, uint8 t *buffer, int byteCount ) File: flash.c

Reads a specified number of bytes starting at a specified address in flash.

Arguments

uint8 t *address

Starting address of flash memory to be read from.

uint8 t * buffer

Pointer to starting byte of buffer to store read data.

int byteCount Number of consecutive bytes to be read from flash. The buffer must accom-

modate this byte length.

Return Value

Success status of flash read process. A non-zero value indicates a successful read and a zero

value indicates a failure.

Errata: No known errata.

+ uint8 t VIBEFlashWrite( uint8 t *address, uint8 t *buffer, int byteCount ) File: flash.c

Writes a specified number of consecutive bytes to flash starting at a specified address.

Arguments

uint8 t *address

Starting address of flash memory location to be written to.

uint8 t * buffer

Pointer to starting byte of buffer containing data to be written to flash.

int byteCount Number of consecutive bytes to be written to flash.

Return Value

78

Success status of flash write process. A non-zero value indicates a successful write and a zero

value indicates a failure.

Errata: No known errata.

+ uint8 t VIBESetFlashProtection( uint8 t policy ) File: flash.c

Sets the write/erase protection policy for data blocks in flash. The write policies must be set

appropriately before data is either read or written.

Arguments

uint8 t policy

8-bit byte containing the flash write policy.

Return Value

Success status of policy update. A non-zero value indicates a success to update the policy and

a zero value indicates a failure.

Errata: No known errata.

+ uint8 t VIBEStartDataLog( uint8 t * logPolicy, uint8 t logRate, uint8 t *address File:

flash.c

Starts a new data log to flash at the starting address specified by the user. The logPolicy argument

defines what data is placed in the data log. The logRate argument defines the frequency at which

new data is written to the data log.

Arguments

uint8 t logPolicy

8-bit byte containing the flash write policy. The following macros are used to set the log policy.

LOG RTC - Enable time-stamping for each entry using the real-time clock date. LOG ACCEL -

Enable accelerometer triaxial data logging. LOG GYRO - Enable gyroscope triaxial data logging.

LOG COMPASS - Enable compass data logging. LOG AMBIENT TEMP - Enable ambient temperature

data logging.

uint8 t logRate

Specifies the rate at which data is logged to external flash. The following macros may be used

to specify the data logging rate:

79

LOG 0 5 HZ - Log data at 0.5 Hertz. LOG 1 HZ - Log data at 1 Hertz. LOG 2 HZ - Log data

at 2 Hertz. LOG 4 HZ - Log data at 4 Hertz. LOG 8 HZ - Log data at 8 Hertz. LOG 16 HZ - Log

data at 16 Hertz. LOG 32 HZ - Log data at 32 Hertz. LOG 64 HZ - Log data at 64 Hertz.

uint8 t *address

Specifies the starting address of the data log in flash memory.

Return Value

Success status of data log initialization. A non-zero value indicates a success to begin the data

log and a zero value indicates a failure.

Errata: No known errata.

+ uint8 t VIBEStopDataLog( uint8 t *address File: flash.c

Stops a currently running data log and returns the address of the last data log entry.

Arguments

uint8 t *address

Pointer to data structure to hold the ending address of the data log returned by the function.

The data log information exists between the starting address specified by the user and the ending

address returned by this function.

Return Value

Success status of data log initialization. A non-zero value indicates a success to stop the data

log and a zero value indicates a failure.

Errata: Currently no function is implemented to read the data log information out in a

standardized format. The format of the data log is specified in the source code file flash.c.

Developers should user VIBEFlashRead( ) with the appropriate address and byte count to read

the log information.

80

2.5 Triaxial Accelerometer

+ void VIBEStartAccelerometer( uint8 t sampleRange, uint8 t sampleMode ) File: ac-

celerometer.c

Starts the triaxial accelerometer with the given sample range, mode and frequency. Accelerometer

data is updated in the system accel vAccel data structure at the specified frequency.

Arguments

uint8 t sampleRange Defines the sampling range of the accelerometer (either +/-2 GForce

or +/-8 GForce. The following macros should be used to specify the range:

ACCEL 2G RANGE - +/- 2 G Force sampling range

ACCEL 8G RANGE - +/- 8 G Force sampling range

uint8 t sampleMode Defines the sampling mode of the accelerometer including sampling fre-

quency. Currently only active measurement modes are available. The following macros should be

used to set the proper mode:

ACCEL MODE MEAS 40Hz - Measure acceleration data at 40 Hertz.

ACCEL MODE MEAS 100Hz - Measure acceleration data at 100 Hertz.

ACCEL MODE MEAS 400Hz - Measure acceleration data at 400 Hertz.

Return Value

none

Errata: No known errata.

+ void VIBEStopAccelerometer( void ) File: accelerometer.c

Stops the accelerometer and places it in a low-power sleep state.

Arguments

none

Return Value

none

Errata: No known errata.

81

+ uint8 t VIBEGetAccelData( struct accel *accelData ) File: accelerometer.c

Returns the last accelerometer sample data in the specified structure. In addition to the automatic

updates to the system accel vAccel data structure, this function may be used to force a reading

of the last accelerometer sample.

Arguments

struct accel *accelData - accel data structure to hold read data.

Return Value

Success status of data read. A non-zero value indicates a success to read data and a zero value

indicates a failure.

Errata: No known errata.

+ void VIBEConvertAccelerationDataToMgrav( struct accel * accelData ) File: accelerom-

eter.c

Converts raw acceleration data in an accel struct to units milligravs. Milligravs is the working

unit for acceleration data and should be used to interpret data, however raw acceleration data may

be used for data logging and wireless transmission to reduce data bandwidth.

Arguments

struct accel *accelData - accel data structure holding the raw acceleration data to be

converted to units milligravs.

Return Value

none

Errata: No known errata.

+ void VIBEAccelHook( void ) File: hooks.c

User-implemented ISR hook. This function is invoked when new accelerometer data is available.

The user may check the accel vAccel system data structure to obtain new accelerometer data.

This function should be short in length as it is called within the context of the system accelerometer

ISR.

Arguments

82

none

Return Value

none

Errata: No known errata.

2.6 Triaxial Gyroscope

+ void VIBEStartGyroscope( uint8 t sampleFreq ) File: gyroscope.c

This function is called to start the triaxial gyroscope and begin sampling data. Data is sampled at

the specified frequency. Users may retrieve new data from the gyro vGyro data structure or use

specified API functions to read gyroscope data.

Arguments

uint8 t sampleFreq - Specifies the frequency at which the gyroscope sensor is sampled. The

following macros should be used to specify the sampling frequency.

GYRO MEAS 1KHZ - Measure gyroscope data at 1 kilohertz.

GYRO MEAS 500HZ - Measure gyroscope data at 500 hertz.

GYRO MEAS 100HZ - Measure gyroscope data at 100 hertz.

GYRO MEAS 50HZ - Measure gyroscope data at 50 hertz.

Return Value

none

Errata: No known errata.

+ void VIBEStopGyroscope( void ) File: gyroscope.c

Stops the triaxial gyroscope sensor and places it in a low-power, shutdown state.

Arguments

none

Return Value

none

Errata: No known errata.

83

+ uint8 t VIBEGetGyroData( struct gyro *gyroData ) File: gyroscope.c

Returns the last gyroscope sample data in the specified structure. In addition to the automatic

updates to the system gyro vGyro data structure, this function may be used to force a reading of

the last gyroscope sample.

Arguments

struct gyro *gyroData - accel data structure to hold read data.

Return Value

Success status of data read. A non-zero value indicates a success to read data and a zero value

indicates a failure.

Errata: No known errata.

+ void VIBEGyroHook( void ) File: hooks.c

User-implemented ISR hook. This function is invoked when new gyroscope data is available. The

user may check the gyro vGyro system data structure to obtain new gyroscope data. This function

should be short in length as it is called within the context of the system gyroscope ISR.

Arguments

none

Return Value

none

Errata: No known errata.

2.7 Digital Compass

+ void VIBEStartCompass( uint8 t sampleFreq ) File: compass.c

Starts the digital compass with the given sampling frequency. Digital compass heading information

is automatically updated in the system compass vCompass data structure at the specified sampling

frequency. The user may also use VIBEGetCompassData( ) to perform a manual read of the

compass sensor.

Arguments

84

uint8 t sampleMode Defines the sampling frequency of the digital compass. The following

macros should be used to set the proper sampling frequency:

GYRO MEAS 1KHZ - Measure compass data at 1 kilohertz.

GYRO MEAS 500HZ - Measure compass data at 500 hertz.

GYRO MEAS 100HZ - Measure compass data at 100 hertz.

GYRO MEAS 50HZ - Measure compass data at 50 hertz.

Return Value

none

Errata: No known errata.

+ void VIBEStopCompass( void ) File: compass.c

Stops the compass and places it in a low-power sleep state.

Arguments

none

Return Value

none

Errata: No known errata.

+ uint8 t VIBEGetCompassData( struct compass *compassData ) File: accelerometer.c

Returns the last sampled data from the compass in the specified structure. In addition to the

automatic updates to the system compass vCompass data structure, this function may be used to

force a reading of the last compass sample.

Arguments

struct compass *compassData - compass data structure to hold read data.

Return Value

Success status of data read. A non-zero value indicates a success to read data and a zero value

indicates a failure.

Errata: No known errata.

85

+ void VIBEConvertCompassDataToHeading( struct compass * compassData ) File: com-

pass.c

Converts raw compass data in a compass data structure to an angular heading. An angular heading

is the working unit for compass data and should be used to interpret data, however raw compass

data is useful for data logging as it reduces the amount of computation necessary to produce a

result from the compass.

Arguments

struct compass *compassData - compass data structure holding the raw compass data to

be converted to units degrees.

Return Value

none

Errata: No known errata.

+ void VIBECompassHook( void ) File: hooks.c

User-implemented ISR hook. This function is invoked when new compass data is available. The

user may check the compass vCompass system data structure to obtain new compass data. This

function should be short in length as it is called within the context of the system compass ISR.

Arguments

none

Return Value

none

Errata: No known errata.

86

Bibliography

[1] Cadsoft. Cadsoft online: Home of the eagle layout editor, August 2010. http://www.cadsoft.

de/.

[2] Advanced Circuits. Advanced circuits tips and tools, August 2010. http://www.4pcb.com/

standard-custom-order-pcbs/.

[3] SunPower Corp. Press release: Sunpower announces new world record solar cell efficiency, June

2010. http://investors.sunpowercorp.com/releasedetail.cfm?ReleaseID=482133.

[4] Elisabetta Farella, Augusto Pieracci, Luca Benini, Laura Rocchi, and Andrea Acquaviva. In-

terfacing human and computer with wireless body area sensor networks: the wimoca solution.

Multimedia Tools Appl., 38(3):337–363, 2008.

[5] David Fontaine, Dominique David, and Yanis Caritu. Sourceless human body motion capture.

In In Proc. of Smart Objects Conference SOCO03, 2003.

[6] D. M. Gavrila. The visual analysis of human movement: A survey. Computer Vision and

Image Understanding, 73(1):82 – 98, 1999.

[7] John Geen and David Krakauer. New iMEMS angular-rate-sensing gyroscope, Analog Dia-

logue, 2003. Dialogue, 37-03.

[8] 4D Systems Inc. 4d systems, research and development, August 2010. http://www.

4dsystems.com.au/.

[9] Honeywell International Inc. 3-axis digital compass ic hmc5843. Application Note,

June 2010. http://www.honeywell.com/sites/servlet/com.merx.npoint.servlets.

DocumentServlet?docid=DA9ACFE3C-F7C0-9998-6085-D9D84941499D.

87

[10] Texas Instruments Inc. Simpliciti application programming interface. Application Note, March

2009. http://tnt.etf.rs/~ms1sms/lab/SimpliciTI%20API.pdf.

[11] Texas Instruments Inc. Simpliciti compliant protocol stack. Website, August 2010. http:

//focus.ti.com/docs/toolsw/folders/print/simpliciti.html#description.

[12] J. M. Kahn, R. H. Katz, and K. S. J. Pister. Next century challenges: mobile networking

for “smart dust”. In MobiCom ’99: Proceedings of the 5th annual ACM/IEEE international

conference on Mobile computing and networking, pages 271–278, New York, NY, USA, 1999.

ACM.

[13] W T Keeton. Magnets interfere with pigeon homing. Proc Natl Acad Sci U S A, 68(1):102–6,

1971.

[14] ST Microelectronics. Tilt measurement using a low-g 3-axis accelerometer. Application Note,

April 2010. http://www.eu.st.com/stonline/products/literature/an/17289.pdf.

[15] Chris Otto, Aleksandar Milenkovic, Corey Sanders, and Emil Jovanov. System architecture

of a wireless body area sensor network for ubiquitous health monitoring. Journal of Mobile

Multimedia, 1(4):307–326, 2006.

[16] Adrian Sapio and Gill R. Tsouri. Low-power body sensor network for wireless ecg based

on relaying of creeping waves at 2.4ghz. Wearable and Implantable Body Sensor Networks,

International Workshop on, 0:167–173, 2010.

[17] Dennis Turner. Surgical treatment of movement disorders: Dbs, gene therapy, and beyond.

In Modern neurosurgery: clinical translation of neuroscience advances, pages 141–156. CRC

Press, 2005.

[18] V. K. Varadan, W. D. Suh, P. B. Xavier, K. A. Jose, and V. V. Varadan. Design and

development of a MEMS-IDT gyroscope. Smart Material Structures, 9:898–905, December

2000.

88