Td5 Tuning

Using the USBBDM as a remap interface

Posted: 
Saturday, September 2, 2017 - 13:00

The Nanocom .map and .tun formats is pretty much a standard for distributing remaps and loading different stock maps.

It should be fairly obvious that this was not just accidental. The support for Nanocom ID and VIN locked files plus respecting the NO READ attribute which prevents tunes being read back out of an ECU are clearly aimed at establishing the Nanocom as an acceptable remap delivery tool.

And this probably the key weakness of the Nanocom as a programmer - it is designed for uploading completed tunes to a customers vehicle.

This has become glaringly obvious over the past week when I've been trying to test mods to the Wastegate Modulator control maps. The testing requires repeated increment and test cycles, and this is where the Nanocom shows just how unsuited it is to the task.

As many are aware the ECU uses a variant map and fuel map pair. The variant is basically the program code and the fuel map is the configuration data. The variant code is only very, very rarely modified, and in most cases only the fuel map is touched. The XDF's only modify the fuel map.

The variant map is approximately 100Kb and the fuel map is 16Kb. The Nanocom erases and programs both maps each and every time it does a .map upload. That little bit at the end of the upload that takes 10-20 seconds to complete is the fuel map being programmed.

Each time you program with the Nanocom it goes something like this..

  • Copy tune to SDCard
  • Place SDCard in Nanocom
  • Connect Nanocom to OBD port
  • Wait for Nanocom to boot
  • Navigate to Td5 Map module
  • Select .map
  • Wait for Nanocom to verify checksum and "protection"
  • Turn on ignition, then push button on Nanocom
  • Turn ignition off, then push button on Nanocom
  • Wait 15 seconds
  • Turn ignition on, then push button on Nanocom
  • Wait while Nanocom erases then programs variant and fuel maps ( approximately 2 minutes)
  • Cycle ignition

If all goes well - and it often doesn't - that process takes at least 4 - 5 minutes.

And yesterday when I was trying to upload a small mod and the Nanocom repeatedly failed at the "protection" check I decided that it was time to bite the bullet.

Enter the BDM

I've had a USBBDM interface for a few years, primarily to recover ECU's bricked by failed Nanocom uploads, but I've been conscious of the fact that tools like WinOLS offer BDM programming interfaces for remapping. BDM is typically used in bench programming setups, however I've added a 10-pin header to my ECU to make debricking a bit more straight forward.

So the simple solution was to connect a short ribbon cable with IDC sockets to the BDM port on the ECU and then feed the cable out under the edge of the lid. It's not perfect as the cable can be damaged by the lid, so I'll probably file a shallow notch in the case so there is less pressure on the wires.

USBBDM

The setup works reasonably well as the BDM port is near the upper edge of the case when installed in a D2.
Ideally I need a longer USB cable so I can reprogram from the drivers seat with bonnet down but this was basically a quick test to see how practical the idea was, so I popped the bonnet to do the reprogramming.

And the result was: very practical

Program Done

There is currently a little to much "are you really sure" checking in the recovery scripts which makes things a little slower than necessary. Once you have the USBBDM interface hooked up it's pretty quick. It takes less than a minute to select and program a new fuel map. The actual programming is done in a couple of seconds and there is no worry about the upload freezing.

A month later...

I first started writing this post about a month ago, and I haven't even considered using the Nanocom to upload a tune since then. The main fiddle at the moment is popping the bonnet to plug in the USBBDM but even with this the fact that you know the tune will program first time makes it a winner. Normally I wouldn't load a map if I was away from home, but loading using BDM is so reliable I don't even hesitate to make adjustments and upload the modded map.

The scripts

Information about the script package can be found in this post. I've made a "remap" version of the recovery scripts that prompts for a .bin fuel map as soon as it runs and only asks once if you want to program.

Working with fuel maps

There are a few minor changes that need to be made to adapt the XDF's for use with fuel map .bins. I'd recommend making a copy of the original.

Open up the XDF header information. You'll see something that looks like this. XDF Header

Change the Bin Size (Hex) to 3FFF and the Base Offset (Hex) to 0, then click apply. Modified XDF Header

Click the checksums tab, and delete the map checksum. That is Nanocom specific and not required.

The Mysterious MAF Patch

Posted: 
Thursday, August 31, 2017 - 17:15

From the earliest versions the donor XDF’s have included an undocumented patch which is simply named MAF Patch.

A few people have asked what it does, and my response always includes something along the lines of “I really should document that!”.
So here it is finally - the documentation...

What it does: short version

The MAF Patch alters the MAF Calibration curve and ai_analg_multip: MAF parameters to extend the usable range of the stock MAF sensor.
With this patch the stock can read out to around 850kg/hr before going out of range.

What it does: tl;dr version

As you’ll be aware from the MAP recalibration tech note the ECU uses a resistor divider to reduce the voltage entering the Analog Digital Convertor (ADC) to 90.7046% of the original value. This is primarly to protect the ADC inputs from over voltage damage.

The ADC uses a reference voltage of 5000mV, so can convert an analog voltage in the range of 0 - 5000mV into a digital value between 0 - 1023. These digital values are known as ADC codes.

A voltage greater than 5000mV will result in an ADC output of 1023.

The following plot shows the relationship between sensor output in mV and ADC codes.

Sensor Voltage to ADC Codes

It should be apparent that the maximum ADC code output of 1023 corresponds to a sensor output of somewhere around 5500mV.

More precisely the maximum sensor output that can be represented without clipping is:

1023 / 0.2046 / 0.907046 or 5512mV

The ADC codes and “magic numbers” are covered in detail in the MAP Recalibration post so I won’t go into detail again here.

The stock map parameters use an ai_analg_multip: MAF of 5388 and ai_analg_divisor: MAF of 1000.
Working backwards from the default MAF limiter voltage of 4950mV we can determine the ADC output in codes

4950 * 1000 / 5388 = 918

And the corresponding sensor output voltage is therefore

918 / 0.2046 / 0.907046 = 4946mV

So the ai_analg_multip: MAF of 5388 reverses the scaling of the hardware and ADC, and the MAF Calibration Curve map is used to determine the Airflow value in kg/hrs.

The obvious thing here is that there is a bit of untapped range available in the ADC convertor. And we know the MAF can output much more than 5000mV.

For the patch I decided to use 5000 as the ai_analg_multip: MAF scalar. So lets assume the same 4950mV limiter and calcuate the ADC Codes:

4950 * 1000 / 5000 = 990

The sensor output that produces 990 ADC codes is

990 / 0.2046 / 0.907046 = 5334mV

You could probably go higher, but I’m keeping it on the safe side. After all range that we are using is quite literally uncharted territory beyond the calibration range of the stock MAF.

The problem now is that the a MAF output of 4950mV now produces

4950mV * (5000/5388) = 4593mV

I resorted to MATLAB’s Curve Fitting Toolbox to come up with a best fit for the stock curve, and then extrapolated the curve out to 5334mV.

Obviously extrapolating a curve in this way comes with no guarantees of accuracy, and the further you move away from the known the more quesitonable the extrapolated value. This is another reason I was reluctant to push to 5500mV with the stock MAF sensor.

Once the curve had been extrapolated the next problem was that retaining the standard column header values made it very difficult to obtain smooth integration of the new maximum flow values.

To solve this problem I used a table optimisation toolbox for MATLAB. The toolbox allows you to load a curve and then specify a required number of columns. It then optimises the breakpoints to minimise the deviation from the orginal curve.

Stock and Patch MAF Curves

The result is of all this was a new MAF curve that reads out to over 850kg/hr, and has a maximum error of +/-1% when compared to the stock MAF curve.

Patch Error

The error plot is slightly misleading - the maximum error is at lower sensor outputs of around 100kg/hr. The larger deviations of 2.5kg/hr occur at flows of 500kg/hr and above, so are in the range of +/-0.5%.

So there you have it.

The MAF patch is basically a take it or leave it affair due to the fact that it’s been optimised to minimise error as far as possible compared with stock.

I’ll look at adding MAF limiter editors in the next revision of the XDF’s which will allow the MAF sensor to saturate at the maximum rather than limiting.

Wastegate Modulator Control

Posted: 
Thursday, August 17, 2017 - 13:15

A couple of months ago I posted on how the Wastegate Modulator operates when energised and de-energised.

That research was necessary because the “common forum wisdom” that the WGM operated to reduce boost seemed to be completely at odds with what the WGM control code appeared to be doing.

To quickly recap, when active the Wastegate Modulator rapidly switches between boost pressure and turbo intake pressure to regulate the pressure at the wastegate actuator. When the Modulator is inactive boost pressure flows directly to the wastegate actuator.

The effect of the switching between intake and boost pressures at 16 times per seconds is to create a blended pressure which related to current value of the two pressures and to the amount of PWM applied. Because the intake is always pressure is always lower than boost pressure (assuming the Turbo is producing boost) the WGM can only reduce pressure at the Wastegate Actuator when there is a PWM signal.

With no PWM modulation applied to the modulator boost pressure flows directly to the wastegate actuator meaning the wastegate behaves as it would if the modulator was not present.

This is absolutely fundamental to the way the WGM maps work, so
if you have any doubts I’d recommend (re)reading the post on WGM operation, and if necessary doing some testing to verify this is correct for yourself.

The WGM Controller

I’ve had a bit of difficulty trying to decide how best to write up the WGM. The software contains support for a full blown PID controller, however the WGM implementation uses only Integral component. The Proportional and Derivative components are both disabled.

For the moment I’ve decided to stick to what is actually used in the standard implementation, but keep there is a huge amount of hidden flexibility and the full PID setup should prove useful for full-blown Boost Controller applications down the track.

As a note of explanation, the parameter names I'm using below come from a list of Td5 System Constants from offical Land Rover engineering docs that were posted to a Spanish forum. While they are not natural language they have the distinct advantage of accurately defining the purpose of the value.

So let’s look at the details.

WGM Enable and Disable

The first thing to note is that the Wastegate Modulator is not “always on”. The control code is only enabled when the engine is operating above specific RPM and IQ thresholds.

The enable thresholds are set by two system constants:
- tb_fuel_mass_enbl = 24.00 mg/fire
- tb_engine_speed_enbl = 1900 rpm

Once the fuel mass (IQ) requested is greater than 24mg/fire and engine speed is greater than 1900rpm the Wastegate Modulator controller is switched on. The controller remain in the “on” state until either engine speed or IQ falls below the disable threshold.

The two system constants for the disable threshold are:
- tb_fuel_mass_disd = 20.00 mg/fire
- tb_engine_speed_disd = 1750 rpm

This state diagram illustrates what is occuring. The controller remains in either an on or off state until the conditions required to switch to the other state are met.

WGM Enable-Disable State Machine

These on/off thresholds are confirmed by data logging. I've filtered a log with just under 1000 data points to extract the lines that have a Wastegate Modulator Duty greater than zero, then plotted RPM vs IQ. The colour bar shows the WGM Duty %.

RPM vs IQ, WGM greater than zero

This shows quite clearly the WGM is only active above the operational thresholds described above.

Narrowing the focus to the “off -> on” transition, I’ve selected rows where a 0% WGM Duty is followed by a non-0 WGM duty %.

Off to On Transition

You can see the engine speed values are mainly +/-100 rpm around 1900rpm, and the IQ values appear to be generally above 24mg/fire.

Looking at the “on -> off” transition, I’ve selected all non-0 WGM Duty % values preceeding a 0% WGM Duty.

On to Off Transition

While the engine speed values are still above 1850rpm, the IQ values between 20 and 24 mg/fire are apparent.

To further illustrate the off -> on transition ploting the log data in more familiar way shows the behaviour of Wastegate Modulator duty, RPM and IQ. In both cases IQ is around 33mg/fire.

The first plot shows behaviour at 1690rpm with IQ of 33mg/fire, and WGM duty at 0%.
RPM = 1690

The second data point 290ms later shows engine speed of 1970rpm, with WGM duty at 31%.
RPM = 1970

Current Boost and Target Boost

These two parameters are calculated each cycle regardless of whether they are used in WGM operation.

Current Boost is a calculated value equal to Manifold Absolute Pressure (MAP) - Ambient Absolute Pressure (AAP).

Target Boost is a value looked up using the final table in all Td5 engine fuel maps.

Target Boost

The X-axis value is IQ (or fuel mass) mg/fire and the Y axis is RPM and the Z-value is Target Boost in kPa.

The Target Boost table is identical across Euro, ROW, Japanese and Korean tunes, on Eu2 and Eu3 motors and Manual and Auto D2’s despite the variation in driver demand tables, and smoke and torque limiters which suggests that this table is not precisely controlling the boost to match fuelling.

I’ve highlighted the region where engine speed is above 1750 and the IQ requested is above 20 mg/fire in a stock D2 Auto driver demand map to illustrate the region where the Wastegate Modulator is operating in an unmodified map.

EU2 Auto Driver Demand

It should be apparent that when you start increasing the duration in the driver demand, smoke and torque limiters that the values returned from the Target Boost table will come from further to the right - in other words the target boost will tend to be higher than for stock driver demand.

Wastegate Modulator Duty Ratio Bias

This map is has Target Boost as the X-axis and RPM as the Y-axis. Z-Axis values are WGM Duty Ratio.

WGM Duty Ratio Bias

This is the underlying amount of WGM Duty Ratio for a given target boost level. Because the ECU map lookup “clips” axis values to maximum or minimum, anything below 100kPa uses the left column, and anything above 120kPa uses the right hand column.
Adapation to higher boost levels will require modification of the header values.

WGM Integral Gain

The Integral Gain map has RPM as the X-axis, Boost Error as the Y-axis, and Integral Gain as the Z-axis.
This is used in the ECU when calculating the Integral (summed value over time) of the error.
WGM Integral Gain

WGM Proportional Amnt

Not Used in factory maps.
X-axis is Boost Error, Y-axis is WGM Duty Ratio.
WGM Proportional Amnt

Boost Error

Boost Error is calculated as the difference between the current boost and the target boost:

Boost Error =  Current Boost - Target Boost  

Note that if current boost is below target boost the error is negative, and positive if current boost is higher than target boost.

Controller code

The integral map described above should give you a big clue as to what we are dealing with here - a Proportional-Integral-Derivative Controller (PID). This is a type of feedback controller that is widely used to regulate “plant” to a steady state.

Fortunately Land Rover has disabled most of the Proportional and Derivative code so what is left is far simpler. However, the fact all the PID controller is still in place does open up the possibility of some fairly advanced boost control implementations in future. At this point I’ll stick to what is actually used.

Integral Calculation

The WGM controller has a “dead band” of +/- 2kPa which is set by the tb_intgl_enbl. Boost Error values of less than this amount are ignored.

If the Boost Error is greater that +/-2kPa, it is limited to the value set by tb_max_err_intgl which is given as 10kPa, but looks more like it should be 1kPa from my reading of the code. Regardless the constant used has a raw value of 100. Given that the raw boost error figures the constant is applied to are kPa * 100, this has the effect of limiting the max error amount to +/- 1 kPa.

The limited Boost Error is then multiplied by the Integral Gain and then divided by 1000 (raw value) to give the required adjustment to WGM Duty Ratio. You’ll note the Integral Gain table values are all negative, and as previously noted current boost values below target boost result in negative boost error values.

100 * -50 / 1000 = -5   
-100 * -200 / 1000 = 20  

This plot of logged engine data shows how the Boost Error and Integral behave. As Boost Error becomes postive the Integral amount decreases, and vice versa. The other point of note is that the values are not calulated when the WGM is not currently enabled.

Boost Err and Integral

The adjustment amount is then added to the accumlated value (Integral) of the Wastegate Duty Ratio adjustment. The maximum adjustment to Duty Ratio is +/-0.2% each time the code is executed.

The WGM controller code runs at 10ms intervals which is set by the scalar tb_intgl_deriv_rate. At this rate the controller can adjust the Duty Ratio by up to 20% in 1 second.

The final step in calculating the Integral is limting checking against tb_clamp_intgl_hi which is set at 10%, and tb_clamp_intgl_lo which is set at -30%.

Total WGM Duty Ratio

The final step is to sum the component values of the PID controller. Because the Proportional and Deriviative amounts are set to zero in this implementaiton this is becomes effectively

 Duty Ratio % = Bias + Integral

You can see this in practise in this plot of log data.
The Duty Ratio Bias is 25.64%, and the Integral is -1.54% and the total WGM Duty Ratio is 24.1%.

This amount is then checked against tb_max_duty_ratio which is set at 82%, and tb_min_duty_ratio set at 16%.

WGM Module Disable

The WGM module can be disabled by setting the scalar which controls the PWM frequency tb_turbo_pwm_freq to 0. Defenders have a fully configured WGM which only requires setting this scalar to 16 to enable.

Overboost Fuel Cut Map

Posted: 
Wednesday, August 2, 2017 - 12:30

The donor XDF's identify a map that limits fuelling when overboost occurs, which I've named "Overboost Fuel Cut".
That naming seems to have created a bit of confusion as I've had a few people email asking if they should increase this map to match the torque limiter.

Where the confusion arises comes from common belief that the kangaroo hopping or jerking that occurs when the wastegate fails to operate is a fuel cut caused by an overboost condition. What is actually occurring is quite different.

Back to the ADC

I've posted previously about the signal flow from MAP sensor through the ECU Hardware to the Analog Digital Conversion module.

This is roughly:

  • Sensor converts pressure to voltage
  • Resistor divider drops voltage by approx 10%
  • ADC converts voltage to a value between 0-1023
  • The value is checked against ADC Max and Min

If the value is above ADC Max, a logged high fault is set, and if below ADC Min a logged low fault is set, and the sensor default value is used.

And this is what occurs when the wastegate fails to open. The pressure quickly increases to a value higher than ADC Max, and the sensor default is set.
Limit checking happens at the first stage of processing after AD conversion, and well before any fuelling calculations. While this might appear to be a fuel cut that is simply a side effect of the dramatic drop in calculated airmass.

The real overboost fuel cut

Overboost Fuel Cut Map is used specifically when the current boost exceeds the boost limit value.
The current boost value is calculated as the difference between Manifold Absolute Pressure (MAP) and Ambient Absolute Pressure (AAP). This is obviously influenced by the pressure drop across the air filter and airbox.

Say for example the reading are 240kpa MAP and 100kpa AAP, in this case boost is 140kpa.
However if there is a 3kpa drop caused by the airfilter, that becomes 240kpa MAP and 97kpa AAP which gives 143kpa boost.

The stock ADC Max limit for the MAP is the equivalent of about 242kpa and stock Boost Limit is set at 142kpa. Due to the drop in AAP at high boost you'll generally reach the Boost Limit at least 2-3kpa before the ADC Max limit.

Once boost exceeds the Boost Limit, the ECU limits the amount of fuel injected using the Overboost Fuel Cut map. This limiting remains in place until the current boost drops below the level set by the Boost Limit Recovery parameter.

A few thoughts

My take on this map is that it is used by the ECU to help control boost levels after overboost is detected, and prior to the MAP value exceeding the maximum limit. With stock values this is a small window of perhaps 3kpa // 0.4psi. It is basically a last ditch effort by the ECU to control overboost, and I personally don't' see any legitimate reason to mod this map.

The best approach is to set boost limit and boost limit recovery values at the maximum value you expect to run.
If this is higher than 150kpa/1.5bar boost you will need to replace the MAP sensor with a wider range unit.
Then adjust the ADC Max value to suit - some thing like 250kpa if you have set the boost limit to 150kpa.
Working in this way you will only hit the Overboost Fuel Cut when the boost reading goes above your maximum expected value.

Fuel Density Compensation maps

Posted: 
Thursday, April 27, 2017 - 09:45

The main of the function of the Fuel Temperature Sensor is to correct for the decrease in fuel density as fuel temperature increases.

RAVE states this quite clearly so no real surprises....

The FT sensor is located at the rear of the engine in the fuel rail with the tip of the sensor inserted at least 10 mm into the fuel flow. This allows the sensor to respond correctly to changes in fuel density in relation to fuel temperature.

This function is handled by two maps:

Fuel Density Lower:

  • EU2 - Map 62
  • EU3 - Map 96

Fuel Density Upper:

  • EU2 - Map 63
  • EU3 - Map 97

These maps have Inject Quantity Request as the X axis, and Fuel Temperature as the Y axis, and output density corrected Inject Quantity.
The lower map is the density corrected IQ at 1000rpm while the upper map is the density corrected IQ at 4200rpm.
For engine speeds between these two points the density corrected IQ is interpolated between the upper and lower maps.

The Density Correction is effectively a four dimensional map - with IQ request, Fuel Temp and RPM as inputs, and the density corrected IQ as output.

The Fuel Density Compensation maps are located after the group of maps consisting of Driver Demand, Smoke Limiter, Torque Limiter, and immediately prior to the Duration Maps. Corrections applied here have a direct effect on the final inject duration.

Because the these maps act to modify the IQ request they have sometimes been identified as a performance enhancing map.
I'd strongly advise against taking this approach as changes to the lower map, and lower parts of the upper map will destroy the temperature -> density relationship and modify the relationship between the duration maps and DD, SL and TL.

Limiter function

A less obvious function of the Fuel Density maps is that they act as limiter on Inject Quantity.
This limiting function is an effect of the last column of the upper map which sets a maximum IQ at 4200rpm of 60mg/fire (stroke). While the Fuel Density maps will output up to 100mg at 1000rpm, the effect of interpolation between the upper and lower maps means the maximum amount injected for 100mg request reduces as rpm increases.

The following plots show the interpolated value returned from the stock Fuel Density Compensation maps at various engine speeds.

1800rpm 75degrees

2600rpm 75degrees

3200rpm 75degrees

4000rpm 75degrees

The "corner" at 60mg is quite obvious, and while it would have minor impact on a Stg 1 tune, once you start playing with 80-90mg/fire (or stroke) it becomes a major problem.

How to solve

Fortunately this is reasonably easy to rectify by changing the upper map. The lower map does not need any alteration.

The simplest solution is to alter the final header value from 6000 to 10000.
Then either use 10000 for each of the cell values in that column.
Alternatively use extrapolated values:
- 9769
- 9977
- 10057

A slightly safer approach is to set the header to your maximum IQ value,
and then interpolate the values between the current last column and 10000.

Current donor XDF's have been updated to include these maps. These are now being distributed in an archive of XDF's for all 49 variant-fuel map pairs listed in Nanocom Map Wizard.

Tech Note No.1: MAP sensor recalibration and replacement

Posted: 
Monday, March 13, 2017 - 08:00

Note link to calculator spreadsheet added at bottom of post

Background

The 1.42 bar boost limitation of the stock Land Rover Td5 engine management system has been a long standing issue when increasing boost levels as a performance upgrade.

The standard solution has been to insert a boost box or some other type of "cheater circuit" in line with the MAP sensor to lower the sensor voltage to provide the ECU with false reading of the boost levels.

In the course of disassembling the ECU firmware it became apparent that the sensor parameters could altered with minor adjustments to the settings in the fuel map to accomodate alternative MAP sensors. The advantage to this approach is that the ECU receives a true reading of the boost pressure rather than a falsified reading that effects pressure readings across the range.

This modification was originally tested on a range of Td5 powered vehicles by members of the Td5Tuning.info forum in January and February 2014.

Under the hood

In order to understand why and how this modification works, it is useful to understand the signal flow from the MAP sensor through the ECU hardware and the processing the ECU firmware applies to the converted analog voltage.

Sensor Signal Flow

The starting point of the conversion process from manifold pressure to ECU representation of the pressure is MAP/IAT sensor which is mounted on the TD5 inlet manifold. The voltage the MAP sensor outputs in response to a given manifold pressure is determined by the characteristics of the sensor used. The relationship between pressure and output voltage is often described as the transfer function of the sensor.

Signal Flow

Once the MAP sensor voltage enters the ECU housing it passes through a voltage divider formed by two resistors. The effect of the voltage divider is to reduce the incoming MAP sensor voltage to 90.7% of the original value.

The reduced MAP sensor voltage is then processed by a 10 bit Analog to Digital Convertor (ADC). The 10 bit range of the ADC allows the sensor voltage to be converted to one of 1024 ( 2^10) values. The conversion process is referenced to a 5 volt supply within the ECU, meaning the maximum ADC value of 1023 represents 5000mV and the minimum ADC value of 0 represents 0mV.

At this point the signal flow moves from hardware to pure software. The ECU code first checks that the raw value retrieved from the ADC is within the preset range. Both the minimum and maximum values are related to characteristics of the sensor being used and the range of sensor voltages that are considered within normal range. The maximum value set for the MAP in stock tunes is the equivalent of a pressure reading of 2.42 bar, which will familiar as the point the ECU limits with over boost. Any value that lies outside the initial check range causes an “out of range” fault to be logged.

In the next stage of processing the range checked ADC value is scaled so the converted value is returned to the required units. In the case of the MAP sensor this is millibar * 100. The scaling and offset values reverse the transformations applied by the ADC conversion, voltage divider and the sensor transfer curve to give the pressure value the sensor measured.

Reverse engineering from the stock MAP sensor

At this point we have a basic outline of how the MAP sensor voltage progresses to a digital representation of the pressure, and where intervention is required if we wish to replace a MAP sensor.

To illustrate the process of configuring the ECU values for a specific sensor the following section works from first principles using the stock MAP sensor.

While the explanation of the process may seem long winded and overly detailed the aim here is to explore the underlying assumptions, so that the same procedure can be applied to other sensors.

Hardware

The sensor datasheet

The starting point is to acquire the specification of the MAP sensor as this provides the key information required to accurately configure the ECU. The stock MAP sensor for the Td5 is Bosch part 0 281 002 205, and the key parameters from the data sheet are shown below.

Sensor Data

Note that the data table pressure range refers to two points - p1 and p2 The information about these points is given in the plot of the sensor Characteristic Curve.

Characteristic Curve

From the spec sheet we can determine that that this sensor has an output of 400mV at 20kPa and 4650mV at 250 kPa.

Sensor Transfer Curve

Calculating the transfer curve is fairly simple and uses only basic high school algebra.
First we calculate the slope of the sensor curve from the two points given by the datasheet.

p1(mV) = 400
p1(kPa) = 20
p2(mV) = 4650
p2(kPa) = 250

The slope of the sensor curve (m) is the change in voltage divided by the change in pressure.

$ m = \frac{p2(mV) - p1(mV)}{p2(kPa) - p1(kPa)} $

Substituting in the stock MAP sensor values

$$ m = \frac{4650- 400}{250 - 20} = \frac{4250}{230} = 18.478260869565217 mV/kPa $$

The slope m tells us that for 1 kPa change in manifold pressure the output of the sensor increases by 18.4783 mV.

The second piece of information required is the voltage the sensor outputs when the pressure is 0 kPa. This is the sensor offset.

 offset = p1(mV) - (m * p1(kPa)
= 400 - (18.4783 * 20)
= 400 - 369.566
= 30.434 mV 

The slope (m = 18.4783 mV/kPa) and offset (30.434 mV) provide us with sufficient information about the MAP to configure the ECU.

ECU Hardware

As discussed in the Sensor Signal Flow section the output of the MAP sensor passes through two fixed stages of processing - a voltage divider and the Analog Digital Convertor.

Voltage divider

The Td5 ECU uses a resistor divider arrangement on sensor inputs to provide a form of over voltage protection for the Analog to Voltage Convertor inputs. The divider consists of two resistors:

resistor1 = 121000 ohm
resistor2 = 12400 ohm

$ voltDivider = \frac{121000}{ 121000 + 12400} = 0.9070 $

The divider therefore reduces the sensor voltage to 90.7% of the original value. This means that a sensor output of 5000mV is reduced to 4535mV at the input of the ADC.

ADC Conversion

The 10 bit ADC divides the range of voltages between ground/0mV and the sensor supply voltage/5000mV into 1024 discrete steps.
Dividing the total number of steps by the voltage range gives the step size of 1 millivolt of input voltage. The output of the ADC is a value between 0 and 1023 that represents the measured voltage.

Note that there is debate as to whether n or n-1 steps is correct. Comparing both methods to the ECU curves indicates that n-1 gives the closest match when compared with stock values.

The voltage of each ADC step (or ADC code) is calculated as:

$ step/mV = 1023/5000 = 0.2046 $

Note that it requires a change of at least 4.8876 mV to cause a change of 1 ADC code.

Putting together the hardware scaling factors

The combined effect of the voltage divisor and ADC allows us to calculate the value in "adc codes" the ADC will output for a given sensor voltage at the ECU connector.

 hwScale = ADCstep/mV * voltDivider
 hwScale = 0.2046 * 0.9070 = 0.18557

Using this hardware scaling factor we can calculate the ADC codes produced by a voltage at the ECU MAP input.
For example if we have 4650mV input...

$ adc codes = 4650 * 0.18557 = 862.9 $

This can be extended to calculate the ADC output for a given pressure.

Using 242kPa as an example...

pressure = 242kPa;
adcCodes = ((pressure * sensor slope ) + sensor offset) * hwScale
adcCodes = ((242 * 18.4783) + 30.434) * 0.18557 $  
adcCodes = 4502.18  *  0.18557= 835.47 $

As another illustration lets use the sensor maximum of 250kPa...

pressure = 250kPa;
adcCodes = ((pressure * sensor slope ) + sensor offset) * hwScale
adcCodes = ((250 * 18.4783) + 30.434) * 0.18557
adcCodes = 4650  * 0.18557 = 862.9

Error handling

At this point in the process the ECU does error checking against minimum and maximum values defined for the specific sensor input. These are the values that are available as scalar editors (ai_limit_min : MAP and ai_limit_max : MAP) in my "donor-ware" Tuner Pro .XDF's.

If the sensor value in ADC codes is below the minimum the ECU logs "below minimum" and "out of range" faults, if the value is above the maximum, "above maximum" and "out of range" faults are logged.

These are the faults the Nanocom reports as "logged low" (1-2,x), "logged high"(3-4,x) and "current" (5-6,x). "Current" simply indicates that there is either a "logged low" or "logged high" fault set.

Using the stock MAP ADC limit check values as example we can work backwards to find the voltages and pressures that have been set.

min = 93
max = 836

By reversing the transforms performed by the ADC and voltage divisor we can reconstruct the input voltage.

sensorV = ( limits /  mvStepADC ) / vDivider
sensorVmin = ( 93 /  0.2046 ) / 0.9070 =  501
sensorVmax = (836 / 0.2046) / 0.9070 = 4505

So it appears the limits are set to a minimum of 500mV and a maximum of 4500mV.

To find the pressure these voltages correspond to we divide the voltage minus the offset by the mV/kPa value m

$ pressureLimits = (sensor voltage - sensor offset) / m $
$ pressureMin = (501 - 30.434) / 18.4783 = 25.46kPa $
$ pressureMax = (4505 - 30.434) / 18.4783 = 242.15 kPa $

25kPa is well below anything you'd encounter while driving on the surface of this planet but higher than the minimum sensor hardware limit. 242kPa matches the well known stock boost limit.

When recalibrating for a new MAP sensor, or using the stock sensor at higher boost it is essential that these limit values are reset to match the new boost levels and sensor curve.

Software: From ADC codes to pressure readings

Working backwards from ADC codes to pressure is a good warmup for the remaining steps of calculating new multiplier, divisor and offset parameters which makes possible substitution of alternative sensors.

In effect we are reversing the transformations done by the sensor curve m, sensor offset, the voltage divisor and the steps/mV of the ADC process in the same way the limiter pressures were checked.

The value used internally by the ECU for MAP is kPa*100. Additionally the divisor in the stock configuration is set to 1000. This is done due to the integer math used in processing - the multiplier is x1000 to give three decimal places of additional precision, and after the multiplication is completed the result is divided by 1000 to the required two places. This means the multiplier should be multipled by 100000 to bring it to correct units for use in a engine map.

$ multiplier = (1/(m * hwScale ))* 100000 $
$ multiplier = (1/(18.4783 * 0.18557 ))* 100000 $
$ multiplier = (1 / 3.429018) * 100000 = 0.2916287 * 100000 $
$ multiplier = 29163 $

The stock value for this parameter is 29163, so the calculated value is a match for the factory calculations.

Stock divisor parameter is 1000, and reverses the three places precision noted above.

The final parameter is the offset which is the sensor offset calculated in the intial steps converted to ADC codes then scaled by the multiplier and divisor.

$$ offset = \frac{sensor offset * hwScale * multiplier}{divisor} $$

$$ offset = \frac{30.434 * 0.18557 * 29163} {1000} = 164.7 $$

Rounding up to the next highest integer value gives 165.

As noted earlier the offset indicates the voltage the sensor would output at 0kPa pressure. This means that to correct so the sensor curve so the output is 0 mV at 0 kPa you need to subtract the offset if it is positive and add if it is negative.

The ECU math uses addition for this calculation, so if the offset is positive we need to swap the sign to make the number negative. And if the offset is negative the number added needs to be signed swapped to make it a positive number.

So in this case the ECU offset parameter should be -165 to remove the positive offset of 165.

In summary, the values calculated from the datasheet information match the stock parameters:

MAP ADC Maximum: 836  
MAP Multiplier: 29163  
MAP Divisior: 1000  
MAP Offset: -165  

Current XDF's have a changed naming scheme for scalars which reflects LR documentation.

ai_limit_max : MAP  = 836  
ai_anlg_multip : MAP = 29163  
ai_anlg_divisor : MAP = 1000  
ai_anlg_divisor : MAP = -165  

1.5 Bar MAP Recalibration

This is a super simple mod to do!

  • Change the MAP ADC Max (ai_limit_max : MAP) value from 836 to 863, which raises maximum input to 250kPa.
  • Change the Boost Limit (tb_over_pres_enbl) from 14200 to 15000.
  • Change the Boost Limiter Recovery (tb_over_pres_disbl) value to 14800.

This mod uses the stock MAP sensor and does not require any hardware changes.
It's a good choice if you are running stock intercooler and turbo.

In the Tuner Pro .XDF's I give as a "thank you" to donors these parameters can be edited using a simple graphical interface. XDF MAP editing

The parameters can be located by searching for the stock values using a hex editor of course, so it's your choice.

MAP Setting Calculator

There is now a MAP Parameter calculator on Google Spreadsheets.
It's read only so you'll need to download as an XLSX or ODS spreadsheet (or copy to your Google account) from the File menu.

The spreadsheet contains the values required for the VAG 3 Bar and Bosch 3.5 Bar (PN# 0 281 002 244) sensors.
- Copy the values you need across to the area highlighted in yellow or enter for the sensor you want to use.
- Set the boost limit required (pressure from Point 2 or lower *100). Recovery is calculated as 2kPa below this.
- If the calculated multiplier is greater than 32767 you'll need to lower the divisor. Try 750 as a starter.

MAP calculator on Google Spreadsheet

Axis Extends

Posted: 
Wednesday, December 28, 2016 - 09:00

Axis Extending the Smoke Limit map is the secret weapon of the new school remap.

When a value being looked up exceeds the maximum value for the axis the ECU uses the last value of the axis. In the case of an EU2 Auto the Airmass axis has a maximum value of 850mg/stroke. Any Airmass values above 850mg/stroke use this column to calculate the smoke limit IQ. This has the effect of gently rolling off the maximum AFR as Airmass climbs beyond the header value.

Looking at the stock IQ's of 850mg air, 48mg IQ at 2000rpm we can see this gives a maximum AFR of 17.7 to 1.
As Airmass increases, say to 1200mg/stroke, the same 48mg IQ limit applies giving a maximum AFR of 25:1.
Bumping the Max IQ to 57mg gives a AFR of 14.9:1 at 850mg/stroke, and 21:1 1200mg/stroke.
Due to the restriction of the airmass in the final column it becomes difficult to increase IQ without making the smoke.

The stock maps appear to select a final column value near the Airmass required at peak torque so the roll off in AFR occurs after this point.
Peak torque seems to occur around 2000-2500rpm so worth checking what Airmass you are making at full throttle at this point and then select the column header based on the airmass at peak torque.

As an example of how this works I've taken the last column of an EU2 Auto smoke map and calculated the existing AFR.
This is simply:

AFR = ( column header value /10) / (table value / 100)

The new values are calculated from the AFR and replacement column header value.

IQ = (New column header / AFR ) * 10

RPM 8500 9500 AFR
650 4000 4000 21.25 / 23.75
700 3000 3353 28.33
1000 3200 3576 26.56
1200 3600 4023 23.61
1500 4800 5365 17.71
1800 4800 5365 17.71
2000 4800 5365 17.71
2700 4800 5365 17.71
3000 4800 5365 17.71
3500 4400 4918 19.32
4200 4400 4918 19.32
4900 3600 4024 23.61

The main tables that need this kind of treatment are the Smoke maps as the higher airmass values in the axis headers allow increased fuel inject amounts while avoiding setting AFR to a level that results in excessive smoke.

Injector Duration Maps

Posted: 
Tuesday, December 20, 2016 - 08:15

The "Old School" mod of choice..

Modifications to the inject duration maps are a key element of "old school" tuning.
The main reason this is done is because the injector open times looked from these maps are not modified - excepting for adjustments for injector performance codes - before being sent to the injector control code. If a tuner modifies these maps there are no problems with "unknown" limiters restricting the requested IQ, and there is no need to account for map variations between Defender, D2 Manual or D2 Auto. It makes life very simple.

The inject duration maps come in two variations - one for EU2 motors with lower pressure/larger fuel droplet injectors and one for EU3 motors with high pressure/smaller fuel droplet injectors. In other words a ROW Defender 110 and Euro D2 with Auto running the same variation of the motor/injectors have identical inject duration maps. Basically these maps are calibration for the behaviour EU2 and EU3 injectors and how droplet size of the injected fuel effects the burn characteristics, and translate a request for a specific Inject Quantity into the opening time required to deliver the requested amount of fuel.

Duration Map axes

  • X-axis: requested IQ mg/stroke
  • Y-axis: Engine speed (RPM)
  • Z-axis: Injector duration (ms)

Map Identification

EU2

  • Map 64: Inject Duration <= 0 degrees advance
  • Map 65: Inject Duration - 5 degrees advance
  • Map 66: Inject Duration >= 10 degrees advance

EU3

  • Map 98: Inject Duration <= 0 degrees advance
  • Map 99: Inject Duration - 5 degrees advance
  • Map 100: Inject Duration - 10 degrees advance
  • Map 101: Inject Duration >= 25 degrees advance

The Duration maps are selected on the basis of overall Start of Injection timing. The maps define duration at 0, 5, 10 and 25 (EU3 only) degree advance with the ECU interpolating values between the maps for intermediate values.
In effect the 3 or 4 individual maps create a 4 dimensional table with advance as the 4th dimension.

Duration Maps as Calibration

The idea that the duration maps are calibrated to deliver the correct amount of fuel for a specific Inject Quantity request is a fundamental idea to "new school" tuning. The Driver Demand, Smoke Limiter and Torque Limiter IQ values are set on the basis that if the ECU requests 35mg of fuel at 2500rpm, the injectors are going to deliver 35mg. Altering the duration maps as a method of tuning destroys that relationship, in that a request for 35mg at 2500rpm might deliver 40.25mg by increasing the length of time the injector remains open.

I should note that the calibration maps are not an exact linear relationship of IQ request to duration. Duration values are influenced by the behaviour of the combustion chamber, scavenging of exhaust gases and the fuel droplet size so seem to incorporate a degree of fitting to the engine design.

Fortunately with the EU2 motors the duration maps extend well past the normal operating range, so it's relatively straight forward to get away without adjusting the duration maps. The EU3 motors present a far greater challenge as the duration maps are truncated to just above the expected operating maximum of approximately 50-55.00mg/stroke, so need to be modified to extend the range of usable IQs.

The EU3 mods I have in mind are currently untested and will require at very least a Wideband O2 sensor to verify "what you request is what you get". In general terms the idea is that the upper column needs to be altered by extrapolating based on the increment and value increases present in the EU2 maps. Again the idea is not to make broadscale tuning mods, but to allow the injectors to deliver the amount of fuel requested.

Difference between EU2 and EU3 duration maps

Due to the differences in table breakpoints (axis values) it's a bit tricky to compare the EU2 and EU3 duration maps. By interpolating the values from the EU2 duration maps to match those of the EU3 maps it's possible to get a sense of how different the Duration maps actually are.

The following image shows the difference in cell values between the EU3 "0 degree" duration map and the EU2 "0 degree" duration, which has been interpolated to same IQ Request values. The last two columns of EU2 map are repeated to approximate the EU3 final column.

Interpolating the EU2 durations for the 70mg IQ request column gives an indication of where EU3 duration would fall if the final column did not repeat the 50mg IQ request. The EU3 durations are shown in red, and EU2 interpolation in light grey. It's apparent that across most of the map the EU2 duration values are slightly higher. The most obvious exception is the low rpm range.

E2 and EU3 overlaid

The idea is to correct the last column of the EU3 maps to remove the limiting LR has designed in by repeating the 50mg column values. This limiting is not present in the EU2 maps so interpolating based on the curve of the EU2 maps in this region gives us an fair approximation of correct values.

The image below shows the type of correction of the last column required to make the "new school" maps work on EU3 motors.

Corrected EU3 duration

The end goal is to have the injectors deliver fuelling that matches the IQ requested.

Airmass

Posted: 
Sunday, December 4, 2016 - 17:30

Note: There was a bit of doubt about the airmass units on my part. This has now been resolved and milligrams/stroke is the winner.

The first "secret' of the Td5 engine maps is that nothing is quite what it seems at first glance.

If you look at the live data from a Nanocom you are presented with individual sensor readings for MAF and MAP, and the assumption is usually the engine is using MAF for fuelling and the MAP readings for boost. In fact, the reality is a bit more complex.

EU2 motors use data from the MAP and IAT sensors to calculate the airmass in milligrams within each cylinder on each intake stroke (mg/stroke).

For EU3 motors the data from the MAF sensor and the Engine Speed in RPM are used to determine the airmass in milligrams within each cylinder on each intake stroke (mg/stroke). As a backup EU3 motors will fail over to MAP/IAT based calculations if the MAF is outside a specific range but more on this later.

The airmass figures indicates is the mass of air within the cylinder at the end of the intake stroke. This is a critical piece of information for the engine as the amount of fuel injected depends on a combination of the amount of air within the cylinder and the speed of the engine

Unfortunately the Nanocom does not give access to the live data for the Airmass parameter, so the only option is to use the MAP/IAT and MAF/RPM data to calculate the airmass value. Strictly speaking airmass value based on the MAF reading is not calculated - Mass Air Flow is divided down to reflect the amount of air drawn into the cylinder on each intake stroke.

I've posted up the math to calculate airmass to several forums as a method of comparing the MAP and MAF readings for diagnostic but the significance has been elided. I'll run through the calculations again before moving on.

It's important to note that the Nanocom alters the values reported by the ECU to more familiar units. This is fine for some purposes but it does tend to obscure the relationship with engine map parameters. I've added multipliers and conversion from deg C to Kelvin (+ 273.2) as necessary.

Speed-Density: Airmass from MAP and IAT

The calculation used for this conversion is based on the Ideal Gas Law, which can be used to calculate the amount of air present in the cylinder given the volume, absolute pressure and inlet air temperature. This method is commonly known as speed-density, and RAVE makes passing reference to this in the Td5 ECU section of the D2 workshop manual.

The formula for the Ideal Gas Law is PV = nRT

  • P is absolute pressure
  • V is volume in litres
  • n is the amount of substance of a gas - also known molar mass. For air this is approx. 28.97g/mole
  • R is the universal gas constant
  • T is absolute temperature in Kelvin.

When all the parameters are known - as in the case of the ECU - the formula can be rewritten as`

n = PV/RT

Airmass in grams can then be found by multiplying n by n(air).

The Td5 ECU applies this method to calculate Airmass based on the MAP and IAT readings:

airmass = (MAP * Cylinder Volume in cc * Molar Mass air (g/mole)) / (IAT(K) * R)

A point of clarification on the ECU units. The MC68336 processor used in the ECU does not provide hardware support for floating point math, making working with decimal fraction extremely slow. To keep the calculations fast integer math is used, and the number scaled to give the required precision. If accuracy to 1 decimal place is required the number is multiplied by 10. The value for R requires three decimal places accuracy and is multiplied by 1000.

The internal values used by the ECU are:

  • MAP = kPa * 100 (or milliBar * 10)
  • IAT = Kelvin * 10
  • Cyl Volume = 498
  • n(air) = 28980
  • R = 8314

To use this with Nanocom logs I substitute the ECU constants used for the fixed elements, and scale to match the ECU internal values for MAP and IAT. The Nanocom alters the raw log values to a more user friendly format, so this requires converting IAT from Celsius back to Kelvin, and multiplying MAP by 100.

airmass = (MAP * 100 * 498 * 28980) / ((IAT+273.2) * 10 * 8314)
or
airmass = (MAP * 10 * 498 * 28980) / (IAT+273.2) * 8314)

The value is close to the ECU calculated value but suffers from a small amount of time smearing due to the engine conditions changing between sensor requests. As can be seen below the relationship between ECU values and the value calculated from MAP and IAT is pretty close, as shown by the straight 45 degree line.

MAP Airmass

MAF and RPM

The MAF airmass calculation is simplified because the MAF reading is already provides the airmass entering the engine given in kg/Hr. Conversion from kg/hr -> g/min is done by multiplying by 1000 and dividing by 60. The intake stroke of each cylinder occur once every 2 revolutions, so the airmass is divided by 5/2 to determine the amount per cylinder. The ECU code combines these to simplify calculation:

33.333 = (1000 * 2) / 60

The final code used in all variants of the Td5 ECU is:

airmass = (MAF * 33333) / (RPM * 5)

Note that the decimal point of the constant is shifted right three places to retain precision in integer math. The ECU representation of the MAF vale has it's decimal point shifted one place to the right. This is significant when reading the ECU maps as the map values use these fixed point numbers.

To confirm the magnitude of the units, lets apply this to the Nanocom values at a typical idle reading of 60kgHr/ 760rpm.

airmass(g) = 60 * 33.333 / 760 *5 airmass = 0.5263g or 526.3mg

And at 680kg/Hr/ 3500rpm airmass = 1.2952g or 1295.2mg

Referring to 0.5623g airmass feels pretty clumsy, so my preference is to use mg.

Looking at log data the time scatter is far more evident in the MAF airmass from the same log data as the MAP airmass. This is evident in the spread of values above and below a 45 degree line.

MAF Airmass

Bonus diagnostic content.

Because we are calculating two values measuring the same quantity, it is possible to check sensor health by comparing the two readings using a scatter plot. If the sensors are behaving correctly there is a linear relationship between the airmass values. If one of the sensors is misreading you tend to see distinct curvature or complete breakdown of the relationship.

randomness