LT1 $EE injector pw floor with Deka 80s

[Catmaigne]

Hi,
I've been having some issues lowering the injector pulsewidth floor in my current $EE/$EEXtra tune. The gist of my setup is a built 383 LT1 with a Procharger D1 and Siemens Deka 80 injectors. The tune is 2bar speed density in open loop and it drives decent, but there are a few kinks in the tune I'm trying to iron out.

It seems like I'm hitting a boundary in the tune that won't allow the pulsewidth to dip any lower than 1.24ms, even though I've had the min pulsewidth set at 1ms or less the entire time. This is causing the car to run super rich (10.5-12) under light throttle conditions just above the TPS threshold for DFCO. I realize that I could just raise the DFCO threshold until it goes away, but that would create a decent sized dead zone in the pedal that I'd like to avoid. Here's a graph from eehack:
eehackgraph1.jpg

Graph of the left inj pw from the same log in excel. You can see the line at 1.24:
injpw.jpg

What I've tried:
-The min pulsewidth has been set at 1ms since the beginning, but I lowered it to 0.73ms and saw no change
-I changed 126d7 'use this value when min inj pulse reached' to match the min pulsewidth and also saw no change
-I zero'd the low pulsewidth table (129f5), but nothing changed so I set it back to the data I found for the 80's
-I tried the 'low pulse injector extend hack' patch hoping it would lower the min pw, but it's still stuck at 1.24ms

Snippet from the current tune:

tunesnapshot.jpg

Any ideas? I've been using a combination of $EE, $EEX, and various versions of $EEXtra to tune this thing and am not sure what else to try. I think I've been using this one primarily:
EEXTRA v0[1].001[MOD_V0005_03_02]V8.xdf

[kur4o]

WIth the patch applied you need to set up this table with correct data in the patch folder.

low pulse inj width correction

Are you sure the commanded pulse width is not a function of measured airflow rather than injector ceiling.
I will look at the dissasembly to see where if there is some other hardbuild limits.


The main injector offset vs voltage is not seen in the log, so you got +0.6ms added in the tpu.

[Catmaigne]

WIth the patch applied you need to set up this table with correct data in the patch folder.

low pulse inj width correction

Gotcha, that table is all 0's as I never set it up. I misunderstood what the patch was intended for, and I'm guessing it's just an extension of the low pulsewidth adder table into higher pulsewidth ranges? Maybe for something like RTT? Regardless, it's not what I'm looking for.

Are you sure the commanded pulse width is not a function of measured airflow rather than injector ceiling.
I will look at the dissasembly to see where if there is some other hardbuild limits.


The main injector offset vs voltage is not seen in the log, so you got +0.6ms added in the tpu.

I went back and reviewed a bunch of older logs and they all show the pulsewidth bottoming out at 1.24ms. I've played with the VE tables a million times since I got the car on the road, but the floor never changes. The 1.24ms floor also pops up at varying RPM/MAP ranges that are just outside of DFCO but not quite accelerating, so I don't think the issue is with the commanded fueling. Here's a left-pw graph from months ago, you can still see the same cutoff:

plot2.jpg

I'm guessing there's a hard limit somewhere that I don't know about. Have you heard of anyone running pw's down in the low 1ms range or lower (logged) on the stock pcm? Also, if the voltage offset isn't accounted for the in log, does 126d5 'min injector pulse' set the limit before or after the offset is added?
Thanks for your help.

[kur4o]

The bpw in the log have no corrections applied to them.

It is the calculated BPW from airflow and fuel flow corrected with BLMs is what you get in the logs.

Than individual cyl trims are applied for each cylinder, Than low pulse offset is added again for each cylinder.
Here the min inj pulse is used.

The main voltage offset is applied in the tpu so main processor have no control over it.

There is a bit set when min inj constant is used. If you log it you will know for sure if it is reached or not. Tside byte_AA bit 6[$40].

[Catmaigne]

The bpw in the log have no corrections applied to them.

It is the calculated BPW from airflow and fuel flow corrected with BLMs is what you get in the logs.

Than individual cyl trims are applied for each cylinder, Than low pulse offset is added again for each cylinder.
Here the min inj pulse is used.

The main voltage offset is applied in the tpu so main processor have no control over it.

There is a bit set when min inj constant is used. If you log it you will know for sure if it is reached or not. Tside byte_AA bit 6[$40].

Gotcha, the bpw in the log should be coming straight from the VE and OL AFR tables then considering I'm running open loop & speed density.

Even though this stuff shouldn't matter for logs, the cyl trims are all set @ 1 on throttle, and playing with the low pulse table and min pw values hasn't affected anything.

How do I go about logging that bit? I played with an adx in tunerpro, but I'm not sure what I'm doing when it comes to picking apart the datastream. I searched around for instructions on how to log custom parameters like that, but I'm still lost. It sounds like my issue is occurring before hitting those min pw thresholds though, but I could check that bit just to be sure.

[kur4o]

You can get eehack, there is a raw window where you can get any ram location with some mode3 custom command.

Type in

03 00 aa

and it will get you the value of byte_aa.

You can loop it and drive around to get the condition. than we can find if the bit got set.

this one is the easies way to log it. Unfortuntelly other data won`t be available.

The BPW is derived from measured or calculated airflow fuel flow and commanded AFR. It is some 8 bit calculation so this might be some limit of the way it gets calculated. That 1.24ms is around $50 in hex, which can be some limit of the math anyway.