Athlete Monitoring via Wireless Sensor on a Mobile Phone
Lilian K. S. Sunna
Master of Science in Engineering Technology Electrical Engineering
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
Athlete monitoring via wireless sensor on a mobile phone
Lilian K. S. Sunna
Lule˚a University of Technology
Department of Computer Science and Electrical Engineering
An internship done at Philips Applied Technologies, as the thesis required for the Degree of
Master of science
in Electrical Engineering.
Supervisor:
Dr. Jan van Deventer
October 26, 2010
ABSTRACT
The coach of a volleyball team needs to predict when to substitue players before they get too exhausted. This will maximize their efficiency, due to the shorter recovery time.
Fresher players would mean an advantage towards the opponents. By monitoring the height of the players’ jumps, their activity can be viewed.
The system consists of two parts: a wireless sensor device and a smart phone. The device is mounted at the front-side of the pelvic, next to the hip bone. The jumps are detected by analysing the acceleration perpendicular to the ground. Whenever the device successfully detects a jump, the measured height will be transmitted via Bluetooth to the smart phone used by the coach. The smart phone platform uses Windows Mobile 6 Professional.
A major part of this project was to design the wireless jump sensor device. The prototype consists of a development board with one microcontroller, an accelerometer, a Bluetooth module and a power supply which charges a Li-Ion battery and switches in the battery when it is not charging. Additional hardware was required for the power management.
An application was written for the smart phone to communicate with the wireless device and graphically present the incoming measured heights. The algorithm to detect jumps and their measured heights was supplied from another internship, but required to be im- plemented for the wireless sensor device.
Tests showed that the wireless device can successfully detect every jump and transmit the height to the smart phone. Analysis of the received heights showed that the resolution of the height measurement was less than 1 centimeter. Nevertheless, the system would be too expensive to create in large scale, if the algorithm is not changed to one which is based on pattern recognition. Otherwise each device requires measurement of its accelerometer offset and compensation of it in the code.
iii
PREFACE
This report was written as the thesis required for the Master of Science degree in Electrical Engineering. The number of applications using sensors has been increasing over the last few years, thus making the applications more aware of the surroundings. The goal of this project was to create a wireless device transmitting the height of a jump to a smart phone.
However, the idea was to easily adapt the system to other applications. I mainly chose this project to broaden my experience: to do every step of the development phase of a prototype, thus facing all the problems and obstacles which might occur.
As anyone doing a master thesis can confirm: the adventure of completing a larger project is a rocky road with its ups and downs. Nevertheless, the knowledge I have gained is invaluable and the glorious and divine feeling of seeing my own creation up and running makes all the long evenings worth it. First of all, I want to give my sincere gratitude to my supervisor Dr. Jan van Deventer for his support and guidance during these six months.
I would also like to thank my two supervisors at Philips Applied Technologies: Henk van Huijgen and Bastiaan de Groot. I would also like to thank all the interns at the various departments of Philips for an hilarious time. Last but definitely not least, I would like to thank my family and friends - both in The Netherlands and Sweden - for sticking with me even when the lack of caffeine made me grumpy. Your love and the laughter we share are invaluable and I would never trade it away for the world. You made this possible: from lending computers, making huge nightly campfires, keeping me down to earth by kicking my ass in the dojo, to giving me love when I needed it the most. I could not have done this without you.
Considering the application of this system, I find it appropriate to end this preface with some wise words by the late Ronnie James Dio:
Jump, Jump / Jump on the tiger / You can feel his heart but you know he’s mean Some light can never be seen - yeah!
Lule˚a August 2010, Lilian Sunna
v
CONTENTS
Chapter 1 – Introduction 3
1.1 Background . . . . 3
1.2 The Approach . . . . 4
1.3 Core Requirements . . . . 5
1.4 Objective and Constraints . . . . 6
Chapter 2 – Jump height detection 9 2.1 Chapter Introduction . . . . 9
2.2 Previous Work . . . . 9
2.3 Jump Force and Acceleration Analysis . . . . 9
2.4 The Implementation . . . . 10
2.5 Chapter Conclusion . . . . 15
Chapter 3 – Hardware design 17 3.1 Chapter Introduction . . . . 17
3.2 The Requirements . . . . 17
3.3 The Approach . . . . 17
3.4 The Chosen Components . . . . 18
3.5 Power Supply . . . . 23
3.6 Wireless Communication Method . . . . 25
3.7 Circuit Card Design . . . . 28
3.8 Chapter Conclusion . . . . 29
Chapter 4 – Software 31 4.1 Chapter Introduction . . . . 31
4.2 Transmitting End: Sensor Device . . . . 31
4.3 Receiving End: Smart Phone . . . . 33
4.4 Chapter Conclusion . . . . 36
Chapter 5 – Discussion 37 5.1 Evaluation . . . . 37
5.2 Problems and Obstacles . . . . 41
5.3 Further Improvements . . . . 41
5.4 Conclusions . . . . 42
A.2 Wireless device . . . . 45
Appendix B – Installation Guide 47 B.1 Active Sync . . . . 47
B.2 .NET Compact Framework 3.5 . . . . 47
B.3 iJump . . . . 48
Appendix C – User Guide 49 C.1 Using the iJump program . . . . 49
C.2 MyHeart Wellness Monitor program: MyHeart . . . . 50
Appendix D – Programming and Compilation 51 D.1 Jump sensor device . . . . 51
D.2 iJump . . . . 52
D.3 MyHeart . . . . 53
D.4 How to do changes . . . . 53
D.5 Common problems . . . . 54
Appendix E – Schematic 55 Appendix F – Component List 61 F.1 Transmitter: jump height detector . . . . 61
F.2 Receiver: smart phone . . . . 62
viii
List of Figures
1.1 The dimensions of a volleyball field [6]. . . . 6
2.1 The different stages of a jump: the acceleration and force versus time [7]. . 10
2.2 The flight-time as described in the report ”Standing jump loft time measure- ment” [7]. Lift-off is the negative peak acceleration quickly after a positive peak acceleration. . . . 11
2.3 The flight-time as described in the report ”Activity detection in professional sports” (see Section 2.2). Lift-off is the initial large positive peak acceleration. 12 2.4 The flight-time as implemented in the work from ”Activity detection in professional sports” (see Section 2.2). Lift-off is when the acceleration is less or equal to 0m/s2 after a positive peak acceleration. . . . 13
2.5 The flowchart for the algorithm to detect a jump and calculate its height. . 14
3.1 The general system architecture. . . . 18
3.2 The header board MSP430H1611 by Olimex [10]. . . . 21
3.3 The development board MSP430P1611 by Olimex [10]. . . . 22
3.4 The power supply architecture. . . . 24
4.1 The graphical user interface structure of Windows Mobile forms. . . . 35
5.1 The prototype board using the development board MSP430P1611 from Olimex. . . . 37
5.2 The received measured heights for the set of high jumps. . . . 38
5.3 The received measured heights for the set of low jumps. . . . 39
5.4 The received measured heights for the set of mixed jumps (high and low). . 40
D.1 The general structure of the C-code for the wireless jump height detection device. . . . 52
1
CHAPTER 1 Introduction
This thesis presents the development of a wireless sensor prototype to measure the jumps of volleyball-players in real-time. The report describes the hardware development as well as the software side, both for the sensor device but also the application running on the receiv- ing hand hold device - a smart phone running Windows Mobile 6 Professional. This thesis was conducted as an internship at Philips Applied Technologies [1] in The Netherlands.
1.1 Background
1.1.1 Company Profile
Philips Applied Technologies provides solutions of technical and business nature to every- thing from a small business to global companies. The solutions provided are from a wide range of disciplines such as software engineering, electrical engineering, molecular biology, human-technology interaction and mechatronics. Around one thousand specialists from the varying technical fields as well as business are employed at Philips Applied Technolo- gies in order to create complete solutions and offer support for every step of the innovation chain.
1.1.2 Use Case
The primary application of this system is to monitoring the activity of a volleyball player.
Volleyball is an exhausting sport due to the vast number of jumps of each player. As a result, the sport demands active and alert players. Knowledge about the amount of jumps each player has done is important for the coach, since it indicates the cumulative activity of the player. Substitue players before they wear out and become too tired will refrain the team members from exhaustion.
Each volleyball player in a team wears a wireless device. The device will detect a jump 3
from its sensor measurements and transmit it to a smart phone at the side of the field. The coach will use the smart phone to monitor the physical activity of the player. Naturally this device can be used for any type of sport activity where physical activity information based on jumps is crucial.
This device has to be wireless, since it is intended for sport activities. Wired devices can drain power through their connected cable and can also use it to transmit their data.
Two examples of this type of wired communication and power source are USB-connected keyboards and mice. However, having wired devices between active players in a field and their coach at the side of the field will significantly affect the physical activity negatively.
1.1.3 Current Solutions
Philips already had a wireless device used for similar purposes, known as the PI-node [2].
This node is not suitable for this application. First of all, its price is too expensive for this system. It uses Zigbee, which makes it power-efficient, but is not compatible with smart phones. The accelerometer also needs to be replaced.
Some smart phones today (for instance the iPhone) has an internal accelerometer. However the size and weight of a smart phone could influence the volleyball player negatively (see section 1.3.2). If every player in the field would have their activity monitored, it would be significantly more expensive to use one smart phone per player instead of one designated wireless device.
1.2 The Approach
The thesis was divided into three parts:
1. First programming part. Porting the MyHeart communication protocol [3] to a smart phone running Windows Mobile 6 Professional. This part also includes developing the smart phone application to process the incoming information and the graphi- cal user interface. This is a separate application depicting the incoming heartbeat measurements in real-time.
2. Hardware part. Evaluate the hardware requirements of the jump application and do the circuit design accordingly. Consideration of the total end manufacturing cost is required. This hardware-focused part also includes the manufacturing of the development circuit card.
3. Second programming part. Program the development circuit card to send data to the other end of communication, i.e. the Windows Mobile 6 Professional smart phone.
Also design and program the application running on the smart phone: it needs to process the incoming data from the jump sensor device and present it to the user via a graphical user interface.
1.3. Core Requirements 5
Now this might seem like an unconventional structure, considering that the first part does not belong to the thesis subject. The subjects are related: both part 1 and 2 in- volves the development of a Windows Mobile application and its graphical user interface.
Additionally, both programs receives data using short-range wireless transmissions. It was estimated beforehand that there would be a gain by this structure: the receiving end with its handling of incoming data and graphical user interface could be started almost instantly, since the transmitting MyHeart sensor device was already functional. Porting the existing implementation of the MyHeart communication protocol would also be a quicker start with the programming language C!. This also opened up for the option of reusing the wireless communication stack in the ported version of the MyHeart protocol, assuming the jump height sensor would use same type of wireless transmission.
1.3 Core Requirements
1.3.1 Jump Detection
If a player jumps straight up from the ground from being immobile, its acceleration will be orthogonal to the plane. Since only the height of the jump is of interest, it is sufficient to base the height detection on the acceleration orthogonal to the ground surface (see section 2.2). Thus, an accelerometer with at least one axis is required.
1.3.2 Position of Device
There are several reasons to position the device at the front-part of the pelvic next to the hip bone. First and most importantly, this will decrease the acceleration influence due to movements of other body parts. If the device is mounted on for instance an arm, the sensor would also detect acceleration from other movements such as waving. To isolate the acceleration due to a jump from these other movements would require a complex algorithm - if it is even possible. An arm can also rotate and be lifted, while the pelvic will during the jump be somewhat orthogonal to the surface. This implies that it is sufficient to only regard the acceleration vertically to the ground if the device is mounted on the pelvic, but would require more degrees of freedom if mounted on another part. Secondly, since the device is intended for extreme sports, it is important that it will not influence the user negatively: the front-side of the pelvic next to the hip bone is a fairly large and flat area, hence can easily carry a device. Additionally, the area is not as primarily used during activities as for instance an arm, thus its presence will affect the user to a lesser extent.
1.3.3 Wireless Communication Range
The size of a volleyball field is important for the wireless range, since volleyball is the primary use of this system. The size of the field is 18 m x 9 m, divided into two 9 m x 9
m such that the teams have one half field each. This area is surrounded by an additional area referred to as the free zone: a zone of minimum 3 m in width. The players may enter the free zone and play, but only after the service of the ball. This means that the total area which can be used during the play of a game is for each team at least 3 m + 9 m + 3 m = 15 m in width and 3m + 9 m + 3 m = 15 m in length [5].
Figure 1.1: The dimensions of a volleyball field [6].
The top height of the net differs between women and men: it is 2.24 meters for female teams and 2.43 meters for male teams respectively. These heights are varied for veterans and junior competitions.
1.4 Objective and Constraints
This report will discuss the hardware and software development of a jump height detection application. The whole chain of the hardware prototype will be concerned: starting from the physical requirements of the system, continuing to the choice of components, soldering of the prototype to evaluation. Due to lack of testing equipment and time limitations, the prototype testing will consist of sets of transmitted heights and their analysis.
Only the height orthogonal to the plane will be concerned in this application, the length
1.4. Objective and Constraints 7
of the jump parallel to the plane is ignored.
The jump height detection algorithm is based on analysis of one axis acceleration, thus it is of importance how the device is worn.
CHAPTER 2 Jump height detection
2.1 Chapter Introduction
This chapter describes the algorithm detecting jumps and calculating their heights in real- time. This thesis project is based on a previous internship, which supplied this threshold- based algorithm.
2.2 Previous Work
Previous work had been done at Philips Applied Technologies for jump height detection:
”Activity detection in professional sports” by Muhammad Rameez Khan. This algorithm analyses acceleration measurements perpendicular to the ground. Measurement data was collected from a wearable device also known as the PI-node. This PI-node has a digital accelerometer for movement measurement purposes. The sampling rate is 100 Hz with 12 bits resolution. The acceleration samples were stored on the PI-node and post-processed using a jump detection algorithm in MATLAB. However, this system demands real-time analysis of the acceleration, since it would be pointless to only monitor the activity of players after the game.
2.3 Jump Force and Acceleration Analysis
A jump can be detected from the acceleration perpendicular to the ground when the accel- eration sensor is worn at area next to the hip bone. Six relevant regions of the perpendicular acceleration-time graph can be detected for a jump [7]: rest, preparation, take-off, flight, landing and recovery. This is clearly shown in Figure 2.1.
9
Figure 2.1: The different stages of a jump: the acceleration and force versus time [7].
The acceleration will have two peaks during a jump: first peak is from the take-off and second is due to the landing. There can be fluctuations of the acceleration due to movements of arms and legs, but the magnitude of these peaks will not be as large as the acceleration due to take-off and landing. The acceleration at mid-jump will be zero: this is when the force of the body upwards equals the gravitational pull downwards just before the body starts moving downward.
The peak jump height can be calculated from h = (−g) · (2t)2
2 . (2.1)
Equation 2.1 given in the previous internship (see Section 2.2) depicts the relationship between the jump height in meters (h), the Earth’s gravitational force (g) and flight-time (t) in seconds. The flight-time is divided into two, since it is only the time from the peak of the jump to the landing which is required. From that point, the body will start falling down, only affected by the gravitational pull of the Earth. Since the jump ends at the same height as it starts, the time from start to peak height will be the same as from peak height to landing.
2.4 The Implementation
This system runs an algorithm to determine the height of each jump. The algorithm was based on a previous internship at Philips Applied Technologies, see Section 2.2. The previous work had a major flaw: the algorithm described in the report and the flowchart
2.4. The Implementation 11
did not match the references nor its implementation in MATLAB. The theory behind all algorithms was the same: the height is related to the flight-time and the flight-time is the time from lift-off to landing. All algorithms used the acceleration to detect the lift-off, flight and landing. The part which differed between them was how to detect the lift-off.
The report ”Standing Jump Loft Time Measurement” [7] describes three types of detecting the jump height. The type which was mentioned in the previous internship ”Activity Detection in Professional Sports” is seen in Figure 2.2. The lift-off is here detected as the largest negative peak acceleration quickly after a large positive peak.
Figure 2.2: The flight-time as described in the report ”Standing jump loft time measurement” [7].
Lift-off is the negative peak acceleration quickly after a positive peak acceleration.
It was concluded in the report ”Standing jump loft time measurement” [7] that of the three flight-time detection described, the one described in Figure 2.2 had best correlation between measured and real flight-time.
The previous internship refers to this report, but describes a different detection of lift- off. The flight-time is detected as the time between two peak accelerations, where the time is between 250 milliseconds and 850 milliseconds. Longer flight-time than the higher bound would trigger a time-out, to remove wrong-fully detected lift-off. The jump is also disregarded if the time is shorter than the lower bound; this is to separate jumps from running steps. The thresholds were set according to the analysis done in the previous internship.
Figure 2.3: The flight-time as described in the report ”Activity detection in professional sports”
(see Section 2.2). Lift-off is the initial large positive peak acceleration.
Unfortunately it was not as straightforward as merely implementing the algorithm from the previous internship (see Section 2.2). Implementing the algorithm was fairly simple and most jumps were successfully detected. A correlation could be seen between the actual jumps and their heights: a lower jump would get a lower measured height than a higher jump. However there was a significant problem: it was clear that the jumps were measured as higher than what would be reasonable. Unfortunately, there was no proper measuring equipment during the tests; the heights were simply measured by the device and then transmitted for analyse. It still gave an indication of how reasonable the measured heights were, since the height could be seen in real-time on the receiving end. Studying the actual MATLAB implementation, that difference of detecting the lift-off was clear. Khan’s implementation detects lift-off as the time when the acceleration drops to 0m/s2 after a positive peak acceleration above 20m/s2, which can be seen in Figure 2.4.
2.4. The Implementation 13
Figure 2.4: The flight-time as implemented in the work from ”Activity detection in professional sports” (see Section 2.2). Lift-off is when the acceleration is less or equal to 0m/s2 after a positive peak acceleration.
This inconsistency is mostly likely due to lack of time. It was a request from the super- visors at Philips Applied Technologies to implement the same algorithm as in the work by Rameez Khan. His report included an analysis of the algorithm to confirm it was working.
This analysis had to be have been done using the implemententation in MATLAB. Thus this system used the same lift-off detection as presented in Figure 2.4.
The previous implementation in MATLAB detects the start of a jump as follows:
• A peak above 20 m/s2 is detected. This marks the peak acceleration in take-off.
• The acceleration drops to zero. This should be the lift-off.
An additional change was added to the algorithm: a time-out of 250 milliseconds after the detected landing of a jump. This was to minimize the risk of detecting the decreasing acceleration after the landing peak as the beginning of a new jump. The threshold values are the same as determined in previous work. However it was required to measure the volt- age offset of the accelerometer and then compensate for it before evaluation, see Sections 3.4.3 and 5.3.
Figure 2.5 depicts the flowchart of the implemented algorithm to calculate the height of a
detected jump.
Figure 2.5: The flowchart for the algorithm to detect a jump and calculate its height.
It has to be noted that this implementation is strictly threshold-based. This is not a good solution for detection based on sensor data. Every sensor will have a different offset;
2.5. Chapter Conclusion 15
two different sensors might not measure the same value even though the environmental conditions are the same. To compensate for this, the offset of every sensor needs to be measured for callibration. A better way is to use another pattern recogintion method less dependent on actual values. Looking at the inclination rate of the acceleration.
2.5 Chapter Conclusion
A vertical jump from standing still can be detected by analysing the acceleration perpen- dicular to the ground. The implemented algorithm is based on threshold-values, triggering a time-counter. This is not a good solution: every accelerometer regardless if they are analog or digital will have an offset voltage. The resulting acceleration due to this off- set voltage needs to be measured and compensated in the code. An algorithm based on pattern recognition would have been a much better solution: analysing the behaviour of the acceleration during a jump would not be affected by an offset. However, it was a re- quirement from the supervisors at Philips Applied Technologies to use this threshold-based algorithm.
CHAPTER 3 Hardware design
3.1 Chapter Introduction
This chapter describes the hardware design of the wireless sensor device which is worn by the athlete. The requirements, choice of components and some circuit card design rules are also concerned.
3.2 The Requirements
The jump detection algorithm was implemented for data sampled at a frequency of 100 Hz.
When a jump has been detected, its calculated height will be transmitted to the receiving end of communication. The receiving end in this application system is a smart phone (see Section 4.3.2). The analysis of each sampled acceleration needs to be finished before the triggering of the next sample. Otherwise the unanalysed samples would risk piling up and there would be an increasingly larger end-to-end delay.
3.3 The Approach
The general design can be seen in Figure 3.1. Bluetooth is used as wireless communication method in this system, but this could also be for example Zigbee or WiFi (see Section 3.6).
By simplifying the interface to the sensor, the sensor can easily be replaced. Thus opening for the future possibility of reusing the core of the board (microcontroller, power supply and wireless communication hardware) for other purposes with only minor adjustments.
17
Figure 3.1: The general system architecture.
It is difficult to precisely determine the hardware requirements beforehand. Thus it is better to choose components which are slightly too good than discovering that the hardware is a bottleneck. When the prototype is finished and operational, it can be sized down and components can be chosen accordingly: i.e., the cheapest yet most power efficient components that would still suffice. Determining the price of components for a larger company could be tricky: bulk-ordering for several projects simultaneously will give large discounts.
3.4 The Chosen Components
3.4.1 Microcontroller
The microcontroller works like the brain of the sensor device. It is a small single integrated chip and contains a processor core, memory and some programmable input and output pins.
Microcontrollers are developed in a wide range for different purposes and at difference prices. The following list are the minimum core requirements of the microcontroller:
• An analog-to-digital converter to sample the battery voltage.
• An interface is required to communicate with the acceleration sensor. The jump detection algorithm requires sample rate of 100 Hz. Depending on the type of sensor, the interface requirements are different:
Analog One analog-to-digital converter per axis of freedom. Depending on ac- celerometer, some additional digital input and output pins are required. They
3.4. The Chosen Components 19
are necessary to control the accelerometer, for example choose which acceler- ation range should be used and put the sensor in sleep-mode for power man- agement purposes. Input pins could for instance be necessary for testing of the sensor.
Digital integrated circuit (IC) interface is standard for digital accelerometers. Two types are common: Inter-Integrated Circuit (I2C) and Serial Peripheral Interface (SPI). I2C uses two bi-directional open-drain lines. The addressing in the refer- ence design can support communication for up to 112 nodes on the same bus.
The nodes can act either as masters or slaves - I2C supports multi-master bus [14]. SPI supports higher bit-rates than I2C. SPI requires more hardware con- trol due to the combination of master-slave relationship and its lack of built-in hardware addressing. For a system like this with only one master (the micro- controller) and one slave (the accelerometer), the lack of hardware addressing is an advantage since it means less communication overhead [8].
It is primarily the sensor and secondarily the system application which determines which interface is better. Analog interfaces are easy to implement and often cheap, but offers low amount of information at a relatively large amount of wires and connec- tions and does not scale well into larger systems. Digital interfaces requires relatively more software for the communication, but can easily change sensor to one of the same type of interface or merely add several components without using additional pins at the microcontroller.
• Low power and easy to put in and out of sleep.
• Interface suitable for the wireless transmission unit.
The microcontroller which is standard at Philips Applied Technologies is the type MSP430 by Texas Instruments. The software stack for microcontrollers developed at Philips Ap- plied Technologies is created for the MSP430-series, thus a microcontroller of this type was chosen. Personally, if this software stack for the MSP430 was not available, a microcon- troller from Atmel would have been perferable: they are very well-documented and are available in a wide range.
The choice fell on the MSP430F1611. The processor is with its 8 MHz in the lower end in the range of MSP430s with regards to computational speed, but it should be enough considering the simple nature for the jump detection algorithm.
No additional external memory is necessary, the MSP430F1611 has 48KB + 256B flash memory and 10KB RAM internally. The algorithm implementation mainly depends on flags and counters, thus requires little memory. The stored amount of data is as follows (see Section 4.2.3):
• Five floats (handling decimal numbers) are necessary for averaging the acceleration:
5· 4 bytes = 20 bytes.
• 100 short integers (handling smaller integers) are required to store the acceleration samples: 100· 2 bytes = 200 bytes.
• 100 short integers (handling smaller integers) are required to store unsent detected heights: 100· 2 bytes = 200 bytes.
The sum of these three arrays are 20 bytes + 200 bytes + 200 bytes = 420 bytes.
By excluding the need of external memory, the cost of the hardware could be reduced since it required one less component. The external memory would not only make the jump sensor device more expensive, but it would also add to the circuit card size and require software to handle the memory interface. Excluding components also affects the reliability:
more components would mean more things that could break or cause other problems. The process of error-searching is simpler for smaller systems.
Because there was no budget to produce a PCB nor free capacity within the PCB design team, it was clear the prototype had to be hand-soldered. It is almost humanly impossible to hand-solder a microcontroller: the distance between its pins is too small. Each pin is 0.23 millimeter wide and they are positioned with 0.5 millimeter from the center of one pin to the center of the next. Hence, the distance between the pins is 0.27 millimeters. Even with a larger width between the pins, hand-soldering a microcontroller is cumbersome work, due to its sensitivity to electrostatic chock. The alternative method is to use a development or header board, where the microcontroller is already mounted. This was another reason for choosing the MSP430F1611: there are already development boards with this microcontroller available on the market. By having the same microcontroller model, the program code can be used without any alternations on a PCB prototype.
3.4.2 Development Board
As described in Section 3.4.1, the core requirement for the development board was that it had the same microcontroller as chosen. The best choice would have been to use a header board: the MSP430H1611 from Olimex, see Figure 3.2. This header board only contains a microcontroller mounted on a small PCB together with JTAG connector for program- ming and debugging, an external oscillator crystal, reset and extension headers for each microcontroller pin. The MSP430H1611 is also physically small: the PCB is merely 48 x 48 millimeters. The header board requires another prototype surface board to mount it on.
3.4. The Chosen Components 21
Figure 3.2: The header board MSP430H1611 by Olimex [10].
Although a MSP430H1611 header-board would have been preferable, the device was built using a full development board: the MSP430P1611, see Figure 3.3. It is significantly more expensive: 54D compared to 35D. The main disadvantage is the size: it is 100 x 80 millimeters. The full development board was used for two main reasons: first of all, it has its own prototype surface. Secondly and most importantly: one was laying around in the office, which made it possible to start as soon as possible.
Figure 3.3: The development board MSP430P1611 by Olimex [10].
3.4.3 Accelerometer
The accelerometer needed obviously to be in the range of acceleration generated by a human jump. When it is in rest it will measure 1G, due to the Earth’s gravity and it measures the vertical acceleration. The upper threshold of measured acceleration should not be significantly higher than what is generated by a jump - larger range means worse resolution. The accelerometer should be able to measure roughly 6G for detecting human jumps [9].
The MMA7361L is the accelerometer used for this implementation. It is an inexpensive analog accelerometer, thus an easier interface since it does not require any software for SPI or I2C. A digital accelerometer is standard at Philips Applied Technologies, but would never reach the desired production cost of 5 US dollars per unit due to its price of 13D.
Bulk ordering would give a significant reduction of the price, but it still cannot compare to the price of a MMA7361L - roughly 3-4D without any discount.
Nevertheless, two accelerometers will differ in offset even if they are of the same model.
Putting two accelerometers in 0G, might show two different measured accelerations. The MMA7361L that was used in the development board was measured when put in 0G (i.e.
accelerometer is position such that the Y-axis is parallel to the ground, since the algorithm will only be using this axis for its analysis). The sampling rate was 100 Hz and the measurement was done for around five minutes, which should add up to 30 000 samples.
The actual amount of samples was 30 082. The mean-acceleration value was 3.17 m/s2
3.5. Power Supply 23
with the standard deviation of 0.78 m/s2. The algorithm compensated for this mean-value offset before analysing the measured acceleration (see Section 2.4). The variance of 0.78 m/s2 is a bit high, but not significant for this application.
3.5 Power Supply
3.5.1 General
The general power supply architecture can be seen in Figure 3.4. The supplied power to the circuitry is the output of the voltage regulator, see Section 3.5.5. When the mini-USB connector supplies power, the voltage regulator will drain the current straight from it. A field-effect transistor (seen as ”FET” in Figure 3.4) functions as a switch: it connects the battery to the voltage regulator when the voltage from the mini-USB connector is low. The device is enabled to use even during charging by draining the power to the voltage regulator straight from the mini-USB connector. If the power always would have been drained from the battery, the user would have to wait until the battery was charged enough to use the device.
A battery charge management component (”Battery charger” in Figure 3.4) is used to charge the Li-Ion battery, see Section 3.5.4.
The microcontroller will detect when power is supplied through the mini-USB connector and can also measure the battery voltage.
3.5.2 Connector
Since the wireless device is intended to be used for sports, a requirement is that the physical size should be small. The choice of connector fell on mini-USB for several reasons. First of all, computers are extremely common nowadays. People are used to plugging in various devices to their computer for charging and data transfer: mobile phones and mp3-players are merely two examples.
The USB 2.0-port standard specify two power modes: low-power and high-power. The maximum current to power a device with the two modes are 100mA and 500mA respec- tively. All devices will by default use low-power mode, but this can be upgraded to high- power mode. Upgrading is done if the device software requests it and the USB power bus can supply it.
3.5.3 Battery Type
The chosen battery type is a Li-Ion for multiple reasons [11]:
• It has high energy density, hence can be made small.
Figure 3.4: The power supply architecture.
• It is rechargeable, but does not demand any periodic discharge thanks to the lack of memory.
• It has low self-discharge: nickel-based batteries have twice the amount.
Nevertheless, Li-Ion batteries are not without disadvantages.
• Protection against under-voltage is necessary to integrate in the design. If the battery is discharged below a certain level, there is a risk of damaging battery cells thus decreasing the capacity.
• Li-Ion batteries are also more expensive than nickel-cadmium.
A battery was never ordered for this project: one was supplied from another project at Philips Applied Technologies.
3.5.4 Battery Charge Management
The purpose of a battery charge management is to improve the charging time of the battery and also protection. The battery charge management used for this power supply is a MCP73812 from Microchip and is specifically designed for Li-Ion batteries. It provides specific algorithms to achieve optimal capacity as quickly as possible.
3.6. Wireless Communication Method 25
The MCP73812 is inexpensive, commonly used for USB-charging and its small physical size and low amount of required external components made it suitable for this application.
Only two external components are necessary: one decoupling capacitor and one resistor used to set low power or high power mode.
This battery charger management device will not start charging until the input voltage is at least 150mV higher than the battery voltage. Whenever the input supply is within +50mV of the battery voltage, the device is automatically put in shutdown mode by its power down circuitry. The Li-Ion batteries does not need protection against overcharging, since they do not have any memory. This is a protection against heat - overheating the battery can damage the battery cells [12].
3.5.5 Voltage Regulator
The voltage regulator is used to change the voltage from either the USB bus or the battery to a level which can be used for the circuitry. The recommended operational voltage levels for the significant components are as follows:
MSP430F1611 3.3V
MMA7361L 2.2V - 3.6V
cbOEMSPA310i-04 3.0V - 6.0V
Thus the desired output voltage from the voltage regulator is 3.3V, since it satisfies all components power needs.
The choice fell on MCP1603 by Microchip. It is inexpensive, small and suitable for both USB powered applications and portable equipment. To minimize unnecessary current draw from the battery at lighter loads, it will change operation mode to Pulse Frequency Modulation (PFM), where the numbers of switching cycles per second is reduced. Normal operation is done with Pulse Width Modulation (PWM): a low noise and low output ripple is achieved by using a switching rate of 2.0 MHz.
3.6 Wireless Communication Method
3.6.1 System Transmission Evaluation
A human being will not jump that often during volleyball: it is in the magnitude of seconds between the jumps as maximum. The transmitted data will only consist of the height and the additional overhead by the protocol stack. The height is originally of the data type short, which is a 16 bits unsigned integer, but converted to an array of characters, char s, before transmission. Only strings can be transmitted using the software stack. The C programming language does not support the data type string, but uses an array of chars instead. This array is one char longer than what is necessary to contain the data, due to the
necessary last symbol to mark the end of the array [13]. A char is one of the standard data types in C programming and is 1 byte long [15]. Adding this information together means that as maximum expected traffic only a few bytes of payload data will be transmitted every second.
3.6.2 Different Communication Methods
Three of the most common communication methods for short range wireless communication are Bluetooth, ZigBee and Wi-Fi. A comparison of these three types can be seen in Table 3.6.2 [21].
Wi-Fi is commonly used in smart phones today and it is estimated that 90% of all smart phones sold by 2014 will offer access to it [22]. However it is suitable for high-bandwidth applications, thus does not suit the requirements in Section 3.6.1: its complexity and high power consumption would be a waste in this system.
As described in Section 3.6.1, this system does not require a high bit-rate. The power consumption is more important: the lower consumption the longer up-time until next charging. Not demanding frequent recharging would also lead to simplified usage for the customer. The protocol overhead will be significant in an application like this, due to the low amount of payload. Smaller protocol stack requires less transmitted data, thus less power consumption. ZigBee has a much smaller protocol stack than Bluetooth [16], so if the issue was only low bit-rate and power consumption then ZigBee would clearly be a better choice. Choosing this type of communication module would demand the customer to use a regular laptop with a Zigbee module. If one is not built-in, then a Zigbee dongle is necessary. A requirement for the hardware was that the coach would be able to monitor the jump data through a smart phone - thus, Bluetooth is the better option even though it will consume more power.
Bluetooth Module
The Bluetooth radio is available in three classes [24]:
Class Approximate range Maximum power
Class 1 100 m 100 mW
Class 2 10 m 2.5 mW
Class 3 1 m 1 mW
The use case is for volleyball, thus the Bluetooth module should be able to handle the length of a volleyball field. Designing a Bluetooth module with the appropriate components which is also efficient regarding power consumption is tremendous work. At many companies and departments, it is common practice to use a Bluetooth module off the shelf for the development phase. This will significantly decrease the development time, but the cost for
3.6. Wireless Communication Method 27
Table 1: Comparison of different communication methods: Bluetooth, ZigBee and WiFi. [21]
Bluetooth Zigbee Wi-Fi
Range 10-100 m 10-100 m 50-100 m
Networking Topology
Ad-hoc,
small networks
Ad-hoc, peer-to-peer, star or mesh
Point to hub
Operating Frequency
2.4 GHz 868 MHz (Europe) 2.4 and 5 GHz
Complexity (Device and application impact)
High Low High
Power
consumption
Medium Very low High
Typical applications
Wireless connectivity between various personal devices such as laptops and smart phones
Toys, games,
industrial control and monitoring,
sensor networks
WLAN connectivity, broadband Internet access
the prototype will be higher. Bluetooth modules also contains a microcontroller to handle the Bluetooth stack, which is work that could easily be done by the regular microcontroller.
When the final product is finished, work can be spent designing a Bluetooth interface which is adapted for the product itself and more cost-efficient. There is another important aspect to choose a module instead of developing the hardware and software interface myself: a unit which transmits wireless cannot be used outside the laboraty until it has been CE- approved.
The chosen Bluetooth module is an OEMSPA310i-04 from connectBlue. This is a class 2 module, hence a range of the magnitude of 10 meters. connectBlue designed this module to for power efficiency yet longer range, hence this module has a range of 50 meters at the maximum power usage of +3dBm (2mW). The great advantage with this module
is its simple usability: from the host device’s view, it is merely a serial port interface.
No implementation at the host microcontroller to handle the Bluetooth protocol layers is necessary.
This module gets its power unregulated since it already contains a voltage regulator.
Power Management
In order to increase the power efficiency and thus prolong the uptime, following actions were implemented:
• A timer triggers the sampling of the battery voltage. An analog-to-digital converter is used to measure the battery voltage. Since the battery is 4.2V and the microcontroller can measure up to 3.3V, a voltage divider was used. The algorithm to calculate the voltage running on the microcontroller compensates for this.
• The Bluetooth module ground is controlled by an NMOS transistor. This way, the microcontroller can power down the module to save battery.
The power management is also done to protect the battery against under-voltage, due to the risk of permanently damaging the Li-Ion battery.
3.7 Circuit Card Design
The following design rules should be considered:
• The coupling distance between the accelerometer and the microcontroller needs to be minimal in order to achieve maximum measurement accuracy.
• A ground plane should be placed beneath the accelerometer for noise reduction.
• The coupling distance between the accelerometer axis output pins and their decou- pling capacitors need to be minimal.
• A LED on the DTR pin for the Bluetooth module indicates when the Bluetooth is active (fully lit) and when it is transmitting or receiving (blinking). This LED control would have otherwise been done by the microcontroller.
• Two PMOS to control the voltage for the two pins for the bi-coloured LED. The idea is to use this as an indication of the battery voltage level: green for full, orange for low and red for crucial. Each pin controls the gate of one PMOS, the LED will drain power from the 3.3V power supply when turned on. The output current of a microcontroller pin would be too low to power a LED.
3.8. Chapter Conclusion 29
3.8 Chapter Conclusion
A prototype for the sensor device worn by the athlete was made using following key com- ponents:
• The development board MSP430P1611.
• The accelerometer MMA7361L.
• The Bluetooth module cb-OEMSPA310i-04.
• Power-supply: charging Li-Ion battery through mini-USB, consists mainly of:
– The battery charger component MCP73812T.
– The voltage regulator MCP1603.
– The Schottky diode BAT760.
Additional light emitting diodes are added to give the user feedback regarding:
• Whenever the Bluetooth is active (fully lit) and transmitting/receiving (flickering).
• Indicate how long it is left until the battery needs charging.
For full component list and the article number see Appendix F.
CHAPTER 4 Software
4.1 Chapter Introduction
This chapter describes the software of the application system. Both the software on the wireless device worn by the athlete and the receiving end application is concerned.
4.2 Transmitting End: Sensor Device
4.2.1 General Programming Approach
The programming for the jump sensor device was done in C, which is commonly used to program microcontrollers. The programming environment was IAR Embedded Workbench IDE, which supports debugging when using the JTAG.
The sampling of the battery voltage and the accelerometer data is triggered by events at a certain interval. The alternative would be to constantly measure the voltage and the data and then at certain moments transmit it to the smart phone. This alternative method would unnecessarily waste power, since it requires the microcontroller to be constantly active analysing its input. By only using event-triggered analysis of the input, the power consumption will be reduced.
If an event for measuring the battery voltage is fired: calculate the battery voltage from the measured analogue input and transmit it to the smart phone. When the event for the measured acceleration is fired, the measured voltage sample will be stored in a circular buffer (see Section 4.2.3). After the event handler has finished this, the analysis will be taken care of in the main thread. The reason for this is to minimize the work done in the event handler such that if another event triggers shortly after, the first event handling will already be finished.
The sensor device uses a software stack (see Section 4.2.2), which includes UART-interface.
This is used for the transmitting end for the Bluetooth transmission.
31
4.2.2 Software Stack
Philips Applied Technologies has a recently developed software stack for the MSP430 writ- ten in C - this project was the first one in Europe to use it. The great advantage of the stack is that it contains all of the initial configurations necessary to boot up the micro- controller plus also the UART-interface. To write the necessary interface would otherwise have required significantly longer time. Although the documentation is fairly poor - most of the functions have some sort of vague documentation. The best option is to merely guess the name or a keyword and then search the files for it.
It was easier to merely write the pin-initialization for the microcontroller than to track down how it was done in the software stack. The initialization will set the direction of the required input and output-pins and also their initial values.
4.2.3 Storing Data
Two circular buffers are used to store height and acceleration data: one of 100 short int to store the incoming acceleration sample, the other of 100 short int for detected heights not yet transmitted. Circular buffers are required if the event handler is not able to analyse an incoming acceleration sample before the triggering of next sample. Otherwise there is a risk or eventually running out of memory, as the accumulated unanalysed samples and detected heights increase beyond control.
Similarly, the past five measured accelerations are stored as floats in a circular buffer. The analysed acceleration values are averaged over this buffer, in order to cope with smaller fluctuations.
4.2.4 Hardware Control: Powering Down
The microcontroller will trigger sampling of the battery voltage every second. Whenever the voltage is below a threshold value, the microcontroller will cut off the power to the Bluetooth module, put the accelerometer in sleep and put itself in low power mode 0. This mode does not affect the timers, hence the microcontroller will be awakened next time the timer will fire an event.
The battery voltage is calculated as:
voltagemeasured= sample× voltagesupply× 2 samplemax
(4.1) The reason for doubling the measured battery voltage is due to the voltage divider in the circuit design. The internal analog-to-digital converter in the microcontroller can only measure up to 3.3V. The lithium-ion battery can maximum be charged to 4.2V, thus there is a need of this voltage division in the hardware. Another benefit of the voltage division is the current reduction at the input pin: this adds as static discharge protection for the microcontroller [17].
4.3. Receiving End: Smart Phone 33
There is no reason to power down everything when the device is plugged in for charging.
The battery voltage will only be measured whenever no power is detected from the mini- USB port. The voltage level supplied from mini-USB is 5V, which could damage the microcontroller due to it operating voltage of 3.3V. A zero is detected if the microcontroller input pin has a voltage below a certain threshold. Above the threshold, a one is detected.
This USB input voltage is only a detection: either the mini-USB supplies the incoming power or it does not. Thus a regular input pin suffice and a analog-to-digital converter is not required.
4.3 Receiving End: Smart Phone
4.3.1 General Approach
The smart phone uses Windows Mobile 6 Professional (see Section 4.3.2 for platform in- formation). The programming environment is Visual Studio 2008 together with the .NET Compact Framework 3.5 and the language is C!. A software stack was used at the receiving end, just like at the jump sensor device. However, this software stack named MyHeart is different: it handles the Bluetooth communication. The MyHeart code could not be used straight away - it needed to be ported to the platform (see Section 4.3.3).
The smart phone presents all information to the coach plus having all the control. Thus the receiving end requires a graphical user interface. A description of its implementation can be read in Section 4.3.4.
4.3.2 Platform
The mobile phone used in this project is an HTC HD2, which runs Microsoft Windows Mobile 6. There are several options when it comes to smart phones. The four most used smart phone platforms and their market shares are in falling order: Symbian, Android, Windows Mobile, iPhone. It is desired to write platform independent code - that way the code can be executed on any type of device. However, because of the differences between the platforms, there is no such way to write completely platform independent code.
Windows Mobile might not be the best option if the idea is to have it platform indepen- dent. Windows Mobile is only 8.7% of the market [18]. There are other options, such as Symbian or Android. Android was created by the Open Handset Alliance (consisting of 64 companies, such as Google, HTC, Intel and Motorola). The Android would be the better option from a programming point of view, since then it would be done with regular Java and some extra libraries. Symbian has on the other hand 46.9% of the market shares for smart phones [18], but varies a lot from manufacturers and models. The native language of Symbian is C++, but supports Java ME as well. Considering which companies the Open Handset Alliance consists of, there might be a future switch to Android for other phone
