There is a stunning lack of public OBD PID data for the XK8 and XKR. Chirpy and I have been putting together a PID list for the extended (and standard) PIDs hopefully applicable outside the 2001-2001 XK8/XKR data from which it has been reverse engineered. Current sources include the Foxwell NT-510 scanner and IDS itself.

Any other contributions are welcome.

The extended PIDS are all currently Ford service 22, and the standard PIDs include every PID my XK8s (2001, 2002) recognize. Applications such as Torque Pro and/or OBD Fusion can use this data. This list will be periodically updated. It currently includes ~200 PIDs. Not all are 'cooked' yet (i.e. the exact location within the data, conversions from data to useful information, etc), but many are fully reverse engineered.

List in Excel form below.

Disclaimer: No usefulness or warranty for any purpose is expressed or implied. There is no guarantee that any of these are correct values for any car. Use at your own risk. Observation: Many of our vehicles can travel in excess of (240 km/hr) (150 mph) and weigh upwards of 2 tons, occasionally with no top. So, presumably, we all have some passing familiarity with personal responsibility. Please use it here.

 

This is awesome. Thank you for the effort. I have an s-type so I can't imagine these will translate exactly, but hopefully close. I plan to do some canbus learning in the future.

 

Updated the PID list, the majority now have IDS names, good conversions, and locations (now over 200 PIDS). For convenience, the list includes the standard PIDS available on the XK8. Should be much more useful. The main missing bits are XKR-only PIDs, especially for the Mercedes TCM.

To use these on my MX+ ELM-like device and OBDFusion, I had to freeze the headers and issue commands to make the reader take the appropriate IDs for requests (e.g. 7E8 for the ECM) and responses (e.g. 7EB for the ECM). For the MX+, these commands are ATSH 7E8, ATCRA 7EC. If one wanted to use TCM PIDS, this would become ATSH 7E9, ATCRA 7ED. Note, one of the recurring pids must be the initialization PID (Mode 01, PID 10). The module IDs in the XK8/Rs were not the eventual standard definitions which is the reason the automatic extended mode 22 pids don't work on ELM devices without a few commands.

I also have listed the SCP PIDs (more than 300 of them). Since my Mx+ and other equipment can scan that network too (SAE J1850, some of which may be accessible on the ISO 9141-2 network too), I may look at these one day since they appear to be useful.

 

Finalized the 2001-2002 XK8 Mode 01 and 22 PID search in collaboration with Chirpy, over 200 ABS, ECM, INST and TCM pids representing everything IDS has for the XK8 with some added PIDS from my Foxwell scanner. Pretty much the only thing that remains are XKR specific PIDS that my cars will not respond to (Chirpy?). Most of the final PIDs (like low oil, transmission hot mode, inertia switch...) were determined by injecting fake response messages over the actual response messages until IDS or the Foxwell scanner recognized them as the appropriate PID. Fun game, turns out this works fairly well unless you send too many of them too fast, overload the bus, and causing CAN errors (Yes, you can pile up a dozen codes in milliseconds, but easily fixable).

I've rearranged the bitwise definitions to follow OBDFusion (and ELM) conventions, and I am currently using a number of these with the Mx+ device and OBDFusion. There is likely some amount of commonality in the several years before 2001 and in the several years after based on the incremental changes in the relevant control modules.

This list should be fairly definitive at this point. Sometime in the not-so-immediate future, this can be extend this to the SCP network (body processor and associated modules) PIDs listed in the document.

Enjoy.

 

So, this would be the baseline information for a nice Jag-aware software tool. Like, say, a TorquePro extension or something?

 

Absolutely. In fact, anyone could add these (with a caveat) since I think adding to TorquePro is much like OBDFusion where one puts together a CSV file and adds the appropriate items in the spreadsheet something like (note: not our values below)

Name,ShortName,ModeAndPID,Equation,Min Value,Max Value,Units,Header
Coolant Temperature,ЕСТ,2102,A/255*192-49,-50,140,°C,ECM
Transmission Fluid Temp,TFT,2182,(A-40),-20,250,°C,TCM
...

The tricky part (that I have figured out for OBDFusion, but not TorquePro since I don't have TorquePro) is that the definitions for the modules in our cars don't follow the later standard. Just changing them and their responses to the addresses 7E8, 7EC (ECM), 7E9, 7ED (TCM)... doesn't directly work on OBDFusion. However, the commands to do this may be accessible in TorquePro too. And some initialization is necessary. I haven't fully figured out the details on OBDFusion, but the outline is above.

Not perfect, but attached is the csv file I'm using with ODBFusion (note: if file is brought into excel, 7E8 and 7E9 become 700 million and 7 billion, so one may need to return them to the text values).

 

Sorry for not stepping up lately, problems with rental house out of state/non-paying tenants skipping out leaving mess/covid etc. plus lots on at work. I intend to get to the XKR specific stuff as time permits. Also, I have torque pro so will work on the appropriate headers that are needed for the custom pids (torque pro documentation is not great, but I think I have a handle on it now - my first attempt was slightly off the mark, and no time to re-validate yet). If anyone else wants to have a crack at it, just download the ELM327 datasheet, and most of the info you need is in there - very similar to what crbass has done on OBDFusion - i.e "at" commands

By the way, based on crbass initial canbus rosetta stone decoding, I am working on a canbus repeater/modifier project to allow the rear axle ratio to be changed, by modifying the ABS speed sensor messages. I can confirm that inserting the repeater between TCM and rest of canbus does not cause any codes to be thrown, and car drives fine. Final piece of the puzzle to claim victory is to put in a breaker yard standard mercedes TCM (which I have from an XJR in my desk drawer) and see if it works on my XKR (because I have a modified TCM for 3.27, so if I can make it work with a standard 3.06 TCM then I will feel good about the solution). Project is stalled out, but I'm hopeful I can get to it over the next couple of months - if it works I will post a new thread with the details, if not then too bad....

 

That's the way it goes sometimes. I also was planning on taking considerable time to do this, but it became addictive, like peanuts. Had to finish the bag...

The rest of the 'cast of thousands' assembled at my house (just seems like it) during the coronavirus times was working on a large puzzle in the dining room. My puzzle was larger, in the garage, and I had three of them to compare. So every time anyone drove, I had more data.

Quick question, your repeater is on both sets of TCM wires, or just on the ABS side (intercept/modify incoming ABS signals, don't interfere with outgoing TCM towards the ECM/INST)?

I was also thinking of doing something like that, but not isolating the module. So, reading the headers at the OBD port, when the right one shows up, firing voltage high and low on the bus for sufficient time to have the modules reject the transmission for a CRC error, then replace it immediately with a well-formed message of my own.

 

Two canbus modules, one facing the TCM, one facing the ECU/ABS side - snip the TCM canbus wires in the ECU compartment and splice in another small box, select connectors so box can be removed and direct connections restored.
The biggest issue I am concerned about is the latency + jitter, most of it due to having to receive the whole message (approx. up to 200 us) before it can be manipulated and then re-transmitted (another 80-100 us maybe :- ~35 us for shuffling data between the canbus modules using SPI, plus ~ 50 us interrupt service routine for actually screening/modifying the messages, plus potential buffering delay if messages arrive from both sides at the same time). So can be up to 300 us, but it seems OK so far.....as mentioned jury is still out......

 

Have either of you found anything relating to the message center in the cluster? It would be fun to mess with that on startup and display something.

 

I've tried figuring this out, but no PID that makes sense does this generally. The only thing I have is the INST pid

Name | Short Name (IDS) | Hex value | Bytes | Source | Request ID | Response ID | Example command input | Example response | Conversion
LCD message | LCDMES* | 67 3A | 1 | INST | 0x7EAh | 0x7EEh | 04 2F 67 3A 01 00 00 00 | 04 6F 67 3A 01 00 00 00 | A LCDMES*=A, 1 is blank, 2 is covered by blocks, 3 is ODO, this command sets the display 1 0 255

When I give it anything but 1, 2 or 3, nothing happens. The body processor over the SCP bus may play a role too, but the SCP commands from IDS show nothing obvious.

Note: Forum interface messes up formatting, follow the vertical bars for field separation.

 

Has anybody been able to get these extended PIDs to work on either OBD Fusion or Torque Pro?

I've imported crbass's CSV file into OBD Fusion, but none of the PIDs work, presumably because they lack these extra addressing commands ( eg ATSH 7E8, ATCRA 7EC) for the ELM adapter. I can't see where to add them in either OBD Fusion or Torque Pro as the documentation with those apps is dire), so if anyone else has successfully done this any pointers would be appreciated.

Edited to add the screenshot of the Torque Pro pid editor screen. I wonder if the Diagnostic Start/Stop Commands are the fields needed (this is a blank example)?



Another edit to show the PID editor screen on OBD Fusion showing one of the PIDs imported from crbass's CRV file (FLWS wheel sensor) - you can see this matches the information on the spreadsheet, but there is nowhere seemingly to add the extra AT commands.

 

I was able to make the Transmission Temp PID work in TorquePro, somehow, with the help of the data published on this thread. The thing to remember is that OBDII functions are available only on ISO-9141, so TorquePro is normally in ISO "mode" the entire time. If you need a PID over CAN, you need to first switch to CAN, get what you need, and then switch back. At least this is what worked for me. Screenshots below.

Best of luck, keep us posted.

 

Thanks for that - that is really useful. So we need to know the protocol the module we are trying to talk to uses also? In your example you switch to ISO 15765-4 CAN (11 bit ID, 500 kbaud) then back to ISO 9141-2. Do you know if all the modules use that ISO 15765-4 CAN (11 bit ID, 500 kbaud) protocol or where you found that information out?

I'm not confident enough to experiment at this stage yet, lol.

 

The car has ISO-9141, SCP and CAN (just one type of CAN) networks. The electrical guide has the network layout as well as the list of modules and their connections to each network. I believe the appendix also has a (unfortunately non-technical) matrix of messages by control module.

You probably already have, but the ELM327 datasheet is a great intro/general read on the subject.

 

So its not just the protocol, its physically a different network it switches to (with different pins on the OBD connector). So I'm guessing the commands you used to switch protocol for the transmission module will also work for the ABS module as it is also on the CAN bus - I think I will try that and see what happens.

 

Good grief man, that is a prodigious work and very unselfish of you. Many thanks.


[QUOTE=crbass;2238115]There is a stunning lack of public OBD PID data for the XK8 and XKR. Chirpy and I have been putting together a PID list for the extended (and standard) PIDs hopefully applicable outside the 2001-2001 XK8/XKR data from which it has been reverse engineered. Current sources include the Foxwell NT-510 scanner and IDS itself.

 

For anyone interested there is more information in this earlier thread, including this contribution from @Chirpy which explains those values that fmertz helpfully posted as screenshots above.

https://www.jaguarforums.com/forum/x...-no-sc-222041/

I've tried the same thing, and a few variants, and can't get it to work on my car - Torque just says no data received. At least TorquePro has the facility to add the extra commands needed - I can't see that anywhere in OBDFusion.

Maybe someone else has got this to work as it would be super useful to have these extended PIDs in Torque.