From long time I am trying to find an easy way to retrofit real time fuel consumption estimation for old cars, which are not OBDII and which don't have electronic injection signals. This is the case of many of them.
MPGuino needs two signals only:
VSS = km/h or miles/h
Fuel = km/l or miles/gallon
Many cars have the first but not the second, which is my case, by the way.
To obtain an estimation of the fuel consumed / injected at any time, without the use of two flow sensors which are complicated to handle, or last short or are too expensive, I am trying another method which is to estimate real time fuel consumption, regardless if it is gasoline or diesel as follows:
Fuel used per unit time = f( rpm, tps)
Where rpm is well known and always available or easy to make available.
Tps which is throttle position, preferable close to injection pump or carburator, not at the pedal (for precision).
Tps is a signal sometimes available, sometimes not. But you can instal a linear sensor position to almost any car.
The problem was to have a math model to make the relation between the independent variables rpm and tps and the dependent variable Fuel with precission. Not easy.
But some fellows from Korea did it, (Science and Technology Vol. 4 Nr 4, December, 2011).
The model developed took measurements of fuel used from onboard computer. They were rigorous in using stats to measure the accuracy of the model.
I am attaching a spreadsheet with the model and a surface graph of it. Want to open discussion on it, but more than that, I will implement in my car, using MPGuino as final onboard computer, using the model output as the second signal.
The model requires to be calibrated to one's particular car, for what I added one zero constant that can shift the complete model up and down, and a scale contante which can change the "slope" of the model in a simplified manner.
One should produce some points (fuel, rpm, tps) with the car using a small fuel tank or a complete tank and calibrate the model.
I know it will be not a precise model, but at least will serve as a relative model, to measure mods made to the car or engine, driving strategies and more. The more one calibrate it, the more it will work close to reality.
Anyhow, all onboard computers need callibration.
Any thoughts?
What I need now is a small IC processor to evaluate the polynomial expression in real time, before sending the result to MPguino together with VSS.
Any contributions? I am not electronic, so please easy, practical solutions.
Hope this will be of use to many.
Oldbeaver
__________________
Mercedes 300 D turbo 1993
Last edited by oldbeaver; 05-16-2014 at 03:04 PM..
Reason: spell
Well, well, the meters look nice. I entered the site and couldn't find information about mechanic method of the flow meters.
Good of using this meters (I have to use two for my diesel) is you measure real fuel flow, instead of estimating it.
I already used a couple of meters once, but they dind't last enough as to calibrate my Arduino board: before I ended both stuck with debris of oil, despite each one has a special filter, in addition to the car fuel filters.
Short afterwards, both flow meters begun to leak and I had to remove them and replace the fuel hoses I cut before.
In my experience, the only reliable fuel flow meters I know, so far, are these:
These are heavy duty fuel flow sensors that will last enough to take advantage of them. Plastic fuel flow meters based on turbines are many, all of them very fragile.
In my experience, you can find good and reliable and durable flow meters which are very expensive, or, you can find cheap flow meters that will not last for long.
Besides, as you need two and you need to calculate the difference, you need a programmable board to make the calculations.
And, you need to cut whatever mean of fuel transport you have, hose or pipes.
Anyway, if the guys that sell the 13mm flow meters can guarantee durability and resistance and robustness of the meters, and they have a solution to calculate the difference between two meters flows, I would try both, the meters and the digital display. Will investigate more.
The meters look robust, let see how they really are.
There is the posible fuel leaks I know well and the space issue too, you must arrange them and the hoses in little room, but if they work well, I would do the effort.
On the other hand, the rpm and tps method is less precise, but a lot less invasive in the car, you will never have fuel leaks this way.
My objective to retrofit such a device in the car (whichever) is not to know exactly how much fuel the car is spending, but to have a real time and objective COMPARISON instrument. For what? For knowing mechanic mods, tire pressure, driving habits, "fuel economizers", aero mods, etc. real effect in fuel economy.
Knowing exactly fuel economy of my car is as easy as to divide all miles driven with a tank for the gallons of fuel I spent.
There is the posible fuel leaks I know well and the space issue too, you must arrange them and the hoses in little room, but if they work well, I would do the effort.
On the other hand, the rpm and tps method is less precise, but a lot less invasive in the car, you will never have fuel leaks this way.
My objective to retrofit such a device in the car (whichever) is not to know exactly how much fuel the car is spending, but to have a real time and objective COMPARISON instrument. For what? For knowing mechanic mods, tire pressure, driving habits, "fuel economizers", aero mods, etc. real effect in fuel economy.
Measurement will always present some errors. You can have mechanical friction in the measurement device, you can have leakage within the device itself, and you can have electrical delays in the device output. Similarly, you can have lag in your code, and electrical delays in your sensors. In both cases, yes, there are also calibration issues to contend with, as well.
There are also unforeseen drivers that will subtly affect your desired output. For instance, I have noticed that the mathematical model, presented in your excel attachment, does not deal with fuel enrichment pumps that operate with large changes in throttle.
The trick is to obtain reliable repeatability. With whatever method you use, it has to reliably agree with the "divide all miles driven with a tank for the gallons of fuel used" method.
I would suggest, as an alternative, creating a cheapie fuel control computer that runs a single throttle body injector. Sure, it would likely cost a few hundred dollars (fuel injector, throttle body, fuel lines, FI-capable fuel pump, throttle position sensor, mass airflow sensor, O2 sensor if you well and truly wanted feedback operation, and the computer hardware itself). However, you'd have a lot more control over what was being injected into your engine, and you'd have reasonably accurate fuel measurement.
I do not mention MegaSquirt because it looks like MegaSquirt is moving away from the "cheapie fuel control computer" concept.
I tried unsuccessfuly to get more info about the fuel meter you recommended to me at first, the 13mm red one, no Brand one. I forgot my password in EBay and these guys insisted in sending me codes to my line phone, which are unusable.
But I searched myself in a chinese provider and found this:
If you look carefuly it is the same fuel meter, and happend to be a reliable fuel metering method or mechanism and it is a japanese one. All that tell me it is more reliable than the majority of them, and very cheap. It makes sense to me that it is more expensive to buy it from China than from EBay if it comes from Japan.
Can you Access EBay seller to ask him some questions? Hopefully get his email. I need to have two meters and calculate the difference between them to get the fuel used. As he sells a digital display that matches the fuel meter, maybe he may have a differential meter too.
In relation to your momments, yes, I had problems computing fuel in Arduino, because of a delays, lack of speed, variations. I tried to compute the mean of ten pulses each time to may the instrument more representative and more stable, but Arduino almost could't cope with that.
And as I told you, when I was getting some stable results, the fuel meters stuck and begin to leak. They were too fragile.
Besides, Arduino program was working well on the protoboard, but when I moved to a stand alone box, it failed miserably. This took me more time to correct and the fuel meters died.
Interesting marine gauges - I wonder how they could be interfaced into MPGuino... They appear to use some sort of serial messaging protocol. Can't be that hard to implement.