Using OBD-II LOAD to derive MAF
There seems to be at least two different interpretations of the OBD-II parameter called "engine load" (i.e., LOAD, in the range of 0-100%), as reported over the OBD-II bus by modern engine computers. One version gives a LOAD value with is directly proportional to MAF (i.e., mass air flow). The other version seems to show that MAF is proportional to (LOAD x RPM).
Originally Posted by tylercee
So, if you want to solve for MAF using LOAD, first you need to determine which LOAD algorithm is being used by the vehicle in question, then you need to determine the appropriate constant scaling factor to derive MAF. Of course in one case you need to read RPM along with LOAD.
Given a calculated MAF, plus a periodic VSS (i.e., vehicle speed) reading, integrating these gets you incremental fuel consumed and distance traveled. Divide one by the other and you get MPG.
As I have noted before, using MAF to derive a fuel flow measured in gallons assumes a constant air-fuel (A/F) ratio and a fixed, known fuel density. Given that modern fuel injected engines are designed to run with a fixed, "stoichiometrically ideal" air fuel ratio of 14.7:1 almost all the time, using a constant A/F ratio for the MPG calculation makes good sense.
Calculating MPG / Using a "Constant" A/F Ratio
You should be able to make this work---I know because I have. As I've told people that have contacted me via email, the "hard part" of implementing a real-time MPG meter with embedded firmware is doing what needs to be done within the constraints of fixed-point integer math---typically limited to 32-bit of precision.
Originally Posted by VegasGuy
The formulas that I have provided yield perfectly fine results---using floating-point math. (You also have to make sure that you use the correct "units" for each of the parameters in the calculation.) Converting these formulas to work on an 8-bit microcontroller requires careful attention to detail. Just one integer overflow somewhere in your calculation chain will destroy the intended result---which is likely what you are seeing.
One way to work this out is to collect a bunch of "raw" OBD-II data and put that into a MS Excel Spreadsheet (e.g., as a .CSV file). Then use Excel "formulas" to calculate MPG using the formulas that I have suggested. Once you have that working, convert the Excel formulas to use "integer math" in place of the floating point math that Excel uses by default. Keep working until you get it right. Trust me! Debugging something like this with a spreadsheet is a heck of a lot easier than doing it in an 8-bit microcontroller! :-)
A modern engine computer maintains a 14.7:1 A/F ratio most of the time. When calculating a real-time MPG value, given the precision of the measured OBD-II parameters, and the accuracy of "constants" such as fuel density, one can expect errors in the range of 5-10%. If anything, the assumed A/F ratio of 14.7:1 likely has the lowest error of all.
Originally Posted by VegasGuy
BTW: The only time the A/F ratio varies from the "ideal" is during "open loop" fuel control mode, which can be monitored with one of the OBD-II parameters (i.e., Mode 01 PID 03). For example, an engine will run "open loop" for a short period of time after it is started, or when you stomp on the accelerator to get full power---again for short periods of time.
The only time I've seen extended periods in "open loop" mode was whenever I put the engine in my 1999 Suburban under extreme heavy load, for example when towing a large trailer up a long, steep hill. It is my understanding that the engine computer was running the A/F ratio "rich" in order to cool the exhaust gases, in order to protect my truck's very expensive catalytic converter---which, by Federal law, must be warranted for close to 100K miles!