RomRaider: Running super rich at high load/low RPM

[PantsDants]

Hey guys, I was reading through some of the older threads about adjusting GDI fueling, and rather than resurrect one of those I figured I'd make a new one.

Was there ever a consensus as to what the Y axes on the GDI Pressure Multiplier tables actually represent? In the OFT definitions, they list engine load on one and MAF g/sec on the other, yet the values are exactly the same and certainly look like they're scaled to be MAF values rather than load.

Additionally, what does the X axis for GDI Pressure Target B point to? From what I've observed, it seems to correlate with "Fuel Pump DC" on the OFT, which I'm assuming is the high pressure fuel pump's duty cycle.

Any pointers (heh) would be greatly appreciated!

[steve99]

Originally Posted by PantsDants

Hey guys, I was reading through some of the older threads about adjusting GDI fueling, and rather than resurrect one of those I figured I'd make a new one.

Was there ever a consensus as to what the Y axes on the GDI Pressure Multiplier tables actually represent? In the OFT definitions, they list engine load on one and MAF g/sec on the other, yet the values are exactly the same and certainly look like they're scaled to be MAF values rather than load.

Additionally, what does the X axis for GDI Pressure Target B point to? From what I've observed, it seems to correlate with "Fuel Pump DC" on the OFT, which I'm assuming is the high pressure fuel pump's duty cycle.

Any pointers (heh) would be greatly appreciated!

Maybe check out the romraider defs they are newer than oft defs might give you some clues otherwise maybe try looking at some table in ecutek @Kodename47 may be able to help their, or your going to have to ask the romraider guys

[ztan]

Was just looking at the disassembly for this last night in A01G:

The value defined as Base Pulse Width (FFF89738) logs very closely to Engine load in g/rev. The Base PW value gets passed to a subroutine (at 51518) where it gets multiplied by 0.84460002 then by 100. The new value (Base PW x 85) is passed to the GDI pressure multiplier as the y-axis value.

To simplify the Y-axis descriptor:

      <table type="Y Axis" name="Load" storagetype="float" endian="big">
        <scaling units="g/rev" expression="x/84.460002" to_byte="x*84.460002" format="0.0" fineincrement=".05" coarseincrement=".1" />
      </table>

There is also another single value scalar GDI pressure multiplier in the next subroutine (at 574A2) used that is applied to results from both GDI multipliers: I think that would be the easy one to use to scale the whole GDI system in one hit.

I understand the result from the GDI pressure target table to be a value sent to the GDI driver as a target for the high pressure pump to hit.

[PantsDants]

Originally Posted by ztan

Was just looking at the disassembly for this last night in A01G:

The value defined as Base Pulse Width (FFF89738) logs very closely to Engine load in g/rev. The Base PW value gets passed to a subroutine (at 51518) where it gets multiplied by 0.84460002 then by 100. The new value (Base PW x 85) is passed to the GDI pressure multiplier as the y-axis value.

To simplify the Y-axis descriptor:

      <table type="Y Axis" name="Load" storagetype="float" endian="big">
        <scaling units="g/rev" expression="x/84.460002" to_byte="x*84.460002" format="0.0" fineincrement=".05" coarseincrement=".1" />
      </table>

There is also another single value scalar GDI pressure multiplier in the next subroutine (at 574A2) used that is applied to results from both GDI multipliers: I think that would be the easy one to use to scale the whole GDI system in one hit.

I understand the result from the GDI pressure target table to be a value sent to the GDI driver as a target for the high pressure pump to hit.

Thanks! I'll try dropping that into my definition and see what it looks like.

Full disclosure: I'm trying to reduce some really bad over-fueling I'm getting at positive manifold pressure and low-ish RPMs (<3200), which ends up translating to engine loads of >1.7 g/rev. I was hoping to get a better understanding of what the X axis is on the pressure target table so that I can more selectively adjust the pressure multiplier for these conditions, since those tables are rail pressure vs. engine load.

[steve99]

Originally Posted by PantsDants

Thanks! I'll try dropping that into my definition and see what it looks like.

Full disclosure: I'm trying to reduce some really bad over-fueling I'm getting at positive manifold pressure and low-ish RPMs (<3200), which ends up translating to engine loads of >1.7 g/rev. I was hoping to get a better understanding of what the X axis is on the pressure target table so that I can more selectively adjust the pressure multiplier for these conditions, since those tables are rail pressure vs. engine load.

you might want to have a look at load limits, not sure if your on oft tune but soime had load limits set to 1.6 for entire rpm\load range which can cause rich fueling at low rpm high load

assume you have done maf scaling as well ?

im no expert but by changing those gdi tables you may upset the balance between the pi and di injection systems

you might want to have a look at the tune tweaks link below, shivalso suggested leaning out the ol fuel table in low rpm high load area , but its better to scale maf and correct load limits. see also @Wayno s tune thread for example load limit tables and maf scaling

[PantsDants]

Originally Posted by steve99

you might want to have a look at load limits, not sure if your on oft tune but soime had load limits set to 1.6 for entire rpm\load range which can cause rich fueling at low rpm high load

Fuller disclosure: I'm running the Phantom supercharger, so I actually need higher load limits throughout. The issue doesn't seem to be that the engine load is being miscalculated, it's that for loads higher than a certain amount, I'm getting waaay too much fuel.

So instead of trying to clamp the calculated load via the load limit table, which effectively stops increasing fuel delivery above a certain point, I want to scale back the fueling for those higher load numbers.

[steve99]

Originally Posted by PantsDants

Fuller disclosure: I'm running the Phantom supercharger, so I actually need higher load limits throughout. The issue doesn't seem to be that the engine load is being miscalculated, it's that for loads higher than a certain amount, I'm getting waaay too much fuel.

So instead of trying to clamp the calculated load via the load limit table, which effectively stops increasing fuel delivery above a certain point, I want to scale back the fueling for those higher load numbers.

you should be able to do that with the ol fuel table, thats the fueling the ecu is targeting when your in open loop. their is also the closed loop fueling as well.

does the rich running occurr in open or closed loop mode ?
is the problem happening with esc active ?

if you mess with the gdi tables i think it going to cause more issues

[PantsDants]

Originally Posted by steve99

assume you have done maf scaling as well ?

im no expert but by changing those gdi tables you may upset the balance between the pi and di injection systems

you might want to have a look at the tune tweaks link below, shivalso suggested leaning out the ol fuel table in low rpm high load area , but its better to scale maf and correct load limits. see also @Wayno s tune thread for example load limit tables and maf scaling

I have scaled my MAF, and that's the strange part: For a given MAF voltage, if I'm below 1.7 g/rev calculated load, I'll hit my AFR target every time. However, at that same MAF voltage with a calculated load above 1.7, my AFR pegs rich.

The Phantom can only flow a set amount of air, and it's independent of engine RPM. From my understanding, with a constant MAF voltage, as engine RPM increases, the calculated load will decrease. So what I'm seeing is basically there's a tipping point where my engine load dips down below this bizarre "threshold" as a result of increasing RPM, and then fueling starts hitting targets again.

[ztan]

Originally Posted by PantsDants

I have scaled my MAF, and that's the strange part: For a given MAF voltage, if I'm below 1.7 g/rev calculated load, I'll hit my AFR target every time. However, at that same MAF voltage with a calculated load above 1.7, my AFR pegs rich.

The Phantom can only flow a set amount of air, and it's independent of engine RPM. From my understanding, with a constant MAF voltage, as engine RPM increases, the calculated load will decrease. So what I'm seeing is basically there's a tipping point where my engine load dips down below this bizarre "threshold" as a result of increasing RPM, and then fueling starts hitting targets again.

What MAF Voltages are you running rich at when load >1.7?

What are you using for an AFR source?

Have you checked trims against MAP? There are some MAP based compensation tables for AFR sensor 1 and MAF flow (EL Comp) that might be applicable.

[PantsDants]

Originally Posted by ztan

What MAF Voltages are you running rich at when load >1.7?

What are you using for an AFR source?

Have you checked trims against MAP? There are some MAP based compensation tables for AFR sensor 1 and MAF flow (EL Comp) that might be applicable.

Seems like anything greater than 3.5V MAF causes this condition when load is >1.7. Again, when load is less than that, AFR is totally on target.

Using the factory AFR sensor.

When you say trims do you mean AFR error? This is occurring solely in open loop. While I can't rule out sensor error or compensations due to positive pressure, I can feel the car bog and struggle when these rich events are occurring; it is immediately obvious when it happens. I don't believe it's only the AFR sensor reading being thrown off and not actual fueling error.

Which tables specifically do you think would be worth looking at? By the way, thanks for that new scaling on the GDI Pressure Multiplier table, it's far more usable knowing what the heck the Y axis actually is!

I feel like I should rename this thread at this point as we've definitely gone far beyond the original topic! Thanks for all your help and insight.

[ztan]

Originally Posted by PantsDants

Seems like anything greater than 3.5V MAF causes this condition when load is >1.7. Again, when load is less than that, AFR is totally on target.

Using the factory AFR sensor.

When you say trims do you mean AFR error? This is occurring solely in open loop. While I can't rule out sensor error or compensations due to positive pressure, I can feel the car bog and struggle when these rich events are occurring; it is immediately obvious when it happens. I don't believe it's only the AFR sensor reading being thrown off and not actual fueling error.

Which tables specifically do you think would be worth looking at? By the way, thanks for that new scaling on the GDI Pressure Multiplier table, it's far more usable knowing what the heck the Y axis actually is!

I feel like I should rename this thread at this point as we've definitely gone far beyond the original topic! Thanks for all your help and insight.

More questions:
Are you using a stock AFR scaling or a modified one? If your sensor scaling is off at the low end, it may read wrong. I made a thread on sensor scaling and the first one I had read a bit rich low down. Updated scaling works quite well.

Are you going rich just after transtioning to open loop? If so, do a search for rich dip on the NASIOC forums. I go rich just after transistion to OL and have tried all sorts of things to eliminate it - have not found a solution.

Have you had a good look at the engine load limiter tables? My understanding was that with an A/T, the torque converter can make load spike quite high transiently leading to a whole bunch of fuel being tipped in when it is not needed. Take care with these - if you go too low, you'll lean out.

[PantsDants]

Originally Posted by ztan

More questions:
Are you using a stock AFR scaling or a modified one? If your sensor scaling is off at the low end, it may read wrong. I made a thread on sensor scaling and the first one I had read a bit rich low down. Updated scaling works quite well.

Are you going rich just after transtioning to open loop? If so, do a search for rich dip on the NASIOC forums. I go rich just after transistion to OL and have tried all sorts of things to eliminate it - have not found a solution.

Have you had a good look at the engine load limiter tables? My understanding was that with an A/T, the torque converter can make load spike quite high transiently leading to a whole bunch of fuel being tipped in when it is not needed. Take care with these - if you go too low, you'll lean out.

Just double checked; I am using your latest scaling.

It's definitely not just a spike on tip-in or transition to open loop. It'll stay pegged for as long as I dare to keep my foot in it. Admittedly, I've not held it like that for more than a few seconds at a time, but with how fast the ECU responds, I wouldn't think it would take longer than that to pull out of it if it were going to.

I have played with the load limiter tables a bit, but like you already mentioned, I ran into issues with going lean. It's difficult to know exactly where to clamp the values without knowing the underlying equation for how the load is calculated. I found the equation for 16-bit ECUs on the RomRaider forums after the fact, but I don't know that it directly translates: MAF*60/RPM

If you think adjusting the load limiter is better than going after the fueling directly, I'll give it another shot. Would it make sense to calculate the max load for each cell using that equation above, then reduce it by the percent AFR error I see as a starting point?

I'd really like to understand why this condition is occurring though; clamping the load feels like a dirty hack to me.

[ztan]

Originally Posted by PantsDants

I'd really like to understand why this condition is occurring though; clamping the load feels like a dirty hack to me.

I've partially helped my rich dip with another dirty hack: I've scaled my MAF to hit target AFR under OL conditions - I've dealt with the lean area at the end of CL conditions (consistently seen when looking at trims v MAP) by adding to the higher pressure EL comp table. I'll use this until I find a more elegant way to deal with it.

[PantsDants]

Originally Posted by ztan

I've partially helped my rich dip with another dirty hack: I've scaled my MAF to hit target AFR under OL conditions - I've dealt with the lean area at the end of CL conditions (consistently seen when looking at trims v MAP) by adding to the higher pressure EL comp table. I'll use this until I find a more elegant way to deal with it.

Heh, well, whatever works I guess. I'm sure there are plenty of undefined compensation tables that have yet to be uncovered in the rom that are throwing things off in transitions like that. Have you tried playing with the CL to OL delay tables at all? I'd also speculate there's enough latency in the system as a whole that it might just be impossible to control things as tightly as we'd like.

Stepping back to the GDI tables, I actually have made significant progress on my problem by scaling back GDI Pressure Multiplier A and B. It still needs to be scaled back a bit more, but I've got my AFR off the peg at least, around 10.5 now, without leaning out the upper rev range / lower loads. The key I've found is to extend and rescale the Y axis so that anything just below 1.7 g/rev isn't affected by my changes. It's bizarre how it's such an abrupt shift in fueling around that magic number, but this strategy works for me.

Once I get this better dialed in I'll post up what I've done. With the typical disclaimer of this could very well break your car and I'm not responsible if it does, but it works on my machine.