Table Driven Injectors.

[Robert Harris]

The use of separate injectors and tables to drive them can be extended to any
situation.

The scenario.  You have 28 pound injectors that would nicely cover from idle
to xxx.  Going up in pressure, or poundage begins to reduce your
controllability at the low end.  Yet you need to wind up with 40 pounds of
flow.  Any number of solutions for single injectors - none of them really
optimum.

For a fixed jet injector at a fixed fuel pressure, it is possible to calculate
the orifices to flow x amount of fuel.  Say we pick it to be 15 pounds.  15  +
28 gives us 43.   Now, this does not have to be a single nozzle.  It could
just as well be 8 nozzles sized appropriately to spray a mist of fuel way up
the runner when turned on.  Not going to happen at low throttle anyway so the
air flow will be strong and CIS will work just fine.  So what we have is a
simple fixed jet(s) turned on at a certain point by a simple solenoid on/off.


Now if we use conventional discrete logic or formulae, we can get snarly right
fast.  But, stealing freely from earlier days when computational time meant
something, we can use a "decision table" or "look up".  

Not a schematic - just a verbalization of a concept.  Implementation is left
to the student as an exercise.  Use a rom as a translator.  Take a sixteen bit
address rom, with 8 bits out.  Seven of the eight bits are fed as an input to
a D/A and the pulse width is the output.  The eighth bit simply turns the
fixed jet solenoid on or off.  

On the input side we calculate % power as a binary number based on MAF or
whatever.  That's n bits.  The address.  We can then calculate initially the
contents of the table so that we can get the proper fuel flow using both the
jet(s) and the injectors.   With no computational overhead - simply read the
address and apply the result.

There is no reason to limit the conversion to a simple Maf to pulse width /
jet on/off.   Increasing the number of bits in the output allows us to control
additional devices - such as fixed stream water/alcohol on/off or three step
water or "fill in the blank"   Increasing the number of bits in the address
allows us to "OR" in address bits that represent additional considerations
such as high gear, cold engine etc.   The total of the discrete bits and
converted analog input give you the total address or size of the table.  

The ROM can be replaced with a flash rom so that you could run - collect data
and change the entire data table and algorithms on the fly.  Several of us
discussed this idea a couple of years ago.  

The use of table controlled small fixed jets allow you to place them where
optimum for whatever you are trying to accomplish.  For example you may want
to place a couple in the plenum following the intercooler on a positive
pressure engine.  Then, with the discrete logic - turn them on at a certain
boost pressure when flow exceeds xxx.  

The more fixed jets that the ROM controls, the smaller the effective range of
the variable jets has to be.

Unusual thinking might be having a somewhat larger output word and controlling
two fuels - such as vapor propane and gasoline or for Dave, a third -
cruise-o-crap.   With a few fixed orifices on two of the three, the ROM could
be set up to blend nicely the various fuels without complex logic and still be
close to correct.

A last example.  The use of liquid propane is a nasty snarly problem.  Not for
me.  Part of the input "address" is the tank pressure of the propane.  Knowing
the tank pressure, I "know" the flow thru a fixed orifice.  If I place a fixed
orifice nozzle in the intake port, I can turn on a fixed flow of liquid
propane straight from the tank with just an on/off solenoid whenever the
throttle demands it.  Think NOS.  Two nozzles at the port gives me four steps
off/1/2/3.  Part of the rom code.  Self tuning - the hotter the day, the more
I need the octane boost and charge cooling and oh lucky me, the higher the
tank pressure.  

Just some silly thoughts to wake up to.