Also plug the OVMS into your laptop usb when you are doing this. When the 12v is unplugged it will switch to 5v usb. Mark
On 19 Aug 2020, at 8:42 AM, Soko <ovms@soko.cc> wrote:
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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev