O'scope injector PW + MPSCAN + OTC2000!

[acannell]

In an effort to help solve the mystery of why we cant get accurate injector pulse width data via MPSCAN (not MPSCAN's fault, we just dont know the right variable or something),

I hooked up a scope to an injector, and simultaneously monitored what MPSCAN said INJPW was, and also, what my OTC2000 said the injector pulse width was.

I did this at idle, heres the results:

RPM: Approx 960 (bounces around 20 rpm)

Oscilloscope injector pulse width: 1.56ms

Oscilloscope injector leading edge to leading edge time: approx 124ms +/- a few ms (bounces around with rpm a bit)

MPSCAN INJPW: 0.46ms

OTC2000 injector pulse width (data line mode 3): 1.8ms

INTERESTING EH?

According to the scope thats a duty cycle of about 1.2% for that injector.

Now the way I measured the pulsewidth using the scope was by placing the probe across the exposed pins on the back of the injector connector, and then using cursors to measure the positive part of the pulse, as shown in the pics. However, the true pulse width may be a bit longer, if you look at the scope trace, you can see (cut off) that the pulse rings a bit. That could make it 1.8ms which would match the OTC2000.

So if the OTC2000 can somehow figure out the pulsewidth correctly, then it must be possible with MPSCAN. Perhaps we could monitor the datastream to the OTC2000 and see what variables its reading from the ECU. Or ???

[acannell]

a sort of obvious conclusion would be that 1.8ms (OTC 2000) divided by 4 = 0.45ms (MPSCAN INJPW)....it cant be that simple right?

[acannell]

a sort of obvious conclusion would be that 1.8ms (OTC 2000) divided by 4 = 0.45ms (MPSCAN INJPW)....it cant be that simple right?

and at 960 rpm, lets see here...

960rpm / 60 = 16 revs per second

1/16 = 62.5ms per rev

gee whilikers batman that looks like half the measured leading edge to leading edge time of about 124ms...

so I suppose at this point we can take INJPW from MPSCAN and convert it to actual injector on time..

in this case, looks like each injector is spraying for 1.8ms out of every 125.8ms, (124ms + 1.8ms)..a duty cycle of 1.4%

so with stock 33 lb/hour injectors at stock fuel pressure, I guess that means 1.4% of 33 lbs per hour, times 4 (4 injectors) = the mass fuel flow rate

OR

1.848 lbs per hour

tada!

that doesnt account for precise fuel density or precise fuel pressure, but its close enough..

hmm...wait a second I think I can now take my datalogged injector pulse width and figure out fuel flow rate for my logged runs!!!

[acannell]

actually theres a little possible error in the way im doing that

I dont have a PRECISE number for the leading edge to leading edge time because the rpm bounces around 20 rpm..so when I say something like 124ms + 1.8ms thats not really true...I think the true available on time for each injector should just be 1 / (RPM/60) * 2

[wallace]

Could mpscan be subtracting the injector dead time?

[ShelGame]

The scantool PW is the same PW we're sending back to MP Scan. The difference is, I think we must have the wrong scaling factors on the tables. It's just 16-bit value. The scantool obviously scales it correctly, and we do not.

I've gone thru the math many times, and I can never get to that time.

- - - Updated - - -

Could mpscan be subtracting the injector dead time?

MP Scan can't subtract it. But, it's not included in the output value either(since it's not actual fuel flow time, only open/close ramp time for the injector).

[ShelGame]

Also, the SBEC has a 'base PW' and then the individual cylinder PW's. Each cylinder can have a 'trim' value if needed. Not sure if your OTC is logging the trimmed value or the 'base' value. I assume base since it doesn't specify the cylinder being displayed.

[acannell]

Also, the SBEC has a 'base PW' and then the individual cylinder PW's. Each cylinder can have a 'trim' value if needed. Not sure if your OTC is logging the trimmed value or the 'base' value. I assume base since it doesn't specify the cylinder being displayed.

hmmmmmmm that makes sense

the otc also has an option to monitor "adapt fuel pulse width" and "adapt fuel pulse mult factor"...but not for individual cylinders..those sound like E85 stuff anyway right?

well one things for sure, the traveler which shows MPG must be able to get precise fuel flow data via the CCD/SERIAL bus..so its in the ECU somewhere

so at the very worst, the answer is locked inside the traveler and/or the traveler/ecu relationship

[acannell]

also one more thing..individual cylinder injector PW trim would only come in to play with data from the knock sensor right? so if i had my knock sensor unplugged can I assume the BASE PW is what was used for the data I took?

- - - Updated - - -

heres my attempt to backcalculate air flow rate in CFM and volumetric efficiency..

this is probably only accurate +/- 20%..maybe 10%..

it assumes alot of things:

that true injector FLOWING duty cycle is:

(INJPW * 4) / ((1/(RPM/60)) * 2)

INJPW as reported by MPSCAN

[cordes]

Tektronics scope?

[acannell]

Tektronics scope?

yesirre bob!

[ShelGame]

hmmmmmmm that makes sense

the otc also has an option to monitor "adapt fuel pulse width" and "adapt fuel pulse mult factor"...but not for individual cylinders..those sound like E85 stuff anyway right?

well one things for sure, the traveler which shows MPG must be able to get precise fuel flow data via the CCD/SERIAL bus..so its in the ECU somewhere

so at the very worst, the answer is locked inside the traveler and/or the traveler/ecu relationship

Bringing out the dead...

"adapt fuel..." is the adaptive fuel PW.

The SMEC/SBEC send data to the traveler differently. The SMEC send a pulsewidth out the single wire. It's proportional to the injector pulse, but not the same value.

The SBEC sends a value out the CCD bus.

[ShelGame]

also one more thing..individual cylinder injector PW trim would only come in to play with data from the knock sensor right? so if i had my knock sensor unplugged can I assume the BASE PW is what was used for the data I took?

Individual trims are by O2 feedback, not knock.

[5DIGITS]

Also, the SBEC has a 'base PW' and then the individual cylinder PW's.
Each cylinder can have a 'trim' value if needed.
Not sure if your OTC is logging the trimmed value or the 'base' value.
I assume base since it doesn't specify the cylinder being displayed.

Rob,
The per cylinder control applies to the knock retard and non-adaptive unless the use of the short-term vs long term knock tables is considered 'learned'.
The fuel control relies on a globally adjusted long-term array based on MAP vs RPM table.
The short-term (instantaneous) adjustment may appear as a cylinder based adjustment but is limited to delayed O2 feedback of all four cylinders and impacts a global adjustment, regardless of banked or sequential injection.

* R1 CELL-ID
* -------------------
* 0 1
* MP1 ---------+---------
* 2 3
* MP2 ---------+---------
* 4 5
* MP3 ---------+---------
* 6 7
* MP4 ---------+---------
* 8 9
* MP5 ---------+---------
* 10 11
*
* IDLE ------- 12 --------

[ShelGame]

Rob,
The per cylinder control applies to the knock retard and non-adaptive unless the use of the short-term vs long term knock tables is considered 'learned'.
The fuel control relies on a globally adjusted long-term array based on MAP vs RPM table.
The short-term (instantaneous) adjustment may appear as a cylinder based adjustment but is limited to delayed O2 feedback of all four cylinders and impacts a global adjustment, regardless of banked or sequential injection.

* R1 CELL-ID
* -------------------
* 0 1
* MP1 ---------+---------
* 2 3
* MP2 ---------+---------
* 4 5
* MP3 ---------+---------
* 6 7
* MP4 ---------+---------
* 8 9
* MP5 ---------+---------
* 10 11
*
* IDLE ------- 12 --------

Ken - In the SBEC, each cylinder has it's own individual pulsewidth; which is the sum of the main calculated PW and each cylinders individual O2 trim value. The V6 does something similar, but the trims are bank-to-bank.

I didn't see anything like this in the SMEC. It has only a global trim based on O2.

I haven't quite figured out how the SBEC knows how to trim each cylinder differently. I would assume that the latency in the O2 signal would be too high to be used as an effective trim, but it appears that's what it does. Do you know how the SBEC determines which cylinder gets what trim value?

[5DIGITS]

Ken - In the SBEC, each cylinder has it's own individual pulsewidth; which is the sum of the main calculated PW and each cylinders individual O2 trim value. The V6 does something similar, but the trims are bank-to-bank.

I didn't see anything like this in the SMEC. It has only a global trim based on O2.

I haven't quite figured out how the SBEC knows how to trim each cylinder differently. I would assume that the latency in the O2 signal would be too high to be used as an effective trim, but it appears that's what it does. Do you know how the SBEC determines which cylinder gets what trim value?

It's kinda crude and somewhat erroneous/misleading.
What you said is true - the O2 latency doesn't support having unique cylinder to cylinder PW adjustments.
Since its dealing with sequential injection, at the time the PW is being pulled and calculated before the next edge trigger the PW includes the last short term O2 feedback adjustment.
This 'appears' as variations in PW delivery but will ultimately result in only one global long term adjustment based on the array limitation of RPM vs MAP for all cylinders.
This is how it misleadingly shows varying PWs from cylinder to cylinder.

On a side note:
The above is sensitive to where the MAP and RPM breakpoints are set and why adaptive control typically becomes unstable with 3bar and higher MAP sensors, due to the break-point definitions and poor resolution.
Because the preceding short term trim appears in the current cylinder PW calculation, any fluctuation in MAP or RPM causes corruption as the adaptive moves to a different cell location in the array.
This results in adaptive 'hunting' and the values never stabilize/normalize and repeatedly learn up and down as the car is driven and bounce between cells.
For any car running 22psi or less on the street, I have always recommended a 2.5 bar MAP and careful selection of the MAP/RPM array breakpoints to minimize these instabilities.
In short, simply converting the MAP values to a 2.5, 3.0, or higher MAP sensor doesn't won't work well if the hardware (head, cam, intake,etc..) have all altered the flow and tuning of the 'system'.
Also, the delta MAP inhibitors need to be adjusted to eliminate any transient throttle/MAP fueling from being included into the adaptive fuel calculation.
This will unfortunately slow the adaptive fuel updates BUT will help stabilize the final learned values by reducing transient fuel corruption.
My previous project using a 2.5 Bar sensor took a week of evening work and data collection just to select where the breakpoints and transient inhibitors needed to be set for 'centered' stable learning.
This will all reduce the cylinder to cylinder variations discussed above while improving the overall stability of the system.

[ShelGame]

On a side note:
The above is sensitive to where the MAP and RPM breakpoints are set and why adaptive control typically becomes unstable with 3bar and higher MAP sensors, due to the break-point definitions and poor resolution.
Because the preceding short term trim appears in the current cylinder PW calculation, any fluctuation in MAP or RPM causes corruption as the adaptive moves to a different cell location in the array.
This results in adaptive 'hunting' and the values never stabilize/normalize and repeatedly learn up and down as the car is driven and bounce between cells.
For any car running 22psi or less on the street, I have always recommended a 2.5 bar MAP and careful selection of the MAP/RPM array breakpoints to minimize these instabilities.
In short, simply converting the MAP values to a 2.5, 3.0, or higher MAP sensor doesn't won't work well if the hardware (head, cam, intake,etc..) have all altered the flow and tuning of the 'system'.
Also, the delta MAP inhibitors need to be adjusted to eliminate any transient throttle/MAP fueling from being included into the adaptive fuel calculation.
This will unfortunately slow the adaptive fuel updates BUT will help stabilize the final learned values by reducing transient fuel corruption.
My previous project using a 2.5 Bar sensor took a week of evening work and data collection just to select where the breakpoints and transient inhibitors needed to be set for 'centered' stable learning.
This will all reduce the cylinder to cylinder variations discussed above while improving the overall stability of the system.

I agree with this completely. And, I've suspected for a while that this is why the 3-bar 2.2 cals idle richer than they should - they are running in the wrong cell at idle. But, I haven't done the calculations to demonstrate it, or to adjust the breakpoints to correct it.

[5DIGITS]

I agree with this completely. And, I've suspected for a while that this is why the 3-bar 2.2 cals idle richer than they should - they are running in the wrong cell at idle. But, I haven't done the calculations to demonstrate it, or to adjust the breakpoints to correct it.

This involves another element when talking specifically about the idle cell.
Use of higher MAP levels typically coincides with larger injectors.
The larger injectors become less stable in the short pulsewidth area within their flow curve.
This introduces inconsistent fuel delivery regardless if the pulsewidth is held constant.

There is a trick to overcome most of this!
On cars that do not run a catalytic converters, change the idle spark advance to a lower value.
This will increase the operating MAP at idle and move the PW up into a more stable/consistent fuel PW range.
The corresponding MAP values to declare the idle cell will also need to change to keep you from triggering into part throttle cell adaption.
I say without a catalytic converter because the timing reduction along with the increase in MAP will elevate the EGT's.
The catalyst substrate temp and casing, without the air flow of a moving vehicle, is an undesired condition during extended idle periods.

It's kinda crude and somewhat erroneous/misleading.
What you said is true - the O2 latency doesn't support having unique cylinder to cylinder PW adjustments.
Since its dealing with sequential injection, at the time the PW is being pulled and calculated before the next edge trigger the PW includes the last short term O2 feedback adjustment.
This 'appears' as variations in PW delivery but will ultimately result in only one global long term adjustment based on the array limitation of RPM vs MAP for all cylinders.
Also, the delta MAP/THR adjustments are also being updated within the fuel routine and are inclusive to sequential PW delivery.
This is how it misleadingly shows varying PWs from cylinder to cylinder.

Rob,
After re-reading, I should have also included the highlighted sentence within the first explanation because it is also a contributor.

Does the above clarify why the pulse to pulse values vary while the O2 'primary kicks' are also being calculated and included in fuel delivery?