While the Nanocom is a pretty useful diagnostic tool it leaves a lot to be desired in terms of datalogging, so I've been messing around with the idea of building a dedicated datalogger for the Td5.
The time I've put into reserve engieering the ECU code has been very useful in this regard. I have been able to identify the routines used to generate and verify the security keys - done using linear feedback shift registers - which are required to gain access to many of the diagnostic functions of the Td5 ECU.
At this point I've been able to sucessfully negotiate a connection with the ECU and request "live" data. On my test ECU running on the bench I'm able to request a single parameter every 20ms. Unfortunately this seems to take a bit of a hit when the ECU is actually hooked up to a running engine, so this appears to best possible under ideal conditions. Nonetheless it appears that it should be possible to log full engine data at around 3-5 times per second, which is substainally better than the Nanocom's once every 1.1 seconds. By prioritising requests so that slow changing data is requested less frequently it should be possible to log critical parameters 10 times per second or faster.
I've also verified that it is possible to request specific data from the ECU providing you where in memory the data is stored. This opens up the possibility of logging the values returned for ECU map lookups. As an example you could log throttle amount, aircharge and the result of the smoke map lookup.
It's still early days yet and I'm currently working to make the code I have already written more robust.
The current wish list also includes an interface for a EGT probe, and ability to connect of other sensors that output 0-5V.
I've attached a screen capture showing a capture of "Raijin" ( the shinto god of storms and thunder) sending a key response and the ECU responding with a security access OK message. Top line is the transmit line and the bottom is the recive line. The ISO interface chip (ST-Micro L9637) I'm using echoes the transmitted data back on the rx line hence the duplication of the TX packets.
