Yeah, you must be doing some kind of decimal to floating point conversion before that. Feeding it my ODB2 logs shows around 200 MPG. :)
Edit: Ok, got it. Just signed decimal of LTFT looks better.
Printable View
Yeah, you must be doing some kind of decimal to floating point conversion before that. Feeding it my ODB2 logs shows around 200 MPG. :)
Edit: Ok, got it. Just signed decimal of LTFT looks better.
Curiosity, I had to do this:
MPG = 710.7 * VSS / (MAF / 100) * (1 + LTFT/100)
I THINK that simplifies to this, double check my math.
MPG = 71.07 * VSS / (MAF) * (1 + LTFT/100)
If you read up, there is a mistake in an earlier post which lightner points out, but he forgets to fix the simplified function. The first function I just posted seems to work for me, and returns an average about equal to what I figure when doing the old miles per tank fillup method.
Ah, maybe that's it. Thanks. It's a little goofy :)
710.7 * 76 / 5 * (1 + 11 / 100) = 10802 MPG
I'm gonna have to say that's not correct. The way I wrote it may be confusing, but if you follow the order of operations, it works out. Making the order of operations explicit, it would be:
MPG = (710.7*VSS/MAF)(1 + LTFT/100)
If you wanted to distribute that out, it would become:
MPG = 710.7*VSS/MAF + (710.7*VSS*LTFT)/100*MAF
MPG = 710.7*VSS/MAF + (7.107*VSS*LTFT)/MAF
or writing it without explicit order of operations (a computer should calculate this correctly)
MPG = 710.7*VSS/MAF + 7.107*VSS*LTFT/MAF
Personally, I think the original formula is easier, because it doesn't have VSS and MAF in it twice; each variable only appears once in the formula, but it's your cat, you skin it how you like :)
Oh, I think I might know why. I'm using grams/s in my calulations (my obdlibrary automatically converts), and the origional function assumed it was 100g/s. Sorry ignore my previous post, mine is a special case.
varies the pulse width to enrichen or lean the mixture. If fuel rail pressure variable the ECU would get conflicting readings from the O2 sensor as the amount of fuel assumed to be injected based on fuel pressure would be different.
Any 'suction' of the fuel from the injector would be compensated for by the ECU as this would work to change the mixture but the effect (if even present) would be constant enough (though perhaps variable over the engine's RPM operating range) to be dealt with by the ECU.
As for long term fuel trims they reflect the ECU's efforts to maintain that 14.7:1 air/fuel ratio.
I think in taking into account the long term fuel trims you are taking into account a factor that has already been taken into account.
Thus the air flow rate at least under closed loop conditions reflects the amount of fuel used. The trouble is back then to what number to use for the weight of the gasoline and this is temperature dependent as well as dependent upon fuel blend.
Sincerely,
MarcW.
Maybe you should have added "estimated" in there. :) It's also instantaneous squirts per feet which is useless to me, so that's why I have to remove the real time errors before they throw off the averaging code. But bottom line is it's better than good enough to figure out where your $$ are going.
Marc is right. A modern vehicle's engine computer (ECU) constantly works to maintain a "stochimetric ideal" air-fuel ratio of about 14.7:1. The reason for this is emissions regulations, and not power, although the ECU can go "open-loop" for short periods to get bursts of power. But, in the long run, stochimetric "rules", and that's why MPG calculations can be done using this kind of data in the first place.
It's my understanding that the OBD-II "fuel trim" numbers are really just a measure of how well the fuel system is doing when using its stored predictions of which set of fuel system parameters (e.g., fuel injection duration, ignition timing, etc.) gives an "ideal" air-fuel ratio. The feedback from the O2 sensors (the ones before the catalytic converter(s)) is what tells the ECU how well it is doing. And, the "fuel trim" number show how well it did with what it had to work with, including perturbations like dirty injectors, uneven fuel-rail pressure, low-grade gasoline, etc.
As for Marc's comment: "The trouble is back then to what number to use for the weight of the gasoline and this is temperature dependent as well as dependent upon fuel blend", it has been my experience that at least when it comes to "plain old" gasoline, what you choose for these "constants" is not critical, given the inaccuracy and variation in the diameter of your tires, the OBD-II sensor readings, etc.
But, if you start mixing in a whole bunch of "corn squeezin's" with your gasoline, then that's a different thang'! :-)
Best regards,
Bruce D. Lightner
lightner@lightner.net
I used this method for my software : http://www.winobd.com
I compared the result with the onboard computer of my Car (Seat Leon 2LTFSI) : the result calculated with winobd is very closed. Try it and give me feedback !
What is the calculation for diesel engine? When using this calculations the readings is 60-70% higher thAn actual mpg. I have a Peugeot Expert Tepee 2008 and also a Citroen Jumpy 2006, both diesel and no mpg software that i have tried with the scantool.net elmscan is doing any correct calculations of mpg. Is it impossible to use MAF in calculation on a diesel engine since it dont regulate the air in same way as a "gasoline" engine?
/pwb