Desktop diagnostics...

Posted: 
Tuesday, January 24, 2017 - 08:00

Garmen has posted up a Python script which at the moment allows the user to read out the "Nanocom Fuelling" parameters. github

The project uses a cheap serial programming interface based on the CP2102 USB to TTL converter plus some external circuitry to interface with comms levels. The trick is that the CP2012 needs to be reconfigured to suit the "non-standard" baud rates, and to allow sending a 0x00 byte with a period of exactly 25ms. It's a fairly neat trick.

Anyway Garmen's work prompted me to pull out a "dumb" OBD-II interface that I'd picked up a couple of years ago and thrown in the cupboard. Most OBD-II interfaces are based on the ELM-327 chip which basically does all the grunt work of managing the diagnostic connection and allows users to simply send OBD commands over a serial connection and read back the response.

A "dumb" interface is a USB to serial converter chip (usually a variant or clone of the FTDI FT232) and hardware to interface with the diagnostic port line levels. These are usually sold as something like "VAG-COM KKL USB Interface" - just google it... These require that the user application to handle all of the communications protocol details.

The interface I have has a cloned FT232BL. The complete lack of markings on the chip is the give away. But as the part cost $14.00AUS including postage it's hard to feel ripped off...

The nice thing about the FTDI chips is that they have a "Bit Bang" mode. This allows you to write a byte to the chip and it will hold that state until you write another byte. It's perfect for doing things like sending the 25ms wake-up message or bit-banging the 5 Baud initialisation sequence.

There are a couple of Python modules that allow access to these FTDI specific features. I'm using pyftdi.

As a rough example of how you do it...

#!/opt/local/bin/python3

from pyftdi.ftdi import Ftdi
import time

HIGH = bytearray([0x01])
LOW = bytearray([0x00])
message = bytearray([0x81,0x13,0xF7,0x81])


uart = Ftdi()

uart.open(0x403, 0x6001)
uart.set_baudrate(10400)
uart.set_line_property(8, 1, 'N')

# Enable Bitbang Mode
uart.set_bitmode(0x01, 0x01)

# Set TX line high
uart.write_data(HIGH)


# Short sleeps in the loop seem to improve accuracy...
# Using time.sleep(.025) for the full delay is very jittery.
# time.perf_counter() can be used instead time.monotonic()
# requires Python 3.3 or later

start = time.monotonic()
while (time.monotonic() <= start + 0.35):
    time.sleep(0.01)

# Set TX line low
uart.write_data(LOW)

start = time.monotonic()
while (time.monotonic() <= start + 0.0245):
   time.sleep(0.00025)

# Set TX line high
uart.write_data(HIGH)

start = time.monotonic()
while (time.monotonic() <= start + 0.0245):
     time.sleep(0.00025)

# Disable Bitbang Mode
uart.set_bitmode(0x00, 0x00)

# Send serial message
uart.write_data(message)

Which should give you something like:

Wakeup Sequence

The ISO14230 spec states the total time for the wakeup time (Twup) should be 50ms +/- 1ms. This code gives Twup of 50.67ms, so is within spec.
As reference the Nanocom sets the line low for 26.54ms and then idles high for 118.9ms giving a Twup = 145.44ms. The Td5 ECU is pretty forgiving.

Td5 KeyGen now on github

Posted: 
Tuesday, January 10, 2017 - 15:45

As a copy of the Seed-Key.txt database has recently turned up in a post on the AULRO forum I've decided there isn't much point in keeping my keygen code under wraps.

Td5 Keygen Github repo

I started doing some testing against the Seed-Key database and came up with some anomalies. As a result I've double checked the code against the ECU assembly code, and I also wrote ended up writing a version in MATLAB to verify what I had was ok. When I ran the MATLAB version against the Seed list I discovered that there are about 308 questionable keys in the database. These are mainly blocks of either 0x2020 or 0xF781 keys which are clearly fillers. This is an example...

SEED_KEY.txt:

F0DD 2020
F0DE F781
F0DF F781
F0E0 F781
F0E1 F781
F0E2 F781
F0E3 F781
F0E4 F781
F0E5 2020

KEY_GEN:

F0DD 7D51
F0DE F9A1
F0DF FCD1
F0E0 2607
F0E1 9303
F0E2 2A0F
F0E3 9506
F0E4 321E
F0E5 990E

There are also two additional values which I believe are wrong.

The Keygen generated values match the remaining 65228 "good" keys.

I'm quietly confident the code is OK, but someone has a 0.47% error rate.

Td5 Tuning - a "Torque Based" approach

Sun, 12/04/2016 - 15:03 -- OffTrack

Introduction

In Feb 2014 I started a small private forum which had as it's main goal the development of DIY Td5 tuning through collaboration and sharing. The forum ran for about 10 months before it was hacked twice and I closed the site.

Shortly after starting the forum, on 11 Feb 2014, I posted a list of key maps and a flow chart of map interactions for the three sets of maps that allow commonly used remapping techniques to be applied to the Td5 engine maps. Subsequent work done with valuable input from mturri, def89, discomad, and russ, included developing and testing the first wide range MAP sensor modification, and discussion of axis extension and rescaling of Smoke Map parameters.

Fast forward to December 2016, and many of the innovations from the Td5Tuning.info forum are now starting to make their way into commercial tunes despite the "strictly for personal use" condition of membership. Rather than leave the information from the Td5Tuning.info forum decay, I've decided to put itinto the public domain so all aspiring Td5 tuners can benefit.

While some have chosen to call this type of remapping "revolutionary", it is more accurate to describe it as the correct way to tune. Rather than working around a lack of information about limiters and map interaction by modifying the injector duration, the aim is to accurately meter airmass and then adjust fuelling parameters to suit. This has major advantages because it allows the ECU to correctly adjust injection quantity and timing.

The method is broadly applicable to both EU2 and EU3 maps. The caveat is that EU3 maps are far more tightly locked to near factory specs and require more work from the tuner to make power. These mods will be covered at a later date.

If your are reading this on the front page, click on "read more". You'll see a list of available "book" chapters , with navigation at the bottom.

Much of the information on the Td5 engine maps posted here has never been publicly available, so if you find it useful, please consider making a donation to the site.

Datalogger updates

Posted: 
Sunday, April 24, 2016 - 14:45

After a week or two distracted by the OLED graphic display - which turned out to be damaged in the end - I've refocused on the core logger component.

I'm now using a simple LED which changes state every time a new line is written to the log buffer. Currently this occurs at slightly less than 0.5 second intervals so it's very obvious when logging stops.

The "refocusing" has meant I've found and squashed a couple of bugs that were causing intermittent issues with the log files. I've also discovered that the road speed data from the ECU is intermittently transmitted with an incorrect checksum. Until I found this issue I had assumed that I was logging too fast. Now that I've added handling for incorrect checksums the diagnostic connection will keep running after "ignition off" until the ECU shuts down.

With a bunch of bugs fixed the logger had a short road test this afternoon. In previous tests the connection would drop after 3 minutes maximum. This time around I was able to take the D2 for a 15 minute drive including a short run on a nearby freeway without out a hitch. I did have a moment of fuel cut as I accelerated on to the freeway and the logs show clearly the MAF sensor voltage climbing above the 4950mV upper limit, and the MAF reading dropping to 0.

A second run to work, to pick up a few things gave another opportunity to test the stability of the logger. The round trip was just under 30 minutes and I found I was able turn the motor off, switch back to accessory position, grab the things I needed from the office, then restart the engine and drive home without dropping the connection. The Nanocom is lucky to do the trip one way without throwing in the towel.

This is a quick comparison of the "Airmass per cycle" figures the ECU calculates from the MAF and MAP done using the MegaLog Viewer scatter plot function.

Live data, at last.

Posted: 
Wednesday, April 6, 2016 - 19:45

The logging to sd card is proving to be a bit of a case of one step forward, two steps back.

Most of the the difficulty has resulted from the decision to make the logging "user" configurable.

Rather than the fixed set of logged parameters that Td5 owners are familiar with from the Nanocom, one of the goals is to allow granular parameter logging . Not all data is available as a single request, but for those that are it's possible to log at more than 10 times per second giving very detailed snapshot of sensor performance.

The screen grab below shows some of the data captured on a short 4 minute run around the block. The top graph is Fuel Temp in C and FT sensor voltage. The lower graph is Engine Coolant Temp and ECT sensor voltage. These are being sampled at slightly more than 4 times per second vs the Nanocom sample time of once every 1.25 seconds.

The log viewer app I'm using is MegaLogViewer HD . The big plus of this over the free Nanocom log viewers is that it's very flexible and allows user defined calculations based on the log data.

Td5 Datalogger Reboot

Posted: 
Monday, March 28, 2016 - 18:00

After a long hiatus I've been working on getting the Td5 Data Logger (aka Raijin Project) up and running.

The low level connection management code has been rewritten so it's a lot more robust. One of the big improvements is that it now uses the 5ms minimum inter byte timing specified by ISO14230 - in practice it's actually between 4.25 and 4.75ms. My theory is this timing allows the ECU more time to handle core processes so should help prevent dropped communications sessions under load. It's still missing error handling and recovery but otherwise working well.

The point to point wired board I've been using for development was a bit impractical for in-car testing, so I've had a piggy back board made up which should make it slightly easier to work on. The board is designed to plug on to a Fubarino SD development board, and has a ISO9141 interface chip, k-type thermocouple interface, 5V voltage regulator running off the OBDII port supply, a 5 way tact switch, and a connector for a small 0.96" OLED. The whole thing is about 25mm by 75mm.

I got notification today that the test boards have finally been shipped, a week later than the original estimated shipping date. I'll be interested to see how they turn out as this was the first time I've used Eagle to design a board and the first time I've had one of my own designs fabricated.

Td5 Datalogger

Posted: 
Tuesday, July 15, 2014 - 17:30

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.

 

Security access granted response from ECU

 

Td5 ECU Tools: scripts for the USBBDM NT

I've been using the USBJtag.com USBBDM NT interface to recover bricked Td5 ECU's and modify VIN information. As supplied the USBBDM NT lacks the required configuration to work with the Td5 ECU, so I have written a package of config files and a script that largely automates the recovery process.

I made a short tutorial video a couple of weeks ago that demonstrates how the "Td5 ECU Tools" config/script package can be used for recovering a "bricked" ECU or loading unencrypted map files.

The main menu of the revised script now looks like this:

The interface and scripts can be used for loading any unencrypted .map file or binary image. This means the system can be used for uploading remaps from vendors who supply maps in the standard Nanocom format.

For a working setup you'll need:

  • USBJTAG.com's USBBDM NT available here
  • USBJTAG software license (needed for Mac or Linux only) available here
  • DC Power supply (in the range of 12-16V - 13.8V is perfect. I use one of these) or plugged into the vehicle harness for "ghetto style" operations
  • 10 pin dual in line header (for soldering a permanent header to the ECU board) or
    • 2 x IDC 10pin dual inline headers
    • 15cm of 10 wire ribbon cable
    • 10 pogo pins

The script package is available for $50.00USD, which helps to support further work on reverse engineering the Td5 ECU firmware.
Site donors can get the scripts for $25.00USD.

The package has been updated to include an archive of all the .map files available in the Nanocom Map Wizard. These have been spilt into Variant and Map .bin files. I've also put together a reference pdf listing all known factory variant and fuel maps.

Please use this  contact form if you are interested in purchasing.

Please do not order unless you have the interface in your possession. A few people have had trouble ordering from USBJTAG.com so you need to make sure the interface arrives before buying the scripts. I can get the scripts sent out within 12 hours of receiving payment.

Pages