ECU7 and diy-efi development

[Al Lipper]

Chris, I will try to answer some of your questions here.


> -----Original Message-----
> From: Chris Caloto [mailto:caloto at eng.usf.edu]
> Sent: Tuesday, August 03, 1999 9:00 AM
> To: Al Lipper
> Subject: ECU7 and diy-efi -> thanks for your reply
>
>
> Hi Al.
>
> Got your e-mail reply. Thanks.
>
> >What makes it unique is that it's a real-time
> >based system using multiple inputs, and especially, that it
> "learns."  The
> >learning is a tricky problem which can be approached in a number of ways.
>
> This sounds really good. That's the first thing I noticed about the
> ECU6/ECU7 projects when I looked at the web pages -> that they can
> self-calibrate themselves to whatever engines they are put on.
> Do they build\modify their own fuel map ?
They start with a pretty crude map which lets the engine run extremely rich.
The idea is that the engine will at least run if it's too rich (and have
time to warm up), but if it's cold, it won't even start.  Then, it checks to
see if the EGO (Exhaust Gas Oxygen) sensor is giving what appears to be
valid feedback.  Next, it starts the steady_state timer to determine if the
engine has not had major MAP or RPM variations for a certain period of time.
If it has indeed been steady, then it decreases PW (injector pulse width)
one step at a time (CL_STEP).  As long as the engine state is steady, it
will do this every few seconds (based on EGO_DELAY) until the EGO sensor
indicates it is in a stochiometric range and then learn the value.
Otherwise, until a variation occurs in which case it will back off one step
and learn that value before moving on to the table cell for the current
inputs.  This is a simplified description, but should give you the general
idea.  Note that TICK15 is a timer that increments every 15ms - its value is
converted to seconds and used for general timing purposes (like the EGO
timer).


> This could be a really good computer science master's thesis project.
> I downloaded all the ECU6 files and was looking through them to
> try to identify your learing algorithms. I see it's making use of
> learning tables (stored at appropriate address spaces in the memory.)
> Can you e-mail some info so I can understand the software better -
> like a software module map that shows the software components and
> how they interact / their purposes.
> Or maybe you don't have that. Just anything you have to speed
> up my learning curve as I try to pick apart the ECU6 code.

I'll see what I can dig up.  If I don't get you what you need soon, feel
free to remind me :)


> I assume it doesn't matter which one I work on - ECU6 or ECU7 -
> they're pretty much the same, right ?
>
Yes, they are very similar.  ECU7 improves over ECU6 in that it uses a
currently manufactured CPU (Intel stopped making the 80C51GB about 8 months
ago, but you can probably still order them from distributor stock.  ECU7
supports 4 independent sets of injectors (ECU6 does 2).  ECU7 uses a 5-volt
flash memory instead of the 12-volt one on ECU6.  ECU7 has much better
protection from noise, spikes, etc. than ECU6 (ECU6 may have a tough time in
electrically noisy cars, or those with voltage fluctuations).  Otherwise,
they are the same.


> For this to work as my thesis project I have to come up with some
> significant improvements to your learning algorithm.
> Did you come up with it yourself - or is your implementation based upon
> somebody else's work ?  If so, please give me the reference(s) so I
> can go read up on it.
> Are there some shortcomings to the learning algorithm
> in it's current implementation that you would like me to
> fix / improve ? This would be great.

The algorithms are entirely original.  But please note, I have a minimal
background in control systems theory, and they could no doubt be greatly
improved or re-written.  The current algorithm works as long as the vehicle
is warm and there are a minimum number of abrupt throttle movements.  It
also tends to enter a nasty oscillation at idle, where there are many zero
crossings (reaching stoich) of the EGO sensor (ultimately stalling the
engine).

>
> A second issue is that I must have some way
> of testing the new learning algorithm to show that it really
> does perform better than the old one. Ideally I would build the
> circuit and implement it on a vehicle(s) and it would run superbly
> and I would collect performance date to document it -
> but that is TOO big a project for me right now - although I think
> it would be great fun and it is something I would like to do -
> I have to remind myself I am not superman and I have limited
> time and resources.
>
> So is there some way to create an artificial test environment for
> the learning algorithm to evaluate it / test it ?
> Have you done anything comparable when you were developing
> ECU6 ?  (or any prior versions - I assume there was an ECU4 and ECU5 ?)
Yes, there were many versions (the first was the PC-based EFI system on the
DIY_EFI site - it was a bit clunky with a PC in the back seat, but it ran!)
For development of ECU6, I used a "vehicle simulator."  Basically, a box
with variable resistors for each of the analog inputs (Temp., TPS, EGO and
MAP), each with a calibrated dial.  Then, there were switches/pushbuttons
for digital inputs.  The RPM signal was generated using a function generator
which I connected a digital tach to in order to accurately monitor its
"RPM."  I used a relay as an inductive load for the injector output, just so
I could hear it buzzing when things worked right.  You can also use LEDs for
other outputs.  The setup works very well - better than a car even.  Too bad
you can't drive the thing :)  What I mean is you're creating an ideal
situation with it, and a real engine is far from ideal and has fluctuations
which are not detected by the system's inputs.  The simulator is extremely
helpful in setting things up and debugging, but really needs to be used with
the actual installation to guarantee it works.  For example, the learning
rountines worked great on the sim., but in the actual vehicle, I ran into
that idle fluctuation problem.  Basically, you need both.

Surprisingly, getting it to work on a car is not nearly as tough as it
seems.  I got it installed on a 57 corvette (including putting in the fuel
pump, and all the wiring) in about 2 days.  And, it ran without too much
work!  While it seems like there's so much data that comes from a car, I've
actually found ways to deal with it all.  In the beginning of ECU6.BAS, you
see all of the PRINT statements.  These are status reports.  I plug an old
laptop in and simply capture all of the data while the car is running under
different conditions.  Then, I take the saved file, import it into Excel and
examine it.  For example, lets say RPMs fluctuate and the engine dies going
up a hill.  Start the data capture, drive up the hill and let it stall.
Then, going back through the data will prehaps reveal a pattern of high MAP
and excessively lean mixture, leading to an attempt at compensation by the
learning rountine.  You go home and simulate the inputs on the simulator,
duplicate the problem, and ultimately see that the compensation is too
extreme.  Or something like that.  Anyway, that's the general idea.


>
> So this diy_efi stuff definitely has potential.
> I am interested in working on the learning algorithm.
> My two main concerns are
> 1) Are there problems / inadequacies in the current learning
>    algorithm so that I could come up with SIGNIFICANT improvements ?
Yes, there is room for significant improvements in the learning algorithm.
I have done very little research into control algorithms, but there is
certainly a lot out there.

> 2) Is there a way to test my new software implementation ?
>    This is very important but could be a sticking point, because
>    as you pointed out the system is real time and uses multiple inputs.
>    But testing \ evaluation is critical for my thesis.
>    I wouldn't mind working on and developing testing software.
>    In fact, that could be a thesis project on it's own ...

You need an ECU6 or ECU7 board to work with.  Once you get the parts, the
ECU6 board takes about 3 hours to put together (if you're reasonably good
with PC boards).  Through some major miracle, mine worked the first time
(though I'm skeptical about ever experiencing this again :)

If you do some decent work on the software, I'd be happy to attach your name
to the copyright and include you if it ever turns into a marketable item.


>
>
> >From the EE perspective, there's the hardware of ECU7.
> >What about taking the circuit and getting it to actually work
> >on a vehicle?
>
> I would love to work on that, but I've got to be realistic.
> Right now I can't do it. It's too big a project for me.
> I'd need to go buy another car (I'm fairly confident I could
> get a suitable rust bucket for a few hundred dollars)
> because if I try getting this to work on my
> current car (a 1982 carburated Mazda RX-7) I will be without
> transportation until I get it to work. I live in Tampa Bay,
> Florida and the public transportation system sucks so this is
> not an option.
> I also don't have a large dedicated work area.
> Must have a good work area.
>
If you just want to do the simulator part and don't have a vehicle to try it
on yourself, I might be able to work something out where you could do the
software development, and I would test new code on a vehicle, then e-mail
you results, etc.  I've done similar things before and it has worked out
pretty well.


> >You didn't mention if your EE program requires a
> >thesis or senior project ...
>
> It does, but I've already got some stuff lined up.
> Of course, I could end up doing something diy_efi related,
> but the senior project needs to be a SMALL, compact
> project.
>
>
> >If you are
> >interested in pursuing this further, let me know and I'd be happy to give
> >you plenty of additional info on the hardware, software and application.
>
> Yes, please send me anything you have that will help me
> understand the software, especially in regards to the learning
> algorithm.
>
> Also, a file contents listing would be handy -> when I unzipped
> the ECU6 zip file it contained a Software directory with 23 files.
> Some it's obvious what they are, others not so obvious.
> A listing of file names and what their purpose is would be good to
> have. If such a thing is already in the zip package what is its
> file name ?   I didn't find such a listing.
>

I'll see what I can dig up for this.  Are there particular files you need to
know about?





> Looking forward to hearing from you,
> - Chris.
>
>
> Here's the full text of the e-mail you sent me:
> At 7/29/99 3:33:00 PM, you wrote:
> Chris,
>         It's great to hear of your interest in EFI stuff.
> Actually, there are a
> number of aspects of the EFI projects that lend themselves to
> master's-level thesis work.  On the computer science end of things, there
> is the programming of ECU7.  What makes it unique is that it's a real-time
> based system using multiple inputs, and especially, that it "learns."  The
> learning is a tricky problem which can be approached in a number of ways.
> >From the EE perspective, there's the hardware of ECU7.  While
> the design on
> this is apparently complete, we have yet to build and test one - that is,
> it looks good on paper, but will no doubt need plenty of work once
> constructed.  What about taking the circuit and getting it to
> actually work
> on a vehicle?  The combination of programming and hardware might work well
> for your requirements.  You didn't mention if your EE program requires a
> thesis or senior project, but if so, you may be able to kill 2 birds with
> one stone.  In any case, congratulations on being almost done.  If you are
> interested in pursuing this further, let me know and I'd be happy to give
> you plenty of additional info on the hardware, software and application.
>
>                                 Al
>
>
>
>
>
>