PDA

View Full Version : Big injectors??



turboberserker
August 16th, 2007, 04:21 PM
Hey Guys,

I tried to setup for my 96lbers (@43.5psi) the other day and discovered we can only set the AFR up to 100lbs/hr. Because I run 58psi, I need to set my IFR to 112lb/hr.

Is there a work around for this somewhere or is this the PCM limit?

SSpdDmon
August 16th, 2007, 04:48 PM
Hmmmm....good question. Fudge the displacement?

turboberserker
August 16th, 2007, 06:08 PM
I'm not sure I follow what you mean?

dc_justin
August 16th, 2007, 11:14 PM
Don't think it can be done... You'll have to make up for the added 12#s with a slightly lower VE table and compensated timing tables or de-pressurize your rail by 9psi or so and set it up for 100#...

SSpdDmon
August 17th, 2007, 12:40 AM
I'm not sure I follow what you mean?
Well...if you can only put in for 100lb/hr injectors, then you will be running rich, right? The injector values will be too small and the PCM will think the IPW's need to be longer to maintain the right AFR. If you fudge the displacement (B0104 I think) to a smaller number, then your IPW won't stay open as long. Either dc's or my way should work. But, you're going to have to fudge something.

If you do it his way, you're going to have to change your VE AND your timing tables because the airmass values will be fudged. I believe my way (if calculated properly) should avoid having to change the timing tables since displacement isn't listed as a factor in the cylinder airmass equation in B0101.

Hopefully, someone with some more brains than me will weigh in on this... http://www.motownmuscle.com/forums/images/smilies/lol.gif

dc_justin
August 17th, 2007, 01:22 AM
Well...if you can only put in for 100lb/hr injectors, then you will be running rich, right? The injector values will be too small and the PCM will think the IPW's need to be longer to maintain the right AFR. If you fudge the displacement (B0104 I think) to a smaller number, then your IPW won't stay open as long. Either dc's or my way should work. But, you're going to have to fudge something.

If you do it his way, you're going to have to change your VE AND your timing tables because the airmass values will be fudged. I believe my way (if calculated properly) should avoid having to change the timing tables since displacement isn't listed as a factor in the cylinder airmass equation in B0101.

Hopefully, someone with some more brains than me will weigh in on this... http://www.motownmuscle.com/forums/images/smilies/lol.gif

The logic is sound, but the problem is that the VE table isn't stored in a % of theoretical maximum, which is where the displacement would come into play. The VE is stored in the unique GM VE unit, which is stored as an absolute airmass value with kPa and temperature factored in. As stated in the Description:
EFILive uses the cylinder volume to calculate the VE as a percentage.
Changing the cylinder volume will change the VE percentages displayed in this table.

To see this in action, open up a tune, adjust the cylinder volume some direction by 50% and save as another file. Open another instance of EFILive and open the original tune. Compare the VE tables in the two instances. You must open in a seperate instance, as the load alternate will not recalculate the alternate based on the alternate's cylinder volume.

SSpdDmon
August 17th, 2007, 01:29 AM
The logic is sound, but the problem is that the VE table isn't stored in a % of theoretical maximum, which is where the displacement would come into play. The VE is stored in the unique GM VE unit, which is stored as an absolute airmass value with kPa and temperature factored in. As stated in the Description:
EFILive uses the cylinder volume to calculate the VE as a percentage.
Changing the cylinder volume will change the VE percentages displayed in this table.

To see this in action, open up a tune, adjust the cylinder volume some direction by 50% and save as another file. Open another instance of EFILive and open the original tune. Compare the VE tables in the two instances. You must open in a seperate instance, as the load alternate will not recalculate the alternate based on the alternate's cylinder volume.

I understand it will change the EFI Live calculated VE percentages. But if the VE is shown in grams*K/kPa, how is it affected then?

dc_justin
August 17th, 2007, 01:37 AM
I understand it will change the EFI Live calculated VE percentages. But if the VE is shown in grams*K/kPa, how is it affected then?

It's not affected.

Since VE is in g*K/kPa, it doesn't matter what size injectors you have, what the displacement is or how many cylinders you have. The VE table is a description of air entering the combustion chamber per cycle. If you've got 1g/cyl at 100kPa at 4000rpms at 30*C Charge temp, that equates to a GMVE value of 3.03. You alter the displacement value, and you still have a GMVE value of 3.03. Since displacement is not a factor in converting GMVE to actual airmass, it will not have the intended effect.

SSpdDmon
August 17th, 2007, 01:44 AM
Ok, I see the flaw (I think) in my theory. Changing the displacement will lean out the mixture, but will still change the grams/cyl. calculation too because you are altering the known volume of the cylinder. Fudge the VE and you fudge the numerator (grams/cyl.).....fudge the cylinder volume and you fudge the denominator (grams/cyl.). :doh:


Continue this logic and fudge both....then, maybe you won't have to change the timing???

x/x=1

(grams*x)/(cyl.*x) where x is less than 1

dc_justin
August 17th, 2007, 01:44 AM
So wait, I'm confused. Are you saying it won't work?
I'm saying that changing the displacement value alone will have no effect.

If you were to view the VE table in % units and copy the VE table to the clipboard, change the displacement, save the tune then close and re-open it and paste the VE table back in, the GMVE would be altered appropriately.

Quite a step, I know, I just did it to work it out.

Conversely, alter your displacement, close the tune then re-open and you'll see that the VE % have adjusted to reflect the new displacement with the existing airflow.

dc_justin
August 17th, 2007, 01:46 AM
Ok, I see the flaw (I think) in my theory. Changing the displacement will lean out the mixture, but will still change the grams/cyl. calculation too because you are altering the known volume of the cylinder. Fudge the VE and you fudge the numerator (grams/cyl.).....fudge the cylinder volume and you fudge the denominator (grams/cyl.). :doh:

Not quite... It's grams / cylinder, not grams / cylinder volume... if it was, then displacement would be a factor. As it is, the units are G of air, Temperature and manifold pressure, displacement doesn't play a factor.

SSpdDmon
August 17th, 2007, 02:00 AM
Not quite... It's grams / cylinder, not grams / cylinder volume... if it was, then displacement would be a factor. As it is, the units are G of air, Temperature and manifold pressure, displacement doesn't play a factor.
Damn....

So, you're saying if I double the size of my displacement in B0104, it won't change my AFR to run pig rich?

turboberserker
August 17th, 2007, 02:45 AM
Rats... This is pretty much what I thought but had hoped to avoid -- a complete retune. Or is it as simple as dropping my known VE table by 12%?


Anyone know why this artificial limit is imposed? PCM, OS limit, or software? From another issue, I know there are buffer imposed limits because of how GM put the OS together, but in this case, 100 and 112 fit in the same number of bits so it doesn't seem like the OS limit is insurmountable.

Oh lord... I can see it now... Me + assembly code = yech.

dc_justin
August 17th, 2007, 02:46 AM
Damn....

So, you're saying if I double the size of my displacement in B0104, it won't change my AFR to run pig rich?

Yep, should run identically. Give it a try.

dc_justin
August 17th, 2007, 02:49 AM
Rats... This is pretty much what I thought but had hoped to avoid -- a complete retune. Or is it as simple as dropping my known VE table by 12%?


Anyone know why this artificial limit is imposed? PCM, OS limit, or software? From another issue, I know there are buffer imposed limits because of how GM put the OS together, but in this case, 100 and 112 fit in the same number of bits so it doesn't seem like the OS limit is insurmountable.

Oh lord... I can see it now... Me + assembly code = yech.

It looks to be an EFILive limit... Change your units to metric, and you'll see a limit of 511.922 g/sec. That's considerably more than 100#/hr. :)

turboberserker
August 17th, 2007, 04:25 AM
It looks to be an EFILive limit... Change your units to metric, and you'll see a limit of 511.922 g/sec. That's considerably more than 100#/hr. :)

3962 lb/hr more!

turboberserker
August 17th, 2007, 04:43 AM
So...


112 lb/hr * 0.126 = 14.112 g/s

That is sooooo strange that the limits are so far apart. PM'ing Paul :)

redhardsupra
August 17th, 2007, 05:40 AM
IF i was to hack up a tune, and i hate doing such things dearly, i'd cut the displacement exactly in half. it's the most universal, linear term in the whole airflow equation. all the other linear relationships will also be cut in half, so it's easy to make sense out of it: if you hit .5g/cyl, you know it really means 1.0g/cyl; if your airflow says 500g/sec you know it's 1000g/sec, etc... this way all your fuel needs are going to be halved too. this way you can exactly half your IFR too, and it will produce the correct final IPW:

.39g/cyl of air at 13.0AFR needs 0.03g/cyl of fuel which at 6.11g/sec yields 4.9ms IPW
but double airmass and double IFR would yield:
.78g/cyl of air at 13.0AFR needs 0.06g/cyl of fuel which at 12.22/sec would yield the same 4.9ms IPW!

so knowing you're exactly at double the airmass your scanner shows would be a good thing also for all the other airmass/airflow based tables, like spark: if you really need 19* spark at 1.0g/cyl, now it's gonna be 19* at 0.5g/cyl.

so basically all your airmass based table are going to lose half of resolution for the sake of double the range, as you suddenly can really dictate parameters for 2.0g/cyl that you couldnt do before because you 'ran out' of tables. just remember to 'move' your spark before you start tuning, or you're might have a nasty experience if you're really flowing 1.0g/cyl but commanding stock 0.5g/cyl spark (usually around 30*)

the problems will show up in all the nonlinear relationships, like short pulse adders, as you will be dumping an unknown amount of fuel, and simply halving/doubling the value might put you in the ballpark, but it wont be anywhere near the real values. so watch out, think twice, and quadruple check everything. go through every table you can find, and if it's airflow or airmass dependent (actually fuel flow dependent too since you're 'lying' about it as well) make sure it makes sense.

good luck, this is not the easiest task, but with some planning and common sense you should be able to get around the limits. hack the planet! :)

turboberserker
August 17th, 2007, 03:04 PM
Paul just confirmed in a PM that everything is converted to metric in the PCM anyway, so the 100 limit in the imperial side is indeed a bug. For now, the work around is what Justin found -- USE METRIC :)

Thanks all.

Chuck L.
August 19th, 2007, 12:43 AM
A dumb ??
Is the added volume gained by running the injs at 58PSI, something you have to do to get the amt of fuel required?
Is this a FI application?

turboberserker
August 19th, 2007, 12:53 AM
A dumb ??
Is the added volume gained by running the injs at 58PSI, something you have to do to get the amt of fuel required?
Is this a FI application?

I forgot I took all the mods out of my sig hehe

This is a twin turbo 408 aiming at the 1000 rwhp mark. According to my calculations, I'll need 106 lb/hr injectors to support that hp at 80% duty cycle. Running the these injectors gives me a little safety net and a little bit of fudge factor.

58psi is the stock fuel pressure on these gen III trucks. I'm not sure at this point where I will end up with the fuel pressure setting -- I need to play around with the aeromotive fpr to see what's what on the boost adaptation.

Paul's already got the bug fixed in the next version, so the metric work around will only be needed until the next version bounces.