C/L WB/WOT OEM ECUs...

[Garfield Willis]

On Fri, 7 Apr 2000 12:59:32 +0100, "Rich M" <rsrich at cwcom.net> wrote:

>Assuming my understanding is correct, accel. enrichment and the like is
>performed in response to rate-of-change signals, notably from TPS. This can
>still be accomodated while limiting the actual max. TPS value as has been
>already suggested. This would allow the ECM to perform transient (required)
>enrichment, whilst inhibiting steady-state O/L operation. If the accel.
>enrichment is also a result of rate-of-change of MAF also, then this might
>not be so easy?

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

These of course are applied on top of the base fueling tables, if I
understand the proper nomenclature. 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. 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. 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.

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. In
addition to the OEM controllers, someone who's an active part of the 332
group and is familiar with it's code, could perhaps say what the O/L
trigger conditions/parameter limits are, and if even that controller
could be "persuaded" to stay in C/L via cal changes alone. That might be
a good examplar place to begin, since all the code is visible. Anyone
familiar with that code?

Obviously if you have full access and control over the code, you can do
better than just faking out the ECU like we've been discussing, so I'm
not proposing the above as the desired way of doing C/L WB in something
like the 332; just that since it's code is available and open, it might
still be an instructive example to look at. Pretend it's an OEM
controller you can peer into openly, but can't change the coding, and
then see if you can get by with just cal changes.

Gar


----------------------------------------------------------------------------
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