Of ECU's and Electronics

Welcome to DiscoTd5.com, a site dedicated to the Land Rover Td5 Engine. The DiscoTd5.com website springs from the interests and experiences of my ownership of a Td5 Discovery which I purchased in May 2011. So far it's been a journey of greasy hands, skinned knuckles, and a lot of fantastic driving experiences - some 20,000 45,000 62,000 kms so far. Since I first set up the site, my interests have become heavily focused on reverse engineering the Td5 ECU firmware, and I'd expect this focus to remain for the foreseeable future. In the near future I'll be making a set of scripts to configure the USBJTAG.com USB BDM NT interface for recovering bricked ECU and loading remaps available for sale. Check back soon...

XDF progress update

Posted: 
Monday, November 5, 2018 - 11:30

Current Status

I'm currently working on new method for generating XDF's which is providing a chance to streamline the process.

One issue that has been bothering me is that significant portion of the NNN XDF's are redundant. This occurs because the XDF's are currently created based on the variant-fuel map pairs in each .map file.

The reality is that the only difference between the fuel maps in for example swdxe007-swtnp004.map and swdxe007-swtnp006.map is the number of the variant map in the fuel map. The fuel map checksum also changes by the difference between the variant map version numbers.

Neither of these differences have any impact on how the XDF defines the tables and constants within the fuel .map. A small number of NNN EU2 maps have additional differences in 5-6 constant values but again the structure of the fuel map is the same, so one XDF definition can edit both versions.

So the upshot is that the next release of the XDF's will be based on the fuel map identifier only, and this will reduce the number of NNN XDF by about 30-40%.

XDF auto loading

Tuner Pro has the ability to auto load XDF's when a .bin / .map is loaded. Unfortunately this must be manually configured but it saves a bit of messing around once it's configured. It's usable with current versions of the XDFs but will make more sense when the XDFs are consolidated.

The auto loading is configured under Tools > Preferences > Default XDFs by selecting enable default definitions.

XDF auto load

These are the offsets for the current NNN XDFs.

Map Offset ID Byte
svlne004-svtnp003 0x1cfe6 0x8f
swdxe007-swtnp004 0x1cfe6 0x9b
swdxr004-swtnp004 0x1cfe6 0xdf
swdxr004-swtnp006 0x1cfe6 0xdf
swdxe007-swtnp006 0x1cfe6 0x9b
sthdr009-sttdp009 0x1ba26 0x3d
suhde036-sutdp014 0x1ba26 0x44
swdxr002-swtnp004 0x1cfe6 0xb8
svdxe008-svtnp006 0x1cfe6 0x30
suhdr009-sutzp005 0x1ba26 0x3f
svdxe008-svtnp005 0x1cfe6 0x30
suhde036-sutdp012 0x1ba26 0x44
suhdr009-sutzp004 0x1ba26 0x3f
svloe005-svtnp005 0x1cfe6 0xca
svloj002-svtnp006 0x1cfe6 0xbd
svdxe004-svtnp003 0x1cfe6 0xe6
svloe004-svtnp003 0x1cfe6 0xd1
svdxe003-svtnp003 0x1cfe6 0xad
sthle022-sttlp010 0x1b98e 0xee
swdxk001-swtnp004 0x1cfe6 0x33
svloe005-svtnp006 0x1cfe6 0xca
svdxr007-svtnp005 0x1cfe6 0x51
sthde021-sttdp010 0x1ba26 0xa1
svloe002-svtnp003 0x1cfe6 0x8b
svdxr007-svtnp006 0x1cfe6 0x51
svloj002-svtnp003 0x1cfe6 0xbd
svlor005-svtnp005 0x1cfe6 0x9
svlor004-svtnp003 0x1cfe6 0xf
sthde021-sttdp009 0x1ba26 0xa2
svlor002-svtnp003 0x1cfe6 0x10
svdxr005-svtnp003 0x1cfe6 0x4d
svdxr002-svtnp003 0x1cfe6 0x4e
swdxk003-swtnp006 0x1cfe6 0x86
svdxe006-svtnp003 0x1cfe6 0x2c
sthle022-sttlp009 0x1b98e 0xef
svdxg003-svtnp006 0x1cfe6 0x7b
swdxk003-swtnp004 0x1cfe6 0x86
surdk004-sutzp004 0x1ba26 0x3b
svlnr004-svtnp003 0x1cfe6 0x16
svlnr005-svtnp005 0x1cfe6 0xff
swdxe004-swtnp004 0x1cfe6 0x5a
surdk004-sutzp005 0x1ba26 0x3b
svlnr005-svtnp006 0x1cfe6 0xff
svlne006-svtnp003 0x1cfe6 0xd5
sthdr009-sttdp010 0x1ba26 0x3c
svlne007-svtnp005 0x1cfe6 0xbb
svlnr002-svtnp003 0x1cfe6 0x18
svlne007-svtnp006 0x1cfe6 0xbb

Site updates

Posted: 
Tuesday, August 7, 2018 - 21:00

While it shouldn't be obvious, I've moved the website to a new host. The process has been fairly problem free but if anything is acting up let me know.

On a related topic Google Chrome and other browsers have started marking sites that aren't secured will SSL certificates as "not secure". It's really a bit of overkill for a site like this, but as the Not Secure warning is kind of off putting I've moved the site across to the secure protocol.

Chrome is currently still complaining because the images in a lot of the posts are hard coded to the insecure address. I'm slowing working my way through and fixing up the links.

For the moment the front page and the donor login pages are now flagged as "Secure".

Hawkeye and Nanocom: The Case of the Wrong Fault Codes

Posted: 
Friday, November 23, 2018 - 12:30

We tend to assume that when you plug in a specialist fault code reader the codes that are reported are correct.

Unfortunately that faith seems to be misplaced.

Initially I thought this was a problem that only afflicted the Nanocom but a recent posting on a UK forum suggests that the Hawkeye suffers from the same problem.

The codes that had been posted will be familiar if anyone who as tried running an EU3 map on an EU2 vehicle.

Nanocom
- (4,3) Coolant temperature circuit. (Logged High).
- (6,3) Coolant temperature circuit. (Current).
- (24,7) Problems detected with auto gearbox. (Current).

Hawkeye
- Fault 3018 Coolant temperature High Fault logged
- Fault 3034 Coolant temperature Fault Active
- Fault 3174 Fault detected with automatic gearbox

The three "phantom" faults reported are caused by the lack of Ambient Air Temp sensor which is part of the 4 wire AAP/AAT sensor used on the EU3 engines. And the codes can be eliminated by adding an extra wire and the EU3 airbox lid and sensor.

But that doesn't explain why the fault codes do not reflect the actual fault.

We investigate anomalies...

It's not widely known that the EU2 NNN maps include code to process the output of the Ambient Air Temp sensor, although the data is not used by the engine maps. I currently have an EU3 4 wire AAP/AAT sensor fitted but have gone back to running EU2 maps. With this setup I discovered the AAT readings are returned as part of the live data. Unfortunately the AAT sensor is completely ignored by the Nanocom, despite multiple requests that this be added.

Given that both EU2 and EU3 NNN maps are AAT aware, it would be fairly surprising if the ECU code was setting incorrect fault bits.

Looking at the ECU code for EU2 and EU3 NNN maps shows that the bits which correspond to faults 4-3, 6-3 and 24-7 are set by code that handles the AAT sensor. So these faults should actually be shown as AAT faults - logged high, active fault, and voltage out of range.

Let's go back, way back...

So at this point I started looking back at the MSB code....

Fault 4-3 corresponds with ECT sensor over voltage, check.
Fault 6-3 corresponds with ECT sensor active fault, check.
Fault 24,7 corresponds with Auto fault, check.

In other words the fault codes are correct on MSB ECU's, but wildly incorrect on NNN ECU's.

Oops...

Unfortunately this issue doesn't effect just the AAT sensor.

There was some internal reordering of ADC inputs done in the upgrade from MSB to NNN which means that 1 in 4 of the fault codes in the 1,x - 6,x range are incorrect. An additional fault in that range cannot be correctly identified without a code that is "invalid" for the MSB and therefore not reported by diagnostic tools.

Beyond the basic input checking codes (1,x - 6,x) there are additional errors and major omissions.

Checking out some of the faulty codes on forums I've seen at least one instance where someone was told to replace the throttle position sensor when the fault code actually related to the MAP sensor... It wasn't surprising to see that after forking out a few hundred for a new pedal the person reported back that the new pedal had not solved his problems.

Other problems with incorrect codes are deemed as "quirks" when it becomes obvious the "faulty" part is fine and advice descends rapidly into random part swapping recommendations.

You just have to wonder how much money has been wasted based on the these incorrect codes...

So if you own a vehicle with an MSB ECU count yourself lucky - any fault codes will be correct.
NNN owners will just have to console themselves with the fact that the codes will be correct about 75% of the time...

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.

Tuner Pro XDF's

Posted: 
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.

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.

Datalogger - more updates

Posted: 
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.

Pages

randomness