ULTM8Z

In SAUJP, is it possible to re-structure the MAT compensation counts table to use finer divisions of temperature? If so, would anyone who knows how be willing to do it?

It's currently divided up into ranges of 12°C. I've gotten this thing dialed in as far as I can go, but it seems like when I get into a particular temperature range at the low end (say the 8 deg C mark in the 8-20 deg C range) by the time the air temp gets to the high end of the range (20 degC), the fueling is off just enough for me to notice it.

Such that when the air temp gets to 21C, it's a big step function into the next range with the next compensation counts value. In reality, the difference in compensation count value between 20 and 21 C should be small, but the temperature ranges force it to be large.

The problem is you can only tune one compensation count value for a given 12 deg range.

Probably just me being really picky and getting carried away with monitoring the WB output...

The current ranges go 8, 20, 32, 44, 56, etc... seems like if went say, 8, 14, 20, 26, 32, 38, 44, 50, 56, etc.. the jumps from one compensation count value to the next wouldn't be as dramatic. Bascically 6 deg ranges.... The finer the divisions the better (ideally, it'd be just a linear relationship).

Any rate, I know SAUJP modified some other tables like adding higher rpms to the VE table... so just wondering if something similar can be done on the MAT compensation counts table.

34blazer

Bump.......lol


Revisiting this subject because I'm buying back my old mustang with the 730 S_AUJP swap and need to jog my memory as to how I figured out the blend ratio. I remember chasing my tail adjusting the inverse table to no avail and still had a large variance in fuel delivery between cool IAT temps and hot. Im hoping my memory isn't to foggy but it wasn't until I started adjusting the counts table that I was able to keep the fuel delivery consistent, and that was on my fiero which also was running S_AUJP V4.

Have you made any progress with this? I think the counts table was more of a blend table for the IAT/CLT which makes more sense to me to blend more or less of IAT correction than trying to calculate the air density based on heat soaking of the intake tract.

ULTM8Z

Because I'm running a true cold air tube with the sensor no longer mounted in the manifold, I disabled the Inv MAT table altogether. There's no need to blend IAT with CTS readings when the sensor is not in the manifold.

As for the MAT Compensation Counts table, I tuned all of my AFR's and BLM's for one air temperature and then used the MAT tables to dial in the other air temps.

Whereas the factory had a spread of 12 counts between air temperature gradations in , I ended up with only a spread of 3 counts per gradation and frankly (from a seat of the pants feel) I can't really tell the difference in how the car runs between cold days and hot days. It's just sooooo consistent (just like the late models of today).

34blazer

I went back and looked at the fiero bin I was using and found the the inverse table was still being used, I just adjusted the MAT counts table and from what I remember it was fairly consistent. And those has the IAT in the air filter canister away from the engine. I think I'll disable the inverse table like you did and see how it affects the temperature correction. Thanks!

84Elky

This post about the $8d AUJP Table at 0x7FD=MAT or Coolant/MAT Differential Compensation Counts is timely because it’s something I’ve been pondering. To clarify some things about that table and also about the related setting of Flag 0x018 b4:

• If Flag b4=1, a Coolant/MAT differential temperature adjusted based on calculated air flow is used to access the table.
• If Flag b4=0, the temperature differential and air flow are ignored and only MAT is used to access the table.

So the table is always accessed, just with different input values. The “counts” from the table are ultimately used in the Base Pulse Width (BPW) calculation. Very importantly, this says the BPW calculation is always influenced by temperature, whether it’s a Coolant/MAT differential or only MAT.

Here are the important points:

• Regardless of the number of elements in any table, if an input value does not exist in a table, the table will always be linearly interpolated. That means more table granularity has no effect on the output – provided the table data are linear. And all are linear except for MAT, which is accounted for via a non-linear table lookup. There may a rounding of 1 hex periodically because all math is in hex and not fractional decimal, but it’s a non issue.
• BPW is really the only concern because in the end that's what affects a tune (BLMs, Lambdas/AFRs).
• Variation in temperature affects BPW.
• Setting Flag b4=0 results in much higher BPW than if set =1 as the data below reveals. Granted this data is only at 32 gm/sec air flow, but the results are similar at virtually any air flow and Coolant/MAT values.

Effect of Flag 0x018 b4 on BPW (Coolant =200°F, Air Flow =32 gm/sec, Sea Level BARO)
(Results of Code Simulation. BPW is before low PW and voltage compensations)


There are several options for the Flag settings combined with the type and location of the MAT sensor. The option providing the most consistent tune (least changing BPW across a temperature range) is:

• Replace the MAT Plenum sensor with a true Intake Air Temperature (IAT) sensor and relocate it outside the engine compartment to ensure it is not affected by under hood temperature saturation
• Set Flag b4=0

The above data along with one more piece of information supports this conclusion:

• BPW =3.05ms when Coolant and MAT both=32*F (assumes cold start)

Regardless of the Flag setting, the 3.05ms BPW is the same because at 32*F it just so happens that adjusted air flow of 32 gm/sec and a Coolant/MAT differential of zero approximately equals MAT. Seems strange but that’s what happens.

Here are BPW changes from both Coolant and MAT=32*F to MAT=99*F and Coolant=200*F:
Assuming Flag b4=1:

• 21.1% BPW Change = (1 – (3.05ms / 2.52ms)) * 100

Assuming Flag b4=0:

• 11.8% BPW Change = (1 – (3.05ms / 2.69ms)) * 100

This says setting the Flag b4=0 will provide less BPW fluctuation as MAT moves from 32*F to 99*F.

But there are other implications. The rightmost column of the above data shows that with the Flag b4=0 and a perfect tune at 75*F, it will be 4.6% leaner at 99*F:

• -4.6% BPW Change = ((2.69 - 2.82) – 1) * 100

It will only be 2.3% leaner with the Flag b4=1 with the same temperature change:

• -2.3% BPW Change = ((2.52 - 2.58) – 1) * 100

Pick your poison. Can’t get away from the fact that no matter the temperature, it always affects BPW!

84Elky

Would appreciate understanding this a bit further. What table provides or whet changes did you make to get to a 3 count spread?

ULTM8Z

Elky, good write up!

I took the MAT sensor out of the intake manifold a long time ago when I went to the Miniram. But I didn't fully grasp impacts to the air temperature calculation/compensation until about a year ago when it finally dawned on me (after re-reading RBob's years-old thread on MAT vs IAT numerous times) that I had to disable the INV MAT Lookup table.

Since my MAT is actually now an IAT (with the sensor located right at the air filter that I relocated under the battery tray), there's no need to factor in the coolant temperature into the final air temperature calculation (the sensor not being in the intake manifold means that the temperature of the aluminum manifold-- driven mainly by coolant temp-- doesn't come into play). So I disabled that table by unchecking the box for b4 as you describe.

After that, the goal was to tune the MAT Compensation Counts table in order to get consistent BLM's and PE/OL AFR's for all air temps. With my BLM's very close to 128 everywhere at one temp, I tuned the MAT Comp Counts table such that I got the same BLM's at every air temperature (at least the temperatures that I get in SoCal). To tune the AFR for PE, I generated a tool that looks at PE AFR only as a function of air temperature. It takes a standard TP excel export the boils down the AFR as a function of temperature. With this, I made several WOT runs and adjusted the MAT Comp Counts table until I got less than ~-0.25 AFR points between one air temp to another. After that excercise, I ended up with a 3 point spread between temperatures.

By "one air temp to another" I mean the preset air temperature ranges in the MAT comp counts table. At least, I thought it was a range.... I thought it was a step function. That is to say, the factory MAT Comp Counts table looks like this.




For example, at 20C, the counts are 60. At 32C it's 72. I therefore thought that from 20C to 31C, the counts are always 6. Then when the temperature hit 32C, the counts jumped up to 72. But you're saying that the counts will increase linearly from 60 to 72 as the temperature warms from 20 to 32? If so, that answers the question in my original post in this thread, so no action is necessary since the ECM is already doing what I want.

That said, I do have that other thread about whether its possible to have TP generate AFR history tables that ignore AFR when AE is active. It'd be good to see AFR that's purely PE or OL or CL without being "corrupted" by AE which can generate pretty decent, albeit transient, rich conditions.... that would make the general AFR tuning even more accurate.

84Elky

Tks for the detail. The ANHT table you posted is the same as Factory AUJP. And yes, all tables are interpolated linearly such that a 3 item table will provide the same output as a 17 entry table. MAT is only exception. That's why the ADX has a Lookup Table. Bring up the ADX MAT Table in TPro and click on Table Graph, Curve is non-linear due to sensor characteristics. The ADX table is identical to that in the ALDL data stream area of the code, except that the ADX table begins with 1, whereas the code table correctly begins with zero. Too much trouble to change ADX. Does not change the result because everything done in hex.

Regarding the history reporting to exclude AE from AFR calcs, etc., that likely not possible because it would require specific coding just for that condition. But never hurts to post it up on the tunerpro.net forum to see.

Elky

34blazer

Thanks guys! Great information here!