[MR2] MK1 ECU quesiton
Aaron Willis
AWillis at lithia.com
Fri Sep 28 15:24:39 EDT 2007
No, I'm not talking about break-in. Let me give you some examples:
1) Swap from 210cc/min injectors to 295cc/min injectors. Car runs very
rich (takes longer to find stoich), then as a few miles are accumulated,
begins to run clean and is always near stoich under closed loop
conditions.
2) Swap to larger AFM (5M-GE housing in place of 4A-GE housing). Car
runs lean (takes longer to find stoich), then as a few miles are
accumulated, begins to run clean and is always near stoich under closed
loop condition.
3) Swap from stock to rumpty-rump camshafts. Car runs ragged (closed
loop AFRs are all over the place), then as a few miles are accumulated,
smoothes out and stays near stoich while in closed loop.
What evidence do you have that the ECU has no long-term storage
capability? It doesn't have to datalog a hundred miles of use. It just
has to recognize that at a given point on the fuel table (say 3200 RPM,
"X" g/second of air) it consistently has to add, say, 12% injector
pulsewidth above its default value to attain stoichiometry. If it's
consistent, it makes sense that the ECU would modify its table and store
the new pulsewidth value for future use. We're not talking millions of
data points here. If it's a simple 2D fuel table (RPM vs. airflow),
maybe 12x12, that's only 144 points. Even 16x16 would only be 256.
That sounds like something even a basic, early 80s ECU could handle.
Scott suggested that the ECU would throw a code if it didn't get
immediate feedback from the o2 sensor indicating that it had attained
stoichiometry. This is not generally true. The ECU will continue to
adjust the mixture (doesn't take more than a fraction of a second) and,
once stoichiometry is reached, of course the o2 sensor will report that
to the ECU. If it is never reached, then you have a problem that will
get flagged as a code - though this may or may not take multiple drive
cycles. Codes are not usually thrown based on single, isolated
instances, especially when the sensor in question simply takes a moment
longer to respond to an anticipated change than the ECU expects it to,
as opposed to failing to respond altogether.
I simply can't use the fact that I was once playing Oregon Trail on a
5.25" floppy disk as a yardstick against what Toyota, NipponDenso, or
Bosch were able to cram into their ECUs. And at the end of the day, I'd
rather use my personal, repeatable experience to determine what the ECU
is capable of than rely on historical knowledge of consumer electronics
technology...sorry, Ben, but that argument doesn't make much sense to
me.
We're not talking about putting a super-zoot, 12.984537:1 AFR at WOT,
ultimate horsepower, split-hair, genius tune on the thing. We're
talking about the ability to adjust and retain values so that the engine
sees a near-stoich AFR during closed loop operation. I
Aaron Willis, Parts Dept.
Lithia Toyota of Springfield
863 Main St.
Springfield, Or 97477
(800)888-6305 ext. 3221 or (541)736-3221
(541)747-4174 fax
-----Original Message-----
From: Benjamin Krueger [mailto:benjamin at seattlefenix.net]
Sent: Friday, September 28, 2007 10:46 AM
To: Aaron Willis
Cc: scottl at cape.com; marc at marcmedina.com; mr2 at mr2.com
Subject: Re: [MR2] MK1 ECU quesiton
* Aaron Willis (AWillis at lithia.com) [070928 10:09]:
> There's no question that a narrowband o2 sensor is only accurate near
> stoich. But since the ECU monitors the o2 sensor during closed loop
> operation, how is it impossible that it would relearn or retrim its
fuel
> tables (at least the closed-loop table) to provide stoich mixtures
after
> a modification has changed the engine's fuelling needs?
>
> If you're adamant that the ECU absolutely will not relearn its closed
> loop tables based on narrowband o2 feedback, I'm just gonna have to
> disagree. I'm not suggesting that it corrects open-loop mixtures, as
> obviously there's no feedback to correct with, but after making many
> changes and resetting the ECU many times, I can report with certainty
> that the car will run much better after it gets some time/miles with
the
> new setup than it does when first fired up.
Can you think of other reasons that an engine would run better after a
period of time? Parts break-in perhaps?
>From an logical point of view, what you suggest simply doesn't make
sense. The ECU has no long term storage capability. It can't record
historical mileage data. To suggest that it takes a week's worth of
data, perhaps 100 miles, to "find" a good tune is to suggest that the
ECU can remember historical data and compare its current results against
it. 100 miles of data is a *lot* of data, even if we simply limit it to
fuel trim samples or knock samples of any single sensor input.
If you assume then that perhaps the CPU keeps a single delta or perhaps
the "best" data so far, I have to ask; what exactly is the "best" data
so far? There is no knock sensor, so we can't measure knock. We only
measure AFR when we're in closed loop. From the limited sensors we have,
how would we determine a "good" tune?
This technology was designed in the early 80s. Do you remember what kind
of computer you had in the early 80s? The answer is probably "none". If
you had a computer, it was about as sophisticated as a modern
calculator. Computers capable of actually writing long term storage did
so with floppy disks and hard drives, and those disks and drives were
tiny, slow, and expensive. Solid state writeable storage was a luxury
that I would bet is not found in your ECU. So how is the ECU learning,
exactly?
Basically, I hate to be contrary, but this just doesn't make sense. The
technology was barely there, and it was exotic and expensive. The amount
of data to retune after that many miles is very large. The processors
were very slow. There is no way to store that data in your ECU. And
honestly, nobody here has offered anything outside of personal
observations to testify to the existance of this feature. Butt dynos are
worth two craps and a wipe, so why are we depending on them to verify
the existance of an unlikely feature?
--
Benjamin Krueger
More information about the MR2
mailing list