TD5 OBD2 Reversing

[DFender]

Hi guys,
Been doing some homework recently on the TD5 and its OBD functionality.

I am aware that the TD5 uses non-standard calls, but I am wondering if anyone has seen or done any work on reverse engineering this?
I want to hook up my laptop and display and log live data. I know that Lynx is available and various other tools, but I am looking to write more functionality into what I display and log with my own sofware. There is alot of OBD and CAN hardware available to sniff this information and fairly cheap.

Looking back on a few threads - OffTrack seemed to be on the right track and did some extensive work. I have also found a few other pages on the net, but they are more targetting fuel map changing etc.

I am a PC engineer by day, but just want to know if I am going down a rabbit hole with a dead-end or if anyone else would be keen to give it a shot as well?

Cheers,
DFender

[OffTrack]

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

[DFender]

Unreal information OffTrack. Was almost starting to give up thinking no one was interested in this sort of stuff!

Have shot you a PM!

[gavinwibrow]

HI Paul and welcome back - you have been missed! Cheers

[Pedro_The_Swift]

Welcome back Paul:cool:

[OffTrack]

Thanks for the welcomes :D

ISO14230 - the fundamentals

Note: everything you need to understand the protocol is in parts 2 & 3 of the ISO14230 documentation. Googling for 14230-2 and 14230-3 will turn up something useful. The Swedish (SSF) versions of the standard are freely available but not quite as good as the 1996 draft ISO standards.

The documentation is a bit daunting so hopeful these posts will shed a little light on how it applies in the real world.


This is really low level but it's really essential if you are going to build an app from scratch rather than "Monkey See, Monkey Do" with a sniffer.

This information is covered in detail in Part 2 of the standard.

Each message sent over the protocol is wrapped in a header of variable length, and followed by a checksum.

http://www.aulro.com/afvb/attachment.php?attachmentid=116416&stc=1&d=1478838873

The Fmt byte is included in every message, while the Tgt, Src, Len bytes depend on the message format - specified by fmt.

FMT is a single byte, divided into 2 sections: 2 bits for address and the remaining 6 bits for length.

http://www.aulro.com/afvb/attachment.php?attachmentid=116418&stc=1&d=1478839524

The address bits describe the addressing mode used in the message and the length give the number of data bytes - that is excluding the header and checksum.

For the initial message to the ECU the tester uses physical addressing mode.

To make this a little more meaningful the address bytes are bits 7 and 6 of a byte. I've highlighted the 8 bits on the calculator, and with physical mode, and none of the length bits set the FMT header the has a hex value of 0x80.

http://www.aulro.com/afvb/attachment.php?attachmentid=116419&stc=1&d=1478840313

In practice you never have a zero length message, but under some conditions the length bits are set to zero.

This screen capture shows the functional addressed message from the tester to td5 ECU.
This is done with the standards compliant 5ms (actually slightly under) interbyte timing I mentioned in the previous post.

http://www.aulro.com/afvb/attachment.php?attachmentid=116421&stc=1&d=1478840799

You can see the fmt byte in this message is set to 0x81.

Looking at how this maps out in terms of bits you can see that the two address bits are set to 10, and the length bits are set to 000001.

http://www.aulro.com/afvb/attachment.php?attachmentid=116423&stc=1&d=1478841289

The length header tells us that this message has a single SID or data byte.
Note that the logic analyser capture above shows a complete message with five bytes in total.

Referring back to the first image we see that the final byte is always a checksum which is the sum of all the non-checksum bytes.
Ion this example it is the sum of 0x81 + 0x13 + 0xF9 + 0x81.

Fire up a hex calculator and add them together and you get 0x20E while the checksum is 0x0E.
The checksum uses only the lowest byte of the sum - this is known as a Modulo 256 checksum.

Next post I'll cover the address bytes in a bit more detail.

[OffTrack]

Continued...

The address bits 0x80 indicate at the message includes TarGeT and SouRCe addresses. The Target Address is the recipient of the message and the Source Address is that of the sender. As illustrated in the first image in the previous post the FMT byte is followed by the TGT then SRC bytes.

Breaking the logic analyser capture from previous down, we have:
FMT: 0x81 ; indicates address mode and length.
TGT: 0x13 ; target address for the Td5 ECU
SRC: 0xF9 ; tester address which can be in a small range for general diagnostics
DATA: 0x81
CKSUM: 0x0E ; lowest 8 bits of 16 bit checksum aka Modulo 256

So what does this all mean?
The first data byte is always a Service ID or SID.
The SID 0x81 corresponds with a startCommunications Request and the format for a message of this type is defined as:
FMT 0x81
TGT xx
SRC xx
DATA/SID: 0x81
CKSUM xx

I've cheated slightly as the startCommunications Resquest must be preceded by either a fast or 5 baud initialisation that wakes the ECU for communication.

http://www.aulro.com/afvb/attachment.php?attachmentid=116428&stc=1&d=1478849646

To perform the fast initialisation the diagnostic line is held line idle state - which is high// battery volt - for time Tidle.
This is required to be at least 300ms after the ECU starts up.
Then the diagnostic line is brought low for TiniL (25ms +/- 1ms), then high for 25ms +/-1 ms before the startCommunications Request message is sent.

This is capture illustrates the fast init 25ms low 25ms high sequence followed by startCommunications Request and the startCommunications Response from the ECU.

http://www.aulro.com/afvb/attachment.php?attachmentid=116430&stc=1&d=1478850139

The startComms Request is same as previous post.

The startComms Response shows some interesting details...
http://www.aulro.com/afvb/attachment.php?attachmentid=116434&stc=1&d=1478853698

The FMT byte in the ECU response is 0x03indicating that the address mode is now 0 0, or "no address information", and the message length is 3 bytes.

http://www.aulro.com/afvb/attachment.php?attachmentid=116435&stc=1&d=1478854157

This indicates the message does not use the TGT and SRC addresses in the message header.
The format for the response message is:
FMT byte
startCommunications Positive Response Service Id
KeyByte 1
KeyByte 2
Checksum

Positive response service ID's are always the Service Request Id + 0x40. for e.g. 0x81 + 0x41 = 0xC1.

The key bytes serve to define the protocol to be used for following communications.
Table 5 of Part 2 of the ISO14230 has the complete breakdown of possible combinations.

0x8F 0x57 indicates that messages will use a 1 byte FMT header with an optional additional length byte.
This defines how all diagnostic communications in this session should be formatted.

The additional length byte is used when the message is 64 bytes or longer. This is required because the largest number that can be represented by the 6 bits of the length portion of the FMT is 63. If the message is longer than 63 bytes the length bits of the FMT header are set to , so a "no address information" mode message with more than 63bytes will have a FMT header of 0x00.

[LandyAndy]

Hi Paul.
Great to see you have returned.
There will be a lot of D2 owners that would appreciate "The D2 Brainstrust" being back online.
ENJOY
Andrew

[DFender]

Haven't been on in a few days Paul. Thanks very much for your posts - really good information to start with. Will spend some time really going over it.

Cheers

[Walruslike]

Hmmm.... From reading these very detailed posts I'm getting the impression that my naive hope that a cheap odb reader with wifi and a iOS app are not going to be much use when it arrives in the mail.

I'm mainly interested in reading live data to ensure while towing that all is ok... I will await my mail and your posts to see how we go.

Good luck to you in your endeavours to grapple with this.

[DFender]

Hmmm.... From reading these very detailed posts I'm getting the impression that my naive hope that a cheap odb reader with wifi and a iOS app are not going to be much use when it arrives in the mail.

I'm mainly interested in reading live data to ensure while towing that all is ok... I will await my mail and your posts to see how we go.

Good luck to you in your endeavours to grapple with this.

Unfortunately mate - I think you have just purchased a paperweight.
EDIT: that said - still useful on other vehicles!

Ideally - I wanted to pull that data and store it, along with GPS coordinates, so I could compare different temperatures and their effect on the car - as well as towing the boat. I tackle some big hills on the way to my boat ramp and to some of the dams around here, so being able to compare the data would be something I find very interesting.

Still tossing up on jumping down the rabbithole or not.

Wondering if the data can be 'pulled out' of a nanocom or other similar tools after they've done the hard work - and saved elsewhere for later perusal...

[OffTrack]

Hmmm.... From reading these very detailed posts I'm getting the impression that my naive hope that a cheap odb reader with wifi and a iOS app are not going to be much use when it arrives in the mail.

I'm mainly interested in reading live data to ensure while towing that all is ok... I will await my mail and your posts to see how we go.

Good luck to you in your endeavours to grapple with this.

Unfortunately OBD-II is pretty well useless on the Td5.
You'll be able to connect but there isn't much to see.

According to EOBD-Facile web site the TD5 OBDII supports
Mode 1
- Trouble codes
- Calculated load value
- Engine RPM
- Vehicle speed
- Throttle position
Mode 2
- Freeze Frame Trouble codes.

So not much use for live data...

cheers
Paul

[garmen]

Hi all!

Here i add all the info I have about the Td5 in a zip:
Td5_inside_20150825 (http://www.mediafire.com/file/bd499tjl8c337ek/Td5_inside_20150825.zip)

And here a video of a RPM and cooland meter I have made some time ago:
https://www.youtube.com/watch?v=0-HRKtRTEmw

Have a nice day :D

[OffTrack]

...

[Walruslike]

Unfortunately mate - I think you have just purchased a paperweight.
EDIT: that said - still useful on other vehicles!

Ideally - I wanted to pull that data and store it, along with GPS coordinates, so I could compare different temperatures and their effect on the car - as well as towing the boat. I tackle some big hills on the way to my boat ramp and to some of the dams around here, so being able to compare the data would be something I find very interesting.

Still tossing up on jumping down the rabbithole or not.

Wondering if the data can be 'pulled out' of a nanocom or other similar tools after they've done the hard work - and saved elsewhere for later perusal...



I have the Freelander 2 MY 13 and am happily reading my coolant temp, boost, calculated engine load and gearbox temperature on the Fusion ios app talking to the ebay ELM327 unit. Both cost around $15 dollars.


So although the D5 might be a different beast it certainly isnt a papaerweight on my Freelander. :)

So glad I can peace of mind watch things while towing the boat.

[OffTrack]

...

[OffTrack]

...

[DFender]

That is quite amusing.

I'd made a commitment to myself if Kreub or one of his proxies posted the project he refused to share with me in 2014 as an attempt to prevent me recouping something for the time I've spent on reverse engineering the ECU code that I would cease to share any information on the ECU or the ECU mapping.

Guess what turned up in the archive Garmen posted.

So I'm outta here...

Been in the same position myself and definitely can't blame you mate.


I have the Freelander 2 MY 13 and am happily reading my coolant temp, boost, calculated engine load and gearbox temperature on the Fusion ios app talking to the ebay ELM327 unit. Both cost around $15 dollars.


So although the D5 might be a different beast it certainly isnt a papaerweight on my Freelander. :)

So glad I can peace of mind watch things while towing the boat.

Nope, the Freelander conforms to the correct specificiations - so no surprises it works.

The TD5 however, does not.

Cheers,
Matt

[OffTrack]

Been in the same position myself and definitely can't blame you mate.



Nope, the Freelander conforms to the correct specificiations - so no surprises it works.

The TD5 however, does not.

Cheers,
Matt

I've removed my post - because I have some mixed feelings.

I think the archive contains a project that it's author refused to share with me several years ago because it contained material he considered opened him up to risk of being sued by BBS. For that reason I doubt he would have intentionally posted it or caused it to be posted.

I'm not certain it is the same thing but it looks suspiciously like it, and contains all the things he recently insisted mine should include if it was to be of any use.

TBH I feel a bit dirty for even having looked at the code.

I've been really, really careful to avoid copying anyone - this is why I'm so keen on deep understanding of the ISO14230 protocol as a basis of coding etc.

[BennehBoy]

Very interesting stuff Paul, cheers for sharing.