RomRaider

I ran across an interesting bit of code in my ROM (A2WC522S).

This routine takes the current Engine Load and multiplies it by the raw Injector Flow Scaling.
So if you have an Engine Load of 1.0 and your flow scaling is 5200, your injector base pulse width will be 5200 (assuming AFR is at stoichiometric).

I've done a few logs and the value of the raw Injector Flow Scaling matches up pretty close to my (E60) Fuel Injector #1 Pulse Width (4-byte)*. From this I'm assuming the Injector Flow Scaling is really the base injector pulse width in microseconds to obtain stoich.

Interestingly the result of this routine (which NSFW called NsfwEnrichmentComp1 in his rich dip thread) is used in a number of table lookups that would appear to be injector pulse width related. Such as this one:
It is also used in the routines that calculate FFB, AFR corrections and others..

You are quite correct.
Injector Flow Scaling is in microseconds PER 1g\rev LOAD to obtain stoich.

The table above looks like VE table but is probably real Torque Vs (IPW, RPM ) and is extremely useful for tip-in enrichment calculations.
Nevertheless I personnally have not analized it's usage in your ROM.

I've gone through the code a bit and at the moment I can't figure out where the results of these tables are finally used. It starts with the value I've called Injector Base Pulse Width (IBPW) which is calculated from the Engine Load reading * the raw Injector Scaling value demonstrated in the code in the first post.

The IBPW and Engine Speed are used to pull values from both Table 1 & 2.
These two tables are blended using the Extended parameter E42 Map Ratio. If Map Ratio is 1 (which it is in most cases) the result of the blending is really just the value from the larger Table 2.

The Table 2 result is then multiplied by a series of compensations based on Engine Coolant Temperature and Atmospheric Pressure (Tables 3 through 6).
Since the four compensation tables are all 0 or 1, the end result is once again the value pulled from the larger Table 2.

Since the large Table 2 is based on injector flow scaling, any change to injectors should be reflected onto the X-axis of the table. I had not changed this table when I move to DW740 injectors and I logged the results pulled from Table 2 and at WOT I saw no reading above 290. I then scaled the X-axis down using the ratio between my old and new injectors, flashed and I now I see the values being pulled from the extreme right side of the table.

I don't know what affect this should have on the cars operation, but so far it has not been negative.

Going through the code and not finding where the results are used, I started to wonder if this was meant for an automatic transmission car. I looked through the ROM of a 2005 Legacy GT AT and found the tables are all populated the same and the code is the same.

Could this be a base torque map for the automatic transmission, as I did see some references where I believe the Table 2 value is sent out on the CAN bus?

Does anyone have any other theories.

Table1 looks like "near idle torque" and Table2 looks like torque vs RPM\fuel injected.
Try to trace whether those values are placed onto CAN bus. They are very important for TCU to calculate line pressure and switch point RPMs.

I have never traced those values for Denso. CAN messages content is evident for Hitachi ecu's.
Check "subdiesel" project. Probably "torque calculated" is really placed onto CAN bus. Those data should definately be there.

Look for my "overall" vehicle system knowleght, all relevant torque is sended on CAN bus:

indicated troque, driver request torque, friction loos troque etc. are send via CAN to VDC or TCU.

all this torques are nessessary to calculate the astimated coefficient of friction, witch sets the maximum alloud torque in a VDC-action.

Same for TCU..

So it is quite importend not to bend the torque modell of mordern ECUs, because VDCs or TCU will not work proper, if torque on CAN is not equal engine torque.


In Diesel-ECU there is are maps for conversion IQ to indicated torque or visavers.
Because of not debugging myself the software, I don´t know any thermperatur or admosphaeric pressure corrections, but of cause they are here and needed

Jochen

There should be a table somewhere which sets start of IPW after TDC based on time etc. Could table 2 be the m/sec before '0' to fire?

Trying to tune big cams is a nightmare when you know they have more duration but want IPW to occur at peak vacuum etc

are you suggesting m/sec = metres/second ?


BTW: my car is manual so I can't check any TCU or VDC info as I don't have that stuff.

Oops, milliseconds, ie 0.32ms earlier inj firing compared to idle to account for piston speed in time it takes cylinder to activate etc. So the inlet valve is opening faster after the crank/cam signal so would need to advance inj fire to account for valve opening time etc

So your example value corresponds to the cell at intercept IBPW = 13000 (µsec) & RPM = 3200 (basically the middle right side of Table 2).

So that's a theory. We'll just need to figure out more of the code to verify one way or another.

The RR Editor Injector Flow scaling formula has always bothered me a bit. The formula attempts to convert the ROM's raw value into a flow rate. Now that I see the raw scaling value is really a value in micro-seconds I can't see how we can reliably convert that to flow. I think there's many variables that will through the formula off too. If you change intake and/or exhaust to make it breath easier, that's going to influence the required amount of fuel to reach stoichiometric AFR and therefore change the value we call Injector Flow even though you never changed the injectors themselves.

Anyway, in the past I changed my injectors from stock to DW740. I ended up with an Injector Flow setting of 760 and a bit more latency than stock. My AFR learned corrections were always with +/- 5%. Just recently I sent my old stock injectors out for cleaning and testing. I thought this would be a great way to see the "real" difference between the old and new injectors.

Here's the results.
First the stock "550cc".

Now the "DW740".

I then used the 100% DC Mean Flow rates to calculate the ratio for table adjustments.
551/741 = 0.743589
I wonder if it would be better to use the 75-80% rates as the Injectors are rarely open fully.
428/535 = 0.8

For my first attempt I used the 100% ratio. I applied it to the Injector Flow Scaling value rather than entering in the Flow Rate. So stock is 520 according to the Editor and with the ratio I get 700 (not 740). I adjusted all the injector pulse width related tables, set latency to stock and went and flashed the ROM.

On cold start (4 °C) my WBO2 read ~13.5AFR. When closed loop activated I saw the corrections run up to about +8% at idle. Not bad! I went for a drive and didn't see any really bad corrections occur.


Here's a 3rd gear pull.


So, what I'm wondering is, should we change the formula in the Editor defs to give the raw Injector Flow scaling value in milli-seconds rather than a fictitious cc/min value? If we did I think people would have a better change at getting the flow scaling close to correct on the first attempt.

There should be no difference what is used for calibrations - cc/min or us/(g/rev) PROVIDED latency values are correct.

Unfortunately latencies are ecu schematic dependant and may not directly corresponds to values calculated form flow bench results.

cc/min is a perfectly legitimate unit here.

Engine load ( grams[air] / stoich-rev ) * Injector Scalar raw ( unknown unit ) = (microseconds / stoich-rev)

Therefore, Injector Scalar raw units = microseconds / grams[air]

It is perfectly acceptable to extrapolate a static flow rate based on this data.

Using stoich ratio (multiply by grams[air]/grams[fuel]) you can easily convert to units = microseconds / grams[fuel]

To find the (cc/min) of the injector, simply invert the value (and thus units) and multiply by (cc/gram)*(microseconds/minute)

I don't doubt the math and we are not talking about latency as that is dealt with elsewhere.

What I'm saying is the current definitions formula is not an accurate means to convert a data sheet flow value to a time in usec, excluding latency to obtain stoich@1g/rev if you just plug in that flow value.

I'd prefer to use the Cobb documented way and reveal the raw value and then allow the user to enter a new value after it is calculated with the ratio multiplier to set it for different injectors.

Explain why it isn't an accurate conversion if you don't doubt the unit analysis math.

Perhaps it is the published flow rate that is inaccurate. Variances in the test fluid (many use n-heptane) and machinery can produce numbers that are simply inaccurate for real-world gasoline use. Or perhaps the math in the definition wasn't done properly? I haven't run the numbers on it.

I would much rather have a ballpark flow number than the comparatively useless usec/g-air/stoich-rev number.

Have a look at the conversion formula. Can you explain how it is suppose to work, because it doesn't.

I used two sets of injectors, one set being stock and the other higher flow than stock and had the tests perform by the same company using the same test process. This removes all the ambiguity you just described and we end up with two known flow rates and an easy way to arrive at the ratio to make table adjustments with.

I guess I forgot to mention the fact the tests were perform by the same company.

It becomes irrelevant when you know what you have and know what you are installing. Just use the ratio and make the change just like any other table.
An inaccurate conversion for the sake of a convenient estimation of the flow rate is less than helpful when tuning. You wouldn't like it if that was the case with the timing table would you?