Designing Engine Management

[JMACKENZ at uk.ibm.com]

Hi Phil / William & other readers,

Sorry for this long note....

"Seems like everyone is designing an engine management system today ! "

...But are any of them sucessful and if so where's the public domain
source?

"It would be great if some of you would get together and pick a
common
platform. Makes it much easier to help  a group of you and the
open source
nature should help you attract others."


...What I will try to do is get the basics of a system developed then I
will open source my code (C++) for all to use and develop if interested.
This will help me to achieve what I want and also aid others. I'm going to
try and base it on a standard analogue and digital sampling  / control
interface for a PC so that nothing is unique unless it has to be.

I'm doing this for a long term interest and hobby and that rush of
adrenalin I'll get when an engine actually drives and is managed reasonably
well (until the computer crashes!)


"It's probably best to spend your first year or so  investigating
engine design
issues then you will be in a position to asses current technology
and
methodology of engine management."

...I'm not rushing into it head first. I know a bit but I'm looking for a
book which describes everything as a starter.

"The care and feeding of an engine is a technology neutral issue.
You can't design a carby without having a reasonable grasp of the
physics
of IC engines and the chemistry of combustion."

...With the mechanical engine stuff I should be OK to start with. Initially
I'm not designing the engine, simply using something which I know works
with the management system it came with.

"Same goes for writing code for an embedded engine management
application."

...This is where the challenge lies for me. I'd like to design it so that
it is capable of being compatible with existing fuel maps.


Can the laptop Handle it!!!
---------------------------
As regards the stuff about can a Laptop handle it...I dunno yet but I think
so. This for me is is the interesting bit because I don't know anyone
that's done it before. This is where I need real help as I am trying to
figure out exactly what analogue and digital inputs / outputs are needed so
I can ensure that what I choose in terms of hardware is more than adequate.
I can guarantee that I am not even looking at in 95 / 98 / NT or any
varient of that nasty unreliable stuff because the 'Blue screen of death'
probably would kill a high reving engine! I will consider OS/2 as I have
worked with it for years and it is one of the few true multitasking OS's
and is extremely reliable but my heart tells me to go with Linux as it
seems to be very flexible and extremely fast and free (and fashionable).
(Unless Microsoft want to sponsor anything?)

Even with the most powerful operating system running on the most powerful
laptop with  the fastest interfaces (USB / firewire?) to the DAC / ADC /
driver circuits I may still be limited. However I don't think I will be as
based on a 10K RPM engine I need the following sensors initially for basic
control of fuel injection (using mechanical ignition timing). Please
correct me if I've screwed up and am way out but these are my initial
calculations;

Inputs
-------

* Airflow (Analogue - Medium sample rate - 2Hz?) - Corrolates directly to
injector pulse width
* Oil temperature (Analogue - low sample rate - 30s intervals) - Too hot /
mix too lean or undercooling or indirect load sensing?
* Water temperature (Analogue - low sample rate - 30s intervals) - Too cold
/ richen fuel mix (choke)
* O2 sensor (Digital or analogue?) - Mixture adjustment
* Inlet Manifold pressure sensor (Analogue - Medium sample rate - 2Hz?) -
Engine load / adjust injector pulse width
* Crank sensor (Digital) - Gives crank position for injector timing and rpm

For the crank sensor, worst case is say 10K RPM (From Williams note). Which
equates to 166Hz. Up to this point I agree with the analysis. However I
think I only need 1 digital pulse per revolution of the crank shaft to
determine rpm and hence through knowing the firing order I can time my
squirts. This means that I only need to react to 166 pulses per second at
worst case. Since I am only getting 1 reading per rotation, Under heavy
acceleration / deceleration the timing of the squirts at low RPM would go
off as the engine approaches the end of the revolution but to offset this
I could use proportional / integral / differential stuff (Yep I studied
control theory / stability etc at Uni!) to keep my prediction of the
position of the crank accurate (hence the fuel squirt for the last cylinder
has a fair chance of being correct!).

Outputs
----------
* Output to each fuel injector (Digital)

At worst the engine will rev at 10K requiring 8 x 166 = 1328 pulses per
second. However since anything above 3.5K RPM results in the injectors
struggling to keep up with this rate of pulsing then above this I could
start firing injectors in banks, ie fire 2 together up to 5K RPM then fire
4 together up to 7K RPM then above this just leave all 8 open to get as
much fuel in the engine as possible? This makes the worst case for
injexctor output at 3.5K RPM which would be equal to 3500/60 * 8 = 466Hz.
If I need to be able to control at 1 msec intervals then I would need to be
able to output at 1KHz. I think I will require clever electronics in order
to address 8 injectors individually or in pairs (any ideas for this)? Would
I need a system with 8 digital outputs at 1KHz each?

If I was to control the ignition timing electronically, it would probably
be using a control to advance and retard the timing using a servo based on
readings for load / rpm and engine acceleration rather than trying to
calculate each pulse directly. If I had to calculate exactly then it would
require very accurate position sensing of the crank. Let me know any
thought on this? For starters though, it will be a standard distributer
setup using vacuum for retard.

To summise, I think it is possible to control all the basics for an engine
management system using a laptop without reaching any sampling limitations.
This means that it is not neccessary to use any external processing
capability.

Best Regards
James MacKenzie