[Lucas@AirLift]

Hello all. I was wondering if it is possible to change the AFR correction on speeduinos to adjust to 0.1% instead of the normal 1%. This would really be fantastic if we could do this, as I know I can extract more MPG from my car if I was able to more accurately correct for AFR. This would enable the user to change their ARF correction settings to respond much more quickly and should be able to maintain more constant AFRs under cruise conditions. If we could also add a 2D table for AFR delay based on RPM that would be incredible!

[PSIG]

Interesting thought. My first reactions are that most do not tune where 1% would make a noticeable difference. If you do, that's awesome, but then you'd also appreciate individual cylinder ignition trims for even more gains at that level of precision.

AFR/Lambda is not that stable in-reality, and part of the problem is delayed or over-reacting with rapid corrections to minor changes that actually make it less stable, like 1/10 AFR because you drove through the cool shade of a tree. It's a "good" correction, but the event is already over before the correction is made, and now the result is not only the uncorrected first event, but also the mis-correction now that it's passed, causing yet another correction. Are you really better-off?

This is why I set number of cycles between corrections rather high, so it is more stable, and provides me better average results. It also increases frequency of reporting as rpm increase. Likewise, some WBO2 controllers allow setting the reporting frequency, while averaging between signals , for a more stable and correct AFR. I'm thinking to try either option for how it works for you. And for a code change, perhaps offer a configurable averaging function that obtains a more accurate averaged AFR correction?

Theoretically, the most stable AFR is without corrections, but of-course the result may be wrong. My perspective is to provide those corrections, but with a tuned average for greater accuracy and stability. What do you think?

[Lucas@AirLift]

I try to tune within 3% for cruising. While I don't disagree with what you are saying, one of the main limitations of this setup in comparison to say a reflashed stock ecu is AFR corrections. Most stock ecus will have a few tables that deal with afr correction delays, both rpm based as well as a delay to start correcting after a decel event. Combine this with afr correction resolution of 0.01% and you have an effective way to keep your AFRs as close to ideal under almost all closed loop scenarios.

If you are not on board with 0.1% corrections, how about a new value and a new table? If we could add an EGO Correction After Decel time value that would solve one of my issues. Doing this would give the ecu time to start correction after decel, which is an issue I have where it wants to correct full rich before it starts to get a correct reading. For the other, the table would be a 2D table, RPM being the axis and EGO Correction Cycle Count for the adjustable values. Having variable ego cycle counts by rpm would make it so I can have idle set to a high value, and have the value decrease as rpm increases as it takes less time for the WB02 to react at higher rpm.

[jonbill]

By decel, do you mean dfco, or fueled deceleration?
I did muck around last year with an after dfco re enrichment feature. It worked, but for me wasn't worth the effort of trying to get it merged.

Imo, the ego correction is only sort of ok, I doubt it would take advantage of 10x resolution of the target.

[apollard]

I agree with David - without a dyno / rolling road to hold steady state rpm/load (and no changes in air resistance due to wind, road slope changes, etc) you simply won't achieve a tune that can use that level of precision. You can achieve a tune that does what you want better than the factory tune, but you are not going to approach factory levels of precision without the equipment to hold load and rpm steady. Yes, some aftermarket ECUs do have that level, but it is a great marketing tool, not one the users will benefit from.

[PSIG]

I'll add that effort to isolate the problem effects will be important to the "fix". For example, I've never had decel enrichment issues (except with wet-manifold TBI - a different situation). As I heard complaints from others, I looked into why mine was OK and found it's because I locked corrections out at idle or severely delayed them, so corrections didn't make things worse half the time. That was purely accidental, and just how I though it would work better. But because of this, there was no confused correction to upset the decel recovery for me. It just began running when it should, with the fuel it should.

Smooth as silk, pointing-out the issue was actually the corrections. I thought about a delay for corrections to begin after decel as one "fix", but I didn't need the fix, so why should anyone else? Yes, that sounds a bit self-centered to some, but they're missing the point. Proof of the problem. This highlights why I am always telling others to seek ways to fix the issues with tools and functions they already have. I'll bet there's a way.

If all efforts are showing promise, but it's just not good enough, then it's time to look at adding yet another "easy button" function. An added bonus and critical point is that it proves the exact problem source, and the way the function should work to solve the issue directly, which beats assumptions and band-aids any day.

[EDIT] Admittedly, I sometimes speak knowing what I'm thinking, and the point isn't always clear to others. Re-reading the above, let me make a different statement that may help show my perspective:
Why does the AFR need correction in the first place? What are the factors that can influence resulting AFR, and how could we improve those, so corrections are not needed (or fewer of them). Approaching from the different perspective, avoiding more of the problem may be more effective than seeking an improved way to fix what has already gone wrong. This requires proving the root of the issue, and how it can be altered.

[Lucas@AirLift]

Well this discussion made me re-evaluate my tune and see if I could fix what was going on. Turns out, when I first made the tune I set the ARF correction range to the full range of the WB02. Simply narrowing this down to 13-16:1 AFR has resolved the issue I was having! Thanks guys can't wait to get my new 2ZZ on a Speeduino!

[PSIG]

Awesome! This makes me think of things I "just do" on every tune that makes life easier, and one of those is to limit corrections to reasonable Lambda/AFRs that will not have partial or full misfire; perhaps 10:1 to 17:1 for this engine, different for another. As either rich or lean misfire reads a high Lambda, corrections are incorrect for actual, and this keeps it out of trouble.

I don't know if this is the effect you also gained, but is just one of those things that we don't think to talk about, that can make a difference in how one setup works differently than another. Congrats on your findings!

[turtana]

In My case i have 370cc injectors on a 2l engine . Running 4bar Fuel pres and 87% on injectors.
Still The Fuel resolution IS Bad. With 1% adjustment IT jumps 0.3-0.4 afr so The closed loop O2 IS pretty rough and you can feel IT while driving.

If i re scale The ve i could have litle More resolution with biger ve values. Ve IS on The ~170 Area with The e85 second map.
With 98ron it's worse.

[LPG2CV]

@turtana, post your tune, but preferable in another topic, as I suspect it's tuning you need