The ultimate LT1 $$EE patch thread

[NomakeWan]

So the Injector Offset Adder is the only table in $EE that I'd need to worry about? Sweet!

The injectors aren't stock GM, but they do have really awesome data. I got them from FIC, so they have really great data tables. The one I was sent was already configured for 43.5 PSI and E10 fuel, even, which was nice. And thanks to that spreadsheet from dzidaV8 it should be pretty easy to translate their data into your patch tables. Thanks again!

Okay, so after messing with this, I just want to make absolutely sure I'm doing it right. I found this discussion by 84Elky over on ThirdGen regarding the calculation for voltage offset, noting that GM apparently applies the value twice. Here: https://www.thirdgen.org/forums/diy-...ml#post6346200

I found that for my injector data, I have some times as high as 5496.246 microseconds in my datasheets, but the LS Inj patch only allows a maximum of 3891 (FF). Is this a limitation of the calculation, or should I be dividing all of my numbers by 2 before putting them in?

[steveo]

I found that for my injector data, I have some times as high as 5496.246 microseconds in my datasheets, but the LS Inj patch only allows a maximum of 3891 (FF). Is this a limitation of the calculation, or should I be dividing all of my numbers by 2 before putting them in?

you'd only divide by two if your xdf's conversion to usec was incorrect

if you're talking about injector vs voltage offsets, you only really have to worry about the data in the lets say 11.5-14.5v range.

if your injector's supply voltage goes outside that range it's because something is broken, so having incorrect values in those areas is the least of your concerns, you will be 'limping' anyway.

pretty common for datasheets to have crazy values outside of operating range

[kur4o]

3891 (FF) is 8 bit limitation, so that is the max you put for these cells. I guess they are in very unusual conditions so you don`t have to worry about it.

I suggest you apply the

low pulse injector extend hack
patch too
and fill the
low pulse inj width correction
table
It gives better resolution for low pulse conditions.

One other limitations is there is no negative values possible, so if you have negative values you can set that cells to 0.

The low pulse offset adder is done by eside cpu, but the main offset is handled by tpu so nobody knows how it is done.

Since I have already run the patch for long enough time, the provided sample tables have been tested well enough and you can use them for reference.

[NomakeWan]

Okay cool, I wanted to make sure. 84Elky noted the 8-bit limitation in his description as well, but that to get around it, GM engineers had the routine run twice back-to-back so it could get twice the maximum value.

I had a feeling that the patch just cuts off those top values since the voltages are so low, but like I said, just wanted to be 100% sure before flashing. I've gone ahead and applied all the patches and filled in all the tables. I won't be able to test the new injectors for a little bit, but definitely looking forward to it! Thank you again!

[kur4o]

Any feedback will be greatly appreciated.

If for some reasons pcm reads less voltage than actual, I have some other versions that can be run. Reading voltage directly from injector circuit, on a spare pcm pin.

If you change substantially the fuel flow, consider adjusting the prime pulse tables. We have a very good write up about it on some thread here.

I also have some version with fixed fuel flow on startup, because I decided that the patch was the issue for first longer crank issues I had, which proved not to be the case.

[Rocko350]

Good stuff, Good Stuff. Not really back to EOIT stuff, more of a question. Can the coolant axis for the lookup table for EOIT be pointed at rpm instead of coolant temp? The coolant temp reasoning from gm was to aid in cold engine warm up. The LT4 table allowed the hot cam to run in that car without tuning. We all know it wasnt great, but it got the job done. (6.0 in the entire table) Some really aggressive lobed cam combos i VE tuned were in the upper 90s and were wanting more than 100% in some cells. Clearly not possible. Those two got engine size upped a bit and fueling rescaled to get the numbers needed in the VE table. I know its not a huge deal for some. Ive backed off cam choices in some later builds to keep from doing a bunch of stuff like that. Two of the over 400" ones i was using 6.3 in the tables to make the upper rpm happy. near 20% in the idle area of the tune. I ended up going to an 65 lb/hr injector so i could get it to idle clean with such a narrow window of injection time. The stroke in them helped a bunch.

Again, you guys ROCK! I never got to get into the software this deep.

Chris

[kur4o]

I was also thinking about some rpm modifier for eoit target, but refreshing that realtime will be useless. Since there is some scalars so eoit target don`t jump off like crazy but update slowly overtime. Eoit is also handled by TPU and it is really hard to tell what is in there. If you are willing to test some quick patch can be made, but the outcome will be unknown. LT4 calibration have some extra map for baro but nothing rpm related. At some higher rpm the injector using 85+DC% will be on almost all the time, You will need some real big fat ones to make a use of EOIT target properly. I did some calculations for the max dc% to make any use of it. For a full 720* of crank you have 20ms time at 6000rpm, remove the degrees for a intake duration, to get the needed ms time for an injector.

Actually eoit temp compensation for startup and warmup is much more important than you think. I did some extensive testing to overcome a lean hole at some specific temp window, and still it is not dialed the way I wanted. Making the eoit target logic a little doubtful and not great to play with. I think there is some synchronization logic that goes out of sync for some specific conditions, and it needs some time to reset.

I think some higher rpm adder can be made, after engine has been warmed, that is used above some certain rpm points. We can make it refresh each low res pulse so it follows quickly. How that will be interpreted by tpu is in question.