I have a spare instrument cluster from my Toyota vehicle that I am using to reverse engineer CAN BUS signals. I have located the address and 2 bytes of data that control the instant fuel consumption display screen. That data can be displayed in Mpg or L/100Km.
I started sending Hex values to that address to see how the cluster on my work bench would react. For example if I send 01 2C (Decimal 300) the display reads 7.84L/100KM.
I logged several different input messages to get different display values. Now I am trying to find out what the scalar value is to take it from decimal 300 to 7.84 L/100KM.
Here is the data so far. The graph of X=Decimal Value Y= L/100KM value looks close enough to linear so I think there is a set scalar value to multiple or divide by.
According to the equation on my graph if I take the decimal value of the CAN message and multiply by .0247 it should get me really close to the value in L/100KM. Does anybody know how this CAN bus messages are scaled up? Would like to try to pinpoint the exact formula as I think my readings could have slight error.
Is the (presumably digital) display rounding numbers to 2 decimal points or is it just truncating digits beyond the second decimal place?
For example, you say decimal 300 gives 7.84. and 325 gives 8, so 301 calculates to 7.8464 which could either be rounded to 7.85 or truncated to 7.84 for display. What do you see?
More examples, 7.8499 truncated to 7.84 is 0.126% in error and 7.8400 truncated to 7.84 has no error.
Therefore you will expect to see the line look like a sawtooth as the error gets progressively bigger then resets to zero ,or close to zero.
Rounding also adds errors Rounding - Wikipedia.
To make things more complicated, different rounding methods give different errors.
Sorry, that was my mistake with decimal places in Excel.
The display is digital. Instant value is shown on a bar graph. Avg value is displayed to one decimal place.
When the instant signal is the same constantly the Avg value is the same also. So at 300, the display only shows 7.8, at 400 it shows 9.8 but sometimes jumps to 9.9
It is rounding to the nearest tenth. I dont think the algorithm is accurate enough to slowly increment from 300 up or down until a decimal value that shows 7.9 or 7.7.... This would give a range of decimal numbers to move the display 0.1
Putting in a constant 400 and seeing the display alternate between 9.8 and 9.9 makes no sense, unless the manufacturer is introducing "comfort noise" into the signal so that the driver doesn't think the display has frozen.
You say it's rounding, but on what evidence?
A lazy programmer would just truncate the data and 99% of car drivers aren't expecting precise measurements from a dashboard. For example most speed indicators leave the factory a few mph/kph low but you don't hear people complaining about that.
With one decimal place instead of two, the truncating errors are 10 times worse, so the reading errors will vary between 0 and 1.26%. To accurately fit a straight line will requires lots of data points with time averaging to null out the comfort noise so you can see the zero error reset points.
The other thing to look for is the presence of a low pass digital filter by doing a step change say from 300 to 4000 and seeing if the display responds instantly. Any delay or evidence of oscillations indicates a filter which will distort the true readings.
I could believe the data is filtered. How to determine the specifics of that filter I have no clue.
I will try to play with it more and find more specific data points. Might just start at 300 and increment 1 value at a time.
It should be no surprise most owners have complained this reading doesn't seem very accurate. I was really hoping for a integer scalar to get close enough and continue testing from there.
The fact I got somewhat close to linear results on the HEX vs L/100KM makes me think I am going in the right direction.
