Injector Dynamic Range

Ed Lansinger elansi01 at mpg.gmpt.gmeds.com
Mon Mar 20 19:22:53 GMT 1995


Peter Wales wrote:

>Injectors are digital devices. They are either on or off! I agree that there
>are areas in the off /on transition and the on/off transition where they are
>non linear due to the fact that they are mechanical devices. I have always
>believed that manufacturers stay out of this area for fuel control because
>it is undefineable in its characteristics. You may be able to correct me on
>that matter.

Even "digital" electronic devices aren't "on" or "off", as my Computer Hardware Design 
professor once eloquently explained.  Everything is analog.  Hopefully, you can find  
operating areas (supply voltages within certain limits, switching times in a certain 
range, etc., all applicable to digital switches as well as injectors) over which you can 
make the simplifying assumption that the device exists in only one of two states called 
"on" and "off".

It's important to understand the limitations of these simplifying assumptions in order 
to be able to stay out of trouble.  It's also important if you want to explore and 
exploit what lies beyond the boundaries of these limitations.  If the non-linear region 
of an injector were indeed "undefinable in its characteristics", then there's little 
more to be said.  Herein lies the significance of the work done by Nomura and Irino in 
their paper ("Non-Linearity at Low Flow Rates from Electro-magnetic Fuel Injector", JSAE 
Review Vol. 8, No. 4, 1987 for those just tuning in).  They have characterized the 
performance of injectors in this region, surmized a physical explanation for it, and 
supported their ideas with a mathematical model based on the assumed physical model that 
produces results which correlate well with the observed phenomena.  Now that this 
knowledge is out, there's no need to limit our understanding of injector dynamics to the 
traditional "on/off" view, even though we may still choose to use this simplified model.

I don't know (and if I did I probably couldn't comment) if the OEM's are exploiting this 
non-linear region.  I can say for myself that when I was developing PCM's at school I 
stayed out of the non-linear region because it's much simpler to deal with.

>I am sure that there are injectors which can deliver full flow in under 1 mS
>and I am equally sure that there are injectors which will not be fully open
>in 2 mS. I was simply trying to explain that working in this area was IMHO
>undesireable and should be avoided. The 1.5 mS was a safe average for most
>injectors.

Certainly, I think Peter would agree with me that knowledge of the actual injector "on" 
time is extremely useful.  I used the traditional 1.5ms "safe average" and later found 
it was way off for the two different injectors I used.  The 1.5ms assumption, although 
it got the vehicle running, required a more complicated fueling algorithm for 
satisfactory operation than when I used the correct "on" time.  In my case, the 1.5ms 
"safe assumption" caused me to be almost 100% off in my low-load fueling.  I would 
encourage people to take the extra step and either get the correct information from the 
supplier or measure it themselves, because it's worth the effort.

>Consider the sitaution when the engine is cranking. It requires a pulse of
>1.5 mS or longer to inject some fuel (bear with me). Hence, we have an on
>pulse requirement of 1.5 mS. Now, when the injector is fully open at 6000
>RPM the inejctor is powered continuously. Thus any reduction in fuel flow
>rate can be considered as switching the injector off, or pulsing it off,
>because as soon as the next injection comes it is going to be switched on
>again. Now it requires an off pulse of 1.5 mS. I was simplistically stating
>that it takes as long to close the injector as it does to open it and 1.5 mS
>is a good average time. Therefore switching it off for less than 1.5 mS will
>not reduce the fuel flow rate. OK? Now, I have ignored the non linear areas
>for simplicity and the fact that you should not be working it that area, so
>please leave that out of the argument.

I thank Peter for clarifying that when he wrote about "off pulses" he was simply 
describing the time when current flow to the injector is shut off, a different yet 
equivalent way of looking at things.

Definitely, a small enough "off pulse" would not affect fuel flow.  I do not disagree 
with 1.5ms as a ballpark figure.  I know that the open and close times are likely to be 
different from each other, because the physical situations are not symmetrical, but the 
total open time + close time should be practically the same regardless of pulse width if 
the pulse width is above a minimum.

Incidentally, Nomura and Irino show that the time it takes for the injector to close 
after the current to it is shut off varies a lot depending on how much current was 
flowing through the injector at the time.  A graph in the above paper shows a closing 
time reduction on the order of 30-50% from maximum near a particular current level.  
This phenomenon is present with both saturated circuit and peak-and-hold drivers.

As another aside, an engineer at Bosch warned me against running injectors at 100% duty 
cycle for any appreciable period of time.  Not that it can't be done, it's just that  
they overheat and begin to operate erratically.  75%-80% is more like it and is 
supposedly the proper figure to use when sizing the injector.

>Finally, as to dynamic range, [snip]

Peter's discussion describes the minimum and maximum pulse widths to which the injector 
is required to respond.  This is the first half of the dynamic range issue.  Andrew 
Dennison additionally addressed the second half with his discussion of the precision of 
measurement:

>What my question was effectively asking was:
>If you have a pulse of, say, 1.5ms what is the noise (repeatability)
>associated with this pulse?  Is it 1.5ms +/- 0.1ms, 0.01ms or
>0.001ms??
>If it is 0.1ms and we have a (design) maximum pulse width of 10ms
>then the timer only needs a resolution of 100 steps (approx. 7 bit
>resolution or 42dB).
>OR:
>100ms pulse with 0.01 resolution: 10000 steps (14bits or 84dB).
>
>This argument comes from normal Signal to Noise calculations, you
>could also use this to decide if you need a 10bit A/D on your MAP
>sensor or if 8 bits is enough.

At some point the noise in the system will make indistinguishable the actual flow 
resulting from pulse widths of nearly identical lengths.  You can use statistical 
methods to determine whether one pulse width truly delivers a different flow volume than 
another pulse width.  Pursuing this analysis across the entire range of minimum and 
maximum pulse widths looking for pulse widths that generate statistically different flow 
volumes will lead you to a finite list of pulse widths that are distinguishable.  
Counting them up will tell you how many bits you need to enumerate them.  As Andrew 
points out, if there are 10000 distinguishable pulse widths, you can assign a unique 
binary number to each using numbers of no less than 14 bits.  You can simplify the 
process if you know, say, the maximum standard deviation (a measure of repeatability) of 
flow volumes at the worst case pulse width.  The larger this standard deviation, the 
fewer bits you can use (or will benefit from using).

Now I remember!  While at school I got some information about standard deviation of fuel 
flows as a function of pulse width for a particular injector.  I'm not sure I can find 
it anymore.  What I remember is that the standard deviation of fuel delivered at a 
particular pulse width was "very small" for pulses in the normal operating region and 
increased significantly at the low end.  If I dig up the exact figures I'll post them, 
but no promises because I really have no idea where they are anymore.

-------------------------------------------------------
Ed Lansinger
General Motors Powertrain
Powertrain Control Center
Premium V Software & Calibration Group
Milford Proving Ground, Milford, MI
elansi01 at mpg.gmpt.gmeds.com  8-341-3049  (810) 684-3049
-------------------------------------------------------





More information about the Diy_efi mailing list