So the question is
How is this usually parameterized? squirt amount (grams) to squirt duration (ms) curve? Theoretical squirt (ms) to correction (ms)?
I would say first we should start to consider the tuning tables differently. The load VS RPM table is a kind of catch all, and should be tuned last. There are several lower level compensation tables that need to be tuned before the load table is tuned.
The short version is to implement the tables shown here
http://injectordynamics.com/chrysler_injector_characterization/ where you have look up tables that allow for more accurate conversions between PWM to mG. However I don't fully agree with this, as it assumes consistent combustion energy from the fuel variations caused by additive like E85, MTBE, etc. As well it assumes consistent pulses with different viscosity's caused by differences in temperature, fuel type, etc. However it's certainly a step in the correct direction, and will allow better chances of obtaining a smooth idle with a larger injector. Also when implemented, plan for doing this kind of compensation on a per injector basis. AKA staged injectors on a V8 is 16 injectors. Also keep in mind that this entire load table thing is a hack, where you smash unknown tolerances into one ball park variable. See below table from injectordynamics that shows how injectors typical vary at low pulse widths.
- Fuel_Mass_Conversion_Chart_3.png (34.28 KiB) Viewed 28783 times
Longer version below.
This question perhaps goes down the rabbit hole further than you may want to go. The generic load vs RPM table was largely done to allow kind of good-ish compensation under a variety of conditions. It was intended to allow the small processors of the 80's and 90's to kind of squish a bunch of compensation data into one calibration table. You didn't really care that you had 10 sources of error where some errors in the + direction, others in the - direction, that caused the final variation(s) of fuel PWM, you could make it "work" with this one table. You often had to dump some extra fuel to stay running, but it worked either way. However modern micro's have much more capabilities these days, so more complicated algorithms exist, and people are starting to look for them. The good news is that rusEFI has the physical capabilities to do this.
At it's core, the load table is really tuning for one of two things. Either people are tuning for peak power, or peak efficiency. For simplicity sake, we'll assume everyone here wants peak power. However don't forget if you are real competitive, at times, you'll want peak efficiency as it provides a fuel weight advantage. AKA know your fuel weight, predict how much you need and run dry as you come across the line. This means lighter vehicle while racing, resulting in faster turns, etc. I guess a very large group of people would also tune for things like minimal carbon footprint, minimal NOx emissions, etc. Point being you typically want multiple load tables. So even this one catch all table, has variations. Lets not forget that below it, you often have these sub level compensation tables. Then occasionally those sub level compensation tables have compensation tables.
At some time you start to wonder, when should you jump from a table driven approach to a different approach.
Peak power is largely a balancing act between spark timing and AFR/charge. AFR/charge is largely determined by PV=nRT. Your valve over lap, intake and exhaust restrictions, etc are going to change your VE which changes your predicted amount of air charge to be used during the combustion. Also keep in mind that your VE will even change based on power vs efficiency tunes. AKA the burning fuel left in your cyl will create different pressure levels in your intake and different levels of cross contamination as some of your overlap will cause some exhaust gasses to back feed into the intake. Efficiency burn will typically have less, or more of this kind of overlap. So your VE will change just by changing your fuel and spark advance. AKA compensation tables on top of compensation tables, on top of compensation tables. It all depends on what kind of tolerances you are willing to tolerate.
Keep in mind that injectordynamics also suggests getting a batch of injectors and balancing them, such that the properties from one injector to the next are the same, as most after market tuning software will only have one table, so you have to compensate for the injector variations via physical means. To get accurate injections, you either need exact injectors, or you need compensation data on a per cyl basis.
The issue you have with trying to tighten the fuel injector pulse down to smaller 0.XXXmS ranges is that you also need to decrease the sources of error from other things in your tuning table. I would say we should start to think of the RPM vs Load table as RPM vs Combustion energy table. Keep in mind that if you fill up on 87 octane, in the states you'll often have a blend of up to 95 octane. If you have less 97 octane being consumed at the fuel stations, the refinery's simply tap off more of the 85 which causes it to grab a bit of the other octanes. However in the EU they have much tighter tolerances on the range of octane you'll actually get in the fuel. This variation in fuel alone will change your tuning table. Also don't forget that E85 with it's sensors, or MTBE additive, or ethanol blends will all have different tuning tables. Then if you use race fuel.....
Any how, you can keep doing table mods on table mods, and consuming RAM and ROM space, or at some point you can make the jump and change from memory space to CPU cycles. I suspect that before long, we'll want to start considering the equation based approach, such that instead of entering tables, you enter cycle size, intake restrictions, exhaust restrictions, etc.