Had a chance to take a quick look at a new run I did last night with a more capable data acquisition system, looks like the data above is undersampled and dropped a number of frames. I have a can logger, but no easy way to wire that in parallel right now.

Will look into this in more detail this weekend, but it appears at least the ECM and ABS first call is on their call IDs is, with the mode/service/data as you have noted.

01 10 00 00 00 00 00 00

Each responds with an 'error' message in one frame on the respective response ID (7F should be error here, I believe)

06 7F 10 00 00 00 00 00

Then the reader asks for data on the respective call IDs (03 = request DTC data as per J1979, I think)

03 22 02 00 00 00 00 00

And gets the response on the respective response IDs (04 should be clear codes, but that's on the input side)

04 62 02 00 00 00 00 00

This exchange, with 0322, is repeated at times with the same response. Interestingly, each overall exchange with the module is ended with the call

01 20 00 00 00 00 00 00

with the response

06 7F 20 00 00 00 00 00

At least this seems organized, less mysterious, compared with the previous data. Will play with this more in the later time and make sure there are no dropped frames and CRC errors...

 

wow you are fast :-)
Certainly this latest capture add some insights

Then the reader asks for data on the respective call IDs (03 = request DTC data as per J1979, I think)
03 22 02 00 00 00 00 00
And gets the response on the respective response IDs (04 should be clear codes, but that's on the input side)
04 62 02 00 00 00 00 00
- I was thinking the 03 indicates the number of following bytes in the message, similar to OBD2 modes?
- 22 for service/mode 22 (maybe along the lines of SAE J2190, although of course I don't have that spec., and this likely pre-dates it...)
- 2 byte PID: 02 00
- and then 4 byte response (62 = 22 + 40 = successful/ACK), requested service ( 02 00), 1 byte of data ( 00 )

One line of thinking could be that if 01 10 is the 'diagnostic enable' message to allow service mode 22 interactions, then given the context you describe of seeing 01 20 at the end of the session, maybe 01 20 turns it off again, i.e. 'diagnostic disable'

I will try and find time over the next week or so to code up a few test routines to investigate in parallel. Trying to use the Torque app is way too clunky and complicated to be helpful.

 

I played around a little more today, and it seems the 01 10 and 01 20 commands do indeed turn on and off the 'mode 22' diagnostics, at least on the ECU (not checked the other modules). The testing was not exhaustive, so I'm not claiming 100% confidence.

So the summary so far for parameter diagnostic reporting procedure (at least the way IDS does it) would seem to be:
- use the canbus (not the OSI 9141-2 serial - although maybe this works too??)
- issue command 01 10 to the target module to enable reporting (use the canbus addressing scheme decoded by crbass) - e.g. ECU at 0x7e8
- get a response back from module (from target address+4) (e.g. ECU at 0x7ec) - which will be 06 7f 10 00 00 00 00
- issue a command for each target parameter you want reported from that module
- 03 22 <a> <b> where <a> and <b> define the extended parameter ID you want (i.e. obd2 customer mode 22 commands) (e.g. to ecu at 0x7e8)
- reports will come back as <# of subsequent message bytes> 62 <a> <b> <1-4 data bytes, depending on PID> (e.g. from ecu at 0x7ec)
- when you are done, issue command 01 20 and get back 06 7f 20 00 00 00 00, to disable reporting

[Higgins - engine oil temp PID appears to be 12 3d, reporting 2 bytes of data. IDS lists range as 0 - 6 V. Engine cold (maybe 60F) the reported data was 02 b6 and IDS showed a voltage of 3.39V. Unless you can dig out some documentation, you will have to calibrate the readings via experimentation :-( ....that's all I have]

 

Thanks Chirpy. But is 12 3d a response you get from sending a specific request, or is it sent across the can bus without requesting it? You are using a scanner tool? I did my logging with a can bus sniffer program in an Arduino microcontroller. I did log several times, around two minutes per session. Each session contains Close to 100 000 records but the sequence 12 3d I cannot fint anywhere in the collected data :-(

The data I collect using the Arduino directly wired to the two can bus wires give my data in the format as follows.

 

To clarify, the IDs you show are 'regular' CAN IDs, they are repeatedly reported by the modules all of the time (e.g. 0x12C, 0x44C, etc).

Then there are diagnostic IDs for each of the modules, as in 'ask and ye shall receive'. The request IDs are 0x7E8 for the ECM, 0x7E9 for the TCM, etc, and the response IDs are 0x7EC for the ECM and 0x7ED for the TCM, etc. The request IDs have PIDs (parameter IDs) that tell the modules what to report and a required structure for the request and the response. There are public PIDs and proprietary PIDS of many forms, but the XK8/R of this period are not exactly standard, it appears. Some standardization was required by the CARB/US/European/etc regulations, but the standards were still evolving, and some appears to be reflected in the request parameters.

As for engine oil, don't know yet what it is, there may be several ways, directly from voltage as noted by Chripy below, or directly through PID 5C, if that works.

 

Yes, appears to be so, and if nothing happens on a request after initialization, the Foxwell just tries again from the beginning. For example, in the sequence below, initiation/initialization happened earlier (01 10), then there was no response later (timeout of that request?). So

Car failure to respond, reinitialized by Foxwell scanner.

Some things like Calc Engine Load (04), Engine Coolant Temperature (05), Throttle Position (11) appear to be standard. Others, I have not been able to figure out yet, but should be straightforward. Not hard to figure out why I started with ones I could easily figure out values for...

Amusingly, Calc engine load above has a value of 19h = 9.8%. There is some slop on this one, the car was off.

 

Thanks for the clarification Crbass, much appreciated. Maybe I will have to get it from the voltage from i wire instead. Checked the Electrical Guide now and it seems the Engine oil temp can be found at the pin EM80-15 with the spec as follows

2.5 V @ 34 °C; 0.5 V @ 90 °C; (DECREASING VOLTAGE WITH TEMPERATURE INCREASE)

Realise this is out of topic, will leave this thread now for what it what supposed to do. Sorry for the disturbance!

 

So TCMs (XK8, XKR) follow the same principal as ECU - good news

That 03 22 20 00 request and response [04 62 20 00 00 ] is perplexing - I have seen it as well, although infrequent, but I know I saw it.
- I put it down as a serial bus error between Arduino and PC, since I am running it close to the limit as I wanted to log in real time, but now I'm rethinking that - I hate mysteries...will try and do some more observations...

 

Higgins, I suggest you do a bit of reading of mode 1 diagnostic reporting on OBD2, Wikipedia info is quite good. This 'mode 22', as crbass explained, is similar but just allows to address more parameters since it uses a 16 bit ID instead of the 8 bit one (256 values only) used on mode 1 OBD2. And the IDs for mode 22 are not published, so they need to be reverse engineered, or purchase a quality scanner/software program where the manufacturer has paid for the 'secrets of the guild' and coded them in (such as the Jaguar IDS tool + Mongoose cable). With your Arduino and canbus shield you have what you need to pull the voltage reports from the canbus without running wires - i.e. 16 bit voltage report. You just need a few data points to reverse engineer the formula between the 16 bit reported value and the actual voltage - likely just a min and max value you have to figure, and then straight line curve. You have two data points already, a bit of software logging while the engine warms up and you will be there. Tougher is the conversion from voltage to temperature. A bit of work with an infra-red thermometer and logging, and you can probably create a curve that is close enough, if there is nothing published - maybe you can get a generic part number? The negative coefficient thermistors have fairly well known characteristics, so dabbling into mathematics and curve fitting, plus guessing the shunt resistor value, and you can get really close, but I doubt it is worth the effort to be ultra accurate.
To be clear, on getting the data reported on the canbus (and depending on how many parameters you have asked to receive, it will be reported about every 60 - 250 ms), you need to load the following hex messages into the MCP2515 (the datasheet is very well written) and send them one after the other.
fd 00 00 00 02 01 10 and fd 00 00 00 04 03 22 12 3d - this is the format used by the MCP2515 registers - SIDH, SIDL, <not used>, <not used>, data length code(DLC), byte 0, byte 1 byte 2 byte 3 etc.. The 11 bit address (0x7e8) in SIDH and SIDL looks weird because it is left shifted as 8 bits in SIDH and the remaining 3 as bits 7 6 and 5 in SIDL.
- I assume you have some friendly software utilities (so taking care of SIDH, SIDL, DLC), but if not you can load it directly in the TX0Buffer using the SPI 'Load TX Buffer" command, transferring consecutive bytes until you are done. And then set the TXB0CTRL.TXREQ bit to 1 to trigger each transmission.
Once this is done, the voltage report will be sent every 100 - 200 ms to address 0x7ec, per the format described earlier, and you can intercept it.

 

A little progress today. Went for a pleasant drive, and my wife agreed to start and stop the data acquisition in concert with Foxwell OBD live measurements. So, I have all of the available Foxwell PIDs for the 2001/2002 for the XK8 in CAN data files. Since I did them 5 at a time, now for the slow process of figuring out what's what and the conversions. Main difficulty is the inability to change some things (e.g. I'm not going to ride around with low oil to check the low oil light). As expected, some of these are standard, some perhaps not. There are about 50-60 of them, here are some I've done to date. This will take a while, but will be quite nice when I start playing with IDS sometime soon.


A good start...

 

I binned it into, 'wait and see what IDS does'. Since you've gotten responses without such a thing, its import remains to be seen.

What I have been using (picoscope) only allows me 5 seconds of logging without frame errors through OBD breakout box, but I have a real-time logger that can go for a month or more. An OBD splitter cable arrives next week so I can use both IDS and the logger at the same time (which reminds me again that I should have bought the CAN logger with wireless streaming...).

 

Nice progress.

Since I already spliced into the Canbus cable for another pending project, I can run IDS into the OBD2 socket whilst simultaneously logging the canbus via the PC. So like you have planned, I can use IDS to trigger requests, and then see what happens. I have hacked some basic software to filter only the 0x7e8 and higher addresses, and then log and display any unique "PIDs' (up to 20) that occur, and log the message details and average interval that they are received (and sent). So I am also now set up to do some logging, if and when I find some time.....

 

I did a few ECU parameters, see attached csv file for importing into your excel master compilation so far...I guess TCM will need to be separated into ZF/XK8 and Mercedes/XKR since they are clearly different codes.
Logged in the order that IDS presents them, skipped some obvious mode 1 values such as fuel trims and downstream O2, got as far as "sensor power supply monitor"...engine was off.
Some codes are clearly bitwise covering multiple items, I did not group those together but you will see the repetitions of the codes.
No attempt made to decode the bitwise coding by toggling the various controls yet, I just captured what was output.

 

Added a few more

 

Over the weekend, I mapped out about 100 mostly mode 22 pids from the foxwell scanner. The vast majority of mine now have conversions, some fairly inexplicable (for example %=(256*A+B)/12. Perhaps the '12' is because they only wanted to use 12 of the 16 bits, but really not obvious.).

There's only a small amount of overlap between what you've done and what I've done (thankfully they appear to be the same values where they overlap). I'll see if I can combine yours and mine into one document over the next few days and proceed from there.

Apart from the IDS reverse engineering that you are doing and I can help with now (if I can somehow con a child again into sitting in the passenger seat operating IDS and the 'list' while I drive), one other thing I'd like to do is to determine which of the standard PIDs the XKs support. The foxwell scanner does not do these for any of my XKs, but I assume many are available.

 

/12 isn't the same as using 12 of the 16 bits

It would be /16.

 

Indeed, mild sarcasm didn't translate clearly.

As noted, inexplicable. It doesn't fill the available bits and is a nonstandard way to derive a percentage to 100. I derived 12 by knowing a couple of answers and regressing every combination of single and two bytes in the response until something like a whole number came out.

I have two that regressed to a multiplication of 33.8 (both transmission input and output speed). I've yet to make actual sense of this, but it reproduces the measured data...

 

Okay, so I put yours and mine together, figured out the set of available standard service 01 PIDs. Between the two of us, we have about 170 extended PIDs and the 23 standard PIDs that the XK8/XKR appears to recognize. These are not all unique because there is clear overlap between the Mercedes TCM PIDs and the ZF5 PIDs. I did nothing to alter or combine these right now while I figure out what the conversions are.

There appears to be some overlap between these and the other Ford PIDs floating around. Anything in yellow is missing a conversion, a bit location, or something. All of the IDs are likely correct when not followed with a question mark. As always, not suitable for any purpose, use at your own risk, no warranty expressed or implied, no deposit, no return.

 

Superb job collating the info, and some great decoding on the formulas.
I guess we will have to chip away at more of these as time permits.

Maybe add a mention that the 01 20 command turns off the diagnostics? With IDS, there must be some kind of heartbeat or error checking, because with my cheap clone Mongoose, IDS sometimes spontaneously issues an 01 20 command (at least I am guessing it is IDS that issues it, since there is no source address in these protocols), and kills the logging, and then displays an error message on the real time data (E012 or something like that) which is frustrating to say the least.

Whilst I have not done any detailed investigation of reporting intervals, it seems based on observation that the reporting interval is around 70 ms +/- 10 ms (serious amount of jitter) per PID, i.e. the more PIDs requested the slower the updates, 140 ms if two enabled, 210 for 3, etc. Maybe this is a standardized thing, I'm not sure since I've not tried to read up on it.

I will also try and cross check the mode 01 support on the XKR correlates with the XK8, although I'd be surprised if any differences.

 

Added the 'turn off' command to the text and some more description. Unclear to me what happens if you don't do this. Also unclear if there is a timeout on the turn-on period (or if a turn-on for 7E8 is okay for 7E9...).

On the reporting interval, mine appears to be about 20 ms between request and response and between response and next request with ~10 parameters reporting (generally a mix of 01's and 22's). Since that was me trying to overload the input to test the performance by firing out all of them at the same time (i.e. 10 parameters does nothing here, my device spaces them out, no matter what idiotic request I made), that may be a low-end value.