[Ovmsdev] Weirdest value conversion ever

Tue Aug 18 15:36:54 HKT 2020

Morning,

Sorry, I reckon I've been at it for too long and did imply a lot of 
things which are not obvious for someone who didn't do it a million 
times already (as it feels to me :/ ). Let's do it step by step and 
(hopefully) my error is somewhere in the early steps...

I have OVMS (no polls active) and VCDS connected to the OBD port via a Y 
cable. In OVMS I turn the canlog on so I can see what VCDS is sending...

In VCDS I go into the 8C ECU and choose "Erweiterte Messwerte". There I 
have a list of all values which I can activate so VCDS polls it from the 
ECU. VCDS polls/refreshes those chosen values roughly 10 times a second.

So I activate AmpHrs charged and discharged, and KwH charged and 
discharged from the list (4 values in total). VCDS shows me the final 
converted values on the screen:

OVMS logs the following on the bus:

As far as I understand it are the red lines the polls by VCDS (as they 
are 7E5=the header of the ECU) and the green lines are the replies. I 
don't understand the red "7E5 30..." line but I reckon its just like a 
"Please give me the rest of the data".
All 4 values are in the same PID "1E 32" (red, bold and underlined 
above). And the green lines, the bold and underlined HEX values are the 
actual data with the last "aa" being no part of it.
This is my procedure to get the data bytes from the canlog-monitor 
lines...Maybe here is my first error somewhere?!

So I have 16 bytes in total to get the 4 values VCDS is showing me:
*00 09 de e1 ff f6 53 21 00 31 62 92 ff d0 88 04*

Simplicity and the value-Ids (some internal numbers) in the list of VCDS 
suggest that same order as given above. So the first 4 bytes is AmpHrs 
Chrg, than AmpHrs Dischrg and so on. This leads us to this relation:

I've also confirmed this by waiting (with ignition on) until the last 
fraction of AmpHrs/kWh discharged values where changing in VCDS to 
-1154,307 and -362,448 and comparing it with the changed hex values. 
These hex numbers changed:
*00 09 de e1 ff f6 53 2_/0/_/__/ 00 31 62 92 ff d0 88 0_/3/_/__/*

Having said that: Not every change in the hex value changes the display 
value. I have more detail data to this if needed...

The way they change suggests 2's complement storage. So let's convert 
them into integers:

Now, for kWh Dischrg as an example, the factor to get from -3110908 to 
-326,447 is: -3110908/-362,447=8583,07007645256. This is a weird one as 
all the other factors so far have been nice numbers!

If I do this for all 4 values I get these factors:

This cannot be right and therefore a waited a few weeks and did 
everything above again. The result was the same unfortunately:

Some other values have an offset. Like the power-efficiency on the 
charger-ECU. The value=0x00 means 75% and 0x06 means 75,6%. It's a quite 
clever way of using just one byte for this value!
So I thought they use some offset here to. But if I take the delta of 
both days I logged I get the same factors:

For AmpHrs Chrg the first value was 1177,611 and the value week later 
was 1424,809 which gives the delta of 247,198.

So now I'm really out of ideas and thought I ask you guys. As you can 
see all conversion factors are close to each other but not exactly the 
same. And given that the VW engineers are quite clever I can't accept 
they would use such weird factors for a conversion.

If you have now another look at the one screenshot I took in my first 
mail you should understand it as it is just the complete version of the 
bits I did here...

Any ideas are highly welcome.

Soko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjbnpadlhnalnloe.png
Type: image/png
Size: 2433 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lejcbcpkglbjjfae.png
Type: image/png
Size: 14797 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: giamhgmdmpcelheb.png
Type: image/png
Size: 3747 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: badiafagplgohkkj.png
Type: image/png
Size: 4815 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dncnhfckigkdlljc.png
Type: image/png
Size: 8016 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fiiimbljgldacoja.png
Type: image/png
Size: 8449 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0019.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nblbkolnjdkfbhpi.png
Type: image/png
Size: 7104 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/a9ff780c/attachment-0020.png>