Low RPM Lean Issue on 96531706
Low RPM Lean Issue on 96531706
I've been having some lean misfire issues below 2000 RPM and below 100 load that are most noticeable when the engine is cold However, it does it even when warm, but the 16:1 and leaner AFRs don't cause misfires like it does when the motor is cold.
Using the RAM addresses provided by MrFred/Logic for the sync accel, sync decel subtractor, Total Sync FPW, and Async FPW, I happened to catch a pretty sever event. Attached is the complete log as a .dif file. This can be opened in logworks or in excel. I have also grabbed some screen captures.
To make it more readable, I've split the screen captures into two sets of channels. Here are the items (top to bottom) on the first chart.
Battery Voltage
Mapped AFR
Actual AFR
Engine Temp
1-Byte Tephra Load
Omni 4 bar
Engine Speed
TPS
Airflow
See attachment 1
Here are items (top to bottom) in the second graph
Actual AFR
1-Byte Tephra Load
Total Sync FPW
Injector Pulsewidth
Async Accel FPW
SyncLoadAccel FPW
SyncLoadDecel Subtractor
See attachment 2
The one thing that stands out most prominently to me is the step in Total Sync FPW from roughly 310 to 464 in one sample. Then immediately after, actual AFR drops from 17.5:1 to 12.8:1. That's a 40% change, and yet no change in load or engine speed that would dictate that change.
There is also a lot going on with the sync accel/decel items AT/immediately after this event. Load also goes up after, but it seems like it's more that the car finally started accelerating at that point and let the turbo spool up. Injector pulse width bounces around a bunch immediately after the step too.
What's your thoughts?
Any ideas of other items I can log to track this down?
Using the RAM addresses provided by MrFred/Logic for the sync accel, sync decel subtractor, Total Sync FPW, and Async FPW, I happened to catch a pretty sever event. Attached is the complete log as a .dif file. This can be opened in logworks or in excel. I have also grabbed some screen captures.
To make it more readable, I've split the screen captures into two sets of channels. Here are the items (top to bottom) on the first chart.
Battery Voltage
Mapped AFR
Actual AFR
Engine Temp
1-Byte Tephra Load
Omni 4 bar
Engine Speed
TPS
Airflow
See attachment 1
Here are items (top to bottom) in the second graph
Actual AFR
1-Byte Tephra Load
Total Sync FPW
Injector Pulsewidth
Async Accel FPW
SyncLoadAccel FPW
SyncLoadDecel Subtractor
See attachment 2
The one thing that stands out most prominently to me is the step in Total Sync FPW from roughly 310 to 464 in one sample. Then immediately after, actual AFR drops from 17.5:1 to 12.8:1. That's a 40% change, and yet no change in load or engine speed that would dictate that change.
There is also a lot going on with the sync accel/decel items AT/immediately after this event. Load also goes up after, but it seems like it's more that the car finally started accelerating at that point and let the turbo spool up. Injector pulse width bounces around a bunch immediately after the step too.
What's your thoughts?
Any ideas of other items I can log to track this down?
Last edited by 03whitegsr; Jan 25, 2010 at 02:27 PM.
For additional information, here are my MAPVE and RPMVE tables.
Code:
MAP Load 10.2 6.0 30.9 20.2 41.1 29.8 60.7 48.3 88 71 120.1 120.1 199.9 199.9 399.9 399.9 RPM VE 500 93 1000 93 1250 93 1500 93 2000 93 2500 94 3000 95 3500 96 4000 97 4500 98 5000 100 5500 100 6000 95 6500 94 7000 88 7500 85 8000 82
So, you're on SD...I didn't know that before. That's a big difference. Also, are you on pump gas or E85?
Anyway, looking at your log, your issue seems to be at throttle tip-in. I think you can ignore what happens afterwards, as this is after your issue and throttle is then steady or declining. Your temps are already pretty warm (64F), so I don't think this has anything to do with cold start/running tables.
Have you adjusting any of the tps sync/async tables, especially the one that is mentioned to be adjusted when running SD? IIRC, I think it's called Asynch vs TPSDelta?
I think mrfred has them all explained in the first couple posts of the advanced fuel control thread now. Make sure that you double check any limiting tables as well, such as RPM, TPS, or temp values may limit the enrichment.
Also, you can try retuning your VE tables a bit to give a little more VE with MAP change at the same RPM. When you press the throttle, the VE is changing, while the RPM is staying the same. Idle may be 60% VE, but when you rev the engine or apply throttle, it may be jumping to 80% or so, for example. It's look like you are somewhat doing that already though, so your tables may be OK. To be sure I would have to know what RPM and map you idle at.
Anyway, looking at your log, your issue seems to be at throttle tip-in. I think you can ignore what happens afterwards, as this is after your issue and throttle is then steady or declining. Your temps are already pretty warm (64F), so I don't think this has anything to do with cold start/running tables.
Have you adjusting any of the tps sync/async tables, especially the one that is mentioned to be adjusted when running SD? IIRC, I think it's called Asynch vs TPSDelta?
I think mrfred has them all explained in the first couple posts of the advanced fuel control thread now. Make sure that you double check any limiting tables as well, such as RPM, TPS, or temp values may limit the enrichment.
Also, you can try retuning your VE tables a bit to give a little more VE with MAP change at the same RPM. When you press the throttle, the VE is changing, while the RPM is staying the same. Idle may be 60% VE, but when you rev the engine or apply throttle, it may be jumping to 80% or so, for example. It's look like you are somewhat doing that already though, so your tables may be OK. To be sure I would have to know what RPM and map you idle at.
Last edited by l2r99gst; Jan 14, 2010 at 06:19 AM.
OK, I did a couple of quick calcs on your VE right before and during your trouble area.
I didn't open the log in LogWorks yet, so going by your screenshots, it looks as if these are the conditions before and during your issue:
55kpa 1000 RPM - 72% VE (before issue)
90kpa 1250 - 75% VE (during issue)
You are idling at 55kpa/1000RPM, with a calced VE of 72% (calced from your VE table settings). Then you increase TPS to roughly 90kpa at that same RPM range...naybe increasing slightly to 1250. The calced VE now is 75%.Well, that's only a 3% change. Looking at some of my old maf logs, I have about a 15% change in VE from those two points.
When you tuned for SD, what method did you use? Did you do the 3D charts of VE from your MAF logs like John suggested? If so, we can look at that data at those two points and see what your VE increase should be. If not, I'm thinking this may be the issue.
Use an Excel spreadsheet to multiply out your two VE tables into a 3D chart to get a better view of your 'VE map' that you are saying to use. It will help in seeing what your tables are actually doing. Make sure there is a decent increase with increasing map change.
Also, you can always use the async/sync TPS additions, but the base tune should be what is covering for most changes. You don't want to band-aid the base tune with addition tables.
Hopefully some of this makes sense.
Eric
I didn't open the log in LogWorks yet, so going by your screenshots, it looks as if these are the conditions before and during your issue:
55kpa 1000 RPM - 72% VE (before issue)
90kpa 1250 - 75% VE (during issue)
You are idling at 55kpa/1000RPM, with a calced VE of 72% (calced from your VE table settings). Then you increase TPS to roughly 90kpa at that same RPM range...naybe increasing slightly to 1250. The calced VE now is 75%.Well, that's only a 3% change. Looking at some of my old maf logs, I have about a 15% change in VE from those two points.
When you tuned for SD, what method did you use? Did you do the 3D charts of VE from your MAF logs like John suggested? If so, we can look at that data at those two points and see what your VE increase should be. If not, I'm thinking this may be the issue.
Use an Excel spreadsheet to multiply out your two VE tables into a 3D chart to get a better view of your 'VE map' that you are saying to use. It will help in seeing what your tables are actually doing. Make sure there is a decent increase with increasing map change.
Also, you can always use the async/sync TPS additions, but the base tune should be what is covering for most changes. You don't want to band-aid the base tune with addition tables.
Hopefully some of this makes sense.
Eric
Can you post a pic of your main map fuel tables? I had this same problem and fixed it by richening up the fuel maps in the 500-2000 rpm range, 40-100 load ranges...richer than you'd think you want, in the 12's and 13's.
This is sort of where we run into the issues of two 2-D tables though. There is only so much you can do compared to a 3D table.
I should mention one additional thing with respect to the log above. The time scale is not correct. When you export into logworks, it ignores your time scale and sets it automatically to 12 samples/second. With how many channels I was logging, I was getting half that or less. What seems to be 2 seconds in the log is likely closer to 5 seconds.
L2R99GS-T, I used my own method, as I changed all kinds of things directly before switching to speed density and on the MAF, the car was completely undrivable (stalling issues due to the quartermaster clutch being too light, the cams messing with the airflow signal at low airflows and the TIAL BOV). I did a lot of pulls at various loads. RPM sweeps, load sweeps, light throttle, heavy throttle, corrected for Accel and Decel enrichments. All statistically based. I can say without a doubt, my current tune is the best compromise between being WAY too lean when this issue pops up and being WAY too rich when it's not there.
I have also used the MAF Comp table to help lean out below 125HZ, to fix a rich idle issue that flat out could not be corrected for with the MAPVE and RPMVE tables without making this issue 1000x worse.
I see why you are focusing on the tip-in. However, I think the more important aspect of the log is not the tip-in but the point of the log where it goes from 17:1 to 13:1. Also, a tip-in issue to me would be on the order of less then a second. This is a lean issue that lasts 5+ seconds. It's like a switch gets thrown and the car goes back to how it is supposed to run. Yes, Async adjustments can help cover up the issue, no doubt. I'm looking to find the actual issue that is causing this though. My car already goes insanely rich on tip in ever where but below 2000 RPM, if anything, I need to pull out tip-in enrichment every where else.
If I heavily load the car, it doesn't do this at all. This morning, I popped it into 4th gear, similar coolant temps, air temps, etc. 800 RPM start point, 88kPa (atmospheric pressure) Rolled into throttle fairly quick. I'll post the log tonight.
The car briefly went lean (Async TPS issue below 2000 RPM that I have not changed) but then the AFR went right to 14.3 area where I have the car tuned at. The AFR matched the AFRMAP value from 900 RPM to 2000 RPM in this pull. It DID NOT lean out at all like in the pull above. For this reason, I feel my MAPVE and RPM VE tables are correct. At the very least, it shows that my RPM curve is correct as MAP was constant and the AFR matched the predicted AFR. There could potentially be an issue with MAPVE, but I've done a LOT of light throttle tuning above 2000 RPM and my MAPVE seems to be dead nuts on above this little issue.
Also, my car already tries to idle at 12:1 with those settings, thus the reason for using the MAF comp tables to target only the idle airflow condition. Almost any throttle at all gets you above 100Hz. But any leaner on the RPM scale and this lean misfire becomes MUCH more apparent. Suggesting to run richer makes the car run extremely rich when it doesn't do this little enleanment thing.
I feel there is a sub-routine stepping in that likely deals with idle control and it has an effect on IPW. The step in total sync load seems to show this as nothing really happens and yet the total sync FPW increases nearly 40% for no apparent reason at roughly 1750 RPM.
Maybe it's is the "decel idle FPW" that mrfred mentioned but seems to not be in 96530006?
Maybe it's how the ECU deals with 2 different loads based on IAT? Similar to the jitter issue, yes the airflow gets replaced, but a flag got set in the original airflow code that influenced what happened AFTER the airflow value was changed. Maybe the same thing is happening here? The Load is calculated differently due to the IAT as previously noted, and the ECU is expecting a similar change and has a flag set for it. But load doesn't change, so some correction is getting applied that shouldn't be?
Thank you for any ideas though, please don't take my "combative" nature as the way it comes across. I'm willing to try out things, but honestly, I've already tried what's been mentioned and I feel where I'm currently at provided the best compromise in everything. I have literally retuned the car COMPLETELY from scratch 4 separate times, each time using a different method and every time, I end up with this same issue.
L2R99GS-T, I used my own method, as I changed all kinds of things directly before switching to speed density and on the MAF, the car was completely undrivable (stalling issues due to the quartermaster clutch being too light, the cams messing with the airflow signal at low airflows and the TIAL BOV). I did a lot of pulls at various loads. RPM sweeps, load sweeps, light throttle, heavy throttle, corrected for Accel and Decel enrichments. All statistically based. I can say without a doubt, my current tune is the best compromise between being WAY too lean when this issue pops up and being WAY too rich when it's not there.
I have also used the MAF Comp table to help lean out below 125HZ, to fix a rich idle issue that flat out could not be corrected for with the MAPVE and RPMVE tables without making this issue 1000x worse.
I see why you are focusing on the tip-in. However, I think the more important aspect of the log is not the tip-in but the point of the log where it goes from 17:1 to 13:1. Also, a tip-in issue to me would be on the order of less then a second. This is a lean issue that lasts 5+ seconds. It's like a switch gets thrown and the car goes back to how it is supposed to run. Yes, Async adjustments can help cover up the issue, no doubt. I'm looking to find the actual issue that is causing this though. My car already goes insanely rich on tip in ever where but below 2000 RPM, if anything, I need to pull out tip-in enrichment every where else.
If I heavily load the car, it doesn't do this at all. This morning, I popped it into 4th gear, similar coolant temps, air temps, etc. 800 RPM start point, 88kPa (atmospheric pressure) Rolled into throttle fairly quick. I'll post the log tonight.
The car briefly went lean (Async TPS issue below 2000 RPM that I have not changed) but then the AFR went right to 14.3 area where I have the car tuned at. The AFR matched the AFRMAP value from 900 RPM to 2000 RPM in this pull. It DID NOT lean out at all like in the pull above. For this reason, I feel my MAPVE and RPM VE tables are correct. At the very least, it shows that my RPM curve is correct as MAP was constant and the AFR matched the predicted AFR. There could potentially be an issue with MAPVE, but I've done a LOT of light throttle tuning above 2000 RPM and my MAPVE seems to be dead nuts on above this little issue.
Also, my car already tries to idle at 12:1 with those settings, thus the reason for using the MAF comp tables to target only the idle airflow condition. Almost any throttle at all gets you above 100Hz. But any leaner on the RPM scale and this lean misfire becomes MUCH more apparent. Suggesting to run richer makes the car run extremely rich when it doesn't do this little enleanment thing.
I feel there is a sub-routine stepping in that likely deals with idle control and it has an effect on IPW. The step in total sync load seems to show this as nothing really happens and yet the total sync FPW increases nearly 40% for no apparent reason at roughly 1750 RPM.
Maybe it's is the "decel idle FPW" that mrfred mentioned but seems to not be in 96530006?
Maybe it's how the ECU deals with 2 different loads based on IAT? Similar to the jitter issue, yes the airflow gets replaced, but a flag got set in the original airflow code that influenced what happened AFTER the airflow value was changed. Maybe the same thing is happening here? The Load is calculated differently due to the IAT as previously noted, and the ECU is expecting a similar change and has a flag set for it. But load doesn't change, so some correction is getting applied that shouldn't be?
Thank you for any ideas though, please don't take my "combative" nature as the way it comes across. I'm willing to try out things, but honestly, I've already tried what's been mentioned and I feel where I'm currently at provided the best compromise in everything. I have literally retuned the car COMPLETELY from scratch 4 separate times, each time using a different method and every time, I end up with this same issue.
Last edited by 03whitegsr; Jan 14, 2010 at 08:58 AM.
Trending Topics
I should mention one additional thing with respect to the log above. The time scale is not correct. When you export into logworks, it ignores your time scale and sets it automatically to 12 samples/second. With how many channels I was logging, I was geting half that or less. What seems to be 2 seconds in the log is likely closer to 5 seconds.
L2R99GS-T, I used my own method, as I changed all kinds of things directly before switching to speed density and on the MAF, the car was completely undrivable (stalling issues due to the quartermaster clutch being too light, the cams messing with the airflow signal at low airflows and the TIAL BOV). I did a lot of pulls at various loads. RPM sweeps, load sweeps, light throttle, heavy throttle, corrected for Accel and Decel enrichments. All staticitically based. I can saw without a doubt, my current tune is the best COMPRIMISE between beeing WAY too lean when this issue pops up and being WAY too rich when it's not there.
I have also used the MAF Comp table to help lean out below 125HZ, to fix a rich idle issue that flat out could not be corrected for with the MAPVE and RPMVE tables without making this issue 1000x worse.
I see why you are focusing on the tip-in. However, I think the more improtant aspect of the log is not the tip-in but the point of the log where it goes from 17:1 to 13:1. Also, a tip-in issue to me would be on the order of less then a second. This is a lean issue that lasts 5+ secondsa. It's like a switch gets thrown and the car goes back to how it is supposed to run. Yes, Async adjustments can help cover up the issue, no doubt. I'm looking to find the actual issue that is causing this though. My car already goes insanley rich on tip in ever where but below 2000 RPM, if anything, I need to pull out tip-in enrichment every where else.
If I heavily load the car, it doesn't do this at all. This morning, I popped it into 4th gear, similar coolant temps, air temps, etc. 800 RPM start point, 88kPa (atmospheric pressure) Rolled into throttle fairly quick. I'll post the log tonight.
The car briefly went lean (Async TPS issue below 2000 RPM that I have not changed) but then the AFR went right to 14.3 area where I have the car tuned at. The AFR matched the AFRMAP value from 900 RPM to 2000 RPM in this pull. It DID NOT lean out at all like in the pull above. For this reason, I feel my MAPVE and RPM VE tables are correct. At the very least, it shows that my RPM curve is correct as MAP was constant and the AFR matched the predicted AFR. There could potentially be an issue with MAPVE, but I've done a LOT of light throttle tuning above 2000 RPM and my MAPVE seems to be dead nuts on above this little issue.
Also, my car already tries to idle at 12:1 with those settings, thus the reason for using the MAF comp tables to target only the idle airflow condition. Almost any throttle at all gets you above 100Hz. But any leaner on the RPM scale and this lean misfire becomes MUCH more apparent. Suggesting to run richer makes the car run exteremly rich when it doesn't do this little enleanment thing.
I feel there is a sub-routine stepping in that likely deals with idle control and it has an effect on IPW. The step in total sync load seems to show this as nothing really happens and yet the total sync FPW increases nearly 40% for no apparent reason at roughly 1750 RPM.
Maybe it's is the "decel idle FPW" that mrfred mentioned but seems to not be in 96530006?
Maybe it's how the ECU deals with 2 different loads based on IAT? Similar to the jitter issue, yes the airflow gets replaced, but a flag got set in the original airflow code that influenced what happened AFTER the airflow value was changed. Maybe the samething is happeneing here? The Load is calculated differently due to the IAT as previously noted, and the ECU is expecting a similar change and has a flag set for it. But load doesn't change, so some correction is getting applied that shouldn't be?
L2R99GS-T, I used my own method, as I changed all kinds of things directly before switching to speed density and on the MAF, the car was completely undrivable (stalling issues due to the quartermaster clutch being too light, the cams messing with the airflow signal at low airflows and the TIAL BOV). I did a lot of pulls at various loads. RPM sweeps, load sweeps, light throttle, heavy throttle, corrected for Accel and Decel enrichments. All staticitically based. I can saw without a doubt, my current tune is the best COMPRIMISE between beeing WAY too lean when this issue pops up and being WAY too rich when it's not there.
I have also used the MAF Comp table to help lean out below 125HZ, to fix a rich idle issue that flat out could not be corrected for with the MAPVE and RPMVE tables without making this issue 1000x worse.
I see why you are focusing on the tip-in. However, I think the more improtant aspect of the log is not the tip-in but the point of the log where it goes from 17:1 to 13:1. Also, a tip-in issue to me would be on the order of less then a second. This is a lean issue that lasts 5+ secondsa. It's like a switch gets thrown and the car goes back to how it is supposed to run. Yes, Async adjustments can help cover up the issue, no doubt. I'm looking to find the actual issue that is causing this though. My car already goes insanley rich on tip in ever where but below 2000 RPM, if anything, I need to pull out tip-in enrichment every where else.
If I heavily load the car, it doesn't do this at all. This morning, I popped it into 4th gear, similar coolant temps, air temps, etc. 800 RPM start point, 88kPa (atmospheric pressure) Rolled into throttle fairly quick. I'll post the log tonight.
The car briefly went lean (Async TPS issue below 2000 RPM that I have not changed) but then the AFR went right to 14.3 area where I have the car tuned at. The AFR matched the AFRMAP value from 900 RPM to 2000 RPM in this pull. It DID NOT lean out at all like in the pull above. For this reason, I feel my MAPVE and RPM VE tables are correct. At the very least, it shows that my RPM curve is correct as MAP was constant and the AFR matched the predicted AFR. There could potentially be an issue with MAPVE, but I've done a LOT of light throttle tuning above 2000 RPM and my MAPVE seems to be dead nuts on above this little issue.
Also, my car already tries to idle at 12:1 with those settings, thus the reason for using the MAF comp tables to target only the idle airflow condition. Almost any throttle at all gets you above 100Hz. But any leaner on the RPM scale and this lean misfire becomes MUCH more apparent. Suggesting to run richer makes the car run exteremly rich when it doesn't do this little enleanment thing.
I feel there is a sub-routine stepping in that likely deals with idle control and it has an effect on IPW. The step in total sync load seems to show this as nothing really happens and yet the total sync FPW increases nearly 40% for no apparent reason at roughly 1750 RPM.
Maybe it's is the "decel idle FPW" that mrfred mentioned but seems to not be in 96530006?
Maybe it's how the ECU deals with 2 different loads based on IAT? Similar to the jitter issue, yes the airflow gets replaced, but a flag got set in the original airflow code that influenced what happened AFTER the airflow value was changed. Maybe the samething is happeneing here? The Load is calculated differently due to the IAT as previously noted, and the ECU is expecting a similar change and has a flag set for it. But load doesn't change, so some correction is getting applied that shouldn't be?
Also, my car already tries to idle at 12:1 with those settings, thus the reason for using the MAF comp tables to target only the idle airflow condition. Almost any throttle at all gets you above 100Hz. But any leaner on the RPM scale and this lean misfire becomes MUCH more apparent. Suggesting to run richer makes the car run extremely rich when it doesn't do this little enleanment thing.
It's sort of hard to explain here unless I show some examples in Excel with maf logs, but it's pretty tricky getting the VE tables tuned perfectly. It's not a 'one at a time' type thing. You have to actually tune both...a change in one affect a change in the other. Since they are two 2D table actually a change in one affect an entire row or column in the resultant 3D VE map. (Again I will mention that there is no way to get it perfect sicne we aren't using a true 3D map...so that can be part of the problem as well. But multiplying your two 2D maps out to show the resultant 3D map will show you the calculated 3D map and where you may possibily need adjustments.)
In the meantime, you can try scheides suggestion as well. Depending on where your close/open loop cutoffs are, you can try richening the fuel map where your lean issue is. That will tell us whether is a VE tuning issue or not.
Last edited by l2r99gst; Jan 14, 2010 at 09:26 AM.
Evolved Member
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Since they are two 2D table actually a change in one affect an entire row or column in the resultant 3D VE map. (Again I will mention that there is no way to get it perfect sicne we aren't using a true 3D map...so that can be part of the problem as well. But multiplying your two 2D maps out to show the resultant 3D map will show you the calculated 3D map and where you may possibily need adjustments.)
Last edited by acamus; Jan 14, 2010 at 09:52 AM.
I would think it would be a good idea to have on the roadmap though. While it does increase the time to fully tune, it also increases the ability to tune transitional areas better because of the issue that I mentioned.
If I change my RPMVE to accommodate the rich idle by leaning out the 500 and 1000 RPM sites, it does two things.
1. My car idles at 1000 RPM. If I have a large VE difference between 1000 and 1250, the AFR is ALL over the place as the engine speed varies slightly around idle. It causes idle surge. I’m not going to trade one bad behavior for another.
2. If I lean out to 1250 (tapering the area to 1500) to eliminate the idle surge and get the idle AFR in check, it makes this enleanment issue 1000x worse, literally to the point where the car is undriveable.
Now, if I use the MAF Comp table, I can easily lean out JUST the idle. Even just the slightest bit of throttle gets it out of the range of the MAF Comp adjustments. The idle issue is very POINT specific and the MAF comp table allows me to target ONLY the idle.
If I richen up the MAPVE to help with the enleanment issue, it messes up my entire tune. I have literally tuned the car on statistics with 1000+ samples per load/RPM site on a GOOD portion of the MAP. I've gotten EXCELLENT data EVERYWHERE except for below 2000 RPM. My STD is less then 3-5% error over the ENTIRE fuel map... EXCEPT for below 2000 RPM. This is with data that I have corrected/removed data where ever accel enrichment/decel is taking place, to avoid skewing the data. The STD is HUGE below 2000 RPM and it reaffirms my thoughts that something else is going on and there is somehow a major correction taking place that we are not accounting for. If it was a consistent response, I would just need a large correction but the STD would still be tight.
It's sort of hard to explain here unless I show some examples in Excel with maf logs, but it's pretty tricky getting the VE tables tuned perfectly. It's not a 'one at a time' type thing. You have to actually tune both...a change in one affect a change in the other. Since they are two 2D table actually a change in one affect an entire row or column in the resultant 3D VE map. (Again I will mention that there is no way to get it perfect since we aren't using a true 3D map...so that can be part of the problem as well. But multiplying your two 2D maps out to show the resultant 3D map will show you the calculated 3D map and where you may possibily need adjustments.)
Honestly, most probably will NEVER notice the issue. I KNOW I wouldn’t if it weren’t for this god damn quartermaster clutch. To prevent VERY Violent chatter, I have to keep the revs very low while slipping the clutch. Thus, with a normal clutch, you typically slip the clutch enough to stay above this problem area. I hit the thing dead center almost every time I pull away from a stop because the driving style required to keep the clutch happy forces me to that part of the map.
I know most disagree with the idea the fuel table reflect lambda values. But I completely disagree and my fuel table and actual AFR match up almost perfectly everywhere except for in this one problem area. My VE values are very realistic to a physics based point of view. I've tuned VE based standalones and my 2D table overlays VERY WELL with another 2.0L motor I've tuned on an Autronic.
I understand what you're saying. I'm merely giving suggestions to your very frustrating problem.
When I mentioned tuning the VE tables, I wasn't really talking about using one table...but a combination of both in tandem so that you can pinpoint the area that you wanted to adjust, just like you did with your maf comp table. It is very hard to explain, and I know you understand what I am saying. It sounds like you may have even gone this route with no luck. It may simply be the lack of a 3D map, as I mentioned.
And of course, don't take my suggestions as telling you that are wrong or your VE tables are wrong. It's just that I went through this whole thing as well when I was trying to find out what the IPW jitter was all about. My car ran perfectly aside from the jitter, but when I multiplied the 2D tables out to 3D and compared to my MAF based logs, I could see the minute discrepancies between the two. I had to alter both tables simultaneously to try to pinpoint one cell or range of cells. It's very difficult to do since changing one cell in either 2D table change an entire row or column in the 3D map. So, even a 1 cell change in one VE table needed a complete retune of both tables to keep the other cells of the resultant 3D unchanged...if that makes sense. That's just where I am coming from with this.
I don't think you are doing anything wrong. I think we are just limited with what we have at the moment.
In the meantime, things like the fuel map trick and other advanced fuel options that mrfred have given us can be used to cover most issues I think. Just don't go nuts too quickly.
When I mentioned tuning the VE tables, I wasn't really talking about using one table...but a combination of both in tandem so that you can pinpoint the area that you wanted to adjust, just like you did with your maf comp table. It is very hard to explain, and I know you understand what I am saying. It sounds like you may have even gone this route with no luck. It may simply be the lack of a 3D map, as I mentioned.
And of course, don't take my suggestions as telling you that are wrong or your VE tables are wrong. It's just that I went through this whole thing as well when I was trying to find out what the IPW jitter was all about. My car ran perfectly aside from the jitter, but when I multiplied the 2D tables out to 3D and compared to my MAF based logs, I could see the minute discrepancies between the two. I had to alter both tables simultaneously to try to pinpoint one cell or range of cells. It's very difficult to do since changing one cell in either 2D table change an entire row or column in the 3D map. So, even a 1 cell change in one VE table needed a complete retune of both tables to keep the other cells of the resultant 3D unchanged...if that makes sense. That's just where I am coming from with this.
I don't think you are doing anything wrong. I think we are just limited with what we have at the moment.
In the meantime, things like the fuel map trick and other advanced fuel options that mrfred have given us can be used to cover most issues I think. Just don't go nuts too quickly.
Last edited by l2r99gst; Jan 14, 2010 at 10:44 AM.
During my few first tests with setting both the MAP VE and RPM VE from scratch, I found that the extremely rich idle and cruise afr's were due to an incorrect value in the lower range of the MAP VE. After reading through the write-up briefly the one day (after I had everything tuned of course lol), it seems that I tuned my setup a little backwards from everyone else though. I set the MAP VE first while leaving the RPM VE at 100% across the board, and then tuned the RPM VE to achieve a near-perfect LTFT. I also reset the ecu every time I made a change so previous LTFT setting wouldn't interfere with the changes I made.
I don't think that's backwards. I basically did the same thing exact that I used a predetermined curve for RPM VE first. MAP VE is the one that has the most effect in on boost situations so that needs to be ironed out pretty well. Then the RPM VE is used to adjust for necessary changes, while adjusting the map VE to suit where needed. The two table work together to build the 3D map.
In my case though I had a good maf based log, so I could see what the actual VE was for my car in all conditions. That was my check back to see if the settings were right (or as close as possible with the two 2D maps).
In my case though I had a good maf based log, so I could see what the actual VE was for my car in all conditions. That was my check back to see if the settings were right (or as close as possible with the two 2D maps).



