[Ovmsdev] Weirdest value conversion ever

Tue Aug 18 16:48:58 HKT 2020

Hi Mark,

Yeah, I've tried that but Thunderbird didn't let me color the lines 
separately so I did screenshots.

So I understood ISO-TP, ISO15765 correctly without even knowing what it 
was :D ;)

So its really up to interpreting the 16 bytes correctly.

I think I will give the car fakeing with OVMS a try next. I think though 
it won't be that easy as VCDS polls the value with ~10Hz and I can't 
type that fast :)
It may goto into error if the replies take too long...

I've already tried to slow down the CPU where VCDS is running on. 
Because the UI of VCDS shows briefly the HEX value before it converts it 
to the real value. At least that's what I thought... But all it displays 
before the real value is shown is "Please wait..." :(

Soko

Your last paragraph contains many many words I don't know (yet). So I 
have to look into all this stuff as well...

On 18.08.2020 10:31, Mark Webb-Johnson wrote:
> I can confirm this:
>
> Please just use copy-and-paste of the text, if you can, rather than 
> screenshots. It is much easier for us to work with.
>
>
> This data is in ISO-TP, ISO15765 format:
>
>   * The 7E5 03 22 is a request
>   * The 7ED 10 … is the first frame of the reply. It provides length,
>     and some data
>   * The 7E5 30 is a request for more frames (with the inter-frame
>     timing specified)
>   * The 7ED 21 and 7ED 22 are the two remaining multi-frame replies
>
>
> The data returned is:
>
>     00 09 de e1 ff f6 53 21 00 31 62 92 ff d0 88 04
>
>
> Assuming 4 bytes per data item returned, that would be:
>
>   * 00 09 de e1
>   * ff f6 53 21
>   * 00 31 62 92
>   * ff d0 88 04
>
>
> To try to decode the values, Michael’s advise is good. You will need a 
> few good known values, along with corresponding data from the CAN bus.
>
> One thing I can suggest is to disconnect the car so you just have ovms 
> and the tool on the bus. Then you can spoof replies:
>
>     can can1 tx standard 7ED 10 13 62 1e 32 00 09 de
>     ...
>
>
> You can mess around with the values and see what the tool displays.
>
> I also suggest you load a crtd dump into savvy can - as well as an ISO 
> TP decoder, that has some utilities to analyse the data in different 
> ways and show all the different variants of values. The DBC editor is 
> pretty useful for that.
>
> Regards, Mark.
>
>> On 18 Aug 2020, at 3:36 PM, Soko <ovms at soko.cc <mailto:ovms at soko.cc>> 
>> wrote:
>>
>> 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:
>>
>> <mjbnpadlhnalnloe.png>
>>
>> OVMS logs the following on the bus:
>>
>> <lejcbcpkglbjjfae.png>
>>
>> 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:
>>
>> <giamhgmdmpcelheb.png>
>>
>> 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:
>>
>> <badiafagplgohkkj.png>
>>
>> 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:
>>
>> <dncnhfckigkdlljc.png>
>>
>> This cannot be right and therefore a waited a few weeks and did 
>> everything above again. The result was the same unfortunately:
>>
>> <fiiimbljgldacoja.png>
>>
>> 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:
>>
>> <nblbkolnjdkfbhpi.png>
>>
>> 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 <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> 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/1e25e442/attachment.htm>
-------------- 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/1e25e442/attachment-0002.png>