Live data, at last.

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

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.

Datalogger updates

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.

Td5 Datalogger

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 KeyGen now on github

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.

AAP/AAT sensor swapping

Friday, April 7, 2017 - 12:15

This is a fairly niche modification.

EU2 and EU3 engines are fitted with significantly different airbox sensors.

The EU2 uses a three wire Ambient Air Pressure sensor, while the EU3 uses a four wire Ambient Air Pressure/Ambient Air Temp sensor.

The curve of the AAP portions of the two sensors are different and require different parameters to give the correct reading.

Without adjusting the parameters there is a misread of around 10kPa. You'll get an over-read ( -700 m altitude) with EU2 AAP + EU3 tune, and under read (+700m altitude) with EU3 AAP + EU2 tune.

The problem is not so bad with EU2 AAP + EU3 tune as the engine assumes higher air density in some correction maps and will INCREASE injected fuel and give a 0.1 bar increase in the boost limit. The boost level is MAP - AAP so reducing AAP by 0.1 results in boost levels 0.1 higher than the would be with correct setup. I suspect this is why you often hear the comment that an EU3 tune drives better that the correct EU2 tune.

If you've addressed the issue by installing a 4-wire sensor - replace airbox lid, sensor and run an extra wire back to the ECU - the problem occurs when you want to run an EU2 map on the motor. The under-read means the ECU uses corrections which reduce the fuelling plus the boost limit is reduced by 0.1 bar. It guarantees bad performance.

The fix is in

The way to fix this problem is to use the correct parameters for the AAP you have installed. Search for the values for the base map and replace with values for the sensor you are using.

EU3 - 4 wire sensor
multiplier: 13171 ( 0x3373 )
offset: 267 ( 0x010B )

EU2 - 3 wire sensor
multiplier: 10410 ( 0x28AA )
offset: 1227 ( 0x04CB )

It's not too hard to find these values with a hex editor as I think they are fairly unique. As a rough guide they are somewhere around an offset of 0x6A0 from the start of the fuel map. In a Nanocom .map the fuel map always begins at 0x19010.

The donor-ware XDF's now have a patch that swaps the values. It's a bit rough as it shows a stock EU3 tune as being patched, so installing the EU2 parameters requires "reversing" the patch.

Td5 NNN ECU "Base" Code

Sunday, March 5, 2017 - 14:15

One of the very early posts one this site shows a diagram of the firmware layout used on the Td5 NNN ECU's.

The portion of memory located between addresses 0x0000 - 0xFFFF was cryptically called "ECU Base Code", with the note that this is not touched during Nanocom .map uploads.

The "Base" code is possibly better described as management or boot loader code. In normal usage the main function it performs is basic setup of the ECU hardware, verifying that certain check points are present in the Variant and Fuel maps, then running the variant map code if everything correct.

The secondary function of the management code is to provide support for factory programming of the ECU. Without a variant or fuel map installed the ECU will boot into a special diagnostic mode that provides access to the functions need to upload .map files, program injector codes, synchronise with the BCU immobiliser, and set the throttle pedal type. I assume this mode would have been used on the production line to program new ECU after installation into a vehicle.

The management code is identical across all the NNN ECU's with two minor differences.

The first difference is the code identifier. Like engine maps each variant management has a unique identifier. The second difference is the ECU hardware code, which reflects the well know NNN numbering. So the thbtp001 ecu code has the indentifer NNN000120, whereas the thbtp005 has the identifier NNN500250.

The complete list is:

NNN000120: thbtp001
NNN000130: thbtp002
NNN500020: thbtp003
NNN500030: thbtp004
NNN500250: thbtp005

If you are simply uploading .map files using a diagnostic tool you don't need to worry about this as the management code is not touched even if you brick the ECU.

Where you can run into problems is if you upload a complete .bin file from a different ECU type.

One of the differences between the NNN000xxx and NNN500xxx ECU's is that the power driver chips used to control the injectors were changed from Intersil HIP0060 to Infineon TLE6220GP parts. While both types of chips use Serial Peripheral Interface bus to communicate with the MCU the format of the messages and the representation of faults differs.

The ECU code uses the identifier from the management code to determine which driver chip is present.

So if you fit a .bin from a NNN000120 to a NNN500020 or NNN500250 for example the Variant code will read the NNN000120 identifier and use the code for the HIP0060 driver chip, rather than the TLE6220GP.

What makes this problematic is that one chip arranges it's fault codes:

A_OverTemp, B_OverTemp, C_OverTemp, D_OverTemp,  A_OpenLoad, B_OpenLoad, C_OpenLoad, D_OpenLoad

with a value of 1 signalling a fault.

The other uses:

A_bit1, A_bit2, B_bit1, B_bit2, C_bit1, C_bit2, D_bit1, B_bit2

If both bit1 and bit2 are set to value of 1 the channel is operating normally, and if both are set to zero there is a "short to ground" fault present.

This means if you send the diagnostic bits from a HIP0600 showing no faults (all zeros) to an ECU configured for a TLE6220GP the best you can hope for is "short to ground" faults on all channels.

The injector fault check is called in the main loop of the ECU code and it's potentially updated every 10 milliseconds or so. I haven't been able to confirm how this impacts general running, but I've been speaking to someone who has had ongoing issues with poor starting who appears to be running NNN000120 management code on an NNN500250 so it seems fairly likely this is related.

Anyway, it's something to be aware of...

ABS Modulator Option A additional fix

Tuesday, April 4, 2017 - 11:15

I can't say I've had this issue personally, but when my brother owned his D2 he made an interesting find in relation to the Option A fix.

While this information was posted to AULRO at the time it seems to have been ignored and/or forgotten, so I've decided to post the information up here.

One of the potential causes of the Three (or Four) Amigos is an dry or cracked solder joint on the "snout" that the Shuttle Valve Switch plugs into.

Option A (2/3rds the way down this page) provides a way of solving the issue by removing the plastic from behind the snout pins to allow the joint to be resoldered. When my brother went to do this fix he discovered these solder joints were fine. Even after a precautionary resoldering the earth connection was still intermittent.

What Steve noticed was that the "snout" could be moved up and down slightly. After a bit of exploratory digging into the external potting he found a second location with two solder connections where the "snout" joins to the circuit board that holds the external connectors. Apparently these two pins had some kind of corrosion and required a bit of clean up before they could be soldered. After soldering these two joints the play in the "snout" was eliminated and solved the connection remained solid even when the snout was wiggled. So if you are planning on doing the Option A fix it's worthwhile checking that the connection remains solid when moving the "snout".

This photo shows the location of the pins and the kind of excavation required to access. The hole needs to be filled post repair but is hidden behind the mounting so this doesn't need to be especially tidy.

location of snout pins

Pages

randomness