Possible way to measure injector characteristics

[Singletree5990]

I don't know if anyone has tried this yet, but I had an idea about how to
empirically determine, for a given car, the values of:
- parms[injectorSettleTimeIdx]
- parms[microSecondsPerGallonIdx]

(I've looked through the EcoModder forums a bit, but did not notice anything
regarding it. I apologize if this is old hat.)

A fixed 500usec is currently coded for injectorSettleTime. This variable
is used to compensate for the time difference between;
- the electrical pulse length applied to an injector
- the length of time that the injector effectively squirts fuel.

A more accurate value for injectorSettleTime and microsecondsPerGallon
promises to improve MPGuino tank-to-tank accuracy, as a driver's ratio
of city:highway driving varies.

I haven't tried this yet so I don't even know how well it might work.

If anyone has time, I would ask for your feedback regarding this proposed method:

Step1: Modify the void "doDisplayCustom" as follows, in order to read out the
number of injector pulses.
void doDisplayCustom(){displayTripCombo('N','P',injPuls es*1000
,'S',instantmph(),'G','H',instantgph(),'C',current .mpg());}
(Does the above code look like it would work?)

Next enter best guesses for injectorSettleTime and microSecondsPerGallon.

Then take two very different "trips":
Trip 1) Idle the car for 90 minutes. (short average injector pulse lengths,
might want to bring some reading material for this trip)
Trip 2) Drive the car at max legal speed on the highway for about 40
minutes (long average injector pulse lengths)
(NOTE: Start and end each trip at the same gas station, one located just
off of the highway.)

Before each "trip":
1) top off the car with gas
2) perform an MPGuino "tank reset"

After each "trip":
1) record the total number of injector pulses (injPulses)
2) record the "tank gallons" (from "tank gallons" you can derive the
MPGuino injector "on time".)
3) top off the tank with gas and record the actual gas consumed.
4) perform an MPGuino "tank reset"

Armed with this trip information, the following two equations could be solved
for their two unknowns.

Ton1 + (ISTgi - ISTsf) * Npulse1 = uSPGsf * Gal1 [from trip 1]
Ton2 + (ISTgi - ISTsf) * Npulse2 = uSPGsf * Gal2 [from trip 2]

Where...
TonX = Total injector "on time" for each trip
(equals MPGuino "Tank Gallons" / initially guessed
microSecondsPerGallon)
ISTgi = InjectorSettleTime value guessed initially
NpulseX = Total number of injector pulses (as read from MPGuino after
each trip)
GalX = Total actual fuel consumed for each trip (from fuel gas station
receipt)

uSPGsf = microSecondsPerGallon variable to be solved for
ISTsf = InjectorSettleTime variable to be solved for

One could possibly collect this same data for each subsequent tank of gas
and perform a least squares fit to gain the best values.

Let me know what you think...


(I would like to try this but am still awaiting my MPGuino kit from Fundamental
Logic. I also have not yet attempted to use the Arduino software
development environment, to make sure that I can reprogram the
ATmega168.)


- Singletree5990

[dcb]

Let me understand, for a given number of pulses and injector open time, you can have multiple combinations of injdelay and us/gal that result in the same indicated quantity of fuel delivered.

What you are saying is record them for multiple trips and see if there is only one combination of injdelay and us/gal that works for all the trips.

Not a bad idea. I'm not sure how much return this will bring in terms of accuracy or what percentage of people will bother. But it is a good acedemic exercise at the least. You will have to be extra consistent on everything at refill time i.e. make everything the same, pump #, location and position in relation to pump , time of day, temperature, nozzle angle and insertion, 1st click, amount of deadweight and it's location in the car, suspension settling, etc. etc.

But the trips themselves should reflect very different driving styles, though the system voltage should somehow stay consistent.

Also note that somewhere, the injector parameters may be published including time to open at different voltages.

[dcb]

I would suggest changing tDisplay thusly (so current and tank data screens show injector pulses in the upper left instead of mph) :

PHP Code:

//arduino doesn't do well with types defined in a script as parameters, so have to pass as void * and use -> notation.      
void tDisplay( void * r){ //display trip functions.        
  Trip *t = (Trip *)r;      
  LCD::gotoXY(0,0);LCD::print("IP");LCD::print(format(t->injPulses*1000));LCD::print("MG");LCD::print(format(t->mpg()));      
  LCD::gotoXY(0,1);LCD::print("MI");LCD::print(format(t->miles()));LCD::print("GA");LCD::print(format(t->gallons()));      
} 


[Singletree5990]

dcb,

Thank you very much for your response, and your advice.

I'm very impressed with the kind, helpful, humble, and extremely
technically competent EcoModder culture, which your colleagues, and you
especially, emulate.

As you mentioned, this refinement may not make much of a difference, but I
do wonder how the effective injectorSettleTimes might compare to 500usec.

As soon as I collect the data on my 1993 Volvo, I will post it in this thread.

To address the system Voltage concern, I'll plan to measure the system
Voltage at the start and end of each "trip". That will give me the option of attempting a correction if necessary.

I may be back asking for help if I have trouble getting the Arduino
environment and/or programming capability setup and working.


Thanks and regards, Singletree5990

[Singletree5990]

Here is the latest on my progress...

I received and constructed my MPGuino kit without
issue.

Using the Arduino software environment I modified
the ATmega168's firmware, With the code change you
recommended, plus another one as well to directly
track the following variables:
- tank.injHiSec
- tank.injHius
- injPulses

These code changes worked well.

Following your suggestion, I looked further into the
effects of:
- Fuel Temperature:
- Gasoline's coefficient thermal expansion =
950ppm/deg K, which is rather large. I added
a thermometer to monitor the fuel temperature
during fill-ups to allow compensation for this.
- Battery Voltage:
- I made oscilloscope measurements to
understand how much the injector delay was
affected by battery Voltage.
- By powering the injectors with a separate
power supply, connected to a big honkin cap,
and using my oscope, I was able to look at
how the injectors' delay-time varied with
Voltage by measuring the change in time that
their "pintle humps" appeared.
- (see http://www.motor.com/magazine/pdfs/012005_04.pdf
for a great explanation about interpreting
injector oscope plots.)
- These measurements indicated that the injDelay, on
these injectors, would drop by about 155usec for
each one-Volt increase in battery Voltage.

I modified my MPGuino code to measure battery Voltage (Vbat)
using the ATmega168's ADC. This allowed me to compensate for
injector delay as battery Voltage varied. (I have attached
a copy of my latest code. This mod also required the
addition of a resistor divider and two capacitors on the
MPGuino circuit board.)

I have not yet performed my two-trip injector calibration.
(This has now become a three trip calibration since I
now have three variables, due to the fact that my inj delay
now includes a Voltage coefficient.)

As a side note: I did encounter what I suspect was an issue
with Arduino-0011 properly handling statements to modify
bits within the ADCSRA register.
I was trying to write "00000101b" by using
different permutations of
"ADCSRA|=((1<<ADPS2|1<<ADPS0)&!(1<<ADPS1));"
but had to resort to
"ADCSRA=5;"
to achieve the desired value in the register.



Thanks and regards, Singletree5990

[dcb]

Very cool, added a mention to the guino hacks page:
Code hacks - EcoModder

[Madact]

Originally Posted by Singletree5990

As a side note: I did encounter what I suspect was an issue
with Arduino-0011 properly handling statements to modify
bits within the ADCSRA register.
I was trying to write "00000101b" by using
different permutations of
"ADCSRA|=((1<<ADPS2|1<<ADPS0)&!(1<<ADPS1));"
but had to resort to
"ADCSRA=5;"
to achieve the desired value in the register.

Very old thread, I know, but just for the benefit of anyone coming across this bit: "!" is a "boolean not", and will return 0 (false) if the operand is non-zero (true), and 1 (true) if the operand is zero (false). You were probably thinking of the operator "~", which is binary inverse.