C/L WB/WOT OEM ECUs...

[nacelp]

> > If the accel.
> >enrichment is also a result of rate-of-change of MAF also, then this
might
> >not be so easy?

I've never seen that.  Not saying it doesn't exist, just none of the popular
gm stuff uses it.

> As mentioned earlier, at least some aftermarket controllers (maybe all?)
> have tables to apply enrichment for ALL/any of the below:
> (1) throttle rateOchange
> (2) throttle pos (the actual position itself)
> (3) MAP rateOchange

Only option 2, seems to be applicable, again gm wise.

> These of course are applied on top of the base fueling tables, if I
> understand the proper nomenclature.

This gets muddier, as I understand things.  They usually have a commanded
AFR.  The corrections for temp., apply, and then some us B/L number
corrections to richen the mixture, others just use 128.

 BUT, the issue of control over O/L
> vrs C/L has more to do with what events/limits THROW you into the use of
> these tables. To illustrate what I'm getting at with that last sentence,
> consider that altho say for example #3 is USED in determining how much
> enrichment to add once in O/L, it may not of itself cause you to be
> thrown into O/L.

Your trapping yourself by using the word "add".  Like I said some use a
commanded AFR that they figure out, and run at.

 So the key variables we need to be able to control in
> order to keep OUT of O/L are the parameters that cause us to be thrown
> into O/L in the first place.

Well, in general, there are a number of those, ie time after restart, CTS,
lots of defaults from sensor failures, etc..  I wouldn't want to disable all
of those features, or you get a very dumb ecm, and that's what we're trying
to avoid in large part.

 Obviously, throttle pos and rateOchange
> have limits that throw us into O/L, and we may indeed be able to fudge
> these since they aren't usually part of/parameters of the base fueling
> tables. But the problem comes in when an engine parameter is used both
> to trigger O/L and is used in fueling calcs. Hence, trying to intercept
> and munge MAP values, for example, isn't gonna be workable, unless we
> have some way of controlling the *limits* themselves that cause
> transition to O/L.

I think your overthinking this, to a slight degree.  If we don't allow a PE
mode by clipping the TPS value, there will be no PE.  If you want to get
clever code wise, you might use some like the EGR area for setting a
specific set of conditions for using the EGR as the "govenor" for the C/L
WOT, and use the EGR enable to trigger a remote feed back devise, that uses
the original PW the ecm calulates for the AFR commanded.   Geez, I hope
someone other then me understands what I'm trying to express here.

> In general, that's why control over the limits that force O/L seems to
> always be a better plan than interception and munging of sensor inputs.
> The question remains, do we have enough authority via table values and
> flags, to control/prevent transition to O/L if we/when we want to.

Yes, for the hac'd ecms.
Grumpy
>

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org