So I've been communicating with Tunercat on AE and the outcome was he added some parameters for AE on $8D and $DA3. Wanted to get some thoughts here...

Max AE pulse width on $8D is set to 5.5 ms in ANHT, AXCN, AUJP, AWFU, etc... probably the same for most 7730's.

It's set to a whopping 15 ms on $DA3! Almost triple the $8D value.

I'm going to try to input 15 ms into my calibration and see what effect it has.

It begs the question in my mind... can you ask too for "too much" AE fuel on the delta TPS, delta MAP, etc... and then get cut off at the knees by this max AE pulse width? For example, in $8D, if all of your AE settings want to see the ECM deliver an asynch pulse width of 8 ms at a given operating condition, then this max allowed value essentially truncates the pulse width down to 5.5 ms? At that point, no matter how much more AE you program in, you don't see any increase?

Another thing that came out of the Tunercat updates...

The LT1 AE filter coefficient is set to .141 across the board. It's a constant in the fueling constants in $DA3 (as opposed to the table in $8D with .063 everywhere). I'm still vague on what this filter coefficient thing does... but given what we know about Minirams/LT1s and their need for AE, does this make sense that GM would over double the coefficient? I'm going to try the .141 value as well...

Thoughts?

Appears to be that way. The max AE PW check is done at the very end of the routine.

Part of my answer depends upon how the filter coefficient is converted via the TDF file. If using the actual value from the BIN with no conversion, a larger value will produce a lower delta TPS value.

Which translates into a smaller AE pulse width and a faster decay of the delta TPS value.

RBob.

Hmmm, I'm not sure. I'll have to ask Tunercat.

The interesting thing is with that max pusle width, folks who are struggling with Minirams and not being able to get enough AE may be fighting a losing battle against this one parameter!

What happens if u are using larger injectors?

Wouldn't the injector constant normalize for that?

The same time frame w a larger injector would certainly flow more fuel.

Understood, but this Max Async Pulse Width is a maximum value allowable by the ECM. Basically a limit on how much Async AE it will deliver.

If you never bounce off this ceiling during engine operation, you'll never know the difference. However, what it sounds like is if your $8D engine wants more than 5.5 ms of Async Pulse, you're not going to get it... you have to raise the maximum allowable.

RBob, is there an overarching formula that takes all the AE values and computes the commanded pulse width for a given delta TPS and delta MAP?

You can go through the code and see what it does, then put together the math for it. I don't have that for the $8D code.

RBob.

Some items for consideration. The AE being discussed here with a limit of 5.55ms is TPS AE (the asynchronous AE) enabled any time TPS% increases by 1.17% in a 6.25ms period. There is also independently MAP AE which is based on similar changes in MAP, is unlimited and which is added to BPW in the Fuel Out Routine.
As stated, the upper limit of 5.55ms is in fact strange because TPS AE can be upwardly adjusted by 3 possible items regardless of whether or not forced to 5.55ms:
- If in DFCO-Stall Saver, 3.90ms is added
- If A/C is detected on the 1st pass through the Asynch Fuel Out routine while in TPS AE, 1.95ms is added
- A battery voltage adjustment is always added whether or not there is any TPS AE PW (13.5v = 0.70ms addition)

There appears to be no reason to restrict TPS AE to 5.55ms before the above add-ons; so if needed, the 2-byte calibration constant at 0x532 can be changed. Factory GM setting is 0x016C = 364d * 0.015259 = 5.55ms

In $8d, this starts TPS AE:Once in TPS AE, must have the following to continue it if < 75ms since started:

Quote:
The LT1 AE filter coefficient is set to .141 across the board. It's a constant in the fueling constants in $DA3 (as opposed to the table in $8D with .063 everywhere). I'm still vague on what this filter coefficient thing does... but given what we know about Minirams/LT1s and their need for AE, does this make sense that GM would over double the coefficient? I'm going to try the .141 value as well...

In $8d, the 0.063 filter coefficient in the table at 0x56B is used to lag filter old lag filtered TPS% 6.25ms ago with current TPS%. The lag filtering results can be seen in the table below. In decimal: NewValue = OldValue + ((NewValue - OldValue) * Coefficient):

Lag Filter,,,,,Old Lag Filtered,,,,Current,,,,,,,,New Lag Filtered
Coefficient,,,,TPS% 6.25ms Ago,,,,,New TPS%,,,,,,,TPS% Change in 6.25ms
$10=0.063,,,,,,$40=25.00%,,,,,,,,,,$50=31.25%,,,,,$41=25.39%(-5.86% change)
$10,,,,,,,,,,,,$50=31.25%,,,,,,,,,,$40=25.00%,,,,,$4f=30.86%(+5.86% change)

$24=0.141,,,,,,$40=25.00%,,,,,,,,,,$50=31.25%,,,,,$42=25.78%(-5.47% change)
$24,,,,,,,,,,,,$50=31.25%,,,,,,,,,,$40=25.00%,,,,,$4d=30.08%(+5.08% change)

$60=0.378,,,,,,$40=25.00%,,,,,,,,,,$50=31.25%,,,,,$46=27.34%(-3.91% change)
$60,,,,,,,,,,,,$50=31.25%,,,,,,,,,,$40=25.00%,,,,,$4a=28.91%(+3.91% change)

After lag filtering, if the TPS% change in 6.25ms is increasing, the new lag filtered TPS% is saved. If the 6.25ms TPS% change is decreasing, the current TPS% is saved. Then the difference between the saved value and the current TPS% is compared against the TPS% change constant at 0x537 (1.17% = GM Factory calibration). If the difference is > 1.17%, TPS AE is enabled for the first time or maintained.

So a larger coefficient results in a smaller lag filtered TPS% change in 6.25ms. When compared against the threshold of 1.17%, a larger coefficient lessens the opportunity of the difference exceeding the threshold (1.17%). So to invoke or continue TPS AE more easily, either the table values can be decreased below 0.063, and/or the threshold of 1.17% can be decreased. With a lower coefficient, the TPS% difference will be larger. With a threshold < 1.17%, the barrier to enter/maintain TPS AE will be lower.

FWIW, the attachment describes the details of $8D TPS AE and MAP AE.

Holy smokes... that just went over my head at 10,000 ft... going to have to spend a lot of time trying to digest that....