MSD80 software upgrade. Part 3.

Day 15 to day 20


After two weeks of frantic search, only one specialist, not very known in certain circle, was chosen. All other specialists, for a variety of reasons, were “discarded”.

As alternative, the offer of Mosselman turbo also was considered. In this case, iMoss OBD/USB adapter has to be purchased together with software, and the reading of files/programming could be proceeded via OBD.

Readed files has to be sent to Mosselman, in the next day modified files (to version 200kW) are sent back – after making the advance payment.

Unfortunately, I couldn’t get more detailed information (for example, if the algorithm of engine version U0, or some hybrid versions of U0 and O0 engine releases are created, etc.)…

When I didn’t get all required information from Mosselman, I took the risk to confide in the previously mentioned unknown specialist. Also the information from him was exactly zero, but he promissed to modify all coding data, not exact file (as Mosselman).


Re-coding of vehicle took 2 days.

The situation is more difficult, because, for example, BMW/ECU Explorer can’t automatically convert CAS3+ to “virgin” and clear motor_hours of MSD80. Only bonus – Explorer can automatically count CRC. Additionally – no one exactly knows, exactly in which memory cells motor_hours data etc. are stored.


Accordingly, as it look’s, the technology of modifications is as following:

1. ISN is read from existing CAS and DME (it’s not possible to read it directly, bet ISN can be “catched”, performing the programming of units); the backup is created;

2. “correct” versions are found from versions spilled in internet or versions readed by self with necessary status bits, and programmed;

3. the ISN is modified, VIN encoded, CRC re-calculated.


After second day I got back my car. Short check-up:

FR both in FRM/LM and CAS is ND71!

Power_class both for CAS and DME is class 2!

DISA valves: performing!

DME (not using UIN) programmed 8603138!

Dynamic – as it has to be for version of 200kW! The efficiency of DISA valves (especially the large one) can be felt, when more aggressive acceleration is performed – direct confirmation, that the valves are performing (also live data via INPA confirm changes of valve position). In first seconds of kick-down mode, Lambda decreases to 0,85 even from 2000 RPM – direct confirmation, that the engine develops maximum torque.


Next step: choosing the best software release.

Short comments about release versions, which were tested:


Last (newest) release, offered by ISTA P.

Incorrect algorithm for rough run in Homogeneous mixture mode. High sensitivity of fake 3104.

Of course, the performance is more correct than for initial versions (for example, 396/397 of 76-th series), but still real unevenness is detected.


Last (newest) release, offered by winKFP as upgrade.

Very similar to 8603138, no significant improvements observed.


Laste releases for N53B30 O0 engine, intended for 630i.

Correct rough run algorithm in all modes, very correct switching between modes, but – very rough error, creating the LTFT offset adaptations. The register of offset adaptation register  for 2-nd bank is not re-written, unjustified error bit in 1-st bank. It’s possible, that with other adaptation data this release functions, but – no desire to use it. Additionally, there is a persisting problem with DSC/DTC (all possible error messages + warning lights in the instrument cluster).

Conclusion: versions 182..188 are not usable, at least for E60 (at least  with 525 differential and manual transmission. It’s possible, that even speed detection cogwheel don’t match, the data exchange of DSC unit etc.)



Version intended for E61.

Differences noticed:

  • Correct rough run algorithm in all modes;
  • A segment replacing principle “Stratified to Homogeneous lean” in case if detected rough run (as, for example, 8603154);
  • Very correct switching between modes “Stratified/Homogeneous lean/Homogeneous”;
  • Energy-compensated regeneration sessions;
  • The incorrect calculation of fuel consumption in Homogeneous lean mode has been fixed (as opposed to release No.154);
  • Correct creation and immediate updating of offset adaptations;
  • Correct corrections of bank against temperature;
  • Decreased sensitivity to fake 3104 (increased allowed treshold of unevenness counters, after which the 3104 error message is registered);
  • Correct updating after confirming 3104 (very correct restoring of adaptations in all modes);
  • No real unevenness observed. The engine switches via modes very correctly;
  • Following bug noticed: fake 3104 error message appears without any reason after driving mid/low quality (bumpy) roads. Good news: error has passive status, no consequences noticed. Detailed description at the end of article;
  • Reduced required minimal driving speed to start/hold desulphation session (down to around 105/100 km/h) and increased desulphation speed (from 50 mg/km to 75 mg/km if sulphurizing level is around 2000 mg).

Much more correct release as 138/174.


Release, which is intended for E61, as if only difference – LHD or RHD, but… Rough run algorithm in Homogeneous mode – incorrect. Bar of cylinder No.1 sometimes jumps from -8 units to +4 .. 6 (which was not observed in release No.178). More deep analysis was not performed (it was enough with detected inadequacy in performance of rough run algorithm).


Why exactly these parameters were chosen as criteria for performance test of releases?

If the real or fake unevenness is detected in Stratified charge mode, the engine switches from Stratified charge to Homogeneous lean mode. If the rough run algorithm in Stratified charge and Homogeneous lean modes are incorrect, it is obvious, that the number of fake unevenness cases will grow, and also driving on even road, the error message 3104 can appear.

If the rough run algorithm of Homogeneous lean performs incorrectly, there is a huge possibility, that also in Homogeneous lean mode the maximum number of allowed events will be reached, and the engine will switch to Homogeneous mode. Also the repeated creation of individual fuel adaptations for all cylinders will start. If the rough run algorithm in Homogeneous mode is functioning incorrectly, there is a huge possibility, that also in this mode the rough run will be detected, and the engine will start to re-create all adaptations.

If the rough run algorithm in Homogeneous mode performs correctly, the engine will switch to Homogeneous lean mode after recreation of adaptations, and after some time – to Stratified charge. If even in one of the stages due to incorrect rough run algorithm fake misfires will be detected, the engine will not switch to Stratified charge. Additional (excluding 3104) error messages will not be recorder, but the fuel consumption will be increased; after a while the engine can suffer all problems, which are typical in case of defective NOx system (problems with LTFT, error messages regarding fuel trim, misfire, etc.)

Additionally, incorrect performance of rough run algorithm falsely detects problems with cylinders, forcing the owner to eliminate non-existing problems, increasing costs of repairs, and, also leading to totally incorrect diagnostics! More about this – here and here.


Update. Release 8603178, part 2.

Testing release No.178 for a longer time, the sensitivity to uneven road and truthfulness of misfire counter was evaluated.

Comparison: the picture, how misfire counter of release 7611396 looked after driving half an hour on even road:

As we see, short term counters counted 2 .. 4 points to each cylinder.

Driving for one hour (2 times longer) on regular road with 8603178, misfire counter of cylinders was 0 .. 1 for each cylinder, it means, the sensitivity of No.178 to uneven road has been decreased for at least 8 .. 10 times. With such sensitivity, even after 5 hours drive on regular road the system will not count such significant values, that long term counters would become different form 0.

So: if you drive on regular/good quality roads, it’s enough to connect ELM adapter and evaluate misfire counters. Long term counters has to be 0 to all cylinders, short term – in area of several units.

After one hour drive (release No.178) on uneven road (really uncomfortable driving with speed max 70 .. 100 km/h in the 6-th gear, with as low as possible RPM – in such conditions the rough run algorithm is much more sensitive), short term counters for some cylinders has counted even 40 events, long term counters were increased (during previous sessions) to 3 .. 5 (driving on this road). Despite these, quite high, numbers of events, no error message 3104 was recorded, the engine continued to perform in Stratified charge mode.

The 3104 was not recorded, even after for 2 seconds group (following) misfire in one cylinder were provoked. This cylinder correctly was marked as damaged, misfire counters for other cylinders didn’t rise.

Conclusion: release No.178 very accurately detects the damaged cylinder and registers it’s misfire in appropriate registers, which makes diagnostics significantly easier. This release also don’t creates false 3104 error messages (with active status) on uneven road.


Attention! The software release 8603178 (possibly, actual also for other releases with increased misfire counters threshold) has following peculiarity: even, if the short-term misfire counters are close to 0 (in current case – they are far away from thresholds, after the real 3104 error message should be recorded with following change of engine performance mode) the error message 3104 sometimes is recorded in error message memory without any plausible reason. The status of error message is passive, no changes in performance of engine has been observed – the engine continues to perform in Stratified charge. In a given situation – if the check of misfire counters confirms, that there are no real misfires – follow the suggestion of BMW AG: don’t take any actions (ignore the error message 3104).

Cause of this issue seems to be pretty simple – threshold to start procedure of 3104 (uneven run) error analysis for some reasons (maybe – accidentally, maybe – changing of this threshold required serious rework, maybe – no one really tested latest software changes) is kept low as in previous versions, and as the result – error is recorded in error memory. But in the same time density of these ”misfires” is below new problem/error confirmation’s thresholds (they were reduced to eliminate problems with adaptations re-creation, etc.) and – the status of this error message remains as passive.

Screenshot of BMW AG/Siemens internal document: recommendations how to act if 3014 error message appears (MSD87).


Related entries:

MSD80 software upgrade. Part 1

MSD80 software upgrade. Part 2