Of ECU's and Electronics

Tuesday, July 2, 2019 - 11:45

Welcome to DiscoTd5.com, a site dedicated to the Land Rover Td5 Engine. The DiscoTd5.com website springs from the interests and experiences of my ownership of a Td5 Discovery which I purchased in May 2011. Since I first set up the site, my interests have become heavily focused on reverse engineering the Td5 ECU firmware, and I'd expect this focus to remain for the foreseeable future.

To thank site donors for their ongoing support, I've decided to give donor account holders "early access" privileges for new tuning and map related content. The content will eventually appear on the site, but there will be delay of around three months. You'll need to be logged in with a donor account to see this "early access" material.

Donated! Didn't get an account?

Yet Another Nanocom Bug: Injector Idle codes

Tuesday, January 5, 2021 - 16:45

It appears that the Nanocom EVO is incorrectly coding the idle trim for Type-1 "Blacktop" and Type-3 "numeric" injectors.

I've done some research and found a post on lr4x4 forum from July 2009 that mentions a bug with Type-1 idle coding which had been fixed in the Nanocom One v2.04 firmware. The documentation was not updated so there was a difference in how codes were displayed.

Prior to the fix in v2.04 the injector idle codes were:

A = 1
B = 2,
C = 0, 3

After the bug was fixed the codes translated as:

A = 0, 3
B = 1
C = 2

The current Nanocom documentation describes the correct A = 0,3 encoding for Type-1 injectors.

However the Nanocom EVO is still using the buggy encoding when writing to and reading from the ECU . To verify check the type-3 numeric encoding by pushing the Inj. Type button until the idle code shows as a number. If the numbers match the correct idle codes for the injector (A = 0 or 3, B= 1, C= 2) then the programmed codes are correct.

The main SOI and EOI trim codes appear to be correct.

Type-2 codes

Type-2 programming seems to be 90% correct. The only questionable aspect is the interpretation of the M code. The Nanocom documentation indicates M is normally programmed as 8 but can be forced to 0.
If the values from E to M were programmed as numerical values from 1 to 8 everything would make sense. The EU3 idle trim has an X-axis with 10 values. The first (index 0) and last (index 9) are correspond with no adjustment. The design of the table suggests the valid values should fall in the range 1-8 and this is what the Nanocom docs describe. However the correlation of M as both 0 and 8 makes no sense at all.
For that to be true M would have to simultaneously be 0 uSec AND -47 uSec. Alt-facts anyone?

Unfortunately without access to the Delphi docs relating codes to timing that is going to remain a mystery, Fortunately the remaining codes for EU3 look reasonable.

Type-3 programming?

The Type-3 programming looks suspiciously like it is broken.

Writing idle codes using Type-3 mode generates the same five hex codes in slots 1-5 regardless of the value in the range 1-8 entered for each injector. Given that at least one of the values is not a valid code I think its safe to say writing this type of injector is not currently supported by the Nanocom.

Programming codes.

At this point I'm tempted to suggest the only 100% safe way to program injector codes using a Nanocom is to find a friend with a Hawkeye.

The least risky path for Nanocom owners is to use the current documentation values to translate type-1 and type-3 codes to type-2 values and then program using type-2 mode.

"Brick Proof" programming tool update

Saturday, August 1, 2020 - 17:30

As I posted previously, I've been working on a tool to enable "brick proof" programming with the Nanocom.

To quickly recap the NNN ECU's have internal protection against failed uploads.

This relies to two things:

  • the checksum for variant and fuel maps have to be correct
  • two verification words need to be set to 0xFFFF.

When the verification routine is run after programming the ECU verifies the checksum(s). If the checksum is correct the ECU programs the verification words in both maps to a preset value.

When the ECU boots it checks that the verification words are programmed. If they are present and contain the correct value the ECU assumes the maps are correctly programmed and boots. If either of the verification words are not correct the ECU drops into programming mode and you can connect to the ECU with a programming tool.

While I've seen a one or two .maps with what look like corrected checksums, all have the verification words set to the "successfully programmed" value. This means if the upload fails the ECU reads these values and proceeds as if the ECU has been correctly programmed. If the upload fails at any time after the fuel map verification word has been programmed you are guaranteed a bricked ECU.

Fortunately the Nanocom runs the verification routine after each part of the ,map is programmed.

To take advantage of the "brick proof" programming all we need to do is update the checksums and set the verification words to 0xFFFF.

Td5 MEMS Checksum plugin

After a bit of messing around I've ended up porting my Python checksum code across to a Tuner Pro plugin.

This was fairly quick, although I wasted most of today messing around trying to work out why the variant checksum wasn't correct. I finally created a fresh map from Nanocom map wizard and the checksum calculated perfectly.

I use the ability to calculate the factory checksum using an unmodified map as the benchmark for testing. My theory is if I can recreate the factory checksums from scratch I'm doing ok.

Checksum Plugin UI

Most of the configuration is embedded into the plug-in and the only additional setup required is the data start and end addresses.
This has primarily been done to allow the XDF's to support "weird" formats like the MEMS3 Flasher dumps.

I've tested the plugin on Windows 10 and XP and seems to work on both.

The current XDFs for Nanocom .map formats come with the plugin preconfigured.

A (very) quick guide to Tuner Pro setup

Monday, July 6, 2020 - 17:15

The Donor XDF's take most of the grunt work out out of setting up Tuner Pro for editing Td5 map files. However after a query from a new donor I've realised that I've been assuming people will just figure it out in the end.

To remedy that I'm planning on making a few posts on which cover getting up and running with the XDF's. This first post looks at getting a .map, XDF and "compare bin" loaded into Tuner Pro.

Keep a clean copy to use as a master .map

It is a good idea to treat the .map files supplied with the XDF's as master copies which you don't edit.
Make a copy of the "master" .map and work from that instead.

Loading .maps

Load .map files using File >> Open Bin.
Change the "Files of type" pull down to "All Files" to see and load .map files.

If the version of the tune is not obvious from the file name, the best way to check is by using the built in hex editor.
This can be found under Tools >> Advanced >> Hex Editor. With the Hex Editor open scroll down to offset 0x19010. You should see the tune and variant identifiers in the ascii view at the right of the editor.

In this example the tune identifier is svdxr007. img

The XDF names reflect the tune they are intended to edit so the tune identifier will give you sufficient information to select the correct one for the current .map.

Load the appropriate XDF

With the tune identified its fairly straight forward to load the appropriate XDF from XDF >> Select XDF. Navigate to where you have the donor XDF saved and pick the XDF with same tune identifier as the map you are editing.

Load a Compare Bin

Compare bins are the main reason you need an unmodified copy of the .map or .bin you are editing. From the Compare >> Load Compare Bins menu item load an unmodified copy of .map into the first slot by clicking "browse".

img

Tick enable to make this compare bin active.

Table Listings

There are a few ways to view listings of defined parameters.

Parameter Ordered List

The default is the "Parameter Ordered List".
This seems to be a favourite of those who have used "Td5 Map Editor" in the past.

img

Parameter Category

The alternative way of listing tables is the "Parameter Category" view.
Each defined table is assigned to one or more categories based on function. The main demand related tables are all organised under the collective title of "System Demand", with driver demand, torque limiters and smoke limiter maps organised into sub-categories.

The result is that tables are arranged into functional groups which - in my view - makes it easier to access the tables.

img

NOTE: Andrew Revill's MEMS3 Flasher

Sunday, June 21, 2020 - 14:45

Please be aware that while Andrew's MEMS3 Flasher will read from, and write to, the Td5 ECU, the application was NOT designed with that purpose in mind.
As a result you will need to exercise a degree of caution when using to program the Td5.

Things to note:

  • LR diagnostics do not give access to the boot loader code, so a full EEPROM read cannot be done on any MEMS3 based ECU.
  • Options like clearing adaptations are at best going to result in an error, at worst they may over-write something like throttle or inject config.

It is important to be aware that the "full EEPROM" save file generated by the Flasher and Mapper apps consists of the variant, programming records and tune read from the connected ECU. However a petrol ECU boot loader used to replace the unreadable boot loader.

The "boot033" boot loader used does not configure the ECU correctly and will prevent correct operation of TD5 variant code and tunes if written to flash over BDM or with an external flash programmer.

If you are planning on using the app for tuning I would highly recommend using the option to save fuel map only. You can modify the XDFs to work with these files by setting the offset in the header to 0 and deleting the Nanocom checksum.

The MEMS3 flasher will take care of the LR specific checksumming.

The "Bad Land Rover Engineering" Myth and .map Programming

Tuesday, June 16, 2020 - 13:00

I'm sure you've heard that the reason NNN ECU's get bricked when uploads fail is due to some variation on the "Bad Land Rover Engineering" theme. The spiel on many LR forums is familiar: "NNN: Worst flash programming ever. Blame the incompetent Land Rover engineers."

It turns out that is a myth.

While doing the disassembly I'd found code than indicated that the ECU had routines to checksum uploaded variant and fuel map code and checked that specific bytes were set in both the variant and fuel maps. I didn't really dig any further with that, as Nanocom .map files always had the specific bytes configured.

Then a couple of weeks ago a long time supporter sent me a link to Andrew Revill's K-Series reverse engineering project. Andrew has done some fantastic work with the K-Series NNN, including an NNN flash programmer application that works with a dumb VAG interface.

Reading the description of his programmer triggered an "Ah ha" moment..

It's taken bit of messing around over the past couple of days but I've now managed to confirm that the Nanocom supports "brick proof" programming. The problem is that none of the maps produced for the Nanocom I've seen - from stock tunes produced by the MapWizard to .tun protected commercial remaps - are set up to use the functionality.

Rather than having "worst programming eva" the NNN has an extremely robust mechanism which only makes the ECU bootable after the fuel map has been completely programmed and the data has been verified. But only if the uploaded map ticks all the boxes.

The video shows the "ignition" being turned off after roughly 3KB of the fuel map has been programmed.
Under normal circumstances this would have guaranteed a bricked ECU.

With the "brick proof" configuration of the .map, the ECU boots back into programming mode and the Nanocom connects without any problems.

As an aside I was having major issue with 1.34 firmware on the Nanocom. Yesterday it came up with a black screen and "cannot find NC image" error message. After installing the 1.35 update, then installing again and wiping the configuration after discovering the unlock codes were completely scrambled it is working far better.

A tool that will update .map files to the "brick proof" format is in the works...

Installing 64bit USBJTAGNT on macOS

Thursday, May 14, 2020 - 20:45

It appears that development for the traditional build of USBJTAGNT ended late in 2019, and only the 64bit build is being regularly updated.

As is usual with the USBJTAGNT updates the new macOS 64bit install was a hassle to get working. I'm still using Mojave (10.14.6) so ymmv if you've updated to Catalina.

The update has changed the app to a single bundle application instead of the old setup on folders and executable.

The problem here is that while the developer has included the required libraries in the application bundle they have not been correctly linked - at least under 10.14 - so you get an error when you launch the app. Unfortunately the developer doesn't seem to think the fact the macOS build requires users be command line gurus to even run the app is in any way a problem...

Getting the app running

The least messy way I've found to get the app running is to make symbolic links - low level aliases - to places the OS actually looks for the libraries.

Open up the Terminal app in the Utilities folder and then copy and paste the following commands into the terminal. You'll need to hit enter after pasting to execute the commands.

Note: The old version of USBJTAGNT will not start once you've done the following. The main issue is that both apps use libusb-1.0.0.dylib but the old app requires a 32bit library, the new version uses a 64bit library.

Create a link to the USB library:

ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/libusb-1.0.0.dylib /usr/local/lib/libusb-1.0.0.dylib

And then to the QT Frameworks:

ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtWidgets.framework ~/Library/Frameworks/QtWidgets.framework
ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtGui.framework ~/Library/Frameworks/QtGui.framework
ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtCore.framework ~/Library/Frameworks/QtCore.framework
ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtNetwork.framework ~/Library/Frameworks/QtNetwork.framework
ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtSvg.framework ~/Library/Frameworks/QtSvg.framework
ln -s /Applications/USBJTAGNT.app/Contents/Frameworks/QtPrintSupport.framework ~/Library/Frameworks/QtPrintSupport.framework

Assuming no errors this should give you a functioning USBJTAGNT application.

Using links rather than copying should future proof updates if the framework versions for QT change. You shouldn't need to repeat this when the app is updated.

I'll add details of installing the debrick scripts shortly.

Map Finder

Wednesday, April 15, 2020 - 17:45

The "Stay at Home" directive from local authorities has given me time to dig out a couple of projects I'd put on the backburner last year.

I'd run into problems building the "Map Finder" app for distribution when I was working on it previously. Today I dusted the project off and finally sorted out the build issues.

The app uses a cross platform gui for python called Kivy that theoretically allows an application to run on macOS, Windows, Linux, iOS and Android.

"Map Finder" uses a database back end to display and filter a listing of engine maps based on a set of criteria - Vehicle, Engine, Wheelbase or Transmission and finally Market. The idea was/is that this will end up as part of a cross platform tool for generating and manipulating Td5 engine map formats.

EU3 Specific Limiters

Friday, September 13, 2019 - 08:45

The 3.0 release of the XDFs includes two additional EU3 specific limiters. Both limiters use ambient air temperature (AAT) as part of the calculation of the parameter value. This makes them slightly problematic as Nanocom omits this value from display and logs despite reading the data from the ECU. Fortunately the calculations don’t seem overly sensitive to AAT so an estimation will likely suffice.
If you are estimating its worth understanding what AAT is...

AAT is not Ambient

While it’s been claimed in various places that the AAT sensor measures “ambient temperature” this somewhat misleading. The AAT sensor is measuring air temperature inside the lid of the airbox and can be significantly higher than external ambient temperature.
The airbox temperature is effectively "pre-heated" by under bonnet temperatures, so engine, radiator, turbo, and even sun on the bonnet have an impact.

AAT and ECT

You can see from the logged data above that from a cold start AAT is reading around 26°C. As the engine and coolant warms up under bonnet temperatures increase and “ambient” temperature rises. AAT peaks at 38°C when the vehicle is idling at the end of the log. So in this example there is a 12 degree differential between AAT when the engine is cold and when the engine is hot and idling.

MAF, AAT and ECT

The other factor to consider is that increased air flow reduces the AAT reading.
As can been seen in the zoomed section of the plot, there was a 2.8 degree drop in AAT when there is high flow through the airbox compared with the no load flow.

The take away is if you need to guesstimate assume AAT will be higher than ambient temperature by something like 10°C.

Over temp multiplier

This table is apparently used to limit fuelling to protect against excessive exhaust gas temperatures.

If you look at the table values you’ll see that the limiter has no influence below 3000rpm, nor when the Y axis parameter is at or below the minimum value.

The Y axis parameter is calculated from ambient pressure and temperature:
$$param = \frac{(AAT + 273.2) \cdot 50}{300} + \frac{25 \cdot 100}{AAP}$$

where AAT is °C and AAP is kPa.

If you were at 2000m where standard pressure is 81kPa, and you had an AAT reading at 35°C the limiter parameter would be: $$param = \frac{(35 + 273.2) \cdot 50}{300} + \frac{25 \cdot 100}{81}$$
$$param = 82 = 0.82$$

This value is high enough to trigger limiting above 3500rpm.

The parameter calculation is roughly twice as sensitive to decrease in AAP as it is to increase in AAT. You'd need extreme AAT values in the range of 70-80°C to cause limiting at sea level.

Where this may become a factor is on high road passes - Stelvio Pass is 2757m ASL for example. At this altitude standard pressure is around 74kPa, so you'd be seeing limiting creeping in above 300rpm with 40°C AAT.

It is likely that this limiter will only rarely need to be touched, if ever.

Turbo Overspeed

The Turbo Overspeed limiter is a bit of a silent killer in the EU3 maps.

The limiter begins reducing fuel once operating conditions reach the equivalent of 1.5 bar boost and 680kghr MAF at sea level.

The exact limiting threshold will change with ambient pressure and temperature, manifold pressure, and mass air flow.

Working with the values in kPa, kg/hr and °C the main parameter calculation for the overspeed limiter is: $$ param = \frac{MAP + 0.0424 \cdot MAF \cdot \sqrt{AAT + 273.2}}{AAP}$$

The parameter calculation can be thought of having three main components:

  1. pressure ratio
  2. flow rate
  3. turbo speed constant

Pressure Ratio

This is a measure of input pressure (AAP) to output pressure (MAP). I’m ignoring the pressure drop caused by intercooler here, so:

$$pr =\frac{MAP}{AAP}$$ As an example lets look at pressure ratio required to produce 135kPa boost at AAP = 100kPa and 80kPa. $$pr = \frac{235}{100} = 2.35$$ $$pr = \frac{215}{80} = 2.69$$

You’ll see from the turbo map that turbine speed increases with pressure ratio. This means to produce the same output pressure turbine speed must increase as altitude increases.

Flow rate

The flow rate is determined as:

$$fr = \frac{MAF\times\sqrt{AAT K}}{AAP}$$

Assuming a temperature drop of 9.8°C per 1000m and 25°C ambient at sea level, and MAF = 500kg/hr.

At sea level: $$\frac{\sqrt(25+273.2)}{101} = \frac{17.27}{101} = 0.171$$ $$fr = 500 * 0.171 = 85.5$$

At 2000m ASL: $$\frac{\sqrt(5.4+273.2)}{101} = \frac{16.69}{80} = 0.209$$ $$fr = 500 * 0.209 = 104.5$$

A decrease in ambient pressure and turbo inlet temperature results in an increase in flow rate multiplier.

tb_speed_const

This is a scalar value set to 0.0424 in all fuel maps. This is incorrectly scaled in the 3.0 XDFs. The issue is fixed in 3.1 release.

Reassemble the components…

If we look at the parameter equation in terms of blocks we have this: $$param = pr + fr \times speedConst$$

So using the above values for sea level: $$param = 2.35 + 85.5 \times 0.0424 = 5.97$$ and 2000m: $$param = 2.69 + 104.5 \times 0.0424 = 7.13$$

The Overspeed limiter x-axis starts at 7.0, with no limiting applied below this parameter value.

Two it would appear that his calculation uses what are effectively the x and y axes of a turbo performance map to create a limiter that accounts for the effect of air density on turbine speed.

To further illustrate I’ve mapped the 7.0 parameter value for 680kg/hr MAF at sea level onto a GT2052S 52 trim performance map.

Annotated GT2052 map
Note the figures in red above the x-axis are MAF in kg/hr.

Because this is a calculated parameter the only way to fully assess whether this limiter is actually impacting is to calculate using the above formula from log data.

This can be done with a spreadsheet app or using a calculated field in MegaLogViewerHD.

As a final illustration of the effect of this limiter, I’ll include a small segement of a log from a site donor who was having some major issues with a hybrid turbo and map levels over 250kPa.

OS Limiter in action

The white trace is request IQ after Driver Demand and Torque/Smoke limiters.
The red trace is the IQ after application of the all system limiters including the Turbo Overspeed map.

The point at the cursor shows a 26% reduction in requested IQ corresponding to the 7.5 cell in the limiter map.

You can also see clearly that as the OS limiter parameter increases above 7.0 the IQ after all limiters reduces. MAP levels when limiting is occurring are around 250-260kPa.

The take away is simple:
If you are running boost above 250 kPa on an EU3 with a "new school" map this limiter is kicking your butt.

Adjusting the limiter

Rather than modifying the limiter table I would suggest altering the tb_speed_const.

  1. Work out max Pressure Ratio at sea level - this MAP divided by AAP $$275kPa / 100kPa = 2.75$$

  2. Subtract that from 7.0 to get your flow component. $$fc = 7.0 - 4.25$$

  3. Work out your maximum MAF multiply and multiply by 0.1738 to get flow rate $$720 \times 0.1738 = 125$$

  4. Divide the flow component by flow rate to find tb_speed_const: $$4.25 / 125 = 0.034$$

A note GT2052S turbo maps

The Garrett catalog and website list three different compressor trims for the stock GT2052S turbo: 48, 50 and 52. There are two maps available for the 52 trim version. The newest of these, which shows an extended range to a pressure ratio of 3.5, is on Garrett website. The others can be found in Garrett catalogs.

The problem here is that the Td5 uses the 54 trim compressor, and there is no publically avaliable map. The 52 trim will be the closest in performance but it will not be the same.

Donor XDFs v3.0

Wednesday, September 11, 2019 - 14:15

This was originally planned as an v2.2 update to the Donor XDFs. I decided the change of filenames and change to 1.60 XDF spec required a bump to 3.0.

XDF naming convention

The naming of previous versions of the XDF’s included both fuel map and variant identifiers.

When there are two variants with the same fuel map the only difference in the fuel map is the name of the variant in fuel map header. For editing purposes this means the required XDF is identical.

To eliminate this duplication the v3.0 XDF’s drop the variant name.

Valid Gear Ratio

The ECU uses engine speed and road speed to determine the currently gear selected.

Manual maps specifically check that the current gear ratio is within +/- 12% of the value defined in the Valid Gear Ratio scalars. If the calculated ratio is outside this range Cruise Control is disabled.

This appears to be the root cause of Cruise Control not functioning on manuals when transfer case ratio swap and tyre sizes are changed by a significant amount.

Fortunately it’s pretty straightforward to determine the value required using the formula:

$$\frac{RoadSpeed \times 1000}{RPM} = gearRatio$$

Verification of formula

To validate the scalar values we can estimate the road speed using the RAVE specifications for top gear, high range in a D2 Td5 Manual.

First calculate the rolling circumference for a 235/70 16 stock wheel.

Section Height: $$235 \times .70 = 164.5mm$$

Rim diameter: $$16 \times 25.4 = 406.5mm$$

Rolling circumference: $$164.5 \times 2 + 406.5 \times \pi = 2310mm = 2.310m$$

Then calculate the speed at 2000rpm.

Speed from gear and rpm: $$\frac{RPM}{(GearRatio \times TransferRatio \times FinalRatio)}\times RollingCirc\times \frac{60}{1000} = speed kph$$

Discovery 2 Td5 Manual, stock top gear: $$\frac{2000}{0.770 \times 1.211 \times 3.538} \times 2.310 \times 0.06 = 84.02kph$$

Based on the estimated road speed of 84kph at 2000rpm, we can now calculate the kph/rpm value.

Gear ratio kph/rpm: $$\frac{84.02 \times 1000}{2000} = 42.01$$

The scalar value used in the stock map for 5th gear is 40.50.

So there seems to be variation between scalar and calculated ratio in each gear:

Gear Calc GR Stock GR Error
1st 8.76 8.00 +9.50%
2nd 15.17 14.10 +7.58%
3rd 23.16 22.00 +5.27%
4th 32.35 30.60 +5.72%
5th 42.01 40.50 +3.70%

I'm not entirely sure of the reason for this discrepancy but keep in mind that the gear ratio has a +/-12% tolerance.

I personally wouldn't calculate these values from ratios and tyre dimensions for real world use. The easiest way to find the correct ratio will be to make a note of RPM and road speed in the gears where you use cruise control.

Ratio0 is reverse, Ratio5 is 5th gear.

Patchers

The MAF and AAP patchers are included in the release.

The AAP patcher has been updated to avoid the previous situation where a stock EU3 map would show as "patched". In this version the standard map always displays as "unpatched".
So for 10P maps the 3 wire AAP setting is "unpatched", and on 15P maps the 4 wire AAP setting is "unpatched".

Applying patches is not entirely obvious:

  • click the "Apply Patch" button
  • click the "Apply" button at the bottom the dialog
  • save the map file from the file menu or save icon

The patches contain the original base data so map can be restored to original settings.

15P Limiters

There are two new limiters for the EU3/15P maps.

I suspect one or both of these are causing problems for most people running big tunes and/or high boost.
These will need posts to explain what the limiters are doing and what you need to consider before touching them. I'll try to get these done over the coming couple of weeks.

Other stuff

Because this release is built on some significant changes - moving from MATLAB and CSV, to Python and SQLite 3 - there is potential for errors to have crept in. I've spent a fair bit of time trying to ensure there is nothing obvious.

However after working on the code and data for the last week I'm sure I have missed obvious things.

Please let me know if you find any issues and I'll rectify for the next update.

Pages