[Ovmsdev] Weirdest value conversion ever

Tue Aug 18 16:05:56 HKT 2020

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/0b4763d9/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/0b4763d9/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/0b4763d9/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/0b4763d9/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/0b4763d9/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/0b4763d9/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/0b4763d9/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/0b4763d9/attachment-0020.png>