A Body Area Sensor Networked Human Motion …edge.rit.edu/content/P06210/public/csp1769 Graduate...
Transcript of A Body Area Sensor Networked Human Motion …edge.rit.edu/content/P06210/public/csp1769 Graduate...
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
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