Inconsistent Injector PW at WOT?

[90Vette]

$8D, 1227727 (basically 1227730) ECM.

I'm tuning WOT VE using my wideband, and I noticed that my AFRs are pretty inconsistent. For example, in one evening I had three WOT pulls, and in three identical cells (5250rpm, WOT) the datastream reported a target AFR of 0.830 (12.2). However, my wideband measured AFRs of 0.762 (11.2), 0.794 (11.7), and 0.857 (12.6). I looked at injector PW, and they're significantly different - 7.2, 7.3, and 6.8ms, which correspond with my wideband readings.

How is this possible? I understand many factors go into fuel calculations, but almost all of those should be reflected in target AFR. I can't think why injector PW wouldn't correspond with target AFR for a given VE cell. BLMs are slightly different (which I don't get, because BLM learn should be disabled in PE mode), but their differences are minor (133, 128, 129) and don't correlate with the injector PW differences. The third sample is at a higher coolant temp (101 vs 88 for the first two) and a lower air temp (35 vs 60 for the first two). However - again - fueling changes related to CTS/MAP should show up in target AFR, I'd think.

The only thing I can think of that might affect injector PW without affecting target AFR is acceleration enrichment. I've been trying to read up on that (thank you to 84Elky for the amazing summary document!), but it's pretty heady. At any rate, the latter two data points are both about 5-6 seconds into the acceleration run, so I'd think AE would have died out by then.

What am I missing?

I've attached an Excel sheet with the WOT data from the two runs. The 5250rpm rows are bolded.

[90Vette]

I've gone back and taken a slightly more rigorous look at the data. In addition to my comparison at 5250 RPM, I've compared at ~3600 where PE AFR is slightly different. Rather than relying on the reported RPM, I've calculated it myself using the time between distributor reference pulses. I've also used that and the MAP along with the VE table to interpolate the exact VE (assuming my memory is correct that the ECM uses bilinear interpolation) for that datapoint. To account for slight differences in RPM and MAP, I've normalized the injector BPW by dividing by the VE. If this doesn't make sense, I can explain why I did this.

Even after all this, we see a major difference (~10%) in injector BPW. I've attached the updated spreadsheet, and a plot is below.
Injector BPW plot.png


To nutshell the root of the issue: why would two points with the same VE and the same target AFR have different injector BPWs (and therefore different AFRs measured by wideband)??

After digging through AE documentation a little more, I see that TPS AE is added in the asynchronous fuel out routine, which (I think) isn't reflected in injector BPW. That leaves MAP AE - maybe I'll amp up the decay rate to see if that makes it more consistent, although it seems like MAP AE should have decayed in well less than a second.

Is there anything else that drives injector BPW but not target AFR? Does anyone know how the ECM calculates target AFR for the datastream?

[90Vette]

I stumbled back across the Thirdgen Prom Tuning Guide Book - what a resource! I need to not forget about it again.

And what do you know, in chapter 5, under the 7730 ECM, there's a topic titled "P730: BPW and Target AFR, how it is used and calculated at WOT in PE Mode". Perfect!

Curiously, the author states that target AFR is only a factor of stoich and the two PE modifiers (temp and RPM). Either I'm missing something big, or this statement isn't quite true, as the target AFR is clearly less than stoich on a cold start when I'm not in PE. I'll skip over this inconsistency for now. Later, the author describes how injector BPW is calculated - it's (grams of air per cylinder)/((target AFR)*(injector flowrate)). Target AFR and injector flowrate are hardcoded into the tune, but grams of air per cylinder is a function of MAP, EGR partial pressure, cylinder volume, VE, and MAT. Cylinder volume is fixed, VE is fixed, and MAP is essentially constant at WOT.

However, I can't believe I didn't think of MAT before! My first two runs, which had the same MAT, still don't perfectly agree (avg norm BPW of 8.88 and 9.12), but the big outlier is the third run with an avg norm BPW of 8.39*. There's still something here I don't understand, but it makes sense that MAT is a big factor. Apparently there's a lookup table that goes into figuring out the MAT's contribution to cylinder air mass. "MAT Compensation Counts vs. MAT" (0x7FD / L87FD for my bin). My XDF gives no description, so now to dig a little deeper to figure out what this does and how to calibrate it.


*I realized I wasn't accounting for the slightly-different BLMs in the three runs (133, 128, 129). I think multiplying by an additional factor of 128/BLM truly normalizes BPW for the purpose of this comparison.

[90Vette]

Okay, looks like there are two relevant tables: MAT Inverse Term Lookup Delta Mult. vs. Airflow and MAT Compensation Counts vs. MAT.

I'm trying to wade through all the math on how each plays a role, but holy crap is it complicated. Here's my best understanding:

MAT Inverse Term Lookup Delta Mult. vs. Airflow
Independent variable: airflow in g/s
Dependent variable: dimensionless multiplier

As I understand it, this multiplier defines how MAT and CTS are combined for a given airflow. For example, at a very low airflow, the coolant temp will have a larger effect on air temps inside the cylinder. At a very fast airflow, there's less time for the coolant temp to heat the air, so MAT will be more heavily weighted. According to RBob over at Thirdgen (cleaned up a bit):
T = MAT + ((CTS - MAT) * MULT) / 128

In other words, the effective air temp is defined as (MAT) plus (difference between CTS and MAT) times (multiplier from this table) divided by 128. FYI, your XDF might be doing the division for you - if it shows decimal numbers, it probably is (e.g. mine goes from 1.000 to 0.125 in the lower cells).

It seems super backwards that this table is based on airflow in g/s, as to get mass flow you need a temperature adjustment (using MAT!) first.

MAT Compensation Counts vs. MAT
Independent variable: MAT in °C
Dependent variable: dimensionless counts

This takes the temperature from the above calculation using the first table and spits out a "count" that can be used to calculate air mass per cylinder. This calculation takes the form of (again, from RBob):
GMS of Air / CYL = ((MAP - EGR) * INV MAT) * VE

where MAP is manifold pressure, EGR is some value quantifying the partial pressure of EGR gas, and VE is the volumetric efficiency. INV MAT is the temperature adjustment, and it's calculated according to:

INV MAT = CYL VOL/((MAT + 233) * 128)

where MAT is the temperature from the compensation count lookup table. Confused yet? I know I am.

Combining the above two equations just to trace the effect of MAT counts:

GMS of Air / CYL = ((MAP - EGR) * CYL VOL/((MAT + 233) * 128)) * VE = 1 / (MAT + 233) * (MAP - EGR) * CYL VOL * 128 * VE

Injector PW is proportional to GMS of Air / CYL, so PW = 1 / (MAT + 233) * C, where C is all of the other multiplied factors.


I'm reading that the inverse term lookup is the table to modify if you've relocated your MAT (as I have with my Superram intake). However, my AFR error appears to be RPM-independent and is a factor only of MAT reading. It makes sense that I could just change the MAT counts to get my PWs back in line, but there must be a reason people say not to mess with those values.

Hmm. Gonna need to think about this a bit.

[90Vette]

My current best guess is that the inverse MAT g/s column is calculated using VE, RPM, ideal gas law, and the raw MAT value (not the weighted MAT-CTS value).

If this is the case, my workaround for over 100% VE could be an issue. (I reduced injector flowrate and VE values by 10% each.) While this effect cancels out in the fueling calculations, lying to the ECU about VE will cause it to lookup the wrong cell in the inverse MAT table. For example, if parameters were such that 200 g/s airflow were calculated, reducing VE by 10% would reduce the calculated airflow by 10% as well to 180 g/s, dropping it a cell or two lower in the table. Of course, that's fixable by shifting the values in this table, but it's kind of a hacky solution. And I don't even know if that's the case.

[90Vette]

Over on Thirdgen, RBob explained that it's circular - the calculated airflow from one loop is used in the inverse MAT lookup table in the next loop.

[84Elky]

You raise many complicated issues. Will address as many as possible below:

First and most important: The PW reported in $8d and I believe all other GM masks is NOT the Final PW sent to the injectors. What's reported in the DDS is PW after o2 corrections if in CL, or calculated PW without o2-related corrections if in OL --- all before any other compensations (see below). This is why S_AUJP v6 was changed to report Final PW. Final PW reflects everything in the true PW sent to the ECM to fire the injectors:

Synchronous includes (Normal Injector firing 160 times a second):

• o2 adjusted PW if CL (Factory reported PW)
• PW for AE-MAP, if active, minus a coolant-based fuel limiting adjustment if:
• AE-TPS is Active, or
• 0x045 b6=’AE-TPS-Limit Fuel Out PW Calculation' is ON, or both are set
• Compensation for Low PW if applicable
• PW compensation for Voltage is always be added

Asynchronous includes (fired as needed 160 times a second -- none of this is in Factory reported PW):

• AE-TPS
• Deceleration Fuel Cut Off Stall Saver (DFCO-SS)
• A/C-just-on
• Once the AE-TPS PW component has been computed, if applicable, the following PW may be added:
• 3.90ms PW (0x5EC) is added if DFCO-SS is active
• 1.95ms PW (0x5A4) is added the first time the A/C clutch is engaged (A/C-just-on)
• PW compensation for Voltage is always be added

VE: VE from the tables is always adjusted for barometric pressure at prior key-off or current key-on, whichever is larger. That adjustment at sea level with Factory values from the Table at 0x81F is somewhere between no adjustment to Table value and +3.9%, so have to allow for that when looking at VE. BARO adjusted VE is that used for all fueling-related calculations.

AE: AE-TPS is instantaneous and gone, like a carburetor pump-shot. AE-MAP lasts a little longer, but after the initial PW effect, it's decayed-out fairly quickly so likely little effect on WOT PW/AFR

AFR: Look at the attached document to understand how AFR is calculated. Search for "Compute an AFR". Also, it's important to understand how temperature is used in the PW calculation. Look at the discussion at "How Flag 0x018 b4 Affects BPW". If the stock MAT sensor is not used and is relocated into the intake air stream, it's generally best to set 0x018 b4=0 so the coolant/MAT differential is not considered. Only MAT is used. But if the MAT sensor is in the plenum (factory set=up), you can use the b4=0 setting; but must recognize that the sensor is reporting heat-soaked temp and not the real Intake Air Temp.

Bottom line: PW varies significantly with temps!

HTH, Elky

[90Vette]

That's very helpful, thanks! I've read and re-read your post several times over the past couple of weeks as I've been working through this. I've also revisited various parts of that doc a few times.

Very interesting that AE-MAP is shown in BPW but not AE-TPS. And you nailed it pointing me to BPW, as you have seen on the Thirdgen thread.

Your document indicates that open loop enrichment values modify the AFR when in open loop. However, I'm not seeing that in my datalogs - it seems that startup enrichment shows in target AFR, but that quickly tapers off to show a target lambda of 1 (even when I'm certain the engine still is in OL). Did I misunderstand your document, or am I missing something?

[84Elky]

TYour document indicates that open loop enrichment values modify the AFR when in open loop. However, I'm not seeing that in my datalogs - it seems that startup enrichment shows in target AFR, but that quickly tapers off to show a target lambda of 1 (even when I'm certain the engine still is in OL). Did I misunderstand your document, or am I missing something?

Would like to respond to your question, but am having difficulty relating it to the document. Would you please expand the question or point me to the document page/area so I can review in context.
Tks.

[90Vette]

Would like to respond to your question, but am having difficulty relating it to the document. Would you please expand the question or point me to the document page/area so I can review in context.
Tks.

Yeah, referring to the section "OL NOT in PE AFR" starting at the bottom of page 30. If I understand the logic correctly, the startup enrichment and the open loop enrichment terms (like 0x41F, OL % change at idle) have the same effect on AFR. However, my datalogs show a target AFR of 1 (lambda, so stoich) as soon as the startup fuel tapers out in the first few seconds, despite there definitely being active open loop enrichment. I've changed open loop idle enrichment from 0% to 15%, and the datalog still shows lambda = 1 in open loop despite wideband readings showing a definite difference in actual AFR.

I guess that's probably just an inconsistency between how the code computes desired AFR and what it reports to the datastream?

[84Elky]

Yeah, referring to the section "OL NOT in PE AFR" starting at the bottom of page 30. If I understand the logic correctly, the startup enrichment and the open loop enrichment terms (like 0x41F, OL % change at idle) have the same effect on AFR. However, my datalogs show a target AFR of 1 (lambda, so stoich) as soon as the startup fuel tapers out in the first few seconds, despite there definitely being active open loop enrichment. I've changed open loop idle enrichment from 0% to 15%, and the datalog still shows lambda = 1 in open loop despite wideband readings showing a definite difference in actual AFR.

I guess that's probably just an inconsistency between how the code computes desired AFR and what it reports to the datastream?

I've rechecked the code against what my doc says and the doc is accurate. Also, there is no difference between what the code computes and what it reports. Once an AFR is computed, it is loaded to variable L00F1. L00F1 is then loaded for L00F3 for DDS reporting. L00F1 = L00F3 is the calculated/commanded value unless in OL (where it is Stoich AFR). So still don't understand why you are seeing other values.

To clear this up and to help my understanding, it would be helpful if you could do the following and then post a .csv file exported from TunerPro:
- Begin logging with key off 2-3 seconds
- Turn key on for 2-3 seconds before starting (reported AFR should be your Scalar Stoich value)
-----EDIT: Discovered that this does not occur. At initialization, $8d does not load Stoich AFR to the Mode 1 DDS AFR variable. Only see zero until engine running. Only then is AFR reported.
- Start engine and let run for 15-20 seconds (Computed AFR should reflect startup enrichment, gradually decayed out in a few seconds and then stabilize)
- Stop log
This will show exactly what's happening.

Please also include the .XDL file in case I need to go deeper with my ADX.

Elky

[90Vette]

I've rechecked the code against what my doc says and the doc is accurate. Also, there is no difference between what the code computes and what it reports. Once an AFR is computed, it is loaded to variable L00F1. L00F1 is then loaded for L00F3 for DDS reporting. L00F1 = L00F3 is the calculated/commanded value unless in OL (where it is Stoich AFR). So still don't understand why you are seeing other values.

To clear this up and to help my understanding, it would be helpful if you could do the following and then post a .csv file exported from TunerPro:
- Begin logging with key off 2-3 seconds
- Turn key on for 2-3 seconds before starting (reported AFR should be your Scalar Stoich value)
-----EDIT: Discovered that this does not occur. At initialization, $8d does not load Stoich AFR to the Mode 1 DDS AFR variable. Only see zero until engine running. Only then is AFR reported.
- Start engine and let run for 15-20 seconds (Computed AFR should reflect startup enrichment, gradually decayed out in a few seconds and then stabilize)
- Stop log
This will show exactly what's happening.

Please also include the .XDL file in case I need to go deeper with my ADX.

Elky

Hey Elky,

Sorry for the delay - haven't forgotten about this, my datalogging is just on the fritz. Once I get datalogging and a few other issues sorted out I can get a TP log of startup. In case it helps, here's a CSV log (from ALDL Scan) of startup. It matches your observation that Target AFR is 0 until the engine is running. Otherwise I'll post another log as soon as I can.

[90Vette]

As promised, here's a TunerPro log. It was taken with ALDLDroid, but it should be identical to one taken with TP.

[84Elky]

That log looks perfectly normal. Startup enrichment has been applied and is slowly being decayed-out as time passes. Perhaps I've lost what the issue is.

[stew86MCSS396]

As promised, here's a TunerPro log. It was taken with ALDLDroid, but it should be identical to one taken with TP.

Sorry for the OT post but I can connect just fine with ALDL Droid but using the same ADX, TunerproRT doesn't connect. Care to share any insights or the ADX you're using to quiet the CCM? thanx!