Since there is barely no information on the PID and ECU ID on the web for the Jaguar IPace CANbus, I have started some investigation.
I have found a little more than 30 ECU ID, and between 10 to 250 PID per ECU.
I will disclose my finding here : https://www.openvehicles.com/node/2423 since I have using the OVMS device for this.
The ECU ID and PID are available here : <GOOGLESHEETS gid="1830471105" id="1wNMtpPqMAejNeOZGsPCcgau8HODROzceFcUSfk2lVz8">https://docs.google.com/spreadsheets/d/1wNMtpPqMAejNeOZGsPCcgau8HODROzceFcUSfk2lVz8/edit#gid=1830471105</GOOGLESHEETS>
For the moment, I am in the investigation mode, I am scanning extensively the CANbus and collecting all data I can find on the bus.
I have not put any Label to the PID, except the odometer, because it was an obvious one . I found that the VIN is replicated almost in any ECU, and the PID in the Fxxx range contain a lot of Jaguar part number. I hope that will help identifying what the ECU is about.
Anyone who want to help on this is welcome.
I found this, this morning : https://www.seeedstudio.com/Wio-Terminal-p-4509.html
Could be an interesting device , coupled with an Wifi or BT OBD2 reader.... Could be an interesting project....
I have ordered one, just to see....
On 746, 747 are you sure EPIC is front and EPICB is rear? When I do a scatter plot and running in Comfort mode (rear wheel mode) I get this plot which shows that EPIC is more active than EPICB. At light loads EPICB is free wheeling.
Absolutely not !
I got the 'short name' EPIC and EPICB a member on another jag forum.
I looked in the tech doc I have and it says:
HV, DC cables for the High Voltage Junction Box (HVJB), Front Invertor (EPICB) and Rear Invertor (EPICC) are arranged in pairs, each containing a single wire with screening and protection, around which is an orange colored insulated cover. HV, DC cables for the HV interior heater, battery heater and Electric Air Compressor (EAC) are twin core, screened cable surrounded by an orange insulated cover.
There may be some hidden PID on the BECM.
I found that PID 487e, 487f, 4880, 4881, 4882, 4883 are all 220 bytes but they only show up in the PID scan from time to time. I had to bump the timeout to 10sec to read them, and even with this 10sec (max possible on my tool) I have a lot of timeout issue and can't read the value.
PID 4181, 4184, 4185 all fail with timeout. If the pid does not exist, it gives an error code from the ECU, not a timeout. Timeout occurs when the data is too long to fetch.
Could it be where the detail info from battery cell are hidden ? I have the feeling that we should investigate more those long PID.
There may be some hidden PID on the BECM.
I found that PID 487e, 487f, 4880, 4881, 4882, 4883 are all 220 bytes but they only show up in the PID scan from time to time. I had to bump the timeout to 10sec to read them, and even with this 10sec (max possible on my tool) I have a lot of timeout issue and can't read the value.
PID 4181, 4184, 4185 all fail with timeout. If the pid does not exist, it gives an error code from the ECU, not a timeout. Timeout occurs when the data is too long to fetch.
Could it be where the detail info from battery cell are hidden ? I have the feeling that we should investigate more those long PID.
I found something interesting. I am using my OVMS box to investigate the OBD2 bus. The shell command on the box is not able to handle multi frame response, so I had to use the embedded pid scanner to do so. In the case of PID 487e, 487f, ... I was assuming that those PID were 220 bytes long because that is what the PID scanner was telling me, but if I activate the debug level on the OVMS box, I can see that the very first answer from the ECU is
From the Canbus doc, I understand that the first byte "1x (15)" tells me that this is the first frame of a multi frame, and the length is "5df" . The Pid scanner seems to return only "df" data, not "5df" data, and I can see in the log that I have around 1500 byte returned, not 220.
I will box at the firmware code of the box to see if there is an issue with multi frame decoding, but that is interesting because it means that this is way more data on those PID than the first 220.
I found that there is an issue in the OVMS box firmware. I have fixed it, and reuploaded the firmware in the box.
Those are quite interesting. I have attached a file with PID 487E, 487F, ... They have 1503 bytes each.
I modified the firmware to allow a timeout of 30 sec, but now that I found the issue with multi frame response, and fixed it, I am not sure that I really need to increase the timeout. Anyway, I know how to do it now...
I will redo a full scan on BECM tomorrow.
I modified the firmware to allow a timeout of 30 sec, but now that I found the issue with multi frame response, and fixed it, I am not sure that I really need to increase the timeout. Anyway, I know how to do it now...
I will redo a full scan on BECM tomorrow.
Ok.
So I wait your scan and will try to analyze the new results.
If you have time, please PM (or email) the new modified firmware so I can investigate too.
My scan is attached in "becm.txt.zip" three post above....
I will see if I can find the binary file on my laptop. After I compiled everything on the laptop, I used the command "make flash", and it magically pushes the image to the box, but I have no idea where the new image is. I will do some research...
4880 and 4883 look similar. They both have 16 to 18 patterns of 12 to 18 bytes like "47 00 33 00 3a 00 23 00 1a 00 1d 00 12 00 27 00 20 00 28 00 0f 00 09 00 03 00 03"
So with 4880 and 4883, this could be 2x18=36 "ish" set of data , one per cell ?
487f and 4882 also look similar. They both have 16 to 18 patterns of 3 bytes like "28 01 01". Once again, is it 2x18 set of data, one per cell ?
Each cell is configured as "3s4p" .
PID 4885 starts with 62 00 62 00 63 00 63 00 62 00 62 00 62 00 62 00 62 00 62 00 62 00 62 00 62 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 00 00 00 . 0x64=100. Could it be a percentage ? a SOH for each cell, but there is only 27 of them ? What value do you have here ?
I just found this picture in the other Ipace forum, looking for a report sample... Some PID to add to the collection....
Capture d'écran, le 2021-03-30 à 16.26.00.png
So I guess
- 4915 is the Average State Of Health (Power fade)
- 4916 is the Min State Of Health (Power fade)
- 4917 is the Max State Of Health (Power fade)
And found this other pic. This seems to be a screenshot , and we can see that there is a window scroller on the right side of the pic, so probably more "cell" in other screens.
Yes , already saw those pics.
Question is:
Which value JLR uses to define the battery SOH? They have (from bms) 6 values, 3 for power and 3 for capacity.
Furthermore they printed, in this report, not less than 36 modules, each one with a SOH value.
If Pathfinder extrapolate those value has to read, somewhere at least the single module tensions...
Did anybody found the Pid for displayed Soc value? I mean the dashboard reported Soc thst goes from 0 to 100%. I know I can extrapolated that value from real Soc but I wonder if there is a dedicated Pid for that value. It would be useful while logging charging session as we all refer for comparison to displayed Soc and not to real Soc.
I don't, for the moment, but I am not sure it is available, or maybe in the Instrument Panel Cluster Module (720).
When I look at the OVMS code for other car, they usually try to "correct" the raw value with a formula.
I don't, for the moment, but I am not sure it is available, or maybe in the Instrument Panel Cluster Module (720).
When I look at the OVMS code for other car, they usually try to "correct" the raw value with a formula.
When you have time could you please check 0xd031 on 720 ? I got a value of 76 while my displayed Soc was 77% . Also it is interesting 0xdd06 as in my case it has a value of 231 (231/3=77). Just guessing of course ...
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Related Threads
?
?
?
?
?
Jaguar I-Pace Forum
101.4K posts
7.5K members
Since 2016
A forum community dedicated to the Jaguar I-Pace owners and electric SUV enthusiasts. Come join the discussion about performance, modifications, classifieds, troubleshooting, maintenance, and more!