In my work, I use only tools, created by professionals of BMW AG – for now, they are the most powerful of available ones. In addition – very accessible.
But there are persons, who choose alternative products, developed by the third side, for example, Carly, Pro Tools, Launch, etc. Part of these products are actually using BMW databases and scripts, but the interface is more modern and more simple for the user.
Today’s experiment – a battery of E60 will be registered with Launch, then data will be checked with INPA. Task – to understand, does Launch performs at the same level (at least in the level of available data) as ISTA D.
Here, IBS data of car before registering the battery:
This is much more interesting case. SOH is positive (value – correct), but data counters of energetical balance have gone to the “second circle”; SOC data regularly incorrect (unavailable); the energetical balance of the day – with incorrect values.
As we see, for the car, which is more than 10+ years old, no battery was registered.
Part 1 of the experiment.
Connect Launch. At first let’s check, does the Launch correctly reads status data of the battery.
The charge of a battery (%), in hours. Data are displayed correctly.
SOC of battery by days. These data correspond with INPA and ISTA D. Exception: current SOC is not availble!
And now – let’s start coding of battery replacement!
Here we see one inaccuracy: actually, the capacity of the registered battery is 90 Ah (according to ISTA D). INPA (obviously, Launch uses INPA script) shows +1 Ah against the true value. Developers of Launch have not taken into account this nuance (or – even haven’t noticed it). But I got a hint, on what base is Launch built (didn’t spending my time to investigate it).
Here, the battery is (as if) registered.
Here, Launch confirms, that the registration of battery is completed.
Part 2 of the experiment.
Let’s connect INPA and check the data of all available registers.
Here, marked fields:
- really, the replacement of battery – registered (odometer readings: correct);
- counters of battery charge and temperature are cleaned: correct;
- group of energetical counters of battery cleaned: correct.
During next 5 .. 10 minutes the energy counters correctly calculated discharge of battery – IBS sensor was sending data, everything looked perfect.
Here, also SOH data are cleaned. Wonderful. But…
Here, from this moment it becomes more interesting. Launch has correctly cleaned test counter of the battery (it indicates 0), but SOC (directly after registering) has fundamental problems:
- not taking into account not-performed tests, actual SOC is displayed as different from 97.X .. 99.X % (this is usually the initial value of SOC after replacing the battery; it changes depending of is the engine turned or not);
- SOC data don’t correspond in both data groups – in the correct situation, SOC actual value is dubbed on the right side column of data.
Obviously, some data thou is not cleaned correctly! Additionally, these are not statistic data (as, for example, data regarding the temperature of the battery), but much more important data – SOC is, possibly, the most important data in whole IBS system!
Deleting of these data (everything, what is connected with a profile of the battery and SOC) is critically important! Determination of SOC is a very complicated task.
Slight derogation – I will shortly explain, how you can (try) define SOC of the battery. In the literature is mentioned: 0 .. 100 % SOC corresponds to the voltage of 12.2 .. 12.8 V. It sounds simple. But:
- voltage has to be measured around 2 hours after a charge of the battery because directly after charging the voltage will be increased;
- this voltage is indicated for the temperature of 20 oC, in other temperatures it changes;
- changes in this voltage are very tiny: +/-2,5 % (against the absolute value), which means – measurements have to be done very accurately;
- some battery manufacturers add different additives to lead plates of the batteries (to reduce degradation of plates, to upgrade its parameters), which a little bit, but still, change the voltage of battery – “numbers” mentioned before don’t correspond anymore;
- each production party and each battery has slight differences from average parameters. For example, a difference of just +/-1 % from ideal (average) value of the voltage will create SOC mistake of around 40 %!
So, to detect SOC, several methods are used in the same time (parallel): the voltage of battery discharge in slow discharge phase (when the car”sleeps”), changes of this voltage, when the battery is charged/discharged for exact number of Ah, are measured; charging the battery, the “saturation” threshold is looked for – at the moment, when the battery doesn’t “absorbs” energy anymore, it’s fully charged. Additionally to this parameter, also the true capacity of the battery should be detected, in the same time – deep discharge cannot be allowed, because in this case can be problems with starting the car. Additionally, all these parameters are changing, depending on temperature (and this dependency is completely different for different battery models/manufacturers).
This is an only small part of problems, which are encountered when detecting the condition of battery charge.
I’m totally convinced – if due to some reasons IBS uses data of old battery to calculate SOC of new battery, the result is unpredictable and for sure – completely incorrect!
Part 3 of the experiment.
ISTA D was used, to repeatedly register the battery and observe, are there any changes or not.
As you see, ISTA D confirms coding of battery, odometer readings – correspond to one, recorded by Launch. Unfortunately, ISTA D didn’t clean any registers. Obviously, ISTA D detected, that the registration with existing odometer reading has already been performed. So – unfortunately, it’s not possible to immediately fix problems, created by other tools.
Sentence of this entry – for coding, adaptation, programming use only tools, developed by BMW AG: ISTA D/+/P.
This experiment strengthened my confidence – no experiments with customers cars. In current case – if Launch uses INPA scripts, but INPA tends to register the batter incorrectly – it’s just logical, that Launch also will perform this operation incorrectly!
