DIY Injection with a PC

[John Dammeyer]

Hi All,

Phil has been real helpful to me so I thought I'd pass on some of my
experience since I had to make many of the same choices that are
itemized below.

Let's start with processor.  I had a price constraint and a 16 bit
processor, both from tools and long term per parts cost was too
expensive.  In hindsight,  I should have used the C167C and bought the
compiler since I ended up buying the Tasking 8051 compiler anyway.  The
extra grief (extra time) caused by the limitations in my processor have
more than eaten up the returns a cheaper processor would return.

Specifically I have used the 80C592 from Philips.  It has a nice T2 set
of compare registers that can set and reset or toggle an output compared
to the free running T2 timer.   CAN bus was a requirement here for
remote instrumentation.

>
>Can the laptop Handle it!!!
>- ---------------------------


Yes.  With a proprietary OS that lets you control what is done with the
timer tick.  If you can't you will find a periodic delay due to
processing on the DOS/WIN side.  Timer is high priority so your encoder
interrupts would be delayed.  I have an electric DC motor and speed
control that lets me simulate cranking all the way to 7000RPM.  On the
scope the signals look perfect.  The engine is not so forgiving since
the speed is dependent on the control system while the DC motor
controller doesn't care what my MAP sensor is doing.

I have a program written in Delphi that receives status messages from
the igntion and displays instruments graphically on the LCD display.  I
click on an instrument and I get a dialog box with the injection
parameters.  I can change them,  try them and then store them into EEROM
if I like what I see.

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


You need to sample the MAP sensor far more often than you think.  As
Phil stated in one of his notes.  At the start of every injection cycle,
using MAP and RPM to index a table to pull out a PW.



>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!).
>

Not even close.  You have to start the engine.  The change in engine
speed from 0 to cranking and then again from cranking to the first
firing is huge.  I found when I used a 4 vane system with one unequal
sized vane to determine TDC I had trouble reliably detecting TDC during
cranking to idle transition.   I blamed it on the high acceleration of
my DC motor but reality is quite accurate here.

Part of the reason was that the T2 timer on my processor is clocked by
the 16Mhz/12/8 resulting in a 6uSec tick.  The 16 bit T2 counter
overflows when engine RPM is less than 225RPM.   (My life would have
been easier if I had an extra divide by 4 available for the clock.)

Because I was interested in knowing absolutely where the engine was I
had my disk on the CAM shaft.  Now we are talking 225 CAM RPM 550 ENGINE
RPM .  Four slots and vanes divide this by 8 and keep the timer from
overflowing since most events are derived from one of the edges.

But,  it doesn't help with the initial start which is why I think Phil
was so insistant on basing everything on the edges.  I found the change
in RPM from cranking to Starting to be so dramatic that I would see teh
short slot and the following long vane (or visa versa) be exactly or
close to exactly the same number of clock ticks in length.  This was
with the electric Motor.  Perhaps a real engine wouldn't have had the
problem.

One of my other problems is that to determine the engine RPM I need to
divide a constant by the number of clock ticks between edge events;
this gives me an RPM that can be used as an index.  Takes a long time to
do a 32 divide operation on a 8051 family so I scaled the # of ticks and
used a 16 bit divide.

We also tried sensing gear teeth with a Hall Sensor and triggering off a
missing tooth.  Once again I had problems clearly keeping track of TDC.

In hindsight,  I would do it differently now.  I'd use two sensors:  one
that told me TDC #1 (CAMSHAFT or Distributor) and the other that
measured the RPM from the crank or a large number of teeth in the
distributor.  I'd use the CAM sensor to tell me where I was,  and then
use the Flywheel sensor to help me determine RPM based on time between
teeth.  As I'd know how many teeth we had I would also know where TDC of
each cylinder was by counting teeth.  Note that the number of teeth must
be divisible by 4 to clearly mark the exact TDC point of each cyl if you
are also doing Ignition. (I am).

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


Your timing resolution needs to be much better than 1ms. for the
injector.  Our Honda is idles comforably with the load of the Hovercraft
Fan (Giant Computer Fan (GCF)) at 1000RPM.   Pulse width once the engine
is warmed up is about 1.0ms and at 1500 RPM about 1.25ms.  At WOT
driving the FAN with all available torque the PW is only 8.25ms.



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

If you can avoid developing and testing ignition at the same time as
injection then do it.  Beats doing it at the same time.  I was
fortunate.  We had an engine on the Dyno that used an Allison Throttle
Body Carb (aircraft) and I debugged the ignition first.

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

The processor is fast enough but the DOS/WIN clock will interfere with
engine management.  you need A/D for the analog signals.  An external
box into the serial port may not deliver the MAP sensor value in time.
If you use a PCMCIA A/D board you can access that hardware directly.

To give you another idea of the problems.  I still have a latency issue
that I have yet to resolve.  I think it's in how I'm handling my sensors
but I can be idling and push the throttle to the firewall and I get a
short stumble and rattle before the engine controller catches the change
in MAP and Throttle Position and injects a big enough burst.  Once it
catches though, the GCF is up to maxium speed in seconds.  Quite
impressive.

Regards,

John