"FMIC Rich Dip" partially caused by the ECU

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

I've found a few parameters that are combined (in non-trivial ways) to generate the "enrichment compensation 2" parameter. There are a half-dozen tables involved in cooking up those four inputs, and some conditional logic, and some math... So far I don't have a clear picture of what any of it really means.

I've attached a spreadsheet and CSV, and a few screenshots.

The thing that puzzles me the most right now are the Boost and "SortaBoost" inputs. When plotted, they both look sorta like boost, but not quite. I haven't figured out how they are calculated. The difference between the two appears to be a pretty significant part of the math behind the EC2 parameter.

The pictures below show the 'rich dip' that I want to fix, and some simple tip-in/tip-out behavior. I am pretty sure I could make all of it go away by filling a couple tables with zeros, but my goal is to keep the tip-in/tip-out and just make the throttle-stomp-rich-dip go away.

For all of the graphs, the X axis is milliseconds, not RPM.

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

logger.xml for the stuff I'm looking into...

<ecuparam id="E912" name="NSFW EC2" desc="Causes tip-in, tip-out, and the dreaded 'rich dip.'">
<ecu id="2F12785606">
<address length="4">0xFF5614</address>
</ecu>
<conversions>
<conversion units="Lambda enrichment" storagetype="float" expr="x" format="0.0000" />
</conversions>
</ecuparam>

<ecuparam id="E924" name="NSFW EC2 Input A" desc="TBD.">
<ecu id="2F12785606">
<address length="4">0xFF561C</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E925" name="NSFW EC2 Input B" desc="TBD.">
<ecu id="2F12785606">
<address length="4">0xFF5620</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E926" name="NSFW EC2 Input D" desc="TBD.">
<ecu id="2F12785606">
<address length="4">0xFF5628</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E927" name="NSFW EC2 Input C" desc="Sometimes seems to just lag behind EC2 by 100 ms. But not always.">
<ecu id="2F12785606">
<address length="4">0xFF5624</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E929" name="NSFW EC2 Boost_1" desc="Resembles boost, but not exactly.">
<ecu id="2F12785606">
<address length="4">0xFF5644</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E930" name="NSFW EC2 Boost_2" desc="Resembles boost, but not exactly.">
<ecu id="2F12785606">
<address length="4">0xFF5648</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

<ecuparam id="E931" name="NSFW EC2 SortaBoost" desc="Resembles boost, but not exactly.">
<ecu id="2F12785606">
<address length="4">0xFF564C</address>
</ecu>
<conversions>
<conversion units="raw" storagetype="float" expr="x" format="0.00000" />
</conversions>
</ecuparam>

dschultz · **Posted:** Wed Jul 27, 2011 10:19 am

Why does the WBO2 not track the FFB like in the graphs you have in post #1?
In these latest graphs it goes lean not rich, what am I missing...?

JackANSI · **Joined:** Thu May 31, 2007 1:26 pm **Posts:** 138

My observations on the 2500-6800:
The "input C" and EC2 curve looks very similar to your boost error at some points. Just would take a bit of graph vertical scaling differences to make the transistions more or less match up. Until after the 4K-4.5K area. I'm suspecting that one of the 'inputs' is another form of the turbo dynamics popping up maybe?

The graphed difference between input A and input D almost seem to fit the difference between FFB and FT. Once those two start jiving better, FFB and FT seem to track nicely.

But either your wbo2 is reading richer because of back pressure, or your maf table is a tiny bit off still

(still closer than mine)

Between 3.5K and 4K your boost target table is a bit off reality, which might be exacerbating the over boost you're seeing. Its starting to correct one way, then gets pulled the other way, then back the other after 4K (all before max boost). But its not like they give you a curve to tune with, it is a straight line. Keeping the curve on one side of that line helped me with my overboosting tremendously.

JackANSI · **Joined:** Thu May 31, 2007 1:26 pm **Posts:** 138

NSFW wrote:

Tangential discovery:

<ecuparam id="E920" name="NSFW Timer Ticks" desc="Timer ticks, approx 135/second, stops at 65535.">
<ecu id="2F12785606">
<address length="2">0xFF52E4</address>
</ecu>
<conversions>
<conversion units="raw" expr="x" format="0" />
</conversions>
</ecuparam>

This counter is zero when you start the engine, counts upward at about 135 ticks per second, and stops at 65535 (since it's a 16-bit unsigned integer). There are a couple of checks of this timer, and the "enrichment compensation 2" logic is skipped if the tick count is less than 625 (4.6 seconds).

Not particularly useful, but there it is anyway. There are a ton of places in the code that reference the timer value, probably for warmup-related stuff I guess.

4.6 seconds is mentioned in the FSM as the time needed to judge the front o2 sensor as NG. Under DTC P0130.

65.5 milliseconds (close to your 135 ticks/sec) is also the initial time step used for DTC P0125: INSUFFICIENT COOLANT TEMPERATURE FOR CLOSED LOOP FUEL CONTROL.

Seems you may have found some DTC logic. I wouldn't be surprised if one of the inputs might even be misfire DTC related.

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

dschultz wrote:

Why does the WBO2 not track the FFB like in the graphs you have in post #1?
In these latest graphs it goes lean not rich, what am I missing...?

Good question, I'm not sure. It's the same tune in all of these logs. I have been focusing on the rich dip and hadn't even noticed it going lean on tip-in... I should definitely do something about that.

JackANSI wrote:

My observations on the 2500-6800:
The "input C" and EC2 curve looks very similar to your boost error at some points. Just would take a bit of graph vertical scaling differences to make the transistions more or less match up. Until after the 4K-4.5K area. I'm suspecting that one of the 'inputs' is another form of the turbo dynamics popping up maybe?

The graphed difference between input A and input D almost seem to fit the difference between FFB and FT. Once those two start jiving better, FFB and FT seem to track nicely.

But either your wbo2 is reading richer because of back pressure, or your maf table is a tiny bit off still

(still closer than mine)

Between 3.5K and 4K your boost target table is a bit off reality, which might be exacerbating the over boost you're seeing. Its starting to correct one way, then gets pulled the other way, then back the other after 4K (all before max boost). But its not like they give you a curve to tune with, it is a straight line. Keeping the curve on one side of that line helped me with my overboosting tremendously.

My fuel table calls for 11.2 and my actual AFR are about 11... that's just laziness, really. I figure 11 is good enough, and haven't bothered to get them aligned more closely.

More later....

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

What I was calling "EC2 Boost 1" is actually Load.
SortaBoost is Load from the previous iteration of the function that calculates EC2.
There's a third parameter as well which is Load from the iteration before that.
So I'm going to rename those to EC2_Load, EC2_LoadPrev, and EC2_LoadPrevPrev.
The code that I thought might be calculating boost error is actually calculating the change in load over time.

So now I need to go rename a bunch of things and review the code again and see if it makes more sense.

I still can't believe I never noticed how lean I've been going right when I stop on the throttle. Thanks for drawing my attention to that, dschultz!

I just reviewed my tip-in settings and they're basically unchanged from stock except for cutting the Throttle Tip-In Enrichment table almost in half (because my current injectors are almost twice as big).

So now of course I am wondering if I will be able to tune this stuff to fix that lean spot AND remove the rich dip.

It's configurable in many ways, but I have to figure out how it all works first...

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

This is all subject to change, but here's what I have so far:

InputA = change in load since the previous iteration
InputB = change in load since two iterations ago, clamped to -0.2 and +0.2

InputC = Table lookup based on InputB, then multiplied by table lookup based on load
- The table based on InputB is pictured below.
- The "table based on load" has values ranging from 2.0 at zero load, to 0.5 at 3.0 g /rev.

InputC is optionally multiplied again by a table based on Rpm (0.97 below 5600, 1.36 at 7200), or alternatively by a second table based on load (1.7 at low load, 0.125 at 1.4 g/rev and higher). I haven't investigated what determines those additional multipliers are used.

InputD = InputA scaled by 0.1 or 0.03125, or a table lookup based on RPM (ranges from 0.97 to 1.36). Again I haven't investigated what determines which multiplier to use.

InputC and InputD each get multiplied by ECT compensation tables, then added together.

EC2 = (InputD * EctMultiplier1) + (InputC * EctMultiplier2)

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

NSFW wrote:

InputC = Table lookup based on InputB, then multiplied by table lookup based on load
[....]
- The "table based on load" has values ranging from 2.0 at zero load, to 0.5 at 3.0 g /rev.

I suspect that if I change that "table based on load" so that it tapers to, for example, 0.1 at 2.0 g/rev and above, then I should retain the tip-in characteristics at low load, but reduce the "rich dip" characteristics at high load.

The left table is always used, the right table apparently gets applied when load is falling rather than rising.

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

Can any assembly gurus sanity-check my interpretation of this subroutine? Or better yet, explain what it's for?

There are dozens of references to this throughout the ROM, so I have come across it a few times, but I have yet to make sense of it. This gets called a couple times while calculating InputA (my explanation above was very approximate / incomplete) so I'd really like to know what's going on here.

Code:

ROM:00002424 ; Inputs are:
ROM:00002424 ; fr4 - A
ROM:00002424 ; fr5 - B
ROM:00002424 ; fr6 - C
ROM:00002424 ; fr7 - D
ROM:00002424 
ROM:00002424 Confusing:                              ; CODE XREF: sub_80A0+5Ap
ROM:00002424                                         ; FuncGetUnknownSensor01+68p ...
ROM:00002424                 flds    fr5, fpul
ROM:00002426                 mov.l   @(h'24,pc), r4 ; Float_MaxValue
ROM:00002428                 sts     fpul, r0        ; r0 = fr5
ROM:0000242A                 and     r4, r0
ROM:0000242C                 cmp/eq  r4, r0
ROM:0000242E                 bt/s    loc_2446        ; return A
ROM:00002430                 fsub    fr4, fr5        ; fr5 = A - B
ROM:00002432                 fldi1   fr0             ; fr0 = 1.0
ROM:00002434                 fsub    fr6, fr0        ; fr0 = 1 - C
ROM:00002436                 fmov    fr4, fr6        ; fr6 = A
ROM:00002438                 fmac    fr0, fr5, fr6   ; fr6 = A + (fr0 * fr5)
ROM:00002438                                         ; fr6 = A + ((1 - C) * (A - B))
ROM:0000243A                 fmov    fr4, fr5        ; fr5 = A
ROM:0000243C                 fsub    fr6, fr5        ; fr5 = A - A + ((1 - C) * (A - B))
ROM:0000243C                                         ;     = ((1 - C) * (A - B))
ROM:0000243E                 fabs    fr5             ; fr5 = abs(fr5)
ROM:00002440                 fcmp/gt fr5, fr7        ; fr7 > fr5 ?
ROM:00002442                 bf/s    loc_2448        ; If fr7 >= fr5, return A + ((1 - C) * (A - B)).
ROM:00002444                 nop
ROM:00002446
ROM:00002446 loc_2446:                               ; CODE XREF: Confusing+A
ROM:00002446                 fmov    fr4, fr6        ; return A
ROM:00002448
ROM:00002448 loc_2448:                               ; CODE XREF: Confusing+1E
ROM:00002448                 rts
ROM:0000244A                 fmov    fr6, fr0
ROM:0000244A ; End of function Confusing

Thanks!

Sasha_A80 · **Posted:** Thu Jul 28, 2011 5:49 am

This seems like A/B blending where C is weighting factor and D is a threshold to be checked.
I am not sure that signs are correct.

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

Thanks! I think you are right. If called repeatedly, with the result being assigned back to A, then A should approach B, at a rate determined by C. I wonder if it is being used as a low-pass filter.

"A - B" should be "B - A" on at 2430, and everywhere else.

Sasha_A80 · **Posted:** Thu Jul 28, 2011 6:26 am

The low pass filter with output limiter
y(n+1)=(1-a)y(n)+a*x(n)

Being subtracted from initial signal may serve as a differentiator.

wrxsti-l · **Posted:** Thu Jul 28, 2011 11:27 pm

If these tables are all load based, perhaps the dip that is occurring is actually related to the MAF hack and it not being applied to these (or other hidden) tables with a load axis?

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 2273

wrxsti-l wrote:

If these tables are all load based, perhaps the dip that is occurring is actually related to the MAF hack and it not being applied to these (or other hidden) tables with a load axis?

If you're thinking of the MAF hack that I think you're thinking of, then that's not it.

32-bit ECUs don't have the hard upper limit that 16-bit ECUs have (300 g/s if I remember right?). So, the MAF scaling can go arbitrarily high, with no need to divide everything by 2 or whatever.

RomRaider

Forum rules

"FMIC Rich Dip" partially caused by the ECU

Who is online