maximum ON before damage

John Dammeyer johnd at autoartisans.com
Sun Dec 12 20:38:34 GMT 1999


>Date: Fri, 10 Dec 1999 02:48:38 +1100
>From: Phil Lamovie <phil at injec.com>
>Subject: maximum ON before damage
>
>Hi John et al,
>
[snip]
>
>The limiting factor with any injector is the max. time in ms available
>at max. rpm. If that rpm is say 6,000 rpm we have 10 ms total.
>

It's at this point, Phil,  that I must still disagree with you.  I suspect again
that it's somehow a philosophical point.  Can an engine function efficiently if
the injector is fired at an 80% maximum duty cycle over a 720 degree cycle?   I
believe it can so in fact at 6000RPM 720 degrees takes 20ms of which 80% is
16ms.

>If it takes 1.2 ms to open (saturated type) and 1.1 ms to close you
>only have 7.7 ms left. Just to make things difficult the first period
>of 1.2 ms has NO flow. So really that 2.5 ms lower limit (for
>stability's sake)
>means you have 2.5 -8.9 ms to play with.


Now,  given that I have engine logs of the behaviour with stock Honda Injectors
operating at 2.0ms at idle and the O2 sensor dancing around 0.5V (Stoich?), and
the engine idles smoothly I'd say that for the first 1.2ms there is some flow.
In fact,  according to one of the papers I have,  the amount of flow is, (at an
average),  66% of the injector flow rate.  This means during injector open time,
of 2.0ms for example,  the injector behaves as a 16 lb/hr injector.  Now using
our injector cleaner,  with 40psi on the injector pump,  I've watch a consistant
and repeatable amount of fuel be dispensed from an injector running at 2ms.
I've yet to do an experiment to determine the minimum pulse width before fuel is
dispensed but you are probably right;  1ms is probably pretty close.  This
minimum pulse width is not only due to the mechanical aspects of the injector
but also due to the injector inductance.  It takes a certain amount of time for
the current to build up and if this is longer than the pulse width,  you'll
never see the injector coil build up enough power to lift the pintle off the
seat.

BTW,  there is no reason that with the same sort of circuit used for saturated
injectors that someone couldn't use a 24 to 48 volt power supply and treat the
saturated type of injectors as PeakHold.  It's the inductance of the injector
coil that prevents the rapid rise of current and increasing the voltage
increases the rate of current rise in the injector.  Once the maximum current is
reach the electronics can reduce the voltage to 12V.  This would have an impact
on the minimum pulse width as now the maximum current may be reached before it's
time to turn off the injector.  If you've got the electronic 'smarts' a
switching power supply that can take 12V and step it up to 48V would do the job.

>Once again I must ask are you pulsing once per revolution or every
>second  / If once your figures don't add up. If every second your
>choice is incorrect. The sequence is not an issue. How often do you
>fire No. 1 injector ?


As I stated earlier,  I inject each cylinder once per engine cycle with a pulse
rate from approximately 2.0ms up to 12.8ms using the stock Honda 24lb/hr
injectors;  we get about 126HP and peak torque is as per the engine curve as
stipulated by Honda.  With 28lb/hr Lucas Injectors my minimum injection time is
reduced a bit,  the engine still idles smoothly and my torque is also still
where it's supposed to be.  My top end RPM goes up from 6600RPM to 6800RPM and
my HP is now at 135HP.  Above 6800RPM my ignition REV Limitor cuts in and
prevents further excursions.

>
>If you apply a table with load vs rpm values instead of you falutin'
>volumetric eff. table you would find that the map sensor response of
>1-3 ms is sufficiently fast to react within 1/4 of a revolution even
>at moderately high rpm. If your code does a run through in under 10 ms
>
>you will never miss more than 1 p/w correction.
>
>You might be in the middle of an output event as the vacuum drops but
>most throttle movements  take  200 - 300 ms from start to finish and
>thus many injection cycles b/w start and finish.


That's a good point.  I'm into a Heisenberg type situation here where if I log
from the engine controller any faster to get better resolution I will be
impacting the injection cycles or the higher speed output from the engine just
won't show up.  My alternative is to put a data acquisition system on the engine
and log on a 100uSec interval all my sensors including my Hall Effect CAM
sensors.  I use two sensors under the CAM shaft timing pulley with magnets on
the pulley to give me a Grey Code 2 bit output to identify which cylinder is on
what part of the cycle.  However,  I don't think my client wants to pay for
that,  they just want an acceleration that works.  Catch-22.

>As to the 40 ms pulse... I don't think so. The maximum fuel required
>is more a function of poor combustion at low rpm than anything else
>but given a max. p/w of 8.5 at 6000 rpm then the pulse width at full
>load 1000 rpm  would be 8.5 plus the excess fuel required due to poor
>tumble, swirl, vaporization etc. etc. Probably no worse than 4 -5 ms
>extra will be required. Don't forget to decay this in proportion to
>the rate of change of rpm (derivative of PID )


I still disagree with your maximum pulse rate but in either case,  the point is
well taken.  How much extra fuel is required when the throttle is suddenly
opened and the MAP goes from 9" to 29".  My sensor acquisition loop is more than
fast enough to calculate new values at an idle speed so it's more a matter of
figuring out how much extra fuel to pour in.  And yes,  I do decay the
enrichment.
>
>This still points to a short coming that you have imposed with your
>12.7 ms upper limit.   Full load plus cold air plus cold water plus
>acc enrichment will put you badly in debt even at low rpm.


I suspect you are correct.  My next experiment will set in max PW as a dependant
parameter of RPM so that at low RPM I will be able to increase dramatically the
amount of fuel and at high RPM not have my software blow up if the requested
pulse rate is too long.
>


Cheers,

John





More information about the Diy_efi mailing list