I mean as a different way of analyzing or bringing information to the user in simple form. MPG has been the industry standard to sell cars for a long time, but how useful is it when it changes drastically each millisecond or even second? But let's say we could see short term costs plus real time counting total costs from home, work, home, store, home, McDonald's, gas station, home, work, restaurant, work, home, bar, Walgreen's, cheap motel, home... then we would get a feel for what we're spending our gas money on. So the question is what's more practical or useful information?
FWIW, I ended up doing my fillup log and summary so that it uses GPM, CPM, and CPG. Then you have last, high, low, and average. I also gave a mileage x 100 switch, because I think it is useful when you can look and say 'oh, I need x gallons to go 100 miles' or 'oh I spend x going 100 miles'.
Originally, I wanted to link live economy with fillup history, basically showing you a counting meter in pollution and cash, like a cab meter. But that got vetoed. It was just a bit much for a motorsports company...
do you know if any of the manufacturers provide injector pulse width through the ecu? that'd be my preferred way of computing mpg. injector size, number of cylinders, rpm & speed ought to get you a pretty good value (assuming fuel pressure is pretty constant, which it should be).
Sorry if it was bad form to do back to back replies, but your question is a lot more technical. Yes, a number of ECU's offer IPW, typically in a vendor specific PID or custom factory tool message.
I actually played with this for fun. Instead of specifying injector flow related values, I just monitored MAF, IPW, and my wideband for a bit. You could probably do the same thing with some indirect analysis of a narrow band sensor, but the wideband made it easy. If I know the mass air flow and the lamdba value, I know what the injector flow rate is for the given IPW.
Using my measured injector flow rate, I then monitored *just* IPW and VSS and made MPG calculations. On my '01 Chevy, very close. There is still the gotcha of sample rate, though it was pretty high in this case (J1850). Not generically useful, but interesting for me.
It actually got me to understand why a fair number of vehicles have both MAF and MAP. MAF is a more direct way to control fuel, but MAP is useful for ignition. Either read the sensor once just before start for atmospheric or (more common now), have a second MAP sensor for barometric pressure. Very helpful in knowing the exhaust composition and pressures.
Originally Posted by jiggersplat
also, if you really want to change people's driving behavior, you need to show how fast dollars are being burned, not gas. people understand and are motivated by dollars. and be annoying about it. play a cash register noise for ever 10c you burn.
See my note above - I was thinking along the same lines, but got vetoed even without the 'ching'...
In my app I used the o2 voltage to determine the actual AFR and then I use the AFR to calculate the mpg.. Actually this is the most accurate calculation. However, the thing is that the AFR of a narrowband sensor always is going up and down, from 11-16 and so on.. I still haven't tested my formula but what I'm planning to do is use the formula from here, use mine and compare..
The LTFT used in this formula can provide an average value of mpg.. But if STFT is the current correction, why not use this in this formula?
...use the AFR to calculate the mpg.. Actually this is the most accurate calculation..
I disagree - isn't the liquid volume of fuel delivered a more accurate measure than the chemical mix? (The liquid volume is unaffected by pressure and is less effected and prone top temperature variations.)
As to using wideband, it may not make much difference. Keep in mind that a wideband is a narrowband sensor but with a "chemical balancing" chamber. That adds significant delay. And much depends on driving profile (steady or fast changing accelerator/loads) and sample rate.
Flow sensors are getting fairly cheap....
Otherwise injector sensing - especially if low impedance types... (unless you can interrogate your EMS?)
I've also incorporated the AF sensor value into my app (ECUTracker). Lucky for me, my car provides a Wideband Lambda value over the SSM protocol. I expect it increases the accuracy quite a bit.
As for the LTFT and STFT, you can't use those to help out with the mileage calculation. They don't show you any form of swing from Stoich. It's only a value of fuel added our subtracted from the calculated value to achieve Stoich.
Flow sensors yeah are the most reliable, maybe the injectors better but when using flow sensors you have to take into account the fuel going back to the tank as well.. Regarding the widebands, they are very accurate and fast - think that they tune cars with that, if they had significant delay then the car would have been tuned wrong resulting to a blown engine.
And yes I spent the night reading about LTFT and STFT, they can't help. So what I will do is use 3 possibilities, one is closed loop, one cruising and one open loop. For each of them I know the target AFR my car has, so I'll use that in the equation. At least to estimate it as best as possible..
Skidd how did you use the AF sensor? The problem with the O2 sensor, even if it is a wideband, when it is OEM the voltage is fluctuating all the time so you can't get reliable numbers for the formula. Can you please give some more details?
Just to clarify - whilst widebands are narrows with the equalisation chamber, they will always be slower than narrowbands.
I dealt with that issue wrt real time tuning. At the time it was better using appropriate knee figures. Sometime curve integration was used.
But injectors or flow sensors (even if two are required) should be way more accurate. Certainly easier.