Group H Final Report

Low Cost Remote Data Acquisition and
Interface Solution for Amateur
Motorsports
19520 CES GROUP PROJECT
FINAL REPORT
GROUP H
Lauren Stewart
200905754
Matthew Bowen
200949172
Amarjeet Singh
200912701
Daniel Chakraverty
200906954
APRIL 2014

19250 CES GROUP PROJECT – FINAL REPORT
GROUP H
Page 2 of 129
ABSTRACT
The University of Strathclyde Motorsport team is made up of a group of students who
compete at an international level every summer against teams from across the world.
The challenge is to design, build and test a single seat race car.
This project has developed a distributed CAN based data acquisition system for the team,
including real-time telemetry, logging, sensor interfaces and real-time video streaming.
All data is integrated within a web based software analysis system, where the data can
be processed quickly and easily. Data can be exported for use in other analysis packages.
The system has a modular design allowing it to meet different requirements, both
technical and financial.
DECLARATION
We hereby declare that this work has not been submitted for any other degree/course
at this University or any other institution and that, except where reference is made to
the work of other authors, the material presented is original and entirely the result of
our own work at the University of Strathclyde.

GROUP H
Page 3 of 129
ACKNOWLEDGEMENTS
We would like to thank Jamie Corr, Victor Lee and Chee Wah Chan for a well-designed
(and well documented) Smart Dash project to build upon.
The University of Strathclyde Motorsport team have been very supportive through loans
of equipment and workspace during development - Jamie Sleigh and Stuart Halkett have
been especially helpful.
We would also like to thank Susan Scurlock for setting up a video call with Richard
Marshall, Chief Electronics Engineer, and Paul Howard, Race Team Mechanic, at Lotus
F1 Team. We would like to thank them for their feedback on our design and helpful
suggestions.
The electronics department at Red Bull Racing have also offered advice and feedback,
and we would like to extend our thanks to them.
The EEE workshop have been incredibly helpful throughout the project - ordering
components, manufacturing PCBs and offering practical advice. We would also like to
thank the Mechanical workshop for drilling out enclosures, the Resource Centre for
doing an excellent job printing our posters and the EEE IT Support for setting up the
computers needed for the tradeshow.
We would like to thank Christos Tachtatzis for sharing his expertise and experience with
radio systems, and Gaetano Di-Caterina for his assistance with video interface solutions.
Finally, we would like to say thank you to Dr. David Harle for the financial support and
advice.

GROUP H
Page 4 of 129
ACRONYMS AND DEFINITIONS
Acronym Definition
ADC Analogue to Digital Converter
API Application Programming Interface
ASCII American Standard Code for Information Interchange
CAN Controller Area Network
CCD Charged Coupled Device
CMOS Complimentary Metal Oxide Semiconductor
CSS Cascading Style Sheet
CSV Comma-Separated Values
DAQ Data Acquisition
DB Database
ECU Engine Control Unit
FAT32 File Allocation Table
FPV First Person View
FS Formula Student
GPS Global Positioning System
HTML Hypertext Mark-up Language
I2C Inter Integrated Circuit
IP Internet Protocol
JSP JavaServer Page
JSON JavaScript Object Notation
MCU Microcontroller Unit
MVC Model View Controller
PCB Printed Circuit Board
POM Project Object Model

GROUP H
Page 5 of 129
RF Radio Frequency
SD Secure Digital
SPI Serial Peripheral Interface
SVN Subversion
TVL Television Lines
USB Universal Serial Bus
USM University of Strathclyde Motorsport
UART Universal Asynchronous Receiver/Transmitter

GROUP H
Page 6 of 129
TABLE OF CONTENTS
1 Introduction......................................................................................................................................... 11
2 Background Research...................................................................................................................... 13
Existing USM Systems ............................................................................................................ 13
The CAN Protocol..................................................................................................................... 15
Third Party Products.............................................................................................................. 15
2.3.1 Race Technology DL1 Data Logger.......................................................................... 15
2.3.2 Race Technology Analysis Software....................................................................... 16
2.3.3 DTASwin Software......................................................................................................... 17
State of the Art........................................................................................................................... 18
Previous Projects ..................................................................................................................... 19
2.5.1 Formula Student Smart Dash .................................................................................... 19
2.5.2 Telemetry System for Formula Student Race Car............................................. 21
3 Project Outline.................................................................................................................................... 24
Requirements ............................................................................................................................ 24
Objectives/Specification ....................................................................................................... 24
4 System Design and Implementation.......................................................................................... 28
On-board Network................................................................................................................... 30
4.1.1 Protocol Choice................................................................................................................ 30
4.1.2 System Architecture...................................................................................................... 31
4.1.3 Microcontroller Choice................................................................................................. 32
4.1.4 Power Supply................................................................................................................... 34
4.1.5 Packaging........................................................................................................................... 34
Standard and Extension Nodes .......................................................................................... 36
4.2.1 GPS........................................................................................................................................ 36
4.2.2 Accelerometer.................................................................................................................. 37
4.2.3 Analogue Voltages.......................................................................................................... 37
4.2.4 Software Design.............................................................................................................. 38
Telemetry Node........................................................................................................................ 39
4.3.1 Radio Link.......................................................................................................................... 39
4.3.2 Hardware Design............................................................................................................ 40
4.3.3 Software Design.............................................................................................................. 40
Logger Node............................................................................................................................... 40

GROUP H
Page 7 of 129
4.4.1 Hardware Design............................................................................................................ 41
4.4.2 Software Design.............................................................................................................. 41
Video Hardware........................................................................................................................ 41
4.5.1 Camera................................................................................................................................ 41
4.5.2 Transmitter and Receiver........................................................................................... 42
4.5.3 Analogue to Digital Converter................................................................................... 45
4.5.4 Display ................................................................................................................................ 45
Off-board Software System.................................................................................................. 46
4.6.1 Architecture of the System......................................................................................... 46
4.6.2 Storing Data...................................................................................................................... 49
4.6.3 Receiving Data and Video............................................................................................ 51
4.6.4 Viewing Data and Video............................................................................................... 55
Business Considerations....................................................................................................... 57
4.7.1 Cost for Prototype.......................................................................................................... 57
4.7.2 Packages and Services.................................................................................................. 58
4.7.3 Customers.......................................................................................................................... 59
4.7.4 Trademarking .................................................................................................................. 59
4.7.5 Patents ................................................................................................................................ 60
5 Testing Strategy.................................................................................................................................. 61
Test Cases.................................................................................................................................... 61
5.1.1 On-Car Network Testing.............................................................................................. 61
5.1.2 Standard Node Testing................................................................................................. 62
5.1.3 Extension Node Testing............................................................................................... 63
5.1.4 Telemetry Node Testing.............................................................................................. 64
5.1.5 Logger Node Testing..................................................................................................... 66
5.1.6 Video Systems Testing.................................................................................................. 67
5.1.7 Off-Board Software Testing........................................................................................ 69
6 Project Management......................................................................................................................... 79
Project Plan Review ................................................................................................................ 79
6.1.1 Standard and Extension Node................................................................................... 79
6.1.2 Telemetry and Logger Node ...................................................................................... 79
6.1.3 Video System.................................................................................................................... 79
6.1.4 Off-Board Software System........................................................................................ 79

GROUP H
Page 8 of 129
6.1.5 Integration......................................................................................................................... 80
Risks Review.............................................................................................................................. 80
7 Future Work......................................................................................................................................... 81
On-Car Network........................................................................................................................ 81
Standard and Extension Nodes .......................................................................................... 81
Telemetry Node........................................................................................................................ 81
Logger Node............................................................................................................................... 82
Video Systems............................................................................................................................ 82
Off-Board Software System.................................................................................................. 82
7.6.1 Lap Parsing........................................................................................................................ 82
7.6.2 Two-Way Communication with Car ....................................................................... 83
7.6.3 User Control of Real-Time Sensors......................................................................... 83
7.6.4 Graph Styles...................................................................................................................... 83
7.6.5 Database Structure ........................................................................................................ 83
8 Conclusion ............................................................................................................................................ 84
9 References ............................................................................................................................................ 85
10 Appendices ...................................................................................................................................... 88
Technical Risks.......................................................................................................................... 88
Cost of System ........................................................................................................................... 89
User and Developer Guides.................................................................................................. 96
TABLE OF FIGURES
Figure 1 - USM13, University of Strathclyde Motorsport's 2013 car..................................... 11
Figure 2 - USM's current sensor setup, and logging systems.................................................... 13
Figure 3 - A GoPro video camera being used to monitor chain slack. ................................... 14
Figure 4 - A screenshot from a GoPro, monitoring air flow over a front wing. ................. 14
Figure 5 - Race Technology DL1 Logger [1]..................................................................................... 16
Figure 6 - Race Technology Analysis Software............................................................................... 17
Figure 7 - DTASwin Software................................................................................................................. 17
Figure 8 - The Ferrari F1 team monitoring the incoming data stream from the car [9].18
Figure 9 - Formula 1 regulated data acquisition system [10]................................................... 18
Figure 10 - Smart Dash Hardware Components [11]................................................................... 20

GROUP H
Page 9 of 129
Figure 11 - Smart Dash [11].................................................................................................................... 20
Figure 12 - On-board System [12]........................................................................................................ 21
Figure 13 - LabView ECU Summary GUI [12] .................................................................................. 22
Figure 14 - LabView ECU Data Log Graph GUI [12] ...................................................................... 22
Figure 15 - Overall System Architecture............................................................................................ 28
Figure 16 - System State Diagram ........................................................................................................ 29
Figure 17 - Extract from ECU Manual showing CAN stream [14] ........................................... 30
Figure 18 - Front and Rear CAN Nodes Architecture ................................................................... 31
Figure 19 - MCP2561 Wiring [21]........................................................................................................ 33
Figure 20 - Standard Node PCB Design.............................................................................................. 35
Figure 21 - Standard Node (top) and Extension Node (bottom) PCBs ................................. 35
Figure 22 - Enclosure................................................................................................................................. 35
Figure 23- Venus 638FLPX Breakout Board by Sparkfun [24] ................................................ 37
Figure 24 - MMA8542Q multiple byte read feature [26]............................................................ 39
Figure 25 - A comparison of lens size and the associated angle of view [35].................... 42
Figure 26 - Linear Polarisation vs. Circular Polarisation............................................................ 44
Figure 27 - Multipath interference....................................................................................................... 44
Figure 28 - Circular Polarised Antennas [39].................................................................................. 44
Figure 29 – System Architecture........................................................................................................... 47
Figure 30 - Parsing Bytes......................................................................................................................... 52
Figure 31 - Real-Time Data...................................................................................................................... 53
Figure 32 - GPS Plotted on Google Maps............................................................................................ 56
Figure 33 - Athenatec Logo ..................................................................................................................... 60
Figure 33 - Gantt chart summary.......................................................................................................... 79
Figure 34 - Summary of Costs ................................................................................................................ 89
Figure 35 - Standard Node Costs .......................................................................................................... 90
Figure 36 - Extension Node Costs......................................................................................................... 91
Figure 37 - Logger Node Costs............................................................................................................... 92
Figure 38 - Telemetry Node Costs........................................................................................................ 93
Figure 39 - Video Systems Costs ........................................................................................................... 94
Figure 40 - Calculating Package Costs ................................................................................................ 95

GROUP H
Page 10 of 129
TABLE OF EQUATIONS
Equation 1 – Transfer Function............................................................................................................. 50
TABLE OF TABLES
Table 1 - Specification for McLaren Electronic Systems F1 DAQ & ECU Systems [10]... 19
Table 2 - Project Objectives..................................................................................................................... 25
Table 3 - Processing Architecture Comparison .............................................................................. 32
Table 4 - Summary of Costs..................................................................................................................... 57
Table 5 - Product Selling Prices............................................................................................................. 58
Table 6 - Services Offered........................................................................................................................ 59
Table 7 - Technical Risks.......................................................................................................................... 88

GROUP H
Page 11 of 129
1 INTRODUCTION
Formula Student is an international design competition challenging students at
university to design, build and manufacture a single seat race-car. The University of
Strathclyde Motorsport (USM) team competes against other universities from across the
world every summer at Silverstone, UK and Hockenheim, Germany. The team’s 13th car,
USM13, is shown in Figure 1. It is important that all design decisions throughout the
season are data driven, and justified through suitable analysis and testing. There is a
need for data acquisition while running the car to allow the team to compare simulated
values with real-life results. This allows them to validate their designs and improve the
car where possible. The high performance nature of a racing car often means that
components are operating at the limits of their design, requiring values to be monitored
in real-time to keep them within safe limits.
Figure 1 - USM13, University of Strathclyde Motorsport's 2013 car
Concerns have been raised by USM that there are three different places that data is
logged on the car, all with differing software packages to access and analyse the
information. This makes it difficult to compare values that have been recorded on
different systems. Team members are also unable to invest the time required to learn
the different software packages. The current system requires an engineer to start the
logging on all the systems before a run which is time consuming and is therefore often
not done, resulting in the car running without data being logged.
Traditionally critical values (such as oil/water temperature) have been displayed to the
driver on the dashboard, alongside RPM lights and current gear. However most Formula
Student tracks are very tight and test the driver’s skill and concentration. Consequently
the driver does not have time to accurately assess these values while also driving to the
best of their ability. If the critical values could be monitored in real-time by other
members of the team at the side of the track the driver could be warned and they could
take appropriate action, without them having to constantly check the warning lights.
This project developed a system that integrated all sensor data onto an on-car embedded
network, making data accessible for analysis – even if the data originated from different
control or sensing systems. Software has been developed that allows team members to
carry out analysis quickly and easily, improving access to the data, while also allowing
data to be exported to more powerful analysis packages when required.

GROUP H
Page 12 of 129
Wireless telemetry has also been developed that allows engineers at the side of the track
to monitor and view critical sensor values and trends on the car. The driver can
therefore concentrate on driving to the best of their ability. Video systems have been
used to assist in driver training and to allow monitoring the behavior of components that
could be difficult to sense through traditional systems – such as rear wing flex, or air
flow.

GROUP H
Page 13 of 129
2 BACKGROUND RESEARCH
This section contains information about the current systems that USM use, studies of
competitors to the proposed product, state of the art systems as used in Formula One,
and summaries of related projects that have been carried out in the past.
EXISTING USM SYSTEMS
Two members of the project team are involved with the USM team, and have
accompanied them to one of their test sessions in order to understand fully how the
current systems are being used. This was essential information to allow the project to
deliver appropriate solutions.
The current team uses a DTA S80 Pro [1] Engine Control Unit (ECU) to sense and control
engine parameters such as oil and water temperature, a Race Technology DL1 MK1 [2]
Data Acquisition Unit (DAQ) to log analysis parameters such as suspension travel,
steering angle and brake temperatures, and a smartphone to display some of these
parameters to the driver.
Figure 2 - USM's current sensor setup, and logging systems.
The ECU outputs various data parameters about the engine onto a Controller Area
Network (CAN) bus which currently drives a smartphone to give dashboard indications
of these parameters to the driver. This has meant that all data on the CAN bus is not
available to the DAQ to log. Some CAN data logging functionality is available on a

GROUP H
Page 14 of 129
smartphone; however this is limited and not easy to access. Data is also logged internally
on the ECU, but again this requires specialist software to access.
It can be seen from the diagram in Figure 2 that data acquired from sensors attached to
the ECU is not available to the DAQ systems, preventing comparisons such as throttle
position against suspension pot readings. USM have purchased a CAN adapter for the
DAQ to allow logging of engine data but they have not been able to make it function
correctly. However this would not be a permanent solution as the current DAQ (Race
Technology DL1) is not expandable past seven analogue inputs, therefore the team
cannot run all of the DAQ sensors shown in Figure 2 simultaneously during a test session.
Figure 3 - A GoPro video camera being used to monitor chain slack.
Finally, it is difficult for team members outside of the electronics team to understand
which sensors are logged on which subsystem and therefore the data that has been
logged is not utilised to make informed design decisions. An example of this was when
tuning the engine on the dynamometer, the Head of Engine Systems required to know
what throttle percentage to tune the engine to (as this improves performance when on
track). It was suggested to look at the data from the race in the previous year to find this
out, so he loaded up the data from the DAQ. He then realised that the data for throttle
position is actually stored on the ECU, so that data had to be loaded up, exported, and
then imported into Microsoft Excel, which is a long process.
Figure 4 - A screenshot from a GoPro, monitoring air flow over a front wing.

GROUP H
Page 15 of 129
GoPro [3] cameras are also used to monitor components on the car as seen in Figure 3
when monitoring chain slack, or in Figure 4 when monitoring air flow over wings. The
most recent version of the GoPro range, the Hero3, has WiFi built in. This makes it
possible to monitor the video feed in real-time on a compatible smartphone. However it
was observed that a delay of 1-2 seconds is present when the team use this feature.
It is difficult to find information on other teams, as they generally do not publish details
of their systems in order to maintain any competitive advantage.
Further research was carried out into CAN in order to fully understand the
implementation required.
THE CAN PROTOCOL
The Controller Area Network (CAN) protocol was developed by Bosch in the 1980s in
order to establish reliable serial communications inautomotive applications. Data is sent
as a voltage difference between two wires (CAN high and CAN low), rather than as zero
volts and high volts as with other protocols. Most electrical noise will affect both wires
in the same way, so the voltage difference will stay constant. This results in a much more
resilient and reliable system.
The CAN protocol implements the lower two levels in the ISO/OSI reference model; the
Data Link and Physical layer. This leaves the system developer the flexibility to
implement the upper levels of the OSI reference in order to standardize start-up
procedures or determine the structure of the actual messages [4]. The protocol is
message based, meaning that all messages are sent over the whole network with the
receiver deciding if it should use the message. The alternative, an address based
network, would send packets to particular devices on the network based on an internal
address in the packet.
CAN is Carrier Sense Multiple Access/Collision Detection (CSMA/CD), operating in a
similar manner to Ethernet. Every node on the CAN bus monitors activity on the bus for
a period of no activity before sending. Once this period is detected, every node has the
same opportunity to transmit, giving it ‘Multiple Access’. If two nodes transmit at the
same time, a collision is detected. In CAN this is non-destructive, so the higher priority
message will be transmitted without delay. This requires the message identifiers in the
CAN messages to be set with appropriate priorities (lower being better). In this
application, very few data values will be higher priority than the ECU data.
THIRD PARTY PRODUCTS
This section will discuss the products that the USM team currently use as well as
discussing other existing products available on the market.
2.3.1 Race Technology DL1 Data Logger
This is the data logger that is currently used by the USM team. It is a small, highly robust
data logging system with a powerful software system for analysis (described in Section
2.3.2).

GROUP H
Page 16 of 129
The DL1 is a small data logger that can store data from a number of sources, including
internal accelerometers, high accuracy GPS and eight analogue inputs. In addition there
are inputs for frequency measurements (such as wheel speed sensors) and a serial data
input for information sent from the vehicle's ECU, such as RPM, throttle position and
engine temperatures (however this requires the additional cost of an adapter to convert
CAN protocol data to a proprietary serial format to be used with USM’s DTA ECU) [5].
The logger can be seen in Figure 5.
Figure 5 - Race Technology DL1 Logger [1]
The data is logged to a CompactFlash card inserted into the logger, which is then used to
transfer data to a PC via a standard card reader. There is no option for real-time
monitoring of the data that has been logged, other than a dash system that can be
connected to the device for additional cost. This dash system receives data over a serial
port, but again the protocol is proprietary which stops different systems from accessing
this data.
The logger is extremely robust, with all electrical connections being vibration proof and
high strength, housed in a tough metal enclosure. The DL1 combines GPS and
accelerometer data to accurately map tracks, with their experiments showing that the
results are much more accurate than other GPS systems [6]. The DL1 logger costs £511.
2.3.2 Race Technology Analysis Software
This is the software package currently used by the USM team for most of their analysis.
After a race, the software receives the data either from a serial (RS232) link running at
high speed or the data is read from a CompactFlash card. The software converts the raw
data into useful information and then the software can be used for analysis. Simple
graphs can be plotted or more powerful analysis features can be used [7].
The Race Technology Data Analysis software package has many desirable features.
Theoretical lap times can be calculated as well as simple lap and sector times. Also,
multiple runs and laps can be analysed which allows for comparison between races and
drivers. The software includes a feature to import video to be viewed alongside the
logged data. It also includes a fully featured standard and HD video export system with
optional overlaid graphics. The interface is drag and drop and there is an optional black
background on graphs for improved trackside visibility in bright sunlight. Virtual
dashboards make a great user experience and real-time playback is very useful when
analysing all the data. To improve the user experience even further, the user can define
and select variables and define graphs. Finally, the software allows the data to be saved,
printed and exported to a spreadsheet or Matlab [7].

GROUP H
Page 17 of 129
Figure 6 shows the track mapping and graph displays. It also shows how different laps
can be analysed and compared against each other by overlaying the data on one graph.
The software is free to download but can only be used with the data from the DL1 logger
discussed in Section 2.3.1.
Figure 6 - Race Technology Analysis Software
2.3.3 DTASwin Software
DTASwin is the control software that is used for the S series of the ECU that the USM
team use in the car. It is used for configuring settings on the ECU such as engine maps,
launch control settings or sensor scaling. The USM team can also use this when
connected to the dynamometer (dyno) for tuning the engine. It displays real-time data
such as water temperature, oil temperature or oil pressure while directly connected to
the ECU.
Figure 7 - DTASwin Software

GROUP H
Page 18 of 129
Communication with a PC can be set up by using a CAN network with a suitable adapter
for the ECU or through a serial cable. An example screen within the software is shown in
Figure 7. It has a virtual dashboard that displays all of the parameters while tuning.
STATE OF THE ART
Research was carried out into the state of the art in data acquisition systems within
Formula 1. As seen in Figure 8, a huge amount of information is required while the car is
running in real-time in order to monitor the performance of the car. Additionally
terabytes of data are logged from the car for analysis at a later date [8].
Figure 8 - The Ferrari F1 team monitoring the incoming data stream from the car [9].
Every team is required by regulation to use the same electronic control system, which is
designed and manufactured by McLaren Electronic Systems [10]. The system has a star
topology as seen in Figure 9, with a central unit (TAG-310B) hosting the majority of
sensor inputs and all of the control systems on the car. Additional units (HIUs) are used
to add additional localised sensors to the system, for example within each wheel.
Figure 9 - Formula 1 regulated data acquisition system [10].

GROUP H
Page 19 of 129
These localised ‘hubs’ interface with the central control unit over a number of embedded
CAN buses allowing sensor data to be transferred over a single twisted pair wire, rather
than a single wire for every sensor. A similar approach is used in this project.
Table 1 - Specification for McLaren Electronic Systems F1 DAQ & ECU Systems [10]
TAG-310B TAG-320
Application processing power 955MIPS 4,000MIPS
Memory (RAM) 40MB 512MB
Memory protection Limited Full
Logged data capacity 1GB 8GB
CAN buses 6 11
Standard analogue input sampling rate capability 1kHz 10kHz
Fast analogue input sampling rate capability 10kHz 100kHz
Internal accelerometer None Tri-axis ±10g
Maximum number of logging channels 512 4,000
Ethernet link maximum speed 100Mbps 1Gbps
Table 1 shows the specifications for the central control unit, with the updated version,
the TAG-320, being developed to control the more complex turbocharged V6 engines
that were introduced in 2014. The technology used to achieve this specification is state
of the art, and is not inexpensive – with such a system costing tens of thousands of
pounds1.
PREVIOUS PROJECTS
This section discusses previous final year projects that have been carried out for the USM
team.
2.5.1 Formula Student Smart Dash
In the academic year 2012/2013, a final year project was carried out that designed,
implemented and tested a smart phone based driver feedback system for use in a
Formula Student race car. The project involved developing a CAN node on the car to
receive data from the ECU, transmitting the data via Bluetooth to the smart phone and
developing an app that would read the data, write to a database, display the values and
perform analysis on the collected data [11].
1 An exact cost is not publicly available, and Formula One teams do not publish cost breakdowns.

GROUP H
Page 20 of 129
For the CAN node, a PIC microcontroller was chosen. A CAN transceiver was required to
communicate with the CAN bus and a Bluetooth module was incorporated to send data
to the smart phone. The hardware architecture can be seen in Figure 10.
Figure 10 - Smart Dash Hardware Components [11]
An Android app was chosen to be developed due to the free development and easy IDE
available. The app featured two modes – a Driver Mode and an Analysis Mode. The Driver
Mode displayed data to the driver and alerted the driver when the measured data went
out of operating bounds. The Analysis Mode was used to analyse the driver’s
performance after the race and displayed a track map showing the data at each point
around the track [11]. The app can be seen running in Figure 11. This also shows the
custom designed enclosure for the smart phone.
Figure 11 - Smart Dash [11]
This project was a success, with all major objectives being met. The project developed a
small CAN network on the car and documented technical manuals on how the system
works, which can be used to further enhance and improve the network by future teams.
The USM team have said many positive things about the project and are currently using
the smart dash in the Formula Student car.
Two members of the project were involved with USM while the Smart Dash project was
being developed. The CAN development carried out as part of the Smart Dash project
was therefore used as a base to develop the system described in this report.

GROUP H
Page 21 of 129
2.5.2 Telemetry System for Formula Student Race Car
In the academic year 2011/2012, a final year project was carried out that involved the
design and development of a wireless telemetry system suitable for the USM team. It
comprised of two main subsystems – an on-board system that extracted the
measurement data from the car and an off-board system that received the data and
displayed them to the pit engineers. The two subsystems were connected via a wireless
communication link [12].
Figure 12 - On-board System [12]
The on-board system was implemented using an Arduino UNO with an XBee Pro
Transceiver to transmit the data. Also included in the on-board system was an OpenLog
Data Logger with a 2 GB SD card to serve as a backup should communications fail [12].
Figure 12 shows the final PCB for the on-board system.
The off-board system used an Arduino UNO to receive the data and a GUI was designed
within LabView to view the data. Figure 13 and Figure 14 show some screenshots of the
GUI.

GROUP H
Page 22 of 129
Figure 13 - LabView ECU Summary GUI [12]
Although the majority of the objectives were met with this project, there were many
problems. Firstly, the XBees used for the wireless transmission only achieved a
transmission distance of about 200 m when tested on a car. Another problem was that
the sampling frequency was not high enough and so a more powerful microcontroller
could have been used. The power supply used for the on-board system was AA batteries
which is not very practical. Rechargeable batteries, or the car’s power supply, would
have been a more cost-efficient solution.
Figure 14 - LabView ECU Data Log Graph GUI [12]
Another problem with this project is the off-board system. The team used LabView to
display their data in a GUI that they designed. This GUI is not customisable and users are
required to graphically program the interface in order to add an interpretation for any
additional sensors. Therefore if the user is not skilled with LabView, they will not be able
to extend this program for future use.

GROUP H
Page 23 of 129
USM have said that the system did not work correctly all the time and that the GUI used
did not display the data the way that was required. As such, this system is not currently
used by the USM team.

GROUP H
Page 24 of 129
3 PROJECT OUTLINE
This section discusses the requirements that were communicated from the USM team,
and then shows the project specification to meet those requirements.
REQUIREMENTS
Meetings were held with USM early in the project in order to understand their current
systems, and requirements. The main problems, discussed in more detail in Section 2.1,
that were found with the current systems are as follows:
1. Lack of expandability to add more sensors to logging systems (limited to seven).
2. Engine related sensors are logged on separate systems to other sensors, often
preventing comparisons between sensors.
3. Multiple powerful and complex software packages have to be used for different
sets of data, preventing the team members from carrying out simple analysis
quickly between test runs.
4. Data is not available in the pits in real-time, leaving the driver to monitor critical
values.
There is a real need to improve the data acquisition systems for the USM Formula
Student team, and it is suggested that other Formula Student teams and amateur racers
have similar problems.
OBJECTIVES/SPECIFICATION
It is proposed to integrate all the data logging functionality on the car into one system,
where all data is available everywhere. For example it would be possible to display RPM
and gear position against GPS data, something that is not possible with the current
system. This would be done by developing an on-board embedded network that all
devices on the car communicate through. Sensor ‘nodes’ will be developed to directly
convert analogue voltages to the network protocol, reducing the amount of wiring on the
car (currently individual cables are run for every single sensor). This would also make
the data acquisition set up a lot more flexible, allowing sensors to be added and removed
as required.
In addition, it is proposed to develop a communication link between the on-board
network and an off-board software system, allowing the sensed data to be monitored in
real-time by the pit crew. The off-board system would allow team members to analyse
the gathered data in a manner that is easy to use by an untrained engineer while also
allowing data to be exported to more complex software packages to be used for more in
depth analysis.
Finally, video systems are to be integrated into the project, enabling team members to
see external factors that cause fluctuations in recorded telemetry. An example of this
would be a driver taking a slightly different racing line in a corner. This could also be
used to assist in driver training and gain significant improvements in overall lap times.
The system is to be modular in design, allowing for it to be integrated into any other
racing car in amateur racing series. The end product will also be lower in cost and more

GROUP H
Page 25 of 129
flexible than other racing data acquisition/telemetry/video analysis systems, making it
more affordable and accessible to amateur racers.
Table 2 shows a summary of the high level objectives of the project, with an importance
assigned to each in order to set scope for the work done Responsibilities were assigned
as shown.
Table 2 - Project Objectives
# Objective Importance Responsible
1 Literature review into automotive network
architectures and protocols.
Major Daniel
2 Develop a network to allow all data acquisition
components on the car to communicate and share data.
Major Daniel
3 Develop nodes to interface sensors on the car with the
on-board network.
Minor Daniel
4 Literature review into on-board to off-board wireless
communication technologies.
Major Matthew
5 Design, implement and test a wireless channel for
communication.
Major Matthew
6 Development of nodes to interface on-board network
and off-board systems.
Major Matthew
7 Development of on-board data logger. Optional Matthew
8 Literature review into current video solutions. Major Amarjeet
9 Integration of video into off-board software system, to
view alongside the acquired data.
Major Amarjeet
10 Implementation of wireless transmission of video
stream(s).
Optional Amarjeet
11 Literature review into existing analysis systems. Major Lauren
12 Development of software and/or integration of 3rd
party software package(s).
Major Lauren
13 Design the off-board system to be user configurable. Minor Lauren
14 Include real-time displays for incoming data from on-
board systems.
Optional Lauren
15 Package the solution as a marketable product for
potential customers.
Optional All

GROUP H
Page 26 of 129
A detailed explanation of the objectives and scope for the project follows.
OBJ-1 Literature review into automotive network architectures and
protocols.
Research is to be carried out into CAN and alternative network
architectures that are available. This will allow appropriate decisions to
be made as to which protocol to use on the car and which is the best
solution for amateur race teams.
OBJ-2 Develop a network to allow all data acquisition components on the
car to communicate and share data.
The chosen network architecture will be implemented and tested,
integrating ECU data with DAQ sensors. This includes both transmit and
receive functions (to be integrated with telemetry and logging systems
as required).
OBJ-3 Develop nodes to interface sensors on the car with the on-board
network.
The developed nodes will convert analogue voltages from sensors into
appropriate data formats for the on-board network. The data will be
labelled as required by the off-board system for identification of
individual sensors.
OBJ-4 Literature review into on-board to off-board wireless
communication technologies.
Research will be carried out into technologies and products available for
wireless communication. This will facilitate the choice of hardware for
the system.
OBJ-5 Design, implement and test a wireless channel for communication.
The chosen wireless channel will be tested under various different
realistic conditions in order to get an idea of the limitations and whether
this will influence the design further.
OBJ-6 Development of nodes to interface on-board network and off-board
systems.
The nodes on either end of the wireless channel will be developed in
order to integrate the system with the data formats provided and
required by the on-board and off-board systems.
OBJ-7 Development of on-board data logger.
An on-board data logger will be developed to store all data on the on-
board network.
OBJ-8 Literature review into current video solutions.
Research will be carried out into wireless video transmission products
that are currently available on the market.

GROUP H
Page 27 of 129
OBJ-9 Integration of video into off-board software system, to view
alongside the acquired data.
This objective includes converting the received video into an appropriate
format allowing it to be embedded within the analysis software.
OBJ-9 Implementation of wireless transmission of video stream(s).
This will include development of a wireless transmitter and receiver to
facilitate off-board viewing of video in real-time.
OBJ-10 Literature review into existing analysis systems.
This will give insight into the types of data that are processed, how the
data is displayed, what analysis can be done on that data etc. and this
knowledge will feed into the design of the software.
OBJ-11 Development of software and/or integration of 3rd party software
package(s).
This involves creating an application that will display the data from the
car in an efficient manner (such as graphs or tables) and that is easy to
use. This application could be entirely developed by the project team or
could involve an aspect of 3rd party software.
OBJ-12 Design the off-board system to be user configurable.
The analysis software should be simple and easy to use. Therefore, if the
user can configure the software to their needs it will enhance their
experience.
OBJ-13 Include real-time displays for incoming data from on-board
systems.
If data can be transmitted wirelessly then viewing the data real-time
would be a significant improvement on the current system.

GROUP H
Page 28 of 129
4 SYSTEM DESIGN AND IMPLEMENTATION
The design has taken the USM Formula Student cars as a prototype and will be integrated
into existing systems where possible. The system has been designed to be modular,
allowing flexibility when packaging solutions for differing types of race teams, for
example real-time displays may not be required by some customers.
The general system architecture is detailed in Figure 15. An on-board network
aggregates all ECU and DAQ data onto the same system (differing from the current
system). DAQ sensors will be input into ‘nodes’, which will interface with the analysis
software. Also connected to the network is a telemetry ‘node’ which transmits the data
to the off-board systems. A logging ‘node’ is included to store the data on the car.
The advantage of using an integrated system means that all data is available everywhere;
the same data can be displayed on the dash as is available on the analysis systems. This
makes the system much more flexible and easily expandable if extra systems are added
in the future, such as active aero or suspension. The new system simply needs to be
connected to the on-board network to access all the data it requires.
Figure 15 - Overall System Architecture
Video systems use a separate set of radios, with the camera being able to be mounted
anywhere on the car to allow different variables to be analysed.
ON-BOARD OFF-BOARD
ECU
Engine Sensors
DAQ Sensors
Logger
Telemetry
EmbeddedNetwork
Analysis and
Display
Camera
Transmitter
Receiver
Receiver

GROUP H
Page 29 of 129
The off-board software system will allow simple analysis to be carried out quickly by
relatively untrained users (compared to the training required for the current systems)
and also allow real-time values to be displayed. The integrated system means that data
from the ECU can be compared with data from DAQ sensors, something that is not
currently possible.
Through consultation with USM, three main states of running the car were identified.
‘Pre-Run’ is when the car is being set up and is the period in which data acquisition
systems are set up, alongside other systems on the car. When the car is ‘Ready to Run’,
the engine is ready to be started and the car will start a session. This is when the data
acquisition systems should be ready to start logging. ‘Running’ is when the car is on
track and logging systems should be active. This is where real-time displays and video
would be useful to the team for monitoring the health of the car and driver behaviours.
‘End of Run’ is when the car comes back into the pits; logging should be stopped and data
stored for future analysis.
The actions to be carried out within each system state are shown in Figure 16.
Figure 16 - System State Diagram
The final design has been split into four subsystems:
1. On-Board Network and Sensor Interfaces
This system includes all on-car network development, interfacing with the ECU and data
acquisition sensors (OBJ-1 to OBJ-3).
2. Telemetry/Logging Systems
1. Pre-Run
• DAQ and telemetry systems set up.
• Video systems set up and mounted on car.
• Off-board software started up.
2. Ready to Run
• CAN nodes sending data.
• Wireless connections established (video shown).
• Logging can be started through switch on car.
3. Running
• Log all data on internal SD card.
• Send real-time values to server.
• Save incoming video on off-board systems and display real-time.
4. End of Run
• Stop logging through button on dash.
• Transfer all data from SD card by removing SD card and
uploading to server.
• Save all data on off-board systems.
• Display simple analysis and export options in software.

GROUP H
Page 30 of 129
This includes all wireless communication development for data transmission from the
car to off-board software (OBJ-4 to OBJ-7). All on-board logging also comes under this
subsystem.
3. Video Systems
All video systems development, testing and integration into the off-board software will
be carried out as part of this subsystem (OBJ-8 to OBJ-10).
4. Off-Board Software System
Analysis software, real-time displays and data storage will be developed as part of this
subsystem (OBJ-11 to OBJ-14).
Each subsystem design is discussed in further detail in the following sections.
ON-BOARD NETWORK
The main design decisions made for development of the on-board network are discussed
in this section, along with implementation details.
4.1.1 Protocol Choice
The main design decision that had to be made for the on-board network was the protocol
to use. The team’s ECU [13] has the option to use RS232 or CAN, with more variables
output over the latter. The CAN stream that is output from the ECU is shown in Figure
17, extracted from the manual [14].
Figure 17 - Extract from ECU Manual showing CAN stream [14]
As can be seen a huge amount of information is available from this source, and as of 2013
it is used to drive USM’s dashboard to allow the driver to monitor essential variables. In
addition RS232 is a unicast protocol and therefore can only be used to transmit to one
device at a time. The CAN protocol is a broadcast system and is much better suited to
this problem, where communications across multiple devices is required. The CAN
protocol is discussed in more detail in Section 2.2.
Other embedded network protocols are available, such as TTEthernet [15]. However as
CAN currently is an industry standard, with most high end ECUs including at least one
CAN controller, the decision was made to use the CAN protocol as the embedded network
for this project. This will allow the developed system to be integrated into existing
systems that USM and other teams use [16], rather than implementing a new system that
replaces existing functionality – something that this project aims to avoid.

GROUP H
Page 31 of 129
Many lower end ECUs do not include a CAN interface as standard and only offer a RS232
interface for programming and basic data stream outputs [17]. However the advantages
of using CAN (all data available everywhere) would warrant implementing an RS232 to
CAN converter for such devices. Many of the ECU manufacturers offer such a converter
for additional cost. As the DTA S80 Pro is at the lower end of the high end ECUs on offer,
and is used throughout the amateur racing scene, using CAN seems to be an appropriate
choice, given that teams who don’t use the higher end ECUs won’t be so interested in in-
depth analysis and tuning of the car.
4.1.2 System Architecture
There are two main options for the main system architecture – individual CAN nodes for
each sensor or larger nodes with multiple sensors attached to them as seen in Figure 18.
As can be seen in Figure 2 the sheer number of sensors means the first option is not
practical, as suitable mounting locations would need to be found for each sensor node
along with the additional weight associated with the enclosures. For this to be practical,
each sensor node would need to be extremely small, resulting in additional development
costs and complexity.
Figure 18 - Front and Rear CAN Nodes Architecture
The decision was made to go with the second option, where the raw analogue voltages
are sent from each node to the data logger/telemetry, with the off-board system
providing calibration functionality. The advantage of this is that each car setup can be
saved easily on the higher power system, rather than adding complexity across the
whole system to achieve calibration functionality.
The second option, shown in Figure 18, has two larger nodes, with multiple sensors
attached to each one. This is a compromise between reduced weight from the wiring and
the additional weight from each enclosure. The design is still expandable, so if more
sensor inputs are required an additional node can be added. It will also facilitate easier
design, manufacture and integration than with the first option. Finally, most
ECU
TELEMETRY
DASH
CAN Bus FRONT
NODE
REAR
NODE

GROUP H
Page 32 of 129
microcontrollers include multiple channel analogue to digital converters (ADCs),
therefore the larger nodes will result in higher utilisation of hardware, reducing costs
further.
When sending data, again two options were discussed. The first was to send the real
values of sensors (in degrees, Newtons or displacement centimetres for example), and
the second was to send the raw voltage of the sensors and calibrate in the off-board
software.
The advantage of the first option is that the sensor calibration has been done before it is
sent onto the network, therefore any device on the network can read the actual value
and act on it appropriately (useful for dash displays). The disadvantage of this is that the
calibration values have to be sent in some way to each CAN node, either through CAN
itself (adding complexity in how these calibration values are stored in non-volatile
memory) or re-flashing each chip (which reduces ease of use). The decision was made
to calibrate sensor values in the off-board software.
4.1.3 Microcontroller Choice
Four main processing architectures were considered for the implementation of the on-
board network: Arduino (Atmel), PIC (Microchip), Atmel, and Texas Instruments AT
series. Most of the architectures researched offered CAN libraries to facilitate fast
development, rather than having to implement the CAN protocol from scratch. Table 3
shows the advantages and disadvantages for each architecture.
Table 3 - Processing Architecture Comparison
Arduino PIC Atmel Texas Instruments
+ Group very
experienced.
+ Some experience. - No experience (other
than Arduinos).
- No experience.
+ Large online
community.
+ Previous projects
have used CAN on
these devices.
+ Devices available that
match project
requirements.
+ Devices available that
match project
requirements.
- None with native CAN
controllers (other than
Arduino DUE).
+ Through-hole
packages available.
- Surface mount only. - Surface mount only.
+ No external
development
systems/debuggers
required.
+ Debugger already
owned by USM.
- Requires purchase of
debugger to load code.
- Requires purchase of
debugger to load code.
- High power
requirements due to
additional hardware.
- Reputation for being
difficult to develop for
[18].
+ Lower power
requirements [18].
The Atmel and Texas Instruments architectures were ruled out due to no through-hole
packages being available, which makes it difficult to prototype and manufacture with the
facilities available at the university. The PIC family of microcontrollers (MCUs) offer
through-hole packaging, with some experience within the group of using the

GROUP H
Page 33 of 129
development environment and debugger (which is already available for use from the
USM team). The group is very experienced with Arduino microcontrollers, but due to the
large size and high power requirements they are not suitable for this project. Therefore
the PIC family of microcontrollers was investigated in further detail.
The microcontroller used for the Smart Dash project in 2013, the PIC18F4580, was
deemed inappropriate due to physical dimensions and the number of digital I/O pins
which were not required for this project. However personal experience using and
tweaking the system led to the conclusion that this was a suitable device family to use,
with CAN libraries available from microC [19] for communication with the inbuilt CAN
controller. The Microchip C18 compiler also offers a CAN library that supports the
inbuilt CAN controller.
The decision was made early on to use the same microcontroller across the project to
aid ease-of-development. This is suitable due to the low costs of the PIC (less than £5).
The architecture decision was also influenced by the other peripheral interfaces
required. UART ports were required to communicate with GPS and radios, alongside i2c
for the accelerometer. An inbuilt ADC was also required.
The device chosen was the PIC18F25K80, in a through-hole package. The specifications
match the requirements of the project, with eight 12 bit ADC channels, a CAN controller,
a SPI, and two UART channels. The package is also very small, at just over two and a half
centimetres in length, which will facilitate small packaging for the CAN nodes.
Experience from the Smart Dash project was drawn upon with it documented that the
internal oscillator on the PIC became unstable after longer periods of time. Therefore an
external 20 MHz oscillator was specified for each CAN node to offer stability. This value
was one of the highest supported as specified in the MCU’s datasheet.
A CAN transceiver is required to convert the CAN differential signals into transistor-
transistor logic (TTL) signals for the microcontroller. This chip protects against high-
voltage spikes in automotive environments, and acts as the interface between the CAN
controller built into the microcontroller and the physical two-wire CAN bus. The
recommended transceiver for the PIC18F25K80, the MCP2561 [20], was selected which
is to be wired as shown in Figure 19.
Figure 19 - MCP2561 Wiring [21]
Voltage Regulator
Microcontroller

GROUP H
Page 34 of 129
All circuit schematics for all the nodes are included in the accompanying CD. The basic
circuit to support the microcontroller (including external oscillator and in-circuit
programming header) along with the CAN transceiver to interface to CAN is the same
across all the nodes, with additional peripherals included to allow node-specific
functionality – such as GPS, radios or on-board flash storage.
An external 20 MHz oscillator is included between pins 8 and 9 on the microcontroller
with loading control capacitors. A 10 kΩ pull-up resistor is connected to MCLR (pin 10)
to keep the microcontroller out of reset, and a 330 Ω current limiting resistor is also
included to protect that input. A decoupling capacitor is included between power and
ground to reduce high frequency noise on the main power supply.
4.1.4 Power Supply
Voltage regulation will be required to offer stable power supplies to the hardware on
each CAN node, especially when the system is powered through the relatively unstable
power supply on the vehicle. Previous experience has shown that switched regulators
facilitate easy development and stable supplies. In addition they do not require large
heat sinks to dissipate the heat generated when stepping down from 12 V to 5 V as
required with linear voltage regulators. The current output was chosen to support 1.5 A,
so that the node is able to power itself alongside external sensors if required.
A small linear voltage regulator was also specified to step the 5 V supply down further
to 3.3 V for peripheral devices, such as radios, GPS and accelerometer. This is a smaller
step down in voltage, and with less current output required, no large external heat
The Formula Student rules were consulted to ensure that power is allowed on the car
while the engine is switched off to keep data acquisition and cooling systems on. The
only time that the car has to be completely off is when the main kill switch is turned off.
This allows systems to be monitored as the engine cools down. This information was
communicated back to USM so they could incorporate this in the design of the electrics.
In addition, system power consumption estimations were calculated so that they could
be fed back to the team, allowing power systems to be sized appropriately. These
calculations indicated that the entire data acquisition system consumed around 2 W.
This is not significant compared to other devices used on the car. This analysis is
included in the accompanying CD.
4.1.5 Packaging
The automotive environment is not very forgiving towards electrical circuits, and as such
they require protection against many different elements. Printed circuit boards (PCBs)
were designed and manufactured by the EEE workshop to achieve high reliability in this
environment. PCB design was carried out in Designspark by RS, as project members had
experience in using this software, and the free version has no board size limitation. An
example of the PCB design is shown in Figure 20 for the standard node, and the
completed PCB is shown in Figure 21. A copper pour was connected to ground across
the whole PCB to improve oscillator stability and improve ease of manufacture.

GROUP H
Page 35 of 129
Figure 20 - Standard Node PCB Design
Figure 21 - Standard Node (top) and Extension Node (bottom) PCBs
Off the shelf enclosures were purchased to house the PCBs while on the car. These were
available in a blue aluminium, which was used across all the nodes to allow a cohesive
brand to be developed in conjunction with the logo and business considerations as
discussed in Section 4.7. An example of these enclosures is shown in Figure 22, this one
for the standard node.
Figure 22 - Enclosure

GROUP H
Page 36 of 129
Connectors were sourced to allow wires to be easily connected to the circuit by the user.
This was done by using a two part pin and socket connecter, with wires that screwed
into one section that is then inserted into the socket on the PCB. This is a neat solution
that is utilised by the Race Technology DL1, with experience showing that this works
well in the automotive environment.
STANDARD AND EXTENSION NODES
The standard node is a single node that includes a GPS module for location sensing, and
an accelerometer to sense the movement of the vehicle. Four of the eight channels are
utilized on the internal ADC. Four of the ADC channels are left unused in order to ease
the requirements on the microcontroller, alongside reducing the size of the enclosure.
The extension node is exactly the same architecturally as the standard node, without the
GPS and accelerometer modules. All eight channels on the ADC are utilised.
4.2.1 GPS
In order to log the car’s position on track, a GPS module is included. Most GPS chips
output a NMEA [22] sentence over a UART serial communication link, containing
position and current time. The Venus638FLPX offers 20 Hz updates (faster than most on
the market) [23] however it is only available in column grid array (CGA) surface mount
packaging which the university does not have the facilities to solder. A solution, albeit
more expensive and with a larger physical size, is to buy a breakout board with the same
GPS device pre-soldered onto it. Sparkfun offer a breakout board, with an SMA connector
for an external GPS antenna on-board, as seen in Figure 23.
This device runs at 3.3 V, whereas the chosen microcontroller operates at 5 V logic. A
logic level converter is therefore required to communicate with the serial port of the GPS
chip.
The module was configured with a custom firmware using the GPS Configurator
software that is supplied by the manufacturer [24]. This software is designed to connect
directly to the module through a USB port, so the module was connected to a serial port
on an Arduino Mega, which was then configured to mirror incoming bytes onto its USB,
and vice versa.
The module was set to output a single NMEA sentence that included the location
information (GPRMC), with other sentences disabled. The maximum rate that the GPS
can send strings is 20 Hz, but testing showed that the microcontroller struggled to deal
with this amount of data while also being integrated with the other peripherals on the
standard node. The system was proven to be stable at an update rate of 2 Hz, however
it is suggested it may be possible to have a higher data rate if the serial port was
configured to have a higher baud rate than the default 9600 baud.
A high dynamic range firmware was also loaded, in theory allowing it to detect sharper
turns at the expense of a slightly noisier signal, as a smaller moving average is used to
calculate position.

GROUP H
Page 37 of 129
Figure 23- Venus 638FLPX Breakout Board by Sparkfun [24]
The datasheet [23] specifies that the chip takes 29 seconds to connect to satellites from
a no power state but only takes 1 second if kept in a low power state. This was tested
and was proven to be the case. The standard node PCB included a 0.2 F super-capacitor
to keep the GPS module in a low power state when the power is switched off.
This circuit diagram can be found on the accompanying CD, including the logic level
convertor to communicate with the MCU, and the LM317 3.3 V voltage regulator as
discussed in Section 4.1.4.
4.2.2 Accelerometer
A similar problem with the accelerometers was found as with the GPS – they are
generally only available in packages that cannot be soldered without infra-red oven
facilities. Pre-soldered breakout boards were therefore sourced, with the knowledge
that if the product was to go into mass production, these manufacturing methods would
be available.
An accelerometer was chosen that had an i2c interface. This allows the module to
independently poll an internal ADC to sense the acceleration – rather than that load
being placed on the host MCU. Only two pins are required to communicate with the
device – SDA and SCL. SDA is the data line and, as i2c is a synchronous protocol, SCL is
the clock line. This architecture also allows more i2c sensors to be daisy chained in the
future if required. As with the GPS, a logic level converter is required to convert the 3.3
V logic to 5 V logic.
The chosenmodule was the Freescale MMA8542Q [25], which can be configured to sense
±2g, ±4g or ±8g.This was configured to ±2g after discussions with USM, however could
be reconfigured for other applications. External i2c pull-up resistors are usually
required on the SDA and SCL lines to keep them high unless pulled low by the master
MCU. These are included on the breakout board that was bought.
The other potential option would be to use an accelerometer module that gives analogue
voltage outputs for acceleration on the X, Y and Z plane individually. The problem with
this is that most of these modules operate at 3.3 V, and with a 5 V MCU, there is a loss of
resolution on the ADC. It is difficult to amplify the output signal to match the input on
the ADC on the MCU, as they rest at 1.25 V at 0g in order to show negative acceleration.
The digital modules were therefore chosen as the most suitable option.
4.2.3 Analogue Voltages
As discussed previously, the internal 12-bit ADC on the MCU was used to sample external
sensors. This simply required the appropriate pins to be connected to the external

GROUP H
Page 38 of 129
sensor. Protection on these inputs was considered, as there is potential for these to be
connected incorrectly by the user. Current limiting resistors could be placed in series
with the input, along with Zener diodes between the input and ground. If a higher voltage
is present at the input, the Zener diode would break down and short to ground –
protecting the input of the MCU.
Further research indicated that the PIC microcontroller used in this project has internal
clamping diodes to protect the inputs up to the supply voltage plus 0.5 V, in conjunction
with current limiting resistors. It was decided that as the sensors in general would be
supplied by the node’s own regulated 5 V supply, the input voltage was unlikely to vary
very much. Transient voltage spikes may be present due to electrical noise on the car,
however they are unlikely to last very long, and a Zener diode would not protect against
these due to the relatively slow reaction time. Therefore the decision was made to use
the internal protection on the microcontroller – with the cost of replacing a
microcontroller (around £2) being less significant than the development and
manufacture of effective protection circuits.
4.2.4 Software Design
The node is required to send data at a rate of 10 Hz. The code is organised so that the
sensors are polled continuously, updating a set of global variables. A timer is set up to
send an interrupt every 100 ms (10 Hz), at which point a flag is set to package the data
into CAN packets and send.
The GPS module sends NMEA sentences over UART. It was important to deal with
incoming bytes as fast as possible. Through testing it was found that the hardware UART
on the MCU has a buffer of 2 bytes which if not read before another byte arrives causes
an overrun error to occur. This causes the MCU’s UART to go into reset, meaning that no
more data can be received. The code was reorganised to have a high priority interrupt
fire when a byte was received on the UART, which then put that byte at the end of a
circular buffer. The polling loop can then process from the start of the circular buffer
when possible, meaning that data was not lost.
The i2c operation for the accelerometer follows the protocol. The master (the MCU)
writes the address of the accelerometer to the bus (controlling the clock appropriately),
at which point all other slaves on the bus ignore any more messages (in this case no other
slaves are present). The accelerometer then sends an acknowledge message. The master
then writes the address of the register that it wishes to read data from. The slave gets
this data and sends an acknowledge command, at which point the master can clock in
the data. The master releases the bus before the next i2c operation by sending a not-
acknowledge, NACK.
The MMA8542Q offers a multiple byte read which allows the next address in the device
to be read automatically after an acknowledge message, without the master explicitly
asking for it. This is very useful as for the acceleration readings six registers have to be
read.

GROUP H
Page 39 of 129
Figure 24 - MMA8542Q multiple byte read feature [26].
The overall process can be seen in an extract from the device’s datasheet in Figure 24.
The operation for the MCU’s internal ADC is relatively simple using the C18 compiler
libraries. The ADC is set up with an appropriate clock speed, and set to use internal
voltage references. It uses the internal RC oscillator on the microcontroller for simplicity.
To make an analogue reading, the ADC needs to be switched onto the appropriate
channel, and a conversion started. The program then needs to wait until the conversion
is complete before reading the ADC result.
A slight issue was found when using some of the channels on the ADC, which was
resolved by fixing some slight errors in the library which were not correct for the specific
microcontroller. This fixed header file has to be included in the source file, rather than
the one from the compiler for those channels to work.
The CAN controller in the MCU is the same as used in the previous Smart Dash project,
so the same approach was used to control it. The helper application from Microchip,
Application Maestro, was used to create an initialise method, and library functions to
send and receive onto CAN. It was necessary to set up the bit timing for the controller, as
the CAN protocol is asynchronous and has no clock sent during data transmission. Each
CAN node on the network has different clock speeds, so synchronisation is achieved by
dividing each frame into different segments: sync, propagation, phase 1 and phase 2.
A CAN bit timing calculator provided by Microchip [27] was used to calculate the
appropriate values for each of the segments, given the clock speed of the nodes (20 MHz)
and the desired bit rate of the CAN bus (1 Mbps). Receive and send filters on the CAN
controller had to be set to extended mode to support the extended addressing as used
by USM systems and the DTA ECU.
TELEMETRY NODE
The telemetry package is made up of two nodes, one transmitter node on-board the car
connected to the vehicles CAN bus and one receiver node positioned at the side of the
track and connected to the off-board software system. The telemetry link is half duplex,
however it is only currently set up to transmit data from the car to the pits. This could
be expanded in the future to allow transmission from the pits to the car allowing further
configuration of the data which is sent or control of on-car systems.
4.3.1 Radio Link
A 173.25 MHz radio link is used to communicate between the two nodes. The low
frequency of this link will allow reliable data transfer between the car, which could be

GROUP H
Page 40 of 129
travelling at up to 60 mph, and the receiver at the side of the track which could be
positioned up to 500 m away from the car. The long wavelength of the 173.25 MHz signal
allows it to diffract around obstacles between the transmitter and receiver making it
more suitable for the environment of a racetrack than a comparable higher frequency
link.
4.3.2 Hardware Design
A PIC microcontroller links the on-board CAN bus with the radio link. A linear voltage
regulator and logic level converter are used to link the 5 V circuit of the microcontroller
and the 3 V specified by the radio transceiver. The circuit for this setup has been included
on the accompanying CD.
The Radiometrix Bim1 radio transceiver [28] on each node communicates with the
microcontroller over a UART serial connection. Due to lack of experience in RF PCB
design the transceivers were connected to the system using their breakout boards as
supplied with the narrow band evaluation kit [29]. However with the time and
production facilities to do so the transceivers could be connected directly to the
telemetry node PCBs, reducing package size and production costs.
The off-board design is implemented on a PCB linking the transceiver through a logic
level converter to an Arduino Mega board. The design utilises several features offered
by the Mega board: the microcontroller, the 3.3 V regulated supply and the UART to USB
used in order to communicate with the server. It would however be possible to use
individual components for each of these in order to reduce package size and production
costs.
On the on-board system data is continually collected from CAN using a polling loop and
used to update a set of variables storing the data. A timer is set to call an interrupt every
0.2 s (5 Hz) at which point a flag is set to call the transmit code on the next loop. This
code transmits all the stored data over UART and the radio link before continuing to poll
data from CAN again.
Due to limitations with the C18 compiler, the variables used to store the data have had
to be manually declared in separate sections. This is due to the compiler not allowing
blocks of memory larger than 256 bytes unless declared in separate sections [30].
A set packet structure is used across the radio link with preamble to reduce noise. The
packet structure has five ASCII STX (start of text) bytes to denote the start and five ASCII
EOT (end of transmission) bytes to denote the end of the packet. Twenty three values
are then sent in real-time, each value separated by a delimiter which is the ASCII US (unit
separator) byte. Finally, a checksum has been used to ensure integrity of the data.
LOGGER NODE
The logger node logs all data on the CAN bus to a microSD card. The data is logged at 5
Hz and includes date and time from a real-time clock module, GPS, accelerometer, all
ECU data and all analogue inputs from the standard node and up to 4 optional extension
nodes.

GROUP H
Page 41 of 129
4.4.1 Hardware Design
A PIC microcontroller is used to retrieve the data from CAN, arrange it into packets and
send it over UART to a second microcontroller which adds the current time sampled
from a real-time clock to each packet before storing to a microSD card.
The DS1307 real-time clock module [31], which has a battery backup, uses an i2c bus.
The Sparkfun SD breakout board used to write to the microSD card, communicates over
SPI. The PIC microcontroller that is used, the PIC18F25K80, supports both of these
protocols. Unfortunately both of the protocols use the same serial port so cannot be run
together. In order to simplify the system and making use of existing libraries developed
for Arduino, the communication with these two devices was offloaded to the second
microcontroller, an Atmel 328PU. The SparkFun SD breakout board was used to provide
the microSD enclosure which is otherwise unavailable in a package size suitable for
prototyping. The circuit for this setup has been included on the accompanying CD.
The logger code is split into two parts each implemented on its own microcontroller. On
the PIC microcontroller data is continually collected from CAN using a polling loop, with
the data being used to update a set of variables. A timer is set to call an interrupt every
0.2 s (or 5 Hz) at which point a flag is set to call the transmit code on the next loop. This
code transmits all the stored data over UART to the Atmel microcontroller before
continuing to poll data from CAN again.
On the Atmel chip the data is received and checked using a checksum to ensure it is
consistent with what was sent from the PIC. The real-time clock is then sampled to find
the current date and time and this is concatenated to the start of the data packet before
being stored to the microSD file in FAT32 format.
VIDEO HARDWARE
The video system designed is very similar to first person view (FPV) systems as used in
remote control airplanes. FPV means that the user can view everything as if they were
actually in a plane or in this case, racing in the car or further monitoring a component.
The design consists of five main components:
 Camera - captures the live video feed.
 Transmitter - transmits the video stream over a selected channel.
 Receiver - receives the video stream over the selected channel.
 ADC - converts analogue video feed into a digital one.
 Display – displays the live video stream.
This section will discuss the hardware decisions that were made during the process of
building such a system.
4.5.1 Camera
There is a wide range of different types of cameras available, from small portable
cameras up to broadcast cameras as used in television productions. USM have specified
that the chosen camera should be small and portable enough to be placed anywhere on
the car. Thus the following factors have been considered.

GROUP H
Page 42 of 129
4.5.1.1 CCD or CMOS
Two of the most common camera types that match the requirement of USM are CMOS
(Complementary Metal Oxide Semiconductor) and CCD (Charged Couple Device) [32].
Both of these cameras capture the video in a similar manner but CCD provides high
sensitivity, enabling it to capture video in very low-light (i.e. under the chassis). This
sensitivity is determined through the lux value of the camera and the chosen CCD camera
has 0.01 lux. This means that the camera can be placed in locations that may be darker
in order to monitor components. In addition, the CCD images are cheaper to develop
compared to CMOS, which leads to CCD cameras being less expensive [33].
4.5.1.2 Camera Resolution
Camera resolution depends on the television lines (TVL) [34], which is a specification of
an analogue camera’s horizontal resolution power. TVL is crucial when measuring a
video system because the more TVL a camera has, the better quality of the captured
video. The camera chosen for this video system consists of 700 TVL, which should give a
high quality image.
4.5.1.3 Lens Size
The lens size of a camera determines the field of observation view and zoom level it
provides. A smaller lens size produces a wider angle of view meaning a larger area can
be viewed, with less focus on individual objects as seen in Figure 25 [35]. Therefore the
lens size chosen is 2.8 mm giving a much wider angle of view allowing the USM team to
clearly see what is happening while the car is on track. Another camera with a larger lens
size can be chosen to provide a target for a particular component on the car.
Figure 25 - A comparison of lens size and the associated angle of view [35]
4.5.2 Transmitter and Receiver
The transmitter and receiver are an essential part of a wireless video system, and the
frequency of these and types of antennas chosen will determine the range and the
reliability of the video transmission. A 2.4 GHz transmitter and receiver have been
chosen for this system and the linear antennas have been replaced with the clover leaf

GROUP H
Page 43 of 129
and skew planar antennas. The reasons for choosing this frequency and these particular
type of antennas are explained in the following sections.
4.5.2.1 System Frequency
When considering FPV video transmission, there are four frequencies that are commonly
used. The lower frequency band allows for a waveform with higher amplitude to be
produced. This gives a longer range and is less susceptible to interference, allowing the
transmission to penetrate objects such as buildings [36]. Due to the fact these
wavelengths are extremely long, they require larger antennas to be transmitted [37].
The frequencies available for the video transmission are as follows [38]:
 900 MHz – This frequency is the lowest frequency band available for
transmitting video thus produces the largest waveform. This would have been
the best frequency to choose but the downside is that it is used by mobile phones
in UK for 3G technology and is illegal to use in the UK for licence-free radio
transmission.
 1.3 GHz – This offers good penetration and allows for long range transmission
but once again it is also illegal to use in UK [36] so therefore has not been
investigated further.
 2.4 GHz – This frequency suffers from interference from WiFi networks so
cannot be used in urban areas effectively. However the tracks used by USM are
often obstacle free and are away from urban areas, so this is not a concern. Due
to the higher frequency, range is reduced however this can be overcome by the
use of specialised or high gain antennas.
 5.8 GHz – This frequency can be used with smaller antennas resulting in a lighter
weight system. It has disadvantages of a shorter transmission range and reduced
penetration.
The 2.4 GHz band is an ideal frequency to use in UK for this particular video system and
where range issues occur, as mentioned above, they can be overcome with the high-gain
antennas on the receiver side.
4.5.2.2 Antennas
Antennas are a crucial link between the transmitter and receiver. Therefore it is best to
select the proper antenna for this scenario to ensure robust transmission and that a long
range is realised. There are two types of antennas; linear polarised and circular
polarised. Linear polarised antennas produce a vertical wave whereas circular polarised
antennas output a wave in a circular pattern. Waves produced by both antennas can be
seen in Figure 26 [39].

GROUP H
Page 44 of 129
Figure 26 - Linear Polarisation vs. Circular Polarisation
One of the advantages of using a circular polarised antenna is that it provides reliable
transmission. With linear antennas the transmitter antenna has to match the angle of the
receiver antenna. This condition not being met can lead to a loss in signal resulting in a
drop in picture quality or even total loss of picture [39].
In addition, linear antennas suffer from multipath interference. Multipath interference
is caused due to a linear signal bouncing off an object (refer to Figure 27) and arriving
later than expected or arriving out of phase compared to the original pattern. In circular
polarisation, when a signal is bounced off an object it changes its pattern in a different
orientation. A receiver antenna doesn’t detect it, leading to the multipath rejection
capability of circular polarised antennas [39].
Figure 27 - Multipath interference
Due to improved signal reception and multipath rejection capabilities of circular
polarisation antennas, the linear antennas weren’t further investigated.
Figure 28 - Circular Polarised Antennas [39]
The most common types of circular polarised antennas are (as seen in Figure 28):

GROUP H
Page 45 of 129
 The Cloverleaf – These antennas are designed specifically for FPV use and
consist of 3 distinct lobes. These antennas have gain of 1.2 dbi and produce an
isotropic radiation pattern [40]. An isotropic pattern means that the radiation
pattern is the same in all directions, allowing a 360 degree vertical and
horizontal bandwidth. Therefore these antennas are ideal for transmitters
because they radiate in all directions with the same gain [38].
 Skew-Planar Wheel – These antennas are also designed specifically for FPV use.
The difference between cloverleaf antenna type and this antenna type is that it
is constructed of four 105 degree arcs instead of three. It also has a lower gain
(0.9 dbi). Their omni-directional nature and better multipath rejection
capability, compared to cloverleaf antennas, makes them a suitable receiver
antenna [41].
 Helical – There is a lack of gain in circular polarised antennas as discussed
above, hence longer range transmission often requires an additional antenna
with higher gain to be incorporated on the receiver side. This usually affects the
circular polarisation of transmission by compressing the bandwidth in one
particular direction. An alternative to this solution is called a helical antenna.
This produces a true circular polarisation and provides a gain of 7.5 – 13 dbi [39]
[42].
A cloverleaf antenna will be used for the transmitter due to their lower cost, smaller size
and appropriate gain. A Skew-Planar antenna will be used for the receiver. Furthermore
a helical antenna can also be used to extend the range of transmission.
4.5.3 Analogue to Digital Converter
In order to display the analogue video alongside the data on the off-board system
application it has to be converted into a digital format. Therefore it requires a conversion
tool such as a video capture card.
This capture card plug into a user’s computer via a USB port and convert analogue video
stream into a digital stream. Once the conversion has taken place the stream can be
modified using video editing tools that are included with the capture card, therefore
allowing the stream to be recorded and saved onto a storage device.
The initial capture card chosen for the system was the EasyCap USB 2.0 video and audio
capture card. After installing the drivers for the card and testing it with the designed off-
board system, it didn’t work as expected. External software was used to validate the fact
that the problem was with the card itself and not the software system. The bought card
consisted of a UTV007 chip which was discovered to be a fake device and doesn’t include
the appropriate video decoder chip [43].
An alternative capture card was sourced solving these issues. The Dazzle DVD recorder
which outputs the analogue signals into H264 format. H264 is a video format of mp4 that
can easily be supported by most of the browsers.
4.5.4 Display
There are two options to display the video; either the video can be displayed on a
monitor through analogue output on the receiver side or it can be displayed alongside
the application with the use of an ADC. This is further discussed in Section 4.6.3.

GROUP H
Page 46 of 129
OFF-BOARD SOFTWARE SYSTEM
This application is used during runs to view data in real-time to allow the pit crew to
watch for any fluctuations that may require immediate attention. A live video stream
alongside the data helps the team to identify reasons for anomalies in the data. The
application is also used after runs for analysing the data for a driver or to aid testing and
designing of the car.
4.6.1 Architecture of the System
It was decided that the software would primarily be programmed in Java, as the project
member assigned the role of developing the system had strengths in Java. As one of the
requirements from the USM team was to be able to view the data in real-time, it was
decided that multiple users should be able to view this data to make the software as
useful as possible. To allow for this, it was decided that the best approach was to design
the software as a web application, allowing many clients to access the application via a
server.
Making the analysis software a web application allows it to be very flexible – many users
can access it simultaneously, multiple sets of data can be viewed at once, the software
can be viewed on different devices and the look and feel of the software can be updated
easily. With previous software that the USM team have used, the software has been
limited to a specific number of computers due to licencing and restrictions. However,
using a web application removes this constraint and allows more members of the team
to use the software simultaneously.
The analysis software is a web application designed with the Model-View-Controller
(MVC) framework in mind. The view is the JSP pages which are styled using Bootstrap.
The model is the underlying code that creates the objects. The controllers use Spring to
pass information between the view and the model. The data is stored in a MongoDB
database (described in the next section). Services are used to write data from the model
to this database, and retrieve data from the database to pass back to the model. The
whole application is hosted on a Tomcat web server and Spring Security is used to only
allow authorised users to view the application. A basic diagram of how the software is
made up is shown below in Figure 29.

GROUP H
Page 47 of 129
Figure 29 – System Architecture
4.6.1.1 Maven
The project was set up as a Maven project. Maven is a tool used for building and
managing Java-based projects. It allows a project to be built using a set of plugins (shared
by all Maven projects) and a project object model (POM) [44]. Maven allows for JARs to
be included in a project by including a few lines of code, meaning that the project can be
easily imported to other computers as Maven will automatically download all the
relevant files.
4.6.1.2 Spring
The system was designed as a Model-View-Controller (MVC) application. MVC is a
software pattern used to separate the internal representations of information (the
model) from the way that the information is presented to the user (the view). The
controller is the link between the view and the model, translating user commands from
the view into messages which can be interpreted by the model. Using an MVC design
allows for different views to be used easily with the same model. To link the back end
Java with the front end HTML, the Spring framework was used as the MVC
implementation for the web application.
Spring is an open source application framework and inversion of control (IoC) container
for the Java platform, providing comprehensive infrastructure support for developing
Java applications [45]. The IoC is a consistent means of configuring and managing Java
objects (otherwise known as beans [46]) – it creates the objects, calls their initialisation

GROUP H
Page 48 of 129
methods and configures the objects by connecting them together [47]. The IoC uses
reflection (examining and modifying the structure and behaviour of an object at
runtime) to do this.
The Spring MVC implementation is designed around a Dispatcher Servlet that dispatches
requests to handlers. Using annotations such as @Controller and @RequestMapping
offers a wide range of flexible handling methods and creates a RESTful2 web application
[48]. The model is a Map interface which allows for complete abstraction of the view and
can be integrated directly with JSP (JavaServer Page that contains static data and
dynamic content [49]) as well as directly generating JSON and other content types.
4.6.1.3 Bootstrap
Bootstrap is a powerful front-end framework for faster and easier web development
[50]. It contains HTML and CSS based design templates for typography, forms, buttons,
navigation and other interface components. It also includes optional JavaScript
extensions [51]. Bootstrap is responsive which means that it adapts to the change in
platforms with super speed and efficiency. For example, if a user moves from using a
laptop to using their phone, the page will automatically resize and components will
adapt [52].
4.6.1.4 Tomcat
As the analysis software has been designed as a web application for client/server use, a
server is needed to host the software. Tomcat is an open source web server and servlet
container which provides a pure Java HTTP web server environment for Java code to run
in [53]. By running this server on a computer, the USM team can access the web
application by going to the following page “http://XXX.XXX.XXX.XXX:8080/USM-
Analysis-Application”, where XXX represents the IP address of the computer that is
running the server.
4.6.1.5 Spring Security
As the data that is recorded from the car is sensitive and the USM team do not want other
Formula Student teams to be able to see the data, security has been put in place to ensure
only USM members can access the analysis application. Spring Security is a powerful and
customisable authentication and access-control framework which is the standard for
securing Spring-based applications [54]. If a user tries to access any part of the web
application, a login box will appear asking for a username and password. Once this has
been entered, the user is free to use any of the web application software. If the user
cannot provide the username and password then they cannot access the application and
therefore cannot view the data. This ensures that the USM’s data is protected if the
username and password is kept to within the team.
2 Representational state transfer (REST) is an architectural style consisting of a coordinated set
of architectural constraints applied to components, connectors and data elements within a
distributed hypermedia system [77].

Group H Final Report

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (13)

Similar to Group H Final Report

Similar to Group H Final Report (20)

Group H Final Report