FINAL DESIGN REPORT
ENGR 339/340 Senior Design Project
Calvin College
2014-2015
Submitted By:
Carl Cooper, Brad Kunz, Jessica Snyder, Nick VanDam
For Review By:
Calvin College Engineering Department
Attn: Professor Mark Michmerhuizen
© Carl Cooper, Brad Kunz, Jessica Snyder, Nick VanDam, and Calvin College
1
Executive Summary
As technology spreads into markets that were once unexplored, advantages of new processes and
information available can arise as a result. With many individuals becoming increasingly interested in
tracking their personal fitness levels throughout the day, technology has recently advanced enough in
order to make this available and efficient to do so. With many personal fitness tracking devices already
on the market, our senior design team, BioBit, has identified a unique need in this market that has yet to
be successfully fulfilled, namely the area of group fitness. With teams and workout groups unable to track
data both individually as well as in a cohesive group, information is difficult to compare and analyze
between multiple individuals. BioBit sees a need for a team-oriented fitness tracking system that can be
used to easily track and display information for active groups, such as sports teams and training groups.
A team of four electrical and computer engineering students from Calvin College decided to solve this
problem by designing a wearable tracking device that sends real-time data to an Android app, where the
user can see the entire team’s fitness information. This fitness tracking system is designed for coaches,
trainers, athletes, and sports teams. Each athlete will wear a fitness-tracking device, which collects data
from biometric sensors. These sensors include the ability to track a user's heart rate, acceleration, and
steps taken. The data taken from these sensors is then sent to a centralized hub, which sits on the sideline
and communicates with all the devices in the network over Wi-Fi. Once the information is received by the
hub, it is published to a web-hosted server and database to be stored and later referenced by the
partnering Android app. The intent of the partnering Android app is to provide the fitness leader, such as
a coach or trainer, a user-friendly interface in order to compare and analyze the data obtained. With this
information in hand, a unique advantage is then available to the users in order to make educated and
timely assessments based on the real-time data received through the technology.
BioBit is requesting $430,000 as startup capital. It will be used for both additional design of prototypes
and the first production models that will be sold. This capital will also support the salaries of the designers,
workers, facilities, marketing, and raw materials. Through growth and additional production, BioBit plans
to be debt free by its third year, giving the company greater flexibility and cash flow to continue into the
future. The goal of the core group of designers is to have a production-ready prototype by May of 2015.
2
Contents
1.
Introduction ........................................................................................................................................ 11
1.1
Calvin College Engineering Program ........................................................................................... 11
1.2
Team Information ....................................................................................................................... 11
1.2.1 Carl Cooper ............................................................................................................................. 11
1.2.2 Brad Kunz ............................................................................................................................... 12
1.2.3 Jessica Snyder ......................................................................................................................... 12
1.2.4 Nick VanDam .......................................................................................................................... 12
1.3
Report Overview ......................................................................................................................... 13
1.4
Design Norms .............................................................................................................................. 14
1.4.1 Trust ....................................................................................................................................... 14
1.4.2 Integrity .................................................................................................................................. 14
1.4.3 Caring ..................................................................................................................................... 14
1.4.4 Stewardship ............................................................................................................................ 14
2. Project Overview ................................................................................................................................. 15
2.1
Project Statement ....................................................................................................................... 15
2.1.1 Problem Identification............................................................................................................ 15
2.1.2 Proposed Solution .................................................................................................................. 15
2.2
Requirements .............................................................................................................................. 16
2.2.1 Functional Requirements ....................................................................................................... 16
2.2.2 Electrical Requirements ......................................................................................................... 16
2.2.3 Software Requirements ......................................................................................................... 16
2.2.4 Communication Requirements .............................................................................................. 17
2.2.5 Physical Requirements ........................................................................................................... 17
3. System Design ..................................................................................................................................... 17
3.1
System Communication .............................................................................................................. 18
3.1.1 Possible Solutions ................................................................................................................... 18
3.1.1.1
Wi-Fi ............................................................................................................................ 18
3.1.1.2
Bluetooth .................................................................................................................... 18
3.1.1.3
ZigBee.......................................................................................................................... 18
3.1.2 Decision Criterion ................................................................................................................... 19
3.1.2.1
Range .......................................................................................................................... 19
3.1.2.2
Power Consumption ................................................................................................... 19
3.1.2.3
Central Hub ................................................................................................................. 19
3.1.2.4
Bit rate ........................................................................................................................ 19
3.1.2.5
Network Size ............................................................................................................... 19
3.1.3 Decision Matrix ...................................................................................................................... 19
3.1.3.1
Best Solution ............................................................................................................... 20
3.1.3.2
Recognized Weaknesses ............................................................................................. 21
3.2 Overall System Block Diagram ...................................................................................................... 21
4. Fitness Tracking Device ....................................................................................................................... 21
4.1
Wearable Location ...................................................................................................................... 22
4.1.1 Possible Solutions ................................................................................................................... 22
4.1.1.1
Wrist ........................................................................................................................... 22
4.1.1.2
Chest ........................................................................................................................... 22
4.1.1.3
Head ........................................................................................................................... 22
4.1.1.4
Waist........................................................................................................................... 22
3
4.1.2 Decision Criterion ................................................................................................................... 22
4.1.2.1
Sensor Capability ........................................................................................................ 22
4.1.2.2
End-User Desirability .................................................................................................. 23
4.1.2.3
Size Restrictions.......................................................................................................... 23
4.1.2.4
Unobtrusiveness ......................................................................................................... 23
4.1.2.5
Weight ........................................................................................................................ 23
4.1.2.6
Materials Cost ............................................................................................................ 23
4.1.3 Decision Matrix ...................................................................................................................... 23
4.1.3.1
Best Solution .............................................................................................................. 24
4.1.3.2
Recognized Weaknesses ............................................................................................ 24
4.2 Fitness Tracking Device Architecture ........................................................................................... 24
4.3
Hardware..................................................................................................................................... 26
4.3.1 Processing Board .................................................................................................................... 26
4.3.1.1
Requirements ............................................................................................................. 26
4.3.1.2
Alternatives ................................................................................................................ 26
4.3.1.3
Decision Criteria ......................................................................................................... 27
4.3.1.4
Decision ...................................................................................................................... 27
4.3.1.5
Implementation .......................................................................................................... 28
4.3.2 Wi-Fi Module .......................................................................................................................... 28
4.3.2.1
Requirements ............................................................................................................. 28
4.3.2.2
Alternatives ................................................................................................................ 28
4.3.2.3
Decision Criteria ......................................................................................................... 30
4.3.2.4
Decision ...................................................................................................................... 30
4.3.2.5
Implementation .......................................................................................................... 30
4.3.3 Heart Rate Sensor................................................................................................................... 30
4.3.3.1
Requirements ............................................................................................................. 30
4.3.3.2
Alternatives ................................................................................................................ 30
4.3.3.3
Decision Criteria ......................................................................................................... 32
4.3.3.4
Decision ...................................................................................................................... 32
4.3.3.5
Implementation .......................................................................................................... 32
4.3.4 Step Sensor............................................................................................................................. 32
4.3.4.1
Requirements ............................................................................................................. 32
4.3.4.2
Alternatives ................................................................................................................ 33
4.3.4.3
Decision Criteria ......................................................................................................... 34
4.3.4.4
Decision ...................................................................................................................... 34
4.3.4.5
Implementation .......................................................................................................... 34
4.3.5 Battery .................................................................................................................................... 34
4.4.5.1
Requirements ............................................................................................................. 34
4.4.5.2
Alternatives and Decision Criteria .............................................................................. 34
4.4.5.3
Decision ...................................................................................................................... 35
4.4.5.4
Implementation .......................................................................................................... 35
4.4.6 Battery Charging Circuit ......................................................................................................... 36
4.4.6.1
Requirements ............................................................................................................. 36
4.4.6.2
Alternatives ................................................................................................................ 36
4.4.6.3
Decision Criteria ......................................................................................................... 37
4.4.6.4
Decision ...................................................................................................................... 37
4.4.6.5
Implementation .......................................................................................................... 37
4.5
Software ...................................................................................................................................... 37
4
4.5.1 Processing Board .................................................................................................................... 37
Central Hub ......................................................................................................................................... 37
5.1
Central Hub Architecture ............................................................................................................ 37
5.2
Hardware..................................................................................................................................... 38
5.2.1 Requirements ......................................................................................................................... 38
5.2.2 Alternatives ............................................................................................................................ 38
5.2.2.1
Raspberry Pi B+........................................................................................................... 38
5.2.2.2
BeagleBone Black ....................................................................................................... 39
5.2.3 Decision Criteria ..................................................................................................................... 39
5.2.4 Decision .................................................................................................................................. 40
5.2.5 Implementation...................................................................................................................... 40
5.3
Software ...................................................................................................................................... 40
5.3.1 Server ..................................................................................................................................... 40
5.3.2 Data Transmission Protocol ................................................................................................... 41
5.3.3 Packet Processing ................................................................................................................... 41
6.
End-User Application ......................................................................................................................... 41
6.1
End-User Application Platform ................................................................................................... 41
6.1.1 Possible Solutions ................................................................................................................... 41
6.1.1.1
Apple’s iOS .................................................................................................................. 41
6.1.1.2
Android ....................................................................................................................... 42
6.1.2 Decision Criteria ..................................................................................................................... 42
6.1.2.1
Usability ...................................................................................................................... 42
6.1.2.2
Implementation .......................................................................................................... 42
6.1.2.3
Customization ............................................................................................................. 42
6.1.2.4
User Interface ............................................................................................................. 42
6.1.2.5
Cost to Enter Market .................................................................................................. 42
6.1.2.6
Ease of Market Entry .................................................................................................. 43
6.1.3 Decision Matrix ...................................................................................................................... 43
6.1.3.1
Best Solution ............................................................................................................... 43
6.1.3.2
Recognized Weaknesses ............................................................................................. 43
6.2
Software Design .......................................................................................................................... 43
6.2.1 Overview ................................................................................................................................ 44
6.2.2 Functionality ........................................................................................................................... 44
6.2.3 Inputs...................................................................................................................................... 44
6.2.4 Outputs................................................................................................................................... 44
6.2.5 Software Updates ................................................................................................................... 44
7. Physical Design Specifications ............................................................................................................ 44
7.1
System Enclosure ........................................................................................................................ 44
7.1.1 Wearable Design .................................................................................................................... 45
7.1.1.1
Product Weight ........................................................................................................... 45
7.1.1.2
Physical Specifications ................................................................................................ 45
7.1.1.3
Wrist Mounted Device ............................................................................................... 45
7.1.2 Material Selection .................................................................................................................. 45
7.1.2.1 Resulting Prototype Housing .............................................................................................. 45
7.1.2.2 Potential Refined Housing .................................................................................................. 47
8. Prototype and Deliverables ................................................................................................................ 49
8.1
Final Prototype ............................................................................................................................ 49
8.2
Deliverables ................................................................................................................................ 49
5.
5
8.2.1 Fall Semester Deliverables ..................................................................................................... 50
8.2.2 Spring Semester Deliverables................................................................................................. 50
9. Testing ................................................................................................................................................ 51
9.1
Feasibility Testing ........................................................................................................................ 51
9.1.1 Raspberry Pi............................................................................................................................ 51
9.2
Prototype Testing ........................................................................................................................ 51
9.2.1 WLAN on the Raspberry Pi ..................................................................................................... 51
9.2.1.1
Setup .......................................................................................................................... 51
9.2.1.2
Results ........................................................................................................................ 52
9.2.1.3
Analysis ....................................................................................................................... 52
9.2.2 Send Data from Pulse Sensor to Arduino Pro Mini ................................................................ 52
9.2.2.1
Setup .......................................................................................................................... 52
9.2.2.2
Results ........................................................................................................................ 52
9.2.2.3
Analysis ....................................................................................................................... 53
9.2.3 Data Accuracy of Pedometer ................................................................................................. 53
9.2.3.1
Setup .......................................................................................................................... 53
9.2.3.2
Results ........................................................................................................................ 54
9.2.3.3
Analysis ....................................................................................................................... 54
9.2.4 Send Data from Database to Mobile App .............................................................................. 54
9.2.4.1
Setup .......................................................................................................................... 54
9.2.4.2
Results ........................................................................................................................ 54
9.2.4.3
Analysis ....................................................................................................................... 54
9.2.5 Fitness Device Power Consumption Test ............................................................................... 55
9.2.5.1
Setup .......................................................................................................................... 55
9.2.5.2
Results ........................................................................................................................ 55
9.2.5.3
Analysis ....................................................................................................................... 56
9.2.6 Battery Test for Fitness Devices ............................................................................................. 56
9.2.6.1
Setup .......................................................................................................................... 56
9.2.6.2
Results ........................................................................................................................ 56
9.2.6.3
Analysis ....................................................................................................................... 57
9.2.7 Server Traffic Test .................................................................................................................. 57
9.2.7.1
Setup .......................................................................................................................... 57
9.2.7.2
Results ........................................................................................................................ 57
9.2.7.3
Analysis ....................................................................................................................... 57
9.2.8 Wi-Fi Range Test ..................................................................................................................... 57
9.2.8.1
Setup .......................................................................................................................... 57
9.2.8.2
Results ........................................................................................................................ 58
9.2.8.3
Analysis ....................................................................................................................... 58
10. Business Plan ..................................................................................................................................... 59
10.1 Vision and Mission Statement .................................................................................................... 59
10.1.1 Entrepreneur's Vision and Mission Statement for the Company ............................................ 59
10.1.2 Values and principles on which the business stands ............................................................... 59
10.2 Industry Profile and Overview .................................................................................................... 59
10.2.1 Industry Background and Overview ..................................................................................... 59
10.2.2 Major Customer Groups ....................................................................................................... 59
10.2.2.1
Trainers and Coaches ................................................................................................ 59
10.2.2.2
Academic Research ................................................................................................... 60
10.3 Regulatory restrictions ................................................................................................................ 60
6
10.4 Significant Trends ........................................................................................................................ 60
10.4.1 Growth Rate ......................................................................................................................... 60
10.4.2 Barriers to Entry and Exit ..................................................................................................... 60
10.4.3 Key Factors for Success in the Industry ................................................................................ 61
10.4.4 Outlook for the Future ......................................................................................................... 61
10.5 Business Strategy ........................................................................................................................ 61
10.5.1 Desired Image and Position in Market ................................................................................. 61
10.5.2 Company Goals and Objectives ............................................................................................ 61
10.5.2.1
Operational ............................................................................................................... 61
10.5.2.2
Financial .................................................................................................................... 61
10.6 SWOT Analysis............................................................................................................................. 62
10.6.1 Internal Strengths................................................................................................................. 62
10.6.2 Internal Weaknesses ............................................................................................................ 62
10.6.3 External Opportunities ......................................................................................................... 62
10.6.4 External Threats ................................................................................................................... 62
10.7 Competitive Strategy .................................................................................................................. 63
10.7.1 Cost Leadership and Differentiation .................................................................................... 63
10.7.2 Focus .................................................................................................................................... 63
10.8 Company Products and Services ................................................................................................. 63
10.8.1 Product Description and Service Features ....................................................................... 63
10.8.2 Uniqueness ........................................................................................................................... 63
10.8.3 Customer Benefits ................................................................................................................ 64
10.8.4 Warranties and Guarantees ................................................................................................. 64
10.8.5
Future Product or Service Offerings................................................................................... 64
10.9 Marketing Strategy ..................................................................................................................... 64
10.9.1 Target Market....................................................................................................................... 64
10.9.1.1
Problem to be Solved and Benefits to be Offered .................................................... 64
10.9.1.2
Demographic Profile ................................................................................................. 64
10.9.1.3
Other Significant Customer Characteristics .............................................................. 65
10.9.1.4
Customers' Motivation to Buy .................................................................................. 65
10.9.2 Market Size and Tends ......................................................................................................... 65
10.9.2.1
Market Size ............................................................................................................... 65
10.9.2.2
Rate of Growth.......................................................................................................... 65
10.9.3 Advertising and Promotion .................................................................................................. 65
10.9.3.1
Message .................................................................................................................... 65
10.9.3.2
Media ........................................................................................................................ 66
10.9.3.3
Budget ....................................................................................................................... 66
10.9.3.4
Plans for Generating Publicity .................................................................................. 66
10.9.4 Pricing ................................................................................................................................... 66
10.9.4.1
Desired image in market ........................................................................................... 66
10.9.4.2
Discount policy.......................................................................................................... 66
10.10
Competitive Analysis ............................................................................................................... 67
10.10.1 Existing competitors ........................................................................................................... 67
10.10.1.1
Polar ........................................................................................................................ 67
10.10.1.2
LUMOlift.................................................................................................................. 67
10.10.1.3
Mayfonk .................................................................................................................. 67
10.10.2 Potential competitors ........................................................................................................ 67
10.10.2.1
FitBit ........................................................................................................................ 67
7
10.10.2.2
Nike ......................................................................................................................... 67
10.10.2.3
Samsung .................................................................................................................. 68
10.11
Description of Management Team ......................................................................................... 68
10.11.1 Key managers ..................................................................................................................... 68
10.11.1.1
President: Nick VanDam ......................................................................................... 68
10.11.1.2
VP of Engineering: Brad Kunz ................................................................................. 68
10.11.1.3
VP of Software and Product Testing: Carl Cooper .................................................. 68
10.11.1.4
VP of Research, Development, and Project Manager: Jessica Par ......................... 69
10.11.2 Future Additions to Management Team ............................................................................ 69
10.11.2.1
VP of Finance .......................................................................................................... 69
10.11.2.2
VP of Marketing ...................................................................................................... 69
10.11.2.3
VP of Sales ............................................................................................................... 69
10.11.2.4
Head of Facilities and Production Manager ........................................................... 69
10.11.3 Operation ........................................................................................................................... 70
10.11.3.1
Legal form of Ownership Chosen and Rationale .................................................... 70
10.11.3.2
Company Structure (organization chart) ................................................................ 70
10.11.3.3
Decision making authority ...................................................................................... 71
10.12 Financial Statements ..................................................................................................................... 71
10.12.1 Income Statement (Annual, 3 years) ..................................................................................... 71
10.12.2 Cash Flow Statement (Quarterly, 3 years) ............................................................................. 71
10.13 Break-Even Analysis ...................................................................................................................... 72
10.14 Ratio Analysis ................................................................................................................................ 73
11. Project Management ........................................................................................................................ 74
11.1 Team Organization ...................................................................................................................... 74
11.1.1 Documentation Organization ............................................................................................... 74
11.1.2 Division of Work ................................................................................................................... 74
11.1.3 Time Allocation..................................................................................................................... 75
11.1.3.1 Carl Cooper .................................................................................................................... 75
11.1.3.2 Nick VanDam ................................................................................................................. 75
11.1.3.3 Brad Kunz....................................................................................................................... 75
11.1.3.4 Jessica Snyder ................................................................................................................ 75
11.1.4 Milestones ............................................................................................................................ 75
11.2 Schedule ...................................................................................................................................... 76
11.2.1 Schedule Management ........................................................................................................ 76
11.2.2 Critical Path .......................................................................................................................... 76
11.3 Operational Budget ..................................................................................................................... 76
11.4 Method of Approach ................................................................................................................... 77
11.4.1 Design Methodology ............................................................................................................ 77
11.4.2 Research Techniques ............................................................................................................ 77
11.4.3 Team communication........................................................................................................... 77
12. Closing Remarks ............................................................................................................................... 77
12.1 Project Results................................................................................................................................. 77
12.2 Lessons Learned ......................................................................................................................... 78
12.3 Credits and Acknowledgements ................................................................................................. 78
13. References ........................................................................................................................................ 80
8
Table of Figures
Figure 1 – Team Photo (left to right) - Brad Kunz, Nick VanDam, Carl Cooper, Jessica Snyder ............... 11
Figure 2 – High-level System Diagram ....................................................................................................... 15
Figure 3 – Diagram of Range for Wi-Fi and Bluetooth Over Standard Soccer Field Dimensions............. 20
Figure 4 – Level One Block Diagram of the Overall System ...................................................................... 21
Figure 5 – Detailed Block Diagram of Fitness Device ................................................................................ 25
Figure 6 – Wiring Diagram for Fitness Device ........................................................................................... 25
Figure 7 – Intel Edison Size Comparison .................................................................................................... 26
Figure 8 – Arduino Pro Mini Size Comparison ........................................................................................... 27
Figure 9 – Adafruit FLORA Size Comparison .............................................................................................. 27
Figure 10 – Size Comparison for SparkFun Wi-Fi Breakout....................................................................... 29
Figure 11 – Size Comparison of RN-XV WiFly Module .............................................................................. 29
Figure 12 – Size Comparison for the ESP-8266 .......................................................................................... 29
Figure 13 – Polar Heart Rate Sensor .......................................................................................................... 31
Figure 14 – TI TIDA-00011 Sensor .............................................................................................................. 31
Figure 15 – Pulse Sensor SEN-11574 .......................................................................................................... 32
Figure 16 – SparkFun Triple Axis Accelerometer - ADXL335 ..................................................................... 33
Figure 17 – STP156 Pedometer .................................................................................................................. 33
Figure 18 – MPU-6050 Accelerometer/Gyroscope GY521 Breakout Board ............................................. 34
Figure 19 – Adafruit Micro LiPo USB Charger Size Comparison ................................................................ 36
Figure 20 – SparkFun LiPo Charger Basic Size Comparison ....................................................................... 36
Figure 21 – Server and Database File Relation Diagram ........................................................................... 38
Figure 22 – Raspberry Pi B+........................................................................................................................ 39
Figure 23 – BeagleBone Black .................................................................................................................... 39
Figure 24 – Front View of Wrist-Mounted Housing .................................................................................. 46
Figure 25 – Top View of Wrist-Mounted Housing ..................................................................................... 46
Figure 26 – Side View of Wrist-Mounted Housing .................................................................................... 46
Figure 27 – Trimetric View of Wrist-Mounted Housing ............................................................................ 47
Figure 28 – Potential Wrist-Mounted Concept View of Face ................................................................... 47
Figure 29 – Potential Wrist-Mounted Concept Right Side View ............................................................... 48
Figure 30 – Potential Wrist-Mounted Concept Side View of Wrist Strap ................................................ 48
Figure 31 – Potential Wrist-Mounted Wearable Concept Wire View ...................................................... 49
Figure 32 – Screenshot of Processing Program to Test Pulse Sensor ....................................................... 53
Figure 33 – Current Consumption Results ................................................................................................. 55
Figure 34 – Test Started 10:55:17 PM ........................................................................................................ 56
Figure 35 – Test Terminated 10:31:19 AM ................................................................................................ 56
Figure 36 – Range Test Results................................................................................................................... 58
Figure 37 – Overview of Company Structure (dotted line to show initial organization) ......................... 70
9
Table of Tables
Table 1 – Decision Matrix for Communication Protocol ........................................................................... 20
Table 2 – Decision Matrix for Device Placement....................................................................................... 24
Table 3 – Battery Type Comparison ........................................................................................................... 35
Table 4 – Decision Matrix for Central Hub ................................................................................................ 40
Table 5 – Decision Matrix for Device Placement....................................................................................... 43
Table 6 – Project Deliverables and Timeline ............................................................................................. 50
Table 7 – Income Statement for First Three Years .................................................................................... 71
Table 8 – Cash Flow for First Three Years (Yearly Overview) ................................................................... 72
Table 9 – Cash Flow for First Three Years (Quarterly) .............................................................................. 72
Table 10 – Break-Even Analysis ................................................................................................................. 73
Table 11 – Ratio Analysis ........................................................................................................................... 74
10
1.
Introduction
This section will provide an introduction to the Senior Design Project by introducing the Calvin College
Engineering Program, giving details of the Senior Design team, breaking down the Project Proposal and
Feasibility Study document, and giving an overview of the team's design norms they are incorporating into
the project.
1.1
Calvin College Engineering Program
The Calvin College Engineering Program uses everything the students are taught over their college career
and accumulates it into one final design project. This Senior Design Project is focused on applying the skills
and knowledge the students have gained from interdisciplinary and concentration focused classes to a
project of the students’ choice. The project encompasses brainstorming of an idea to a deliverable
prototype over the course of the students’ senior year. Teams are typically constructed of four members
and can include multiple engineering concentrations if the project requires it.
1.2
Team Information
The BioBit team consists of four senior engineering students of the electrical and computer concentration.
The members of the team can be seen in Figure 1. The four team members have been taking classes
together for at least 2 years and had plenty of experience working as a team, as demonstrated in other
classes and labs.
Figure 1 – Team Photo (left to right) - Brad Kunz, Nick VanDam, Carl Cooper, Jessica Snyder
1.2.1
Carl Cooper
Carl Cooper is a senior at Calvin College studying Electrical and Computer Engineering. During the summer
of 2014, he had the opportunity to work with Professor Kim in the Calvin College Engineering Department
to develop a system that would monitor sustainable energy systems wirelessly with smartphone apps. He
gained experience creating and sending data over wireless networks, programming microcontrollers and
Android apps, and reducing power consumption on both microcontrollers and smartphones. He
understands the benefit of being able to track players on sports teams from his experience of playing on
11
sports teams all the way through elementary and high school in Chiang Mai, Thailand, including Varsity
Basketball and Volleyball.
In his spare time Carl enjoys pursuing the outdoors through rock climbing and backpacking, as well as all
things audio, from recording to building guitar amps and effects pedals. After graduation Carl will be
working at Gentex as a Production Support Engineer.
1.2.2
Brad Kunz
Brad Kunz is a senior Electrical and Computer Engineering major at Calvin College, who grew up in
Hudsonville, MI. Brad has had two previous internship experiences. Most recently, in the summer of 2014,
he was a part of the Digital Ventures team at Steelcase’s headquarters in Kentwood, MI. This Research
and Development team was focused on finding new and insightful ways to integrate technology into the
office space. He was exposed to various wireless communication protocols, along with the early stages of
product development and design. In the summer of 2013 Brad worked with the Automotive Plastics team
at Royal Technologies Corporation in Hudsonville, MI.
Brad enjoys staying active through sports such as soccer, tennis, golf, hiking, and going to the gym. He is
also interested in audio projects and music production. Brad will be joining JR Automation in Holland, MI
after graduation as a full-time Electrical and Controls Engineer.
1.2.3
Jessica Snyder
Jessica Snyder is a senior at Calvin College studying Electrical and Computer Engineering. The past two
summers (2013 and 2014), Jessica had the opportunity to intern at Koops Inc. in Holland, Michigan as a
Control Engineer. At this internship, Jessica was involved in many different aspects of the design and
building of factory automation solutions. She was also involved in the Controls Design department and
developed electrical schematics, pneumatic schematics, and bills of material. Jessica gained experience
building control panels in the Machine Assembly group and worked with Koops Launch Engineers to debug
and prove out several different pieces of automation. She also learned to create documentation manuals
for a variety of machines and be onsite at the customer’s facility performing service and support.
Jessica is currently working as a Student Office Assistant at the Engineering Department. She organizes
documents, updates the engineering website, helps plan the department events, and assists professors
when needed. She is also a student leader for Calvin’s Women and Engineering club. She plans social
events and study groups for the women engineers. After graduation, Jessica will be joining a Field Service
Engineering team at Burke E. Porter.
In her spare time, Jessica enjoys being active through going to the gym with friends, rock climbing,
camping.
1.2.4
Nick VanDam
Nick VanDam is a senior Electrical and Computer Engineering major with a designation in International
Engineering. Nick is currently an employee under two different organizations. Since 2008, Nick has been
working for Grand Rapids Christian High School Athletics as an Event Manager and Facility Caretaker. Nick
also works as an intern at AECOM (Legacy URS) Corporation within the Intelligent Transportation Systems
12
(ITS) division. He has held this position since May of 2013. This position is concerned with the technology
behind roadways which helps to improve the safety and efficiency of our transportation systems.
Surveillance systems, vehicle detectors, dynamic message signs (DMS), and their means of communication
(Fiber & Wireless) are all things encountered through this job.
In his spare time, Nick is also working on side projects involving mechanical and electrical repairs for both
the Calvin and local communities.
Upon graduation, Nick will join Siemens Energy within their renewable energy division. With this role, he
will enter a wind energy training program for the first year before specializing his job responsibilities for
years to come. With this job, Nick will have the opportunity to travel abroad and visit numerous wind
farms around the world operated and installed by Siemens.
1.3
Report Overview
Detailed below is a short description of each section of the Design Report document.
Section 2: Project Overview
Section 2 covers the requirements of the project specified by customers, similar products on the
market and what was identified by the team.
Section 3: System Design
Section 3 evaluates alternative solutions for aspects of system design. It also includes an overall
system architecture.
Section 4: Fitness Tracking Device
Section 4 breaks down what components will go into the fitness tracking device and how it will be
implemented in the design. The decisions are broken down based on requirements, alternatives,
decision criterion, and gives a final decision for each component.
Section 5: Central Hub
Section 5 discusses the design of the central hub and its implementation. The hardware decision
of the hub is broken down based on requirements, alternatives, decision criterion, and gives a
final decision. The section also talks about the software that will be used to implement the central
hub.
Section 6: End-User Application
Section 6 discusses what application platform is best suited to help implement the team’s design
and breaks down how the application will operate from a software aspect.
Section 7: Physical Design Specifications
Section 7 discusses the requirements and specifications for the physical design of the fitness
device housing and how it was design to meet the design requirements.
Section 8: Prototype and Deliverables
Section 8 discusses the prototype and outlines the deliverables of each stage of the project.
13
Section 9: Testing
Section 9 outlines how the system was tested. The section include feasibility testing done early in
the project and testing on the system components primarily concerned with system
communication and meeting performance requirements.
Section 10: Business Plan
Section 10 outlines a business plan for a potential startup company that is developed around
selling this a product based on this project.
Section 11: Project Management
This section details the team organization, each team member’s role and contributions, the
team’s budget, and the project timeline.
Section 12: Closing Remarks
Section 12 concludes the design report. It summarizes the project results, gives lessons learned
from this Senior Design project, and gives credit to the people and sources that helped in project
development.
1.4
Design Norms
The Calvin College Engineering Department encourages the integration of design norms into every project
that the students encounter during their college career and to continue this integration into their work
careers. These design norms are not exclusive to Christian engineering but help raise questions in the
design process that require the use of Christian faith. BioBit chose four design norms to focus on and help
guide this project: trust, integrity, caring, and stewardship.
1.4.1
Trust
Trust is something that is integral to the design. The users of the devices are relying on them to help
improve their fitness. Trust will be achieved by providing reliable data and constructing a dependable and
comfortable device. The customer should feel comfortable knowing that the device’s primary goal is to
help improve fitness and not harm them.
1.4.2
Integrity
This fitness tracking device shall have a harmonious form and functionality to it. The users of this device
should feel comfortable using the device in any situation and feel like it is merely an extension of their
body and not something that will hinder their performance in any way.
1.4.3
Caring
Caring is another design norm to be considered in the design process. The team wants the user to know
that this fitness device is for their physical, mental, and emotional benefit.
1.4.4
Stewardship
The team desired to integrate stewardship into its design by remaining conscientious of the materials
used in the design. Also by being good stewards of not only the resources that were given to the team but
also of our God-given talents.
14
2.
Project Overview
For the design scope and standards set forth by the team, please refer to the content herein. The following
sections define the requirements that convey the team's core values and standards.
2.1
Project Statement
The team came across the idea of a team-oriented fitness tracking device based on the combination of
their desire to work with a wireless communication and the members’ interest in personal fitness. Once
this shared interest was found the project idea was explored and researched.
2.1.1
Problem Identification
The market for personal fitness tracking devices is oversaturated with little variation in product
characteristics, and very little has been done on the side of team-oriented fitness trackers. This little
variation in the market was the area that the team is looking to capitalize on.
2.1.2
Proposed Solution
The solution that the team proposes is to design a team-oriented fitness tracker to provide a better way
to gage the intensity and effectiveness of workouts. The final design will include fitness wearables for a
whole athletic team that will connect to a centralized hub, where the data from all the wearable devices
will be collected. The user will be able to access the fitness data using an Android app anytime within the
local area network (LAN) via Wi-Fi communication protocol. The product will provide the end-users, such
as coaches and fitness trainers, the ability to access their data in real time. A high-level system diagram of
this can be seen in Figure 2.
Figure 2 – High-level System Diagram
15
2.2
Requirements
A list of requirements regarding the breakdown of functionality, electrical systems, software,
communication protocol standards, and physical requirements are listed below. It should be noted that
the corresponding requirement name to each definition will be used in the remaining of the report rather
than restating the definition.
2.2.1
Functional Requirements
REQ 2.2.1.1 The wearable devices shall be located on the body so as to be comfortable for the user and
still able to collect the desired data.
REQ 2.2.1.2 All devices shall have power on, off, and reset capabilities.
To provide proper functionality to users, they shall be able to turn on and off the devices when
they are ready to use them and when they are done with the devices. They also need to be able
to reset the devices in case some error occurs or they would like to restart the system.
REQ 2.2.1.3 All devices shall indicate status such as ON/OFF and mode.
In order for the users to easily recognize when devices are on or off, there will be an LED to
indicate when the device is on.
REQ 2.2.1.4 All devices shall be water resistant.
The devices will be used outdoors, thus submitting them to wind and rain as well as sweat from
being worn on the body of athletes.
2.2.2
Electrical Requirements
REQ 2.2.2.1 Wearable devices shall consume power to last at minimum two hours.
A typical practice session is two hours, so all devices being used shall have adequate power
supplies to last two hours at the minimum.
REQ 2.2.2.2 All wearable devices shall be portable and have internal rechargeable power supplies.
The battery will last a minimum of one practice session and it is inconvenient and expensive to
buy batteries and change them after every practice. To save time and money, each device shall
be rechargeable from a micro USB port.
REQ 2.2.2.3 The first prototype will incorporate a heart rate sensor and a pedometer sensor.
2.2.3
Software Requirements
REQ 2.2.3.1 Users shall be able to navigate displays on a mobile app.
Different data are important to different users so they shall be able to select what data they want
to be displayed. Data can also be grouped in several ways, such as by individual or by the whole
team, so users shall be able to choose what data is displayed and what format it will be displayed
(lists, graphs, charts).
16
REQ 2.2.3.2 Hub software shall run on an easily customizable operating system.
REQ 2.2.3.3 The hub shall run a database to store the data.
REQ 2.2.3.4 User's shall be able to view data on a mobile application.
REQ 2.2.3.5 Software shall be able to send data real time.
2.2.4
Communication Requirements
REQ 2.2.4.1 The protocol used needs to be accessible to smartphones.
The project requires the use of a smartphone for the coach so it shall be compatible with
smartphones, which limits the protocol to Bluetooth (IEEE 802.15), Wi-Fi (IEEE 802.11), or ZigBee
(IEEE 802.15.4) combined with one of the other two.
REQ 2.2.4.2 The protocol needs to handle a minimum of 22 athletes.
The project shall be useful to a soccer team with 11 players per team and thereby shall support a
minimum of 22 players at a time.
REQ 2.2.4.3 The protocol needs to work over a minimum range of 90 m.
If the hub is centered on the side of a soccer field, the maximum distance a player may be from
the hub is the opposite corner, or 88.5 m away so we have rounded up to 90 m.
2.2.5
Physical Requirements
REQ 2.2.5.1 The design shall not hinder the motion of the user.
REQ 2.2.5.2 The device shall be produced at maximum weight of 4 ounces.
REQ 2.2.5.3 The device shall be intuitive for operation and wear.
REQ 2.2.5.4 The design shall consider the environment when selecting materials for construction.
REQ 2.2.5.5 The design shall use a minimal number of parts.
REQ 2.2.5.6 The device and central hub shall be able to resist minor exposure to water.
REQ 2.2.5.7 The device shall be impact resistant from consistent exposure to athletic activity.
3.
System Design
This section discusses the approach to the system design and how it serves as a solution to the problem
stated earlier in the document. The section will look at several design alternatives that will affect the scope
of the design. At the end of each section there is a selected best design based on a decision matrix. These
high-level decisions will go into further detail in the following sections of this document.
17
3.1
System Communication
This section explores the wireless communication protocol that the devices will use to send and receive
data. The wireless communication protocol chosen is a large decision as it has a great impact on other
decisions made throughout because the microprocessors that are chosen need to have the capability to
use the protocol or have a way to interface with the protocol. The three most common wireless protocols
are listed below and rated in a decision matrix to determine the most suited protocol for this project. It
was found that Wi-Fi is the best choice for this product because it meets the requirements and can be
implemented in the most intuitive and reliable manner.
3.1.1
Possible Solutions
The three most common wireless protocols Wi-Fi, Bluetooth, and ZigBee are listed below and a brief
overview of each is given.
3.1.1.1
Wi-Fi
Wi-Fi (IEEE 802.11) is a wireless communication based on Ethernet (IEEE 802.1). It was designed to connect
devices together on a wireless local area network (WLAN) and ultimately to a router and from there to
the World Wide Web. It uses collision avoidance (more specifically Carrier Sense Multiple Access with
Collision Avoidance, CSMA/CA) to eliminate communication problems arising from multiple devices
talking at the same time. It is one of the most prevalent forms of wireless communications, being found
in computers and smartphones. This gives it an advantage because there is a wealth of information on
how it works and how to use it. It also gives the project the possibility to post information on the Internet,
thus expanding the accessibility of the data from the WLAN to anywhere Internet is available.1
3.1.1.2
Bluetooth
Bluetooth (IEEE 802.15) is a form of wireless communication developed to provide a low power alternative
over a short range. It is primarily used to connect peripheral devices to a master, such as Bluetooth mice
and keyboards to a computer. It is also being used increasingly in smartphones to connect to speakers,
other smartphones, and even personal fitness tracking devices. Bluetooth uses adaptive frequency
hopping to prevent data packet collisions. Bluetooth has an advantage that it consumes minimal power,
thus making devices last longer between charges.2
3.1.1.3
ZigBee
ZigBee (IEEE 802.15.4) was developed to address the shortcomings of Bluetooth and Wi-Fi. It was designed
to create wireless personal area networks (WPAN) for applications that use a lower transmission data
rate. It has lower power consumption than Wi-Fi but it can also have a larger range than Bluetooth. ZigBee
also uses CSMA/CA to handle issues that could arise from multiple devices attempting to transmit
simultaneously. It was designed to be used in applications such as home automation or other wireless
communication between devices around the home.3 It does provide an obstacle in that smartphones and
tablets do have the capability of communicating over ZigBee so it would need to be used in conjunction
with Wi-Fi or Bluetooth to give the app accessibility to the system.
18
3.1.2
Decision Criterion
The following subsections outline the areas that the team decided were critical in the decision a of wireless
communication protocol.
3.1.2.1
Range
Each wireless communication protocol has a different range and this is significant to the decision of which
communication to use. As determined by REQ 2.2.4.3, the protocol shall be able to transmit data from
each player back to the coach over a range of 90 meters. Thus a suitable communication will allow players
to cover this distance and still get data back to the coach reliably.
3.1.2.2
Power Consumption
The power consumed by each protocol is crucial to the project because the devices need to be able to last
for an entire practice. The less power the wireless protocol typically uses the better, because not only will
it allow the device to last for one practice, it could also potentially last for several practices, which puts
less effort on the coach to make sure that they are charged.
3.1.2.3
Central Hub
Depending on the protocol used, a central hub may or may not need to be used. Adding a central hub to
the project will raise the price of producing the product, which will increase the price to the end user. On
the other hand, if the protocol does not require a central hub but does require implementing a mesh
network and routing data through devices to get back to the host, it may increase the scope of the project.
3.1.2.4
Bit rate
The bit rate of the protocol determines how fast data can be sent. A faster bit rate indicates the ability to
send more data and send data at faster intervals. While not highly critical because the amount of data
that will need to be sent is not a significant amount, a faster bit rate is beneficial in the event of adding
more sensors or decreasing the rate at which packets are sent.
3.1.2.5
Network Size
The number of devices that a network can contain for each protocol is important to the success of the
project. As determined by REQ 2.2.4.2 the protocol that is chosen shall be able to handle a minimum of
22 players on the field at a time. If the protocol can handle more devices, it will get a better score because
more tracking devices could be added to the network for different applications. If the chosen protocol
does not handle 22 devices per network, some other form of networking shall be chosen, such as forming
and disbanding networks quickly to route packets between devices. This adds complexity that may be out
of the scope of the project, resulting in a lower score.
3.1.3
Decision Matrix
From the criteria described in the previous section, a decision matrix was constructed, as seen in Table 1.
Each criterion has its own weight that multiplies the ranking of the design alternatives being considered.
The weights are based on which criterion is considered critical to implementing the design given the
requirements. The alternative with the highest summed total from each criterion is to be considered the
best solution4.
19
Table 1 – Decision Matrix for Communication Protocol
3.1.3.1
Best Solution
From the decision matrix, it is clear that Wi-Fi is the best option. It will cover the range that is needed as
well as the number of players required, as seen in Figure 3. It has the highest bit rate and has an ample
worst case scenario power consumption that will allow a battery last for an entire practice. Another major
contribution to the decision of Wi-Fi was the ease of collecting data and implementing a database on a
central hub as well as the possibility of having that data available outside of practice on the Internet. If
ZigBee was chosen, an additional wireless protocol would have to be used because phones do not have
the capability to transmit and receive data over ZigBee. This adds extra and unnecessary complexity to
the project. Bluetooth does not cover the required range or network size so additional work would have
to be done to quickly form and disband networks to route data through other devices on the field to the
central hub.
Figure 3 – Diagram of Range for Wi-Fi and Bluetooth Over Standard Soccer Field Dimensions
20
3.1.3.2
Recognized Weaknesses
One of the biggest problems with Wi-Fi is that it consumes the most power. While the power consumption
should be low enough to meet the requirements, it is something that will need to be addressed and
focused on to make sure that it complies with the requirements. Depending on what power consumption
other components have and the size of the battery, the power consumption of Wi-Fi could be a problem.
Another issue that may arise is that while the accepted range of Wi-Fi is 90 meters, if the antennas on the
hardware that are selected are low quality, there will be a loss in range and signal strength. To
compensate for this, better antennas can be obtained, or data can be stored until devices are in range of
the central hub again.
3.2
Overall System Block Diagram
Below, in Figure 4, a high level view of the final overall system is shown in the form of a level one block
diagram. The block diagram shows three subsystems: a fitness device, a central hub, and a mobile device.
There will be multiple fitness devices connected wirelessly to the central hub’s Wi-Fi module, but for
simplicity only one is shown. The battery charger shown is to indicate the charging process of the battery
in the fitness device, but is not a permanent connection. Dashed lines between components are wireless
connections while solid lines within a component are wired.
Figure 4 – Level One Block Diagram of the Overall System
4.
Fitness Tracking Device
Within the contained selections below, a discussion of the fitness tracking device and a breakdown of the
components of the design are covered. The tracker is the core device that will be measuring the user’s
biometrics. The subsections will discuss individual components, which includes requirements,
alternatives, decision criteria, the decision, and implementation where it was deemed fit. Decisions where
21
there were no clear favorite for fulfilling the requirements take a slightly different evaluation which
include a decision matrix to help with the final decision.
4.1
Wearable Location
The location on the body of the wearable is integral to the design as it can limit the capabilities of the
design and the nature in which it is implemented. The top four suggested wearable locations, as per a
consumer survey, are evaluated in the following subsections. The team determined that a wrist mount
would be the best location for the prototype.
4.1.1
Possible Solutions
The possible solutions listed below were the top four responses in an early customer survey sent to local
Grand Rapids, MI coaches, fitness trainers, exercise science professors, and athletes.
4.1.1.1
Wrist
The age of the Smart Watch is here and smart fitness devices are only a few steps ahead of them. The
wrist is a go-to location for personal fitness wearables because of its easy placement and it can serve as a
fashion piece. The wrist is also a good location for devices that require personal interaction with it, such
as button pushing, screen reading, and user-program interaction.
4.1.1.2
Chest
It is not uncommon that a chest mount is used in professional sports fitness tracking devices. The main
purpose for placing a fitness wearable on the chest is to get an accurate reading for a heart rate measure.
A fitness tracker typically requires skin contact, depending on what data it is attempting to collect. The
chest mount would have the bulk of the device placed on the back of the user with the heart rate sensor
placed around the front near the heart on a strap. It also provides a good location for accurate step data.
4.1.1.3
Head
A fitness wearable could be placed on the head in the form of a headband. This location is capable of
measuring the desired data, but it would be subject to the largest volume of sweat and it would have to
have a very low profile in the headband. Tracking from the head is a possible future design to be integrated
into helmet designs for contact sports.
4.1.1.4
Waist
A wearable device located on the waist has similar capabilities and requirements to the chest mount. It
would be worn similarly to a belt and an adequate location to take heart rate readings would have to be
found.
4.1.2
Decision Criterion
The criterions listed below are what the team deemed critical to the wearable location decision.
4.1.2.1
Sensor Capability
The placement of the wearable is largely dependent on whether or not the data can be measured at that
location. Certain places on the body are better suited for taking heart rate readings and step data than
others. A wearable placed on an extremity would be more difficult to decipher the step motion with the
added noise from the swinging of arms or legs. Measuring the heart rate is based on how close arteries
22
are to the surface of the skin to get a good reading. The four placements were based on the ease of
recording the desired data from body.
4.1.2.2
End-User Desirability
There are certain locations that end-users are more willing to wear this fitness tracker. This particular
criterion was based on the responses received from the customer survey. Responders were asked where
on the body they thought athletes would feel most comfortable with the tracker being placed.
4.1.2.3
Size Restrictions
The size of the device is dependent on where it is placed on the body. Certain locations would require a
lower profile and a reduced sized product. Locations that restrict size and complicate the design were
rated lower than those that allowed for adequate amount of space.
4.1.2.4
Unobtrusiveness
The location of the fitness tracking device needs to be placed in such a way that the user feels comfortable
and that it will not hinder their performance. This is based on movement during fitness activities and
whether the user would have to place it on the body under their clothes.
4.1.2.5
Weight
Given that the system would be about the same weight regardless of body placement, this criterion is
based on where the added weight of a wearable would be least noticeable to the user.
4.1.2.6
Materials Cost
Depending on the placement of the fitness device, there may be different materials required. This
criterion helps determine the location that would have the smallest material cost to implement.
4.1.3
Decision Matrix
From the criteria described in the previous section, a decision matrix was constructed below in Table 2.
Each criterion has its own weight that multiplies the ranking of the design alternatives being considered.
The weights are based on which criterion is considered critical to implementing the design with the given
requirements. The alternative with the highest summed total from each criterion is to be considered the
best solution.
23
Table 2 – Decision Matrix for Device Placement
4.1.3.1
Best Solution
From Table 2 it can be seen that the best location for the fitness device is a wrist mount. This decision will
be critical for the rest of the design as it will directly affect the algorithms written for the pedometer and
at what sensitivity the heart rate sensor will be able to work at. The end-user reason for this choice is the
increased comfort and ease of use.
4.1.3.2
Recognized Weaknesses
For a wrist mounted device, the biggest weakness would be in the physical design. This is because the
design would have to find a middle ground between device functionality and size of the device. Depending
on the resources, budget, and capabilities of the team, a small wrist mounted wearable that users would
be willing to wear may not be capable for a prototype. However, the team is willing to accept a larger
device for a first prototype that could be reduced in a final design. Another issue the team may face is
that the wrist is not the most ideal location for either a heart rate sensor or an accelerometer. For the
heart rate sensor the finger, ear, and heart are better locations and for the accelerometer is better located
on the trunk of the body.
4.2
Fitness Tracking Device Architecture
The main component of the fitness device is the processing board, for the final design this will be an
Arduino Pro Mini. This board will receive power from the battery that is located within the device and the
Arduino will serve as a power source for the two onboard sensors. These sensors will have a data
communication line to the I/O pins on the onboard processor and the Wi-Fi chip will wirelessly send the
data to the central hub. This can be seen in detail in the block diagram below along with a wiring diagram.
24
Figure 5 – Detailed Block Diagram of Fitness Device
Figure 6 – Wiring Diagram for Fitness Device
25
4.3
Hardware
This subsection will discuss how each of the hardware pieces were decided upon and what requirements
they fulfill within the fitness device.
4.3.1
Processing Board
The device’s microprocessor will host a program that will collect incoming sensor data, run calculations
and compile the data into packets that will be sent to a Wi-Fi module, which will transmit the data
wirelessly to the central hub.
4.3.1.1
Requirements
The processor shall be fully capable of handling the data load and computations that it would be
processing. The board shall have the ability to upload software to it. The board shall have input and output
pins available to receive or send data to other components. The board shall meet the following
requirements listed earlier in the document: REQ 2.2.1.2, REQ 2.2.1.3, REQ 2.2.2.1, REQ 2.2.2.2, REQ
2.2.3.5, REQ 2.2.5.2, REQ 2.2.5.4, and REQ 2.2.5.5.
4.3.1.2
Alternatives
The two ways to solve these requirements are either to fabricate a custom circuit board with the desired
processing, storage, and communication capabilities, or to purchase a general purpose board that
encompasses the listed requirements.
Three examples of pre-fabricated boards that the team looked at using to solve the listed requirements
are the Intel Edison, Arduino Pro Mini, and Adafruit’s FLORA. The Intel Edison5 seen in Figure 7, is a
development kit made for wearables. It features an Atom dual-core CPU, integrated Wi-Fi and Bluetooth,
memory for data storage, and a range of I/O pins for connecting to peripheral circuit boards.
Figure 7 – Intel Edison Size Comparison6
The Arduino Pro Mini7, Figure 8, has all the same capabilities of the larger Arduino Uno but just in a smaller
board. It has two different versions that either include 16MHz or 8MHz processors paired with either a 5V
or 3.3V operating voltage. It offers a large variety of input and output pins, both digital and analog.
26
Figure 8 – Arduino Pro Mini Size Comparison8
The Adafruit FLORA9, seen in Figure 9, is an Arduino-compatible microcontroller designed for wearable
projects. It has built in USB support and has a modified version of the Arduino IDE. It offers multiple
compatible boards that include components like GPS, accelerometers, various other sensors, and
capacitive touch10.
Figure 9 – Adafruit FLORA Size Comparison
4.3.1.3
Decision Criteria
The decision will be made based on the ease of implementing the design and what capabilities either
alternative gives us. The board shall be designed to work with a wearable device and offer the ability to
expand if design stretch goals are pursued. Other criteria include price per board and labor time required
to get it to a point of implementing within the design.
4.3.1.4
Decision
The processing board alternative chosen was a prefabricated board in the form of the Arduino Pro Mini.
The Arduino offers plenty of computing power with plenty of input pins for several peripherals. It is better
suited than the Adafruit FLORA because the FLORA is aimed toward integrating in fabric and requires
multiple partner boards to implement the design. It is also easier to implement than the Intel Edison,
27
which would need for level shifters to communicate with sensors as its I/O pins use 1.8V and most sensors
use 3.3V. A customized fabricated board will not be pursued due to budget and time constraints.
4.3.1.5
Implementation
The implementation for the Arduino Pro Mini board is intended to provide the main capabilities to collect
raw data coming from the sensors, perform calculations on the data to get the desired fitness data, and
package the resulting data to be sent to the server by a partnering communication board. This will be
done via the Wi-Fi wireless communication protocol in a LAN setup as described in Section 3. With the
implementation of the board, features such as physical design, electrical requirements, and wireless
communication standards shall be evaluated in order to ensure consistent and reliable functionality. It
should be noted that the Arduino Pro Mini has the capability to be programmed, but it requires using a
separate Serial to USB board. However, by not buying a board with this functionality built-in the team
saved space, which is crucial to this project.
4.3.2
Wi-Fi Module
A Wi-Fi module is needed to communicate the processing data from the Arduino Pro Mini to the central
hub. The decision to choose Wi-Fi as the system communication can be found in Section 3. The following
subsections will walk through the decision to choose a Wi-Fi module and how it was implemented in the
design.
4.3.2.1
Requirements
The Wi-Fi module shall be fully capable of handling the data from the processing board. The board must
be able to be implemented easily with an Arduino. The board must also be of relative small size to
integrate into the physical housing of the wearable. The board shall fill the following technical
requirements listed earlier in the document: REQ 2.2.2.1, REQ 2.2.2.2, REQ 2.2.3.5, REQ 2.2.4.1, REQ
2.2.4.2, and REQ 2.2.4.3.
4.3.2.2
Alternatives
The team decided to go with a pre-fabricated Wi-Fi board due to the design scope and the market
availability of products that are fully capable of meeting the project’s desired requirements. Below are
three different alternatives that were considered by the team.
First is the SparkFun Wi-Fi Breakout11, which uses the CC3000 chip and can be seen in Figure 10. The chip
offers the ability to be powered from a range of 3.3V – 12V and be interfaced at 16MHz. It’s capable of
attaching an external antenna if the original is found to be too weak. The dimensions of the board are
46.4 x 26.2 x 3.6 mm and costs $35 on SparkFun.
28
Figure 10 – Size Comparison for SparkFun Wi-Fi Breakout
A second option is the RN-XV WiFly Module, seen in Figure 11. This module incorporates an 802.11 b/g
radio, a 32 bit processor, and a TCP/IP stack. It is also considered to be ultra-low power with a 4uA sleep
mode and 38mA active mode. It is designed with the same footprint as X-Bee chips so as to allow for easy
switching between protocols. The cost of the board is $35 on SparkFun.
Figure 11 – Size Comparison of RN-XV WiFly Module
A third option is the ESP-8266 Wi-Fi Module as shown in Figure 12. The module is a self-contained SOC
(System on a Chip) with an integrated TCP/IP protocol stack. It is operated using simple AT commands and
it is designed to be plug and play with Arduino. It has an 802.11 b/g/n radio and additionally it has an
onboard 32-bit CPU, if it were to be used as an application processor. The board is smaller than the other
two alternatives and is much cheaper as well at $7 a piece on SparkFun.
Figure 12 – Size Comparison for the ESP-8266
29
4.3.2.3
Decision Criteria
The decision will be made based on the ease of implementing the device into the design and what
advantages each alternative offers over the other alternatives. The board shall be able to handle the
amount of data that will be sent over it and offer the ability to expand if design stretch goals are pursued.
Other criteria include price per board and labor time required to implement it into the design.
4.3.2.4
Decision
The Wi-Fi board that the team chose was the ESP-8266. This was due to a number of reasons, including
its price, size, and ability to integrate into the system. All of the devices offer the same functionality with
variable implementation processes and the team felt that a cheaper component would still serve the
customer’s needs while keeping with our design norm of integrity by building a fully functional product.
While there is limited documentation for this device available, the team felt that they would be able to
overcome this lack of information, because there were plenty of forums and tutorials online as it is a very
popular product for do-it-yourself projects.
4.3.2.5
Implementation
Once the team was able to obtain the boards from several different vendors, the boards were
incrementally implemented into the design first by sending manual AT commands through a serial
terminal and then implementing it into the final design by writing code for the Arduino to send the
appropriate commands automatically. Inside of the fitness device the board is connected to the Arduino’s
Serial receive and transmit pins. Unlike the sensors, the ESP-8266 is powered by a separate circuit as the
current demand during peak usage of the board is unable to be provided by the Arduino. Therefore, the
board was powered separately from the Arduino using Schottky diodes to lower the battery’s voltage to
a level the Wi-Fi board can operate from (3.3V). These connections can be found in the design’s wiring
diagram in section 4.2 Fitness Tracking Device Architecture.
4.3.3
Heart Rate Sensor
One of the sensors needed to complete the system is a heartbeat sensor. This sensor will track the user’s
heart rate and send the measured data to the processor.
4.3.3.1
Requirements
Defined by both the end-user and the device capabilities, the requirements for a heartbeat sensor include
size, protocol used, and power requirements. With this, the team looked to optimize these requirements
and meet a middle ground on all aspects in order to reach a decision on what manufacturer to choose and
how to implement it. The board shall fulfill the following requirements listed earlier in the document: REQ
2.2.1.1, REQ 2.2.2.1, REQ 2.2.2.2, REQ 2.2.2.3, REQ 2.2.5.1, and REQ 2.2.5.2.
4.3.3.2
Alternatives
Within the exploration of possible sensors for heart rates, there are two major alternative designs for
tracking the information. These two types include both conductive and optical sensors. The conductive
design uses two exposed metal tabs that contact the skin directly. As the blood pulses through the body
of the user, the conductance between these two tabs fluctuates. It is this fluctuation that is registered as
a heartbeat. As for the design of the optical sensor, light is emitted on the skin. With this light, the amount
received or reflected back to the device is dependent on the transparency of the skin. As the users’ pulse
30
passes through the area, the transparency of the area changes and a different amount of light is received
by the sensor, thus registering a heartbeat on the device.
The Polar Heart Rate Sensor12, as seen in Figure 13 below, provides a simple 32-bit heart rate buffer
solution using conductance to track heart rate. With multiple interfaces, including USB, Logic-Level serial,
and I2C, various types of communication methods can be used to utilize the device. This expands the
options of connectivity between the sensor and the microprocessor. Additionally, dual heart rate
processing algorithms are both averaged together and presented as raw data independently, thus
providing redundancy and accuracy.
Figure 13 – Polar Heart Rate Sensor
Secondly, the features of the TI TIDA-0001113, as seen in Figure 14 below, present a new set of options
with measuring the pulse from the veins in the wrist optically. This heart rate sensor has dual processing
algorithms with both averaged and raw compilations, much like the Polar heart rate sensors as listed
above.
Figure 14 – TI TIDA-00011 Sensor
Finally, the Pulse Sensor SEN-1157414, as seen in Figure 15 below, is uniquely set apart from the previous
options as it is Arduino compatible and operates via a simple optical sensor with amplification and noise
cancellation integrated. This sensor draws 4 a milliamp current at 5 volts. With its size, 0.625" diameter
and 0.125" thick, it could certainly become an advantage when looking to make a compact device.
31
Figure 15 – Pulse Sensor SEN-11574
4.3.3.3
Decision Criteria
The decision will be based on the board’s ability to fulfill the requirements of reading and outputting a
heartbeat signal along with the board’s footprint. The board needs to be small enough to fit within the
inside of the wearable and most importantly it needs to be reliable. The board’s ability to be integrated
into the project will be another factor that will be considered when making a decision.
4.3.3.4
Decision
The team decided to use the Pulse Sensor based on the fact that the Pulse Sensor is an optical sensor that
would only have to be in contact with the skin in one place. Another great feature of the pulse sensor is
its size, it is one of the smallest market available sensors and in a size restricted design this will help. A
third reason for choosing the Pulse Sensor is its Arduino compatibility and that its code is open source.
Finally, it is much cheaper than the other options, which lends itself to helping the team follow the design
norm of stewardship.
4.3.3.5
Implementation
Due to the Pulse Sensor’s compatibility with Arduino boards there were only minor adjustments to the
available software to make it compatible with the Arduino Pro Mini, which runs at 8MHz rather than the
16MHz the sensor was designed for. The producer of the sensor provides basic code that calculates the
beats per minute (BPM) of the user. This code was adapted and manipulated to be compatible with the
team’s design.
4.3.4
Step Sensor
A second sensor that is required for the system is a step sensor. This data will be transferred to the
processor to process the data and send it on to the central hub.
4.3.4.1
Requirements
When scanning the market for potential step sensors and/or accelerometers, the team will again look to
acquire a component that has a small footprint in both size and weight without compromising quality and
accuracy. The step tracker is dependent on how the device is oriented on the body, while an
accelerometer requires maintenance of axis in order to determine motion direction and speed. The board
shall fill the following requirements listed earlier in the document: REQ 2.2.1.1, REQ 2.2.2.1, REQ 2.2.2.2,
REQ 2.2.2.3, REQ 2.2.5.1, and REQ 2.2.5.2.
32
4.3.4.2
Alternatives
The alternatives listed below are the result of research of the current market. It is outside of the team’s
scope to design customized sensors.
The SparkFun Triple Axis Accelerometer - ADXL335 sensor15, as seen in Figure 16 below, functions with
three axes, allowing for a step tracking but also measurement of vertical movement if desired. With its
low noise and power consumption of 320 µA, its g-force sensing range is an impressive ± 3g. The
dimensions of the board and sensor above are 17.8mmx17.8mm.
Figure 16 – SparkFun Triple Axis Accelerometer - ADXL335
Similarly to the SparkFun accelerometer, the STP156 pedometer16, as seen in Figure 17 below, is a triple
axis MEMS G sensor accelerometer. Its working voltage rests between 2.5 volts and 3.3 volts and an error
range of ±5% per step, which is a significant factor to be considered. The dimensions of the board and
sensor come out to be 11.26mmx41.8mm.
Figure 17 – STP156 Pedometer
A third option is the InvenSense MPU-605017, seen in Figure 18, the sensor contains a MEMS
accelerometer and a MEMS gyro. The on board DMP (Digital Motion Processor) is able to do all the needed
calculations to relieve the partnering processor such as an Arduino. The dimensions of the board are
21mm x 16mm.
33
Figure 18 – MPU-6050 Accelerometer/Gyroscope GY521 Breakout Board
4.3.4.3
Decision Criteria
The decision will be made based on the ease of implementing the design and what capabilities the
alternatives gives us. The sensor should have easy integration with the processor. The board shall be
designed to work with a wearable device and not limit the ability to expand the design's stretch goals if
they are pursued. Other criteria include price per board and labor time required to get it to a point of
implementing within the design.
4.3.4.4
Decision
Based on the decision of using an Arduino Pro Mini as the processing board, the best choice was the MPU6050. This was due to its easy ability to be paired with the Arduino. The size of the board, while larger
than the other alternatives, does not restrict the ability to design a first prototype and it gives the option
for greater sensitivity by having both an accelerometer and gyroscope.
4.3.4.5
Implementation
The board was first tested for the ability to record raw data and capability to communicate over I2C with
an Arduino. Then an algorithm was written to take the raw data and convert it into steps. This algorithm
was adapted from the Pebble Watch's open-source step tracking algorithm. The sensitivity of the sensor
was refined through testing to find the optimal range for accurate step tracking.
4.3.5
Battery
Due to the needed mobility of the fitness device, a battery will be the source of power. The subsection
below details the requirements, alternatives, decision criteria, decision, and implementation.
4.4.5.1
Requirements
The required size of the battery is found based on the length of operating time and the average amount
of current the system needs. This was calculated roughly to be 300mAh. The ranges of voltage
requirements are expected to fall between 3V and 5V. The battery itself shall be compact, efficient (low
emission of heat), and rechargeable. The board shall fill the following requirements listed earlier in the
document: REQ 2.2.2.1, REQ 2.2.2.2, REQ 2.2.5.1, REQ 2.2.5.2, and REQ 2.2.5.4.
4.4.5.2
Alternatives and Decision Criteria
The alternatives when regarding the power source for the wearable technology are laid out in Table 3
below. Within this table there is a brief explanation and specification for content such as capacity, weight,
comparative price, and benefits versus disadvantages.
34
Table 3 – Battery Type Comparison
NiCd
NiMH
Li Ion
Li Po
Capacity Per Volume
(Wh/L)
[volume energy density]
50-150
140-300
250-730
300
Memory Effect
Yes
Yes
No
No
Minimum Voltage before
damage
1V
1V
2.8 V
3.7 V
Price (comparably)
$
$$
$$$
$$$
Environmental Issue
XXX
- Cd is highly
toxic
X
- recyclable
- less toxic
X
- recyclable (not
efficient)
X
- recyclable (not
efficient)
Pros
- fast charging
- high number
of cycles
- good temp
performance
- higher capacity
(compared to
NiCd)
- less memory
effect
- recyclable
- high specific
energy
- low selfdischarge
- high specific
energy
Cons
- memory effect
- high selfdischarge
- complex charge
algorithm
- high selfdischarge
- requires
protection circuit
- subject to aging
- high cost
4.4.5.3
Decision
After receiving all of the components that would be included in the wearable device, the team compiled
high-level estimates for power consumption in the situation of maximum load. This estimate included the
acknowledgement that the Wi-Fi module would take up a large percentage of the demand from the power
supply. With this, a single-cell 400mAh 3.7V Lithium Polymer (LiPo) battery was selected. Additionally, a
charging circuit was implemented into the wearable, which provides the user a micro-USB port on-board
in order to charge the device with ease and efficiency.
4.4.5.4
Implementation
Upon installment of the LiPo battery into the wearable device, the decision was made to place the battery
in the bottom of the housing next to the heart rate sensor. Additionally, the charging circuit was put on
the top layer of the boards in the housing to increase accessibility and provide a visually pleasing location
for the micro-USB charging port.
35
4.4.6
Battery Charging Circuit
Once the decision of the battery for the fitness wearable was completed the team needed to implement
a way to charge this battery. Due to the late nature of this decision, the team decided that they would not
have the time to design and construct their own charging circuit, but rather a manufactured board would
be pursued.
4.4.6.1
Requirements
The main requirements for the charging circuit would first be compatibility with the 400mAh 3.7V Lithium
Polymer battery that was chosen and a small footprint as it will be used within the fitness device and
space comes at a premium. The charging circuit shall fill the following requirements listed earlier in the
document: REQ 2.2.2.2 and REQ 2.2.5.5.
4.4.6.2
Alternatives
The alternatives listed below all fit the desired requirements and come from various vendors.
First is the Adafruit Micro LiPo with MicroUSB Jack – USB Charger18, this is a simple board that will power
the 3.7V LiPo battery chosen for the design and has the option to either be charged at 100 mA or 500 mA.
The dimensions of the board are 21mm x 19mm. At time of decision the board cost $6.95 on Adafruit.
Figure 19 – Adafruit Micro LiPo USB Charger Size Comparison
A second alternative is the SparkFun LiPo Charger Basic – Micro USB19, the board is capable of charging
3.7V LiPo cells at a rate of 500mA. The board incorporates an LED to indicate the charging status. The
board’s dimensions are 29.4mm x 10.8 mm. At time of decision the board cost $7.95 on SparkFun.
Figure 20 – SparkFun LiPo Charger Basic Size Comparison
36
4.4.6.3
Decision Criteria
The decision will be made based on the ease of implementing the charging circuit into the design. The
main factor will be size as it was the last component decided on in the fitness device and there is a limited
amount of room in the housing.
4.4.6.4
Decision
The charging circuit that the team chose was the Adafruit Micro LiPo with MicroUSB Jack – USB Charger.
This is due to the size of the board, as it fit better than the SparkFun LiPo Charger Basic because it had a
square footprint and the SparkFun board was too long to fit into the predetermined location in the fitness
device. The Adafruit charging circuit was also the cheaper alternative without giving up any functionality.
4.4.6.5
Implementation
The implementation of this charging circuit is reasonably easy. The location was finalized and placed
within the fitness device. The connections to this board are the jack where the battery plugs in and two
soldering points for the output power and ground for the rest of the components in the fitness device.
The power pin goes to a switch before powering the rest of the circuit so that the device can be turned
on and off easily.
4.5
Software
The section herein discusses the role of software within the design and operation of the fitness wearable.
Software will control and serve as a communication medium between the hardware components listed
above.
4.5.1
Processing Board
The Arduino Pro Mini of the fitness device must serve as the processing component of the whole device.
In order for this to happen a program was written using the Arduino IDE and uploaded to each Arduino
used in the devices. The program must collect the data coming in from the Pulse Sensor and the
accelerometer/gyroscope. Once this data is collected, as an analog voltage from the Pulse Sensor and as
and raw axis values from the MPU-6050, it must run it through algorithms to output the needed data of
BPM and step count. This data is then packaged into an HTTP GET request and is sent to the server via the
ESP-8266 (Wi-Fi board). The program is executed in a way that an update to the server is sent every 10
seconds. This window is easily adjusted using the Arduino's Timer library.
5.
Central Hub
This section outlines the central hub architecture, the hardware, and software design and discusses many
aspects of each subsystem that will be implemented within the central hub. The team looked at two
options of single board computers and decided to use a Raspberry Pi as the central hub.
5.1
Central Hub Architecture
To create the entity of the central hub, a device will be used as a server that is in charge of receiving and
managing all the data coming from the wearable devices. This data will be stored in a database and then
made available through the use of a mobile application. The hub is capable of acting as a wireless
hub/router so that it can create a wireless network and allow other devices connect to the network. See
in Figure 21 for a diagram of how the files are organized.
37
Figure 21 – Server and Database File Relation Diagram
5.2
Hardware
The following sections discuss the design and decision process for the central hub hardware components.
5.2.1
Requirements
The central hub is a key component in the system as it shall be capable of creating a secure wireless
network, running a Dynamic Host Configuration Protocol (DHCP) server paired with a database to store
data, and send data to the end user app. The hub shall fulfill the following requirements listed earlier in
the document: REQ 2.2.1.2, REQ 2.2.1.3, REQ 2.2.1.4, REQ 2.2.3.2, REQ 2.2.3.3, REQ 2.2.3.5, REQ 2.2.4.2,
REQ 2.2.4.3, and REQ 2.2.5.6.
5.2.2
Alternatives
There are several options for how the central hub could be implemented. The team could design their
own circuit board with the required functions, use a computer, or single board development boards.
Designing a circuit board for this complex a device is out of the scope of the project. There is no need to
use a personal computer (PC) as this would drive up the price, have more functionality than the project
requires, and increase the size of the device, so it was decided that the hub shall be implemented with a
single board computer. A single board computer is a computer contained on one circuit board. It has a
CPU, memory, and I/O ports, but does not have as high specifications and processing power as a PC.
5.2.2.1
Raspberry Pi B+
A Raspberry Pi B+20, as seen in Figure 22 below, is a single board computer that is capable of acting as a
central hub. The Raspberry Pi is a small computer that typically runs a version of Linux called Raspbian,
but can run other operating systems. A Raspberry Pi uses a 700 MHz Low Power ARM1176JZFS
Applications Processor CPU and has 512MB of SDRAM. It has 40 pins for connecting inputs and outputs as
well as 4 USB 2.0 ports, but in this application they may not need to be used. To give the Raspberry Pi WiFi capabilities, a USB Wi-Fi module would need to be connected. Since it runs Linux, it is fully capable of
creating a Wi-Fi network and running a server.
38
Figure 22 – Raspberry Pi B+
5.2.2.2
BeagleBone Black
A BeagleBone Black21 is a similar type of single board computer, as shown in Figure 23 that can run a
number of operating systems, including Linux. It has an AM335x 1 GHz ARM Cortex-A8 and 512 MB DDR3
RAM as well as 4GB 8-bit eMMC on-board flash storage. It would also need a USB Wi-Fi module to have
Wi-Fi capabilities. It is fully capable of creating a Wi-Fi network and running a server.
Figure 23 – BeagleBone Black
5.2.3
Decision Criteria
The decision criteria used were for deciding on a central hub include: power consumption, amount of
reference material, price, and processing power. Both are capable of performing the required tasks and
have similar specifications so the specifications were a minimal factor in the decision.
39
Table 4 – Decision Matrix for Central Hub
5.2.4
Decision
The team decided to use a Raspberry Pi B+ as the central hub. The Raspberry Pi has been on the market
longer than the BeagleBone and is more widely used so it has a larger community base and reference
material. While the BeagleBone may be better in terms of processing power, the Raspberry Pi is cheaper
and still has the power that the team needs. Not only is the base price of the Raspberry Pi cheaper than
the BeagleBone, both would need a USB Wi-Fi module to create a WLAN and to get the same amount of
storage as the Raspberry Pi, the BeagleBone would need an SD card as well. There are no exact numbers
for the power consumption of the Raspberry Pi available like the BeagleBone, but the reported numbers
are less than the BeagleBone. All of these factors combined with the fact that the team had access to a
Raspberry Pi to do some early testing made it the better choice.22
5.2.5
Implementation
A Raspberry Pi B+ was purchased and set up to create a wireless local area network (WLAN), a dynamic
host control protocol (DHCP) server to assign IP addresses, a MySQL database, and a PHP server.
Additional testing was completed to make sure that it could set up a server as further explained in section
9.
5.3
Software
The central hub will run software developed by the team, this was necessary in order to achieve the
desired functionality. Additionally, a Wi-Fi wireless local area network (WLAN) was created with the
central hub as the access point. Again, the team wrote the software on the hub so that when it turns on,
it creates a secure network and allows other devices to connect to it and start a server.
5.3.1
Server
The hub needed to run a server for the fitness devices to send data to and for the mobile app to connect
and receive data from. To achieve these connections, the hub will need to run a database on the server
and use a scripting language such as Personal Home Page: Hypertext Preprocessor (PHP) or JavaScript to
handle receiving and serving data to and from clients. There is free server software available that comes
equipped with all of these functions, such as a Linux, Apache, MySQL, and PHP stack (LAMP). Alternatively,
Mongo DB and Node.JS could be used. As such, the team did not have to write code to make a server, but
did have to develop code to make the server perform as desired.
40
5.3.2
Data Transmission Protocol
With the wireless protocol chosen to be Wi-Fi, there are two primary defined protocols that the team
could use: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Both use Internet
Protocol (IP) addresses and ports to indicate what device and program the packet is from and where it is
going. TCP is used as the basis for the Internet because it includes protocols to make sure that packets are
not lost. With TCP, a connection shall be set up between the two devices, an acknowledgement shall be
sent when data is received, and the connection shall be closed by both devices. UDP on the other hand,
does not implement any methods of making sure packets are received. It sends a packet and hopes that
it gets there. With this in mind, UDP is faster than TCP because it does not have to go through a three way
handshake, but it is more susceptible to data loss. TCP provides reliable communication, but the server
has to be able to handle many clients at a time if connections are kept open.23
The other option the team has is to define a transmission protocol to get a better balance between the
two. UDP could be used with part of the packet defining an acknowledgement and implementing retries
if an acknowledgment is not received, but the added complexity is not within the scope of the project.
Due to the reliability of TCP over UDP, the team decided to use TCP as the data transmission protocol.
5.3.3
Packet Processing
Packets will be stripped of headers as they go up the protocol stack until the application gets the data.
The protocol stack for this application starts with the link layer where the media access control (MAC)
addresses are stripped off. The packet is then passed up to the network layer where the IP addresses are
stripped off. Then the transport layer receives the packet and strips off the TCP header. Finally the
application layer and reads the Hypertext Transfer Protocol (HTTP) packet on port 8080 and performs the
request, whether that is inserting data into the database or sending data back.
6.
End-User Application
For a description of the details of the end-user Android application and how it will be integrated into the
system, please refer to the content below.
6.1
End-User Application Platform
This section will explore which application platform is most suitable for the team’s goals to display the
fitness tracking data. There are only enough resources for one application platform to be pursued, and as
such the team concluded that Android is the best platform to pursue as a part of the design.
6.1.1
Possible Solutions
The two platforms that will be compared below are Google’s Android and Apple’s iOS. The means of this
comparison is shown using decision criterion and a final decision matrix.
6.1.1.1
Apple’s iOS
Apple’s iOS is very popular and considered by some to be the elite operating system in smartphones.
BioBit could benefit by creating an iOS app. Apple has been in the smartphone business longer and often
apps are published to its app store and get updates first. Furthermore, apps that make it onto the app
41
store are required to be well refined and polished, which means that the developer must design to meet
these rules.
6.1.1.2
Android
Android devices are becoming increasingly popular and now control over 80% of the world’s market24 so
naturally this presents a good option for BioBit to pursue. Android is developed by Google and is
distributed as open-source. One reason it is so popular is that there are a wide variety of devices that run
Android with many different price points and features. This presents a challenge to the developer to make
sure that the app will run on a variety of devices with different size screens and capabilities.
6.1.2
Decision Criteria
The criteria below are the categories the team considers critical to choosing an application platform.
6.1.2.1
Usability
The usability of the operating system that is chosen is very important to the success of the project. Not
only does the team need to be able to develop an app in that operating system, but the usability on the
users’ side is also important. Android is developed using Java, which is very user friendly even if the
programmer has never coded in Java before. Android is open-source, which at times can make it easy to
use because there is documentation and it is customizable, but at other times more complicated and
difficult to use. On the other hand, iOS uses Objective C, which is quite different than the programming
languages the team members know and is more complicated than Java.25
6.1.2.2
Implementation
As the developers need to be able to design an app to use, the most crucial issue is whether or not such
an app can even be implemented. Furthermore, the ease of implementation is something that shall be
taken into consideration. Both Android and iOS are able to implement the desired functionality in an app
but Android is most likely easier to implement than iOS because of the programming language and the
rules are not as strict.
6.1.2.3
Customization
Both iOS and Android provide ample customization to the developer and the end user, but iOS has to
follow stricter guidelines than Android. Android is also much more customizable to the end user and there
is a wide variety of device specifications in Android that the developer needs to be aware of when
developing an app.
6.1.2.4
User Interface
The user interface would be the same for both Android and iOS. If both were used it would be ideal to
make the user interface and graphics look the same or similar on both operating systems for the sake of
consistency for users.
6.1.2.5
Cost to Enter Market
Both iOS and Android require a fee to make applications for their platform and put on their respective
app stores. With a limited budget, the team will look toward using the lowest cost platform.
42
6.1.2.6
Ease of Market Entry
Each platform also has its own route and requirements to get third party applications available on their
app store. The easier it is to develop and enter the market with an application the better the option it is
for the team to pursue.
6.1.3
Decision Matrix
From the criterion described in the previous section, a decision matrix was constructed, as seen in Table
5. Each criterion has its own weight that multiplies the ranking of the design alternatives being considered.
The weights are based on which criterion is considered critical to implementing the design with the given
requirements. The alternative with the highest summed total from each criterion is to be considered the
best solution.
Table 5 – Decision Matrix for Device Placement
6.1.3.1
Best Solution
From the above discussion, the team shall focus primarily on developing an Android application. If there
is time, it would be a good stretch goal to develop an iOS application because many coaches and athletes
use iPads and iPhones. If BioBit was going to market, an iOS app would be needed, but it does not fit in
the scope of this project to do both.
6.1.3.2
Recognized Weaknesses
While Android may be easier to implement, there are some weakness that will need to be addressed.
There are many different screen sizes and densities and the app shall be tested on many devices to make
sure that it is compatible with these differences but the team only owns seven inch Android tablets. This
was less than ideal for the team to develop from. The application can also be simulated using the Android
development environment, but the emulator is very slow and does not always work well. Due to the scope
of the project the team was unable to develop for different size screen android devices.
6.2
Software Design
A detailed description of the Android application software components and functionality are discussed
below.
43
6.2.1
Overview
This application is designed to be used by the head of the training session whether that is the coach,
fitness trainer, or a professor. It will be the final presentation of all data and status from the athletes
wearing the fitness devices. The application will provide easy navigation between stats and the biometrics
the fitness trackers are collecting. This Android application will be available to use on any Android device,
primarily targeting tablets.
6.2.2
Functionality
The main function of the application is to provide a user interface to the data being recorded in the fitness
devices. The application will be able to be filtered in two ways. First, the whole group can be viewed
showing the current heart rate and steps taken, as well as the team averages. The other way the data can
be viewed is looking at an individual. This will show more metrics on each player that is not logical to
group with the team metrics such as past heart rate levels and step rates.
6.2.3
Inputs
The inputs to the system will be the user’s touch and the data from the central hub as the application
updates. The user will have complete control of the application through the touch screen on the Android
device. The central hub will also send input to the application via Wi-Fi. These will be provided in the form
of data packets that the application will be able to decode and use to display updated information.
6.2.4
Outputs
The system’s output will be primarily in the form of what is seen on the screen of the Android device. The
two ways this data will be shown is as a team and individual data, as detailed in 6.1.2 Functionality. The
app will also send data to the server when the user creates a new player so that the proper rows and
tables are added to the database.
6.2.5
Software Updates
If there needs to be updates to the application they will be done as quickly as possible to fix the problem.
This will be done by uploading a patch or update to the Google Play Store, where the app was originally
downloaded from. The user will have to be connected to the internet via Wi-Fi or cell service in order to
access these updates. Once the update is uploaded to the Google Play Store, the user will receive a
notification prompting them to update the app.
7.
Physical Design Specifications
Along with the technical aspects regarding the implementation of the BioBit device, the physical housing
and design shall also be valued in order to provide the end-user a sleek and intuitive design. With this, the
BioBit looks to be compact, comfortable, light weight, and use minimal materials. It shall be compact as
the team looks to design with integrity, and not hinder the movement and performance of a user. Comfort
and weight are also driven from this viewpoint in order to provide an optimal product to the market. The
following subsections acknowledge these requirements set forth by the team in greater detail.
7.1
System Enclosure
The system enclosure section will describe the detailed information of the device such as the product
weight, placement, and the material selection for the device.
44
7.1.1
Wearable Design
Within the wearable design sub-sections, a discussion of the design decisions for the wearable device can
be found. This includes the evaluation of product weight and physical specifications.
7.1.1.1
Product Weight
When determining weight, a comparison to similar devices on the market was taken into account. Because
of this, a range between 26g (0.92oz) and 37.9g (1.34oz) was found to be the acceptable weight for fitness
wearable devices. However, without the funding, time, and man-power to achieve such a minimal weight,
the team has left the requirement to remain above the market average. With these set guidelines, the
design of the BioBit will not only be driven for technical capabilities, but also restricted for the weight of
the components in respect to the material chosen.
7.1.1.2
Physical Specifications
The physical specifications are concerned with the comfort and location when fitting the apparatus to the
end-user. This device, no matter how sophisticated and efficient, will not be accepted by the customer
unless it fits a physical requirement of fit and comfort. A chest mount, waist clip, and wrist-wearable were
considered. Of the different organizations and individuals who participated in our survey, twelve noted
they would prefer the wrist, while eight liked the idea of a waist clip and five noted they would desire a
chest mounted device. The final design was that of a wrist mounted wearable.
7.1.1.3
Wrist Mounted Device
The potential consumers identified a wrist wearable as the most desired device type to wear on the body.
In this location, the majority of motion and functions are not interfered with, while also being readily
viewable and accessible to the user. The complications which come from the design are size and weight.
Along with that, the sensing ability of counting steps is significantly harder considering the swinging of the
arm, which causes noise in the signal. However, with this placement being the most desired application,
the team is chose to move forward with design and implement into the final product. Because of this,
additional detail is required in the chosen design; multiple perspectives of the official prototype can be
seen below in Figures 24-27.
7.1.2
Material Selection
In coordination of minimizing weight and maximizing comfort, the design is to mainly be constructed of
plastic. Taking advantage of the 3D plastic printer available at Calvin College, an ABS plastic will be used
to build the main body of the wrist-mounted device. The design will also take into account the necessary
void space for electronic components. In short, plastic will be used from the printer available, with minimal
alternative materials in order to properly house the electronics and operate the device.
7.1.2.1 Resulting Prototype Housing
The result of the team’s prototype housing, as seen in the following figures, is simple due to the limitation
of time and man-power to deliver a sleek and minimalistic design. However, given the parameters,
resources, and time constrains, the resulting prototype provides all functionality and services as outlined
in the design constraints and requirements.
45
Figure 24 – Front View of Wrist-Mounted Housing
Figure 25 – Top View of Wrist-Mounted Housing
Figure 26 – Side View of Wrist-Mounted Housing
46
Figure 27 – Trimetric View of Wrist-Mounted Housing
7.1.2.2 Potential Refined Housing
Given additional resources and time, a potential refined housing design could provide a much more
slender and efficient wearable device. This would include compressing the footprint of the circuit boards
by printing circuit boards and customizing the dimensions to the products design. While the team was not
able to provide such a prototype due to the previously mentioned constraints, it certainly does have the
vision to continue refinement and efficiency beyond the given time.
Figure 28 – Potential Wrist-Mounted Concept View of Face
47
Figure 29 – Potential Wrist-Mounted Concept Right Side View
Figure 30 – Potential Wrist-Mounted Concept Side View of Wrist Strap
48
Figure 31 – Potential Wrist-Mounted Wearable Concept Wire View
8.
Prototype and Deliverables
This section will discuss the prototype the team will be constructing and will outline the deliverables from
the project.
8.1
Final Prototype
The final prototype's design has been outlined in the previous sections. The prototype was ready and
functional by the time the team presented on the Senior Design Project night held on May 9, 2015. The
prototype consisted of 2 fitness devices communicated with a centralized hub and an Android app that
was able to interact with the system.
8.2
Deliverables
The team provided a wide array of deliverables throughout the project including reports, presentations,
a website and prototypes. A breakdown of what was provided by what dates is located in Table 6.
49
Table 6 – Project Deliverables and Timeline
Deliverable
Presentation 1
Date
Oct 17, 2014
Presentation 2
Dec 3, 2014
Website
Oct 22, 2014
Team Poster
Oct 31, 2014
PPFS
Dec 8, 2014
Detailed Business Plan
Dec 8, 2014
Presentation 3
Presentation 4
Final Prototype
Mar 2, 2015
May 4, 2015
May 9, 2015
Final Presentation
May 9, 2015
Final Report
May 13, 2015
8.2.1
Description
Introductory presentation to provide a broad overview of
problem, solution, and design norms; 6 minutes followed
by Q&A.
Second presentation to reintroduce project, includes
current status, scope redefinition, and feasibility; 7-9
minutes followed by Q&A.
Team dedicated website used to post updates, documents,
and give a general overview of the project.
A poster that gives a quick overview of the team and
project design.
Defines the project proposal and the feasibility of the
project, it details things like system design, design decisions
made, management, and budget.
This document is made in conjunction with senior design in
BUS-357 to outline a business and financial plan as if this
project were to become a profitable business.
The third presentation of the project giving a status update.
The final in-class presentation of the project.
The deliverable prototype that will be on display on Senior
Design Night.
A presentation given on Senior Design Night about the
overall project.
Final report of the project, which will include portions of
the PPFS, design details, progress details, and other
updates.
Fall Semester Deliverables
The first and most important deliverable of the fall was the PPFS. It is the document that defines the
problem, outlines the design decisions and solution, and details the feasibility of the project. Other
deliverables that are available via the team's website are the first two presentations along with the team's
poster. In order to access these deliverables please visit the team's website at
http://www.calvin.edu/academic/engineering/2014-15-team10/ .
8.2.2
Spring Semester Deliverables
At the culmination of the design the team is delivering a single Android app, a single hub (Raspberry Pi),
and two wearable devices. With this the team was able to design a prototype of the system to prove that
a design such as this is feasible and viable for years to come. Similar to the fall semester, the team has
posted all relevant documentation to their website found at the aforementioned link.
50
9.
Testing
The testing section is intended to verify and point out any potential shortcomings in the design in
comparison to the aforementioned design specifications. To view an explanation of the testing procedures
performed, setup, results, and analysis, please see the content herein.
9.1
Feasibility Testing
During the fall semester of 2014, the initial testing on the Raspberry Pi was carried out. A server and a
database were run in order to check its capabilities and functionality. This test was completed in
conjunction with the team's Computer Architecture and Digital Systems Lab.
9.1.1
Raspberry Pi
The Raspberry Pi was used to host a server and run a database. The server on the Raspberry Pi was run by
an Apache webserver. An Apache HTTP server is the most common webserver software used. This
webserver ran a MySQL database that was controlled via the web using phpMyAdmin software. This
software provided a GUI that made it possible to set up the database in MySQL. The Raspberry Pi's server
hosted a webpage that gave the ability to manually enter data into the database and displayed all of the
data entries. The webpage was written in the PHP and HTML. These languages can interact easily and they
are widely used in web-based applications.
The testing results were encouraging as the Raspberry Pi was set-up as a server and database easily. This
proves that a Raspberry Pi will be a good solution for our central hub. The Raspberry Pi also allows for
external storage expansion which will most likely be needed for the database.
9.2
Prototype Testing
The team outlined a number of tests to complete during the prototyping phase of the project. The tests
revolve around achieving communication, data transfers between components in the system design, the
ability to meet the requirements noted in Section 2, and final prototype functionality.
9.2.1
WLAN on the Raspberry Pi
The central hub has the requirement to set up its own wireless local area network (WLAN) for the devices
and the mobile app to communicate on. A plug-in Wi-Fi dongle was plugged into the Raspberry Pi and
software was written to set up the hosting services to assign and communicate with the wearable devices
via IP addressing (DHCP). This was attempted in conjunction with the first test of the Raspberry Pi when
a server and database were set up.
9.2.1.1
Setup
In order to simulate a number of devices on the network without enough physical hardware to construct
numerous wearable devices, the team created a simulation via an executable file that was able to run on
standard Windows operating system computers. Given the resources on hand at the time of the test, a
total of ten devices were used to simulate a test for connection of the devices to the Raspberry Pi via the
wireless local area network.
51
9.2.1.2
Results
As a result of this test, the system handled the traffic of device connections without interruption or error.
The devices connected in this test varied between the two BioBit devices and eight laptop computers
running Windows.
9.2.1.3
Analysis
Analyzing the test provided conclusive and constructive results. While the team would have liked to
review more than ten devices for the system test, there were not enough devices on hand to expand the
sample size. The system was setup to handle up to 30 devices when using DHCP to assign IP addresses.
Based on the system being setup to handle more than the required 22 devices and the sample test
returning results without any errors, the team feels comfortable that this requirement was met.
9.2.2
Send Data from Pulse Sensor to Arduino Pro Mini
The Pulse Sensor has one analog input to the Arduino Pro Mini. This data is a voltage reading from the
light detector on the Pulse Sensor. This analog voltage can be graphed using software given by the
manufacture of the Pulse Sensor. It is important to determine the accuracy of the data being transmitted
and verify that the beats per minute (BPM) calculation is correct.
9.2.2.1
Setup
The Pulse Sensor was paired with an Arduino program and Processing software provided by the
manufacturer as open source. Once the Arduino program was uploaded to an Arduino and the needed
pin connections were made, the Processing program was run. This gave an output of the analog signal in
the form of a graph and showed the calculated BPM. The accuracy was checked first by physically feeling
for a heartbeat on the body and making sure each beat was recorded by the program. Then a secondary
heart rate device was used to check the accuracy of the code’s calculation.
9.2.2.2
Results
The Processing software worked as advertised and output the data seen in Figure 32. The figure shows a
nice graphical representation of the analog reading coming from the Pulse Sensor which is processed by
the Arduino. The BPM calculation was correct based on the comparison from the secondary heart rate
device. The Processing program also had a visual heartbeat, where the heart in the top right corner would
“beat” when a heartbeat was determined, which made the physical test of making sure each heartbeat
was read by the program easy.
52
Figure 32 – Screenshot of Processing Program to Test Pulse Sensor
9.2.2.3
Analysis
The results from this test showed that the sending of data from the Pulse Sensor to the Arduino is easy to
implement and the data is reliable. This is an extremely positive result as this confirms the decision to use
the Pulse Sensor and allowed the group to further the Pulse Sensor’s integration into the design. Because
the Pulse Sensor would not be used on the athlete’s finger, as it was tested here, the team would have to
make sure it would achieve the same results when the Pulse Sensor is integrated into the final prototype
design. The sensor was found to be functional on the top of the wrist where the prototype would be
mounted.
9.2.3
Data Accuracy of Pedometer
With the accelerometer and gyroscope on the MPU-6050, this gives the team six possible degrees of
freedom. But for the step counter the team developed, only the accelerometer was used. This meant that
only the accelerometer’s x, y and z axes were used in the calculation of a step. Because the algorithm used
in the counting of a step was taken from an open source on the Pebble Watch company website, it was
important to check the accuracy of the step counter along with testing the communication between the
MPU-6050 and the Arduino Pro Mini.
9.2.3.1
Setup
Before the test could take place, the accelerometer was attached to the Arduino and tested to make sure
it was sending reasonable data from each axis. This was done using source code26 found on Arduino’s
website. After the data was verified the accuracy of the step tracking algorithm was able to be tested. The
MPU-6050 board was implemented into prototyped fitness tracker. It was very important to get the
placement of the board just right because the orientation of the board is crucial when adjusting the axis
sensitivity in the algorithm. Once the board was communicating data successfully, the team conducted
tests of physically running a certain amount of steps and checked it against the output of the fitness
53
device. This was done iteratively and the sensitivity of the axes were adjusted based on the most recent
test.
9.2.3.2
Results
After testing, the team ended up with values for the calculations that gave reasonably accurate results.
When tested by running around a 200m track, 163 ± 2 steps were counted and the wearable device
calculated that 161 steps were taken. This is an error of 1.2%, which the team found to be acceptable.
Similarly, over shorter distances, such as 10-40 steps, the device was off at a maximum of three steps.
While this is a larger error percentage, the team found it to be acceptable because it still gave the coach
a general idea of how far players had gone.
9.2.3.3
Analysis
As the results show, the algorithm to track steps taken is not as accurate and reliable as it could be, but
this could be improved with further testing and tweaking of values. The results the team obtained were
acceptable, but with more time would be further improved. The team found that the x and y axes were
more sensitive than the z axis. This makes sense because according to the placement of the accelerometer
in the wearable device, the x axis is perpendicular to the arm, the y axis is parallel to the arm, and the z
axis is normal to the arm. During a normal running movement, the arm moves mostly in the x and y
directions, but very little in the z direction.
9.2.4
Send Data from Database to Mobile App
Once the team had a basic functioning app, a test to prove that data could be sent from the central hub
to the mobile app was successfully performed. This test was part of the critical path because it allowed
the design of the app to be continued. It marked a point where the app could move from basic functions
to aesthetics and displaying the data from the server appropriately.
9.2.4.1
Setup
On the server side of the test, a php file was written that would access the Current_Values table from the
MySQL database and return the entire table encoded in JSON format. JSON encoding was chosen to send
the data to app because it allowed the app to easily extract the various values. The app was programmed
so that when an activity was opened it would start an asynchronous task that would request data from
the server. This task used a built in HttpClient class to send a GET request to the server and access the php
file that would send back the table. When the data was received, it would print out the string in the debug
monitor to show exactly what was being received and if it was correct. The task then stored this string as
a JSONArray and iterated through each row to extract the data. This information was then printed out on
the screen by row to show that the data was being processed properly.
9.2.4.2
Results
Through this process, the server sent the correct information to the app using JSON encoding and the app
was able to receive this data and extract the values from it properly. The data in the debug monitor was
correct and the data displayed on the app was correct as well.
9.2.4.3
Analysis
As this test showed, the process of retrieving data from the server is functional. Furthermore, the latency
was so small that it was not noticeable, making it suitable not only in terms of data reliability but also
speed. As a result, this process was applied to every other transaction between the server and app. Each
54
of these transactions were tested with a similar process and they all showed the same result of correct
sending and processing of data as well as unnoticeable latency. This test gave certainty of communication
and allowed the app to move on to displaying data in aesthetically pleasing and useful ways.
9.2.5
Fitness Device Power Consumption Test
It is important to understand and calculate the power consumption of the fitness device because it will be
powered via a LiPo battery. This test should give a rough estimation of battery life and give an insight to
the power consumption during the program data sending cycle. Current measurements were recorded
during the data transmission cycle, or the period between data packets being sent to the server. At even
intervals the data was recorded and placed into an excel file. From the data, calculations were used to
find the output and a graph over time was the result.
9.2.5.1
Setup
A multimeter was placed in series with a power supply used to emulate the battery that will be in the final
design. The multimeter was set to read out the current consumption as the power supply powers the
fitness device on a breadboard. The Arduino program was run and a video was taken of the multimeter
and the Wi-Fi module. Once the video was taken the video was broken down into half-second screen shots
and the multimeter reading was recorded into an excel file. The Wi-Fi module was used to indicate when
data was being transmitted via an onboard blue LED.
9.2.5.2
Results
The average data cycle is about 10 ± 2 seconds based on how quickly the device makes a connection with
the server and transmits data. Using this data the average current consumption over a 10 second data
cycle was found to be 36.2mA. The current consumption spike when the Wi-Fi module made a connection
to the server and when the data was transmitted had max currents of 70mA and 90mA respectively during
those times. A graph of the results can be seen below in Figure 36.
Current Reading (mA)
Current Consumption Over 10 second Data Cycle
100
90
80
70
60
50
40
30
20
10
0
Connect to Server
Data Transmission
Average Current
Over Data Cycle =
36.2mA
Current
(mA)
0
2
4
6
8
Time (seconds)
Figure 33 – Current Consumption Results
55
10
9.2.5.3
Analysis
Considering the team decided to use a 400mAh battery for the fitness device with an average current of
36.2mA this gives an estimated battery life for the fitness devices of 11 hours. This estimation is
considered to be high as the test was conducted under an ideal situation on a breadboard, about 5 feet
away from the central hub, and powered via a power supply. But this estimation does help in confirming
that the fitness device should meet the required minimum operating time. The graph also confirms our
hypothesis that data transmission and connecting to the central hub is the most power consuming aspects
of the fitness device.
9.2.6
Battery Test for Fitness Devices
The team selected a single-cell Lithium Polymer battery at 3.7 volts and 400 milliamp-hours for on-board
power of the wearable. The purpose of the test was to determine both the run time of the battery at
operational power consumption as well as the recharge time from total depletion to a full charge.
9.2.6.1
Setup
The setup, while simple for this particular test, was important to track accurately in order to provide
correct information to the end-user if they can indeed make it through a practice on a single charge.
Additionally, it is important to note the recharge time in order to ensure that the device is ready prior to
the next practice session of the device being used. In order to do this, we simulated a player using the
device and sending the data to the database. The reason this simulation was performed was to maximize
the power load on the battery throughout the duration to simulate a real situation of use, as well as when
sent to the database the data is able to be time-stamped. Given the time of the first data time stamped
in the database and the last, the team can then verify the total life time of the battery on a single charge
at maximum load. This information was then viewed through using the PHPmyAdmin interface setup on
the Raspberry Pi and accessible through the device IP address.
9.2.6.2
Results
Upon reviewing the test, a player was simulated as ‘Charlie’ and the data timestamps were noted. As seen
in the figures below in Figure 34 and Figure 35 the start and end times can be seen.
Figure 34 – Test Started 10:55:17 PM
Figure 35 – Test Terminated 10:31:19 AM
56
9.2.6.3
Analysis
The results showed that a single run time of the battery is 11 hours and 36 minutes and had 3,865 data
transmissions in the process. This averages out to 5.5 data transmissions per minute, which confirms that
the system was running the simulation for the full duration as the data is uploaded to the server roughly
every ten seconds.
9.2.7
Server Traffic Test
Another test that was completed was one to verify how much traffic the server set up by the Raspberry
Pi can handle. If the server cannot handle the traffic requirement of 22 devices then the team will have to
find a new alternative to handle the traffic.
9.2.7.1
Setup
Given the lack of materials needed to construct 22 wearable devices, the team decided to run a simulation
that behaved much like the wearable with respect to the communication with the server. This was done
by writing an executable test simulation of a player that transmitted random data (within reasonable
ranges) to the server every ten seconds, much like the actual wearable device does during operation.
9.2.7.2
Results
Upon running 25 of the executable files, which appeared as unique and independent devices to the server,
the simulation performed with success. These simulations were left for several hours in an attempt to try
to overload the database and max out the memory allocated for the system (5.2 GB). As a result, no errors
were found once again as the team never achieved full capacity of data within their database system on
the Raspberry Pi; in fact all the data only used less than 2 Mb of memory. All server traffic requirements
were met as the requirement of 22 devices was exceeded.
9.2.7.3
Analysis
As a review of the test performed, the design team is satisfied that the system was able to handle more
traffic of the server than required. However, given this achievement the group would also be curious how
many devices would able to handle before crashing. Given more time, this could easily be as it would only
require running more executable files to send data to the server via the WLAN and transmitting data every
ten seconds.
9.2.8
Wi-Fi Range Test
In order to ensure that the final prototype met the requirements, a test of the range of communication
over Wi-Fi was completed. The team needed to make sure that the wearable devices would be able to
communicate with the central hub over a range of 90m to ensure that it would cover a soccer field.
9.2.8.1
Setup
This test included a test indoors and outdoors. The central hub was plugged in at the location and allowed
to boot up. The wearable devices were turned on and verified that they connected to the network and
were properly sending data to the server using the app. Then one of the team members walked away
from the central hub in a straight line with a surveyor’s wheel to measure the distance. The test started
at 100ft and the person with the wearable device would wait until another team member with the app
verified that the central hub was still receiving new data. Then the distance was moved 20ft further and
57
the process was repeated until the hub no longer received data. The distances were then converted to
meters to compare to the requirement.
9.2.8.2
Results
The outdoor test resulted in a loss of communication at 180-200ft or 54.86-60.96m. The indoor test
resulted in communication out to 300ft or 91.44m. A diagram of the resulting ranges can be seen below
in Figure 37 with respect to a soccer field and the required range.
Figure 36 – Range Test Results
9.2.8.3
Analysis
This range test showed that outdoors the range of the prototype is not sufficient to meet the requirement
of 90m; in fact it is only about two thirds of the requirement. However, when used in doors, the devices
are able to communicate over a range greater than the requirement. These differences are due to the
increased reflectance off of walls and ceilings indoors whereas signal is lost and spread out more when
outdoors. In order to improve the range outdoors, a better antenna with a longer range would need to be
used on the central hub.
58
10.
Business Plan
The outline of the business goals and the details of how the company plans to achieve financial success
are described herein. Company values, industry profiles, competitor analysis, and regulatory restrictions
are also included below.
10.1 Vision and Mission Statement
The company's vision, mission statement, values, and principle are the building blocks of the company’s
success and are discussed below.
10.1.1 Entrepreneur's Vision and Mission Statement for the Company
The vision of BioBit is to become a standard in group workout sessions by supplying a need through
innovation, while remaining competitive and relevant. The mission of the company is to make a reliable,
yet cost effective product.
10.1.2 Values and principles on which the business stands
BioBit values team work, honesty, efficiency, and sustainability. The company also strives to develop a
design team that is established under the principles of integrity, stewardship, transparency, and caring.
BioBit guarantees the information our devices provide the users to be clear and concise, with a simple
and user friendly interface.
10.2 Industry Profile and Overview
Within the industry profile and overview, the major customer groups and market sectors are identified.
With this, BioBit found that the best market to enter includes trainers, coaches, and for academic research
concerning gathering of human biometric data.
10.2.1
Industry Background and Overview
The sophistication of data compilation and analysis has certainly seen major growth in the past century
as electronics and automation have quickly dominated a large spectrum of markets. Specifically, the
market of athletics and training has shown their need for technological advancements in order to better
understand biomechanics and conditioning of athletes and trainees. That being said, BioBit looks to fill a
void in this market by allowing a team or training group to compile and analyze data as both a single unit
and individually.
10.2.2
Major Customer Groups
BioBit will be marketed towards two major customer groups, first being trainers and coaches who could
use our product in their practice and training sessions. The second major customer group the field
academic research.
10.2.2.1
Trainers and Coaches
Both trainers and coaches would look to utilize the device as a tool to give to their workout participants
and players. By doing this, they would be able to compile and analyze data on a real-time basis in order
to be able to make educated and quick decisions when regarding the output of the individual. By allowing
trainers and coaches to have this information readily available, the participant is the benefactor, as their
59
performance may be maximized by using this device. These types of customers would be looking for high
reliability and precision in a device such as this.
10.2.2.2
Academic Research
In an academic application, researchers and professors would look to utilize device in human performance
labs and classroom settings. By allowing these types of customers to use BioBit, there is another avenue
to explore the exercise sciences. Because BioBit can be used in both individual workouts and groups
settings, the end-user would be able to analyze the effects and differences in different types of workout
settings, a dynamic that has seen minimal research thus far.
10.3 Regulatory restrictions
For customers looking to use BioBit in research or training applications, there are no known restrictions
or regulations. It shall also be noted however, the safety and health of the individual shall be held
prominent. The regulations and restrictions are established when a coach is looking to use the collection
of devices with their team, depending on the level of competition in which they participate. The National
Collegiate Athletic Association (NCAA) states that no wearable technological device may utilized in a
competition setting in which to provide a particular party an advantage in performance or disclosed
knowledge. These regulations are also upheld by most state high school athletic associations. That being
said, BioBit is intended, by its designers, to be utilized by the end-user in practice and workout settings.
By having this regulation established, devices can be designed and marketed knowing the end application;
not to be used in competition settings.
10.4 Significant Trends
Currently, the wearable technology market has quickly grown into an application for a single user in order
to monitor themselves for both workouts and leisure. Current products which fall under the classification
would include, but are not limited to, smart watches and sports bands. The increasing market value has
shown that there has been significant growth in the past decade as the retail market value has increased
ten-fold in less than four years27. Because of this, users have shown that they are willing to pay high prices
for devices similar to BioBit, so the value and market need for an item like BioBit certainly exists, and this
is where BioBit looks to thrive and capitalize within the market.
10.4.1
Growth Rate
Because the wearable technology market is growing so quickly, current manufacturers are challenged by
staying up-to-date and unique. With growth in the number companies and device types in the market, the
price of each unit has also grown 20% in the past four years, providing insight that individuals are willing
to pay for better technology even if that means it is at a higher cost28 .
10.4.2
Barriers to Entry and Exit
A variety of barriers may prevent new companies, such as BioBit, from entering the wearable fitness
technology market. Because wearable technology devices can quickly grow in sophistication and price,
the priority to provide the greatest value for the lowest price possible is crucial in order to compete on a
retail level. Dealing with electronics and wireless networks also increases the detail required for design
and manufacturing of such device. This too can exist as a potential barrier to a company looking to enter
the market, as the cost of a startup would be large and difficult to overcome without a predefined
60
strategy. New companies may also have a tough time becoming a known participant in the marketplace
as this takes both time and money to become established and respected among customers and
competitors.
10.4.3
Key Factors for Success in the Industry
The key to success for a business in the fitness wearable technology market is to be able to compete in
two distinct ways. A business can become successful when they compete on both cost and differentiation.
The customers for these types of devices are looking for an intuitive and sleek design so as to minimize
hindrance while receiving unique and valuable information that may not be otherwise obtainable.
However, these factors quickly become obsolete when the cost of the product cannot compete within the
marketplace. Because of this, the company will look to excel at both performance and value with their
final deliverable product to market.
10.4.4
Outlook for the Future
Moving forward, the market looks to continue its trend of rapid growth in sales and diversify its product
line. The cost for components and size of units will decrease, while reliability and accuracy will continue
to be refined. When projecting towards the future, researchers expect a growth of 1,000% in retail market
value of wearable technology over the next four years29. This trend is estimated to continue through the
year 2025, upon which, the market will see more of a plateau and stabilize itself with price points and
growth.
10.5 Business Strategy
The subsections following describe BioBit's desired image and position in the market, along with the
company's goals and objectives for its operational and financial characteristics.
10.5.1
Desired Image and Position in Market
The desired image of the company is to produce a quality fitness wearable with a low cost that will be
focused towards helping coaches, sporting teams, and group-performed the exercises. With these
identified customers, BioBit will look to establish a reputation of honesty, reliability, and excellence. This
reputation will be prominent through the ability of the devices to track biometric data and the
accompanying android app, which can provide real-time data in a clear and concise manner.
10.5.2
Company Goals and Objectives
This section describes the operational and financial goals of BioBit.
10.5.2.1
Operational
The operational goal of the company is to bring an ethic of teamwork with efficiency, sustainability,
integrity, stewardship, and caring to the customers who will use the product. The product shall be
designed in such a way to provide maximized quality and minimized cost.
10.5.2.2
Financial
The financial goal of the company is to use the first generation design to make enough profit to repay
both the startup loan and reinvest in the company’s future. BioBit will be financially aggressive when it
comes to paying off its start-up debt. This will help reduce the risk for the company and the employees in
61
the unfortunate circumstance of economic instability. Once BioBit has its debts taken care of and starts
seeing a profit, the company plans to expand the brand and potentially increase the product diversity but
this will be done in financially responsible means so as to stick to the company’s value of sustainability.
10.6 SWOT Analysis
A SWOT analysis is a study undertaken by a company, in this case BioBit, in order to identify its internal
strengths and weaknesses, as well as its external opportunities and threats. The practice of this analysis
in regards to the company’s specific characteristics is identified below. The advantage for doing an analysis
such as this is to maximize operational and financial success through self-awareness.
10.6.1
Internal Strengths
The major internal strength of the company is its leaders; they are people who strive for quality and to
meet the needs of customers. They are aware that the quality of work they complete reflects them and
the company’s image. Every team member is dedicated to seeing the company succeed and have financial
responsibility for the company’s success due to their own monetary investment in the company. Another
strength is the product itself. The product will be of the highest quality while maintaining a low cost, which
creates a reputation in the marketplace of a well-engineered product.
10.6.2
Internal Weaknesses
There are several weaknesses that shall be addressed when marketing the product. One weakness is the
limited target market. Because of this, the company shall aggressively market the product. A second
weakness is the lack of experience in marketing and minimal name recognition. Since the company is a
startup, the sales representatives will need to show strong confidence in the company’s products and use
both the rapidly growing market and customers in order to win further business in place of its direct
competitors.
10.6.3
External Opportunities
First and foremost, the company hopes to move into a marketplace that is under-developed. By starting
off on a small scale, a team-oriented fitness device can exhibit high quality features and performance
while still retaining a value price in order to compete with larger, mass-producing companies. With the
wide popularity of sports and the increasingly competitive nature between teams, coaches will be looking
for innovative ways to improve their team. This is a golden opportunity for our company to promote our
product. This opportunity is mirrored in the fitness industry, in the last few years the role influence of
fitness a human’s health has seen a dramatic increase and BioBit could capitalize in this market.
10.6.4
External Threats
An external threat to the company is when competitors see the opportunity BioBit is exploring, and will
attempt to make a similar product with a comparable price point. This, in turn, may reduce the company's
profit margin and force the company to sell at a lower price. Furthermore, a threat may exist if companies,
both old and new, were to start integrating this sort of functionality into their smart watches. Especially
as many established companies have smart watches that already have the capability to detect heart rate
and steps taken. To reduce this threat, our company will sell the product with the lowest possible price
point, thus maximizing value.
62
10.7 Competitive Strategy
BioBit plans to stay competitive in the fitness tracking market by differentiating itself from similar
competitors and providing a low-cost solution to fill market needs. BioBit will also have a focus on
marketing to build a customer base. For further details please see the corresponding sections below.
10.7.1
Cost Leadership and Differentiation
The company plans to compete using both cost leadership and product differentiation. The company is
looking to generate its own niche in the market by selling the product with a lower price range than what
is not currently covered by other competing companies. The company is not planning to compete with
the existing higher-quality systems in the market, but is looking to have comparable quality to mid-range
products. On the other hand, the company is planning to provide lower prices than competitors and offer
the best value products to the market.
10.7.2
Focus
The focus of the company is creating a quality product with a low cost. Currently Polar, BioBit’s main
competitor in this market, provides an expensive solution for team-oriented fitness tracking. The company
hopes to find a niche in this price range gap while providing a quality product. Most importantly, the
company will focus on marketing to build trust with the customers and continue competing in the market.
Once the company has a returning customer base it can use this leverage to get into other markets and
build the BioBit brand.
10.8 Company Products and Services
BioBit will begin by selling one product in the form of a package of fitness devices, a central hub, and
access to the mobile application. The subsections below will go into detail about the company's product,
the services offered, and some of the benefits that go along with it.
10.8.1
Product Description and Service Features
BioBit’s flagship product will be a fitness tracking device worn on the wrist. The devices will provide
coaches and trainers to view real-time data from the player’s devices. These devices will track biometrics
such as heart-rate and steps taken. The data will be displayed on an app that the coach or trainer can filter
and look at their desired statistics along with previous logged sessions.
The baseline package that will be available on the market will include 15 fitness tracking devices, 1 central
hub, and access to the mobile application. This baseline package is customizable based on the number of
devices the customer desires.
10.8.2
Uniqueness
BioBit will differentiate our product from our competitors’ by creating a package of group-oriented fitness
trackers compared to personal fitness trackers. Most fitness trackers currently in the market are for
personal use only and link up to an app on the person’s phone when there is a Bluetooth connection. Our
system will do everything a personal fitness device can do and have the advantage of evaluating the
grouped data in one location. BioBit also allows the user to not be required to be within communication
distance of a phone, as many athletes typically do not have their phone on them when they train.
63
10.8.3
Customer Benefits
Not only will BioBit offer our customers the benefit of improved fitness information and analytics, but
BioBit will also give additional benefits to returning customers. These would include offers such as
discounted pricing, early availability of new products, along with opportunities to be involved in beta
testing.
10.8.4
Warranties and Guarantees
BioBit will come with a limited warranty. This warranty will cover any issue that arises with the product
that is determined not to be a customer related issue but is an issue with how the product was designed,
fabricated, or assembled. This warranty will not account for any abuse of the product or if it becomes
dysfunctional from being used outside of the directed method. Customers will be given updates to the
software of the tracking device and frequent updates to BioBit’s tracking app. If there is a design flaw in
the product, BioBit will guarantee a quick product replacement or a full refund.
10.8.5
Future Product or Service Offerings
BioBit has plans to extend its reach into the fitness tracking market by offering other products that include,
but are not limited to, a personal fitness device, variations on the group-oriented device, and equipment
integrated fitness trackers. The knowledge that BioBit accumulates from making a group-oriented fitness
tracker will make it very possible for BioBit to enter the personal fitness tracking market. It is also a goal
of BioBit to be able to make a customizable tracker, so the customer can track whatever data they desire.
This could be achieved by getting BioBit to a price point where it can include all desired sensors. Another
market BioBit would like to implement technology into is activities that are not currently explored such as
football or hockey. These trackers could be placed in the chest pads or in the helmet depending on the
activity it is used for.
10.9 Marketing Strategy
This section will describe the goal of increasing sales and achieving a sustainable competitive advantage
of the company. With this strategy, the company may be able to approach the market with a specifically
designed tactic in order to set themselves up for the best opportunity to succeed. To view the details of
this approach and the various components taken into account, please view the content herein.
10.9.1 Target Market
10.9.1.1
Problem to be Solved and Benefits to be Offered
The problem that BioBit is trying to solve is to make a team oriented fitness device. The majority of the
market currently offers individual devices, which do not typically offer much variety for the user to select
what type of data to track. The company’s focus will primarily be on customers for sports teams, coaches,
and people who work out as group. This device will give the customers efficient access to their data in an
intuitive android app.
10.9.1.2
Demographic Profile
BioBit’s market demographic profile includes coaches, trainers, athletes, and educational research labs.
Coaches and fitness trainers will benefit the most from this technology as they will be able to make
adjustments real time in their sessions. They will be able to see how the group is doing as a whole and see
64
who needs to work harder during the sessions. Athletes benefit from this system as they will be able to
see their progress form session to session. Finally, educational research labs can use this system to
conduct scientific research for the application being researched.
10.9.1.3
Other Significant Customer Characteristics
The significant customer characteristic of BioBit’s product is that the unit can be used in a group setting,
thus connecting multiple customers to the same network. This provides the opportunity for a cohesive
and collaborative environment giving an advantage for easily comparing and monitoring multiple
individuals on a single interface.
10.9.1.4
Customers' Motivation to Buy
The main motivation for customers to buy BioBit’s product is for athletic benefit as individuals and as a
whole and better team fitness analytics. The customer would be motivated to buy a device that is teamoriented with the same capabilities and efficiency of a larger, mass-producing competitor. The customer
can track their data as a team and will be able to access that data at anytime, anywhere. These capabilities,
that are not readily available on the market, make BioBit’s product valuable to the customers.
10.9.2 Market Size and Tends
10.9.2.1
Market Size
The advantage of entering the fitness tracking device market at this time is that it is growing at an
exponential rate from year to year. As the company grows, the market will certainly accept whatever
product line is available as the demand and excitement for these types of product are only increasing for
the years to come. With the focus leaning heavily oh high school and college athletics initially, expansion
into professional and private fitness groups can be explored as a second wave of marketing. The reason
BioBit is looking to focus on a smaller demographic initially, is so that the demand does not outweigh what
can be supplied. As integration of a full production line and operation is optimized, the marketing into
larger sectors will be of high interest to the long-term success of the company.
This identified plan within BioBit correlates with how other similar companies have entered the market.
As personal fitness trackers did not catch on until they were well established in the market, the majority
of sales took off eight months after the device had been introduced.30
10.9.2.2
Rate of Growth
As the implementation of team-oriented fitness trackers into the market is still occurring, much of the
market comparison and research was done in the personal fitness tracking devices sector. When looking
at the personal fitness device market, multiple sources are forecasting that the retail value is to continually
grow 1000% by 201831.
10.9.3 Advertising and Promotion
10.9.3.1
Message
The primary message that BioBit wishes to deliver is simply its vision and purpose. BioBit wants to be
known as an innovative company that is delivering the next-generation of fitness devices that center
around teams. Quality and integrity are a part of that message and help convey a sense of trust in both
the company and its products.
65
10.9.3.2
Media
In the first year of the product being on the market BioBit use online and social media as its primary means
of promotion. This is best option due to budget restrictions, as they tend to be cheaper than print or TV
advertising and will be one of the best ways to reach out to the target market. Further into the BioBit
brand, when the budget for marketing has increased, the team will explore any and all options of
advertising in order to expand BioBit’s reach.
10.9.3.3
Budget
As explained in detail below within the financial cash flow section, BioBit views the advertising and
promotion of both the company and its product line very seriously. This is due to the fact that establishing
a presence and maintaining a good reputation among competitors is pivotal to a company’s success,
especially upon the startup of a product line. Because of this opinion, BioBit has chosen to allot $100,000
annually towards the marketing and advertisement of the company and its products. This equates to 16%
of the company’s total annual fixed operating costs.
10.9.3.4
Plans for Generating Publicity
The biggest way that BioBit plans to generate publicity is by showcasing and demonstrating the products.
This will help the company create a buzz about the features and abilities of the product. On top of this,
BioBit will use social media to connect with people, share product demos, and get feedback on the product
design.
10.9.4
Pricing
The pricing for a single unit is dependent on the quantity the company is able to sell annually as well as
the cost of materials and operation. Because of this BioBit intends on offering a single unit for sale for
$13,949.14 the first year, $5,954.17 the second year, and $3,155.94 the third year. It is at these price
points that the company must sell at a minimum. However, because similar devices on the market range
from $14,300 to $16,100 BioBit will look to sell at a maximized price point which that offers the best value
and a lower price than any competitor. With the minimal sale price of a BioBit unit in the first year being
3% lower than any other competitor, BioBit is confident that they can sell at this price into years two and
three, thus maximizing profit margins while still offering the cheapest price to consumers compared to
direct competitors.
10.9.4.1
Desired image in market
The image that BioBit strives to is to provide a high quality product that customers can rely on with a
relatively low implementation cost. BioBit wants to create a product and provide services that will create
a loyal customer base that will keep returning when BioBit brings more products to market as well as
recommend our products to others.
10.9.4.2
Discount policy
Being a small startup company, BioBit will not offer discounts to the customers in the beginning years.
However, this policy may be modified as company growth warrants and more flexibility is available with
pricing. If this discount policy is implemented in future years, it will first be offered to valued customers
as well as new customers of particular interest to the company in order to expand its market.
66
10.10 Competitive Analysis
BioBit will have to remain competitive in a rapidly growing market in order to create a sustainable
business. The subsections below will detail who BioBit’s competitors are and what companies have the
capabilities to enter the market and become a competitor.
10.10.1 Existing competitors
10.10.1.1
Polar
3Polar has a product called ‘Team2 Pro’ which falls under the necessary classifications in order to compete
directly with our product. This means it is a wearable tracking device that is team-oriented. However, the
price and the lack of variety tracking methods are what hold this product back. The cost of a single unit is
approximately $17,200; which includes a hub, computer interface, and numerous trackers. In order to
compete with Polar, BioBit looks to provide a better value by lower price and increasing the variety of
tracking sensors.
10.10.1.2
LUMOlift
LUMO has a product currently on the market named the LUMOlift. This is an individual-oriented device
which helps aid in tips for posture and muscle energy longevity. The LUMOlift provides competition to the
BioBit through its unique tracking and data gathering. However, this device is for an individual and thus is
not team-oriented. The market price for a single LUMOlift is $210.00.
10.10.1.3
Mayfonk
Mayfonk is a vertical leap tracker with a direct focus towards athletes involved in high jump, basketball,
and volleyball. The Mayfonk competes on the same level with BioBit through its intuitive design on a
mobile application supported through iOS. This device is intended for a single person and is worn on the
hip which tracks only vertical leap. The base price for a single unit and its accompanying mobile application
is $180.00.
10.10.2 Potential competitors
10.10.2.1
FitBit
FitBit already is a leader in personal fitness tracking wearables. If this company looks to enter the market
of team oriented devices, it could pose as a threat to BioBit. Fitbit has shown it is very detailed oriented
and efficient in its current market and because of this, may look for additional avenues to increase their
footprint in the fitness tracking market.
10.10.2.2
Nike
Nike also has gotten into the personal tracking systems and is currently in direct competition with the
FitBit. If one of the two companies should choose to explore the production of team-oriented devices, the
chances of the other company to follow would be very high. Nike currently dominates its markets through
strong sales and marketing teams while following through on customer service. If Nike chooses to join, it
could also implement its current products, such as shoes, into its design and essentially double dip in the
sales of a device and apparel. If this is the case, it could pose as a challenge for BioBit to compete on sales
and marketing.
67
10.10.2.3
Samsung
Finally, Samsung may also be interested in similar markets as it has started to include sensors in its
products, such as their smartphones. Samsung could potentially pose as a competitor as it would more
than likely be very strong in its mobile application and intuitive design. While this is an aesthetic attribute
it still hold weight as it bridges the gap between the technology and the user, allowing for ease of use and
efficiency.
10.11 Description of Management Team
10.11.1 Key managers
10.11.1.1
President: Nick VanDam
Nick VanDam is a senior Electrical/Computer engineering major with a designation in International
Engineering. Nick is currently an employee under two different organizations. Firstly, since 2008, Nick has
been working for Grand Rapids Christian High School Athletics as an Event Manager and Facility Caretaker.
Second, Nick also works as an intern at URS Corporation within the Intelligent Transportation Systems
(ITS) division. He has held this position since May of 2013. This position is concerned with the technology
behind roadways which helps to improve the safety and efficiency of our transportation systems.
Surveillance systems, vehicle detectors, dynamic message signs (DMS), and their means of communication
(Fiber & Wireless) are all things encountered through this position.
In his spare time, Nick is also working on side projects involving mechanical and electrical repairs for both
the Calvin and local communities.
10.11.1.2
VP of Engineering: Brad Kunz
Brad Kunz is a senior Electrical/Computer Engineering major at Calvin College, who grew up in Hudsonville,
MI. Brad has had two previous internship experiences. Most recently, in the summer of 2014, he was a
part of the Digital Ventures team at Steelcase’s headquarters in Kentwood, MI. This Research and
Development team was focused on finding new and insightful ways to integrate technology into the office
space. He got exposure to various wireless communication protocols, along with the early stages to
product development and design. In the summer of 2013 Brad worked with the Automotive Plastics team
at Royal Technologies Corporation in Hudsonville, MI.
Brad enjoys staying active through playing sports such as soccer, tennis, golf, going hiking and going to
the gym. He also interested in audio projects and music production.
10.11.1.3
VP of Software and Product Testing: Carl Cooper
Carl Cooper is a senior at Calvin College studying Electrical/Computer Engineering. During the summer of
2014, he had the opportunity to work with Professor Kim in the Calvin College Engineering Department
to develop a system that would monitor sustainable energy systems wirelessly with smartphone apps. He
gained experience creating and sending data over wireless networks, programming microcontrollers and
Android apps, and reducing power consumption on both microcontrollers and smartphones. He
understands the benefit of being able to track players on sports teams through playing on sports teams
all the way through elementary and high school in Chiang Mai, Thailand including Varsity Basketball and
Volleyball.
68
In his spare time Carl enjoys pursuing the outdoors through rock climbing and backpacking as well as all
things audio from recording to building guitar amps and effects pedals.
10.11.1.4
VP of Research, Development, and Project Manager: Jessica Par
Jessica Par is a senior at Calvin College studying Electrical/Computer Engineering. The past two summers,
summer of 2013 and 2014, Jessica had an opportunity to intern at Koops Inc., in Holland, Michigan as a
Control Engineer. At this internship, Jessica was able to get involved in many different aspects of the
design and building of factory automation solutions. She was also get involved in Controls Design
department and developed electrical schematics, pneumatic schematics, and bills of material. Jessica
gained experience building control panels in the Machine Assembly group and worked with Koops Launch
Engineers to debug and prove out several different pieces of automation. She also learned to create
documentation manuals for a variety of machines and be onsite at the customer’s facility performing
service and support.
Jessica is currently working as a Student Office Assistance at the Engineering Department. She organized
documents, update the engineering website, help plan the department events, and assist professors when
they need a hand. She is also a student leader for Calvin’s Women and Engineering club. She plans social
events and study groups for the women engineers.
In her spare time, Jessica enjoys being active through going to the gym with friends, rock climbing,
camping. She also likes to watch TV shows such as Castle, Bones.
10.11.2 Future Additions to Management Team
10.11.2.1
VP of Finance
With the need of a Vice President of Finance, the company would look to stabilize their business financially
and look for consistent growth in an ethical and strategic manner. An individual who is a Certified Public
Accountant (CPA) and a Master of Business Administration (MBA) would best fit the requirements the
company is looking for in this position.
10.11.2.2
VP of Marketing
In this role, the Vice President of Marketing would take on a role to drive the market acceptance and
reputability through the company’s image and its products. An individual who has had past experience in
marketing technological devices and has received a Master’s in Business Marketing would best fit this role
in the company.
10.11.2.3
VP of Sales
When looking to fill the role of Vice President of Sales, the company would look for an individual who can
maintain the image of the company through managing a sales division and its respective geographical
regions. The company would prefer to have an individual which has a minimum of 15 years of experience
in a direct or related market.
10.11.2.4
Head of Facilities and Production Manager
The Head of Facilities and Production Manager would be required to communicate and manage the
production facilities and be knowledgeable in the engineering field through previous education. With this
69
role, the individual may also be required to explore avenues to optimize production through equipment,
facilities, staff, and materials.
10.11.3 Operation
10.11.3.1
Legal form of Ownership Chosen and Rationale
The members of BioBit have determined that it would be in their best interests to form a limited liability
company, also known as an LLC. While there is more of a process to go through to become an LLC, the
protection it adds to the personal liability of those employed in business related transactions is well worth
it. While it is unlikely that the company would be sued, separating the employees from that liability is
important in case legal action is taken. Furthermore, as BioBit will need a loan to get the company started,
there is a need to separate the individual’s assets from the company’s. Another benefit of forming an LLC
is that the business would be easier to sell in the event of foreclosure or the owners decide to turn their
efforts elsewhere. Additionally, BioBit will have more flexibility than a corporation and will be taxed more
like a partnership, which puts less stress on the company32.
10.11.3.2
Company Structure (organization chart)
BioBit will be a small company and, because of this, there will not be many positions to occupy initially.
There will be a president overseeing the whole company with three vice presidents below him/her. Each
vice president will be in charge of a separate division. The company will start off with just three divisions
related to production – engineering, software and product testing, and research and development – but
as the company grows marketing, sales, and finance divisions will be added. Initially the vice presidents
will oversee the entire operation of each division, but in the future it may be beneficial to add subdivisions
with a head of each. The company structure can be seen below in Figure 29. Initially, all members of
BioBit will be owners of the company, but as BioBit grows only the president and vice presidents will be
owners.
Figure 37 – Overview of Company Structure (dotted line to show initial organization)
70
10.11.3.3
Decision making authority
Each vice president has control over the decisions made in their division and any minor decisions can be
made by the vice president. However, any major decisions that will either alter the structure of the
company or significantly alter the product shall be passed by the president, who in turn, shall inform the
other vice presidents. Transparency of each division is essential in a small business so vice presidents shall
inform the other vice presidents and president of decisions that are made, but only significant decisions
shall be approved by the other owners.
10.12 Financial Statements
To analyze the financial feasibility of BioBit LLC, several financial statements were used. The following
sections go over the Pro-Forma Statement of Income and Cash Flow Statement.
10.12.1 Income Statement (Annual, 3 years)
The income statement in Table 7 shows the costs and revenues for the first three years of business. The
bottom of the table lists the net income after tax for each year. As can be seen in the table, after the first
year the company will be making an approximate $185 thousand, which can be used to expand production
and pay off debt. By the end of the second year, the net income will be around $1.5 million and $5.8
million by the end of the third year.
Table 7 – Income Statement for First Three Years
10.12.2 Cash Flow Statement (Quarterly, 3 years)
The cash flow statement is an important document because it shows how the cash moves through the
company. This statement for the first three years can be seen in Table 8 and it is expanded into each
quarter in Table 9 and it should be noted that the company ends with a positive cash balance at the end
of each year. The cash flow statement also lists the loan information; including receiving the loan and the
71
payoff plan. As the company ends each year with a positive cash balance, BioBit LLC will pay off the loan
in the second year split into four payments to be paid out each quarter. As the note under Table 8 states,
there are no changes in assets and liabilities other than cash, notes payable, and equipment so a balance
sheet is not needed.
Table 8 – Cash Flow for First Three Years (Yearly Overview)
Table 9 – Cash Flow for First Three Years (Quarterly)
10.13 Break-Even Analysis
The break-even analysis is shown in Table 10 shows the break even sales volume to be just over $1 million
each year. BioBit plans on exceeding this point each year as there is a large market for the product.
72
Table 10 – Break-Even Analysis
10.14 Ratio Analysis
The ratio analysis for the first three years of business can be seen below in Table 11. It should be noted
that the profit margin ranges from 13% to 43%, which exceeds the minimum of 10% as budgeted each
year. With these numbers comparable to market, the 13% is far too low; however, 43% is a great margin
73
of value. This means that to improve profits, costs would need to be reduced. It should also be noted
that the net asset turnover decreases after years two because the company gains assets over the first
three years so even though the revenue is increasing, the ratio decreases.
Table 11 – Ratio Analysis
11.
Project Management
This section describes the structure of how the team organized project documents and the breakdown of
the project work load between the team members. In addition, this section also describes the outline of
the cumulative project schedule and discusses the method that the team uses to approach the project to
reach a completed design.
11.1 Team Organization
Within the team organization sections is a description of the team's work division, document
organizations, and milestones. The document organization section will describe the locations of project's
documents. The division of work describes how the team divided work and the team's major decisions
made are described under milestones.
11.1.1
Documentation Organization
The team has used a combination of locations to keep documents. Google Drive has been used to keep
meeting minutes, research documents, Senior Design lecture notes, and it hosts a forum for the group to
communicate through. Formal documents are located on Microsoft's OneDrive. Files such as CAD
drawings, presentation material, weekly updates, and website code are hosted on Calvin's Shared drive.
These methods make it possible to access all the files and documents from anywhere there is an internet
connection.
11.1.2
Division of Work
During the fall semester, the division of work depended on the task at hand. No team member had specific
designated tasks. When there was work to be done the team got together and divided and conquered.
This happened with early design and research of the project. Once the testing began, the team split into
two groups. Nick and Brad worked on the Raspberry Pi while Jessica and Carl worked on the processing
board. This division was in conjunction with the team’s Engineering 325 lab.
Additionally, at the beginning of the second semester, parts were allocated for the project and tasks were
reassigned. For the remainder of the project, the task allocations were as follows. Carl Cooper was
responsible for app development, Brad Kunz was responsible for the heart rate sensor and wearable
74
communication, Nick VanDam responsible for the wireless network communication and server/database
construction, and Jessica Snyder was responsible for the pedometer. As a unit, the team felt that this was
the most efficient way to go about completing the design, and as a result, did indeed achieve their goal.
11.1.3
Time Allocation
Since the team began the design process, many hours were logged regarding anything from team
meetings, presentations, design, and implementation. Throughout the process the total estimated time
spent on the project was 1,381.25 hours worked. This should be noted that the fall semester was an
assumed hour allocation per person as only daily hours were tracked in the spring semester. Below is a
breakdown of each individual and their time spent and the percentage to the total hours worked amongst
the team.
11.1.3.1
Carl Cooper
Carl Cooper’s primary responsibility was to work on the end-user Android app. While he did much more
than this by helping out in many other facets of the project including the business plan, the majority of
Carl’s 363.25 hours worked was spent on refining the app and improving the functionality. This equates
to 26.3% of the total hours worked by the team.
11.1.3.2
Nick VanDam
Nick VanDam’s primary responsibility was to work on the Raspberry Pi with the WLAN communication
and the Server/Database construction. Additionally, Nick also worked on the housing of the wearable
device and refining the business plan second semester. The total hours worked equates to 346.5 hours
and 25.1% of the teams total hours worked.
11.1.3.3
Brad Kunz
Brad Kunz’s primary responsibility was to work both on the heart beat sensor as well as with the Wi-Fi
module on board the wearable device. He also assisted in other roles amongst the team totaling with 342
hours worked and a 24.8% of the total team hours throughout the year.
11.1.3.4
Jessica Snyder
Jessica Snyder’s primary role was to work with the pedometer on the wearable device. This was done
through working with the accelerometer and gyroscope. This totaled to 329.5 hours worked equating to
23.9% hours worked.
11.1.4
Milestones
The major milestones throughout the year, as outlined by the design course, are identified below.










Project Selection
Project Proposal and Approval
September 15 – PPFS Outline
October 15 – First Oral Presentation
October 17 – Choose communication: Wi-Fi
October 22 – Project website
November 2 – Chose Components: Intel Edison and Raspberry Pi
November 10 – PPFS Draft
November 12 – Bought Intel Edison and Raspberry Pi
December1 – Second Oral Presentation
75











December 4 – Tested processors and communication
December 8 – PPFS
December 15 – Website Update
February – Design and Product Testing
March 4 – Third Verbal Presentation
March 9 – New Parts Allocated for Design; Arduino Pro Mini
April 24 – CEAC Review
April 27 – Draft of Design Report Due
May 1 – Fourth Verbal Presentation
May 9 – Senior Design Night Open House
May 13 – Final Design Report Submitted
11.2 Schedule
11.2.1 Schedule Management
The team initially created a Gantt chart for how the team would approach the project and the supporting
documentation. While a Gantt chart is useful to display and visually represent deadlines, the team opted
to rely on alternative methods for keeping track of assigned tasks and due dates. A weekly status report
was generated, setting goals and assignments for each individual along with group-wide tasks.
Additionally, weekly meetings were held with all team members to ensure everyone is under the same
understanding and maintain similar goals and ideas towards the design project.
11.2.2
Critical Path
As the team consolidated a design and a plan of action, it was crucial to also identify the critical path. This
is defined by the operation and deliverables which must be present at the end of the project with no
exceptions. Upon this evaluation, the team determined that the critical path included ensuring a full
communication path between the wearable, Raspberry Pi, and the Android app. Along with this, the
sensors must track data and deliver it successfully to the application. Once this critical path was
accomplished, the team then focused on refining the accuracy of the data tracked, the housing of the
wearable, and the functions of the Android app.
11.3 Operational Budget
The funding a support for this project was generously given to the design team through the Calvin College
Engineering Department. Given a budget of $500, the team looked to not only create a functioning
prototype but also maximize its value and minimize the resources needed in order to accomplish this goal.
Throughout the design process, the team managed funds through a supporting excel spreadsheet where
manufacturers, contact information, purchasing dates, and current balance were documented. With this,
the team created an estimate at the beginning of the project as well as an expenditures report. The
comparison between the two of these spreadsheets allowed the team to manage their funds by each
transaction. With a $500 capital, the team estimated that the project would cost $376. At the conclusion
of the design, the team was indeed able to stay within the allotted $500 and achieve their budget under
$376 by spending a total of $374. This resulted in a remaining capital of $126, which may be returned
back to the engineering departments to be used for alternative expenses.
76
11.4 Method of Approach
This section is intended to describe the design methodology, the research techniques, team
communication, and the specific design norms that have influenced the team’s design decisions.
11.4.1
Design Methodology
The team took on a design methodology of designing first for our found requirements. These
requirements, whether they were noted by our potential customers or set by the team, were the basis of
the team's design. The team also tried to design with our design norms of trust, integrity and caring in
mind. These would tailor some of the design choices to make sure that our product would be the best the
team could produce and meet the customer's expectations.
11.4.2
Research Techniques
To find relevant information to the project, the team used a combination of informal websites and the
Heckman Library (Calvin College) databases. During the early stages of the design the team would sit down
and break up the research for each specific facet of the system design. The team would rely on a
combination of online tutorials and reviews of products to help understand the design and what type of
elements would be required to complete the design. Once a reliable and helpful source was found the
location was noted and placed in a topic specific Google Doc for future reference.
11.4.3
Team communication
The team used email and texting as their primary communication. The team found these communications
to be the most effective. The team also has a forum that can be used for discussing topics and
communicating with the entire team. This was in addition to the weekly meetings the team had where all
team members were required to be present.
12.
Closing Remarks
This section discusses results of the project, along with a listing of lessons learned along the way. The
document will end by giving credit to those who have helped the team during this project.
12.1 Project Results
This project resulted in a working proof of concept system that allows coaches or fitness instructors to
see the fitness levels of their players during a practice. The team was able to deliver a central hub that
creates a Wi-Fi network and hosts a database, two working wearable devices that track heart rate and
steps travelled, and an Android app that displays this data individually or as a whole team.
As this is merely a proof of concept, or a very early prototype, there is much work that could be done to
improve the product. Beyond improving and optimizing the current algorithms, one of the first things the
team would change is the size because the design for the wearable device is much larger than users would
be willing to wear so it would need to be slimmed down. One important step in this process would be
designing our own hardware. By designing hardware, the team would be able to eliminate features that
are not needed and the extra space on breakout boards could be eliminated. The team could also add
further algorithms that count calories burned or distance travelled without adding extra hardware. The
team would also like to add GPS to the system to provide the coach a heat map of where on the field
players go and spend most of their time. Finally, if BioBit were to go to market, the app would need to be
77
improved to provide more customization options and expand compatibility to multiple screen sizes and
versions as well as an iOS app would need to be made to widen the number of users who could use the
system.
12.2
Lessons Learned
Throughout the first semester of the project the team learned some valuable lessons that they can apply
to the remainder of the project. The first lesson was given to us by Eric Walstra about scheduling. He said
that we are like the 95% of the working population that do not hold true to their Gantt chart. While the
task of setting up a Gantt chart can be very helpful in determining the work breakdown, it is much easier
to work from hard deadlines instead of the intermediate goals set in Gantt charts.
A second learned lesson for the team is the need for weekly meetings. These meetings are important to
touch base, evaluate the current status of the project and to look forward at the near and distant future
goals. This became increasingly important in the second half of the project as the team split up and worked
on their own portions of the design. Each teammate had to give detailed updates of their progress and
communicate with others in the group to successfully integrate their portion into the system.
The large role of communication within a project of this size is another lesson that the team has realized.
The team has been forewarned by plenty of professional mentors that communication is essential in a
group project. But the best way to learn this is by actually being a part of a large project.
The team also learned a lot about the characteristic of patience. This came to fruition as the group was
working with the Wi-Fi modules for the fitness devices and setting up a WLAN on the Raspberry Pi. There
were several instances where hours would be spent on debugging issues and then after a night off the
issue was fixed in the next debugging session reasonably quickly. The team also had to exercise patience
when dealing with suppliers. Out of the 15 Wi-Fi modules the group received only three worked out of
the box and one stopped working before the team could get it in a working prototype. There was plenty
of time spent waiting for replacement parts and this would handicap the team as we tried to move
forward.
One of the final lessons the team learned while working on the project is to expect the best, and prepare
for the worst. Some outcomes of testing and debugging were less than ideal but the team learned that
we had to be prepared for these types of results. We held ourselves to a high standard throughout the
project and we encountered our fair share of unforeseen obstacles, this will ultimately help us in future
projects throughout each individual’s career.
12.3 Credits and Acknowledgements
The team would not be as far as we are if it weren't those around us. We would like to thank those people.
First, Professor Mark Michmerhuizen as the team's advisor. He has given us plenty of feedback from the
project design, to formal documents, along with words of advice and encouragement. We would also like
to thank the three other professors, Professor David Wunder, Professor Jeremy VanAntwerp and
Professor Ned Nielsen, who lead the Senior Design class along with Professor Michmerhuizen. They are
quick to help any team that approaches them and have given their respective lectures that help the teams
to grow and become more professional. Team 10 would also like to thank Eric Walstra for being the team's
78
industrial consultant and providing an outside professional viewpoint to the project. Finally, we'd like to
thank the Calvin College and Grand Rapids Christian High School athletic departments along with the
Calvin College Kinesiology department Professors for their suggestions and their willingness to help the
team’s project development.
The team would also like to thank our friends and family for their continued and unconditional support.
They are the ones that help us get through this tried and testing time in our academic lives and we hope
we can make them proud through our work.
79
13.
References
1
Comer, Douglas E. Internetworking with TCP/IP: Vol. I. Upper Saddle River, NJ: Pearson Prentice Hall, 2006. Print.
"Welcome to Bluetooth Technology 101." Fast Facts. Bluetooth Technology Website, n.d. Web. 14 Oct. 2014.
3
Lee, Jin-Shyan, Yu-Wei Su, and Chung-Chou Shen. "A Comparative Study of Wireless Protocols- Bluetooth, UWB,
ZigBee, and Wi-Fi." The 33rd Annual Conference of the IEEE Industrial Electronics Society (IECON)(2007): 46-51. A
Comparative Study of Wireless Protocols- Bluetooth, UWB, ZigBee, and Wi-Fi. Acedemia.edu. Web. 18 Oct. 2014.
4
Lee, Jin-Shyan, Yu-Wei Su, and Chung-Chou Shen. "A Comparative Study of Wireless Protocols- Bluetooth, UWB,
ZigBee, and Wi-Fi." The 33rd Annual Conference of the IEEE Industrial Electronics Society (IECON)(2007): 46-51. A
Comparative Study of Wireless Protocols- Bluetooth, UWB, ZigBee, and Wi-Fi. Acedemia.edu. Web. 18 Oct. 2014.
5
"Intel® Edison Module." Intel. N.p., n.d. Web. 25 Oct. 2014.
6
"Intel® Edison." SparkFun Electronics. N.p., n.d. Web. 25 Oct. 2014.
7
"Arduino - ArduinoBoardProMini." Arduino - ArduinoBoardProMini. N.p., n.d. Web. 11 May 2015.
8
"Arduino Pro Mini 328 - 5V/16MHz." Singapore Robotic. N.p., n.d. Web. 11 Mar. 2015.
9
"FLORA - Wearable Electronic Platform: Arduino-compatible." Adafruit Industries. N.p., n.d. Web. 05 Nov. 2014.
10
"Adafruit Learning System." Adafruit I. N.p., n.d. Web. 05 Nov. 2014.
11
"SparkFun WiFi Breakout - CC3000." - WRL-12072. N.p., n.d. Web. 11 Apr. 2015.
12
"Polar Heart Rate Monitor Interface." - SEN-08661. N.p., n.d. Web. 08 Dec. 2014.
13
"Optical Heart Rate Monitor Reference Design with BLE Connectivity." - TIDA-00011. N.p., n.d. Web. 08 Dec.
2014.
14
"Pulse Sensor." - SEN-11574. N.p., n.d. Web. 08 Dec. 2014.
15
"SparkFun Triple Axis Accelerometer Breakout - ADXL335." - SEN-09269. N.p., n.d. Web. 08 Dec. 2014.
16
"STP156 Embedded 3D Pedometer Module by Nicerf." Tindie. N.p., n.d. Web. 08 Dec. 2014.
17
"MPU-6050 Accelerometer + Gyro." Arduino Playground. N.p., n.d. Web. 11 May 2015.
18
"Adafruit Micro Lipo W/MicroUSB Jack - USB LiIon/LiPoly Charger." Adafruit Industries. N.p., n.d. Web. 11 May
2015.
19
"SparkFun LiPo Charger Basic - Micro-USB." SparkFun. N.p., n.d. Web. 18 Apr. 2015.
20
"Raspberry Pi - Model B+." Sparkfun. N.p., n.d. Web. 06 Dec. 2014.
21
"Beaglebone Black - Rev C." Sparkfun. N.p., n.d. Web. 06 Dec. 2014.
22
Leonard, Michael. "How to Choose the Right Platform: Raspberry Pi or BeagleBone Black?" MAKE. N.p., 25 Feb.
2014. Web. 25 Oct. 2014.
23
Comer, Douglas E. Internetworking with TCP/IP: Vol. I. Upper Saddle River, NJ: Pearson Prentice Hall, 2006. Print.
24
Evans, Jon. "Android vs. IOS Development: Fight!" TechCrunch. N.p., 16 Nov. 2013. Web. 04 Dec. 2014.
25
Henneke, Cameron. "Android vs. IOS: Comparing the Development Process of the GQueues Mobile Apps."
GQueues. N.p., 29 July 2013. Web. 05 Dec. 2014.
26
"MPU-6050 Accelerometer + Gyro." Arduino Playground. N.p., n.d. Web. 12 Feb. 2015.
27
"Generator Research." Share. N.p., n.d. Web. 01 Nov. 2014.
28
T., An Ihs Whitepaper, and September 20. Wearable Technology – Market Assessment (n.d.): n. pag. Web.
29
"Generator Research." Share. N.p., n.d. Web. 01 Nov. 2014.
30
"Generator Research." Share. N.p., n.d. Web. 01 Nov. 2014.
31
"Generator Research." Share. N.p., n.d. Web. 23 Dec. 2014.
32
Lawrence, Beth. "LLC Basics." Nolo.com. Web. 31 Oct. 2014.
2
80