Originally Posted by scheides (Post 314263)

Monday update, the part throttle cruise either has gotten worse or I'm noticing it more. I am going to turn my async table back down to stock and see if that makes it better or if the increments I made to the EGR timing advance table make any difference either (I'll try that next).

I unplugged my stock MAS/MAF tonight w/o issue. No CEL, no stumble (did it while car was running), nadda, just plain awesome! Does anyone know if the MAF Scaling and associated tables actually do anything anymore?

Originally Posted by Kracka (Post 314278)

How do the EGR settings play into all this? I'm a bit lost on that considering you don't even have EGR on your car.

Originally Posted by mrfred (Post 7747203)

I've been putting some time into trying to figure out this issue, and there are a couple of areas where I can provide some clarification:

1) You guys may already know this, but the name "MAF filter" is somewhat of a misnomer. This value is used to calculate a weighted running average between the old master load value and the newly calculated master load (from the MAF). The formula goes like:

MasterLoad = [MAFfilter*MasterLoadOld + (256-MAFfilter)*MasterLoadNew]/256

2) SD master load is inserted in place of MAF master load further down in the master load calculation subroutine, so SD master load is not affected this weighting calculation, and thus any changes in the "MAF filter" value have no effect on the SD master load.

However, in looking a little further just now, I do see that there is a flag that gets set at the end of the subroutine where the weighting value is determined. The value of the flag is dependent on whether the weighting parameter is above or below 200. This flag doesn't affect the master load calculation, but it does affect some of the calculations for the fuel pulse width. This is the best candidate that I've seen for causing the jittery IPW issue. I'll see if I can look at it further this weekend and perhaps come up with a patch to test it.

EDIT: Having thought about it a little more, it should be pretty easy to test this. We can create a 1D table for the over/under value, and then set the over/under value to 255. Another over/under value to try would be 0. This value is below all the possible weighting parameter values. For the 9653 ROM, the address of the over/under value is 0x162C. Its a word length value, so use uint16 for the scaling.

Originally Posted by mrfred (Post 7756704)

You are welcome to use either fix if you are not having any driveability issues. Here's a rundown of the situation:

For uncompensated loads of < 70, the FPW calculation subroutine wants to use the following formula to scale the base fuel pulse contribution to the total fuel pulse:

BFPW scalar = (MasterLoadW +/- C*DeltaMasterLoadW)/2048

where "+" is used when the load is increasing the "-" is used when the load is decreasing. The "W" means the values are scaled by the fuel pulse width warmup up compensation table, aka MAFMULTWARMUP.

When uncompensated load is >= 70, then the code wants to use this formula for the base fuel pulse scalar:

BFPW scalar = MasterLoadW/2048

For reasons that aren't clear to me yet but are surely in the details of how the master load is calculated in low load conditions, a car in MAF control seems to do ok with this scenario, but a car with the SD patch does not like the DeltaMasterLoadW contribution.

Here is what the first fix does:

1) It forces the code to use MasterLoadW/2048 at all times for the base fuel pulse width scalar.

2) It changes the method for calculating the min load change needed to induce a SyncLoadAccel contribution to the total fuel pulse width. Compared to the factory setup, at low loads, the min load change required is increased, and at high loads, the min load change required is decreased. Thus the car may have a little more hesitation during load change at low loads (below 160 load), and may be a little richer during load change at high loads (above 160 load).

The second fix just forces the use of MasterLoadW/2048 at all times.

Without knowing how much SyncLoadAccel contributes to the total fuel pulse width, the second fix seems the safer route to go. However, if you are happy with AFRs during load transitions when using the first fix, then its ok to use.

What ultimately may be the best solution could be the use of the second fix in combination with access to the tables that control the min load change required to induce a SyncLoadAccel enrichment contribution. These min load change values for SyncLoadAccel contributions may be causing the jittery response that you feel with the second fix. I plan to post those tables in my advanced fuel control options thread later this week.