The 3d table is a multiplier of IPW, not a divider. The next thing I would suggest rechecking is the scaling of the baroiat axis.

 

A fairly healthy enrichment w/ temp is a great safeguard against not only knock, but also helps keep coolant temps under control.

At a fixed AFR, exhaust gas temps go up with increasing ambient temp. Higher EGT puts more heat into the cooling system. Retarding timing (to control knock) compounds this problem, sending EGTs up and up, sending coolant temps up, making the engine more knock-sensitive, which requires more timing to be pulled... death spiral.

Something to consider...

 

Good point, I agree. However, this is just about making it adjustable for those that want to adjust it, with some reporting huge offsets. What they put in is up to them. Personally I'm happy with the stock settings.

I've gone through these routines and although there is no sensible way of putting in the axis into Ecuflash, the temperatures from left to right at 101.5 kPa are -32C, 26C, 76C, (115C). The last one in () because at this baro you can't actually reach the 4th column.

With interdependence on other tables you can't sensible change this axis either, but the first three columns should be useful and cover the usual range of IAT.

 

Eureka!

Ahhh... so you're saying lower temp is on the left and higher temp is on the right?? That would make sense. Not only does that make sense for these to be IPW multipliers but also it makes sense that the OE settings would try to decrease IPW in low density situations and increase IPW in high density situations.

Are you sure there is no way to make the X-axis read "-25F, 78F, 168F, 239F"? Is there some way I can just write a static x-axis that does not actually reference the real data? I really wish I could do this stuff on my own, but alas, we must all have our weaknesses.

Eric (lr299gst)?

 

There are ways to hard code/label things.

I wouldn't use this table for tuning personally!

I'm now convinced we should use air temp one you've shown instead.

 

Those values aren't linear, so I'm not sure if jcsbanks just gave rough numbers or not.

But, if you want to create a scaling like I did for you before, it's pretty easy. The decimal values in the ROM for that axis from left to right is 34, 50, 66, 82.

Just plot that as the X axis and the temps as the Y axis in Excel and add a trendline. The equation of the line is your scaling equation.


Eric

 

I looked through everything as well and have corrected the entries. I'll post them later today.

 

lol, you gurus need to agree on something!! Someone needs to fully understand how all these interact and be able to describe it in a simple way with pictures for each one.

 

This is a particularly tricky table to understand, never mind explain.

The numbers I gave should be pretty close. It goes through a few tables to get there and is unconventional in the way it is calculated.

 

The output value is straightforward. Its the air temp / baro factor that is tricky to explain. In looking at it again, I realize that the horizontal axis is a relative air volume rather than a relative density. Strange that its done as a volume.

 

The baro bit is easy, the weirdness is in the air temp. From IAT it is converted to TEMP_COMP_ARG1 (not linear), then converted to TABLE_ARG1 (not linear), then finally the usual table look up.

Since neither of the transformations are linear, and neither are real units, I struggle to find a way to automatically calculate the axis using Ecuflash. Hence I worked back from the final table to find the breakpoints I posted for temperature. I suppose you could show each stage as a separate table, but that doesn't produce an easy to understand temperature.

Are we on the same page? Do you get the same temperature values as I do?

I can't remember seeing this process before where nested maps are looked up simply to calculate an axis. It is very weird, and I don't think it reduces to volume. It is a value that is related to IAT and moves in the same direction but non-linearly, and is inversely proportional to baro. I think originally it is designed as a minor factor to compensate for electronic drift of the MAF sensor itself.

 

One thing I realized today is that I had been working from a bad definition. In my previous work, didn't realize that the IAT comp table definition has the {flipy="True"} modifier which was reversing the pairing of the IAT input values and the table output values in ECUFlash. I also realized that the definition points to a coolant temp input axis instead of the an IAT input axis. Once I fixed those things, then I get a nearly linear relationship between IAT and the output.

This output value from that 2D IAT table is divided by baro, and since air volume (for a fixed number of molecules) is proportional to T/P, it seemed reasonable to conclude that the horizontal axis input to the 3D IPW correction table is proportional to an air volume.

 

They are not wildly off linear, but how do you account for the double (nested) lookup of the temperature? I can see what you mean about volume.

 

Not sure I follow exactly your point. I see one of the inputs to the 3D IPW correction table not as a nested air temp divided by baro, but has a relative air volume. The indirect use of IAT does however make it undesirable to try to represent that axis input into the 3D table in terms of temperature units (even though it can be done) because any changes to the 2D rel air vol vs IAT table would render the scaling incorrect. That's why I've been resisting requests to produce a scaling in terms of temperature. Perhaps that is what you mean?

 

I suppose we end up with something unitless or with arbitrary units then? It doesn't make it very useful as a tuning table, but then I don't think it is designed to be. I expect it was populated based on some characteristic of the MAF sensor at low flows that someone thought needed to be compensated. I wouldn't attempt to intelligently tune this table except to fill it with 0x80 (along with the MAF smoothing table) to disable it when the MAF goes in the bin