Perhaps, but I think reflashing the TCM is a huge risk with no upside for me since I have three of the old illumination boards. I'd probably go lightless before I did anything to the TCM.

The only thing I don't quite get about this is that, while there could be a new mapping between the ZF and the TCM, I see no obviously remotely programmable parts on the illumination module board (either version). So, that leaves me with the same CAN bus input to turn on red light 2 on my old board, for example, and if Jag changes it by flashing the TCM, then old red light 2 doesn't turn on making that a bad software upgrade, especially in the context of a reverse engineered board developed long after the model was discontinued.

Another point is my lack of clarity why a Jag OEM with a Jag part in a Jag box would need to reverse engineer anything, but it's clear that my clarity is unnecessary here.

 

I was suggesting the possibility of turning red light 2 for example can be accomplished using more than one CAN message in the original board. There would be the "Jaguar" message, the "BMW" message, etc. Different messages having the same net result. If a software update changes from the original "Jaguar" message to the "BMW" message, there is no net change if you have the original board because it recognizes both messages as meaning "turn light 2 on". As for the reverse-engineering, maybe the original board is ZF, and ZF did not offer replacement parts after a while. So Jaguar had someone else make that board, and it happens to only support the later message set. This is of course just a theory on my part, but it seems to fit the known facts.

As for the TCM update, the note suggests it is a problem if somehow you had some modification done to the factory TCM software by a third party, and Jaguar overwrote that modification with their own update. To my knowledge, there is hardly anyone making after-market flash updates for our cars, and none for the TCM. To me, the risk is similar to updating your mobile phone. There is always a risk, but you are likely better off with the latest version. I definitely had my car updated early on, both the ECU and TCM (I was told my car was running very old software, likely never updated). But you are also right to be risk-averse as Jaguar dealers only updated the software if you complained about the transmission, never as routine maintenance. Could be wrong on this, but with a proper installation of IDS/SDD, it is likely you would have the option to reflash the TCM with more than one version, meaning you could likely revert the update to an older version if you had problems with the newest one.

 

Hello crbass,


Being the originator of this thread, I'm curious as to who the vendor is in this scenario.


If you would rather not name names, I would simply like to know if it was purchased from a dealer or aftermarket supplier.


It seems that the level of response you received was far superior to what I received from my local dealer.


Thank you and good luck with it. I can appreciate your frustration.


Patrick

 

The dealer was jaguarclassicparts.com, cheapest part, almost immediately substantively responsive, offered a full refund right away.

fmertz,

Indeed, could be true.

I have a CAN analyzer. One day when the mood and time hits, I'll see what messages come over the wires for "light 2" for the original and the "extra crispy" boards (old Kentucky Fried Chicken reference for anyone mystified) and report back.

A couple of years ago, I updated my iphone to the newest software, as usual, and spent months listening to music that sounded like it was being played on a scratchy record player. Fixed by an advanced beta version, but took two major updates before apple fixed it for real. Tried going back to the previous version. That didn't work well.

Science by generalizing a single anecdote...

 

These boards are "write only" devices. The data packet comes from the TCM. The test would have to be before an after a TCM reflash, really. Even if you are no ready for the risk associated to this update, it might be interesting to log the traffic to this board as you move the shifter around. First, the CAN address of the board would have to be discovered...

 

Yes, plan is to figure out what my address and message is for all of the shift locations from my tcm to the board.

Then either a) inject a range of signals on the bus to see if ‘2’ lights up on he new board, probably inducing all range of faults (but probably okay for that address) or, better, b) find someone with a later model who doesn’t mind me taking data off of the bus while they shift with the brake on. The latter should take a couple of minutes tops.

Then compare and contrast...

 

So, this was relatively straightforward and quick since one can shift with the ignition switch on, engine off. So, engine operation, interactions with ABS, etc are quiescent. So, given the theory that this information comes from the CAN bus, it appears that the relevant input is below, repeated on the bus every second or so.

Next will be injecting these into a powered board (original version, have several of these) out of the car and seeing what happens. If that produces the appropriate lights, seeing what happens with the new board.

Gear ID Data
(TCM)
P 0x3E8h 00 00 45 02 00 00
R 0x3E8h 10 00 45 02 00 00
N 0x3E8h 20 00 45 02 00 00
D 0x3E8h 34 00 45 02 00 00
2 0x3E8h 64 00 45 02 00 00
3 0x3E8h 54 00 45 02 00 00
4 0x3E8h 44 00 45 02 00 00

 

Owing to my inexperience with his forum, the formatting went badly in the previous message. How about

 

Unfortunately, based on other CAN analyses I'm doing for an intermittent fault while driving, it appears that the J-gate position illumination is more complex than the codes above cleverly obtained with the engine off/ignition switch on.

Since Fig 5.1 in the 2001 electrical guide says that gear selection position indicators come over the CAN bus, I still assume at least some part/all of the led data is from the CAN bus.

So, back to the drawing board.

 

Reading from my drawing board...

When the engine is on, the leading transmitted byte of ID 0x3E8h (in hex) is Park - 0, Reverse - 16, Neutral - 20, Drive - 31, 4 - 41, 3 -51, 2- 61, (intermediates 17, 27, 37, 70 - P to D engine off, 71 ,74 - 4 to 2 engine off). This is either gear position actual or gear position selected. Based on order within the CAN messages in the electrical guide, it would be actual. My uncertainty on selected and actual is that no other field reacts to the change in gear position without the car moving, so I'm having difficulty finding the second field, even though it should be in the same ID (0x3E8h). For some reason, when the car is off, park and neutral stay the same (all hex again), but, as noted above, R - 10, Drive - 34, 4 - 44, 3 - 54, 2 - 64 (note, this is apparently not the CAN bus definition in SAE J1939-71 SPN 59 - gear position which is defined as 1 byte, 0.4%/bit, 0 offset). In any case, this may indicate why P and N light up with the more modern board, but none of the others do since P and N are constant. There are many other numbers in the hex 10s, 30s, 40s, 50s, 60s that could trigger the other leds in later cars.

 

Ok, not clear why this took me so long, I guess because I kept thinking some part of it would be related to SAE J1939-71 SPN 59, but it is definitively not). Having looked at all the messages now, it's pretty clear that the protocols do not strictly follow the 1998 version of J1939. But refining this:

The leading transmitted byte of CAN bus ECM ID 0x3E8h (in hex) has three messages.

First message, starting at the 3 least significant bits, is the CAN gear position actual. 000 is park, neutral, 001 is first, 010 is second, 011 is third, 100 is fourth, 101 is fifth, 110 is reverse, 111 is intermediate between gears.

Second message, bit 4, is CAN torque converter status, 0 is off, 1 is on.

Third message, top nibble of the first byte (bits 5-8), is the CAN gear position selected. Park - 0000, Reverse - 0001, Neutral - 0010, Drive - 0011, Gear 4 - 0100, Gear 3 - 0101, Gear 2- 0110, (intermediates 0111) (note, as above, not SAE J1939-71 SPN 59 - 1 byte, 0.4%/bit, 0 offset, or SPN 525).

Presumably the third message is the one the illumination board responds to.

When I have time, I'll ping the new board with this and see what happens, but I suspect nothing happens that is different than in the car (i.e. nothing on the new board lights up but P and N). Would be interesting to look at the CAN messages in a later XK8. The 2003 XK electrical manual (and beyond?) has an apparently different set of CAN messages.

 

I was reminded of this oldish thread when I eventually had the need for another gear illumination module fix/replacement today since our "new" car had the usual backlight bulb failure (and much of the rest of the shift housing too, but I digress). So I tried the module supplied by jaguarclassicparts.com again, discussed above, in the hopes that it wasn't a generic problem with 'earlier' (i.e. middle) XK8's.

N=3 now, and it's generic for me. Only P and N illuminated. Considering the CAN instructions from the bus through 2002, I would be surprised if this 'reworked' board works for these years (2001-2002, likely before), no matter what revision of the software is on the modules.

Happily, I have five of the earlier board. All of these work fine except for the backlight bulbs, so I picked one, resoldered the board edge connections and replaced the backlight bulbs with the last two Radio Shack bi-pin bulbs (272-1154) that I had. Based on an extensive (2 minute) internet search, it appears that these may have been the last two on earth.

In the search for spares, however, I have found and ordered JKL-7371 and JKL-8097 that appear to be the same/very similar in the hopes that they will provide the same patchy illumination that I have come to love when the Radio Shack parts expire.