Fuel Density Compensation maps

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.

Wastegate Modulator: Operation

Thursday, May 4, 2017 - 09:00

This is a bit of background on how the physical waste gate modulator unit operates.

It has only been in the last few weeks that it finally dawned on me that I'd been uncritically accepting the "Active to Limit" theory as correct. While it doesn't seem that important on the surface, it's difficult to make sense of code when the behaviour seems to be at odds with how you believe the hardwares should be operating.

Let's start by looking the Active to Limit Boost theory of operation:

  • power off, the valve is in an open position and boost flows from turbo outlet pipe to the Wastegate Actuator;
  • power on and no PWM signal from the ECU, the valve is in a closed position and boost is prevented from reaching the Wastegate Actuator;
  • power on and PWM signal from the ECU, the valve opens and allows boost to reach the Wastegate Actuator, opening the waste gate.

Active to Limit Boost is the most commonly expressed explanation of how the WGM operates, even if it's not explicitly stated.

This example is from Urban Panzer's excellent www.discovery2.co.uk website...

"trying to the rev the engine over 2500 RPM the waste gate modulator info that Nanocom shows under "read fuelling" went to zero occasionally, so it basically was not controlling turbo charger boost / waste at certain times and was very "hit and miss" at best. That all seems to make sense and description in RAVE would appear to confirm that view. And the Nanocom logs seem to suggest this is what happens in practice.

You can clearly see the WGM active = controlling boost, WGM inactive = boost uncontrolled aspects of the Active to Limit Boost theory.

You'll see this theory of operation informing most forum posts relating to over boosting and WGM diagnosis. It's difficult not to fall into this way of thinking due to it's prevalence - that's my excuse anyway.

So lets look at this in detail...

Hardware first

After a bit of digging I found a couple Pierburg service information sheets for electric switch over valves. These were for parts identical in appearance to the D2's waste gate modulator, but with different part numbers. The test methodology given in the service information required a hand vacuum pump, so I decided put the site donations fund to use and purchased a Mityvac kit. Thanks again to those who have contributed!

The test procedure is fairly straight forward, but the main question I had was whether the valve on the D2 behaved in the same way as described.

WGM testing
WGM diagrams

Testing the modulator on my D2 suggests that the flow through the modulator does match that outlined in the test procedures.

  • power off, boost flows from turbo outlet pipe into port 1 for the modulator and out of port 3 to the waste gate actuator;
  • power on, engine running, and no pwm, boost flows in from turbo outlet pipe into port 1 for the modulator and out of port 3 to the waste gate actuator;

In the course of doing these tests I discovered that while the WGM seemed to be OK, it wasn't passing the Tightness test 1.3.
It was possible to pull down to 0.5 bar vacuum but this dropped to 0 within roughly 10-15 seconds. Similarly, applying pressure to port 1 with port 3 capped resulted in a loss of pressure over 10-15 seconds.

To confirm normal operation I ordered a Pierburg OEM modulator and bench tested.
Out of the box the modulator would hold 0.5bar vacuum on port 2 for 20 minutes with no visible loss of vacuum.
Testing with port 3 capped and 2.0 bar applied to port 1, there was no visible loss of pressure after 20 minutes.

The pin to pin resistance of the new WGM was 29.3ohm, which is within the 28.4ohm +/-1.5ohm specification.

Powered Benchtests

Rather than leave the testing hanging I decided to perform tests 1.1 and 1.2 from the Pierburg service information. This was done with a bench power supply and confirmed the new WGM behaved as described.

For test 1.1 Electrical Function there was distinct click as the solenoid activated, as you'd expect
For test 1.2 Internal Fouling the air flow matched the required values:

  • no power: air flowed from port 1 -> port 3.
  • power: air flowed from port 3 -> port 2.

The thing to note here is that port three is the common outlet. The solenoid is switching between port 1 and port 2.

Next step was to connect the WGM to my tester ECU. Power to the + pin on the WGM was taken from the "master relay" on the interface board. The - pin was connected to A21 on the ECU.

I also hooked up the Bitscope Micro with the scope probe connected to the - pin and the earth clip hooked up to the power supply earth. Add in the Mityvac and Nanocom and it all starts getting a bit messy!

WGM Testing

The main difference between unpowered (ignition off) and powered (ignition on) without a PWM signal is the voltage level.
Unpowered and no PWM gives 0V on both +ve and -ve pins.
Powered and no PWM gives supply voltage on both +ve and -ve pins.

Because there is no voltage differential between +ve and -ve no current flows and no "work" is done.

In the case of power applied to +ve pin and PWM operation, the +ve pin is at supply voltage and -ve pin at earth reference when the PWM completes the earth path. Because there is a voltage differential of around 13.5V and the solenoid coil has resistance around 29ohms the WGM will draw 0.46 amps and dissipated about 6.28 Watts when it is activated.

I can attest that leaving the WGM hooked up to a 12V supply for 5 minutes results in the WGM becoming hot to the touch. oops!

The Bitscope capture below shows the Nanocom Wastegate Modulator Test in action.

Nanocom WGM test

You can see the effect of the PWM completing the earth path resulting in the voltage at the - pin of the WGM dropping by just under 12V.

The pulse width is 100ms or 10Hz, and the duty cycle is roughly 50%, which corresponds with frequency and duty cycle requested by the Nanocom test routine.

I couldn't work out how to capture on video but with the port 3 capped and port 1 pressurised to 2 bar, there was a distinct "puff" as pressure was released through port 2 each time the WGM activated.

As can been seen from the video the WGM is directing pressure to the capped port 3 when it's not receiving a PWM signal.
When PWM is active the pressure in the capped waste gate actuator outlet is released via port 2.
The small drop in pressure seen on the gauge with each activation is due to the small internal volume of the cap I've used.

Revised Theory of Operation

At this point it should be apparent the theory of operation outlined at the start of the post was a bit back-to-front.

Updating the theory to reflect real world behaviour we get:

  • power/ignition off, air pressure flows from port 1 (turbo outlet) -> port 3 (waste gate actuator) - wastegate receives full boost
  • power/ignition on, and no PWM signal, air pressure flows from port 1 (turbo outlet) -> port 3 (wastegate actuator) - wastegate receives full boost.
    In these cases the WGM is de-energised.

WGM de-energised

  • power/ignition on and PWM signal, air pressure flows from port 3 (waste gate actuator) -> port 2 (turbo intake pipe) - wastegate isolated from full boost.

In this case the WGM is energised.

WGM energised

This means when the WGM is recieving a PWM signal it is operating to reduce pressure at the Wastegate Actuator. Rather than "Activate to Limit Boost" the system is "Activate to Increase Boost".

But RAVE says...

So what does RAVE actually say to support the "activate to limit boost" theory?
The following sentence is often pointed to as evidence:
When full boost is reached a control signal is sent to the wastegate modulator, and a vacuum is applied to the wastegate valve.

Interestingly this sentence incorrectly states that vacuum rather than boost operates the waste gate valve. This is often excused as a typo but there is clearly an error in the statement.

Nothing else in RAVE indicates a specific method of operating, just that the system controls boost pressure to prevent overboost.

What about the Nanocom logs....

The Nanocom samples engine data once every 1.2 seconds in the current EVO guise - Nanocom 1 was a bit quicker at 1 second.
The WGM control code samples boost pressure and engine load once every 10ms and updates the PWM amount at that speed.

This means the WGM PWM has potentially been updated 120 times for each data point the Nanocom logs show. Transitions between PWM on and off to control limit boost occur quite quickly. 500ms is not uncommon, and the actual switch off occurs faster than the 70ms sample time of the logs.

In conclusion...

Looking back at the opening quote it's pretty obvious what is occurring.

... the waste gate modulator info that Nanocom shows under "read fuelling" went to zero occasionally, so it basically was not controlling turbo charger boost / waste at certain times and was very "hit and miss" at best.

The waste gate modulator PWM drops to 0% because the ECU is trying to direct full boost pressure to the waste gate actuator. And from the diagnostic information you can surmise the failure mode is either loss of spring tension in the valve or internal fouling of the modulator.

The next post in the Wastegate Modulator series will look at the WGM control maps.

Overboost Fuel Cut Map

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.

Tech Note No.1: MAP sensor recalibration and replacement

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

Tuner Pro XDF's

Tuesday, August 22, 2017 - 16:00

The donor-ware XDF's for NNN ECU's had a bit of a version bump today...

Note: These XDF's and all future updates are available anyone who supports the site with a donation of $5.00 USD or more.

These are changes I could remember:

Version 2.0 20170822
- Add SOI maps
- Add Smoke compensation maps
Note that EU3 maps use an adjust map and scaling map pair.
The scaling map is a multiplier so if there is 0 in the scaling map the adjust output is 0.
It's going to take me a bit of time to document so please be patient.
Information will be posted when it is ready.
- Add Air Conditioning load map
- Add Auto Torque Reduction IQ map
- Add Auto Engine Torque map
- Alter scalar naming
- Add Waste Gate Modulator control maps and scalars
- Add "hidden" Injector Idle Response map to EU2 XDFs
- other stuff...

There were a few tweaks to improve axis scaling, and descriptions added...
As always the XDF's are a work in progress.

Tuner Pro Update

Mark Mansur has just uploaded a new version of Tuner Pro which fixes a bug introduced in the previous version.
The bug prevented the patches included in the Td5 XDF's from applying.
You can download the new version from the Tuner Pro Download Page.

Td5 ECU Tools: scripts for the USBBDM NT

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

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

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

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

For a working setup you'll need:

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

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

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

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

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

Td5 Tuning - a "Torque Based" approach

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

Introduction

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

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

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

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

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

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

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

Datalogger - more updates

Tuesday, July 25, 2017 - 15:00

It's been about six weeks since I posted the last update to the site, so thought I better post something...

Since the last post I've been working on implementing a modular system, with the idea that the basic logger can handle control inputs from USB, Bluetooth LE, a simple stop/go button interface, or a touch panel. The "Pass Through" interface shown in the last post is intended as a way of allowing applications running on mobile devices to communicate with the ECU without the need to micro-manage the low level protocol. You send a Service ID, Resource ID and any other necessary data for the request and get back a positive response plus data, or negative response if the request fails.

The second module is a configurable logger. And this is what I've been working on since start of July. The logger is currently set up with definitions for the 18 or so diagnostic requests that I think you'd realistically want to log.
Requests are set by using something like..

AT M LC  09 0D 1B

LC indicates a "Log Configure" command, and the items to log are specified using the Request ID. In this example 0x09 = RPM, 0x0D = Road Speed, and 0x1B = Throttle Voltages. The command input is not case or space sensitive.

Starting and stopping logging is controlled by AT commands.

AT M LS  
AT M LE  

These are the "Log Start" and "Log End" commands respectively.

By default the data from the logger is in ECU format with no transformations. Using the LR command

AT M LR  

toggles between "Raw" and "Convert" mode which converts Kelvin to Celsius and shifts decimal places where appropriate.

The next thing I need to tackle is the logging to SD Card and the button control interface.

Using an XDF with Td5 engine maps...

Thursday, March 2, 2017 - 06:45

There are a couple of little tricks to loading up the Tuner Pro defintions so thought I'd make a quick post on the procedure.
You'll have to excuse the "retro" Win XP look n feel. I'm running a Windows virtual machine under macOS and XP does the job without too much bloat.

1. Open a file to edit.

Use File >> Open Bin to open the file to edit.
For nanocom .map file select "All Files" as the file type.

Open dialog

2. Open the XDF

Use XDF >> Select XDF to open the appropriate XDF file.

Open XDF

3. Add Compare Bin

Use Compare >> Load Compare Bins... to load one or more compare bins.

Load compare bins

With a compare bin loaded you can use the "Show compare difference" and "Show compare bin data".

  • Using a random mod to illustrate, select a range of cells and multiply by 1.05
    Random mod

  • Clicking the "Scales" icon gives "Show compare bin data" - table values from the Compare Bin.
    compare bin data

  • With "Show compare bin data" on, clicking "Show compare difference" shows the difference between the map being edited and the compare bin.
    compare difference

If you find yourself having to load the same base file and xdf every time you start Tuner Pro, go into Tools >> Preferences and under the "Genera"l tab enable the two options to load the last used file at startup.

Footnote

I'm offering what I describe as a "basic" XDF as donor-ware. These have a bit more detail on tables than Td5MapEditor, have some unit converted to more human friendly representations, and allow direct editing on MAP and Boost limits using the GUI.
The "deal" is anyone who makes a donation will receive an XDF of their choice. How much you donate is entirely up to you.

Td5 Datalogger updates

Sunday, June 11, 2017 - 08:00

I've come to something of a Catch 22 where I need detailed logging to properly document and verify the waste gate modulator, and the code that handles torque reduction requests from the auto gear box before I can post details of the maps. On the other hand, if I work on the datalogger nothing much happens on the website.

The combination of changes to the Microchip tool chain which caused issues with my old code, a failed hard drive which lead to the discovery that the Microchip peripheral library installer does not work on current versions of macOS, and the need for a rethink and rewrite has meant the datalogger has been out of action since late December.

When I was playing around with the VAGCOM adapter and Python earlier in the year I had ported//rewritten part of my C code and found that using a publish and subscribe framework solved a few of the issues I'd run into. As a result of that little "ah ha" moment and the hassle of dealing with the Microchip libraries I've been working on writing and unit testing peripheral drivers and a publish & subscribe framework in C.

Over the past few weeks I've been progressively bolting together the code that manages the communications with the Td5 ECU.

The way I've decided to approach this is to look at the ISO14230 docs and build a module that handles the startCommuncations, sendData and stopCommunications commands as the base of the logger/interface. That section is now working quite well and at this stage only requires some additional error handling to deal with cases where the ECU response times out mid-message.

From that base I've been working on adding a command interface and USB interface. The idea is to provide a basic set of ELM-like AT commands to configure the settings from default. The current defaults for "pass through" operation are set to connect to a Td5 ECU in manufacturer specific diagnostic mode - Testbook diagnostics in other words.

In practice this means you can hook up the interface and send requests without worrying about the underlying communications protocols. This is similar to how the ELM327 operates.

This is a short demo of the pass through mode, operating over a serial usb connection. The delay between hitting return on the "21 01" command and the response includes the time taken to connect and authenticate to the ECU.

Pages

randomness