We’ve had the opportunity recently to work on some very interesting engine setups on the Porsche 996 and 997s. As some were dedicated race cars, some fairly aggressive camshaft profiles were chosen.

The car made 70kPa of vacuum at idle. It was at 90kPa shortly after opening the throttle. In short, Speed Density did not work on this car for calculating engine load. In the internals, Engine Load is air charge per cylinder, so if we have other ways to come up with this, why not use it?

Up until very recently, the common OEM method of load calculation was via the use of a MAF (Mass Air Flow) sensor. This directly measured the amount of air that was actually making it into the engine. There is some lag, but as it turns out, the response times of the MAF is significantly faster than the pressure sensor. There is also the assumption that the air quantity in the engine is that which is in the intake tubing. This is fine for steady-state, but transient fueling is definitely different than under speed-density. Thankfully the fueling model should still work, if you change the axis from MAP (Manifold Absolute Pressure) to Engine Load, which can be derived from simple math.

The assumptions behind the design for GPR do not work for engines which have a very high specific output, or individual throttle bodies. These engines do not make enough vacuum, or do not have enough range, to make precise control of fueling possible. We can, however, do some math on the MAF value, and calculate the same Engine Load, and therefore use that instead.

The entire design of GPR assumes availability of a MAP signal, or a table with an estimated MAP value. Unfortunately it is not possible to completely remove it at this time, without some complex math to determine pressure based on the airflow. So if you choose “Mass Air Flow” as the Engine Load Normalized value in any of the Drobnak Software packages, you only need a MAP sensor, or a MAP Estimate table, for fuel pressure calculation purposes. Load is not derived from it at all.

The problem with the MAP estimate table, is that it can make your efficiency map look crazy, with values well over 150% when they should not be. It occurred to me that it made much more sense to provide a table that is a fallback for if the MAF sensor fails, but does not rely upon the crazy values that playing with the MAP estimate table does. So we’ve added in an “Engine Load Estimate Main” table.

This is basically an ambient pressure and temperature compensated table with expected air mass values at a given Throttle and RPM point. It is similar to the Engine Efficiency map, but it is a direct value. If you have the correct injector calibration, and good ambient pressure sensors and temperature sensors, you could run the car off this with no other sensor, just putting in the correct load value at each point. This assumes a correctly filled out MAP Estimate table, again due to the fuel pressure subsystem needing it. However, it also allows for a fallback should the MAF sensor fail. This allows the flexibility of near-direct inputting of injector timing values, but with all of the advantages of being able to swap out injectors and not have to re-tune, as the rest of the air and fueling model is intact.

The upside of this: run your crazy cammed cars. Run your individual throttle body cars…with excellent results. The initial fluctuations are due to fuel film not being quite right, but as you can see, they are still well within tolerances.

Also, do note the negative values in the Airbox Mass Flow Sensor Translation table - modern sensors can detect reversion - when air flows back over the sensor in the opposite direction. The code we use takes a sum of multiple samples, so we can account for this effect.

In the past we’ve tried to keep as close to GPR as possible, but moving forward we will not hesitate to deviate from it where it provides advantages to our customers.