Donington Haltech Report

1. Acquiring A Data Logger

Data Logging has become one of the most important aspects of modern motorsport and being quite keen on becoming a race engineer I thought it was high time to dive into it. Looking around the HQ of the Oxford University Motorsport foundation I saw two primary forms of acquiring data: 1. The Vbox which only outputs video and speed via a gps and 2. A Motec data Logger from 2003 that sadly no longer fully functions. Not letting myself be defeated so soon I went to Ding with my query and he duly reminded me that I may have an opportunity to get a new data logger at the race retro motorsport show. Upon looking at the list of stands at race retro my ambitions to acquire the squiggly lines was re-lit with Haltech being in attendance.
At race retro we were met by Martin Stelleman and Mark Luney who both jumped right on board in my quest to learn proper race engineering and graciously allowed OUMF to ‘have a play’ with a Haltech Nexus S2. Not getting too personal, but my excitement was through the roof. 11 analog inputs! 6 SPI’s! A MAP sensor!?!? Once the Haltech (which is what I will refer to the Nexus S2 as from now on) was with us we put it on display at the Practical Classics Restoration Show at the NEC with many ooo’s and aahh's from not only the students in the club but many a show goer. I was just ready to crack on and get the thing into one of our cars!

---

2. The Original Plan

Being six weeks from our first race of the season I knew it was going to be a challenge to get the Haltech into a car, so, I decided I was going to attempt to put it in two! Firstly, our Elva MkII Courier, a sports racer from 1959 that has Goodwood heritage and just so happened to be in pieces waiting for a complete rebuild and brand new setup. Some would say a perfect opportunity to learn about and then apply data logging. And second, our Riley 1.5, the clubs ‘old reliable’ and the car that was running the previously mentioned Motec system so it should be a case of changing some pins and off to the races! Right?

​(Elva TPS linkage CAD Assembly)

Anyways, since I was pretty new to race engineering (let alone data analysis) I dove straight into the literature with two books everyone recommended: ‘Competition Car Data Logging: A Practical Handbook” by Simon Mcbeath (part of a wonderful series which I highly recommend) and ‘Making Sense of Squiggly Lines’ by Christopher Brown. These two books gave me a basic understanding of what data, and in turn which sensors, I should be after: speed, RPM, throttle position, steer angle, Longitudinal G, and Lateral G. Knowing this and looking at the Elva in bits, there was a lot to do and a lot to learn. Previously, having had the mindset that anything electrical is black magic, I knew it was going to be quite difficult to tackle wiring the haltech in alone. I asked fellow OUMF member,Ethan Wakeman (who pretty much made the loom for the Elva) if he would teach and aid in setting up the Haltech and after looking through the data sheet and having a whirlwind of ideas, he was in. We set off making a list of everything that needed doing to the Elva over a 5 week period (excluding a race engine build). My first task was to design a throttle position sensor mount and linkage to fit our Weber Carburetor. I got dimensions, drew up some sketches, 3D modeled the thing, and sent it off to get the parts water jet cut! While the design process was going on Ethan was getting his head around the Haltech and all of its capabilities by wiring up and off car setup to test gauges, sensors, and the MAP input. Along with Ethan and I’s shenanigans: the rest of the team was starting to put the Elva back together with new suspension arms, dampers, springs, bolts, and bushes. It seemed possible to get the thing to our first Race at Donington Park which, by this point, was 4 weeks away. But the clock kept ticking and we were still missing some parts, and even though our new race engine was coming along swimmingly, the door was starting to close and with it the realization that running in a brand new car and engine in just 1 week without testing, was just plain stupid. With what felt like a great sigh of disappointment, we shut the Elva shed to re-focus on our new task at hand. 

3. Plugging into a car from the 50’s

The Riley had already been wired up for data logging by OUMF generations gone by, so the idea was to quickly swap the pins into Haltech connectors and bob’s your newt! If only it were so easy... The Riley has long been a part of OUMF and thus many ideas have been tried and tested, which has made the wiring quite messy (a future project for sure). So began the tracing of wires and studying pinouts to suss out what was what. First to tackle, the steer angle sensor. Which was found, and tested - still working! Next was the throttle position which proved more interesting. We traced the wires and plugged them in! Nothing. We triple checked wires supplying voltage, quadruple checked wires that were going to ground... nothing. The throttle position sensor had been on the car for 10+ years and it seemed it had finally gone kaput. Without time to design a new system, we were going to have to improvise. We grabbed one of our new Haltech throttle position units and luckily the mounting holes were the same distance as the old ones, so only minor fiddling of the hardware was needed. Ethan got to routing wires through the firewall and I drew up some adapters to step down the Haltech D-shaft to the Double-D-Shaft needed to fit the old system. We asked a friend to 3D print them overnight as we were now 4 days away from the first race! Once we got the adapters, we mounted it up and boom, a squiggly line in the throttle trace. 
Next was the accelerometer. It took some fiddling to try and find the correct wires for the correct axis, but after some digging through the HQ’s electrical corner we finally found the data sheet, and so we configured the Haltech software to the correct pins and we seemed to get a reading. 

(Adapted Riley TPS System)

We now had two days to go until the race and now was the fun part, testing! The first run was just an alpha test to make sure the Haltech system stayed in one place and stayed on! Car went out, car came back, and the Haltech was still secure, plus we had some squiggly lines! We (Ethan and I) now had two main goals, both suiting our wiring and technical abilities quite well. Ethan was going to try and make a CAN Bus to allow the Haltech and VBOX to communicate so we could get Haltech data on our VBOX video, and I was going to wire in a switch. My switch worked brilliantly but Ethan’s endeavor took the next 14 hours and sadly to no avail. We think it has to do with VBOX hardware but there is still much to learn on this front. We then packed in and packed up to go to Donington Park.

4. Trying to Understand Squiggly Lines

We got to Donington feeling quite overwhelmed in the data logging department. It was our first time with the Haltech and we still needed to swap the VBOX between cars while off loading its data. Sunday was going to be a busy day. We sent Ding out in the Riley for the first Quali of the day. The event was running on the GP layout which nobody was particularly happy about, especially Ding who had not driven the layout for several years. Lots to learn all around then... He did his laps and Qualified 8th out of 17 in class. As the car came back, Ethan and I hopped into action, I plugged straight into the Haltech and offloaded the data while Ethan grabbed and gave me the VBOX SD card after removing the VBOX itself to put in our other car, which was already warming up for its own session.

(Riley 1.5 Quali Data)

I knew going into the weekend the Haltech Data Log Viewer was plainly a data viewer with no motorsport oriented features (yet?) so the plan was to compare speed traces from the VBOX and Haltech to find out which part of the track the data was showing me. Once I had the data in front of me I very quickly realized how much data can be collected in a short 25 minute session. I was a bit out of my depth, but dug deep and tried to analyze what I could. I soon had quite a worrying discovery, the Haltech speed trace was not matching the VBOX. Talk about a spanner in the works. After double checking our calibration was not miles out, I found a filter had been put on the GPS input and so I wiped it to see if that would work. The team made some changes to the car and it got sent out to race. After starting from back, due to a mistake by the officials, Ding finished valiantly 5th in class and 4 second quicker than his Quali time. Back in the paddock, I was now staring at an hour's worth of data and was coming to the conclusion that getting a data logger in the car is one thing, but having the tools to process and analyze the data is a completely different ball game. I then downloaded the data as my laptop was on 1% and helped the team pack up.

​(Riley 1.5 Race Data)

5. Much to Learn

Putting the Haltech into a car has been one of the most rewarding and challenging tasks in my 3 years at OUMF. Not only do I feel like I’m properly making progress to becoming a real race engineer, I’m tackling topics which I never have touched before. One of these is coding, specifically in Python. I hated not knowing what to do with the data at the track, so I’m beginning to learn Python to develop my own tools to extract the Haltech data and cut it into laps, and then to hopefully plot and sort the laps. Quite a task for a newbie like me! Ethan on the other hand is still quite upset he could not get the VBOX and Haltech to talk via CAN so he is back to being knee deep in the bits and bites of both systems. There is still lots to do with the software and on
the hardware front we still need to wire it into 2 more race cars (and possibly the rally car). OUMF recently got permission to use the MIRA test track which is a huge opportunity for a team which has NEVER tested on a closed course. It also presents Ethan, myself, and any OUMFer who is interested in data analysis to dig deep and really understand our cars. I must give my most sincere thanks to all those at Haltech, Race Winning Brands, Mark Luney, and Martin Stelleman for giving me and the rest of OUMF the chance to dig into data logging. I look forward to my next update after Oulton Park in July.

-Charlie Lemme
Placement Year Student
BEng Motorsport Technology @ Oxford Brookes University