[Ovmsdev] Weirdest value conversion ever

Tue Aug 18 16:34:06 HKT 2020

Thanks Michael,

A lot of options to check out here, great!

After reading my email again I had a light bulb moment which relates to 
your 100/255 factor example. I thought what if they wanted to make the 
maximum number a (kinda) nice value. So I gave math a try and found that 
a factor of (2^32/2)/250200 works perfectly for the kWh values. So they 
may have said 250200 kWh is the maximum value we want to represent with 
4 bytes. 250000 would have been more nice but it doesn't give me the 
VCDS values. Having said that: If VCDS does also reverse engineering 
maybe they got it wrong ;) Or do they pay VW for the data?

I've also made a copy the VCDS Runtime and all files. But I can't 
believe that they would put such crucial info in an XML file or 
something similar. I reckon you need a disassembler at least...

Soko

On 18.08.2020 10:05, Michael Balzer wrote:
> Soko,
>
> sometimes values are encoded in two parts, for example a 32 bit value 
> may consist of a 20 bit part + a 12 bit part, with different scaling 
> on each part (low + high resolution).
>
> Scaling factors also can be non-intuitive, even the OBD2 standard 
> includes factors like 100/255. Internal values like these may be 
> multiples of some odd current sensor resolution.
>
> If (!) bit chunked parts represent integer and fractional parts of the 
> value, you may get more insight if you catch a change from (x).999 to 
> (x+1).000. Be aware three fractional digits may be a rounded 
> representation.
>
> Another option to check is the VCDS software. These systems normally 
> are rule based, so if you can find the rule set, you may be able to 
> find the value conversion scheme.
>
> Yet another option is to send crafted fake values to the VCDS to see 
> how they translate.
>
> Regards,
> Michael
>
>
> Am 18.08.20 um 09:36 schrieb Soko:
>>
>> 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
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/53001515/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/53001515/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/53001515/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/53001515/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/53001515/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/53001515/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/53001515/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/53001515/attachment-0020.png>