Rebuilding a Discontinued Jaguar XJ220 Diagnostic Tool from Captured Traffic

Published: | Category:

A vintage supercar circuit board being probed with a logic analyzer with colorful test leads, an oscilloscope showing signal traces in the background

Some hardware reverse engineering stories are about clever exploits. This one is about a much smaller, quieter problem: keeping a thirty year old car running when the one tool that talks to its brain is basically extinct.

Tom Radom, who owns Jaguar XJ220 chassis #50, wrote up how he recreated the diagnostic interface for the car’s Zytek ECU after realizing his original tool, a device called the SPD-1039, was effectively irreplaceable. You can read his full account and request a unit at Port220.com, with the story also covered on Hackaday here.

The actual problem

The XJ220 and its even rarer sibling, the XJR-15, both run on a Zytek ECU from the early 1990s. The only tool that speaks its diagnostic protocol is the SPD-1039 interface, and there just aren’t many of them left. Tom already owned one, which put him ahead of most owners, but he was smart enough to realize that “I own the only copy” is not a great long term plan for keeping a car running.

His first move was to try opening the original interface and reverse engineering it directly. That failed immediately: the internals were potted in silicone, presumably to protect trade secrets or just survive a garage environment, and there was no way to inspect the circuit without destroying it.

The actual fix

Instead of fighting the potted hardware, Tom sidestepped it. He hooked a logic analyzer between the original interface and the car and just recorded every byte crossing that link while running normal diagnostic sessions. That gave him the protocol without ever needing to see inside the box that implements it.

From there, he built a replacement using an FT232RNL USB to serial bridge chip, which handles the physical link to the car’s diagnostic port. Here’s the part I like most: he didn’t touch the software at all. The original DOS based diagnostic program still runs fine in an emulator. Only the hardware bridge between a modern USB port and the car’s connector needed to exist again.

What’s clever about this approach

Capturing traffic instead of decapping silicone is the right instinct here, and it’s a technique that generalizes well beyond car ECUs. Anytime you’re facing potted, glob-topped, or otherwise physically hardened hardware, protocol analysis on the wire is often faster and less destructive than trying to get at the silicon. You don’t need to know what’s happening inside the chip if you can fully characterize what goes in and out of it.

Keeping the original DOS software running in emulation instead of rewriting a diagnostic tool from scratch was also the pragmatic call. Rewriting diagnostic software for a system you don’t fully understand introduces a lot of ways to get something subtly wrong, especially for something safety adjacent like an engine control system. Emulating the known-good original and only replacing the part that had actually failed, the physical interface, is a smaller and safer surface to change.

Where I’d have made different choices

Tom is giving these modules away for free to XJ220, XJ220S, and XJR-15 owners, on the theory that keeping the cars diagnosable protects their value more than the cost of building the interfaces. That’s generous, and it’s probably true for a community this small, but free-and-manual doesn’t scale past a handful of requests. I’d have looked at putting together a small batch run through a contract manufacturer once demand was proven, both to make the supply less dependent on one person’s spare time and to build in a small margin that funds the next batch without needing goodwill to carry it forever.

I’d also want more detail on error handling in the bridge itself. FT232RNL chips are reliable, but they’re a generic USB-serial part, not something purpose built for automotive diagnostic timing. If the original SPD-1039 had specific timing tolerances baked in, a straight UART bridge might drop bytes under load in ways that only show up occasionally. Worth stress testing before trusting it during an actual roadside diagnosis.

The alternative nobody in the thread wanted

One commenter on the original piece suggested just swapping the old Zytek ECU for a modern aftermarket unit entirely. Better performance, better efficiency, problem solved forever. The response from other owners was immediate: no, because originality is the entire point of owning a car like this. A modern ECU swap might make the car objectively better to drive, but it also makes it a different car, and for a vehicle whose value is tied up in being exactly what it was in 1992, that trade doesn’t make sense.

It’s a good reminder that “just replace it with something modern” isn’t universally the right answer, even when it’s technically superior. Sometimes the constraint you’re solving for isn’t performance at all.

My take

This is a small story about a niche car, but the underlying lesson applies to anyone maintaining old hardware they don’t have documentation for: capture the traffic before you try to crack the box open. It’s less destructive, it’s often faster, and in Tom’s case it meant he never had to reverse engineer the ECU’s actual firmware at all. He just needed to make something else on the wire look exactly like the tool that used to be there.

Leave a Reply

Your email address will not be published. Required fields are marked *