Thoughts on rpm/load based heatsoak compensation

Hey guys,

I've had a few different setups regarding IAT.

Standard MAF with inbuilt IAT (very slow to respond)

MAF replaced with fast response IAT sensor in MAFs place (very fast to respond)

IAT sensor replaced in a low airflow area of an air filter box (same sensor, but back to being slow to respond)

and currently IAT located in the plenum.

What I'm finding is that where ever my IAT sensor is located, it seems to be trying to fulfill two seperate jobs.

Account for the air temperature itself.

And then also account for the heatsoak factor of a hot intake manifold (or not)

Soooo Ive been wondering how to isolate these two things from each other. I think fitting a surface mount thermistor to the intake manifold and then having an external IAT will be best solution. (But I havent done this yet)

However as a brain exercise in the meantime. (Excuse my potentially dodgy maths here)

Lets say that the heat influence from conduction from the engine and engine bay air temp, heats your intake manifold to a consistent 45 degrees when it would otherwise naturally stay at 20 degrees.

Using specific heat value of aluminium and a 5kg intake manifold, that means 135 Joules of energy put into the manifold to maintain that temp.

In order for 135 joules of heat energy to come back out of the manifold (so manifold temp stays the same instead of increasing or decreasing) and assuming that all of this heat ended up into your intake air.

You end up with a HUGE temperature change from heatsoak at low rpm/load conditions, and virtually none at high load/rpm.

Ignore the values here because they arent realistic because you dont get 100% of the manifold heat energy dissipating into the air flow, but I think the ratio of difference that heatsoak makes across this map would be more or less correct:

(The numbers in the graph are temperature in Kelvin, and represent air temperature increase from heatsoak)

I've been thinking that I might make a fuel table overlay that has this ratio of values, (But numbers scaled down hugely) that adds or subtracts fuel based on a surface mount thermistor on the intake manifold.

So lets say I scaled this map down so the maximum value was 100:

Looks as though heatsoak from manifold is only hugely relevant at those lower loads and rpm.

(According to my maths at least, not sure if I believe this)

However it will be interesting to see if I can partition out the actual influence of IAT as IAT alone, and see if it follows ideal gas law any better, and whether "drift" from ideal gas law seems to follow this model above.

Has anyone here tried something like this previously? I know it's splitting hairs when you can just use closed loop lambda for cruising.

Especially when you look where the values are above, it's all low load / low rpm.

But I thought it was an interesting topic for discussion.

Also an interesting point here... The only reason compensation tables like this are required, is because a MAP sensor needs to calculate VE from temperature and pressure. If the car used a MAF sensor that measures grams/sec directly, this is all automatically compensated for. (Which is why OEMs like using MAFs!)

It makes me think some more favourable thoughts about the idea of switching back to one.

Although, having an air leak with a MAF sensor, arrrrgggghhhhhh I dont miss that hahaha.

Apologies if this is getting too nerdy, but I figure you guys are a more interested audience than my mrs or friends at the pub who arent interested in cars or temperature readings or whatever haha.

Thanks

Dave

Here's a few thoughts I'll add for you to consider.

The first point that's often overlooked is that it's the inlet charge temp that is important to the ideal gas law (the temperature of the inlet air as it passes the valves and enters the cylinder) and the IAT sensor doesn't do a great job of measuring this under all conditions (or perhaps most conditions would be more accurate). The issue as you rightly point out is the heat transfer from the intake manifold back into the intake air at low air speed - Actually some amount of heat will also be transferred into the air from the port wall and the intake valves too which is possibly harder to account for.

The most common way of dealing with this if you want to go beyond just using the raw IAT value is with a charge temp approximation table that allows you to bias the charge temperature towards either ECT or IAT depending on the load and rpm (essentially air flow). Motec have gone a little further with this idea in the M1 and also introduced a factor for how much heat is transferred from the intake manifold to the IAT sensor element (basically how much heat soak is influencing the displayed IAT value).

The issue I see is that the more we try to improve the accuracy of the charge temp measurement, the more complexity we add and the harder it is for the average tuner to get the right results. The other factor that you need to consider to improve accuracy of the air fuel ratio across changing conditions is the fuel temperature and hence the fuel density. It's also important to get some perspective on what you should expect to see in the way of error between your target and measured AFR and when I see a current generation factory vehicle with a sophisticated ECU still apply as much as a 15% short term trim in response to a hot restart, I feel better about what I consider to be 'good'.

Please don't think I'm being negative about your idea though, and I'd be interested to hear how it works out for you if you do try applying it.

Hmmm thanks, I dont think you've being negative, it's all good discussion.

I've never seen an OEM car fitted with heatsoak measurement so it may very well be the consensus that it's irrelevant due to only affecting the part of the map where closed loop takes over anyway.

I'd seen the charge temp approximation table but it seemed strange that you'd bias towards ECT because generally "pre heatsoak" my engine temp will be identical to afterwards as well.

I know what you mean about sometimes over scrutinizing things, I've been driving around without a wideband connected for the last few weeks and have noticed absolutely nothing wrong with how the car drives under all conditions hahaha.

Even though I'd probably be annoyed with something if I was looking at the data and fussing over it.

But at the same time, sometimes its interesting to learn even if it's something of little consequence in real world.

I think I'll definitely fit the second temp sensor at some point, if for nothing but interests sake.

I'll post up again in this thread if the results are anything interesting.

Been thinking about this some more, or more generally how to build any sort of compensation table in a meaningful way with minimal fuss or guess work.

So my plan. Turn off all compensation values/tables/etc.

Get the car as heat soaked and high temp as I possibly can, so that the temps of everything are already stable on the "high" side.

Then run through my map and get fuel values spot on as best I can.

Then let the car cool down completely, start it up and start a datalog once the engine temp reaches say 85deg.

The drive around for ages and build up a big datalog file of how the fuel changes over time on account of heatsoak etc.

Then add a 4D fuel table, But with different axes to the main table, and then use mixture map from the datalog to build the results for the overlay table.

So the overlay table axes could be RPM and intake manifold temp sensor readings (if I had one) Or whatever else.

If there's a genuine trend happening, you'll see it in the shape of that overlay map generated by mixture map.

If it's just random spikes up and down, then I'll try something different for the axes and rinse repeat until I find what it is that causes the trend, without having to run the car at all.

Then if this works, I can run the car with that comp table in place and do same thing again to build up the next comp table on top of that for something else (if need be)

I will give this a go some time this weekend, with IAT compensation turned off for starters and see if it comes up with a compensation table that matches what I would expect.