Unexpected VE load values on decel affecting EAE
#1
Unexpected VE load values on decel affecting EAE
Hi guys, I'm having a weird issue that I thought was caused by EAE, but upon further inspection actually seems to only manifest itself with EAE, causing some bucking back and forth on deceleration.
When I back off the gas pedal from anywhere around 60kPa and up, EAE immediately pauses fueling as it should, but after a few cycles allows fuel back in, and allows too much too soon. Here is a picture showing the odd EAE curve.
At first I thought this was just how EAE does things. I suppose it makes sense to yank a big chunk of the fuel puddle away as soon as possible, as this area of my map has a lot of Sucked and not much Added coefficients.
Upon closer inspection, however, it seems like this behavior is actually due to the ECU reporting an inaccurate Primary Fuel Load value, which in turn affects VE, which in turn tells EAE it should be at a MAP value that the engine is not actually in.
I verified this by loading the tune and checking my VE and EAE tables in Tunerstudio, notice the funky jump in the history trace:
So there is my issue. I imagine that if there wasn't a goofy dip in Fuelload compared to the actual MAP measurement that EAE would operate more smoothly, and therefore cause less jerky movement of the car on throttle lift.
I have tried to fix the issue by changing my primary and EAE fuelloads under the "General Settings" menu from %baro to Speed Density and just plain old MAP to no avail.
Is this normal behavior? Does it have to do with my MAP signal at all? I have had MAP averaging lag factor set to 90 for some time now, so I wouldn't think it's related.
Thanks for any help! I'll attach my MSQ with a log for reference.
When I back off the gas pedal from anywhere around 60kPa and up, EAE immediately pauses fueling as it should, but after a few cycles allows fuel back in, and allows too much too soon. Here is a picture showing the odd EAE curve.
At first I thought this was just how EAE does things. I suppose it makes sense to yank a big chunk of the fuel puddle away as soon as possible, as this area of my map has a lot of Sucked and not much Added coefficients.
Upon closer inspection, however, it seems like this behavior is actually due to the ECU reporting an inaccurate Primary Fuel Load value, which in turn affects VE, which in turn tells EAE it should be at a MAP value that the engine is not actually in.
I verified this by loading the tune and checking my VE and EAE tables in Tunerstudio, notice the funky jump in the history trace:
So there is my issue. I imagine that if there wasn't a goofy dip in Fuelload compared to the actual MAP measurement that EAE would operate more smoothly, and therefore cause less jerky movement of the car on throttle lift.
I have tried to fix the issue by changing my primary and EAE fuelloads under the "General Settings" menu from %baro to Speed Density and just plain old MAP to no avail.
Is this normal behavior? Does it have to do with my MAP signal at all? I have had MAP averaging lag factor set to 90 for some time now, so I wouldn't think it's related.
Thanks for any help! I'll attach my MSQ with a log for reference.
#2
Tweaking Enginerd
iTrader: (2)
Join Date: Mar 2013
Location: Boulder, CO
Posts: 1,788
Total Cats: 362
Not sure what you mean by adding too much too soon, EAE is pulling fuel for nearly the entirety of the screen shot above.
EAE values less than 100 are pulling fuel.
FYI, For EAE you need to plot wallfuel and AFR as well. If using time based as well, plot that too.
EAE values less than 100 are pulling fuel.
FYI, For EAE you need to plot wallfuel and AFR as well. If using time based as well, plot that too.
#3
For some reason, the fuelload axis on my EAE and VE tables does not track with the MAP (or %baro) values in this situation.
I'm wondering if this is intended functionality, because it seems to be making EAE's job harder.
"Fuelload" detaches from MAP even when Primary Fuelload is set to MAP, but this only happens in this very specific scenario and nowhere else that I've noticed.
This causes the estimated engine VE to take a dive, you can see in the screenshot here how VE drops to 56 while MAP is at 43 and RPM at 2386. Engine VE in is area should be closer to 64.
Notice the AFR Error peak a fraction of a second later- that's the issue I'm chasing. Less deceleration happening at that area of low AFR error (due to the fuelload dip) makes the rest of the rich decel area feel herky jerky.
Thank you for having a look. I've read in another EAE thread about your model, I trust your car is pretty dialed at this point!
#5
Tweaking Enginerd
iTrader: (2)
Join Date: Mar 2013
Location: Boulder, CO
Posts: 1,788
Total Cats: 362
you know it has been a very long time since I have looked at this stuff in any detail.. I went and looked at a couple of random logs, and TBH I don't see anything too glaring in what you have above in terms of issues. Are you certain A) this data above represents the undesirable behavior on the street, and B) If you turn EAE off does the undesirable behavior go away?
The MAP and RPM traces in your data don't communicate undesirable behavior here. Do NOT chase the gauge on lift-off. It is a losing proposition, and will drive you crazy. Even on my car (and yes it is extremely well behaved) has a dip in AFR on lift-off.
One thing that does pop out to me with what you are posting, assuming that this data DOES NOT show the undesirable event... you have a 19 in your sucked table. Depending on what you have in CLT/RPM modifiers, you do not want any use conditions where the product of all 3 can exceed 25.5. You will get a noticeable event if this happens.
EAE is super tricky for people because to do well, everything is relative. Which is to say that you can't really use a basemap and get good results, even with a near identical setup. Below are a couple of plots of found that would be similar, one slow (TS log) and one fast (SD log). Looking back I can't definitively determine which you are posting (TS vs SD).
The main thing I will point out with your data, is that I wouldn't expect EAE to go to 0% with this event. You will notice I supplement with time-based. Even EAE isn't awesome at compensating for a lift-off, which is the hardest use condition.
The MAP and RPM traces in your data don't communicate undesirable behavior here. Do NOT chase the gauge on lift-off. It is a losing proposition, and will drive you crazy. Even on my car (and yes it is extremely well behaved) has a dip in AFR on lift-off.
One thing that does pop out to me with what you are posting, assuming that this data DOES NOT show the undesirable event... you have a 19 in your sucked table. Depending on what you have in CLT/RPM modifiers, you do not want any use conditions where the product of all 3 can exceed 25.5. You will get a noticeable event if this happens.
EAE is super tricky for people because to do well, everything is relative. Which is to say that you can't really use a basemap and get good results, even with a near identical setup. Below are a couple of plots of found that would be similar, one slow (TS log) and one fast (SD log). Looking back I can't definitively determine which you are posting (TS vs SD).
The main thing I will point out with your data, is that I wouldn't expect EAE to go to 0% with this event. You will notice I supplement with time-based. Even EAE isn't awesome at compensating for a lift-off, which is the hardest use condition.
#6
Ah, I see. It's probably not something I have the ability to fix then, if you haven't been able to.
I will reduce my maximum Sucked values and multipliers to make sure they don't cross that threshold at 25.5, I believe my max Sucked RPM Multiplier was 199 before you mentioned that...
That previous log I shared was a TS log, here is a 5ms log I took today, I forgot to add VE to the logging parameters.. but you can see similar behavior at the 187.5 second mark.
I've had fun dinking around with the EAE settings, I still don't fully comprehend how each setting affects the other but the car feels almost stock to me, in just a few areas of operation Thank you for the advice!
I will reduce my maximum Sucked values and multipliers to make sure they don't cross that threshold at 25.5, I believe my max Sucked RPM Multiplier was 199 before you mentioned that...
That previous log I shared was a TS log, here is a 5ms log I took today, I forgot to add VE to the logging parameters.. but you can see similar behavior at the 187.5 second mark.
I've had fun dinking around with the EAE settings, I still don't fully comprehend how each setting affects the other but the car feels almost stock to me, in just a few areas of operation Thank you for the advice!
#7
Tweaking Enginerd
iTrader: (2)
Join Date: Mar 2013
Location: Boulder, CO
Posts: 1,788
Total Cats: 362
You say that the car is herky jerky when this is happening, but the screen shots you have posted don't show anything in MAP or RPM that would indicate something like that. Would you say you are getting the undesirable behavior in these plots?
AFR is more insightful than AFR_error
AFR is more insightful than AFR_error
#9
Tweaking Enginerd
iTrader: (2)
Join Date: Mar 2013
Location: Boulder, CO
Posts: 1,788
Total Cats: 362
So that oscillation looks coupled to overrun. I recommend turning all overrun features off (fuel and ignition) when tuning any fueling, including EAE.
Your fuel is also poorly controlled prior to lift off. The VE table has to be dialed in before tuning EAE. Looks to me like you could really benefit from some extended VEAL time. Start with normal, progress to very hard, hit all areas of the table, including decel. Avoid transient events (dramatic tip-in and lift off) as much as possible. VEAL is good about ignoring transient samples, but the residual effect of the transient may persist beyond the blanking period.
Your fuel is also poorly controlled prior to lift off. The VE table has to be dialed in before tuning EAE. Looks to me like you could really benefit from some extended VEAL time. Start with normal, progress to very hard, hit all areas of the table, including decel. Avoid transient events (dramatic tip-in and lift off) as much as possible. VEAL is good about ignoring transient samples, but the residual effect of the transient may persist beyond the blanking period.
Thread
Thread Starter
Forum
Replies
Last Post