Welcome to this first part in a running column about all things motorsport electronics related. In the future we will discuss several different topics surrounding the use of electronics and electrical components in the world of motorsports aiming to make these relevant to general car enthusiasts as much as possible.
I thought we would kick this all off by covering a subject that gets a lot of focus these days – Data Acquisition, or Data Logging as some like to call it.
How about we start from the basics and slowly progress into more details in the future? The subject of data acquisition can fast become rather complicated and includes aspects related to hardware, software, electronics and, a feature that is becoming more and more common, video. This picture is a quick example of the complexity related to the subject of data acquisition. Here is a screen shot of data recorded and getting analysed after my 2013 Porsche Sports Cup Final race in Sweden at Mantorp.
Data acquisition has been used in motorsport as far back as the early 1970s, but was, at the time, restricted to the larger teams with the budget to afford such technology. It is not until more recent times, when the ability to record data (and subsequently analyse the results) has it become more affordable and, therefore, more interesting to a wider audience and user group that the benefits are no longer just for the world of motor racing. As we will look at in more detail in the future, data acquisition systems can be used for driver education, testing and a number of other areas – but for now, we will focus on the basics.
Let’s start with a simple definition. Data Acquisition is any system that will record desired and relevant information related to the engine, chassis and driver for future review and analysis. Whilst the conventional instruments in a vehicle display mainly (but not restricted to) engine-related parameters, they do not store the values for future review. This, therefore, requires the driver to remember the values and record them after the event along with the related variables and conditions that were experienced – not easy after a 20 min race!
So what are the main components that make up a simple data acquisition system? At the core we need a minimum of three elements to be able to have a working data acquisition system:
- Sensors – we need one or more sensors to measure the parameters that we are interested in and will be analysed at a later date.
- The Data Acquisition unit – a dedicated electrical unit which will receive the information from our sensors and store them to memory which can be accessed after the event.
- Personal Computer – Using either a cable connected directly to the acquisition unit or by reading the removable memory card from the unit we can download the recorded data for analysis.
Whilst only the two first in our list represent the core parts of the data acquisition system, it is an expensive but useless item if we do not have the computer to read and analyse the recorded data. The following picture shows some of the data acquisition products available from Racelogic, and represents only the tip of the iceberg when it comes to the number of product providers and components that are available today.
To further work on our definition, it is also good to point out that data acquisition is not telemetry. Whilst it is a part of telemetry, it is not in itself the same. Telemetry is the ability to make measurements at a long distance, and at the core relates to the transmission of data via radio or other means to a remote receiver. When we talk about motorsport the subject of telemetry is more commonly seen as transmitting acquired data from a racing vehicle back to the team in the pits or at a remote location. So whilst telemetry is at times confused with data acquisition, it is clearly not the same, but does have a close relationship to it.
Acquiring the Data
As already mentioned above, when we talk about data acquisition it is normal to split the information into three core areas – engine, chassis and the driver. Most data acquisition systems today will also take advantage of GPS technology to record geographical information such as location and direction of travel, and as mentioned earlier, over the last few years we have seen an increase in systems synchronizing video with the acquired data.
Integrated video is fast becoming increasingly popular with both trackday enthusiasts and professional racing drivers. It is without doubt a fun way to share the driving event with friends, but also gives a new channel for driver analysis. We will cover the benefits of integrated video for making better and faster data analysis when trying to improve lap times or review an incident at a later date when we do a deeper dive into this subject. For now we will return to the fundamental areas related to data acquisition.
In all vehicles there are a minimum number of instruments to aid the driver during a race, these will in general display information such as the engine rpm, some temperature and pressure related information and maybe even the wheel speed. But as already discussed, these instruments give a single point in time picture as to the state of the vehicle and have no ability for past reference. And you can forget trying to remember the value on all the instruments at a given moment during a race when the driver had an unusual incident!
So it goes without saying that we need the data acquisition system to record these values. At a minimum it is recommended that the engine rpm is recorded as this will give the best picture for analysis at a later date. But other values that could be useful to record, if you have the spare channels in your acquisition system, include fuel and oil pressure, water and oil temperature, exhaust gas temperature and mixture, inlet air temperature and any other variables you feel appropriate.
When we talk about the chassis, we cover everything else on a vehicle which is not directly related to the engine, such as the suspension, wheel speed, gear position, g-force and more advanced options such as tyre pressure and temperature, drive height etc.
For any vehicle to make it around a racing circuit there is an inherent need for driver input such as the steering and pedals (I will exclude discussions about the google car and other vehicles that move without human intervention for now). In this case we therefore look to collect things like steering angle, throttle position and brake pressure as well as any other parameters that are directly affected by input from the driver.
Obviously, all the values related to the Driver are at the core either within the area of the Engine or Chassis. But for future analysis we want to distinguish between data which is fully controlled by the driver and those data points that are a related effect of the entire system. As a simple example, the driver will manually alter the throttle position, brake pressure and steering angle when taking a corner (Driver data points). These actions will affect the suspension, engine rpm, speed, longitudinal and lateral g-force (Engine and Chassis data points). We can therefore see that whilst the way the corner is driven is down to driver input, the way the car behaves is more related to engineering and how the car has been set-up. Analyzing this data can therefore give insight both on how the driver can improve and corrections to be made to the configuration of the car.
The Minimum Usable Subset
So we have a Data Acquisition system and some sensors to collect data points whilst we are in motion, but before we install a plethora of sensors all over the car lets define the minimum data points that we should be collection to gain any value from the system.
Using me as an example, I am collecting the following core data channels on my racing car:
- GPS coordinates
- Engine Speed (rpm)
- Throttle Position (%)
- Brake Switch (on/off)
These channels give me the minimum data points I need to be able to analyse both my driving and the configuration of the car for any given racing circuit I have driven on. The values collected give me the ability to see if there are any hidden issues developing with my car, but also by comparing repeated sessions I can see what has worked best and what to avoid in the future.
There are different views from the experts as to what is the minimum information required to have any value for analysis. Excluding the throttle position, for me the above list from my car is what I would list as the minimum.
My good friend and mentor Simon McBeath, who has extensive experience in the subject and has written a book on data acquisition, argues that the minimum channels required can be reduced down to speed, throttle position and steering angle. He argues that at the end of the day it is the speed that we are interested in, and it is the effect of the driver interacting with the throttle position that gets the car up-to-speed. And that the combination of throttle position and steering angle can give you a lot of information on how the car is handling.
So now we have a good foundation on the subject of data acquisition. In the next installment we will take a closer look at the types of hardware available and what to look for in your system. We will also discuss how to get your system installed, set-up and ready for your first data acquisition session.
If you have any questions related to the article or would like to request a subject to be covered in a future article then please drop me a line.