[Ovmsdev] Weirdest value conversion ever

Wed Aug 19 08:42:28 HKT 2020

About sending spoof replies to VCDS from OVMS:
If I disconnect the obd plug from car I also loose power to OVMS, don't I? Is there an easier way to solve that than buying an OBD extension cable and make the two CAN wires switchable?

On 18 August 2020 10:31:54 CEST, Mark Webb-Johnson <mark at webb-johnson.net> 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> 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 20 00 31 62 92 ff d0 88 03
>> 
>> 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
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200819/55acda48/attachment.htm>