5

Among other things, I'm a computer science instructor. I'm considering a programming exercise to simulate the dashboard mpg display found on many modern cars. It seems easy enough: monitor the fuel line and the odometer data, and at periodic intervals from the start display the elapsed mileage divided by the cumulative amount of fuel used.

  1. Correct so far?

If I figured it right, I have a related question: Is the interval of reporting based on time (say every five seconds) or by distance (say every 700 feet traveled)? The reason I'm asking is that the first option will be slightly more difficult to compute (though by no means impossible) than the first. I have no preference on which option to assign, but I'd like the simulation to be as close to reality as possible.

3
  • 1
    It's actually figured using how much fuel is being shot at the cylinders (injector pulse width or duty cycle) and not monitoring the fuel line itself. Much easier to figure out how much fuel is injected at any one time. Besides, most fuel injected vehicles have fuel return lines, which brings the unused fuel back to the fuel tank ... you'd have to monitor both sides in order to figure it out. As far as the interval, this would probably be specific to the manufacturer. They could set it up however and make it fairly accurate. Commented Sep 13, 2016 at 23:30
  • You might find this interesting - MPGuino an Arduino based fuel consumption display / trip computer.
    – dlu
    Commented Sep 14, 2016 at 0:29
  • I always thought it was a "Consumption Assumption". :-)
    – CharlieRB
    Commented Jan 12, 2018 at 18:15

4 Answers 4

4

Your idea to monitor odometer and fuel line could work in theory, but in reality, it's not used. First, there's often a fuel return line, so you need two flows sensors and calculate the difference of the measured values. This adds cost and complexity, though there are other, already available ways to calculate mileage.

Today's engines use injectors which add a certain amount of fuel to the air. The ECU knows exactly how much fuel has to be injected, and with this information (and the distance driven), you can calculate the mileage without additional hardware.

Further more, there are those apps for mobile phones etc. which connect to the OBD-II (diagnosis) port. Mileage or fuel consumption is usually not available via that port, but information about air flow is. Knowing this, the app can calculate how much fuel has to be added for a perfect air/fuel ratio. This of course does not work for diesels, and usually does not recognize fuel cut-off.

From the programming side, I don't really see a difference. The ECU either uses a timer interrupt or an interrupt on some kind of "distance ticks".

If you watch a mileage gauge, you will see updates every few seconds, regardless of your speed. Think about: It would be nasty if the gauge updates once per minute when you are driving stop-and-go, and also, when it updates twice per second on the highway. A time-constant update interval is much more convenient!

2

Among other things, I'm a computer science instructor.

Hey! Me, too!

I'm considering a programming exercise to simulate the dashboard mpg display found on many modern cars. It seems easy enough: monitor the fuel line and the odometer data, and at periodic intervals from the start display the elapsed mileage divided by the cumulative amount of fuel used.

If you are just posing a homework problem, this is fine. If you wanted to make a commercial product, it can be a little more complex than that.

If I figured it right, I have a related question: Is the interval of reporting based on time (say every five seconds) or by distance (say every 700 feet traveled)?

Every display that I've ever seen has been time-based. It's also a bit more complex than that:

  1. There's usually an instantaneous fuel consumption / mpg reading (which is really just updating over the last second).
  2. There's usually an overall average fuel consumption / mpg since the last reset.
  3. There's often a moving average fuel consumption / mpg that covers a longer window than example 1 above.
  4. Kalman filters are important in all of the above.

However, if you just wanted to introduce the students to some basic system & user interface programming an average over a time window is a straightforward problem. E.g., assume that you're getting fuel data + distance covered every 1/10th second or so. Have a time-bounded queue that captures those data samples and produces an MPG estimate at 1 Hz.

0

At least my car uses at least the calculation based on time units, perhaps there is also a backup calculation based on distance.

Reason:

When idling / moving under a certain velocity the display switches to liters per hour. It is impossible to use a distance interval when the vehicle is not moving.

0

I believe (hopefully someone can correct me if I am wrong) that fuel is measured by the flow of the fuel injectors and the time the injectors are open. The injectors are designed to flow a set amount of fuel at the vehicle's fuel pressure. The time they are open is determined by the ECU.

The distance traveled is determine by the Speed Distance Sensor. You get one pulse for each rotation. You are interested in the pulse width - the amount of time between pulses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .