MEMS3 Downstream Lambda Delete – Decat without DTCs or MIL light.

Download Link: https://andrewrevill.co.uk/Downloads/MEMS3Tools.zip

Using my MEMS3 Mapper you can now delete the downstream lambda sensor (when running a decat pipe), without logging DTCs or turning on the MIL light.

When running with a decat pipe, the downstream lambda sensor will report DTCs (fault codes) relating to the performance of the catalyst, or will report DTCs relating to the sensor itself if it is removed. The MIL light will illuminate. It is possible to set flags in the map to suppress these DTCs, which also avoids turning on the MIL light.

HOW TO DELETE THE DOWNSTREAM LAMBDA SENSOR

You will need to use version 6.17 Release or later of MEMS3 Mapper.

Read your ECU or load a project file in the normal way..

Select Tools, Wizards, Downstream Lambda Delete from the menu:

If this menu item is disabled, MEMS3 Mapper has not been able identify all of the scalars which it needs to modify. In this case select Identify, Keep Existing form the menu and MEMS3 Mapper will search for the scalars it needs for the current firmware version.

You should see the following dialog:

To delete the downstream lambda sensor, simply check the checkbox. To reinstate a deleted lambda sensor, uncheck the checkbox, the wizard will then apply all of the necessary changes to the map.

Write the map back to the ECU using MEMS3 Mapper in the usual way.

BEHIND THE SCENES

I have tested this across a large number of different MEMS3 firmware versions, including MPI, VVC, turbo and automatic versions. I have tested each of these on a running engine (although not always the correct engine for the map version!) and an electronic simulator. I have tested these with no downstream lambda sensor connected. In most cases, the ECU logs DTC P1191 (description “Downstream (Post Catalyst) Oxygen Sensor Heater Electrical Fault”) fairly rapidly, followed up to 20 minutes later by DTC P0141 (description also “Downstream (Post Catalyst) Oxygen Sensor Heater Electrical Fault”). DTCs P0136 to P0140 are also associated with the downstream lambda sensor (“Bank 1 Sensor 2”) and may also appear. Each of these DTCs is suppressed by a different flag in the map, which is changed from 0 to 1 to suppress the DTC.

The scalar flags which suppress the different DTCs are all together in a large block towards the start of the map. Some very early Rover 25 and Rover 75 firmware versions don’t seem to have them and on these I can’t suppress the DTCs, but they are present in all of the later firmware versions right across the MEMS3 family. If you need to delete the downstream lambda sensor on one of these very early firmwares, it may be possible to flash the ECU with a later firmware for the same vehicle which does include the facility.

The scalar flags actually caused some problems for my automatic Identify feature, which aims to identify specific tables and scalars in previously unseen firmware versions. Many of the scalars in the maps tend be largely unchanged across very large numbers of different firmware versions and maps; they are in fact just the constants used in the code, and the code evolved slowly from one firmware version to another. My code looks for patterns of similar values in adjacent and surrounding scalars when identifying specific locations. The large blocks of flags, mostly set to 0, did not provide it with enough information in order to positively identify the lambda delete scalars.

However, examination of the structure of the blocks of scalars across a wide range of different firmware versions revealed that they tended to follow a consistent structure within different major families (NA MPI Manuals / VVCs & Later 75 / ZT, Turbos, Automatics and Freelanders). Although the structures varied between these families, they were still largely the same. The turbos all appeared to possess one additional flag, and the automatics appeared to have seven additional flags inserted at the start of the block, probably relating to automatic gearbox DTCs. On either side of the flag block were scalars that were highly conserved across all MEMS3 versions, and which could easily be found by my Identify system.

I therefore added a new feature to the definition of a scalar in MEMS3 Mapper; bookmarks. This allows you to define a scalar as being identified relative to the locations of two other bookmark scalars. Provided that the application has seen another firmware version with the same spacing between the two bookmarks, it will be able to find the specified scalar by looking at the corresponding distance from each of them. In all cases, where the flag block structure differs between two MEMS3 instances, the distance between the two bookmarks also differs. The application only uses other firmware versions with the same distance between the bookmarks as templates when identifying the delete flags.

With this feature in place, the latest version of MEMS3 Mapper appears to have automatically found the correct scalars in all MEMS3 versions that I have tested.

As always, please do get in touch with me if you have any questions or queries.