Fuel trims on stock intake/injectors
Fuel trims on stock intake/injectors
I noticed yesterday that my fuel trims are pretty far off and it's throwing off my tune. I'm on the stock airbox and filter as well as injectors. Now, my air filter is a little dirty and I'm assuming that's the reason. Has anyone else experienced this?
The trims are around +14% low, +6% mid and 0% high. I've got just under 12k on the car and I'm on the stock paper element filter.
While checking this and another car yesterday I noticed something odd in the ECUFlash definitions ... the MAF scaling values for the IX v.15 ROM are set as uint8 and max out at 255 (as expected with an 8bit value). The VIII v.08 ROM has these values set as AirFlow8 (g/s) and that table maxes out at ~376.
In the MAF scaling tutorial there is a random +140 value added to the uint8 value in the % of offset calculation ... is this to make up the difference between the uint8 value and the AirFlow8 (g/s) value? And, if so, would that change the correction formula for the XIII to omit the +140 value?
I simply changed my MAF Scaling values to AirFlow8 scaling ...
The trims are around +14% low, +6% mid and 0% high. I've got just under 12k on the car and I'm on the stock paper element filter.
While checking this and another car yesterday I noticed something odd in the ECUFlash definitions ... the MAF scaling values for the IX v.15 ROM are set as uint8 and max out at 255 (as expected with an 8bit value). The VIII v.08 ROM has these values set as AirFlow8 (g/s) and that table maxes out at ~376.
In the MAF scaling tutorial there is a random +140 value added to the uint8 value in the % of offset calculation ... is this to make up the difference between the uint8 value and the AirFlow8 (g/s) value? And, if so, would that change the correction formula for the XIII to omit the +140 value?
I simply changed my MAF Scaling values to AirFlow8 scaling ...
He was seeing the AFR change based on trims, and yes I'm seeing the same thing. the big thing here is that my intake and injectors are completely stock. Why are the trims off that much?
Post a screenshot of your high octane fuel, just to feed my curiousity. Ive seen mine at different numbers too, but it generally is when Im mid-tune and havent finished it yet. Alot of times I'll do a few logs going to work, play with the map, then log on the way home. So maybe its not liking what your running in your octane map. You have a wideband right TB? What are you at peak torque thru redline?
12.8 - 12.6 at spool up
~ 11.5 from 3500 to about 5000
taper to 10.9 or so at 7000
Lean Spool is disabled.
With your method 20, you are resetting the trims before your logs on the way home. My AFRs are solid right after the flash ... I just noticed this yesterday. i haven't logged or flashed for a couple of weeks ...
~ 11.5 from 3500 to about 5000
taper to 10.9 or so at 7000
Lean Spool is disabled.
With your method 20, you are resetting the trims before your logs on the way home. My AFRs are solid right after the flash ... I just noticed this yesterday. i haven't logged or flashed for a couple of weeks ...
I was the one who discovered this behavior on the Evo 9. I have logged my Evo and another Evo that have had high trim numbers. Both have a TBE, dropin. The second evo has LICP.
I logged an Evo 8 with TBE, dropin, fuel pump and cams, but it did not behave like the Evo 9s.
There is another Evo 9 that I am tuning that I have not logged the trims on. But my hunch is that the trims will also be high.
I cannot explain why this happens. It could be the better exhaust flow that is triggering the ECU to dump more fuel as razorlab suggested.
The fix is very simple. Just rescale your injectors to 472 or 464 and that should take care of your problem. My injectors are set @ 472 and my trims are @ +/-3 90% of the time. On occasion the LTFT_Lo hits 5 but it goes back to 3.
I logged an Evo 8 with TBE, dropin, fuel pump and cams, but it did not behave like the Evo 9s.
There is another Evo 9 that I am tuning that I have not logged the trims on. But my hunch is that the trims will also be high.
I cannot explain why this happens. It could be the better exhaust flow that is triggering the ECU to dump more fuel as razorlab suggested.
The fix is very simple. Just rescale your injectors to 472 or 464 and that should take care of your problem. My injectors are set @ 472 and my trims are @ +/-3 90% of the time. On occasion the LTFT_Lo hits 5 but it goes back to 3.
My intake and injectors were also stock when I first noticed this. They were and ARE still stock now. Unless you re-scale your injectors down to 472, you will have this problem.
Trending Topics
Post a screenshot of your high octane fuel, just to feed my curiousity. Ive seen mine at different numbers too, but it generally is when Im mid-tune and havent finished it yet. Alot of times I'll do a few logs going to work, play with the map, then log on the way home. So maybe its not liking what your running in your octane map. You have a wideband right TB? What are you at peak torque thru redline?
1. Flash your ECU
2. Do a log and save the AFR
3. Drive the car for at least two days
4. Do another log WITHOUT flashing the ECU
5. Check your AFR. If it is richer from 3-6K than before, then do number 6
6. Check your fuel trims and you will find the low trim @ 9-10 and the mid trim @ 8-9
That is the only way to find out if you have the "Funky AFR Syndrome."
It happened the same way with me. I flashed the car and then did not log for two days. When I logged again the AFR was richer in the 3-6K rpm range.
While checking this and another car yesterday I noticed something odd in the ECUFlash definitions ... the MAF scaling values for the IX v.15 ROM are set as uint8 and max out at 255 (as expected with an 8bit value). The VIII v.08 ROM has these values set as AirFlow8 (g/s) and that table maxes out at ~376.
In the MAF scaling tutorial there is a random +140 value added to the uint8 value in the % of offset calculation ... is this to make up the difference between the uint8 value and the AirFlow8 (g/s) value? And, if so, would that change the correction formula for the XIII to omit the +140 value?
I simply changed my MAF Scaling values to AirFlow8 scaling ...
In the MAF scaling tutorial there is a random +140 value added to the uint8 value in the % of offset calculation ... is this to make up the difference between the uint8 value and the AirFlow8 (g/s) value? And, if so, would that change the correction formula for the XIII to omit the +140 value?
I simply changed my MAF Scaling values to AirFlow8 scaling ...
Please keep us posted if the change from "units" to "g/s" corrects your trims. If it does not, then try 472 injector scaling and see how this works for you.
Changing to g/s doesn't make a difference. It's still the same 8-bit value just displayed differently. The only issue I see is the MAF scaling correction formula I mentioned in the first post. Adding the 140 value in to the calculation makes a sizable difference in the corrected value.
Basically, I'm saying that the MAF scaling correction formula should be ...
VIII
(g/s value * trim %) + g/s value = new g/s
OR
IX
(8 bit value + 140 * trim %) + 8bit value = new 8 bit value
You follow? If you take the higer g/s value from a VIII ROM and follow the MAF scaling tutorial you will over correct for the trims. I personally think that the AirFlow8 (g/s) value is the correct scaling for that table and it should be changed in the IX ROM.
Basically, I'm saying that the MAF scaling correction formula should be ...
VIII
(g/s value * trim %) + g/s value = new g/s
OR
IX
(8 bit value + 140 * trim %) + 8bit value = new 8 bit value
You follow? If you take the higer g/s value from a VIII ROM and follow the MAF scaling tutorial you will over correct for the trims. I personally think that the AirFlow8 (g/s) value is the correct scaling for that table and it should be changed in the IX ROM.
Last edited by TouringBubble; Aug 6, 2007 at 07:50 PM.
For example,
(200 [load 2304] + 140 * 14% [your max LTFT_Lo]) + 200 = 219.6
Is the example above correct? The issue is your using the 14% trim as a constant, but it is a variable. Yours was @ 14% now, but it could be @ 9% tomorrow. For instance, I started my car this AM and I have not driven the car for 24 hours. My trim were re-set to 0%. By the time I got to the on-ramp that is 8 minutes from my house my LTFT_Lo was @ 5%. Then it went down to 3% and settled there.
If I am reading you correctly you are going to use the 14% for all of the load cells in the MAF scaling table. Am I wrong?
(200 [load 2304] + 140 * 14% [your max LTFT_Lo]) + 200 = 219.6
Is the example above correct? The issue is your using the 14% trim as a constant, but it is a variable. Yours was @ 14% now, but it could be @ 9% tomorrow. For instance, I started my car this AM and I have not driven the car for 24 hours. My trim were re-set to 0%. By the time I got to the on-ramp that is 8 minutes from my house my LTFT_Lo was @ 5%. Then it went down to 3% and settled there.
If I am reading you correctly you are going to use the 14% for all of the load cells in the MAF scaling table. Am I wrong?
Well, I just typed a big thing about the scaling correction and my browser closed before posting .. nice.
Anyway, I'm not using the correction % as a constant. I get the correction % from the trim sum and I include an average of the O2 Feedback Trim value as well.
I just did seom math and found that the difference between the 8 bit value and the g/s value doesn't really change the results of the scaling formula much. The g/s result seems to be about 5 g/s lower than calculating the correction in 8 bit and converting to g/s. That shouldn't matter much at all.
Anyway, I'm not using the correction % as a constant. I get the correction % from the trim sum and I include an average of the O2 Feedback Trim value as well.
I just did seom math and found that the difference between the 8 bit value and the g/s value doesn't really change the results of the scaling formula much. The g/s result seems to be about 5 g/s lower than calculating the correction in 8 bit and converting to g/s. That shouldn't matter much at all.
Last edited by TouringBubble; Aug 7, 2007 at 05:16 AM.






