Mantis Bug Tracker

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





With incoming AFR/lambda data (wideband O2 sensor usually) and a lambda map already "tuned" to one's liking, the tuning app should be able to automatically "tune" the VE table. Many tuning software suites have this feature, and most I've seen do it poorly. I haven't met one that I like yet. A good human tuner is always better and faster.

Pitfalls to avoid:
1) Changing one cell at a time only. The footprint of changed cells should be four cells usually.
2) Also no changes should be made until the engine is in a steady state.
3) Lastly, changes should be made on average data taken over time.
Avoid these three issues and we should have a good thing here.


Here is the basic algorithm:

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

02) Record 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) Take the average integral lambda data gathered and compare it with the average AFR data recorded earlier (by the lag time of the sensor) and if they do not match (within a user-defined range) a change to the VE table should be made. More detail on how to change it is below* Goto 01.



*As for how to change the values accordingly. Read on:


This is how to change the values in the VE table when a change is desirable.

If the recorded AFR data shows lower/richer than the averaged integral lambda value, then the VE table value(s) need to be lowered. If the recorded AFR data shows higher/leaner than the averaged integral lambda value, then the VE table value(s) need to be raised.

Exactly how those VE table values are raised and lowered will be described next...
TagsNo tags attached.
Issue TypeNew Feature
Attached Files

- Relationships

-  Notes
User avatar (0001641)
Fred (administrator)
2012-07-11 19:58
edited on: 2012-07-11 20:18

If exactly on a cell, which is rare, you can set the VE 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. Ben or I will elaborate on this later.

User avatar (0001642)
BenFenner (updater)
2012-07-11 20:27
edited on: 2012-07-11 20:31

This is how to change the values in the VE table when a change is desirable.

Take the average RPM and average pressure data gathered and use it to look up the corresponding *interpolated* data from the lambda table. Compare the interpolated data from the lambda table to the average AFR data recorded earlier and if they do not match (within a user-defined range) a change to the VE table should be made.

If the values don't match and a change to the VE table needs to be made, then this is how it should be done.

If the recorded AFR data shows lower/richer than the interpolated lambda table data the VE table value(s) need to be lowered. If the recorded AFR data shows higher/leaner than the interpolated lambda table data the VE table value(s) need to be raised.

Exactly how those VE table values are raised and lowered is described a little bit by Fred above. Someone will expound on that in more depth soon. Likely me or Fred.

User avatar (0001643)
Fred (administrator)
2012-07-11 20:29

I disagree with the above, but can't comment right now.
User avatar (0001645)
BenFenner (updater)
2012-07-12 16:50
edited on: 2012-07-12 16:54

-Ben: You want to talk about VE auto-tune algorithm here or in -dev before going to the tracker?
*Fred: basically, if you're watching for steady state, and you meet that condition, and your current rx data is still steady compared to history, then just change it, no need to wait and do averages etc
-Ben: Well, I guess that depends on how the user defines steady.
-Ben: And how fucking amazing (or not) all their sensors and wiring and grounds are.
-Ben: It certainly doesn't hurt to average, you think?
-Ben: You already have the average.

*Fred: if you're averaging, what are you changing
-Ben: You're checking for steady state, so you already have all that info.

*Fred: steady state, for example, is a sweep through a gear at WOT
-Ben: Noooooooo.
*Fred: sure as fuck is
*Fred: not 1st
*Fred: 4th
-Ben: Well it depends how the user defines the steady state.
-Ben: if they define it as no more than 5 rpm change over 1 second... Then 4th gear sweep is no good.
-Ben: Or no more than 10 rpm change over 10 seconds.
-Ben: All that is to be user definable.
-Ben: So you, for your sweep, can do no RPM check at all.
-Ben: But I warn you, thatis a HORRIBLE way to tune a VE table.

*Fred: whatever
*Fred: if you define stable as X
*Fred: then make changes provided your "isStable()" method returns true
*Fred: and you need to track your changes timing with the data you receive
*Fred: because if you send a packet, the new table only applies to packets recieved after that is acked.
-Ben: True...




-Ben: And if isStable() returns true, you'll already have the data you need to average.
*Fred: hmm

*Fred: also
*Fred: (15:03:50) Ben Fenner (work): But I warn you, that is a HORRIBLE way to autotune a VE table.
*Fred: fixed
-Ben: Yah, it would be bad for auto-tune... Ususally.

*Fred: only due to the lag in the wbo2
*Fred: which is something that should get mentioned
*Fred: o2 applies to engine conditions from 0.2s before
*Fred: or something like that
-Ben: We should talk about the current state or the current need or lack of a need for acceleration enrichment. Proper acceleration enrichment.
-Ben: Are we of the mind now that ECU HW has gotten fast enough to be able to avoid this all together?
*Fred: no, certainly not, not possible, physics prevent it
-Ben: As I figured.
*Fred: it's very minimal with a proper setup, though
-Ben: So tuning a 4th gear sweep (or 3rd gear in my cases) on the street is the best we can get to sloooow rpm change.
-Ben: Without a dyno.

*Fred: realistically autotune is going to get used for mid throttle normal driving type stuff
*Fred: not full power sweeps
*Fred: that's human territory
-Ben: I understand.

User avatar (0001646)
BenFenner (updater)
2012-07-12 19:19
edited on: 2012-07-12 19:26

After some more discussion in IRC it is clear there are two ways we'd like to solve this issue, so there will be two implementations on the table, available for users.
This issue is one, and here's the other one: http://issues.freeems.org/view.php?id=612 [^]

All details for implementation will be in the issue itself shortly. No need to read these notes anymore except for fun.

User avatar (0001649)
Fred (administrator)
2012-07-13 09:27

Corrected some details.
User avatar (0001650)
Fred (administrator)
2012-07-13 09:40

Another tweak. Same stuff. The data comes as matched sets. If you average it, you average all of it. You don't average some, and use that to look up a specific point lamdba value as then you'd be inferring the shape of the curve, and likely wrongly...
User avatar (0001651)
Fred (administrator)
2012-07-13 09:46

Remove wholesale duplication.
User avatar (0001652)
Fred (administrator)
2012-07-13 09:49

Once again, Ben, the integral lambda that the device used to set the pulsewidth in the first place is the only lambda that you can compare the exhaust gas lambda with. You can't go and average some, and look up others. That's actually broken and wrong. You're making an assumption that your tables are the same exact size/axes, etc, and doing extra work because of it. You must use the most general case, which this time, is less work, because the data is already there for you. No need to repeat the work already done by the device and discard valuable information that's available to you.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker