Ignition module

Paul E. Campbell pecampbe at mtu.edu
Fri May 12 16:14:13 GMT 1995

I've been lurking for quite some time now, and this is what I have surmized:

1. The number of programmers and mechanically related types on this list is
quite high, with a smattering of others.

2. "The" model recommended for electronic fuel injection seems to be the
mean value engine model. I have two questions related to it:

a. How do you measure the parameters required for the model? The "perfect"
solution of course would be some simple user-entry parameters (number of
cylinders, displacement size, overbore size, CFI/SEFI/EFI injection type),
and then let the engine computer determine the rest online.

b. How would you convert it from a model to a control algorithm? I understand
that there are 3 inputs and 2 states..but the next step is to derive some
physical parameters that you wish to optimize based on the model. It does
not appear that anyone has ground out the mathematics yet except Mike
Klopfer (Jan 7, 1995) who seems to have made a pretty good stab with a similar

3. There is lots of squabble over the proper microcontroller to use. I have
personally used everything from off the shelf PC's to custom wired TTL logic
circuits (up to about 20 chips) to 68xx and recently, Microchip based
controllers. Everyone (and I mean everyone) has their own personal
preferences, usually based on familiarity. Essentially, the differences
between microcontrollers matter only on the kind of support that is
available and the complications that may come up because of interfacing.
Vehicle electronics is pretty darned simple to interface, so that leaves
support, which is pretty good everywhere you go. The specific features to
look for will probably boil down to:
	Is DSP capability necessary (the speed limitation)?
	Is lots of memory necessary (the giant array problems)?

Now, lots of people have said that you need current state-of-the-art
processors to ever hope to be able to do engine control management.
I can illustrate where this mistaken belief comes from with current available
PC's. Workstations and the Amiga computer rely heavily on custom chips for
their graphics. Essentially, some of the highly repetitive or large array-type
problems are done on custom chips. The normal processor just sequences the
operations. How much is done in custom chips and how much is done by the
processor depends on the system. Taken to the extreme, the Macintosh (at least
it used to) does EVERYTHING down to the pixel level on the main processor.
The Nintendo-type game boxes do almost everything on specialized chips.

What does this matter? Well, the claim is that very expensive and fast
processors are required to do EFI. This is not true. Use a PLL and some
programmable comparators and counters to do all the nasty timing intensive
work. All your processor has to do is be able to keep up with the important
events (a reasonable response time), not diddle around with the timing for
every single injector pulse.

4. Someone suggested strongly several times that the first project should be
getting a high performance electronic ignition module working. So far, all
the opinions on this list have suggested that the standard induction coil
charge route with transistor drives is the way to go. I agree, but before I
take the plunge, I have several questions. I have read Mr. Jacob's blurbs
and tried to determine just what it is that his little blue boxes are doing
so you'll know where I'm coming from.

a. Don't bother with Jacob's patent. All it does is detail the actual physical
driver, not the control aspects. I've already got a copy and there is not
anything really earth shaking in it.

b. How does one detect knock? And what do you do about it from an ignition
point of view?

c. What is the optimum spark voltage? The higher the better or is there some
curve? How do you measure it? What are the dependent variables?

d. How long should you maintain a spark? I have seen mention that it should
remain lit until TDC, but since your flame front has a certain amount of
propagation time, it seems that you may want to stop earlier. And this will
depend on engine rotation speed since the burn time is a constant, but it
should complete right at TDC? Or before or after?

e. How do you determine when to start the spark? I suppose this is related to
the previous question.

f. Jacobs claims he measures the resistance (??) of the spark gap when the
spark is or is not (??) lit to determine conditions inside the piston chamber.
Determining spark voltage/current should be a simple thing to do, along with
measuring resistance inside the chamber before/after burn, but what does this
tell you and how can you use it?

5. What I am thinking of is this: SAE 750348 details an ignition system that
lets you vary the starting voltage, the voltage to hold the spark, and the
duration of the spark. Some simple modifications could allow for relighting
the spark if it goes out, taking measurements, etc. All of these operations
could be controlled by a few dollars in discrete parts. A microcontroller
can be used to actually set up the ignition module and do the more complicated
measurements and calculations. From a user-standpoint, I'd like to be able
to stick a laptop on it and take in data as well as have some nifty diagnostic
lights in the cab and also toggle switches and/or a spark advance
potentiometer in the cab. A car alarm port would be nice, too. All of that
stuff could come from a header on the side of the classic mysterious black
(or blue) box. But to build the box, I need to know what is going on (answers
to question 4).

6. I've found the SAE Transactions in the local library (Michigan Tech.,
Van Pelt), and they do pretty good but they don't even come close to having
all of the papers SAE publishes. Some of the "unpublished" ones have been
posted on this mailing list. Does SAE publish any other journals that have
them or do you have to call SAE and pay for a specific paper for the majority
of them? My bachelor's degree is in electrical engineering, so I'm used to
the IEEE system where practically everything on anything has probably been
published in some obscure journal, but this doesn't appear to be the case for

More information about the Diy_efi mailing list