It's certainly possible and has been done by a few people.
The Td5 uses a ISO14230 protocol, so the documentation for that gets you a long way down the path. ISO14230 defines the communication and the framework which supports the manufacturer specific requests. The manufacturer specific information is not documented.
The biggest issue is the security key and response needed to access the diagnostics. You can establish a connection to the ECU without this key and response but you can't access anything useful.
What I've ended up with is a mess of PIC32 C code that interfaces with the ECU using a L9637 driver chip. I've used a Fubarino SD development board, but have blown away the Arduino firmware and use it as a bare metal PIC32. I've also had a small piggyback pcb made - it needs revising as there were a load of mistakes - which carries a small display, switch, L9637 chip, regulator, and a K-type thermocouple interface. The thermocouple chip used was a bad choice as it needs cold junction compensation done in software. I'll pick something else for the next revision.
At this stage the comms and logging are pretty robust. It took a while to get there as running code on the bench and in the vehicle are quite different.
I had bugs where the code was running fine on the bench but would stop communicating intermittently in the D2. I eventually tracked it down to the occasional message that had a checksum didn't match the contents. It looked like one byte was getting corrupted during transmission. Once I found that I realised the code wasn't handling failed checksums properly. It was verifying the checksum but basically aborting when a checksum failed so altering the behaviour to resend the request fixed the issue.
Basically the closer you follow the error handling and timing from ISO14230 the more robust the comms. The Td5 appears to follow the draft standard from 1997/8 rather than the offical 1999 version.
The ECU doesn't seem to care too much about interbyte timing that is specified in the standard, and doesn't check for it in the code. I've tried it with and without the 5ms space between bytes when sending and it doesn't really make any appreciable difference. I think the theory is it reduces the workload on the ECU when running.
cheers
Paul
Bookmarks