Welcome to the first instalment of PovSpec Post-Race Analysis, where I, the devil on Blandon’s shoulder, will try to analyse Blandon’s driving throughout the 2018 Interclub Supersprint season (and subsequently tell him to keep driving faster).
We were out at SMSP Druitt (formerly known as North Circuit) the otherweekend for the first round of the season, it was Blandon’s first time on the track and my first time trying to be a race engineer using Racechrono and Microsoft Excel.
In this introductory post, we’ll cover all the gear we used to capture and process the data so that you, too, can give this a go and analyse your own track data (provided your vehicle/ECU has OBDII, OBDI may work not sure).
Here’s all that we used:
- Smartphone – Such as my Samsung S8
- Racechrono Pro App ($27.99) (Compatible with both iOS and Android)
- External GPS Receiver – We used a Qstarz BT-Q818XT (~$100)
- OBDII Bluetooth Reader – El Cheapo eBay special (~$5)
- Spreadsheet program such as Microsoft Excel, Open Office Calc, etc.
That’s pretty much it, a very basic setup that captures some very useful data. For our analysis, we focused on the speed output, GPS location and altitude, which were captured using the external GPS receiver through Racechrono Pro. Then using the OBDII reader we obtained the throttle position from the ECU. The sample rate on the OBDII reader is a combined 5Hz and as we opted to capture throttle position and RPM, each channel was being captured at only 2.5Hz, it halves the sample rate for each channel so if we selected 3 it would be 1.6Hz each channel. So the sample rate of throttle position isn’t as high as the outputs from the GPS receiver (2.5Hz vs 10Hz).
Some may wonder why we used an external GPS and not the inbuilt one in your smartphone and the the reason is sample rate, the number of times it captures data per second. A smartphone usually has a frequency of 1-3Hz (1 – 3 times a second) where our unit has 10Hz (10 times a second). You may have noticed some videos online where the speed doesn’t match the video and it’s due to the program not having enough data points to extrapolate or “guesstimate“between data points. A good way to visualise is to use the example below.
The above is an example of a 10Hz log, there are 10 data points, plenty for the program to make accurate calculations. If it was only 1Hz it would capture the 0ms data point then the 900ms data point. The program has no idea what’s happening between it so it guesses hence leading to inaccurate logging and even the controversial “Optimal Lap Times” where the program has made a completely inaccurate extrapolations between data points.
Here’s the setting page of RaceChrono where we can select the external devices and interface it to the app so we can capture data and export it. We can also select the channels of our OBD reader and even a Bluetooth camera (GoPro) and have it automatically overlay the data without having to manually do it.
This is what the raw data looks like after it’s been exported from Racechrono in .csv format.
As you can see, Racechrono itself outputs a lot of data channels but we’re focusing on Speed, Throttle Position and Altitude for our analysis. An interesting note, the OBDII Reader’s throttle position output ranged from 11% to 78%. We believe it may be caused by a calibration issue between the voltage range on the car’s Throttle Position Sensor (TPS) vs the OBDII Reader’s voltage range (eg. 0.5V to 4.5V on the TPS vs 0.0V to 5.0V on the reader). However, it can easily be converted to a 0-100% scale using a basic formula in Excel.
Additionally, we used the GPS Co-ordinates to generate the track map in Excel. We split up the data according to the sectors then combined them. This allowed us to have each sector in a different colour for ease of identification.
To analyse the speed and altitude, we plotted speed (primary y-axis) and altitude (secondary y-axis) vs time (x-axis). This gave us a basic plot of the data we wanted to analyse.
Here’s one we prepared earlier. With a bit of mucking around with the graph’s format, this is what we ended up with. This is an overlay of the data from Blandon’s PB lap compared to a previous lap.
From here it’s up to you what data outputs you would like to analyse. I chose speed and throttle position as a function of lap time. This allows me to analyse Blandon’s throttle application and his speed delta throughout the lap.
And that’s basically it. You can have basic data AND reliable acquisition for less than $150, given you already have a smartphone and a copy of Microsoft Excel. (Note: Some ECUs have certain protocols that prevent it from working with certain (read: cheap) OBDII readers. This is when you’ll need to spend a bit more on the reader. The one we used didn’t work with an early 2000 Mitsubishi Lancer)
In the next post, we’ll go through in detail Blandon’s performance at the first round of Interclub Supersprints held at SMSP Druitt (North Circuit).
Here’s the data we captured overlaid onto his personal best lap.
Thanks for tuning in and if you have any comments or suggestions, please throw them in the comments section below.