Injectors. Adaptations. Coding

Several themes will be merged in this post, but it’s necessary, to explain the principles of performance of the engine management system.

 

Disclaimer. As usually, information from the manufacturer – zero, everything described below is a result of research and could differ for different software releases.

 

Let’s start with several interesting issues regarding coding of injectors. everybody knows, that the injectors have to be coded after replacement. Grouping data are printed on each injector.

We will explore this theme a bit deeper.

Injector flow-rate data: in the first line.

INPA identifies, that these data could be in area 52,9 .. 70,8 mJ. Performing elementary mathematical operations, we calculate: average value: 61,9; maximum deviation +/-17%.

 

The reaction time of the injector: in the second line.

According to INPA, these data can be in area 1,55 .. 2,86 mg/stk, average value: 2,21; maximum deviation: +/-42%.

 

It look’s that everything is OK – a possible scattering of the parameters is quite wide, so the splitting in groups is necessary.

 

Additionally, the manufacturer has made last numbers of the code as “checksum”, grouping conditions are kept in secret – it sounds quite serious.

 

The situation gets more interesting when we start to explore available data from injectors more closely. Collecting data from quite a significant amount of injectors, we come to conclusion, that there is flow-rate in the area of 56,9 .. 59,1 mJ possible, and the time-describing value: 1,99 .. 2,56 mg/stk.

Accordingly, the flow-rate scattering comes out around +/-2%, but reaction time: +/-11%

 

If we could group the reaction time (in several groups), the flow-rate is so close to average value, that grouping is totally pointless!

 

Next step – make sure, that these data are not some kind of a “secret code”, but an analog value, which is described by them.

 

As already observed here, the input of incorrect check-sum complicates the creation and restoration of adaptations, but, if the adaptations are already created, the input of any data is possible, using INPA, and no negative indications are observed.

 

Input of injector data and research of injector correction menu

showed:

  • coding data of injectors really are value, not code (for example, group code);
  • for each injector data the multiplicator is applied (parameter, which describes flow-rate), additionally, the parameter, describing reaction time of the injector, is counted.

At this point, it becomes even more interesting – it is clear, that at least one on the parameters is actually redundant, because the injector flow-rate is with such small technological difference, that grouping, taking in account this parameter, is totally pointless.

 

Next step of the experiment – find out, how these data codings affect the performance of the engine management system. On the first stage, we have to find out, if it is possible to cheat the “system”. As we see in the previous image, the corrections applied to injectors (1st bank: 1 and 3) are significantly different. Idea: if we modify initial parameters of the injectors – maybe we can get “perfect” injectors? If that would be possible, we could rewrite data of the injectors after some long while and evaluate both drifts of their parameters and conformity of the manufacturer’s data (even relative) to real obstacles, and also evaluate the influence of other factors (differences in the mechanical properties of the cylinder group).

 

Unfortunately, this idea failed. It turns out, that data of the injectors (more precisely – the difference between previously stored values and new data) are taking into account only in the moment, when the injector is being registered, to decrease possible performance imbalance (significant unevenness of the engine). In the further action correction data of the injector (flow-rate and response time adaptations) are created, NOT TAKING IN THE ACCOUNT the manufacturer’s coding.

 

Sample. Let’s suppose, that the performance parameter fo the injector (factory coded and confirmed by adaptations) is 50 mJ. In the current situation, the applied correction is +20 mJ. Total energetical parameter: 50+20=70 mJ. All adaptations and change of this parameter take place in relation to the existing (70 mJ) value. Coding data of the factory are not taken into account (anymore).

Coding data of the replaceable injector are 60 mJ (+10 mJ against old injector). MSD changes existing energetical parameter with a required difference: it means, 70+10=80 mJ. After alteration of data, MSD “forgets” factory coding data, and all future corrections are performed with parameters of altered corrections.

 

This solution has several advantages:

  • if the service specialist applies the correct coding procedure, the initial unevenness of the engine after replacing the injectors is reduced, but in turn, if the coding procedure is applied incorrectly or is not applied at all – there are no negative long-term effect;
  • disregarding input coding data, the control of max/min allowed (defined by the factory) parameters of the injectors is not disturbed;
  • no cheating with injector data is possible – injectors, which inappropriate and/or with an inappropriate technical parameter, cannot be coded – the coding will not be successful.

 

There is also a disadvantage:

if the previous injector was coded incorrectly, no adaptations were performed (exact/correct parameters measured), also next coding (if correct data are entered) could be incorrect because the difference between old/new parameters will be inappropriate.

 

Taking into account all mentioned above, we come to conclusions:

  • uncoded or incorrectly (incorrectly: data from another injector, but with correct check-sum) coded injectors CANNOT BE the cause of the unevenness of the engine after creating new adaptations;
  • the importance of coding of the injectors is highly overrated, taking into account, that MSD performs the tests of cylinder mechanical efficiency in idle, and also flow-rate tests under different load and RPM circumstances, common Lambda adaptations of banks etc. – it means measures and accordingly corrects true parameters of the injectors.

 

In the picture below: block scheme of the creation of adaptations of injectors (very simplified).

Short description of functionality.

 

Each injector is characterized with two basic parameters:

  • flow-rate (defines amount of injected fuel in case of long opening);
  • time delay (defines reaction of the injector to very short opening).

In any mode (idle, full load, Homogeneous mixture, Stratified charge etc.), MSD takes into account both parameters, mentioned before. It is self-explanatory – the longer the opening of the injector, the less impact of time delay and greater impact of flow-rate, and vice versa: the shorter the opening, the greater the impact of time delay and less impact of flow-rate. Or: time delay has a greater impact on idle, flow-rate – in full load.

 

During all life cycle of the engine MSD performs individual tests of cylinders:

  • tests of mechanical efficiency (Homogeneous or Stratified charge mode), idle;
  • tests of Chemical efficiency (Lambda) for the Homogeneous mixture, in low, average, high load area, in different RPM*

* MSD creates multidimensional map according to the opening time of the injectors, RPM, and other conditions. Data of Homogeneous mode are later used in Stratified charge mode, for similar work conditions.

 

If new injectors are installed and registered, MSD performs following actions:

  • reads measured (true) parameters (data, which are stored from tests, mentioned before) or, if such data don’t exist yet – coding data of old injectors; the action marked in block scheme with direction ‘<‘ ;
  • calculates the difference between new (just inputted data of the new injector) and possibly more reliable data and modifies the parameters of the injector; the action marked with ‘>’.

With this moment, the “impact” of data of new injector is over. Benefit (as already mentioned before) – quicker adaptations and more even running of the engine directly after registering the injector. But in long term it has no meaning, are the injectors registered or not! The main requirement – the coding data has to be true, it means, the control-sum of the has to be appropriate.

If the control-sum is not true/correct, creating of MSD adaptations is disturbed, as described here!

 

Initial data of the injectors are supplemented with correction data of all Lambda bank. These data are with offset type correction in idle (to 1200 RPM) and with multiplicative impact in case of higher RPM and in non-zero load. These Lambda corrections consist both of multidimensional LTFT and additional corrections of integrators.

For older software releases is typical, that in addition to each bank also temperature-related additional corrections are applied (max depth of correction +/-8%). In newer releases, this correction is either not applied or even has no output.

 

As we see, data from a head module of Lambda correction of the banks and from temperature additional correction module are directed to adaptation module, which affects individual data of each injector. These corrections are characteristic for newer software releases and perform the following function:

  • if Lambda correction for both banks (tenths/hundreds of motor hours) shows the necessity to perform deep LTFT correction (multiplicative correction: above +/-10%) in the mid/high load conditions or the offset LTFT are “moved” in one polarity (against 0 mg/stk);
  • if additional corrections against the temperature for both banks are significantly “moved” to one polarity in all range of temperature;

the data of the injectors are slowly (during tenths/hundreds of motor hours) modified, so the LTFT mentioned before (both offset and multiplicative) and also additional corrections of the temperature are reaching 0.

 

And now – to practical things!

Correction data of the injectors: ../F5/Shift+F6/F1 (line 4 .. 6) and the opening time (first three lines)

Ignition on, the engine not started: INPA shows:

  • the flow rate and time delay parameters of the injector, additional correction of the temperature are taken into account (first three lines)
  • flow-rate data + additional corrections of the temperature (line 4..6).

With the engine on, following data are added (according to RPM, load etc.): bank data of LTFT to current performance mode.

Correction data of injectors are displayed (and are being processed) as absolute values, it means, they are displaying “corridor” of parameters, allowed by the manufacturer.

 

Additional correction depending on temperature (for the latest software releases/MSD81 – not used) can be seen here: ..F5/Shift+F6/F4

Test results of Chemical efficiency of the injectors in Homogeneous mixture mode are displayed here:

../F5/Shift+F6/F3

Measurements of mechanical efficiency of cylinders (injectors) in Homogeneous mixture mode/idle cannot be seen directly, results of test quality are displayed as Rough run measurements ../F5/F7

Attention: Rough run measurements are displayed in firing order!

 

Measurements of mechanical efficiency of cylinders (injectors: applied correction) in Stratified charge/idle are displayed here: ../F5/Shift+F6/F5

 

Related entries:

Flow rate data coding of injectors

STFT and LTFT