Help me with a little experiment
Joined: Aug 2012
Posts: 7,854
Likes: 3,404
From: Foothills East of Sacramento
You are correct: I screwed up the entry in the calculator and did not do it twice. Funny, I was a little surprised at the difference. Duh!
I don't think it has 2 separate odometers. It just has two firmware outputs for the wheel rotation measurement. Pick one or the other.
I don't think it has 2 separate odometers. It just has two firmware outputs for the wheel rotation measurement. Pick one or the other.
Thread Starter
Joined: Feb 2001
Posts: 4,061
Likes: 363
From: Redondo Beach
Well, one vs. two odo's is maybe just a philosophical/semantic difference - there's obviously only one VSS signal. What I'm getting at is that the main odo's are legally "special" - it's unlawful to tamper with the readings in a way that reduces the apparent mileage. (That's why going in reverse still accumulates miles - that old "trick" to roll back miles hasn't worked in 50 years or more.)
For our purposes, this legal mandate means that every time a certain pre-programmed number of VSS pulses have been counted, a new mile is officially --and permanently-- tallied: the odo is incremented by 1, and that becomes the "official record" of vehicle mileage. The exact same thing happens for kilometers: the only difference is the number of VSS pulses required to increment the km tally. So there's never any actual mathematical conversion between miles and kilometers; instead, the dash computer just has two different tallies which are proceeding independently. That's why I view them as two odo's: there are *two* "official records" of total distance traveled. One record is in miles and one is in km, but neither one is derived directly from the other, so neither one can be "preferred" over the other.[**But see below]
With this in mind, here's an example of how I believe the discrepancy arises.
[Edit: The basic description below is valid, but the pulse rate is incorrect. See post #22 below for correction/clarification.]
The vehicle speed sensor (VSS) is a device, attached to the transmission, which transmits an electrical pulse to the dash computer each time the third gear set makes one revolution. Each odometer (whether mile, km, or tenth) must count an *integer* number of VSS pulses for each (and every) one of its increments. Now one pulse corresponds to the same physical distance travelled, determined by gearing and tire size. For this example, let's pretend it's exactly 27cm per pulse. Then one km would be 3,703.7 pulses. But you can't count a fraction of a pulse; moreover, you want to be able to consistently increment tenths on the trip odo, which means you want your km count to be divisible by 10. Finally (this being a being Honda lol) let's say you want to err on the side of overestimating speed. So, with all these constraints, you decide to program the kilometer odo to increment every 3,700 pulses. (For the trip odo, a tenth would be 370 pulses.) That means your km readings will be 0.1% too high.
Similarly, for the miles odo, the same 27cm distance corresponds to 5,960.53 pulses per mile. For this example, let's say you go ahead and program a mile as 5,960 pulses (so a tenth on the trip odo is 596 pulses). This is much closer to the "correct" value: your miles odo will only be 0.01% too high.
It's this *difference* in approximation errors that results in our discrepancy. In our example, the odo kilometer will be incrementing at a *net* rate that's 0.09% faster than the miles odo, relative to the exact ratio of km and miles. So the two odo's will appear to gradually diverge from each other.
Based on the data posted here, what we seem to be seeing is that the kilometer odo increments at a net rate that's 0.04% faster than the miles odo. What puzzled me is that the discrepancy seems to be identical for both AP1 and AP2. Due to the gearing and tire changes, I expected to see a different rate of divergence - I even thought we might find that AP2s logged miles "faster" than kilometers. Instead, it seems that the designers decided to keep the same pre-programmed VSS counts for the AP2. I suspect they thought it didn't really matter, given that the *actual* error of the odo(s) (relative to the *actual* distance traveled) is about an order of magnitude larger than this effect. (Some owners have reported "real" odo errors of as much as 5 or 6%!)
I'd still like to see some more AP1 data, though.
** "Neither one can be preferred over the other": Of course, once the vehicle is sold with a warranty or other legal condition that's expressed in, say, miles rather than kilometers, then the miles odo becomes the legally preferred reading. However, because both mile and km tallies are independently generated, stored, and electronically protected from tampering, each one is eligible to be the "official vehicle record", and Honda doesn't need to worry about which units are legally preferred in the market where the car is sold.
For our purposes, this legal mandate means that every time a certain pre-programmed number of VSS pulses have been counted, a new mile is officially --and permanently-- tallied: the odo is incremented by 1, and that becomes the "official record" of vehicle mileage. The exact same thing happens for kilometers: the only difference is the number of VSS pulses required to increment the km tally. So there's never any actual mathematical conversion between miles and kilometers; instead, the dash computer just has two different tallies which are proceeding independently. That's why I view them as two odo's: there are *two* "official records" of total distance traveled. One record is in miles and one is in km, but neither one is derived directly from the other, so neither one can be "preferred" over the other.[**But see below]
With this in mind, here's an example of how I believe the discrepancy arises.
[Edit: The basic description below is valid, but the pulse rate is incorrect. See post #22 below for correction/clarification.]
The vehicle speed sensor (VSS) is a device, attached to the transmission, which transmits an electrical pulse to the dash computer each time the third gear set makes one revolution. Each odometer (whether mile, km, or tenth) must count an *integer* number of VSS pulses for each (and every) one of its increments. Now one pulse corresponds to the same physical distance travelled, determined by gearing and tire size. For this example, let's pretend it's exactly 27cm per pulse. Then one km would be 3,703.7 pulses. But you can't count a fraction of a pulse; moreover, you want to be able to consistently increment tenths on the trip odo, which means you want your km count to be divisible by 10. Finally (this being a being Honda lol) let's say you want to err on the side of overestimating speed. So, with all these constraints, you decide to program the kilometer odo to increment every 3,700 pulses. (For the trip odo, a tenth would be 370 pulses.) That means your km readings will be 0.1% too high.
Similarly, for the miles odo, the same 27cm distance corresponds to 5,960.53 pulses per mile. For this example, let's say you go ahead and program a mile as 5,960 pulses (so a tenth on the trip odo is 596 pulses). This is much closer to the "correct" value: your miles odo will only be 0.01% too high.
It's this *difference* in approximation errors that results in our discrepancy. In our example, the odo kilometer will be incrementing at a *net* rate that's 0.09% faster than the miles odo, relative to the exact ratio of km and miles. So the two odo's will appear to gradually diverge from each other.
Based on the data posted here, what we seem to be seeing is that the kilometer odo increments at a net rate that's 0.04% faster than the miles odo. What puzzled me is that the discrepancy seems to be identical for both AP1 and AP2. Due to the gearing and tire changes, I expected to see a different rate of divergence - I even thought we might find that AP2s logged miles "faster" than kilometers. Instead, it seems that the designers decided to keep the same pre-programmed VSS counts for the AP2. I suspect they thought it didn't really matter, given that the *actual* error of the odo(s) (relative to the *actual* distance traveled) is about an order of magnitude larger than this effect. (Some owners have reported "real" odo errors of as much as 5 or 6%!)
I'd still like to see some more AP1 data, though.
** "Neither one can be preferred over the other": Of course, once the vehicle is sold with a warranty or other legal condition that's expressed in, say, miles rather than kilometers, then the miles odo becomes the legally preferred reading. However, because both mile and km tallies are independently generated, stored, and electronically protected from tampering, each one is eligible to be the "official vehicle record", and Honda doesn't need to worry about which units are legally preferred in the market where the car is sold.
Thread Starter
Joined: Feb 2001
Posts: 4,061
Likes: 363
From: Redondo Beach
Joined: Aug 2012
Posts: 7,854
Likes: 3,404
From: Foothills East of Sacramento
Simplicity is key. The car is counting pulses/rotations/whatever. So many pulses (and percentage of it) is directly computed to miles, if selected and it will show computed klicks
if desired. Same data, just different computing depending on what is selected. Like flipping a switch on Fahrenheit vs Celsius thermometer. One sensor is used to compute the data two ways.
if desired. Same data, just different computing depending on what is selected. Like flipping a switch on Fahrenheit vs Celsius thermometer. One sensor is used to compute the data two ways.
Thread Starter
Joined: Feb 2001
Posts: 4,061
Likes: 363
From: Redondo Beach
Cosmo, I think that's how we all intuitively assumed it would/should work: just store a running count of *total* VSS pulses, and then translate that number to either miles or km using built-in conversion factors. Unfortunately that just doesn't fit the data we're seeing.
First: You'd need at least 32 bits of VSS pulse counts to represent the full 6 digits of the odo, which implies 32-bit math. (In fact, the *exact* conversion factor between miles and km can be stored in just 24 bits.) But the 0.04% discrepancy we're seeing is equivalent to just 10-bit precision! For our hypothetical 32-bit calculations, it just makes no sense that they'd truncate the conversion factors to just 10 bits. If it really operated this way, they'd use all 32 bits, and there would simply be no observable discrepancy between the miles and kilometers.
Second: This method actually involves a *lot* of 32-bit calculations. Worst case, to keep the odo displays updated in real time, you'd be doing two 32-bit divisions at every single received VSS pulse (one division for the main odo, one for the currently displayed trip odo). Now, you might argue that's unnecessary -- it's good enough to just recheck the division every couple hundred pulses, since even the smallest increment of 0.1km is several hundred pulses. But that means you're keeping separate VSS pulse counters going in order to trigger the division operations -- and separate pulse counters are all that's needed to trigger the odo increments anyway!
So it really is as you say: simplicity is key, and the simplest, most efficient, and most robust solution uses the VSS pulse counters that I described.
First: You'd need at least 32 bits of VSS pulse counts to represent the full 6 digits of the odo, which implies 32-bit math. (In fact, the *exact* conversion factor between miles and km can be stored in just 24 bits.) But the 0.04% discrepancy we're seeing is equivalent to just 10-bit precision! For our hypothetical 32-bit calculations, it just makes no sense that they'd truncate the conversion factors to just 10 bits. If it really operated this way, they'd use all 32 bits, and there would simply be no observable discrepancy between the miles and kilometers.
Second: This method actually involves a *lot* of 32-bit calculations. Worst case, to keep the odo displays updated in real time, you'd be doing two 32-bit divisions at every single received VSS pulse (one division for the main odo, one for the currently displayed trip odo). Now, you might argue that's unnecessary -- it's good enough to just recheck the division every couple hundred pulses, since even the smallest increment of 0.1km is several hundred pulses. But that means you're keeping separate VSS pulse counters going in order to trigger the division operations -- and separate pulse counters are all that's needed to trigger the odo increments anyway!
So it really is as you say: simplicity is key, and the simplest, most efficient, and most robust solution uses the VSS pulse counters that I described.
Joined: Jan 2012
Posts: 44
Likes: 3
From: Idaho
Excellent analysis, twohoos. I agree 100% that your conclusion is the most plausible.
Your task now is to instrument up the VSS and count pulses per distance traveled, to verify that the 0.04% correlates to the difference in odo increment points.
Your task now is to instrument up the VSS and count pulses per distance traveled, to verify that the 0.04% correlates to the difference in odo increment points.
Registered User
Joined: Oct 2000
Posts: 15,323
Likes: 28
From: Longmont, CO
It seems pretty simply to me - the ECU simply calculates kilometers as exactly 1.61 times miles, instead of 1.60934 like Google says.
From the examples posted above:
twohoos:
62112 * 1.61 = 100000.3 (100000 reported)
59.3 * 1.61 = 95.473 (95.5 reported, could be hundredths of miles are recorded but not shown)
rrounds:
118570 * 1.61 = 190897.7 (190897 reported)
283.3 * 1.61 = 456.113 (456.1 reported)
cosmomiller:
57787 * 1.61 = 93037.07 (93037 reported)
131.6 * 1.61 = 211.876 (211.9 reported, again, could be hundredths used but not shown)
chuck s:
50698 * 1.61 = 81623.78 (81625 reported, perhaps miles for calculation used was 50698.8)
7397.0 * 1.61 = 11909.17 (11970.0 reported, which falls outside the 1.61 pattern - it's closer to 1.62 for some reason)
The difference between 1.610000 and 1.609344? That's 0.04%.
From the examples posted above:
twohoos:
62112 * 1.61 = 100000.3 (100000 reported)
59.3 * 1.61 = 95.473 (95.5 reported, could be hundredths of miles are recorded but not shown)
rrounds:
118570 * 1.61 = 190897.7 (190897 reported)
283.3 * 1.61 = 456.113 (456.1 reported)
cosmomiller:
57787 * 1.61 = 93037.07 (93037 reported)
131.6 * 1.61 = 211.876 (211.9 reported, again, could be hundredths used but not shown)
chuck s:
50698 * 1.61 = 81623.78 (81625 reported, perhaps miles for calculation used was 50698.8)
7397.0 * 1.61 = 11909.17 (11970.0 reported, which falls outside the 1.61 pattern - it's closer to 1.62 for some reason)
The difference between 1.610000 and 1.609344? That's 0.04%.
