Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000612EMStudioGeneralpublic2012-07-12 18:432012-07-22 13:49
ReporterBenFenner 
Assigned Tomalcom2073 
PrioritylowSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version 
Target Version1.0.0Fixed in Version 
Summary0000612: Auto-tune feature for VE table. (Real-time algorithm.)
DescriptionThere are two dominant algorithms on the table for implementing VE auto-tune.
This one we're calling the "real-time" approach.
The other one, which is described in 0000609, we are calling the "averaging" approach.

See 0000609 for details of pitfalls and general principal.



Here is the basic algorithm:

01) Check for coolant temp above user selectable amount. If above goto 02.

02) Check TPS data, RPM data, pressure data, AFR data, and possibly others for
user-defined steady-state over a user-defined time frame. If steady-state is achieved goto 03.

03) For a given sample, deemed as stable from step 02, compare integral lambda with exhaust gas lambda, if not equal, determine correct VE for that point with CorrectVE = (ObservedEGO / UsedLambda) * UsedVE, see below for details of how to apply that value to the VE table.

04) Wait until either (exhaust gas data from new tune arrives (sensor lag time has passed)) OR (you're 2 cells away on different data unaffected by last change). Go to 01.


As an alternative to 04 you could also just check to see if the VE in the table matches what you received, and if not, discard this change. This may be cleaner and simpler to implement.


In the usual case of UsedVE and CorrectVE not matching, apply the CorrectVE value in the following ways:

If exactly on a cell, which is rare, you can set that cell to CorrectVE exactly, in one step. Extremely unlikely, and the general case may/should cover this.

If exactly on one axis and not exactly on the other, the two cells being used should have a weighted change applied with a formula. This case is still very very unlikely, but should be handled correctly, and proven so with a unit test.

If not exactly on either, a formula is applied to determine the weighting of the changes applied to the four cells that are being used.

Fred will elaborate on this later.
TagsNo tags attached.
Issue TypeNew Feature
Attached Files

- Relationships

-  Notes
User avatar (0001653)
Fred (administrator)
2012-07-13 10:10

Updated to remove duplication and specify the real time algorithm correctly.
User avatar (0001654)
Fred (administrator)
2012-07-13 10:19

If exactly on this cell, then the change applied is 100% new value, 0% old value. If not on this cell at all (exactly on the one next to it for example) then the change applied is 100% old value and 0% new value.

If you're exactly on one axis, and half way in between two cells, by axis distance in the other axis, then you should weight the old and new values 50% each and use the result.

If you're exactly on one axis, and 25% away from one cell, 75% away from the other cell, in the other axis, then in the closer cell, you should weight the old value 25% and the new value 75% and use the result.

Thus in one axis, on a plane, the result is this:

NewVE = (PercentDistanceToCell * OldVE) + ((100% - PercentDistanceToCell) * CorrectVE)

I'll expand to cover the normal case of four cells later today.
User avatar (0001659)
BenFenner (updater)
2012-07-14 13:21

Clarified that step 02 is being referenced, and not a typo of "O2".


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker