http://forums.evolutionm.net/7753333-post44.html
fix#2:
Code:
<table name="Scaling Factor for Transition Load" category="Speed Density Programming" address="1630" type="1D" level="1" scaling="uint16"/>
Put fix#1 back to 205 (or leave it stock if you haven't done it yet) and set fix#2 to 0.
fix#1 was SOOO SMOOTH it left my car feeling like a caddie! I was initially so impressed, I was blinded by the fact that what this fix did was actually make the car lethargic under 160load. It's too bad, because it was so nice
Fix#2 brings back quick response and leaves the car nice and smooth, probably the best solution for 99% of everyone that would want to try this and not touch any other tables.
Here's an excerpt from mrfred about what the two fixes do:
Quote:
Originally Posted by mrfred
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.
|
I'm going to run on fix#2 for a few days, see how I like it, and go from there. Might try a combo of the two or maybe dig deeper, but for your basic bang/buck speed density setup, fix#2 (Scaling Factor for Transition Load=0) is IMHO the way to go.