What's up with the number 127.0?

[avusblue]

I’ve owned cars before with mpg gauges, and it’s a feature I appreciate. I usually leave the “instant mpg” feature up most of the time I’m driving my daily commute. So here’s my question, which is admittedly irrelevant and doesn’t matter. But does anyone else find it odd that when you’re coasting along, the mpg gauge “maxes out” at 127.0 mpg? What is the significance of this number? Most other cars, when they're getting "infinite" mileage, either show 99 mpg, 999 mpg, go blank, show dashes, or whatever. But to max out at such a specific number? Just seems odd.

BTW -- so far, after about 1300 miles, the cumulative average of my 6MT is 32.7 mpg, which exceeds my expectations and I’m extremely pleased with.

[Hawaiian]

I was in a chevy cruz that capped at 99mpg. If they allow that number to go too high it will skew the average mpg way over what it actually is. By allowing it to get to a higher threshold but not hit 1kmpg it will keep the calculated MPG more true to actual real world performance of the car.

[b.e]

It's called "quantization error." It has to do with the minimum volume of fuel which will trigger the "fuel used" sensor. As fuel is consumed, the sensor sends a pulse for every "unit," like a paddlewheel might if it closed a momentary contact every revolution. Yes, you might be using 100 mpg worth of fuel during some interval, but the sensor still sent only one pulse. Same applies to distance traveled.

[ja1217]

Its a computer thing. Most likely they are using an 8 bit number for MPG. So, in other words, they are using 7 bits for the whole number (2^7 = 128, for numbers 0-127) and the final bit for the decimal point.

This may not be exactly right, as it has been a while since I had those early comp sci classes, but the reason for 127 should be related to this.

[Alkiera]

Originally Posted by ja1217

Its a computer thing. Most likely they are using an 8 bit number for MPG. So, in other words, they are using 7 bits for the whole number (2^7 = 128, for numbers 0-127) and the final bit for the decimal point.

This may not be exactly right, as it has been a while since I had those early comp sci classes, but the reason for 127 should be related to this.

Yes, it's a computer thing, with a fixed-point number format that caps out at 127 as that is the largest 7-bit number. Odds are, given it's the ECU in the card doing all that, that's it's either some custom fixed-precision format 7.9 (7 bits for left of decimal, 9 for the right) or it's a byte each, and for some reason they are using signed bytes, where the 8th bit is used for negative values.

[FRiSson]

For what it is worth, after 8 fill ups, I find that my calculations using the odometer and gas pump are within a few tenths of a gallon of the in-car MPG calculator.

The real-time mpg calculator is pretty useful in comparing driving techniques. For example it is more efficient to drive at 2000 rpm in 6th than the same RPM in 5th.

[phattyduck]

Originally Posted by b.e

It's called "quantization error." It has to do with the minimum volume of fuel which will trigger the "fuel used" sensor. As fuel is consumed, the sensor sends a pulse for every "unit," like a paddlewheel might if it closed a momentary contact every revolution. Yes, you might be using 100 mpg worth of fuel during some interval, but the sensor still sent only one pulse. Same applies to distance traveled.

There is no "fuel used" sensor. It is calculated based on injector open time and injector flow rate.

When the car is in gear (MT) and coasting (above say 1200-1300rpm) it really is using no fuel. The injectors never open.

The error on the OBC mileage generally comes from imperfectly calculated injector opening time, plus a bit of 'optimistic' engineering (OBC mileage reads ~2mpg better than actual on most cars).

-Charlie

[Brett]

I'm a EE, and I dork with fixed point math in DSPs and FPGAs all day.

My first thought was that they used an 8-bit signed number, but the fact that there's a decimal place is weird. It could be fixed point as someone said, but that seems unlikely, as it works out to a weird number of bits. Sure it could be 7.9 or something, but that would make your LSB (least significant bit) about .002 MPG, and that's a bit more precision than anyone really needs.

It probably actually is an 8-bit signed value, as weird as that may be. Maybe they gave that part of the interface to a co-op. It reminds me of the original Zelda on the NES where you could only get up to 255 rupees (8 bit unsigned value).

I'm a nerd.

Brett

[dietz]

This would make a great puzzler for car talk. I'm an ME and immediately converted MPG into different units to see if it was a round number, but of course it is not. Can we change the units on the display? That would, I think, confirm that it has to do with being an 8 bit number if we see the same pattern.

[DSPographer]

I agree the 127 probably comes from 7 bits before the decimal or 8 bit signed. This value doesn't have anything to do with the accuracy of the average. You compute average MPG from total miles and total fuel since reset. You never just average together the instantaneous MPG, because when the injectors shut off while the car is moving the instantaneous MPG really is infinity: so there is no correct value to choose that would yield a proper average.

[Want.FR-S]

Question: for the instantaneous MPG figure, do you have the decimal points shown (e.g. 32.7 MPG)?

When it said it shows 127.0 MPG, we do not know if this is an integer (7-bit or 8-bit), or a floating point number (16/32 bit) or a floating point number with other customized format.

Bear in mind that this CPU also needs to be able to display fuel usage number like L/100KM or other units. I would even assume that it can handle the floating point number calculation. Since in integer calculation, you cannot divide past the decimal.

So, if the CPU is doing a true floating point calculation, I would think the number 127.0 MPG was randomly chosen by the person and trying to imitate the maximum value of a 8-bit sign number (2^7-1=127) since it is known that the car could never reach 127.0 MPG in real life.

[old greg]

Originally Posted by Alkiera

Odds are, given it's the ECU in the card doing all that, that's it's either some custom fixed-precision format 7.9 (7 bits for left of decimal, 9 for the right) or it's a byte each, and for some reason they are using signed bytes, where the 8th bit is used for negative values.

Originally Posted by Want.FR-S

Question: for the instantaneous MPG figure, do you have the decimal points shown (e.g. 32.7 MPG)?

More specifically, are there decimals other than ".0" or ".5"? It's possible that it's an 8 bit number in a 7.1 format.

[Want.FR-S]

Originally Posted by old greg

More specifically, are there decimals other than ".0" or ".5"? It's possible that it's an 8 bit number in a 7.1 format.

In the op statement the CPU needs to calculate to an average 32.7 mpg so I would assume it can handle the floating point calculation. Although I was thinking about that 7.1 format as well.

Does anyone have any idea of the CPU that is used in automotive application. I would be surprise if that does not have a floating point ALU embedded already.

[Grimlock]

I'm an embedded software designer, but not for automobiles. Remember that the average mpg reading is basically a calculus operation (area under the curve) of the instantaneous mpg over time. When the instantaneous display reads 127 mpg, it is literally using 0 fuel, which basically means infinite mpg. Since 0 fuel used could really screw up a division, my bet is that they tweak the min fuel used number to give realistic results. On some cars they set it to 99 or 999 mpg. On my VW it used 200 mpg.

I highly doubt that they would use anything less than a standard 32-bit floating point (float in C parlance for most compilers) to represent the MPG. Even they are using 16 bit computers, a half-precision floating point is still capable of representing 2^-14 to 65504. If they are using an floating point processor for this calculation, it would make zero sense to use anything less than a half-precision float.

What I've also done in the past is avoid floating point computations all together. The way this can be accomplished it by using a 16 or 32 bit unsigned integer and take known measurements. Then, floating point division can be approximated by algorithms utilizing integer division, multiplication, and bit shifts. Skipping the floating point arithmetic is great for speedy computations on slower computers.

Like I said before, I'm an embedded software designer, but not for automobiles. I work with much less capable computers and we have to be conscious of how efficient our algorithms work.

My bet is, like I said before, that the 127.0 figure is a decent 'maximum value' for the algorithm to use to produce realistic real world results.