DATA ACQUISITION FOR

IMPROVEMENTS IN MOUNTAIN
BIKE RACING
Mechanical Engineering Honours Project
2017/18

Stewart Lowe - 130015085

Supervisor: Dr. Keith Johnston

Word Count: 18831

 ACKNOWLEDGEMENTS

I’d like to show my gratitude to my project supervisor, Dr. Keith Johnston, for all of his
help and guidance over the course of writing this paper, and to the members of DUMRCC
for their assistance.
 ABSTRACT

Downhill and Enduro mountain bike races see athletes compete on timed downhill
sections of track, encompassing rough ground, drops, jumps, and banked turns. While
electronic data acquisition systems in road cycling are widely used to monitor position,
speed, heart rate, and power, they are less so utilised in the Downhill and Enduro
disciplines. The scientific literature on the subject suggests that due to the dynamic nature
of these races, power and heart rate data does not satisfactorily quantify performance. The
current study describes the development of a data acquisition system for the gathering
and analysis of more in-depth performance data.

The system developed herein used an Arduino microcontroller to read position speed and
time from a GPS module, front and rear suspension travel from slide potentiometers, and
front and rear braking force, measured at the piston by force sensitive resistors. The data
is either stored on an SD card for post-processing or transmitted wirelessly, via 2.4GHz
antennae to a second Arduino which sends the data into a program written in Python for
real-time analysis and post-processing.

The study was successful in developing methods of sensing suspension travel, braking
force, and position. The measurements were obtained and wirelessly transmitted via the
radio antenna to a PC. The Python post-processor performed satisfactorily by displaying
data in real time, as well as logging to a spreadsheet for storage and future analysis. The
study did not, however, come to any conclusion on the usefulness of the braking data
acquired, due to lack of system tests under real conditions. Additionally, the study was
unsuccessful in logging data to an on-board SD card, limiting the usability of the system
in its current form.
 TABLE OF CONTENTS

Chapter 1 Introduction............................................................................................... 1
1.1 Aims and Objectives ..................................................................................... 1
1.2 Literature review ........................................................................................... 1
1.2.1 Physiological Demands of Mountain Biking .......................................... 1
1.2.2 Mountain Bikes ..................................................................................... 2
1.2.3 Global Positioning System .................................................................... 4
1.2.4 Force Sensors ........................................................................................ 4
1.2.5 Displacement Sensors ............................................................................ 6
1.2.6 Microcontrollers .................................................................................... 8
1.2.7 Data Acquisition.................................................................................... 9
1.2.8 Universal Testing Machines ................................................................ 10
1.2.9 Strava .................................................................................................. 11
Chapter 2 Materials and Methods ............................................................................ 12
2.1 Apparatus.................................................................................................... 12
2.1.1 Bicycle ................................................................................................ 12
2.1.2 Force Sensors ...................................................................................... 13
2.1.3 Displacement Sensors .......................................................................... 13
2.1.4 Mounting Hardware ............................................................................ 14
2.2 Electronics and software ............................................................................. 17
2.2.1 Sensor Circuits .................................................................................... 17
2.2.2 Microcontroller ................................................................................... 18
2.2.3 GPS Module ........................................................................................ 18
2.2.4 Telemetry ............................................................................................ 20
2.3 Sensor Calibration....................................................................................... 21
2.3.1 Force Sensors ...................................................................................... 21
2.3.2 Displacement Sensors .......................................................................... 23
2.4 Post-processing ........................................................................................... 23
2.5 Suspension Sensor Testing .......................................................................... 24
Chapter 3 Results and Discussion ............................................................................ 25
3.1 Force Sensor Calibration ............................................................................. 25
3.2 Displacement Sensor Calibration................................................................. 26
3.3 GPS Tracker Testing ................................................................................... 27
3.3.1 Update Rate......................................................................................... 29

i
 3.3.2 Strava Compatibility............................................................................ 29
3.4 Antenna Testing .......................................................................................... 30
3.4.1 Data Rate ............................................................................................ 30
3.5 Suspension Tuning Test .............................................................................. 32
3.5.1 Test 1 Results - Minimum Damping Settings....................................... 33
3.5.2 Test 2 Results - Medium Damping Settings ......................................... 34
3.5.3 Test 3 Results - Maximum Damping Settings ...................................... 35
3.5.4 Comparison and Discussion of Suspension Tests ................................. 36
3.6 Post Processing ........................................................................................... 38
Chapter 4 Conclusions............................................................................................. 41
Chapter 5 Future Work ............................................................................................ 43
5.1 Limitations .................................................................................................. 43
5.2 Additions .................................................................................................... 46
Bibliography .............................................................................................................. 48
Appendix A - Safety Assessment............................................................................. 53
Appendix B - Time Management Diagram .............................................................. 56
Appendix C - Detailed Photographs of Mounting Hardware .................................... 57
Appendix D - Sensor Calibration ............................................................................. 59
Appendix E - GPS Test Code .................................................................................. 60
Appendix F - Receiver Code ................................................................................... 62
Appendix G - Transmitter Code .............................................................................. 64
Appendix H - GPX Wrapper for GPS Data.............................................................. 66
Appendix I - Post-Processor Code.......................................................................... 67
Appendix J - Suspension Velocity and Acceleration Graphs................................... 70

ii
 LIST OF FIGURES

Figure 1: A diagram of the construction of a force sensitive resistor (a), and the method
by which conductive elastomers and pressure sensitive inks create a change in
resistance with applied force (b)............................................................................ 5
Figure 2: The Arduino Uno .......................................................................................... 8
Figure 3: The Tinius Olsen H5KS benchtop material testing machine ......................... 10
Figure 4: Strava analysis of a ride, showing the various recorded quantities over the
distance of the ride; altitude, speed, power, heart rate, cadence, and temperature. 11
Figure 5: YT Industries Wicked 650b ......................................................................... 12
Figure 6: Flexiforce piezoresistor ............................................................................... 13
Figure 7: The RS Pro Linear Transducer..................................................................... 14
Figure 8: CAD model showing the mounting hardware for the rear suspension
displacement sensor mounted on the shock absorber ........................................... 14
Figure 9: (A) CAD model showing how the displacement sensor will mount to the fork.
The sensor body (green) is mounted to the fork lowers, while the end of the actuator
rod is affixed to the crown (topmost part of the fork assembly) (CAD files for the
fork taken from GrabCAD), (B) Upper fork bracket, (C) Lower fork bracket ...... 15
Figure 10: Sensor apparatus and transmitter mounted to the bike, with a laptop running
the post-processor connected to the receiver (Shown highlighted in yellow).
Highlighted in red is the fork displacement sensor, in green the electronics case in
blue are the brake force sensors........................................................................... 16
Figure 11: The electronic components inside the case to mounted on the bike. The
Adruino cannot be seen, it is beneath the blue GPS shield at the right of the case 17
Figure 12: Schematic of the sensor circuits connected to the Arduino Uno ................. 18
Figure 13: Example of a GPX trackpoint coded in XML. As well as elevation and time,
trackpoints can contain other activity data such as heart rate, power, and cadence.
........................................................................................................................... 19
Figure 14: The experimental setup for calibrating the force sensors using the Tinius Olsen
material testing machine ..................................................................................... 23
Figure 15: Graph showing how the output value from the Arduino varied with applied
force ................................................................................................................... 25
Figure 16: Voltage versus Distance curve for the displacement sensor on the suspension
fork..................................................................................................................... 26

iii
Figure 17: Voltage versus Distance curve for the displacement sensor on the rear shock
absorber .............................................................................................................. 27
Figure 18: Display of GPS path on Google Maps........................................................ 28
Figure 19: The GPS path with higher latitude and longitude resolution ....................... 28
Figure 20: Figures showing timing of the outputs to the serial monitor for both
configurations. (Left: 1Hz, RMC and GGA sentances, right: 10Hz, GGA sentence
only) ................................................................................................................... 29
Figure 21: Stava analysis of the GPS test data, showing speed and estimated power ... 30
Figure 22: The GPS data with time stamps, as received by the antenna during bench
testing. ................................................................................................................ 31
Figure 23: The transmitted data for the second bench test, including simulated suspension
and braking values. Highlighted in red are the points where a data set was lost. .. 31
Figure 24: The serial monitor after the program had been altered to increase the baud rate.
Note the presence of a data set approximately every 100ms. ............................... 32
Figure 25: Suspension displacement versus time during the first drop test, with the
rebound and compression damping set to the minimum. ..................................... 33
Figure 26: Suspension displacement versus time for the second drop test with the medium
rebound and compression damping settings. ....................................................... 34
Figure 27: Suspension displacement versus time for the drop test with rebound and
compression damping set to maximum................................................................ 35
Figure 28: The plots produced by the post processor from the random sensor data being
streamed by the Arduino. .................................................................................... 39
Figure 29: The broken tabs on two displacement sensors. ........................................... 45
Figure 30: The electronics case mounted to the frame. Also pictured are the radio
(Indicated with blue box) and GPS antennae (indicated with green arrow), as well as
the Garmin Edge 810 head unit used to keep track of speed. ............................... 57
Figure 31: Left shows the front suspension displacement sensor mounted to the fork.
Right shows a detailed view of the fork displacement sensor connection and the front
braking force sensor mounted in the caliper (circled blue). Arrows show how the
sensor wiring (green and blue) are routed to the electronics case by following the
brake hose (yellow) up the fork leg. .................................................................... 57
Figure 32: Left shows the broken wiring for the rear brake force sensor, most likely due
to suspension movement. Right shows how the brake force sensor mounted into the
caliper. ................................................................................................................ 58
Figure 33: Suspension Velocity versus Time - Minimum Damping ............................ 70

iv
Figure 34: Suspension Velocity versus Time – Medium Damping .............................. 71
Figure 35: Suspension Velocity versus Time – Maximum Damping ........................... 72

v
 LIST OF TABLES

Table 1: A table showing the change in position, maximum velocity, and maximum
acceleration for each of the four suspension events, in each of the three tests. ..... 36
Table 2: The tabulated data produced by the Python post processor. Note; the first line of
data returns 0 for all GPS data (time, latitude, longitude, and speed) ................... 40

vi
 CHAPTER 1 INTRODUCTION

Telemetry and data acquisition systems are becoming extensively used in many sports;
from GPS trackers to monitor players' movements around the field in team sports such as
football and rugby, to advanced use in high-level motorsport, electronic data is becoming
increasingly important to stay competitive in high-level sport. During races and training
camps, professional road cycling teams use electronic systems to monitor, amongst other
things, speed, heart rate, pedalling cadence, and power output of their athletes and relay
this information to coaches and team managers in a car following the group, or save the
data for analysis afterwards. Whilst this technology is almost ubiquitous in elite road
racing, the concept of telemetry has gained little traction in the world of mountain biking;
even at the highest level of downhill and enduro racing, it is rare for teams to utilise much
more than a GPS based cycle computer and heart rate monitor.

1.1 AIMS AND OBJECTIVES

This project aims to create a data acquisition system for use in downhill and enduro
mountain bike racing. The system should monitor variables such as speed, suspension
travel, and braking force in an attempt to give riders, coaches, and mechanics a more
complete understanding of the physical and technical demands of a particular course and
the areas of the rider’s technique or physical condition on which he/she should improve.
The data gained from the use of the system should give information to assist in the optimal
race strategy, training programs, and adjustments to bike setup.

1.2 LITERATURE REVIEW

1.2.1 Physiological Demands of Mountain Biking

Although power meters are widely used in other types of cycling their use is limited in
downhill and enduro racing, even at an elite level. Hurst & Atkins (2006) investigated the
effect of power output and cadence on the lap times of downhill cyclist competing at a
national level event. The study showed that peak power was not closely related to run
time; all riders reached their peak power out of the start gate and once the rider was up to
speed, pedalling was required only to maintain speed and to overcome deceleration due
to braking or technical trail features, where local peaks in power were observed. The
riders heart rate was relatively steady for the length of the course, and mean heart rate
was not found to have a significant correlation to run time. It was concluded that difficult
1
terrain encountered on downhill courses create a condition whereby the rider is prevented
from pedalling for much of the run, around 55% of the run was spent at freewheel, with
the average pedalling action shorter than 5s. This suggests the rider has less choice as to
where on the course power can be produced to maintain speed, and implies that technical
skill is more important than physical condition for these technical sections and a
successful rider must achieve a balance between the two.

Hurst et al. (2013) furthered the work mentioned above by using GPS tracking to perform
time-motion analysis on elite downhill mountain bikers. The study focuses on how the
terrain of the course changes the physiological demands on the rider by comparing data
obtained from two tracks; one was a ‘man-made’ course, characterised by a smoother trail
surface, large jumps, and banked corners; and one a ‘natural terrain’ course, which uses
the topography of the area to guide the track and act as features. The study found that the
differing track characteristics which can be encountered in downhill racing impose
differing demands on the rider and influence the style of riding adopted. The runs on the
man-made track exhibited a higher average speed, likely due to banked, shallow corners
allowing for less braking, as well as the smoother surface, more agreeable to high speeds.
Contrastingly, the tighter turns and uneven surface of rocks and tree roots found in the
natural terrain course forced riders to brake more and afforded less pedalling opportunity,
resulting in the slower average speeds observed. It also confirmed the work of Hurst &
Atkins (2006); that performance in downhill mountain biking may not be fully quantified
using heart rate and power data alone. The literature considering the physiological
demands of downhill mountain biking suggest that the dynamic loading experienced by
the rider may be of equal or greater importance than power output, and parallels are
evident between the demands of downhill mountain biking and the demands of off-road
motorcycling; in a study into the oxygen consumption of downhill mountain bikers, Burr
et al. (2012) commented on the similarity of the oxygen demands on off-road
motorcyclists found by Burr et al. (2010).

1.2.2 Mountain Bikes

The design of mountain bikes was not seriously researched until the sport became
professional in the 1990s. By collating work which modelled arms (Wong & Hull, 1981)
and legs (Greene & McMahon, 1979), as well as developing component systems for the
saddle, pedals, wheels, and fork, Wilcsynski & Hull (1994) created a dynamic system
which replicated experimental data (acquired by having cyclists ride an instrumented
2
bicycle in a standing and sitting position). This work was furthered by Wang & Hull
(1997) by also considering the resonant frequency of the cyclist’s internal organs, and
modelling the riders head as a separate mass from the torso. The model was split into
upper and lower body and was simulated for a sitting position and two standing postures;
one as in the work of Wilczynski & Hull (1994) (a standing position suited to pedalling
on flat ground), and one in a descending posture, where the riders weight was shifted
backwards with around 90% being transmitted through the pedals, as opposed to around
70% in the standard standing position. Although Wilczynski & Hull (1994) comment on
the need for mountain bike suspension to help in the prevention of fatigue and injury, and
Wang & Hull (1997) comment on the potential for their results to be used in the
development of mountain bike suspension systems, both studies were carried out at a time
when suspension in mountain bikes was not commonplace and severely limited in
performance by today’s standards.

It has been shown that suspension in mountain bikes can improve performance in many
situations; it has been shown that 8 cyclists over a 30-minute test showed an increase in
speed when riding a bike suspended front and rear compared to riding a bike with front
suspension only, although the athletes had to output a higher average power over the 30
minutes (Nishii, et al., 2004). This is since, just as suspension dissipates energy induced
from the irregular riding surface, it can also dissipate energy produced by the rider. There
has been some research into the extent of the energy absorbed by suspension systems;
one study showed only a 3% difference in oxygen consumption at a set power between a
fully rigid, front suspended, and fully suspended bike (Neilens & Lejeune, 2000).
However, limited conclusions may be drawn from this research, as the test was carried
out in a laboratory on a stationary bike. Another study investigated the difference between
a full suspension and front suspension mountain bike on two uphill courses; paved and
un-paved. The study found no difference in time on the paved course and a negligible
difference in time on the un-paved course, however average power output was
significantly higher for the full suspension bike (MacRae, et al., 2000). The relevance of
these results to modern downhill and enduro racing, however, is limited; these tests were
carried out on bikes with 100mm or less suspension travel whereas modern enduro bikes
tend to have 160-170mm, and downhill bikes at least 200mm. The fact that most cross
country athletes sacrifice the comfort and control of full suspension to race with front
suspension bikes suggest that energy losses due to suspension may be more significant
than these studies suggest, therefore proper suspension set up is vital to performance.

3
1.2.3 Global Positioning System
The Global Positioning System (GPS) is system of 24 satellites, with a network of
systems on the ground which act as support for these satellites. It provides positioning
data to users by time of arrival ranging from four satellites; one to synchronise the clock
of the receiver to the GPS ‘system time’, and three to determine position. The Standard
Positioning Service (SPS) is the service provided by GPS for unrestricted civilian use,
with Precise Positioning Service (PPS) being reserved for military, government, and US
Department of Defence approved civilian applications (Kaplan, 1996). The use of GPS
for tracking displacement and speed during sporting activity is well documented; it was
found that the speed of humans on foot can be tracked with high accuracy for a range of
speeds, with only a minimal lessening in accuracy due to bends (Townshend, et al., 2008).
This is in agreement with the earlier work of Witte &Wilson (2004), which found that
GPS tracking systems could accurately collect acquire speed data from a cyclist, however
it was noted that speed was underestimated in bends, with the underestimation increasing
with a decrease in bend radius.

1.2.4 Force Sensors

The unit of force, a Newton, is defined as the force require to accelerate 1 kg by 1 ms-2,
and can be measured in many ways, both directly and indirectly. Indirect measurements
of force can most simply be achieved by balancing the force with a known mass, as in
traditional balance scales, however modern, electrical methods may derive force from the
distance that a spring is compressed under load; by measuring the mechanical strain in a
load cell using strain gauges; or by using the force to pressurise a fluid and measuring the
resultant pressure. The measurement of force by converting force directly to an electrical
signal is less common but can be achieved by taking advantage of the piezoelectric effect
which is present in many natural crystals, manmade ceramics, and some polymers.

Piezoelectric materials can be used to create transducers which covert force directly into
an electrical signal by utilising the fact that in a crystalline piezoelectric material, a force
causes a rearrangement of atoms, and resultant difference in electrical potential at
different areas of the crystal. For example, in a quartz (SiO2) crystal, silicon atoms have
charge of positive 4, where the pair of oxygen atoms have charge of negative 4, creating
a neutral overall charge when the crystal is subject to zero strain. When the crystal

4
receives a tensile or compressive force, the induced strain causes a reordering of the
crystal structure, creating a potential difference between different areas of the crystal
(Fraden, 2016). This basic effect, however, is limited in it use in sensors of force by the
fact that voltage is only created in response to a changing force, while a constant force
would produce no force. This can be overcome by taking advantage of the fact that the
piezoelectric effect is reversible: as well as an applied strain creating a voltage, a voltage
applied to the material will create a strain. If one set of electrodes is used to create an AC
excitation voltage in the piezoelectric material, and another set used to measure the
resultant strain, the measured voltage will change in frequency with a constant applied
load.

All materials undergo some change in electrical resistance when they are subject to
mechanical strain due to the piezoresistive effect. Strain gauges are comprised of a
resistor of metal foil or a semi-conductive material on an adhesive backing, which is
attached to the surface of the strained member, as the member is loaded the strains in the
direction of the gauge cause a change in resistance; an increase in tension and a decrease
in compression. Force sensitive resistors (Figure 1) also exhibit a piezoresistive effect;
they are constructed of a conductive elastic polymer, or may be printed in the form of
pressure sensitive inks. Conductive elastomers are typically silicon rubber or
polyurethane combined with conductive particles to create a conductive composite. When
this composite is compressed, the elastomer deforms and allows the conductive particles
to move closer other, if the particles are in contact, electrons may move between them by
conduction, and close enough proximity of the particles allow electron hopping and
quantum tunnelling.

Figure 1: A diagram of the construction of a force sensitive resistor (a), and the method
by which conductive elastomers and pressure sensitive inks create a change in resistance
with applied force (b) (Fraden, 2016)

5
Force sensitive inks work on similar principles, they contain small particles of metal
oxides; both conductive and insulating. The ink is printed into the desired sensor shape,
then dried and sintered to combine the conductive and insulating oxides into a single force
sensing element, which, when deformed, moves the conductive particles into closer
proximity, lowering resistance.

1.2.5 Displacement Sensors

Displacement or position may be measured in many ways, some requiring physical
movement of parts of the sensor in relation to others, such as LVDTs or linear
potentiometers, whilst some use optical, ultrasonic, or capacitive effects to determine the
position or movement of an object.

A potentiometer is a voltage divider comprising of a resistive element, across which an

excitation voltage is applied, and a movable wiper where voltage is measured. Since the
elements resistance increases with length, the potential difference between the wiper and
ground will vary linearly depending on its position. A potentiometer is a ratiometric
device; the voltage output depends only on the excitation voltage and the ratio of wiper
displacement and maximum displacement and, for this reason, changes in resistance due
to temperature have little effect on their accuracy (Fraden, 2016).

Linear Variable Differential Transformers (LVDTs) are another method of sensing

displacement. They are constructed of three coils around a tube containing a
ferromagnetic core, which the object to be measured is attached. The coils are positioned
end to end with a secondary coil either side of the primary coil in the middle. The output
voltage of a LVDT is the difference in voltage between the two secondary coils. An AC
excitation voltage applied to the primary coil induces an AC voltage in the secondary
coils, which varies with the position of the core. When the core is in the centre, the
induced AC voltages in both secondary coils are equal and opposite, creating no output
voltage. As the core is moved towards one secondary coil, and away from the other, the
coupling between the primary and secondary coils changes, inducing more current in one
of the secondary coils. Direction is inferred from the phase of the output voltage with
regards to the input; they will have the same phase for one direction, and the secondary
will lag by 90° for the opposite direction (Vemuri & Sullivan, 2016).

6
Contactless position sensors, or proximity sensors, may be in the an optical, ultrasonic,
or capacitive form, and detect the position of an object without mechanical attachment.
A basic optical displacement transducer is made up of a source of electromagnetic
radiation (visible light, infrared, etc.) and a photodetector. The device may also contain
some components concerned with the guidance of the light such as reflectors, lenses, and
fibre-optic cables. In simpler optical sensors, the emitted light is reflected off the object
to be measured, either directly or with an attached reflector, back towards the
photodetector. The photodetector may be a photovoltaic cell or light-dependent resistor
(LDR) and the intensity of the reflected light will increase as the object moves closer to
the sensor. Alternatively, an optical sensor may work on ‘time of flight’ principles, where
pulses of light are emitted and the time taken for the reflection to reach the photodetector
is measured and multiplied by the speed of light to give the distance of the target object
from the sensor (Fraden, 2016).

Ultrasonic sensors work on one of the two principles mentioned above; where a
continuous stream of soundwaves is emitted, and the level of energy reflected is
measured; or where pulses of sound are emitted and the time take for the reflections to
reach the sensor is measured. Piezoelectric materials are used for both the creation and
detection of sound waves in ultrasonic sensors, and when operating in the pulse
configuration, the same piezoelectric element can be used for both; a voltage is applied
to the element to create the pulse, and due to the reversing properties of piezoelectric
materials, the reflected sound wave will vibrate the material and induce a voltage to be
measured (Fraden, 2016).

Non-contact capacitive sensors take advantage of the fact that capacitance varies with
distance between capacitor plates, and differing dielectric properties of materials between
plates. When sensing the displacement of a target object made from a conductive material,
the target itself may act as one plate of the capacitor, meaning measured capacitance will
increase as the target is moved closer to the sensor, which contains the other capacitor
plate. A capacitive displacement sensor may also be used to transduce movement in
electrically insulating objects. All materials, including insulators, have dielectric
properties which will create some interference with the electromagnetic field generated
by a capacitor, thus inducing a measurable change in capacitance. While capacitive
proximity sensors are effective in sensing non-conductive materials, the degree of
accuracy is lessened compared to the sensing of conductive materials (Fraden, 2016).

7
1.2.6 Microcontrollers
A microcontroller is an integrated circuit containing CPU(s), memory (RAM and ROM),
and input/output ports, and are essentially simpler versions of the microprocessors used
in PCs. Where a microprocessor in a PC will have separate chips for separate functions,
a microcontroller combines all the essential elements into a single IC chip. This results in
ease of mass production, cost effectiveness, and the ability to design systems quickly
(Bates, 2011). Single-board microcontrollers consist of a microcontroller IC mounted to
a printed circuit board along with additional circuits and componentry aimed towards
prototyping and development. Additions to the microcontroller chip may include a clock
generator, input/output circuits (including headers for the attachment of jumper wires), a
USB or Ethernet interface, and other supporting ICs such as additional memory and
storage.

Figure 2: The Arduino Uno (Arduino, 2018)

Arduino is a company which creates open-source hardware and software company. They
design and manufacture single-board microcontrollers for prototyping, DIY projects, and
education, as well as an integrated development environment (IDE). The products are
widely used due to their low cost, wide availability, and ease of use. They are also
distributed under a GNU General Public Licence, meaning anyone has the right to run,
copy, modify, and distribute the software and hardware created by Arduino. Owing to the
products’ popularity, is the wide community of support and knowledge, all publicly
8
available (Arduino, 2017). Programming in the Arduino IDE is done in a dialect
containing elements of C and C++, although technically a program could be written in
any high-level language then compiled into machine code and uploaded to the Arduino.
The most popular, and therefore the most widely documented and supported, board made
by Arduino is the Uno (Figure 2). It is based around the Atmel ATmega328P
microcontroller, which contains 32KB of program memory, 2KB of SRAM (static
random-access memory), and 1KB of EEPROM (electrically erasable programmable
read-only memory) (Atmel Corporation, 2016). The board also has headers for 14 digital
input/output pins, of which 6 can generate a pulse width modulated (PMW) output; 6
analog input pins, which may also be used as digital I/O pins; a quartz crystal clock
running at 16MHz; a USB type-B connector; a power connector; and a reset button.

Owing to the open-source nature of the Arduino software and hardware, there are many
third-party products made specifically for use with the Arduino single-board
microcontrollers. ‘Shields’ are printed circuit boards which fit the headers of the Arduino
boards and mount directly to them, expanding their functionality (Arduino, 2017). These
boards may include features such as a GPS module (GlobalTop Technology Inc., 2011),
a motor driver (SparkFun Electronics, 2017), or a prototyping area (Firewing, 2014).

1.2.7 Data Acquisition

Data acquisition (DAQ) is the collection of real-world data for analysis, and is widely
used in science and engineering. This is most simply done by manually recording
observed values, however this is limited in many ways; a human observer will struggle
to read and record data at intervals more frequent than around 1s, for example.
Furthermore, one cannot be in a lab and record data indefinitely, and reading and recoding
data points manually will introduce some human error into the readings, especially in
long experiments, where user fatigue becomes a factor.

The automation of DAQ systems using computers allows readings to be made a sub-
millisecond intervals, and allows the length of time over which data is acquired to be
increased. Almost any physically quantifiable property may be recorded by a DAQ
systems by employing one or more sensors or transducers to convert the property into an
electrical signal; either directly, such as a photovoltaic cell converts light level into a
voltage, or indirectly, such as using a strain gauge to deduce force. To interface the
electrical signal with a digital DAQ system, the data must be discretised by an analog-to-
9
digital converter (ADC); it must be converted from an infinitely variable quantity in
continuous time to discrete quantities at pre-set time intervals (sampling intervals), which
allows the data to be stored as an array of digital numbers, separated by the sampling
interval of the ADC (Austerlitz, 2003).

1.2.8 Universal Testing Machines

Universal Testing Machines (UTMs) are used to apply tensile or compressive loads to
materials and products by mechanically or hydraulically driving fixtures at a precise rate.
A load cell is used to measure the force being applied to the specimen, and therefore
determine material properties (Davis, 2004).

Figure 3: The Tinius Olsen H5KS benchtop material testing machine (Tinius Olsen,
2010).
The Tinius Olsen Testing Machine Company design, manufacture, and supply tensile
and/or compressive material testing machines, including the Tinius Olsen H5KS (Tinius
Olsen, 2018). The H5KS (Figure 3) is a single-column, mechanically actuated UTM,
capable of applying loads up to 5kN at between 0.001mm·m-1 and 500mm·m-1. Loads are
applied via an interchangeable Z-beam load cell, and a variety of fixtures, allow tension,
compression, bending, or shear tests. Data from the Tinius Olsen H5KS is collected and
presented using the Tinius Olsen Horizon software. The software allows programs and
commands to be created and sent to the machine for execution, as well as producing
graphs and exporting tabular test data (Tinius Olsen, 2010).

10
1.2.9 Strava
Strava is a mobile application and social network for tracking cycling, running, and other
physical activity. As well as recording GPS data acquired by the app directly, or via third
party hardware, such as smart watches or cycling GPS devices, Strava can record power,
heart rate and other measures of performance to create an activity profile for sharing with
the users’ social network (Strava, Inc., 2018).

Figure 4: Strava analysis of a ride, showing the various recorded quantities over the
distance of the ride; altitude, speed, power, heart rate, cadence, and temperature.
Strava also has a paid subscription service which allows users to further analyse the
collected data: to give an impression of current fitness and fatigue levels; compare split
and lap times in a race; or take part interactive training programs, which use the acquired
data to quantify the riders fitness and adjust training intensity and goals to suit (Strava,
inc., 2018).

11
 CHAPTER 2 MATERIALS AND METHODS

2.1 APPARATUS

2.1.1 Bicycle
The bicycle used in this study was an ‘enduro’ style full suspension mountain bike (Figure
5). The frame was a YT Industries Wicked 650B (YT Industries GmbH, 2014), in size
medium. The bike had 158mm of rear wheel suspension travel with a ‘virtual-four-link’
linkage system actuating a RockShox Monarch RT3 (SRAM LLC., 2012) with 63mm of
travel. The RockShox Monarch RT3 allows for adjustment of air spring pressure, from
0bar to 24bar, adjustment of air spring volume, adjustment of compression damping rate
to 3 settings, and adjustment of rebound damping rate to 8 settings. The front suspension
fork, RockShox Pike RC (SRAM LLC., 2013), has 160mm of travel, and allows for
adjustment of air spring pressure, from 0bar (3.10bar is the manufacturer recommended
minimum) to 10.20bar, adjustment of air spring volume, adjustment of compression
damping rate to 15 positions, and adjustment of rebound damping rate to 18 positions.

Figure 5: YT Industries Wicked 650b (Vital Media Network, Inc., 2018).

The brakes used are Formula T1 (Formula Group S.r.l, 2012) hydraulic disc brakes, with
203mm rotors front and rear. The brakes allow for adjustment to the lever reach and the
bite point. The bike has 10 speed gears actuated by the SRAM X9 (SRAM LLC., 2017)

12
group of components, with maximum and minimum gear ratios of 3.27 and 0.86
respectively. The bike is fitted with a DT Swiss E1900 wheelset (DT Swiss AG., 2016),
of nominal diameter 27.5 inches (actual wheel rim diameter 584mm), with 2.4 inch
(nominal width) tyres; Continental Trail King on the front wheel, and Continental
Mountain King on the rear (Continental AG., 2018). Both allow adjustment in tyre air
pressure up to 4.00bar, with a manufacturer recommended pressure of 3.10bar.

2.1.2 Force Sensors

The force sensors used in this experiment (Figure 6) are FlexiForce A201 sensors
(Tekscan, Inc., 2017), which are thin (0.203mm), flexible, piezoresistive sensors, and can
measure forces from 0N to 4448N. The sensor will be used to detect the braking force by
measuring the force in the brake calliper, applied by the piston on the back of the brake
pad, meaning a thin sensor is required to minimise interference with the brakes function.

Figure 6: Flexiforce piezoresistor (Tekscan, Inc., 2017).

2.1.3 Displacement Sensors

To detect suspension travel in the front fork an RS Pro Linear Transducer (RS
Components Ltd., 2018) is used. The transducer, shown in Figure 7, is constructed of a
membrane potentiometer in an extruded aluminium structure with a steel rod, which
actuates the wiper. The stroke of the transducer is 200mm, which is in excess of the
required 160mm, meaning there was some room for adjustment when mounting the
transducer. The sensor also has protection against dust and water ingress to a rating of
IP65, meaning complete protection from dust ingress and protected from water ingress
by a 6.3mm jet (International Electrotechnical Commission, 2001).

13
Figure 7: The RS Pro Linear Transducer (RS Components Ltd., 2018).
Displacement of the rear shock will be measured using the Alps RSA0N slide
potentiometer (Alps Electric Co., Ltd., 2018). This transducer had 100mm of stroke
which, again, is in excess of what is required (63mm) to allow for some adjustment when
positioning the sensor on the bike.

2.1.4 Mounting Hardware

The mounting of the hardware on the bike must be fixed firmly enough to withstand the
rigours of a downhill course, however must be easy to remove from the bike; while teams
competing at a high level will likely have more than one bike available to each of the
riders, meaning one bike could be dedicated to data acquisition, most semi-professional
and amateur racers will have one bike available to them; meaning the system would be
used during practice, then removed for race runs.

Figure 8: CAD model showing the mounting hardware for the rear suspension
displacement sensor mounted on the shock absorber.

14
To create the brackets, measurements of the fork and shock were taken at the mounting
points, as well as dimensions from the sensor data sheets which allowed CAD models to
be created in Autodesk Inventor software (Autodesk, Inc., 2017). The shock mounting
hardware created consists of circular brackets that fit to the air can , to hold the body of
the potentiometer, and a small acrylic clip to hold the rod which transfers suspension
movement to the wiper of the potentiometer. A model of the shock absorber and
potentiometer were also created to create a CAD assembly of the components (Figure 8).

(A) (B)

(C)

Figure 9: (A) CAD model showing how the displacement sensor will mount to the fork.
The sensor body (green) is mounted to the fork lowers, while the end of the actuator rod
is affixed to the crown (topmost part of the fork assembly) (CAD files for the fork taken
from GrabCAD (Gawronski, 2017)), (B) Upper fork bracket, (C) Lower fork bracket
The front displacement sensor came supplied with some mounting hardware; metal tabs
which interface with slots on the side of the sensor body. To simplify the design of the
mounting hardware, the tabs were incorporated into the design. To mount the sensor body
to the fork lower, two circular brackets were created with holes at the correct spacing to
accept the supplied mounting hardware (Figure 9 (C)). The actuator rod of the sensor is
connected to the wiper at one end and has an M5 thread at the other. To transfer the
suspension movement to the wiper using this rod, another circular bracket was created.
The upper bracket (Figure 9 (B)) is similar to the ones used on the fork lowers, however,
protrudes out farther, and had a hole for a clearance fit with the M5 thread in the vertical
axis. The rod will be secured using a nut either side to allow for fine vertical adjustment
of the rod relative to the fork crown. A CAD model of a suspension fork was taken from
GrabCAD (Gawronski, 2017), and a model of the sensor created to allow the mounting
solution to be assembled in the CAD software.

15
The microcontroller, power supply, GPS module, and other supporting electronics were
put inside a case for mounting on the bike (Figure 10). The case consisted of a small,
clear plastic box, just big enough to fit the required components to avoid adding
unnecessary bulk to the bike. Holes were made in the case to allow access to the Arduino’s
USB port and power input, as well as to accept the threaded bosses for attaching the radio
and GPS antenna. Allowances were also made for the wiring which would run to the
external sensors.

Figure 10: Sensor apparatus and transmitter mounted to the bike, with a laptop running
the post-processor (Section 2.4) connected to the receiver (Shown highlighted in yellow).
Highlighted in red is the fork displacement sensor, in green the electronics case (See
Figure 11 for detailed view), in blue are the brake force sensors.
The sensor apparatus was attached to the bike using the bracketry described above (Figure
11), and the electronics case was attached to the frame in a location where there was
minimal risk of interfering with the normal operation of the bike; away from knees during
pedaling, and away from moving parts such as suspension and headset. The wiring
connecting the sensor apparatus to the electronics in the case was terminated using crimp-
on connectors. More detailed, close up photographs of the mounting solutions may be
viewed in Appendix C.

16
Figure 11: The electronic components inside the case to mounted on the bike. The
Adruino cannot be seen, it is beneath the blue GPS shield at the right of the case.
The brake force sensors were held in place by friction fit (Appendix C, Figure 32, right).
With the wheel off the bike, the brake pads were removed and piston in front of which
the sensor will be placed is pushed back into the caliper. The pads may then be reinstalled
with the sensor, followed by the wheel. Finally, the brake lever was pumped in and out
to allow the pistons to reset. The hydraulic disc brakes used self-adjust for pad wear, and
as such, will compensate for the extra thickness introduced by the sensor.

2.2 ELECTRONICS AND SOFTWARE

2.2.1 Sensor Circuits

The sensors for suspension displacement and braking force were incorporated into
circuits to create an analog output voltage between 0v and 5v, which is readable by the
Arduino. The potentiometers were simply applied with 5v across the power pins, and the
wiper connected to an analog input pin on the Arduino board. The voltage should be
applied such that the output voltage increases as the fork and shock are compressed. The
Flexiforce sensors were simply connected as a voltage divider, such that the output
voltage increases with increasing force. During calibration, a suitable value of resistor

17
must be found to allow the sensor to resolve forces across the appropriate range. Figure
12 shows a schematic of the sensor circuitry.

Figure 12: Schematic of the sensor circuits connected to the Arduino Uno (Created using
Autodesk Circuits online software (Autodesk, Inc., 2018). Note: “ANAOLOG” is an error
within the Autodesk Circuits software, and is not a user input name.

2.2.2 Microcontroller
The electronic control of the system was performed by the Arduino Uno microcontroller
(Arduino, 2018), and the software developed in C/C+ using the Arduino IDE. The
microcontroller is responsible for reading voltages from the transducers, and collecting
and parsing data from the GPS module. The data is then either transmitted via radio
antenna for real-time analysis, or logged to an SD card.

The first step in creating the embedded software was to write separate programs for each
sensor, and for the GPS module. These were then be combined into the full system, with
additional code for writing to the SD card and transmitting via radio.

2.2.3 GPS Module

The Adafruit Ultimate GPS Logging shield (GlobalTop Technology Inc., 2011) was
chosen for GPS tracking and data logging. The shield contains a GPS module and an SD
card reader/writer with all the required supporting components and a small prototyping
area. (GlobalTop Technology Inc., 2012)

18
For initial testing purposes a code was created which disregards the other sensors, reading
and saving only GPS data (Appendix E). The GPS module streams data in the form of
NMEA (National Marine Electronics Association) sentences, of which two types were
used for this test; RMC, which contains the recommended minimum information,
including time, date, latitude, longitude, and speed; and GGA, which contains altitude
and satellite fix information. In the setup of the program, a command is sent to the GPS
module, instructing that only these two sentences be streamed. Commands must also be
sent to prevent the module automatically streaming updates on antenna status, and to set
the update rate (1Hz for the GPS test). Initialisation of the SD card reader/writer involves
searching for any old data files, and deleting them if present.

Once the GPS module and SD card were initialised, the character stream from the GPS
module was read by the program and stored as strings (NMEA1 and NMEA2). For the
purposes of debugging and testing, a file was created on the SD card which stores the raw
NMEA sentences, although this is not required in post-processing for the final system,
due to the data being parsed to a useful format for within the Arduino program by the
Adafruit GPS library.

Commands from the Adafruit GPS library (Adafruit, 2018) parse the GGA and RMC
NMEA sentences and obtain universal coordinated time, latitude, longitude, and altitude,
all of which was written to a separate GPS coordinate text file on the SD card. They must
be formatted in the form of GPX trackpoints (Example shown in Figure 13).

1. <trkpt lat="56.45781326" lon="-2.98068637">

2. <ele>39.70</ele>
3. <time>2018-03-20T12:07:09Z</time>
4. </trkpt>

Figure 13: Example of a GPX trackpoint coded in XML. As well as elevation and time,
trackpoints can contain other activity data such as heart rate, power, and cadence. (Code
formatted for display using online tool: SyntaxHighlighter (Beach, 2011))
The program was uploaded to the Arduino, which is walked around a block of buildings
on the university campus to gather GPS data.

Additional supporting code is required to change the created file into a useable format,
and for this purpose a GPX “wrapper” (Appendix H) was created using an activity profile
downloaded from Strava as a template (Strava, Inc., 2018). It was decided to have the

19
system output data in the GPX format rather than as a KML (Google Earth format
(Google LLC, 2018)) as the GPX format can store the relevant time data for each
trackpoint, where KML contains only position data. For this reason GPX files may be
converted to the KML format using an online tool (Gpx2kml, 2018), however conversion
from KML to GPX will result in a GPX file with no time data, limiting its usability.

A test was also created to optimise the update rate of the GPS module. The test simply
printed out Universal Coordinated Time (UTC) to the serial monitor of the Arduino for
analysis. Different configurations of update rate and NMEA sentence types were tested
to allow the system send GPS data whilst maintaining a satisfactory sample rate for the
suspension and braking sensors.

2.2.4 Telemetry
The addition of nRF24L01+ radio antenna allows the wireless transmission and real time
analysis of data from the system. The 2.4GHz transceivers used (Nordic Semiconductor,
2008) have a nominal range of 800+ meters with line of sight, which would be enough
for many downhill courses, however, for use in enduro racing, where races cover many
kilometres, data should still be logged to the SD card.

Initial testing of antenna examined the basic functionality and the transmission range of
the hardware. To test the transmission range of the antenna, an Arduino on the bike
(transmitter) streamed GPS data, via the antenna, to an Arduino connected to the
computer (receiver). The transmitter was moved away from the receiver until GPS data
was no longer being received. This GPS data may then be used to find the distance at
which the signal was lost. This test was repeated in open space, with line of sight, and in
a wooded area, similar to a typical mountain bike trail, to give a better understanding of
the range of the device under real conditions.

The code for the range test consists of two Arduino sketches; one for the transmitter and
one for the receiver. The transmitter code reads and parses GPS data in the same way as
the GPS test program, then stores position and time data in a struct, which allows the data
to be sent via the radio antenna. The antennae have four power levels (MIN, LOW, HIGH,
MAX), and three data rates (250kbps, 1Mbps, 2Mbps). While the power levels for both
antennae were set to maximum to obtain the largest range, bench testing was carried out
on the antennae to find the required data rate to transfer GPS data at a satisfactory speed
20
for the range test. The minimum data rate which can keep up with the parsing of GPS
data will be used, as the sensitivity of the antenna is reduced as the data rate increases;
Nordic Semiconductor (2008) quotes a sensitivity of -85dBm at 1Mbps and -82dBm at
2Mbps.

Bench testing of the antennae began at 250kbps, with the transmitter sending UTC
(formatted as hr:m:s:ms), latitude, longitude, and speed. Since UTC was transmitted to
millisecond accuracy, the serial monitor was observed to verify that lines of data are being
received at 100ms intervals (10Hz). If this condition is not satisfied, the data rate must be
increased.

The first bench tests of the radio system (detailed above) transmitted a limited amount of
data, and had the purpose of verifying the functionality of the ‘setDataRate’ command.
However, when the strut is increased in size to include suspension and braking data, the
data rate must be retested and possibly increased to allow for the transfer of more data,
therefore decreasing the range. For this reason a second bench test was performed,
generating random numbers for suspension travel and braking force, to simulate the
quantity of data which will be experienced during real-world operation. The code
developed for this second bench test completes the final design for the embedded software
on the receiver (Appendix F), and approaches the final design for the transmitter
(Appendix G). The changes to the transmitter’s embedded software to allow real world
testing were to initialise the sensor input pins, and assign the relevant variables within the
struct to the input value from those pins. The program viewable in Appendix G contains
the code necessary for real world testing commented out (See Appendix G, lines 8-11,
46-49, 79-82), as well as the code used for the bench tests, that is the code relating to the
random number generation, and the use of the serial monitor for debugging (See
Appendix G, lines 29, 51, 73-76, 92).

2.3 SENSOR CALIBRATION

2.3.1 Force Sensors

The Flexiforce sensors were calibrated using the Tinius Olsen H5KS benchtop material
testing machine. To find the range over which the force sensor should be calibrated, initial
rough calculations were performed approximating the pad force required to decelerate
bike (mb = 15kg) and rider (mr = 70kg) from 10ms-1 to 0ms-1 in 10s (a = -1ms-2) using

21
one brake only, neglecting any skidding at the tyres. This is most likely to be approaching
extreme value of braking force that would be experienced, as in practice, both brakes are
used, and at this level of deceleration, it is almost certain there will be some skidding,
especially on loose gravel, wet rocks, mud, etc.

The force required for the above deceleration is given by:

𝐹" = (𝑚& + 𝑚( ) ∙ 𝑎
𝐹" = 85N
Translating the deceleration force to torque at the wheels by the following:
𝑇 = 𝐹" ∙ 𝑟2
𝑇 = 24.82Nm
𝑇 ≈ 25Nm
Where rw is the radius of the wheel (0.292m).
If braking torque is given by:
𝑇 = 2 ∙ 𝜇 ∙ 𝑟9 ∙ 𝐹:"9
Where:
Required braking torque, T = 25Nm
Coefficient of friction of brake material on steel, µ = 0.4
Mean radius of braking surface on disc, rd = 0.01m
Force exerted by pads on the disc, Fpad
Therefore:
𝑇
𝐹:"9 =
2 ∙ 𝜇 ∙ 𝑟9
𝐹:"9 = 3125N
Taking these rough calculations into account, the sensor was calibrated from 0N to
3000N.

To calibrate the force sensors a simple Arduino program was created to read in the analog
voltage from the Flexiforce voltage divider circuit. Initially a fixed resistor of resistance
100kΩ was used, although this can be increased or decreased if it was found to be
unsuitable.

First, the Arduino was loaded with the program (Appendix D) and the serial monitor was
opened to view the output voltage of the sensor. With the force sensitive element under
the head of the machine (Figure 14), the Tinius Olsen Horizon software was used to create

22
a test such that the head of the machine moved down at 0.5mm/min until a force of 100N
was detected, whereby it waited for a user command to continue to the next 100N step.
For each force step, the voltage output of the sensor was recorded, allowing a relationship
between force and voltage to be established.

Figure 14: The experimental setup for calibrating the force sensors using the Tinius
Olsen material testing machine.

2.3.2 Displacement Sensors

Once the displacement sensors were mounted on the bike, they may be calibrated to find
the relationship between wheel travel and output voltage. With the bike on a stand, the
air spring in the fork was decompressed and the damping settings set low to allow the
fork to be cycled through its travel freely. The fork was then lowered in 0.01m increments
and the output voltage recorded at each increment using the same program as for the force
sensor calibration (Appendix D) allowing a graph showing distance vs. voltage to be
created.

The displacement sensor on the rear shock absorber was calibrated using a similar
method; the air spring was decompressed, and damping settings set to minimum, allowing
the shock absorber to be compressed at 0.005m increments, and voltage readings taken.

2.4 POST-PROCESSING
For post processing, a program written in Python (van Rossum, 2018) was interfaced with
the Arduino serial monitor. The program displays data in real time, as well as stores data
in a spreadsheet.

23
To create graphs and perform the necessary mathematical operations on the acquired data
using Python, a number of libraries were used. NumPy (Opliphant, 2006) adds support to
the Python language for complex mathematical calculations and allows for easier
handling of large matrices and arrays. Matplotlib (Hunter, 2007) provides utility for
embedding plots and graphs into programmes written in Python, and with the addition of
the drawnnow library (Sievert, 2018), allows for the plotting of live data. To store data,
the xlwt library (Machin, 2017) was used to create and write to a Microsoft Excel
spreadsheet (.xls format).

The post processor operates by reading characters from the Arduino serial monitor, which
are formatted as comma separated values, with a new line for each data set. The post-
processor then separates this data and adds each field to a list before plotting in real time
and writing to an Excel spreadsheet (Microsoft, 2016).

2.5 SUSPENSION SENSOR TESTING

To test the functionality of the system for suspension tuning, a test was created whereby
suspension data which was recorded as the bike was ridden off a small kerb (0.2m) to flat
ground was analysed. The rider attempted to land with their mass split evenly between
the front and rear wheel, and to ride at a constant speed for every attempt. Speed was
monitored in real time by the rider using a Garmin Edge 810 GPS head unit (Garmin Ltd.,
2016) mounted to the handlebars (Figure 30, right).

The recorded data was analysed to view the behaviour of the suspension after the landing
impact to evaluate the usefulness of the gathered data, and, if the data proved useful, to
make any necessary adjustments to the rebound and compression damping settings. At
the beginning of the test the air pressures in the fork and shock were set to give 20%
suspension sag with the rider in a standing position (32mm front, 12.6mm rear. Note that
suspension sag was not set with any external measuring devices but using the scale on the
fork and shock stations, therefore the sag values of 32mm and 12.6mm are nominal only).
For the first test, all damping adjustments were set to their minimum damping force, while
the second and third test will use the middle setting and maximum setting respectively.

24
 CHAPTER 3 RESULTS AND DISCUSSION

3.1 FORCE SENSOR CALIBRATION

The calibration of the force sensor resulted in a logarithmic relationship between force
and output value (Figure 15), described by the relationship:

𝑉 = 266.09 ln 𝐹 − 1283

Where V is the 8-bit digital conversion of voltage, and F is the force in Newtons.

It was found that the initial estimate of 100kΩ for the fixed resistor gave the sensor a
suitable working range.

Force vs. Output value

900

800

700
V = 266.09ln(F) - 1283
600
Output Value

500

400

300

200

100

0
0 500 1000 1500 2000 2500 3000 3500
Force (N)

Figure 15: Graph showing how the output value from the Arduino varied with applied
force.
To give a more linear result, the sensor could have been wired into a circuit using an op-
amp, as recommended by the manufacturer (Tekscan, Inc., 2017). However, to reduce the
number of components on the bike, the voltage divider circuit was used in the final design.
Furthermore a rider will feel greater the effects of changing braking forces at the lower
end of the range, that is, they would feel the difference between 0% and 10% braking
more that 90% and 100%, meaning that sacrificing some accuracy at the top end of

25
braking force for the increased rate of change at the bottom end may be a beneficial trade
off.

3.2 DISPLACEMENT SENSOR CALIBRATION

Calibration of the both the front and rear suspension displacement sensors resulted in a
linear relationship between output voltage and displacement for both the suspension fork
(Figure 16) and the rear shock absorber (Figure 17). For the suspension fork displacement
sensor the relationship is described by:

𝑉 = 5.1 ∙ 𝑥 + 155.53

And for the rear shock absorber:

𝑉 = 11.024 ∙ 𝑥 − 2.0733

Where V is the 8-bit digital conversion of voltage, and x is the suspension displacement
in millimetres (x = 0 when suspension is at full extension, and increases with
compression).

Distance versus Output Value

1200

1000 V= 5.1x + 155.53

800
Output Value

600

400

200

0
0 20 40 60 80 100 120 140 160 180
Distance (mm)

Figure 16: Voltage versus Distance curve for the displacement sensor on the suspension
fork.

26
 Distance versus Output Value
800

700

600

500 V = 11.042x - 2.0733

Output Value

400

300

200

100

0
0 10 20 30 40 50 60 70
Distance (mm)

Figure 17: Voltage versus Distance curve for the displacement sensor on the rear shock
absorber.

3.3 GPS TRACKER TESTING

In testing the GPS module, the device was walked around a block of buildings on the
university campus. Figure 18 shows the path obtained in the initial test, displayed on
Google Maps. The GPS path created in this test is quite dissimilar to the path actually
taken with the GPS module in the test. This is because the latitude and longitude were
rounded to 2 decimal places. To increase the accuracy of the GPS data, the code was
modified to return latitude and longitude to 8 decimal places.

27
Figure 18: Display of GPS path on Google Maps (Google LLC, 2018).
In the second test, the code was reiterated to write latitudes and longitudes to 8 decimal
places, which resulted in a smoother and more accurate path (Figure 19).

Figure 19: The GPS path with higher latitude and longitude resolution.

28
3.3.1 Update Rate
One of the limitations of this configuration is the 1Hz update rate; while reading GPS
data once per second provides satisfactory performance for tracking location, once the
GPS tracker is combined with the other sensors in the system, this is much too slow a
sample rate for collecting useful data, especially from the suspension travel sensors, as
riding over a series of small bumps in quick succession could result in suspension
movements quicker than 10Hz.

Figure 20: Figures showing timing of the outputs to the serial monitor for both
configurations. (Left: 1Hz, RMC and GGA sentances, right: 10Hz, GGA sentence only)
For this reason, when combined into the full system, the update rate is set to the maximum
of 10Hz. A drawback of this increase in update rate is that GPS module is only capable
of streaming the recommended minimum (RMC) NMEA sentence, meaning altitude data
will be lost. While this is a limitation, altitude data would be more accurately read from
a barometric altimeter, which could be incorporated into the system in the future.
Furthermore, if data is being uploaded to Strava, the website has a system whereby
altitude is calculated using topographical data and other users GPS data (Strava Inc.,
2018). A comparison between the update rates for the 1Hz and 10Hz configurations can
be seen in Figure 20. The 1Hz update rate with GGA and RMC sentances outputs one
line to the serial monitor every 1s, while the 10Hz update rate with only GGA sentence
outputs approximately every 100ms.

3.3.2 Strava Compatibility

To test the compatibility of the created file with Strava, the test data was uploaded to the
website. The file uploaded successfully and the Strava analysis can be seen in Figure 21.
Although this feature is functional, it makes somewhat limited use of the GPX format,
29
which could theoretically store the suspension and braking data gathered by the data
acquisition system, however Strava does not accept these types of data. An improvement
in functionality could be made by creating a proprietary system, similar to Strava, which
does accept these data types, or by working with Strava to extend their capabilities as
electronic systems become more common in mountain biking. A further increase in the
utilisation of the GPX format could be gained by adding into the system compatibility for
third-party heart rate monitors and power meters, the data from which can, at present, be
shared via Strava.

Figure 21: Stava analysis of the GPS test data, showing speed and estimated power
(Lowe, 2018).

3.4 ANTENNA TESTING

3.4.1 Data Rate

Bench testing to investigate the ideal data rate for the range test revealed 250kbps was
satisfactory for the transmission of GPS and time data at 10Hz. The serial monitor is
shown in Figure 22, and confirms that a line of data is received approximately every
100ms.

30
Figure 22: The GPS data with time stamps, as received by the antenna during bench
testing.
The 250 kpbs data rate was found to be satisfactory when transmitting the data required
for the range test; four integers for hour, minute, second, and millisecond, and three
floating point numbers for latitude, longitude, and speed (totalling 224bits).

Figure 23: The transmitted data for the second bench test, including simulated suspension
and braking values. Highlighted in red are the points where a data set was lost.
Indeed it was found, once the additional data was simulated, that 250kbps appeared
insufficient; most of the data was transmitted and received however, as show in Figure
23, some of the transmitted data is not displayed. Highlighted in red are some examples
of adjacent data sets which have timestamps separated by 200ms. The fact that the
program skipped a data set entirely, rather than output corrupt data suggests the radio
modules have some built-in error trapping. This is useful for the robustness of the Python

31
post-processor, which reads data directly from the serial port, and any out of place or
unexpected characters may cause a crash.

While it is possible this data was lost in transmission, there is also the possibility of the
fault lying in the receiver programming. The baud rate of 9600 is relatively low, and may
be causing the program to miss some of the transmitted data while the previous set is
being printed to the serial port. To test this, the data rate was kept at 250kbps, and the
serial baud rate was increased to 115200.

Figure 24: The serial monitor after the program had been altered to increase the baud
rate. Note the presence of a data set approximately every 100ms.
Figure 24 shows the serial monitor displaying the receiver output after the serial baud rate
was increased to 115200. The data is now being streamed at 100ms intervals, thus
maintaining the 10Hz update rate of the data acquisition system.

3.5 SUSPENSION TUNING TEST

The following section presents the results of the suspension sensor test, attempts to
characterise suspension events, and hypothesises changes which may improve the
suspension characteristics. The graphs herein were created the spreadsheet output from
the post-processor. During the first run of the test, the rear suspension sensor mounting
hardware failed, and for this reason no results for rear suspension were obtained. For all
results presented in this section, movement of the suspension in compression
(downwards) shall be taken as positive displacement.

32
3.5.1 Test 1 Results - Minimum Damping Settings
The results of the first drop test, with the rebound and compression damping set to their
lowest setting can be seen in Figure 25. The actually recording of the test took place over
42.7s, however for clarity, the graphs have been cropped to begin at t = 15s, just before
the bike was mounted, and end at t = 24s, when the bike suspension displacement had
settled as the bike was ridden away over smooth ground. Although the sensor had been
calibrated previously, an adjustment to the suspension displacement data were necessary;
when the bike was unloaded, and the suspension was at full extension, the system return
a non-zero value for suspension displacement. This was due to the sensor body being able
to move slightly up and down in its mounting. To account for this the error (3.4255mm
in the current case) was subtracted from the measured suspension, to give the adjusted
value plotted below.

Front Suspension Travel versus Time - Test 1

180

160

140
Suspension Travel (mm)

120

100

80

60

40

20

0
15 16 17 18 19 20 21 22 23 24
Time (s)

Figure 25: Suspension displacement versus time during the first drop test, with the
rebound and compression damping set to the minimum.
The main focus of this test is the drop itself and the directly related events, between
t = 19s and t = 22.2s. This region of the graph may be split into four distinct events:

1. The rider preloading the fork in preparation for the drop (t = 19s to t = 19.6s).
2. The release of this preload as the bike goes off the drop (t = 19.6s to t = 19.8s).
3. The compression of the fork on landing (t = 20s to t = 20.2s).

33
 4. The rebound and consequent oscillations as a result of this compression (t = 20.3s
to t = 22.0s).

Note also that preload release (2.) and compression (3.) are separated by 0.2s while the
fork is at maximum extension (top-out), additionally the compression and rebound are
separated by 0.1s while the fork is at maximum compression (bottom-out). Other
movements which are not classified under the four events detailed above include the first
movement detected between approximately t = 17.0s and t = 18.0s, which represents the
suspension compressing and rebounding under pedalling (pedal-bob). Additionally, the
slower rebound between t = 22.2s and t = 23.0s shows the resultant front suspension
movement of the rider sitting back, and taking weight off of the handlebars.

3.5.2 Test 2 Results - Medium Damping Settings

The front suspension displacement data gathered by the system during the second test is
shown in Figure 26. As in the previous test, the suspension data had to be adjusted for
movement in the mounting brackets, in this case 5.5823mm was subtracted from the
measured values. The total length of this test was 37.1s, and, as in the previous section,
the graph is cropped for clarity between t = 14.0s and t = 25.0s.

Front Suspension Travel versus Time - Test 2

180

160

140
Suspension Travel (mm)

120

100

80

60

40

20

0
14 15 16 17 18 19 20 21 22 23 24 25
Time (s)

Figure 26: Suspension displacement versus time for the second drop test with the medium
rebound and compression damping settings.
The four events detailed in Section 3.5.1 can also be seen in the results of this test:

34
 1. Preload between t = 18.0s and t = 18.2s.
2. Release of preload between t = 18.2s and t = 18.6s.
3. Compression between t = 18.6s and t = 18.8s.
4. Rebound and oscillation between t = 18.8s and t = 20.3s

Movements out with these events include pedal-bob seen in the displacement values
between t = 15.4s and t = 16.0s, as well as at t = 22.0s to t = 25.0s. There is also a
movement starting at t = 17.2s, which may be the rider changing from a sitting to a
standing position in preparation for the drop, as well as a movement beginning at
t = 21.2s, which may be the opposite; the rider moving from a standing to a sitting
position.

3.5.3 Test 3 Results - Maximum Damping Settings

The third test investigated the effects of overdamping the suspension, increasing all
damping settings to maximum, and the results are shown in Figure 27. As with the two
sections previous, the graph has been cropped from its full length (33s), and begins at
t = 15.0s, just before the bike is mounted. The adjustment made to compensate for the
sensor movement was a subtraction of 5.0912mm from the measured values.

Front Suspension Travel versus Time - Test 3

180

160

140
Suspension Travel (mm)

120

100

80

60

40

20

0
15 16 17 18 19 20 21 22 23 24 25
Time (s)

Figure 27: Suspension displacement versus time for the drop test with rebound and
compression damping set to maximum.

35
The four events detailed in Section 3.5.1 can also be seen in the results of this test:
1. Preload between t = 19.4s and t = 19.6s.
2. Release of preload between t = 19.6s and t = 19.8s.
3. Compression between t = 19.8s and t = 20.0s.
4. Rebound and oscillation between t = 20.3s and t = 20.8s

Pedal-bob can again be seen between t = 16.7s and t = 18.2s, as well as some movement
from the rider changing his stance (t = 21.8s to t = 25.0s).

3.5.4 Comparison and Discussion of Suspension Tests

Data from the results of each drop test can be seen in Table 1. While the data here is from
one run of each test, limiting the confidence with which conclusions may be drawn, some
trends are apparent. In general, the change in position, maximum speed, and acceleration
decrease with increased damping. As mentioned in Chapter 5, Section 2, the system
would benefit from accelerometers mounted to the sprung portion of the frame, which
would allow one to find the absolute acceleration felt by the rider.
Test 1 – Minimum Test 2 – Medium Test 3 – Maximum
Damping Damping Damping
Δx vmax amax Δx vmax amax Δx vmax amax
-1 -2 -1 -2 -1
(m) (ms ) (ms ) (m) (ms ) (ms ) (m) (ms ) (ms-2)
1. Preload 116.86×10-3 1.1686 11.647 113.33×10-3 0.93137 9.4510 77.062×10-3 0.60588 4.4118

2. Release -136.08×10-3 -1.1706 -13.294 -142.35×10-3 -1.0941 -12.961 -92.552×10-3 -0.86275 -8.98039

3. Compression 163.72×10-3 1.1922 11.980 149.02×10-3 1.2431 9.9608 107.65×10-3 0.80000 11.392

4. Rebound -156.68×10-3 -1.5039 -15.039 -118.83×10-3 -0.77255 -20.157 -110.59×10-3 -0.86863 -0.89804

Table 1: A table showing the change in position, maximum velocity, and maximum
acceleration for each of the four suspension events, in each of the three tests.
The test with minimum damping settings is an example of an underdamped suspension
system. The low compression damping settings decrease the force resisting the loads to
the suspension thus increasing the net force on the suspended (upper) part of the fork and
increasing acceleration (F = m·a), which results in the bottom-out observed in the data
(Figure 25). The bottom-out is the point at which the suspension cannot be further
compressed, and since suspension operates by storing kinetic energy as potential energy
in the form of air pressure (or spring tension in the case of coil sprung suspension), the
suspension is inoperable until the fork can rebound. Opposed to this, the high acceleration
of the fork lowers relative to the frame suggests that the acceleration of the frame relative

36
to the ground may be lower, although, as mentioned above, this would require further
investigation using accelerometers on the frame.

The low rebound damping settings reduce the force resisting the air spring in the fork
returning to its fully extended position, meaning the potential energy stored in the fork is
released quicker. This is desirable for avoiding ‘pack-down’ of the suspension; where
successive bumps push the suspension up quicker than it can rebound. Although the
quicker return speed of the fork is desirable for this reason, a compromise must be made,
as the same low resistance force causes the full force of the rebounding spring to be
absorbed by the rider; the results show a maximum upwards acceleration of 15.093ms-2
in the rebound event, and since the wheel is on the ground during this time (no movement
in the vertical direction), this acceleration is transferred fully to the rider. Another result
of the low damping settings is the oscillation observed after rebound. Figure 25 shows a
decaying sinusoid between t = 20.2s and t = 22.0s, although the second peak is somewhat
truncated, possibly due to compensation by the rider. This compensation is the reason
such oscillation is undesirable; it adds another dynamic element that the rider has to
control and adjust for.

Increasing the rebound and compression damping adjustment knobs to their middle
settings increased the resistance against suspension loads and air spring force both, the
result of which was a general decreasing trend in change in displacement (Δx), maximum
velocity (vmax), and maximum acceleration (amax) during the four events detailed in Table
1. There are some exceptions to this trend; the change in displacement during preload
release is increased on Test 1. This may be down to human error, as the rider cannot load
the fork in the same way every time. Additionally, maximum speed during compression
and maximum acceleration during rebound are also increased. Ideally, the experiment
should be performed multiple times for each damping setting to discover if these values
are due to errors or are representative of the suspension behavior. Beneficial effects of
increasing the damping settings include a reduction in oscillations after the rebound event.
In Figure 26 (t = 19.2s to t = 21.0s) the suspension displacement can be observed
oscillating only slightly after rebound, with the general trend towards one peak before
settling at approximately 44mm by t = 20.3s. Additionally, the bottom-out was reduced
in severity. Analysis of the graph of velocity and acceleration for the previous test
(Appendix J, Figure 33) show a point of inflection in the speed data at approximately
v = 0ms-1 from t = 19.9s to t = 20.0s, and a resulting dip in acceleration (Δa = -11.294ms)

37
. Comparing this with the same graph for the second test (Appendix J, Figure 34), which
also has a point of inflection at 0ms-1, indicating a bottom out, however it can be seen that
the resultant dip in acceleration is less violent (Δa = -7.5687). Identifying the severity of
bottom out occurrences in this way may suggest that suspension jerk (j = ȧ(t)) could be a
useful calculation to be made in post-processing.

The maximum damping settings continues the general trend of decreased displacement,
velocity, and acceleration values. Again, there are exceptions, potentially due to the lack
of multiple test runs, namely maximum acceleration during compression, and maximum
speed during rebound. The high rebound damping here has induced ‘pack-down’ of the
fork during pedaling (Figure 27, t = 16.7s to t = 18.5s). The fork is being compressed on
the down-stroke of the pedal action, and due to the high forces resisting the air spring, the
fork cannot return to full extension before the next pedal down-stroke. The high rebound
damping also has the effect of removing any oscillation after the rebound event; leaving
only a slight overshoot in compression of approximately 4mm (t = 20.5s) past the settling
level.

3.6 POST PROCESSING

The post processing program developed in Python can be viewed in Appendix I. Initially,
the code was tested in the lab with the Arduino creating random values for suspension
and braking force. During the initial test of the post processor, it was found that on starting
the program some data fields at the beginning of the line were missed, causing the
program to assign data to the incorrect list, or crash completely. To rectify this issue, the
Arduino program was changed to output a verification character ($) in the first field,
followed by the data thereafter. An ‘if’ statement was used to check if the first field
matched the verification character, and if so, the data could be stored correctly, else the
program should re-read a line of characters.

38
Figure 28: The plots produced by the post processor from the random sensor data being
streamed by the Arduino.
As an example of the data which may be presented in the spreadsheet (Table 2), this test
gives maximum and average speed, as well as some data useful for suspension tuning;
the average fork and shock sag, the fork and shock maximum travel used, and the number
of bottom out occurrences (taken as the number of times the fork or shock is within 3mm
of its maximum travel).

Usually, when setting up a bike, the suspension sag is set in a static state, that is, the rider
mounts the bike and adjusts air pressure or spring preload to achieve a value of sag 20-
30% of the total available travel. While this provides a starting point for further
adjustments, it is not ideal, as the bike is under dynamic loading when in use, which will
change the air pressure or spring tension necessary to deliver the desired amount of
suspension sag. With this system, the suspension is continuously measured, therefore
allowing the user to base his/her sag setting on the dynamic loads experienced during
riding.

The bottom out value and number of bottom out occurrences also provide useful data; an
ideal suspension system will bottom out once on a ride at the maximum impact, meaning
the data acquisition system would return a maximum travel utilisation of 160mm for the
fork and 63mm for the shock, and 1 bottom out occurrence for each. Should the system
return 0 bottom out occurrences for a ride, the user will look to the maximum travel

39
utilisation and see how much travel is being used, if this figure is slightly below the total
travel of the fork or shock it would suggest that compression damping is set too
aggressively or the spring rate/air spring pressure are too high. If the maximum utilised
travel is drastically lower, and feedback from the rider suggests the suspension is set to
their liking, it may suggest that bike choice should be reconsidered, and a lighter, shorter
travel bike would be better suited to that particular ride.

Average Speed: 0.345526316 Average Fork Sag (mm): 50.67007224 Average Shock Sag (mm): 30.28389212
No. of Fork Bottom Outs: 0 No. of Shock Bottom Outs: 1
Max Speed: 0.46 Fork Max Travel Utilisation (mm): 151.2686275 Shock Max Travel Utilisation (mm): 62.30755298

Time Latitude Longitude Speed Front Suspension Travel (mm) Rear Suspension Travel (mm) Front Braking Force (N) Rear Braking Force (N)
0:0:0:0 0 0 0 51.07254902 1.358449556 1267.751427 278.7471687
18:26:19:46 56.46 -2.98 0.46 -20.88823529 31.4254664 282.969568 162.8505284
18:26:19:140 56.46 -2.98 0.45 19.50392157 58.23220431 303.9161295 2074.28105
18:26:19:234 56.46 -2.98 0.45 42.64117647 45.55334179 209.4857053 1136.833657
18:26:19:328 56.46 -2.98 0.45 151.2686275 35.77250498 963.5516213 1167.140501
18:26:19:500 56.46 -2.98 0.44 31.07254902 39.03278392 639.6648148 1341.278178
18:26:19:609 56.46 -2.98 0.43 136.5627451 27.98406086 361.2770045 2219.470112
18:26:19:687 56.46 -2.98 0.41 -28.53529412 43.3798225 226.690356 413.6220871
18:26:19:796 56.46 -2.98 0.4 19.50392157 23.54645897 2618.612504 129.4845201
18:26:19:906 56.46 -2.98 0.38 -4.61372549 36.2253215 267.4576232 689.6024525
18:26:20:0 56.46 -2.98 0.37 98.91568627 44.91939866 130.4615353 147.1352124
18:26:20:93 56.46 -2.98 0.35 26.75882353 30.88208658 204.8144025 600.0716071
18:26:20:187 56.46 -2.98 0.35 98.91568627 50.35319688 373.7069459 275.6217683
18:26:20:296 56.46 -2.98 0.36 -15.20196078 34.86687194 432.7046104 146.5832355
18:26:20:406 56.46 -2.98 0.37 116.954902 7.697880819 266.4542576 1524.114616
18:26:20:484 56.46 -2.98 0.37 116.7588235 41.29686651 412.0703865 370.9082869
18:26:20:609 56.46 -2.98 0.37 143.8176471 43.74207571 167.1919601 2541.047032
18:26:20:703 56.46 -2.98 0.37 55.58235294 35.22912516 212.6589475 804.4958041
18:26:20:796 56.46 -2.98 0.38 -28.14313725 4.437601884 2244.637692 2236.216947
18:26:20:890 56.46 -2.98 0.37 20.09215686 25.44828835 2194.584719 408.984427
18:26:20:984 56.46 -2.98 0.35 7.739215686 28.8896939 2456.528759 2401.750846
18:26:21:109 56.46 -2.98 0.34 65.38627451 24.63321862 544.2053954 2749.738249
18:26:21:203 56.46 -2.98 0.33 50.87647059 13.85618547 2074.28105 1301.548407
18:26:21:296 56.46 -2.98 0.33 147.7392157 62.30755298 552.4488961 627.7560097
18:26:21:406 56.46 -2.98 0.34 8.719607843 8.150697337 131.4459224 679.3123816
18:26:21:500 56.46 -2.98 0.33 80.28823529 5.162108314 2339.385185 644.4913549
18:26:21:609 56.46 -2.98 0.31 1.268627451 38.39884079 164.6971645 125.6490813
18:26:21:687 56.46 -2.98 0.3 144.2098039 25.62941496 207.136886 267.4576232
18:26:21:796 56.46 -2.98 0.3 65.77843137 22.18800942 139.0694924 1371.869369
18:26:21:906 56.46 -2.98 0.29 -18.92745098 34.32349212 518.2540751 1945.889683
18:26:22:0 56.46 -2.98 0.29 -15.39803922 30.97264988 702.6845115 2227.827794
18:26:22:93 56.46 -2.98 0.29 114.6019608 33.50842239 278.7471687 142.7769455

Table 2: The tabulated data produced by the Python post processor. Note; the first line
of data returns 0 for all GPS data (time, latitude, longitude, and speed)

While the post-processing program was funtional during most tests, some issues with
robustness and stability were obseved, mostly stemming from Python’s interface with the
Arduino serial monitor. The crashes occurred when the post-processor recieved a line of
data which was too short, causeing an error when diving the line into the separate lists.
Furthermore, post-processor and reciever were started before the GPS module, the GPS
data in the first line received was lost (Table 2).

40
 CHAPTER 4 CONCLUSIONS

The aim of this study was to develop a system to acquire data from a mountain bike to
better quantify performance, therefore allowing effective changes to bike setup, riding
style, and race tactics. While the concept of using GPS data to track position and speed
in cycling is accepted and implemented in many commercially available products, the
more in-depth methods data investigated here are less so.

The GPS component of the system was successfully developed; the GPS module and
Arduino were shown to accurately track position, and the post-processing methods
displayed well this data. The post-processing of GPS data was proven to create a practical
GPX file which may be uploaded directly to Strava and be converted into a format useable
by Google Earth.

The tests of the suspension sensors revealed that the data acquired is useful for setup and
adjustment, and can be used to identify fundamental suspension events. Further testing is
required however, as the rear suspension sensor was not tested, and only a single set of
data was acquired for each test.

Although the braking force sensor components were able to return values of force when
the brakes were applied, the usefulness of such information is not confirmed in this study.
The test performed here were of too short a duration, and performed on fairly modest
terrain, where complex braking events, such as those which may be observed in a real
mountain bike ride, did not take place

The telemetry component of the system was successful in transferring data and did
quickly enough to keep up with the sample rate of the current system. It was, however,
lacking in reliability at times due to the adverse effect of radio interference. Furthermore,
telemetry by this method (2.4GHz radio) may prove to be less useful in a more advanced
iteration of the data acquisition system, which would potentially have both a much higher
sample rate and more data fields to be transmitted.

The combination of the separate components into the full system was somewhat
successful, in that all sources of data were gathered, transmitted, displayed and logged,

41
however the lack of testing under real-world conditions somewhat limits the conclusions
that can be drawn about the functionality of the system as a whole.

42
 CHAPTER 5 FUTURE WORK

5.1 LIMITATIONS
One of the main limitations of this project was the use of fairly basic electronic
components. While the Arduino Uno proved useful for this proof of concept, a more
powerful, faster operating microcontroller would be better suited to the present
application. Alternatively, two Arduino Uno’s could have been used; one to collect GPS
data, which is limited to 10Hz, and one to collect suspension and braking data at a much
faster sample rate. Alternatively, GPS could be removed from the system entirely, and
instead handled by a GPS device already on the market, while the data acquisition system
developed here focuses solely on suspension and braking data. This would allow a much
higher sample rate to be achieve, as well as giving more headroom for additional sensors.
The drawback of this configuration is synchronising the two sets of data gathered on two
unconnected devices. This could be overcome by interfacing the two devices directly or
synchronising the timing chips of both at the beginning of each recording.

The study was unfortunate in timing, in that the system was developed over autumn and
winter, meaning agreeable weather in which one could ride mountain bike trails and
handle electronics outdoors was rare. This could be overcome by developing some
method of sealing the electronics (mentioned below) and performing tests when weather
conditions are dry.

Furthermore, printed circuit boards containing the supporting components could have
been utilised to slim down the hardware and allow for much neater packaging, built into
a bespoke case. To allow for real-world testing, the case would be sealed against water
and dust ingress, and all wiring on the bike would be terminated with waterproof
connector housings. Additionally, real world testing would require an improved power
supply solution for the system, such as an integrated, rechargeable lithium ion or lithium
polymer battery. The radio antennae in particular use a large amount of power, and the
charge from the 9V batteries used in the current study were depleted quickly.

The nRFL01+ radio antennae proved challenging to work with; they appeared very
sensitive to interference from other sources of radio such as Wi-Fi and mobile telephones.
During the bench testing of the modules, the radio signal would cut out fairly often and
return after a random amount of time, most likely due to the high level of interference
43
found on campus. When range testing on open ground, away from other sources of radio
signals, the reliability appeared to improve. Indeed, this may prove not to be an issue
when the system is in service, as mountain bike trails tend to be free of the level of
interference found on campus. One step which may be taken to reduce interference is
creating a Faraday shield to cover the printed circuit board of the radio module, while
leaving the antenna exposed, however the effectiveness of such measures would have to
be investigated.

A problem encountered in the development of this project was that the integrated SD card
reader/writer stopped functioning during early testing. To confirm the issue was with the
hardware, the Arduino was loaded with an example code, included in the Adafruit GPS
library (Adafruit, 2018), and an attempt was made to write a file to the SD card. The
program returned that the initialisation of the SD card had failed, and no data was written
to the SD card. To verify the functionality of the SD card itself, files were written to and
read from the card using a desktop computer successfully, suggesting the problem lay
with the reader/writer or within the PCB onto which it was integrated.

The post-processing program, while performing the basic functions of data display and
logging, has much room for improvement. Firstly, the incorporation of a graphical user
interface (GUI) would greatly improve the usability and functionality of the system. At
present the program begins recording data as soon as it is opened and continues until it is
fully exited, which is inconvenient, especially if one wishes to have the program start
recording data at short notice. A GUI could present the user with options to start and stop
receiving data, to select which data is displayed, and select whether to display data only
or display and log data. Furthermore, as the radio antennae used can be configured to
receive and transmit, the post processor could be used to send commands to the on-board
hardware, for example to change from transmitting data to logging data onto the SD card.

The displacement sensor chosen to track front suspension movement had an issue where
the small tab of the membrane potentiometer which protruded from the end of the case
was quite brittle and broke twice (Figure 29). The conductive traces in the remaining part
of the film were too thin to reliably crimp new pins to the component, and as such, the
whole displacement sensor had to be replaced. Future work to solve this problem may
include manufacturing of a case or guard which attached to the end of the sensor,
protecting the pins and the film from impacts and excessive bending. There also appears

44
to be space within the case of the sensor to move the membrane element so that the
protruding tab is smaller. This would necessitate breaking the adhesive holing the
membrane to the case and reattaching, which may have damaged the sensor if, for
example, heat and excessive force was used to loosen the adhesive, or an adhesive not
compatible with the film material was used in the reattachment.

Figure 29: The broken tabs on two displacement sensors.

The wiring for the rear brake force sensor (Appendix C, Figure 32) and the mounting for
the rear shock were also broken during testing, meaning no results were acquired from
these compenents.

The method of testing for the GPS module limited the conclusions which could be drawn
as the results obtained were not compared to any known data set for verification. While
observations show that the GPS path follows the same route taken during the test, that is,
it can be seen to circle the same block of buildings, the precision of the results cannot be
demonstrated to a degree of accuracy any greater than the width of the road; around 5-
10m. To assist in the validation of the GPS results, the test could be repeated, moving the
GPS module along a measured route. Comparing the resulting GPS data to this measured
route would give an error, therefore quantifying the accuracy of the device. Alternatively,
a GPS device, the accuracy of which is known, could be moved in tandem with the GPS

45
device under test, again, resulting in a set of control data against which the results could
be compared.

The method of sensing the rear wheel travel may also be improved. At present the travel
is measured directly at the shock absorber, rather than at the rear wheel, meaning the
value presented by the postprocessor is not the travel of the rear axle relative to the frame.
The shock travel is 63mm compared to the rear wheel travel of 158mm, giving a leverage
ratio of approximately 2.5, however since the shock absorber is actuated via a four-bar
linkage, this leverage ratio is dependent on the position of the rear axle in its travel. This
could be overcome by modelling the four-bar linkage of the bike, and calibrating the post-
processor to convert shock absorber travel into rear axle travel, or by devising some
method of measuring rear axle displacement directly. The former of these solutions
appears to be the easiest; the each link in the four bar linkage is of a known length, and
analysis of four-bar mechanisms are well studies, however, if future systems aimed to be
compatible with multiple bikes, then either every bike would have to be measured and
analysed as required, or a database of all suspension designs and geometries expected to
be encountered would have to be created (A considerable task, especially taking into
account the fact that suspension geometry is updated by many manufacturers year on
year, and may even vary with the size of the frame). Measuring the movement of the rear
axle directly presents difficulties, as the rear axle is at distance from the front triangle of
the frame, which is the part of the bike that displacement must be measured relative to. It
could be accomplished by optical methods, by measuring the change in angle of the chain-
stays (portion of the frame between the crankset and the rear axle) relative to the front
triangle of the frame, or by accelerometers on both the front triangle of the frame and at
the rear axle, where the second integration of acceleration by time would give the
displacement for both, and comparison of these two values would give the relative
displacement of the rear axle with respect to the frame.

5.2 ADDITIONS
The scope for additional data sources that may be incorporated into this system is
massive, both by integrating the system with third-party sensors currently on the market,
as well as building in further sensors to the system.

The system could be given ANT+ (Dynastream Innovations Inc., 2018) compatibility, it
would allow the user to add many third-party products from different manufacturers to
46
sense a wealth of information about both bike and rider, such as power output, cadence,
gear selection, and heart rate. The system would then collate and process this information
for analysis. ANT+ compatibility would also allow a wireless head unit to be developed,
which would display data to the rider in real time.

To assist in analysing the effectiveness of the suspension set up, it would be useful to
incorporate into the system some method of sensing vibration in the portion of the frame
supported by the suspension, as well rear triangle and fork lowers. Comparing the
vibration in the sprung and un-sprung parts of the frame would allow the user to examine
the effectiveness of the suspension. Vibration sensors on the frame, used in conjunction
with tyre pressure sensors, may also be useful in optimising tyre pressures and tyre choice
for a given course. The vibration sensors may be able to sense the harsh bottom out of a
tyre when the wheel rim comes into contact with the riding surface, while the tyre pressure
sensors would return a spike in pressure.

The addition of wheel speed sensors into the system would allow the system to better
analyse how much traction the bike has; it would show the user instances of wheel locking
(skidding) and would show when the difference in speed between the two wheels is great,
which may suggest a loss of traction. Combining this information with feedback from the
rider may allow the cause of losses in traction to be identified and adjusted for.

Another method of tracking suspension travel would be to used video cameras at on the
frame of the bike, taking videos of the suspension during a ride. The video could then be
analysed using image processing techniques in MATLAB (The Mathworks, Inc., 2018).
Small ‘action-sports’ cameras such as the GoPro Hero 6 are capable of recording 1080p
high-definition footage at 240fps (GoPro, Inc., 2018), which would give far more accurate
tracking of suspension movement that the 10Hz sample rate the system developed here is
capable of. The drawbacks of using cameras in this way include the challenge of
synchronising the suspension data gathered by the camera with the GPS and braking data,
as well as the battery life of the camera. Furthermore, depending on frame and suspension
design, the added bulk and weight of two cameras may prove problematic.

47
 BIBLIOGRAPHY

Adafruit, 2018. Adafruit Ultimate GPS Library. New York(NY): GitHub, Inc..
Alps Electric Co., Ltd., 2018. RSA0N11S9A0K Data Sheet. Tokyo: Alps Electric Co.,
Ltd..
Arduino, 2017. Sheilds. [Online]
Available at: https://www.arduino.cc/en/Main/ArduinoShields
[Accessed 10 December 2017].
Arduino, 2017. What is Arduino?. [Online]
Available at: https://www.arduino.cc/en/Guide/Introduction
[Accessed 8 December 2017].
Arduino, 2018. Arduino Uno Rev 3. [Online]
Available at: https://store.arduino.cc/usa/arduino-uno-rev3
[Accessed 26 January 2018].
Atmel Corporation, 2016. Amtel ATmega328/P Datasheet. San Jose: Atmel Corporation.
Austerlitz, H., 2003. Data Aquisition Techniques Using PCs. 2nd ed. Amsterdam:
Academic Press.
Autodesk, Inc., 2017. Autodesk Inventor 2017. San Rafael(California): Autodesk, Inc..
Autodesk, Inc., 2018. Circuits. San Rafael(California): Autodesk, Inc..
Bates, M., 2011. PIC Microcontrollers: An Introduction to Microelectronics. 3rd ed.
s.l.:Elsevier.
Beach, J., 2011. Syntax Highlight Code in Word Documents. [Online]
Available at: http://www.planetb.ca/syntax-highlight-word
[Accessed 30 March 2018].
Burgress, D., Naughton, G. & Norton, K., 2006. Profile of movement demands of national
football players in Australia. Journal of Science and Medicine in Sport, 9(4), pp. 334-
341.
Burr, J. F., Drury, C. T., Ivey, A. C. & Warburton, D. E. R., 2012. Physiological demands
of downhill mountain biking. Journal of Sport Sciences, 30(16), pp. 1777-1785.
Burr, J. F., Jamnik, V. K., Shaw, J. A. & Gledhill, N., 2010. Physiological Demands of
Off-Road Vehicle Riding. Medicine & Science in Sports & Exercise, 42(7), pp. 1345-
1354.
Continental AG., 2018. Bicycle Tyre Range 2018. Hanover: Continental AG..
Davis, J., 2004. Tensile Testing. 2nd Edition ed. Materials Park(Ohio): ASM
International.

48
Deutsch, M., Kearney, G. & Rehrer, N., 2007. Time – motion analysis of professional
rugby union players during match-play. Journal of Sport Sciences, 25(4), pp. 461-472.
DT Swiss AG., 2016. DT Swiss Wheels User Manual. Biel/Bienne: DT Swiss AG..
Dynastream Innovations Inc., 2018. What is ANT+?. [Online]
Available at: https://www.thisisant.com/consumer/ant-101/what-is-ant/
[Accessed 4 March 2018].
Firewing, 2014. Firewing Protosheild. [Online]
Available at: http://www.firewing.info/pmwiki.php?n=Firewing.ProtoShield
[Accessed 10 December 2017].
Formula Group S.r.l, 2012. Formula Technical Bicycle Components 2012. Prato: Formula
Group S.r.l.
Fraden, J., 2016. Handbook of Modern Sensors: Physics, Designs, and Applications. 5th
ed. San Diego: Springer-Verlag.
Garmin Ltd., 2016. Garmin Edge 810 Owner's Manual. Olathe(KS): Garmin Ltd..
Gawronski, T., 2017. GrabCAD Community. [Online]
Available at: https://grabcad.com/library/steel-29-27-5-b-hardtail-mountain-bike-with-
159-mm-suspension-fork-1
[Accessed 26 January 2018].
GlobalTop Technology Inc., 2011. FGPMMOPA6H GPS Standalone Module Data Sheet.
Taiwan: GlobalTop Technology Inc..
GlobalTop Technology Inc., 2012. GlobalTop PMTK Command Packet. Taiwan(R.o.C.):
GlobalTop Technology Inc..
Google LLC, 2018. Google Earth Pro. Mountain View(CA): Google LLC.
Google LLC, 2018. Keyhole Markup Language. Mountain View(CA): Google LLC.
GoPro, Inc., 2018. GoPro HERO6 Black. [Online]
Available at: https://shop.gopro.com/EMEA/cameras/hero6-black/CHDHX-601-
master.html
[Accessed 25 March 2018].
Gpx2kml, 2018. GPX2KML. [Online]
Available at: https://gpx2kml.com/
[Accessed 10 March 2018].
Greene, P. R. & McMahon, T. A., 1979. Reflex stiffness of man's anti-gravity muscles
during kneebends while carrying extra weights. Journal of Biomechanics, 12(12), pp.
881-883, 885-891.

49
Hunter, J., 2007. Matplotlib: A 2D graphics environment. Computing In Science &
Engineering, 9(3), pp. 90-95.
Hurst, H. T. & Atkins, S., 2006. Power output of field-based downhill mountian biking.
Journal of Sport Sciences, 24(10), pp. 1047-1053.
Hurst, H. T. et al., 2011. The effect of suspension forks on upper body muscle activation
during a simulated mountain bike drop-off. Liverpool, European College of Sports
Sciences.
Hurst, T. H. et al., 2013. GPS-Based Evaluation of Activity Profiles in Elite Downhill
Mountain Biking and the Influence of Course Type. Journal of Science and Cycling, 1(2),
pp. 25-32.
International Electrotechnical Commission, 2001. IEC 60592 - Degrees of Protection
Provided by Enclosures (IP Codes). Virginia USA: National Electrical Manufacturers
Association.
Kaplan, E. D., 1996. Understanding GPS: Principles and Applications. Boston: Artech
House.
Lowe, S., 2018. https://www.strava.com/activities/1462524524/overview. [Online]
Available at: https://www.strava.com/activities/1462524524/overview
[Accessed 2018 March 20].
Machin, J., 2017. xlwt. s.l.:Lingfo Pty Ltd..
MacRae, H. S., Hise, K. J. & Allen, P. J., 2000. Effects of front and dual suspension
mountain bike systems on uphill cycling performance. Medicine & Science in Sports &
Exercise, 32(7), pp. 1276-1280.
Microsoft, 2016. Excel 2016. Redmond(WA): Microsoft Corporation.
Neilens, H. & Lejeune, T., 2000. Energy Cost of Riding Bicycles with Shock Absorption
Systems on a Flat Surface. International Journal of Sports Medicine, 22(6), pp. 400-404.
Nishii, T., Umemura, Y. & Kitagawa, K., 2004. Full suspension mountain bike improves
off-road cycling performance. Journal of Sports Medicine and Physical Fitness, 44(1),
pp. 356-360.
Nordic Semiconductor, 2008. nRF24L01+ Single Chip 2.4GHz Transceiver Product
Specification. Trondheim(Norway): Nordic Semiconductor.
Opliphant, T. E., 2006. A Guide to NumPy. s.l.:Trelgol Publishing.
RS Components Ltd., 2018. RS Pro Datasheet IPL Linear Position Sensor.
Corby(Northants): RS Components Ltd..

50
Sievert, S., 2018. drawnow 0.72.0. [Online]
Available at: https://pypi.python.org/pypi/drawnow/
[Accessed 28 February 2018].
SparkFun Electronics, 2017. SparkFun Ardumoto - Motor Driver Shield. [Online]
Available at: https://www.sparkfun.com/products/14129
[Accessed 10 December 2017].
SRAM LLC., 2012. 2013 RockShox Monarch RT3 Service Manual. Chigago(IL): SRAM
LLC..
SRAM LLC., 2013. RockShox Pike Suspension Fork User Manual. Chicago(IL): SRAM
LLC..
SRAM LLC., 2017. 2x/3x Mountain Bike Derailleurs User Manual. Chigago(IL): SRAM
LLC..
Strava Inc., 2018. Elevation for Your Activity. [Online]
Available at: https://support.strava.com/hc/en-us/articles/216919447-Elevation-for-
Your-Activity
[Accessed 9 March 2018].
Strava, Inc., 2018. Strava Features. [Online]
Available at: https://en.wikipedia.org/wiki/Universal_testing_machine
[Accessed 9 March 2018].
Strava, inc., 2018. Strava Premium. [Online]
Available at: https://www.strava.com/gopremium
[Accessed 9 March 2018].
Tekscan, Inc., 2017. FlexiForce Standard Model A201 Data Sheet. Boston(MA):
Tekscan, Inc..
The Mathworks, Inc., 2018. MATLAB. [Online]
Available at: https://uk.mathworks.com/products/matlab.html
[Accessed 25 March 2018].
Tinius Olsen, 2010. Tinius Olsen Benchtop Materials Testing Machines. Horsham(PA):
Advanced Test Equipment Corp..
Tinius Olsen, 2010. Tinius Olsen Benchtop Testers. Horsham(Pennsylvania): Tinius
Olsen.
Tinius Olsen, 2018. Tinius Olsen. [Online]
Available at: https://www.tiniusolsen.com/tinius-olsen-testing-machine-company
[Accessed 22 February 2018].

51
Townshend, A., Worringham, C. & Stewart, I., 2008. Assessment of Speed and Position
during Human Locomotion Using Nondifferential GPS. Medicine and science in sports
and exercise, 40(1), pp. 124-132.
van Rossum, G., 2018. Python. Wilmington(DE): Python Software Foundation.
Vemuri, A. T. & Sullivan, M., 2016. Ratiometric measurements in the context of LVDT-
sensor signal conditioning. Analog Applications Journal, Volume 2016Q3.
Vital Media Network, Inc., 2018. 2014 YT Wicked 650b Bike. [Online]
Available at: https://www.vitalmtb.com/product/guide/Bikes,3/YT/Wicked-
650b,14562#
[Accessed 26 January 2018].
Wang, E. & Hull, M., 1997. A Dynamic System Model of an Off-Road Cylist.
Transactions of the ASME Journal of Biomechanical Engineering, Volume 119, pp. 248-
253.
Wilczynski, H. & Hull, M., 1994. A Dynamic System Model for Estimating Surface-
Induced Frame Loads During Off-Road Cycling. Transactions of the ASME Journal of
Mechanical Design, Volume 116, pp. 816-822.
Witte, T. & Wilson, A., 2004. Accuracy of non-differential GPS for the determination of
speed over ground. Journal of Biomechanics, 37(12), pp. 1891-1898.
Wong, M. & Hull, M., 1981. Transfer Function Measurement of the Arms in Flexion. In:
Advances in Bioengineering. New York: ASME, pp. 167-170.
YT Industries GmbH, 2014. YT Industries Wicked 650B. [Online]
Available at: https://www.yt-industries.com
[Accessed 26 January 2018].

52
 APPENDIX A - SAFETY ASSESSMENT

DIVISION OF MECHANICAL ENGINEERING & MECHATRONICS

PERSONAL RISK ASSESSMENT FOR STUDENT PROJECTS

PLEASE READ THIS FIRST

Each student who undertakes Project Work is required to complete all of the sections below which
are relevant to the work which is to be undertaken. In many cases, details may not be known at
the start of the project and it will be necessary to enter them later. At no time, however, may an
activity start unless the risks which it may involve have been assessed and recorded. The
form must be available for inspection during the project and a copy must be appended to the
final report. A copy must be sent to your Supervisor before you start any practical work for
your project and the attention of your Supervisor should be drawn to any additions during the
session.

Project work is not particularly dangerous, but it is important at this stage to realise that in your
professional career you will have a legal obligation to think carefully about any hazards which
may be encountered. This awareness encourages careful working and it makes sure that everyone
will be sure that the necessary precautions have been identified and are being applied. Consult
your supervisor if you require special safety information and always use the precautions which
are recommended. The first stage of safe working is that you think carefully about what you are
planning to do.
YOUR FULL NAME Stewart Joseph Lowe

STUDENT ID 130015085

NAME OF Keith Johnston

SUPERVISOR

TITLE OF PROJECT Data Acquisition for Improvements in Mountain

Bike Racing

In the sections below, the date required is the date when you first specified the details concerned.
As noted above, you may add entries throughout your project when the need arises, but you must
always assess the risk of an activity before you perform it. Use additional pages if required

1.0 EMERGENCY PROCEDURES

Sign here to confirm that you know the following. Note details. See Honours Guide and Notices Displayed
on walls etc. Relate to the location of your work
ITEM Date Sign and add details
Nearest Telephone for Emergency 10/12/17 F16, Tel.: 4141
Help and Number to Ring

Trained First Aiders 10/12/17 Cameron Anderson, David Turbine (F9)

Jenny Murray (School Office)

Fire Assembly Point 10/12/17 In front of Fulton Building

Nearest First Aid Equipment 10/12/17 Drive team office

53
2.0 ELECTRICAL RISKS
Identify electrical risks and indicate the precautions to be taken.
RISK Date Details and Precautions
Exposed DC potential differences n/a
exceeding 50V

Exposed AC potential differences n/a

exceeding 50V

3.0 MECHANICAL RISKS

List any mechanical risks which you will encounter. Include the lifting of heavy weights, the use of hand
or power tools and the use of pressurised systems
RISK Date Details and Precautions
Drill Press 11/2/18 Drilling holes in mounting hardware: safety glasses
worn, work held securely in vise.

4.0 THERMAL RISKS

Identify risks from equipment or substances which will be at high or low temperatures
RISK Date Details and Precautions
High Temperatures 13/11/17 Soldering iron: Always return soldering iron to
stand when not in use, avoid contact with heated
element.

Low Temperatures

5.0 RISK from DUST and POWDER

Identify risks of fire, explosion, or injury by contact/breathing from dust or powder
RISK Date Details and precautions

54
6.0 RISK from CHEMICALS or GASES
List each chemical substance you use which you consider to offer a significant risk, the date when you
first knew you would use it, the risks associated with it and the precautions to be used. Risks are listed on
containers, in manufacturers data sheets and catalogues, and are usually known to research workers and
members of staff.
Substance Date Details and Precautions
Soldering flux gasses 13/11/17 Use benchtop extractor fans, solder in a well
ventilated room.

7.0 LOCATION OF YOUR WORK

Give the location(s) in which you will be working, specifying any special safety facility which you need
to use (isolated electrical supply, fume cupboard, etc)
LOCATION Date Special Facility
Fulton Mechatronics Lab 13/11/17 Soldering station with fans

8.0 DECLARATION
Date Your Signature
I have given careful consideration to 3/4/18
the work I am planning to do and I
believe I have identified the
significant risks to which I will be
exposed. I will consult my Supervisor
if I am uncertain about safe working
practices during my work.

55
APPENDIX B - TIME MANAGEMENT DIAGRAM

56
 APPENDIX C - DETAILED PHOTOGRAPHS OF

MOUNTING HARDWARE

Figure 30: The electronics case mounted to the frame. Also pictured are the radio
(Indicated with blue box) and GPS antennae (indicated with green arrow), as well as the
Garmin Edge 810 head unit used to keep track of speed.

Figure 31: Left shows the front suspension displacement sensor mounted to the fork. Right
shows a detailed view of the fork displacement sensor connection and the front braking
force sensor mounted in the caliper (circled blue). Arrows show how the sensor wiring

57
(green and blue) are routed to the electronics case by following the brake hose (yellow)
up the fork leg.

Figure 32: Left shows the broken wiring for the rear brake force sensor, most likely due
to suspension movement. Right shows how the brake force sensor mounted into the
caliper.

58
 APPENDIX D - SENSOR CALIBRATION

1. int inputPin = A0; //name pin A0 as input pin

2. int output; //create output variable
3.
4. void setup() {
5.
6. pinMode(inputPin,INPUT); //initialise input pin
7. Serial.begin(9600); //start serial monitor
8.
9. }
10.
11. void loop() {
12.
13. output = analogRead(inputPin); //read in voltage
14. Serial.println(output); //print digital value
15. delay(100); //delay 0.1s for easier reading
16.
17. }

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011)

59
 APPENDIX E - GPS TEST CODE

1. //Libraries for SD card

2. #include <SD.h>
3. #include <SPI.h>
4.
5. //Libraries for GPS
6. #include <Adafruit_GPS.h>
7. #include <SoftwareSerial.h>
8.
9. //Begin SoftwareSerial, sheild uses pins 8 and 7
10. SoftwareSerial mySerial(8, 7);
11. Adafruit_GPS GPS(&mySerial);
12.
13. //String variables for 2 NMEA sentances, RMC and GGA
14. String NMEA1;
15. String NMEA2;
16. //For reading character stream from GPS
17. char c;
18. //CS pin on SD reader
19. int chipSelect = 10;
20. //File object for SD
21. File sensorData;
22.
23.
24. void setup()
25. {
26.
27. Serial.begin(115200);
28.
29. //Initialise GPS Module
30. GPS.begin(9600);
31. GPS.sendCommand("$PGCMD,33,0*6D"); //Stop GPS sending antenna data
32. GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCGGA); //GPS only streams RMC and GGA
sentences
33. GPS.sendCommand(PMTK_SET_NMEA_UPDATE_10HZ); // 10 Hz update rate
34.
35. //Intialise SD card
36. SD.begin(chipSelect);
37. if(SD.exists("CSVData.txt")){ //Delete previous data if any
38. SD.remove("CSVData.txt");
39. }
40. if(SD.exists("NMEAraw.txt")){
41. SD.remove("NMEAraw.txt");
42. }
43.
44. delay(1000); //Pause
45.
46. }
47.
48.
49. void loop()
50. {
51.
52. readGPS();
53.
54. if(GPS.fix==1){//Only write GPS data when there is a fix
55.
56. //Create and write to file of raw NMEA sentances, not strictly required fo
r GPS tracker but data may be useful for debugging
57. sensorData = SD.open("NMEAraw.txt",FILE_WRITE); //Create file to store raw
NMEA sentances
58. sensorData.println(NMEA1); //Write NMEA sentances to file in SD card
59. sensorData.println(NMEA2);
60. sensorData.close();
61.

60
 62. //Create and write to file of coordinates
63. sensorData = SD.open("CSVData.txt",FILE_WRITE);
64. if(GPS.hour<=9){
65. sensorData.print("0");
66. }
67. sensorData.print(GPS.hour,DEC);
68. sensorData.print(":");
69. if(GPS.minute<=9){
70. sensorData.print("0");
71. }
72. sensorData.print(GPS.minute,DEC);
73. sensorData.print(":");
74. if(GPS.seconds<=9){
75. sensorData.print("0");
76. }
77. sensorData.print(GPS.seconds,DEC);
78. sensorData.print(",");
79. sensorData.print(GPS.latitudeDegrees,8);
80. sensorData.print(",");
81. sensorData.print(GPS.longitudeDegrees,8);
82. sensorData.print(",");
83. sensorData.println(GPS.altitude,8);
84. sensorData.close();
85.
86. }
87.
88. }
89.
90. void readGPS(){
91.
92. while(!GPS.newNMEAreceived()) { //Keep reading charaters until a complete NM
EA is seen
93. c=GPS.read();
94. }
95.
96. GPS.parse(GPS.lastNMEA()); //Parse NMEA
97. NMEA1=GPS.lastNMEA(); //save NMEA
98.
99. while(!GPS.newNMEAreceived()) { //Repeat above for NMEA2
100. c=GPS.read();
101. }
102.
103. GPS.parse(GPS.lastNMEA());
104. NMEA2=GPS.lastNMEA();
105.
106. }

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011)

61
 APPENDIX F - RECEIVER CODE

1. #include <SPI.h>
2. #include <RF24.h>
3.
4. //Create radio object
5. RF24 radio(7,8);
6.
7. //Address to recieve data
8. const byte address[6] = "00001";
9.
10. //Create struct to store recieved data
11. typedef struct{
12.
13. float latitude;
14. float longitude;
15. float speed;
16. int hour;
17. int minute;
18. int seconds;
19. int milliseconds;
20. int FBForce;
21. int RBForce;
22. int frontTrav;
23. int rearTrav;
24.
25. }
26. B_t;
27.
28. B_t recieve;
29.
30. void setup() {
31.
32. //Begin serial monitor
33. Serial.begin(115200);
34.
35. //Initialise radio
36. radio.begin();
37. radio.openReadingPipe(0,address);
38. radio.setPALevel(RF24_PA_MIN);
39. radio.setDataRate(RF24_250KBPS);
40. radio.setChannel(124);
41. radio.startListening();
42.
43.
44. }
45.
46. void loop() {
47.
48. if(radio.available()){
49.
50. //Recieve radio data
51. radio.read(&recieve,sizeof(recieve));
52.
53. //Write to serial monitor
54. Serial.print("$,");
55. Serial.print(recieve.hour,DEC);
56. Serial.print(",");
57. if(recieve.minute<=9){
58. Serial.print("0");
59. }
60. Serial.print(recieve.minute,DEC);
61. Serial.print(",");
62. if(recieve.seconds<=9){
63. Serial.print("0");
64. }

62
 65. Serial.print(recieve.seconds,DEC);
66. Serial.print(",");
67. if(recieve.milliseconds<=9) {
68. Serial.print("0");
69. }
70. if(recieve.milliseconds<=99) {
71. Serial.print("0");
72. }
73. Serial.print(recieve.milliseconds);
74. Serial.print(",");
75. Serial.print(recieve.latitude);
76. Serial.print(",");
77. Serial.print(recieve.longitude);
78. Serial.print(",");
79. Serial.print(recieve.speed);
80. Serial.print(",");
81. Serial.print(recieve.frontTrav);
82. Serial.print(",");
83. Serial.print(recieve.rearTrav);
84. Serial.print(",");
85. Serial.print(recieve.FBForce);
86. Serial.print(",");
87. Serial.println(recieve.RBForce);
88.
89. }
90.
91. }

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011)

63
 APPENDIX G - TRANSMITTER CODE

1. //Include relevant libraries

2. #include <Adafruit_GPS.h>
3. #include <SoftwareSerial.h>
4. #include <SPI.h>
5. #include <RF24.h>
6.
7. //Name sensor input pins, uncomment for real-world tests
8. /*int frontBrake = A0;
9. int rearBrake = A1;
10. int fork = A2;
11. int shock = A3;*/
12.
13. String NMEA;
14.
15. //Initialise software serial and create object for GPS
16. SoftwareSerial mySerial(8, 7);
17. Adafruit_GPS GPS(&mySerial);
18. //Create radio object
19. RF24 radio(2, 3);
20.
21. //Variables to read and store NMEA sentances
22. char c;
23.
24. //Address for radio
25. const byte address[6] = "00001";
26.
27. void setup() {
28.
29. Serial.begin(9600);//For debugging, not necessary
30.
31. //Initialise GPS Module
32. GPS.begin(9600);
33. GPS.sendCommand("$PGCMD,33,0*6D"); //Stop GPS sending antenna data
34. GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY); //GPS only streams RMC senten
ces
35. GPS.sendCommand(PMTK_SET_NMEA_UPDATE_10HZ);
36.
37. //Initialise radio
38. radio.begin();
39. radio.openWritingPipe(address);
40. radio.setPALevel(RF24_PA_MIN);
41. radio.setDataRate(RF24_250KBPS);
42. radio.setChannel(124);
43. radio.stopListening();
44.
45. //Initialise sensor input pins, uncomment for real-world tests
46. /*pinMode(frontBrake,INPUT);
47. pinMode(rearBrake,INPUT);
48. pinMode(fork,INPUT);
49. pinMode(shock,INPUT);*/
50.
51. randomSeed(analogRead(0));
52.
53. delay(1000);
54.
55. }
56.
57. void loop() {
58.
59. readGPS();
60.
61. //Create struct which will be transmitted
62. typedef struct {
63.

64
 64. float latitude = GPS.latitudeDegrees;
65. float longitude = GPS.longitudeDegrees;
66. float Speed = GPS.speed;
67. int hour = GPS.hour;
68. int minute = GPS.minute;
69. int seconds = GPS.seconds;
70. int milliseconds = GPS.milliseconds;
71.
72. //Assign random values for benchtop tests, comment out for real-
world tests
73. int FBForce = random(850);
74. int RBForce = random(850);
75. int frontTrav = random(159,975);
76. int rearTrav = random(689);
77.
78. //Uncomment for real world test
79. /*int FBForce = analogRead(frontBrake);
80. int RBForce = analogRead(rearBrake);
81. int frontTrav = analogRead(fork);
82. int rearTrav = analogRead(shock);*/
83.
84. }
85. A_t;
86.
87. A_t transmit;
88.
89. //Transmit data
90. radio.write(&transmit, sizeof(transmit));
91.
92. Serial.println("Transmitting...");//For debugging, not necessary
93.
94.
95. }
96.
97.
98. void readGPS() {
99.
100. while (!GPS.newNMEAreceived()) { //Keep reading charaters until a com
plete NMEA is seen
101. c = GPS.read();
102. }
103. GPS.parse(GPS.lastNMEA());//Parse NMEA
104. NMEA = GPS.lastNMEA();//Needed?
105.
106. }

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011).

65
 APPENDIX H - GPX WRAPPER FOR GPS

DATA

1. <?xml version="1.0" encoding="UTF-8"?>

2. <gpx creator="StravaGPX" version="1.1" xmlns="http://www.topografix.com/GPX/1/
1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.top
ografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3
http://www.garmin.com/xmlschemas/GpxExtensionsv3.xsd http://www.garmin.com/xml
schemas/TrackPointExtension/v1 http://www.garmin.com/xmlschemas/TrackPointExte
nsionv1.xsd" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtensio
n/v1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
3. <metadata>
4. <time> START TIME/DATE HERE </time>
5. </metadata>
6. <trk>
7. <name>GPS_test</name>
8. <trkseg>
9.
10.
11. DATA FROM SD CARD HERE
12.
13.
14. </trkseg>
15. </trk>
16. </gpx>

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011)

66
 APPENDIX I - POST-PROCESSOR CODE

1. #Import relevant libraries

2. import serial
3. import numpy
4. import matplotlib.pyplot as plt
5. from drawnow import *
6. import xlwt
7. import time
8.
9. #Set recording to true on startup
10. recording = True
11.
12. #Counter to organise Excel data
13. i = 0
14.
15. #Initialise serial port and flush old data
16. data = serial.Serial("/dev/cu.usbmodem1421",115200)
17. data.flushInput()
18. data.flushOutput()
19. time.sleep(.1)
20.
21. #Create lists for data
22. hour = []
23. minute = []
24. seconds = []
25. milliseconds = []
26. speed = []
27. latitude = []
28. longitude = []
29. frontTrav = []
30. rearTrav = []
31. frontBrake = []
32. rearBrake = []
33.
34. #Counters for suspension bottom outs
35. bottomOutOccF = 0
36. bottomOutOccR = 0
37.
38. #Turn on interactive plotting
39. plt.ion()
40.
41. #Initialise spreadsheet by adding headings
42. bold = xlwt.easyxf('font: bold 1')
43. book = xlwt.Workbook(encoding="utf-8")
44. gpsSheet = book.add_sheet("GPS",cell_overwrite_ok=True)
45. gpsSheet.write(0,0,'Average Speed:',bold)
46. gpsSheet.write(2,0,'Max Speed:',bold)
47. gpsSheet.write(0,3,'Average Fork Sag (mm):',bold)
48. gpsSheet.write(1,3,'No. of Fork Bottom Outs:',bold)
49. gpsSheet.write(2,3,'Fork Bottom Out (mm):',bold)
50. gpsSheet.write(0,5,'Average Shock Sag (mm):',bold)
51. gpsSheet.write(1,5,'No. of Shock Bottom Outs:',bold)
52. gpsSheet.write(2,5,'Shock Bottom Out (mm):',bold)
53. gpsSheet.write(4,0,'Time',bold)
54. gpsSheet.write(4,1,'Latitude',bold)
55. gpsSheet.write(4,2,'Longitude',bold)
56. gpsSheet.write(4,3,'Speed',bold)
57. gpsSheet.write(4,4,'Front Suspension Travel (mm)',bold)
58. gpsSheet.write(4,5,'Rear Suspension Travel (mm)',bold)
59. gpsSheet.write(4,6,'Front Braking Force (N)',bold)
60. gpsSheet.write(4,7,'Rear Braking Force (N)',bold)
61.
62. def makeFig(): #Create the figure
63.
64. plt.subplot(221)

67
65. plt.plot(frontTrav)
66. plt.title('Fork Travel')
67. plt.ylim(0,160)
68. plt.ylabel('Travel (mm)')
69.
70. plt.subplot(222)
71. plt.plot(rearTrav)
72. plt.title('Shock Travel')
73. plt.ylim(0,65)
74. plt.ylabel('Travel (mm)')
75.
76. plt.subplot(223)
77. plt.plot(frontBrake)
78. plt.title('Front Brake Force')
79. plt.ylim(0,4000)
80. plt.ylabel('Force (N)')
81.
82. plt.subplot(224)
83. plt.plot(rearBrake)
84. plt.title('Rear Brake Force')
85. plt.ylim(0,4000)
86. plt.ylabel('Force (N)')
87.
88. def writeExcel(): #Write to speadsheet
89.
90. #Call global variables for counters
91. global i
92. global bottomOutOccF
93. global bottomOutOccR
94.
95. avgSpeed = numpy.mean(speed) #Calculate average speed
96. maxSpeed = max(speed) #Calculate max speed
97. avgSagF = numpy.mean(frontTrav) #Calculate sag
98. avgSagR = numpy.mean(rearTrav)
99. maxTravF = max(frontTrav) #Calculate maximum travel utilisation
100. maxTravR = max(rearTrav)
101. #If current suspension value is in the last 5mm of travel, +1 botto
m out
102. if(frontTrav[i]>=155):
103. bottomOutOccF = bottomOutOccF+1
104. if(rearTrav[i]>=60):
105. bottomOutOccR = bottomOutOccR+1
106.
107. #Write calculated values to sheet
108. gpsSheet.write(0,1,avgSpeed)
109. gpsSheet.write(2,1,maxSpeed)
110. gpsSheet.write(0,4,avgSagF)
111. gpsSheet.write(1,4,bottomOutOccF)
112. gpsSheet.write(2,4,bottomOutF)
113. gpsSheet.write(0,6,avgSagR)
114. gpsSheet.write(1,6,bottomOutOccR)
115. gpsSheet.write(2,6,bottomOutR)
116.
117. #Write aquired data to sheet
118. gpsSheet.write(i+5,0,'{:d}:{:d}:{:d}:{:d}'.format(hour[i],minute[i]
,seconds[i],milliseconds[i]))
119. gpsSheet.write(i+5,1,latitude[i])
120. gpsSheet.write(i+5,2,longitude[i])
121. gpsSheet.write(i+5,3,speed[i])
122. gpsSheet.write(i+5,4,frontTrav[i])
123. gpsSheet.write(i+5,5,rearTrav[i])
124. gpsSheet.write(i+5,6,frontBrake[i])
125. gpsSheet.write(i+5,7,rearBrake[i])
126.
127. book.save("test.xls") #Save sheet
128.
129. i=i+1 #Counter +1
130.
131.

68
 132. while recording:
133.
134. line = data.readline() #Read line from Arduino serial port
135.
136. ## print line #Uncomment line to print raw data for debugging
137.
138. dataArray = line.split(',') #Separate data feilds and store in list

139.
140. #Every line Arduino outputs begins with '$'
141. #If recieved line begins with '$' proceed with storing data
142. if(dataArray[0]=="$"):
143.
144. dataArray.pop(0) #Remove the verification character
145. h = int(dataArray[0]) #Store list as variables
146. m = int(dataArray[1])
147. s = int(dataArray[2])
148. ms = int(dataArray[3])
149. lat = float(dataArray[4])
150. lon = float(dataArray[5])
151. v = float(dataArray[6])
152. ft = (int(dataArray[9])-155.53)/5.1
153. rt = int(dataArray[10])/11.042
154. fb = 2.71828**((int(dataArray[7])+1283)/266.06)
155. rb = 2.71828**((int(dataArray[8])+1283)/266.06)
156.
157. hour.append(h) #Add variables to list of each data field
158. minute.append(m)
159. seconds.append(s)
160. milliseconds.append(ms)
161. latitude.append(lat)
162. longitude.append(lon)
163. speed.append(v)
164. frontTrav.append(ft)
165. rearTrav.append(rt)
166. frontBrake.append(fb)
167. rearBrake.append(rb)
168.
169. drawnow(makeFig) #Update the figure
170. plt.pause(.000001) #Pause for stability
171.
172. writeExcel() #Update spreadsheet
173.

Code formatted for display using online tool: SyntaxHighlighter (Beach, 2011)

69
 APPENDIX J - SUSPENSION VELOCITY AND

ACCELERATION GRAPHS

Test 1

Figure 33: Suspension Velocity versus Time - Minimum Damping

70
Test 2

Figure 34: Suspension Velocity versus Time – Medium Damping

71
Test 2

Figure 35: Suspension Velocity versus Time – Maximum Damping

72