LAST month, we looked at how the datalogging functions of the Haltech ECU in Arby’s WAR440 Valiant could tell us how its engine performed in last year’s Street Machine Drag Challenge. This time around, we’ll speak to a number of racers and tuners for their thoughts on what datalogging can do for you.
Mark McCoy is an applications engineer at MoTeC, and the tune-up man for 2014 Drag Challenge champion Quentin Feast and his eightsecond turbo LS-powered Torana. Mark says there are still racers who are reluctant to use datalogging. “On the street/drag level, there’s still an impression that there’s a bit of witchcraft involved,” he says. “Most guys are more comfortable with a carb and points than they are with a laptop – fair enough. But look at what’s happening now: What’s a fast street car?
Fifteen years ago it was a carbed big-block running 11s. These days we’ve got guys running in the sevens and eights.”
Mark believes that without datalogging you’re really just poking around in the dark. Hopefully the information presented here will prove you don’t need to have a high-tech car to take advantage of this kind of technology; datalogging is just as valid to use on your carbed small-block V8 as it is for twin-turbo LS-powered monsters. Sure, you won’t be able to adjust your mixtures with a few keystrokes on your laptop, but with the knowledge of what is actually happening in your motor, you’ll be able to zero in on the best tune possible a lot faster, and without any of the guesswork.
And if you’re still not convinced, this is what Mark has to say about the supposed ‘black magic’ around sensor technology: “Most sensors actually work the same as far as the electronics go. The majority of sensors are what we would call analogue – their voltage reading changes depending on the state of the device it is connected to. So a throttle position sensor, shock absorber position and G-force meter give the same sort of information – a varying voltage. It’s only the ECU or datalogger that converts it to percentage throttle, millimetres of shock travel or Gs of acceleration.”
Over the following pages Mark will take you through some real-world examples of the kind of information datalogging records.
THIS graph shows an overlay of two runs of Quentin’s Torana at Heathcote. The red trace shows an 8.72-second pass, and the black one is an 8.82-second pass. There were no changes to the tune between the two runs, but obviously one is slower.
You can see in the rpm overlay (top trace) that the biggest problem is that the driver shifted too early – 0.6 second early, to be exact – and it cost him one-tenth second at the end of the strip. The effect this has on force (second trace down) can be seen between the and green lines, with the red trace higher for nearly a second. Higher G-force means more acceleration.
The third trace down is throttle position, which shows it wasn’t the driver doing something stupid on the throttle that caused the slower time.
The bottom trace is the speed of the car, so you can the difference in speed that the short shift gives – two-thirds of the graph the well-shifted run (red trace) ahead. these graphs failed to pinpoint the problem, you could search through the list of other channels you’ve logged compare them until you found your answer. Maybe driver did shift at the right time and a loss of boost the issue, for example. The more parameters you log, better chance you have of finding out why the car slower. of a of a G-fo blue seco Th that thro Th see for t is ah If t sear and the was the was TH Tor 8.7 pas Y big
I WISH I had datalogging on our old burnout car; we would have saved ourselves a few blow-ups and problems. We would have the car on the chassis dyno and everything would look fine; it took us a while to realise that the tuning was a fair way out at part-throttle – which is where we were most of the time on the burnout pad. On the pad, you’re never really getting to full throttle and you’re constantly at vacuum; you’re never really loading it up.
It was always lean and we were hurting pistons and detonating, but didn’t realise because it was rich at idle. So the moment we got off the burnout pad the plugs would be all fouled up. We thought it was rich and couldn’t understand it, but if we’d had data we could have fixed it straight away. Fitting an O2 sensor is not hard and most people have a general idea where it has to be. Yes, it can be expensive, but man, it can make life so much easier.
The other big benefit is that you can send information to people – like Mark McCoy – who can troubleshoot problems and save you a lot of trial and error. Mark also says people don’t need to be afraid of sending information – they get really secretive about it. Don’t send screen shots, send actual information. They’re here to help you, they’re not going to run off and tell everyone what the tune is.
HERE are two examples of oil pressure readings from the same engine at the same temperature. The narrow one on the left is what the engine should be doing, while the wide one on the right was about the time we could hear a small knock in the car, and we weren’t sure what was going on. While the oil pressure was at about the right level, it was ‘noisy’.
Because we had many examples of what it should be, and we datalogged it at a high rate (more on logging rates in the next caption), any change in how the oil pressure acted stood out like dog’s balls, so we knew we had some sort of issue. We stopped straight away and put the car on the trailer.
When the engine was pulled down it had a big crack in the crank. If we had ignored the data and given it one more run we would have almost certainly destroyed the engine.
Plus, having the data negated all the ‘expert’ opinions we had around the track!
THESE two graphs show the same info in different ways. We always talk in logging rates, which is how many times per second you sample and record a channel. This is specified in Hertz (samples per second). We can see this in the graph on the right, which shows the same information as the left graph but represented as a series of dots. Each dot represents a sample point that was recorded.
Normally people look at the line version in the left graph, where the dots are all joined up so that it’s easy to read. But don’t be fooled by the line view, because it actually shows each dot (sample point) joined up by a straight line that doesn’t necessarily reflect the actual values between the dots. We always flick between the dot view and the line view to get an idea of what is definitely a recorded sample point and what is just the straight line joining them. It can depend on what type of sensor you’re looking at as to which view is best.
You can see on the manifold pressure trace at the bottom of the dot graph that the red trace was recorded at a slower rate compared to the green – there are far less dots in the red, meaning it’s missing a lot of what went on during the run. When you don’t log something as fast as it is likely to change, you can miss important data, so it’s always vital to match the logging rate to the channel you are looking at. For example, engine speed (top trace) in the dot graph almost looks like a line view – that’s because it was logged at a very high rate (200Hz), so that we didn’t miss anything important.
Most modern dataloggers will allow you to choose the logging rate to match the sensor. For example, if a parameter is likely to change slowly – engine coolant temperature for example – it’s fine to log it at a slower rate (1 or 2Hz). For something like inlet temperature on a turbo engine, you might go up to 20Hz because it changes much faster. Engine rpm can change quite quickly so you want to log that at 100-200Hz. The same goes for wheel speeds, in order to see the quick bits of wheelspin you get over the bumps in certain lanes at certain strips.
Once the car is back in the pits, if you find you’ve logged a channel too slowly, that missing data is gone forever. On the other hand, If you have gone nuts and now have too much information for what you want to look at, the data analysis software will allow you to filter or average the data out a bit.
I WAS old-school carby, no data or any of that, and Mark comes from a hightech background at MoTeC. Over a couple of bourbons – like blokes do – he says: “We should put injection on your car, a twin-turboed LS in it,” and yeah, here we are.
We actually put the dash and some sensors in the car with the carby and went to the track in some filthy weather and we went four-tenths faster over five passes. We went one-tenth faster every run just from having the logging and knowing exactly what was going on and where to adjust the tune. The car PB’d every pass and everyone else was going slower. I couldn’t race without it.
All I changed was jets to get the A/F ratio right. We were pretty fat about 12.2, so I leaned it out to 12.4 and it went 0.15sec quicker, so we knew we were going in the right direction. We just kept leaning it out and at 12.7 or 12.8 it did its PB. Then we leaned it out to 13.0 and it went slower. So, for my combo around 12.8 made the most horsepower.
It was just one day and all we had on the car was throttle position – because Mark wanted to know if I was being a girl and not holding the throttle – and that’s what data does. It takes all the bullshit out and all the ego out and you know exactly what’s going on. If you don’t have data, you’re just guessing.
HERE’S a good example of seeing something you don’t expect. This is an rpm, throttle and fuel pressure trace from a race car. The fuel pressure goes nuts when you back off the throttle, because the fuel, which was flowing at a great rate of knots, now has nowhere to go, and you effectively get water-hammer. Also notice how much it fluctuates when on power – this is not a mistake, it’s what is actually happening. Remember, each fuel injector is like a tiny leak that opens and shuts multiple times a second, so the fuel pressure logically has to up and down rapidly.
I would suggest, to get the total story on this, fuel pressure should be logged faster. A fuel pressure regulator will never keep up with those fluctuations, so a different design of fuel system may be needed to combat this effect if it becomes a problem. You just don’t see this kind of thing on your oil-filled, shiny anodised dash meter! ure as o stake, el ple o go ny
ON GARY Myers’s car and STRUGLIN and a few other guys, they run individual port nozzles. Some cylinders run colder than others so I try and equal them all up. I also monitor fuel pressure, temperatures. On Bushy’s car [Justen Brown] we’ve also got gearbox pressure, because doing burnouts with drag racing gearboxes that are only typically meant to be run for eight seconds under full load, you get a lot of pressure building up as you get on and off the throttle for long periods of time.
What it does is push the converters against the rear main and blows the motors up!
After a burnout I’ll have a look at the whole run. It will tell you rpm, boost, temperatures, oil pressure – there can’t be any lying. For myself personally, it’s more of an insurance policy. A lot of the burnout guys are running on adrenalin and will go out there and scream it to 9000rpm with no dry sumps. I had a GoPro on an oil pressure gauge in one car to see what it was doing and during the run it was losing oil pressure and had no oil pressure for 40 seconds! It seized the motor completely and threw rods.
So I’m covering my arse and tuning the cars with it as well. If they say to me: “It had oil pressure and it blew up,” okay, we’ll go back to the datalogger and have a look.
If I see a hot cylinder, or something that’s getting hot, I’ll pull the plug anyway and match it to the reading I’m getting off the datalogger.
DATALOGGING has done heaps for my VC. Its first-ever meeting it ran 9.40.
Without changing anything – just from datalogging – the exact same car in eight passes went 8.90. From there it ran 8.60 – without changing anything still, just from the data and tuning it to suit.
We raced a couple of meetings like that where it was an 8.50 index. Then we made a few changes, like exhaust manifolds, but still the same engine combo and driveline, and in one meeting – where we tried to go fast – in five passes we went from 8.60 to 8.10. The next time I tried to go fast it went 7.97.
We lost a lot of our data and had to start from scratch with tune-ups. We did four passes and pretty much blew the tyres off it every pass. The previous best we’d ever gone in the 60-foot was 1.23. I really wanted to get into the 1.1s and we just looked at the data and made changes to the shocks and suspension, one pass at a time. Within 10 passes we were going 1.17 in the 60-foot. I don’t think you’ll find another radial car in the country that’s gone 1.1s in the 60-foot, especially at 3300lb.
I’ve been tuning cars for about 16 years now at my shop, so I’ve always done some sort of data acquisition. These days, aftermarket ECUs and datalogging are that good that when I dyno vehicles I don’t hook up half the stuff I used to, because it’s all in there.
I’ve got customers that don’t have datalogging and when they hurt an engine, deciphering what went wrong is a hell of a lot harder than if you have data. With data you generally know what went wrong before you pull it apart.
You might have to spend $10,000 on data for everything you need to make your car fast, but when you save one engine – because you see something going wrong before you hurt it – it’s paid for itself.
IN THIS one you can see overlays of a couple of runs with different boost. Overall the runs are fairly different; telling factor is that we added more boost, but the force reading (second trace down) tells us that it really make that much difference to the rate of the acceleration. So, was it really a gain or should we looking at doing something else? times I have set up cars with launch control and I will ask the driver to just go out and do a heap of launches any way they want to. I can then overlay all the launches and pick the best bits of each. far as the launch control goes, or even the boost control or maybe throttle map, I can ‘Frankenstein’ a number of good parts together to get the best bits of It can be a really good way of learning if you have the right boost or rpm but at the wrong time – maybe need to bring it in earlier or later.
G-force sensor is absolute gold in this instance, and in day and age they are not expensive considering much good info they give.
TH d the tel G-forc didn’t car’s a be loo Many w launch launch As fa contro numbe each. rig you ne A Gin this how m
CRAIG’S car is a little different from the others in that it still runs a carby – a gigantic SV1 single-barrel – and will be running copious amounts of nitrous as well.
“I’m logging O2, rpm, tailshaft speed, fuel and nitrous pressure. The carby is similar to tuning a Holley HP carburettor with the extra air bleeds and stuff like that. I have to tune it the old-school way by changing jets, but using the data I get from the O2 sensors. At least with the data, every time I make a change I’ll be able to see what the change did; I don’t necessarily need to go to a dyno.
“I still like to use dynos as a tool, but the Racepak will do that as I run down the track. My ignition is an MSD Power Grid, which is computer-controlled and plugs into the Racepak. There is a lot of adjustability in that, and I’m just scratching the surface as to what it can do. The Racepak logs the ignition map as well as all the other sensors.
“I’ve got the same logger that the Doorslammers use. You can even plug a GoPro into it and sync the footage with the data, and take footage from a start-line camera and sync that.
“I was unsure about putting it on my car but I got talked into it by the guys at ITP Race Cars. I asked if my car was at that level, and they just said: ‘Dude, you’ve got a race car.’ Anyone who has a race car without having some sort of logger on it is wasting their time. If something’s not quite right, you’re not going to know.”
THE left graph here shows the rpm at the top and the lambda sensors (air/fuel ratios) at the bottom. The green line at the bottom is the mixture aim – what you actually want. This is just a channel the ECU datalogs so you always have a reference as to where the mixtures should be. The aim mixture is usually known from experience or actual testing on the dyno as to what is best.
If the actual mixture (as shown by the sensors) deviates from the green line – it’s richer in this case – it means you are not at your optimal mixture and something should be done.
The right graph shows that the mixtures have been adjusted, although there is a little bit of a rich spot at 4000-4500rpm that should be fixed. You will also notice that there is some lambda-bounce on the gear change. You probably won’t smooth that out completely; the engine is being forced to a lower rpm extremely quickly.
You will also notice the jagged nature of the lambda traces; we have them logged at 50 times a second, so you can see the kind of pulsing you get in the exhaust system. s