March 10, 2016

Dr. Andrew Rawicz School of Engineering Science Simon Fraser University Burnaby, British Columbia V5A 1S6

Re: ENSC 305W/440W Capstone Project Design Specifications for Floe: the Athletic Balance Monitoring System for Skiers

Dear Dr. Rawicz,

Please find the design specifications document for our Capstone project, Floe: the Athletic Balance Monitoring System for Skiers, enclosed herein. Our objective with this project is to design and build a system that can assist skiers in furthering their abilities by collecting quantitative data on their performance and converting it into useful real-time feedback.

This document consists of a full breakdown of our proof-of-concept model in its physical, hardware, firmware, and software elements and the justified choices behind the design of said elements. All system components are listed and the reasoning behind our selection of them and their implementation is given in this document.

Pinnacle Biometrics is comprised of four Simon Fraser University engineering science students: Kurtis Bohlen, Eric Raposo, Louis Roux, and Clara Tsang. Specializing in systems and electronics, we are motivated and passionate about our fields of study and the use of technology to help athletes meet their true potential.

Please do not hesitate to contact me at clarat@sfu.ca if you have any questions or concerns in regards to this submission. On behalf of my team at Pinnacle Biometrics, I thank you for your time and consideration of our project’s design specifications.

Sincerely,

Clara Tsang Project Manager, Pinnacle Biometrics

Enclosed: Design Specifications for Floe: Athletic Balance Monitoring System for Skiers

Design Specifications for

Floe: the Athletic Balance Monitoring System for Skiers

Contact Person: Clara Tsang clarat@sfu.ca

Date Issued: March 10, 2016

ii

Abstract

Floe: the Athletic Balance Monitoring System for Skiers is designed to provide the amateur and professional skier, as well as their trainers, with quantitative augmented feedback and allow them to further their skills more efficiently. The final marketable version of Floe will use force-sensitive insoles and the readily available gyroscope and accelerometer on the user’s mobile or HUD device to compare the balance of the user to characteristics corresponding to skiing with proper form. With such information, the user can receive real-time quantitatively gathered feedback during their performance, as well as view a summary of performance statistics post-run.

Every stage of Floe is comprised of the same three sub-systems: the pressure-sensing insoles, the boot-mounted hardware, and the software application. Weight distribution data is taken by the pressure-sensing insoles, which are wired to the boot-mounted hardware. The boot-mounted hardware then converts the analogue signal received from the insoles into a digital signal to be transmitted wirelessly to the software application. Finally, the software processes the received data and converts it into usable graphical information for the user.

This document will outline the design specifications of Floe, and will be referred to as a guide for model construction as well as testing. The specifications made in this document will describe in detail the justified design choices behind each of the three sub-systems as defined by Floe’s proof-of-concept model in the previous document, “Functional Specifications for Floe”[1]. This document is divided into sections corresponding to the physical, hardware, firmware, and software elements of the model. Justifications for the chosen system components as well as the details on their implementation are given for each section.

Lastly, this document will outline the high-level testing procedures required to ensure that our product meets its requirements. The test plans are first broken down into procedures testing the individual aforementioned elements, and then proceed to describe procedures testing the system as a whole.

iii

Table of Contents

Abstract ..................................................................................................... ii

Table of Contents ..................................................................................... iii List of Tables and Figures ......................................................................................... iv

Glossary ................................................................................................... vi

1 Introduction .......................................................................................... 1 1.1 Scope .................................................................................................................. 1 1.2 Intended Audience ............................................................................................. 1 1.3 Project Background ............................................................................................ 1 1.4 Classification ....................................................................................................... 2

2 System Specification ............................................................................ 2 2.1 System Overview ............................................................................................... 2 2.2 Use Case ............................................................................................................ 3 2.3 Functionality Justification ................................................................................... 4 2.4 Safety & Sustainability ........................................................................................ 4

3 Physical Design .................................................................................... 5 3.1 Insoles ................................................................................................................. 5 3.2 BMH Housing ..................................................................................................... 6

4 Hardware Design .................................................................................. 7 4.1 Sensors ............................................................................................................... 7 4.2 Signal Conditioning Circuit ................................................................................. 8 4.3 System-on-Chip .............................................................................................. 10

4.3.1 BLE .............................................................................................................. 10 4.3.2 ADC ............................................................................................................. 10 4.3.3 RF Hardware ............................................................................................... 10 4.3.4 Timer ............................................................................................................ 11 4.3.5 Memory ....................................................................................................... 12

5 Firmware Design ................................................................................ 12 5.1 Data Collection ................................................................................................. 13 5.2 BLE Transmission ............................................................................................ 13

6 Software Design ................................................................................. 16 6.1 User Control Flow ............................................................................................. 16 6.2 Data Structures ................................................................................................ 17 6.3 Process Flow Design ....................................................................................... 19 6.4 Data Transfer ................................................................................................... 21

iv

6.5 Data Processing ............................................................................................... 22 6.6 Display .............................................................................................................. 23

7 Test Plan ............................................................................................ 24 7.1 Component Testing .......................................................................................... 24

7.1.1 Physical ....................................................................................................... 24 7.1.2 Hardware ..................................................................................................... 25 7.1.3 Firmware ..................................................................................................... 25 7.1.4 Software ...................................................................................................... 26

7.2 System Testing ................................................................................................. 27

8 Conclusion ......................................................................................... 27

References .............................................................................................. 29

Appendix A .............................................................................................. 30

List of Tables and Figures Figure 1.1 – High-level concept of Floe 1

Table 1.1– Requirement classification priority definition 3

Figure 2.1 – System overview of Floe 4

Figure 3.1 – Insole FSR array 6

Figure 3.2– BMH physical design 7

Figure 4.1 – Top and bottom view of FSR 402 7

Figure 4.2 – Resistance vs. force plot for the FSR 402 8

Figure 4.3 – FSR voltage divider 8

Figure 4.4 – Linear voltage vs. force graph for FSR 402 9

Figure 4.2 – Complete signal conditioning circuit 9

Table 4.1 – SoC radio states 11

Figure 4.6 – Radio state diagram 11

Figure 4.7 – Timer block diagram 12

Figure 5.1 – Wireless transmission master-slave relationship 13

Table 5.1 – Transmission buffer data breakdown 14

Table 5.2 – Transmission data packet breakdown 15

Table 5.3 – Receive data packet breakdown 15

Figure 5.2 – Firmware program flow 16

Figure 6.1 – Software control flow 17

Figure 6.2 – FloeDataPt UMP class diagram 18

Figure 6.3 – Floe app dependency and inheritance diagram 19

v

Figure 6.4 – Floe app process flow diagram 20

Figure 6.5 – Sensor data software value assignment 22

Figure 6.6 – Real-time GUI cases 23

Figure 6.7 – Post-run analysis graphs 24

Figure A.1 – Complete FSR 402 dimensions 30

Figure A.2 – Polymer thick film FSR construction 30

Figure A.3 – nRF52832 pin layout 31

Figure A.4 – Simple ADC sample network 32

Table A.1 – ADC acquisition times 32

Figure A.5 – nRF52832 complete memory map 33

vi

Glossary Anteroposterior: relating to front-to-back motion

API: Application Program Interface; set of routines, protocols, and tools used for software application development

Augmented feedback: performance feedback received from an external source; for example, a coach, video, biometrics, etc.

BLE (Bluetooth LE): Bluetooth Low Energy; a low-energy wireless data transmission protocol

BMH: Boot-Mounted Hardware; system component of Floe pertaining to the ski boot-mountable enclosure containing the SoC, signal-conditioning circuit, and power supply

CoP: Centre of Pressure; single point on a body at which summarizes the total net force induced by several forces

FSR: Force-Sensitive Resistor

GUI: Graphical User Interface; type of interface that bases user interaction with an electronic device on visual indication/graphical controls

Hallux: big toe

HUD: Heads-Up Display; transparent display that allows user to interpret shown data without the need to divert vision

Interdigitate: (of two or more things) interlock like the fingers of two clasped hands

Mediolateral: relating to side-to-side motion

NUS: Nordic UART Service; includes BLE service

Op-amp: operational amplifier

PPI: Programmable Peripheral Interconnect

SAADC: Successive Approximation Analogue-to-Digital Converter

SDK: Software Development Kit

SMD: Surface Mount Device

SoC: System-on-Chip; single chip with integrated circuit that gives it all components of computer/electronic system

UART: Universal Asynchronous Receiver/Transmitter

UI: User Interface

UML: Universal Modelling Language

1

1 Introduction

1.1 Scope The objective of this document is to define and organize the technical details regarding

the design for the proof-of-concept model1 of Floe: the Athletic Balance Monitoring System for Skiers. In this document, the system is divided into its hardware, firmware, software, and physical components, and then further divided into subcomponents; the design specifications will be organized under these subcomponents. Justification will be given for each specification, and where applicable, functional requirements defined in the Functional Specifications document [1] will be referenced for further justification. Lastly, this document will outline the high-level testing procedure needed to evaluate the overall performance of Floe.

1.2 Intended Audience The design specifications made in this document are intended for the use of all

members of Pinnacle Biometrics, as well as potential stakeholders of Floe. This document will be used as a reference guide during the implementation and testing of the system to ensure the product’s overall quality. The specifications made in this document can also be of use to potential stakeholders in obtaining a more technical understanding of Floe.

1.3 Project Background At Pinnacle Biometrics, we are working to assist athletes in meeting their true potential

by relieving them of learning limitations imposed by performance analysis that is exclusively qualitative. Floe: the Athletic Balance Monitoring System for Skiers will provide the amateur and professional skier with accessible quantitative analysis on their performance.

Figure 1.1 – High-level concept of Floe

1 Due to the limitations imposed by the project timeline, design specifications made in this document correspond to the proof-of-concept model of Floe, unless stated otherwise. Details on the scopes of the three production stages, including the proof-of-concept model, can be found in the Functional Specifications [1] document.

2

Through the use of force-sensitive insoles and Bluetooth technologies, Floe will collect weight distribution data during a skier’s performance and convert it into useful information to be displayed as real-time prescriptive feedback in a heads-up display or post-run performance statistics on a mobile device. A high-level depiction of Floe’s concept can be seen in Figure 1.1 above.

Floe will not only allow users to learn more effectively with the addition of consistent, quantitative augmented feedback, but it will enable instructors to review and analyze their students’ progress more effectively. Floe is not intended to replace the role of the ski instructor; it is intended to enhance the benefits of independent training as well as increase productivity in a student-instructor environment.

1.4 Classification Throughout this document, functional requirements referenced from the Functional Specifications document will be represented in the following convention:

[Rxx-p] Requirement description

where xx represents the requirement number and p is the priority of the requirement, as defined in Table 1.1.

Table 1.1 – Requirement classification priority definition

Priority p Definition

i High priority; essential to functionality and concept of product; present in all

stages of product

ii Intermediate priority; requirements that will allow product to be used

effectively in its designated environment; present in the prototype and further

iii Low priority; requirements that will enhance the usability and value to the

user; present in the final product

2 System Specification This section will outline and give justification for the overall functionality of Floe. It will

also summarize the safety and sustainability issues concerning this system.

2.1 System Overview Floe can be broken down into three components: the pressure-sensing insoles, BMH

(comprised of the SoC, signal conditioning circuit, and power supply), and user interface. As shown in Figure 2.1, the BMH is wired to the insoles to receive analogue sensor data, in which it then converts into digital data to transmit via BLE to the paired device. The system then relies on the software to interpret the received data and convert it into information that is useful to the user, in which it will be displayed in a manner intuitive to the user under real-time constraints.

3

Figure 2.1 – System overview of Floe

2.2 Use Case . Figure 2.2 shows the interaction between the user and the three system components

of Floe. Although the user is directly in contact with the sensors of the insole, conscious interaction between the user and the system remains within the realm of the mobile application, allowing for simplicity in the system’s user interface. The BMH is essentially a receiver and transmitter, awaiting a signal from the mobile application to begin acquisition of sensor data via serial connection, conditioning and processing of said data, and transmission of processed data back to the mobile application via BLE.

4

Figure 2.2 – Use case diagram for Floe

2.3 Functionality Justification As we were not improving upon an existing product, the main objective behind the

design of Floe was to allow our product to be easily integrated into the existing equipment of the user. Alpine sport equipment is already relatively expensive, and this in turn also reduces any excess consumption of the user.

The user interface for Floe is to be on a mobile application, accessible to the user on their existing mobile devices. We chose to start the product off with the Android API, as Android devices are widely owned and used, as well as how easily integrated the application can be to the existing Recon Instruments Snow2 HUD API.

We designed the BMH and insoles to be easily integrated into the user’s existing ski equipment to avoid the need to modify their boots. The BMH is designed to be easily mounted to any ski boot, whereas the insoles can be easily slipped into their boot. Furthermore, we chose to implement a BLE SoC to minimize physical bulk, reduce power consumption, and avoid the need to redevelop when advancing our product.

Lastly, we designed Floe to utilize wireless transmission between the BMH and user interface, as this was the most appropriate data transmission protocol to not disturb or hinder the user’s motion.

2.4 Safety & Sustainability Issues regarding safety and sustainability have been addressed upon the design of

this system. With its high descent speeds, potential obstacles and great number of

5

variables to keep in mind, alpine skiing is a sport that carries with it a sizeable risk to the athlete’s health. Furthermore, the production and consumption of any new product has its impact on the environment, and design choices have been made to minimize ours.

The electrical components of Floe could pose a risk to the safety of the user, mostly for the potentially distracting effects of a shock. The voltages used in our circuits are very low, and therefore pose no real risk to the user’s health by themselves, but we are nevertheless committed to follow international norms on the safety of electrical components. As specified in the Functional Specifications document, all electrical circuits and systems of Floe will comply with various IEC, CAN/CSA, and IEEE standards.

The BMH, due to its volume, also has the potential to cause harm to the user. To minimize such risks, it is to be attached to the boot in a location that in no way hinders the movement of the user or impairs the user’s ability to perform any task during a ski session.

Distraction is the greatest risk that Floe poses to the user. When travelling very rapidly down a hill dotted with seen and unseen obstacles, it is crucial that the user be able to concentrate fully on the task of navigation when it is necessary. Therefore, the real-time feedback functionality of Floe is designed to be intuitively informative, which lets the user assimilate the displayed information quickly without diverting too much attention away from the safe execution of the sport.

As mentioned above in Section 2.3, developing software that can be executed on existing mobile devices allows our customers to use Floe with the devices they already possess, thereby reducing excess consumption.

Our choice of board for the BMH also reflects our commitment to environmentally friendly technology. The system consumes a very low amount of energy, and uses a rechargeable battery as a power source, which greatly limits the environmental impact of Floe’s operation. The prototype models are designed and built with polyvalent and high-quality parts, to allow the team to use the same parts in many different ways if the product design should change.

Lastly, we will implement the physical design for our proof-of-concept model by reusing materials found in our households. For example, the housing of our BMH can be constructed using an appropriately sized plastic container, and the plastic sheets needed by the insoles can be constructed using old plastic report covers.

3 Physical Design This section describes the design specifications and gives justification for such design

choices of Floe’s two physical components: the pressure-sensing insoles and the housing of the BMH.

3.1 Insoles The pressure-sensing insoles are composed of an array of four FSRs housed

between two sheets of durable poly material. As can be seen in Figure 3.1, FSRs are placed underneath the hallux, first and fifth metatarsal heads, and the heel of each insole.

6

The FSRs corresponding to the hallux and heel are to sense change in anteroposterior pressure, whereas the FSRs corresponding to metatarsal heads are to sense change in mediolateral pressure. By implementing the minimum amount of sensors needed to collect sufficient data to calculate a user’s centre of pressure, requirement [R29-i] is fulfilled while limiting the percentage of the budget spent on sensors.

Figure 3.1 – Insole FSR array

To fulfill requirements [R31-i], [R32-i], and [R43-i], we chose to house the sensors in sheets a poly material, utilizing its waterproof, thin, tear-resistant, flexible and durable properties. Furthermore, this material is easily obtained through reusing old plastic report covers.

3.2 BMH Housing The BMH housing is the physical component containing the SoC, signal conditioning

circuit, and power supply. This is the most physical element in Floe, and therefore most physical requirements of the product focuses on this component.

As can be seen in Figure 3.2, the shape of the BMH is a simple rectangular box, fulfilling requirement [R63-i], with dimensions that minimize the space between the interior walls of the box and its contents. The material to be used in constructing the body of the housing is just a simple plastic container, fulfilling requirements [R65-i] and [R9-i], as well as being a material we can easily find in our households to reuse. An opening into the container will be available on the back of the body above the mounting mechanism to allow the wires leading from the insoles to connect to the contents of the housing.

The mounting mechanism for the BMH housing is a flexible loop, to be constructed using a scrim-backed pressure-sensitive tape reinforced with polyethylene and attached to the body of the housing with a rubber-based adhesive. The existing Velcro strap on the user’s ski boot can then be fed through this loop to secure it onto the boot without requiring any modification of their equipment, fulfilling requirement [R62-i].

Lastly, as seen in Figure 3.2, the power control for the BMH and its corresponding LED power status indicator is on the top of the body to be easily accessible to the user, fulfilling requirements [R54-i] and [R58-i].

7

Figure 3.2 – BMH physical design

4 Hardware Design The hardware of Floe is comprised of three main components: pressure sensors, used

to measure the balance data; a SoC, used to read and transmit values taken from the sensors; and a signal conditioning circuit, used to provide the SoC with suitable values. Whereas the SoC and signal conditioning circuitry, along with the power supply, collectively compose the BMH, the sensors are located on a flexible insole; a cable leading out of the boot connects the two.

4.1 Sensors The pressure sensors chosen for the design are FSRs. Such components feature the

obvious advantages of being flexible and very thin in comparison to other force sensors, such as load cells or other SMD sensors that require a PCB to be mounted upon. The sensor we are using is a polymer thick film FSR made by Interlink [2]. The exact model, shown in Figure 4.1, is the FSR 402, a member of the FSR 400 Series Round Force Sensing Resistor family.

Figure 4.1 - Top and bottom view of FSR 402 [2]

8

The FSR is robust and can withstand up to 10 million actuations [2], exceeding the use over 3 ski seasons laid out in requirement [R43-i]. This sensor has a thickness of only 0.55mm [2] and will therefore be imperceivable to the user while situated in the insole of their ski boot, fulfilling requirement [R31-i]. The complete dimensions and construction breakdown of the sensor can be found in Appendix A.

The measureable force of the sensors ranging from 0.1 to 10kg [2] is sufficient for the proof-of-concept model of Floe and the initial testing conditions stated in [R29-i]. The logarithmic relation between force and resistance can be seen in Figure 4.2 below.

FIgure 4.2 - Resistance vs. force plot for the FSR 402 [3]

4.2 Signal Conditioning Circuit Signal conditioning is needed to convert the sensor output resistance into a voltage

readable by the SoC. A simple and common way to translate a resistance to a voltage is through the use of a voltage divider. This satisfies requirement [R46-i]. The implementation of a voltage divider with the FSR is shown in Figure 4.3. The output analogue voltage is given by Equation (1).

Figure 4.3 - FSR voltage divider [5]

9

𝑉!"# =  𝑅!𝑉

𝑅! +  𝑅!"#

(1) In this configuration, the output voltage increases with applied force as RFSR) decreases.

The force-voltage characteristics for varying RM values can be seen in Figure 4.4 below. We have chosen RM to be 10kΩ to maximize the force sensitivity range of our sensor.

Figure 4.4 - Linear voltage vs. force graph for FSR 402 [3]

The second objective of the signal conditioning circuit is to provide a low output

impedance to improve the performance of the SoC, requiring the output voltage to be isolated from the high source impedance of the FSR. This can be achieved through the recommended circuit from Interlink seen in Figure 4.5 below.

Figure 4.5 - Complete signal conditioning circuit [3]

By using an op-amp as a unity gain buffer, the output impedance seen by the SoC can be lowered. The op-amp chosen for our design is the MCP6004 - a standard 1 MHz, low-power op-amp. This op-amp has a high input impedance of 10TOhms; therefore, the op-amp does not load the source voltage, only draws negligent current from it, and, in turn, maintains the operation of our voltage divider. Additionally, the analogue output pins of the op-amp are low-impedance and can therefore act as voltage sources, satisfying requirement [R48-i] [6]. The signal conditioning circuit is housed in the same enclosure as

10

the wireless SoC and will connected to the sensors located on the insole by thin wires to satisfy requirement [R30-i].

4.3 System-on-Chip With the intention of saving physical space, reducing power consumption, and easing

the transition from prototype to finished professional product, we decided to use a SoC rather than a microcontroller. The device that we are using in our design is the Nordic Semiconductor nRF52832, an ultra-low power 2.4 GHz wireless SoC that integrates the nRF52 Series 2.4 GHz transceiver and an ARM® Cortex®-M4 CPU with flash memory. The nRF52832 has flexible power management and can run on voltages from 1.7V to 3.6V [7], satisfying requirements [R14-i],[R39-i], [R40-i], and [R51-i]. As the nRF52832 SoC is a professional, industry-grade device, it allows for the refinement of the hardware design and firmware development in our final product. Its complete block diagram can be found on http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.0/products/quarkfp1/overview/image/block.svg [7], and its pinout diagram can be found in Appendix A.

4.3.1 BLE BLE is a RF protocol specifically designed for low power, short range, low data rate

wireless communications. We decided to implement BLE technologies in our design as it satisfies a large variety of requirements of our product, namely requirement [R61-i]. The SoC is able to transmit at a maximum power of 0dBm, allowing for a transmission through free space of approximately 40m at maximum, greatly exceeding requirement [R44-i] of a 2m range connection [7].

4.3.2 ADC The ADC on the nRF52832 is a SAADC, featuring a 12-bit resolution without the need

for oversampling, fulfilling requirement [R47-i]. The ADC has 8 channels, exceeding our need to accommodate for 4 sensors. We will be implementing channels 4 through 7 to correspond with pins P0.28/AN4 through P0.31/AN7. The ADC also has a full scale input range of 0 to Vdd which is what the SoC is running at. The SAADC can sample at a maximum rate of 200 ksps (kilo samples per second), which meets our requirement for 10 samples per second [R59-i] [7]. The low output impedance of the signal conditioning circuit allows for a very high acquisition rate. A simplified ADC sampling network and a table of acquisition times can be found in Appendix A.

4.3.3 RF Hardware The benefits of using a SoC are exemplified by the wireless hardware integrated in

silicon on the same die as the processor. The nRF52832 contains a 2.4 transmitter and receiver compatible with 1 Mbps BLE connections. The Nordic SoC uses wireless protocol stack libraries called SoftDevices. The protocol runs on the CPU for a certain connection interval and uses the RF hardware on the SoC to communicate wirelessly with connected clients [7]. A description of the radio states and a state diagram for the radio can be found in Table 4.1 and Figure 4.6, respectively.

11

Table 4.1 – SoC radio states

Figure 4.6 – Radio state diagram [7]

4.3.4 Timer The nRF52832 features 5 32-bit timers with 2 modes of operation: timer and counter

[7]. A block diagram of the timer can be found in Figure 4.7 below.

The timer runs on the high frequency clock and can be divided down by the 4-bit prescaler. Clock source selection between PCLK16M and PCLK1M happens automatically according to the TIMER base frequency set by the prescaler. The PPI system, closely related to TIMER, allows a TIMER event to trigger a task of any other system peripheral of the device, which we use to trigger the sample task for the SAADC. The TIMER is started by triggering the START task and stopped by the STOP task [7]. These tasks will be triggered based on data received from the mobile device.

12

Figure 4.7 - Timer block diagram [7]

4.3.5 Memory The SoC has 512kB of nonvolatile flash storage and 64kB RAM [7]. Memory will be

utilized to store the sensor data before transmission and to hold firmware code. The nRF52832 complete memory map can be found in Appendix A.

5 Firmware Design The firmware running on the SoC within the BMH allows data to be collected from the

pressure sensors and sent wirelessly through BLE to the mobile application. Utilizing Nordic Semiconductor’s nrf52 SDK v9.20 and S132 SoftDevice, we are able to develop firmware that uses timers, an ADC, and BLE services to read sensor data periodically and transmit it in real time to the user interface. Nordic Semiconductor provides all the necessary libraries and project files needed to develop applications using Keil’s µVision® IDE & Debugger.

The Bluetooth protocol and stack is implemented through Nordic’s S132 SoftDevice firmware on the SoC. All hardware peripherals contained within the SoC are accessible through driver libraries supplied by Nordic.

In order to achieve 10 balance data updates per second, we need our data transmission for all sensors to take less than 100ms. Achieving 100ms from data collection to transmission ensures our user is receiving data in real time.

The firmware design is kept simple to ensure the fastest data throughput. The SoC will sample all pressure sensors periodically and send the data over BLE as soon as it is ready. A predefined header within the transmission identifies the foot that the data is received from. Data transmission will start once a successful connection is made and the mobile application sends an ENABLE command; sensor data transmission terminates

13

upon a DISABLE command from the mobile application. The main firmware application runs alongside the pre programmed S132 SoftDevice when the SoC is powered.

5.1 Data Collection The FSRs from the boot insoles are connected to analog input pins AIN4-AIN7 on the

SoC. The voltages they produce are converted to 12-bit signed integer values using the SAADC peripheral. This fulfills requirement [R47-i].

To set up periodic reads, we used a hardware timer and the PPI to trigger sampling on the SAADC. The PPI allows peripherals to interact autonomously with each other using tasks and events independent of the CPU [1eric]. Because the CPU is not utilized, the events are guaranteed to be sent consistently without computation onset delays. The driver libraries allow us to initialize all peripherals within the main firmware application.

We are able to initialize the hardware timer to compare every 100ms and send a NRF_SAADC_TASK_SAMPLE task through the PPI channel to the SAADC. The function saadc_sampling_event_init initializes TIMER1 and the PPI channel. The function saadc_init sets the SAADC to use 12-bit sampling resolution for our selected analog pins. Nordic’s documentation states that the maximum acquisition time for the SAADC is 40µs, which is enough time to sample all 4 FSRs sequentially within 100ms. Once the SAADC has completed the conversion, a NRF_DRV_SAADC_EVT_DONE event is sent to the main firmware application. Within our firmware application, the saadc_callback function receives the event and data to be sent to the Bluetooth service. Achieving a rate of 10 balance updates a second within the 100ms real time constraint fulfills requirements [R59-i] and [R69-i].

5.2 BLE Transmission In order to transfer data from the SoC to the mobile application, we used the Nordic

UART service (NUS), fulfilling requirement [R61-i]. A BLE service is a collection of data values - also known as characteristics - and relationships to other services that encapsulate the behavior of a BLE device [2]. The NUS consists of two characteristics: the TX characteristic, used for transmitting data; and the RX characteristic, used for receiving data. BLE networks use the following network topology as seen in Figure 5.1.

Figure 5.1 – Wireless transmission master-slave relationship

14

A central device, also known as the master, can be connected to multiple peripheral, also known as slave, devices. In our case, the mobile application is our central device, while both SoCs within the BMH are peripherals. Both the central and peripheral devices share the same service characteristics once connected. In order for the peripheral device to connect to the master, the peripheral device initiates its advertising mode upon turning on. In this mode, it waits to receive an event to connect from a central device and advertises its identity through a service ID and name. When the BMH updates the TX characteristic, the mobile application is notified of the change and reads the new value. When the mobile application changes the RX characteristic, the firmware running on the SoC is notified and reads the new data through event callback functions. Both TX and RX characteristics consist of an array of bytes known as buffers. For our application, we set both buffers to consist of a maximum of 10 bytes. Table 5.1 shows the breakdown of the case in which the maximum amount of data is being transmitted over a buffer.

Table 5.1 – Transmission buffer data breakdown

In order to implement Bluetooth connectivity, the SoC runs the Nordic S130 SoftDevice in conjunction with its main application. As explained earlier, it implements the Bluetooth protocol and stack through separate firmware on the chip. The SoftDevice can be initialized and controlled from the main firmware application using SoftDevice API calls.

In order to achieve the fastest transmission speed, the SoftDevice must be configured to send and receive data in short intervals. The length of time a BLE device is sending and receiving data when connected to a central device is called the connection interval. Within this interval, all communication between the peripheral and central device is performed. Between connection intervals, the BLE device sleeps and conserves energy. Since only a small amount of data is needed to be transferred, a short connection interval can be used. We configured the Soft Device's Connection interval to be set to 10ms. Thus all transmit and receive data must be communicated within the 10ms window.

To initialize the BLE connectivity for our application following functions are used:

• ble_stack_init - to initialize the BLE stack • service_init - to initialize the BLE services used by the firmware application • advertising_init - to initialize Advertising functionality • conn_params_init - to initialize the BLE connection parameters (such as

connection interval)

The NUS BLE service is initialized through the service_init function. The callback function on_ble_evt within the main application handles all incoming BLE events. The NUS

Buffer Header Balance Data (TX)

------------------ BMH Command (RX)

Total Data

TX 1 Byte 8 Bytes (10bits/sensor) 9 Bytes

RX 1 Byte 1 Byte 2 Bytes

15

service uses the API call ble_nus_string_send to write data on the TX buffer. We use this function to pass the data from the SAADC to the BLE service.

As mentioned in the firmware design overview, header data within each transfer is used to specify which BMH the balance data is being sent from. Tables 5.2 and 5.3 show the data structure used for TX and RX buffer transmissions, respectively. Once the saadc_callback receives an NRF_DRV_SAADC_EVT_DONE event after sampling, it packages the data into the correct packet structure and sends the data to the NUS service using ble_nus_string_send.

When the mobile application sends data to the BMH, a handler function nus_data_handler is used to receive the data and execute the specified command. As outlined in Tables 5.3 and 5.4, the possible commands sent from the mobile application, ENABLE and DISABLE, respectively enable or disable the SAADC sampling event discussed in the data collection section by using the functions saadc_sampling_event_enable and saadc_sampling_event_disable, respectively. In the case that the connection to the central device is lost, the SAADC sampling event will be disabled and the SoC will be put into advertizing mode awaiting reconnection. Figure 5.2 illustrates the program flow for the main firmware application.

Table 5.2 – Transmission data packet breakdown

Table 5.3 – Receive data packet breakdown

Byte # 0 1 - 8 9

Content Header FSR Data Unused

Left BMH

0x 4C 0x AA AA BB BB CC CC DD DD 0x 00

Right BMH

0x 52 0x AA AA BB BB CC CC DD DD 0x 00

* A = Sensor 1 Data, B = Sensor 2 Data, C = Sensor 3 Data, D = Sensor 4 Data

Byte # 0 3 4 - 9

Content Header Command Unused

Left BMH

0x 4C ENABLE | 0x45

DISABLE | 0x44

0x 00 00 00 00 00 00

Right BMH

0x 52

* ENABLE = enable SAADC sampling, DISABLE = disable SAADC sampling

16

Figure 5.2 – Firmware program flow

6 Software Design This section presents the detailed design of the mobile application. Although the mobile

application has the primary function as a user interface, it is also the framework behind all data processing in manipulating the data to be presentable and usable to the user. For this to be feasible, it must also be able to receive data from the BMH seamlessly.

As previously mentioned, our companion app for Floe is developed for the Android platform, to ensure maximal compatibility with users’ existing mobile devices, as well as for easy integration with an eventual Snow2 HUD device. The Android Software Development Kit (SDK) uses the Java programming language and contains lots of resources that make app development for the platform simpler as well as gives all Android apps a common, standard structure.

Receiving, analysing and displaying data from the BMH part of Floe are the main duties of the app. As the duty is very data-centric, the design of our app also had a lot of emphasis on the handling of said data. This section of our design specifications will briefly cover the simple user control flow of our app, and then describe in depth our app’s data structures, its process flow its data transmission functionalities, and its data-processing methods. We will close this section by discussing the app’s custom-made graphical user interface elements.

6.1 User Control Flow The high-level description of the user control flow within the mobile application can be

seen in Figure 6.1 below.

17

Figure 6.1 – Software control flow

6.2 Data Structures The Android SDK provides a pre-existing group of superclasses, from which we

extend our own inherited classes to make the app perform its duties. For the purposes of our app, we had to create inherited classes for the SQLiteHelper, Activity, Service, Binder and ServiceConnection superclasses.

Activities each represent a given screen of the app, and each activity has its own specific duty to perform. Because Activities have to produce the output that goes to the display without being held up, they do not perform intensive calculations themselves. For such calculations, we use classes inherited from the Service superclass. Services live on their own threads, which lets the current activity continually update the display without “hanging”. In our app, we need the Services to be able to communicate with the client that launched them to transmit data from the Service level to the Activity level (and thus to the user). This requires us to use “bound” services, which rely on classes inherited from the Binder and ServiceConnection superclasses to communicate between a service and its client.

To store and pass around the data collected from the sensors, we use a custom-made class called FloeDataPt. This class contains multiple attributes that store the unique identifier for the run during which the data was recorded (runID), the time at which the data was received (timestamp), the individual sensor values (sensorData[]), and the x, y coordinates of the centre of pressure (centerOfPressure). The class also has standard public “getter” and “setter” functions, as well as a constructor for an empty object. The final method of this class is a constructor that uses a BLE attribute as an argument, extracting from it all the data needed to fill in the FloeDataPt object’s own attributes. A UML class diagram for FloeDataPt class can be found in Figure 6.2.

18

Figure 6.2 – FloeDataPt UML class diagram

The storage of data points for later review by the user is handled by our FloeRunDatabase class, which itself is inherited from the SQLiteHelper superclass. This database implementation allows us to create a persistent record of all previously recorded runs and lets the user review them at any time using the app, as per functional requirement [R72-i]. The FloeRunDatabase class contains a table of all data points previously recorded, sorted by their runID for quick information retrieval. This database is stored on the Android device’s externally accessible storage, to allow the user to easily transfer it to an external device such as a computer for further analysis of the data, as per functional requirement [R70-i].

As mentioned earlier, our app uses multiple inherited classes to fulfill its duties. These classes necessarily rely on each other in a complicated web of inheritances and dependencies. The dependency and inheritance diagram in Figure 6.3 shows how all the implemented classes of our app are related.

Starting at the top of Figure 6.3, we see the MainMenuAct Activity, which is where the user first enters the app. From this class, the other Activities are inherited. Due to the way the Android system works, this makes it simple for the user to go back one step to the previous page (previous Activity). Most of the Activities rely on the FloeRunDatabase class to read or store data, and thus indirectly rely on the FloeDataPt class as well. Many of the Activities have their own bound Service, used to perform the more intensive calculations. Each bound Service relies on two inherited classes (one inherited from Binder and one from ServiceConnection) to do the communication between the service and its client.

19

Figure 6.3 – Floe App Dependency and Inheritance Diagram

The FloeDataTransmissionSvc Service is central to the data structure of our app as well. This is because it communicates with the two BLE Services (one for each boot) that gather the data from the BMH part of Floe and combines their data into single FloeDataPt objects that can then be used by other Services and Activities. The way in which it does this is described in Section 6.5. The Data Transmission and BLE Services are optimised for rapidity of execution, to ensure that our design meets functional requirement [R69-i].

An important thing to note is that Figure 6.3 only shows the classes used by the app that the Floe team develops itself. Indeed, the Android API contains many pre-defined classes and methods that our system relies upon. However, covering all of them here is unnecessary, as they are described in much detail in their own developers’ documentation [8].

6.3 Process Flow Design In Section 6.1 of this document, we offered a description of the simpler user control flow

of the Floe app. While this reflects all the information that will be visible to the user while he uses the app, the underlying processes occurring in the app are more complex than what the user sees. An overview of the app’s process flow can be found in Figure 6.4.

20

Figure 6.4 – Floe App Process Flow Diagram

Once the app is started, the user is presented with the main menu, which offers four choices. Upon picking the Calibration option, the app launches the FloeCalibrationAct Activity, which is meant to perform the initial calibration of Floe with the user’s weight. The Activity opens the database of runs, displays instructions and then launches the FloeDataTransmissionSvc Service, which in turn launches the FloeBLE1Svc and FloeBLE2Svc Services. The BLE Services connect the Android device to the BMH and pipe data from the BLE connection to the Data Transmission Service, which combines the data from each boot into FloeDataPt objects, which it then sends to the Calibration Activity. The Activity performs the necessary calibration operations and stores the calibration data in the Run database for future reference. Upon completion of the process, the user is notified and given the option to return to the main menu. When the command to go back to the main menu is given, the Calibration Activity is destroyed, and all of its bound services (data transmission and BLE) are destroyed at the same time.

The processes work in a similar manner for the other main menu options. When the user picks the RT Feedback option, the FloeRTFeedbackAct Activity is launched. It in turn connects to the run database to access the calibration data, and launches the FloeRTFeedbackSvc Service. This Service is in charge of generating the images that are displayed by the RT Feedback Activity, as described in Section 6.4. When launched, the RT Feedback Service launches the Data Transmission Service, which in turn launches the BLE Services. The data sensor is collected from the BMH in the same way as

21

previously, and the images created by the RT Feedback Service are sent to the Activity for display. When the user chooses to go back to the main menu, the Activity and its bound Services are once again destroyed.

Upon choosing the Record Run option from the main menu, the FloeRecordingAct Activity is launched. This Activity is special, because it and its bound Services are not interrupted when the device is locked, which allows data to be recorded even when the device is locked. Upon being launched, the Recording Activity performs the now-familiar steps of opening the run database and launching the Data Transmission and BLE Services that allow our app to collect data from the BMH. The data arriving in the Recording Activity is stored in the Run Database with a unique runID, to allow easy identification and sorting of data during review. When the user stops the recording session and returns to the main menu, the activity and its services are destroyed.

The fourth option in the main menu follows a different process than the other options. Once the user picks this option, the FloeReviewListAct Activity is launched. This Activity opens the Run Database, and looks into it to find all the different runs that are store inside of it. The Review List Activity presents the user with a list of such runs, and prompts him to pick one to review. When such an action is performed, the FloeRunReviewAct Activity is launched. This activity is already connected to the database through its parent, and launches the FloeRunReviewSvc Service. The Run Review Service looks into the Run Database for all the FloeDataPt objects with the correct runID and creates graphs from the data. The graphs, along with all the relevant run information, are sent to the Run Review Activity, which displays them for the user. If the user wishes to modify the name of a run or delete it from memory, he can do so. The command will be passed on to the Run Review Service, which will perform the action in the database. When the user decides to go back to the list of runs, the Run Review Service and Activity are destroyed. The Review List Activity is destroyed when the user decides to go back to the main menu.

6.4 Data Transfer As mentioned previously, the transmission of data from the MBH to the app’s

Activities is done through three Services. The two BLE Services, FloeBLE1Svc and FloeBLE2Svc, are the first to see the data as it arrives from the BMH. Upon being launched, the Services scan for available BLE devices, and connect to the BMH. Once the connection is established, they send to their respective BMH a signal to start collecting data. The two BLE services communicate with the Android device’s Bluetooth adapter through the BLE methods and classes included in the Android API. The profile used for the transfer of data is that developed by the firmware specialist of the Floe development team, as described in detail in Section 4 of this document.

Every time the BLE Services receive a packet of data, they pass it on to the FloeDataTransmissionSvc Service through the IBinder objects created when the BLE services are launched. When the Data Transmission Service has received a packet from each BLE Service, it separates it into its constituent pieces. The next step is to convert the raw sensor data (in voltage units) into force units, which is done by a simple exponential operation. The converted sensor data is then used to calculate the user’s centre of pressure. Once this is done, the sensor data and the centre of pressure coordinates are collected into a proper FloeDataPt object, which is passed on through

22

another IBinder object to the Activity or Service that launched the Data Transmission Service. From then on, with the sensor data neatly packed into a standard object, the rest of the app can manipulate it as is necessary.

6.5 Data Processing Upon receiving the sensor data from the BMH, the program assigns these values to

value names to be calculated into usable information. The specific value assignments are described as sxx, xx corresponding to the labels in Figure 6.5 below. Each value has two distances in the form of dab measured from the x- and y-axes, with a corresponding to the sensor number and b corresponding to the axis it is measured from.

Figure 6.5 - Sensor data software value assignment

Prior to calculating the CoP, the program requires a stage called “weight calibration”. Though this stage does not actually calculate the weight of the user, it takes the relative value needed to calculate the CoP later on. The “weight” is simply the average of the sum of all the sensor values, stotal, shown in Equation (2), over 75 instances.

𝑠!"!#$ =   𝑠!! + 𝑠!! + 𝑠!! + 𝑠!! + 𝑠!! + 𝑠!! + 𝑠!! + 𝑠!!

(2)

From then on, during the run recording and real-time feedback functionalities, the values are calculated into the two coordinates representing the user’s CoP using Equations (3) and (4) below.

𝐶𝑜𝑃! =  (𝑠!! − 𝑠!!)𝑑!! + (𝑠!! − 𝑠!!)𝑑!! + (𝑠!! − 𝑠!!)𝑑!! + (𝑠!! − 𝑠!!)𝑑!!

𝑠!"!#$

(3)

𝐶𝑜𝑃! =  (𝑠!! + 𝑠!!)𝑑!! + (𝑠!! + 𝑠!!)𝑑!! + (𝑠!! + 𝑠!!)𝑑!! − (𝑠!! + 𝑠!!)𝑑!!

𝑠!"!#$

(4)

23

6.6 Display Once calculated, the CoP will be able to be displayed to the user in two different

modes: under real-time feedback functionality or post-run review functionality. The former must not be distracting to the user and abide by requirement [R78-i].

Our design for an intuitive, non-obstructive real-time feedback display can be seen in Figure 6.4 below, in which case (a) shows all of the available indicators within the GUI, and (b) through (f) show 6 different cases that could occur.

Figure 6.6 – Real-time GUI cases

The appearance of a yellow strip indicates the user’s weight is slightly off to its corresponding side, where the appearance of a red strip indicates the user’s weight is much too weighted on its corresponding side. These coloured strips appear when the CoP of a user crosses certain thresholds in the x- and y-axes. The threshold for the yellow strip corresponds to the user exiting the centre third (division by three) of the overall balance grid, and the threshold for the red strip corresponds to the user entering the outer quarters of the balance grid.

24

Our design for the post-run analysis consists of two line graphs depicting the user’s CoP deviation from their balance origin against time; the first corresponds to the anteroposterior CoP, and the second corresponds to the mediolateral CoP. Examples of these graphs can be seen in Figure 6.7 below.

Figure 6.7 – Post-run analysis graphs

7 Test Plan To ensure that Floe works as planned for all users, extensive testing must of course

be conducted. This testing takes place mostly at the component level during the development of Floe, with whole-system testing following when nearing project completion.

7.1 Component Testing

7.1.1 Physical The physical testing of Floe is separated in two, for the two physical parts of the design.

25

First, the BMH enclosure must be subjected to a variety of operating environments and actions, and observations must be made to ensure the following:

• That the BMH housing does not leak when submerged in water;

• That the BMH remains stable inside its enclosure when various shock forces are

applied;

• That the BMH housing retains its structural integrity when various shock forces are

applied;

• That the BMH is securely fastened to the ski boot strap.

Second, the insole must be subjected to a variety of opera ting environments and actions, and observations must be made to ensure the following:

• That the insole works properly after being bent in a reasonable range of motion;

• That the insole works properly in various humidity and temperature conditions.

7.1.2 Hardware The hardware side of Floe requires testing on two different fronts.

Firstly, the BMH hardware is to be monitored under a variety of operating conditions and measurements must be taken to ensure the following:

• That power consumption stays within the acceptable operating range at all times;

• That device temperatures stay within the acceptable operating range at all times;

• That the sensors output correct force values;

• That the sensors operate accurately within the correct force range.

Second, the electrical hardware components incorporated into the insole must be monitored under a variety of operating conditions and measurements must be taken to ensure the following:

• That the pressure sensors give the correct output voltages over the whole range of

possible physical loads;

• That all wiring in the insoles maintains full integrity.

7.1.3 Firmware The firmware part of Floe lives entirely on the BMH SoC. For that reason, all firmware

testing will require use of at least one of the SoC chips.

Firstly, the firmware is to be tested for proper functionality. Appropriate debugging tools are to be used to monitor the firmware’s behaviour under a variety of operating conditions and ensure the following:

• That enable and disable commands are received and executed correctly;

• That no clipping occurs for any value over the full range of the ADC;

• That data is transmitted within real-time constrains (i.e. >15 times/second);

• That the data being transmitted is the same as that collected locally on the chip;

26

Second, the firmware is to be tested for reliability. This will once again require the use of appropriate debugging tools to monitor the firmware’s behaviour under a variety of operating conditions and ensure the following:

• That no critical errors occur during prolonged operating sessions (i.e. >10h);

• That no critical errors occur when repeatedly connecting and disconnecting (i.e.

>20 times) a device.

7.1.4 Software The Floe app, due to its complexity and the large number of interacting components, is

difficult to test under all possible operating conditions and for all combinations of user input. For that reason, different components of the app are to be tested separately, and some test cases are to be used to test the app as a whole.

First, proper functionality of each of the classes created by the Floe software development team is to be tested individually with the help of appropriate debugging tools to ensure the following:

• That every method of every class executes correctly and reliably;

• That every attribute of every class holds the proper data.

Second, proper interaction between objects at runtime must be confirmed. Communications between Services and their clients, as well as are to be tested with the help of appropriate debugging tools to ensure the following:

• That all Services bind correctly and reliably to their clients;

• That all Services can communicate correctly and reliably with their clients;

• That all objects are created at the proper point in the app’s execution, and that

they are created correctly and reliably.

Third, the data reception, storage, retrieval and manipulation mechanisms of the app must be tested for reliability and functionality. Appropriate debugging tools are to be used to ensure the following:

• That the connections to both boots is established correctly;

• That data packets are received and unpacked correctly;

• That FloeDataPt objects are constructed correctly;

• That the Run Database can be opened and closed correctly and reliably;

• That data in the Run Database is persistent over multiple uses of the app;

• That data in the Run Database is exportable, and that it is usable once exported;

• That data can be recorded while the device is locked;

• That the graphics generated for the user match the data used to generate them

exactly;

• That the parts of the app that must operate under real-time constraints (RT

Feedback, Data Transmission, BLE Services), do so.

27

Fourth, the system as a whole must be tested to ensure reliability and functionality. Appropriate debugging tools are to be used to ensure the following:

• That the user can navigate between screens easily, reliably, and without lag;

• That the app controls are intuitive (also requires test subjects);

• That the correct objects and processes are created and interact correctly and

without lag.

7.2 System Testing Once all individual components of Floe have been tested thoroughly for functionality

and reliability, the system is likely ready to be fully assembled and tested as a whole. If all components performed well on their own, the risk of malfunctions of the system should be much reduced.

At this point, the system should be subjected to the same testing procedures described previously in this Section, to verify that the desired output is produced for any given input to the system. Once such tests give satisfactory results, Floe is ready for live testing on real ski slopes. Many runs of varying lengths and topology are to be recorded with Floe as well as with a video camera for the purpose of comparing the recorded data with filmed observations of the skier’s balance throughout the run.

The same procedure is to be repeated for the real-time feedback functionality of the app. The filmed footage of the skier can be compared with filmed footage of the Android device’s screen to validate the feedback given by Floe.

8 Conclusion In this document, we have laid out in detail the design specifications of Floe: the

Athletic Balance Monitoring System for Skiers. These design specifications were developed to completely fulfill the functional specifications described in Pinnacle Biometrics’ Floe Functional Specifications document. The current document is to help the development team create Floe in a coordinated manner and with a common, agreed-upon view as to how to fulfill the previously defined functional specifications.

By separating the design specifications into four main areas of development, this document makes it simpler for the team responsible for each part of Floe to find the details and objectives pertinent to their own work. This document also outlines where the connections between different development groups’ work occur. That is to help the groups in question understand when to work together to work out kinks in the design and make Floe as coherent and well-performing a product as possible. By providing a test plan for every area of development, as well as a plan for testing the product as a whole, this document also sketches out a framework to evaluate the success of the team’s efforts towards the creation of Floe. This framework ensures that each sub-section of Floe is ready for action before attempting to merge them together, thus minimizing the risk of intractable problems that could arise during whole-system testing.

It is important to note that, while this document has the goal of defining as precisely as possible the final design of Floe’s proof-of-concept implementation, such an

28

implementation is not complete as of the time of the writing of this document. Therefore, it is possible that some small changes will have to be made to the design between the time of writing and the time of product delivery. These changes could be due to unforeseen problems arising from the current design, or from improvements to the current design that are too beneficial to Floe to pass up. When making such changes, the utmost care must be taken to ensure that they do not negatively affect the rest of Floe. The design specifications presented in this document were conceived to work together across different areas of development, and unilateral change in one area could make another area’s design unworkable.

Barring any large, unpredictable setbacks in development, this document is to serve as a final roadmap to the completion of Floe’s proof-of-concept version. The separation of design specifications into four areas of development will help the team at Pinnacle Biometrics focus on developing and perfecting the components within each member’s own area of expertise, and ensure that the resulting product is of the highest quality possible.

29

References

[1] Functional Specifications for Floe: the Athletic Balance Monitoring System for Skiers, 1st ed. Pinnacle Biometrics, 2016, pp.4-12.

[2] FSR 402 Data Sheet, 1st ed. Interlink Electronics, 2016, pp. 1-4.

[3] Force Sensing Resistor Integration Guide and Evaluation Parts Catalog, 1st ed. Interlink Electronics, 2016, pp. 1-26.

[4] “FSR tutorial | Open Music Labs", Openmusiclabs.com, 2016. [Online]. Available: http://www.openmusiclabs.com/learning/sensors/fsr/. [Accessed: 11- Mar- 2016].

[5] “Using an FSR | Force Sensitive Resistor (FSR) | Adafruit Learning System", Learn.adafruit.com, 2016. [Online]. Available: https://learn.adafruit.com/force-sensitive-resistor-fsr/using-an-fsr. [Accessed: 11- Mar- 2016].

[6] MCP6001/1R/1U/2/4 1 MHz, Low-Power Op Amp, 1st ed. Microchip, 2016, pp. 1-42.

[7] "nRF52832 System on Chip", Infocenter.nordicsemi.com, 2016. [Online]. Available: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52/dita/nrf52/chips/nrf52832.html. [Accessed: 11- Mar- 2016].

[8] Android. (2016, March 10). Introduction to Android | Android Developers [Online]. Available: http://developer.android.com/guide/index.html

30

Appendix A

Figure A.1 – Complete FSR 402 dimensions [2]

Figure A.2 – Polymer thick film FSR construction [3]

31

Figure A.3 – nRF52832 pin layout

32

Figure A.4 – Simple ADC sample network

Table A.1 – ADC acquisition times

33

Figure A.5 – nRF52832 complete memory map [7]