Alter, Laufleistung und Batteriekapazität

[OBDZero]

Here is a list of the cars named in Liste mit Alter, Laufleistung und Batteriekapazität. The dates shown in the column Batterie Datum are the dates I'm using to compute the age of the battery relative to the import (EZ) date or the date the battery was replaced. I would like to compute the battery age relative to the biuld (BJ) date instead. This will eliminate the uncertainty in the time between leaving the factory and arriving in Germany. It will also bring the analysis closer to the original capacity of the battery. As mentioned before the BJ date can be found using the car's VIN number and these decoders:

https://www.vindecoderz.com/EN/Citroen

https://www.vindecoderz.com/EN/Mitsubishi

https://www.vindecoderz.com/EN/Peugeot

If send the VIN code to me in a PM then I will look up the date.

I will really appreciate this information plus any additional information such as the number of cells, the battery type 50 or 50N. Also corrections will be very welcome. Thanks in advance.

David

[OBDZero]

The following is an analysis of the Leaf data for the 40 kWh battery. This data has implications for our iMiev batteries which I will get to in a future post.



The analysis in a previous post showed that the Leaf 24 capacity (SoH) and the iMiev capacity can be best compared using % rather than Ah. This is particularly true as the difference in battery size increases. Therefore I am using % rather than Ah in the graph above.

The model is SoH % = 98.1 - 0.0000041* km - 0.0069 * days

The inverse of the days parameter is 145 days/% and the inverse of the km parameter is 244000 km/%. The Leaf 40 battery has about 125 Ah so % and Ah are similar enough that these numbers are comparable with previous Ah models. This shows that the Leaf 40 battery capacity is affected by age and but in practical terms not by km.

Note too that there is almost no spread in the highest capacities. This indicates that the capacity is set to 100% when the Leaf is imported or maybe when it is sold as I theorized with the Leaf 24 battery.

The equation in the graph shows that on average the measured and the modelled Leaf capacities are equal. The Leaf 40 R2 value is the similar to the R2 value for the Leaf 24 and the iMiev models so the Leaf 40 model is as good a description of degradation as the previous models. But it is still not very good.

Another observation is the apparent curve in the data. This indicates that the rate of degradation slows as the battery ages. This effect can be included in the model by using the square root of the days, as shown in the next graph. (Note that the number of days between marks on the x axis increases with the age.) I have seen the square root used in this way in e.g. the Yuasa technical reports on the iMiev batteries.



The model is SoH % = 102 - 0.329 * square root(days)

By converting to the square root the km factor became even smaller so there was no reason to include it in the model.

The R2 value in the graph is greater than the R2 values in previous graphs indicating that this model is a bit better description of the battery degradation. It isn’t great but it is better.

According to this model the rate of degradation at 100 days after import is 60 d/% which is very fast while the rate at 1600 days is much slower, 245 d/%. As the effect of age decreases the effect of km will become more noticeable. In other words we need to wait until we have more data for the Leaf 40 battery in order to determine the km effect.

[OBDZero]

In this graph I compare the reported SoHs of cars with the LEV50N battery with the reported SoHs of Leafs with the 40 kWh battery. In my previous post I concluded that the Leaf-40 battery degraded mostly due to aging at this early stage in its life. The effect of the number of km’s driven is much smaller than the effect of aging. Therefore this comparison between the two battery types is based on age alone. Age in this case is days since the cars were imported (EZ). I’m also using % rather than Ah because it makes the comparison easier. For the LEV50N this is % of the gross capacity, 50Ah.

Notice how spread the LEV50N SoHs are, compared with the Leaf. I believe this is because the SoH is set to 100% when the Leaf is imported or maybe even when it is sold. This is not true for the LEV50N therefore the spread in the LEV50N SoH is probably due to varying numbers of days between the day the battery was manufactured and the day the car was imported.

However this age related degradation of the LEV50N seems to be quite large, as much as 10% or 5Ah from the time of manufacture to the time it was imported into Germany. This is much larger than the rates found in my previous posts.

It is possible that the rate of age degradation is much higher when the battery is new than after it was imported into Germany. Yuasa that manufactures the LEV50N measured this early rate of degradation in the lab when developing the battery. Here is a graph from the Yuasa technical report on the LEV50N from 2012.


Figure 8 on age dependent degradation from the Yuasa technical report on the LEV50N cell (100% = 50Ah)
https://drive.google.com/file/d/1tuBiKR ... sp=sharing

Note that the rate of degradation is quite large to begin with. The battery loses 2 % (1 Ah) in the first 30 days after manufacture. This fast rate continued at 45oC. However at 25oC the rate dropped to about 1% (0.5 Ah) every 300d after 100 days. At that time the capacity was 96% or 48 Ah. The average air temperature in Germany is much less than 25oC so this rate must be even lower after the car has been imported. However, the temperature in transport from Japan to Germany could have been much higher than the German average. We will never know the temperature during transport but we can find the date the car was built. And the day the car was built must be closer to the day the battery was manufactured, the time 0 days shown in the graph above.

Coded in the cars VIN number is the build date of the car. This date can be found using one of these VIN decoders:

https://www.vindecoderz.com/EN/Citroen

https://www.vindecoderz.com/EN/Mitsubishi

https://www.vindecoderz.com/EN/Peugeot

With the build date rather than the import date we can hopefully explain some of the large variation in the early capacity measurements of the LEV50N battery.

[OBDZero]

Battery capacity interests us because of its affect on the range. Therefore getting the most range out of the battery is also a subject for this tread. There are two factors that determine how far you can drive, the rest range (RR) shown on the instrument panel and the speed. The car tells us the RR but it doesn’t tell us at what speed that range can be driven. If you drive at a constant speed in the same direction on a level highway then after about 15 km the car computes the RR at that the car’s speed. If you change speeds then a process begins that recalculates the RR at the new average speed. Increase the average speed and the RR decreases faster than the km driven.

When I first started on the OBDZero app I had something a bit different in mind. I wanted to know how fast I could drive and still reach the next charging station. I figured that this would give the shortest overall travel time. To do this I needed the following numbers, the remaining kWh in the battery, the distance to the charging station and the watts at any speed. The remaining kWh is the SoC times the battery’s 100% capacity. I know the distance to the charging station. Computing the watts at any speed requires a model of the car that computes the watts as a function of speed. I programmed this model into OBDZero. It is a textbook model that includes rolling resistance, air resistance and auxiliary watts. Auxiliary watts is e.g. heating. With this, the app finds a speed that gives the same kWh as that remaining in the battery. Here is the app screen.



At the start of a trip I enter the top number, the distance to the next changing station. While driving, the app re-computes this distance based on speed and time. The second number is the difference between the RR and the distance to the station. This is a big help for me because I’m bad at doing arithmetic in my head. The bottom number is the speed the model computes. I call it the suggested speed. I have driven the suggested speed many times on many trips and it works. I have never seen the turtle while on the road. (But I have experimented with running the heater until the turtle appeared.)

A couple of years ago, it occurred to me that this Drive function could also compute the “hidden” speed behind the RR on the instrument panel. The next screen show the Drive function in this mode. When the distance to the next charging station is 0, the middle number is the RR. The bottom number is the model computed speed that will result in the true rest range agreeing with rest range computed by the car.



I’m rather proud that my 2011 CZero still shows more than 100 km when fully charged. But there is a natural explanation. We have only driven 35000km and even more important the “hidden” or suggested speed to begin with is always low 30 - 40 km/h. As soon as I get out on to the highway the RR drops quickly but the suggested speed increases. After some km on the highway the suggested speed and the car's average speed are more or less the same.

There are more details in the OBDZero user manual
https://obdzero.dk/wp-content/uploads/2 ... nual38.pdf

[OBDZero]

On March 13, 2023 I updated OBDZero to version 4.00. In this version there are 4 new screens:



The Ah screen is of particular interest because both the capacity and the present charge come from the BMU PID 762. The capacity is the same as that reported by CaniOn and EvBatMon. The present charge is new as far as I know. Together they permit computing a SoC that is a bit more precise than that reported directly by the car. This computed SoC is most similar to the SoC 1 reported by the car and shown in OBDZero. It is less similar to SoC 2 shown in OBDZero and reported as SoC by other apps. Knowing the BMU's Ah account makes a more accurate calibration of the battery amps measurement possible.

Se the manual at:
https://obdzero.dk/wp-content/uploads/2 ... nual38.pdf
for more details.

[OBDZero]

Computing the Amps to and from the Battery


This graph shows a slow charging of the battery in my CZero recorded a couple of months ago. The green line is the BMU’s present charge in amp hours (AhBMU) using data from PID 762. The red (AhCal) and blue (AhOrg) dotted lines are computed present charges in Ah based on the amps to and from the battery.

AhOrg is the accumulated Ah using this formula for the amps to and from the battery:
PID 373: (((D3 * 256) + D4) - 32768) * 0.01 = Pack Amps In

This formula was first published on the English language iMiev forum in 2012
https://myimiev.com/forum/viewtopic.php?p=4805#p4805

AhCal is the accumulated Ah using this formula:
PID 373: (((D3 * 256) + D4) - 32700) * 0.01 = Pack Amps In

To compute the accumulated Ah for the red and blue lines, I first computed the added Ah in each time step by multiplying the time step in hours with the average of the amps at the start and finish of the time step. Then I started both the red and the blue lines in the graph with the AhBMU start value of 7.8 Ah. Finally I added the step Ah to the previous sum of Ah for each step from 20:38:43 to 05:35:02. At 05:35:02 the BMU Ah was 38.2, AhOrg was 32.12 and AhCal was 38.19.

It is clear that the accumulated Ah based on the AhCal formula agrees much better with the BMU Ah. Therefore this is the formula for the battery amps that is used in OBDZero.

[OBDZero]

There are two SoCs reported by the car’s Battery Management Unit (BMU). These are the first and second bytes in PID 374 transmitted on the car’s CAN network. I call them SoC1 and SoC2 in the OBDZero app. They have slightly different values and functions. Having the information from the BMU PID 742 helped me to figuring out the difference between them.



This graph shows the 10 min pause in slow charging from the same session shown in the post above. The purpose of this pause is to measure the true SoC of the battery based on the 0 load battery voltage. Note that SoC1, the green line, hops up and down as the voltage drops to the 0 load voltage from the higher charging voltage. There is a natural delay due to the battery's capacitance. This means that SoC1 is adjusted by the BMU to the true SoC. At the same time the present charge, BMU Ah, first increases then decrease again. I believe this is in response to the changes in SoC1. During the pause the BMU fully charged capacity of 38.5 Ah does not change. Therefore the BMU computation is:
Present charge = SoC1 * capacity/100

For the first change in present charge: 27.3 = 71 * 38.5 /100
For the second change in present charge: 27 = 70 * 38.5 /100

The present charge doesn't follow the SoC1 precisely because of the limited resolution of the numbers and because the present charge is only recorded at 1 minute intervals.

Before and after the 10 min pause the BMU computes the present charge and the SoC1 based on the measured amps to and from the battery. In other words SoC1 depends on the BMU’s present charge most of the time. It is only during the 0 load pause that the reverse is true.

During the pause the blue line SoC2 doesn’t change. I believe that this is the SoC displayed on the instrument panel. If the SoC display did hop up and down as much as SoC1 it would be disconcerting.

[OBDZero]

Slow Charging the i-MiEV, CZero and iOn

Every time our cars are slow charged from SoC less than SoC 24% to 100% the battery capacity is measure by the BMU. Here is a detailed description of the process based on a slow charge I recorded a month ago.


Slow Charge May 2023

To start with here are some definitions.
Cap1 is the capacity reported by CaniOn and EVBatMon. OBDZero reports it as the Battery Management Unit (BMU) capacity. Ah1 is the present charge in Ah in the battery corresponding to Cap1. OBDZero and EVBatMon reports this but not CaniOn. SoC1 is the State of Charge equal to 100 * Ah1/Cap1. SoC1 is reported by EVBatMon as SoC. It is reported by OBDZero as SoC1. CaniOn does not report it. Range is computed using Cap1, Ah1 and SoC1.

Cap2 is a second capacity computed by the BMU. It isn’t reported by CaniOn or EVBatMon. It is reported by OBDZero as just the battery capacity. SoC2 is the SoC reported by CaniOn but not EVBatMon. It is reported in OBDZero as SoC2. Ah2 is the present charge in the battery corresponding to Cap2. It can be computed by
Ah2 = SoC2 *Cap2/100. I have not found a PID containing Ah2 but I’m fairly sure that the BMU keeps an account of Ah2. In this case I have computed Ah2 based on the measured amps to the battery. This is called Coulomb counting.

Now the slow charge data
During the slow charge show in the graph above and before SoC1 reached 28 %, Ah1 and Ah2 increased by Coulomb counting by the BMU. The BMU computes SoC1 and SoC2 according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2
Cap1 was 38.3 Ah and Cap2 was 38 Ah.

On this day the charging pause that we often see at about SoC 30% began when SoC1 was 28%. Looking at other slow charges the pause can begin between 24% and 37%. It appears that the trigger is not the SoC but a battery voltage of about 339 V while charging.



During the pause shown here between 105 minutes and 120 minutes, charging stopped and the amps went from about 5 down to about -0.5. While the current was low, the BMU measured the open circuit voltage (Voc) and computed the true SoC of the battery. SoC1 is adjusted to the true SoC using a simple function such as:
SoC1 = a* Voc + b
The factors a and b are specific to the LEV50(N) cell but I don’t know what they are yet.
Cap1 didn’t change and Ah1 was updated according to:
Ah1 = SoC1 * Cap1/100
In this case SoC1 was 29.5 % when the pause ended and
Ah1 = 29.5 * 38.3 / 100 = 11.3 Ah
Studying other slow charges, SoC1 varied between 29 % and 32 % at the end of the pause.

Ah2 continued to increase by Coulomb counting but changed only slightly because the current from the battery was very small. Cap2 didn’t change and
SoC2 = 100 * Ah2 / Cap2

Other things like cell balancing may occur during the pause but I believe the primary purpose of the pause is to measure Voc and compute the true SoC of the battery.

After 15 minutes charging resumed and both Ah1 and Ah2 increased by Coulomb counting as before the pause. The BMU also computed the SoCs as before:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2



During the pause shown here between 105 minutes and 120 minutes, charging stopped and the amps went from about 5 down to about -0.5. While the current was low, the BMU measured the open circuit voltage (Voc) and computed the true SoC of the battery. SoC1 is adjusted to the true SoC using a simple function such as:
SoC1 = a* Voc + b
The factors a and b are specific to the LEV50(N) cell but I don’t know what they are yet.
Cap1 didn’t change and Ah1 was updated according to:
Ah1 = SoC1 * Cap1/100
In this case SoC1 was 29.5 % when the pause ended and
Ah1 = 29.5 * 38.3 / 100 = 11.3 Ah
Studying other slow charges, SoC1 varied between 29 % and 32 % at the end of the pause.

Ah2 continued to increase by Coulomb counting but changed only slightly because the current from the battery was very small. Cap2 didn’t change and
SoC2 = 100 * Ah2 / Cap2

Other things like cell balancing may occur during the pause but I believe the primary purpose of the pause is to measure Voc and compute the true SoC of the battery.

After 15 minutes charging resumed and both Ah1 and Ah2 increased by Coulomb counting as before the pause. The BMU also computed the SoCs as before:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2



At 379 minutes shown in the graph above SoC1 was 89%. Both Ah2 and Cap2 were updated. Cap2
decreased from 38 Ah to 37 Ah and Ah2 was set equal to Ah2
Then SoC2 was updated according to the new values for Ah2 and Cap2.
SoC2 = 100 *Ah2 / Cap2
In this case SoC2, the light blue line, increased from 88 to 92.5%
At the same time, there were no changes in Cap1, SoC1 or Ah1.

This update always occurs when SoC1 is 89% during a slow charge. However, the changes in SoC2 and Cap2 are often too small to see.

After that, Ah1 and Ah2 were equal and both increased by Coulomb counting. SoC1 and SoC2 were computed by the BMU according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2

When SoC2 reached 100% at 461 minutes, it stopped increasing but Ah2 continued to increase due to Coulomb counting. Ah1 also increased by Coulomb counting and Ah1 and Ah2 were still equal. SoC1 also continued to increase beyond 100% according to
SoC1 = 100 * Ah1/Cap1.



When balancing of the cells finished at 461 minutes, charging stopped. However the capacity measurement wasn’t complete. All PIDs continued to flow on the CAN network for another 15 minutes. Ah2 decreased due to Coulomb counting but only slightly because the current from the battery was very small. During this time the BMU was busy completing the measurement. Among other things, Cap2 increased slowly from 37 to 39 Ah in order to match Ah2. I don’t know why Cap2 didn’t change immediately to Ah2 but instead increased slowly over more than 15 minutes. The change in Cap2 occurred before data stopped but my app didn’t record this change until 558 minutes, when I turned the car on and full data transmission resumed. By this time Ah2 and SoC2 had also been updated and
SoC2 = 100 * Ah2 / Cap2


During the period from 476 minutes and 558 minutes there were only 4 PIDs transmitted on the network at 1 minute intervals. These didn’t contain data related to the charging process. The reason for the 82 minute gap was that full data transmission stopped at 6 o’clock in the morning. It took me 82 minutes to wake up, drink a cup of tea and then go out to the car and turn it on. When I turned on the car, all PIDs became available on the CAN network again.



This graph shows Ah1, SoC1 and Cap1 over the same period as the previous graph. During the 15 min after charging at 461 minutes and until data transmission stopped at 476 minutes the current was about -0.5 amps, the BMU measured the Voc and computed SoC1 according to:
SoC1 = c*Voc + d
Like a and b above c and d are specific to the LEV50(N) cell and I don’t know what they are yet.
Cap1 doesn’t change and Ah1 is computed from SoC1 and Cap1.
Ah1 = SoC1 *Cap1 /100

When full data transmission restarted at 558 minutes, both Cap1 and Ah1 had been updated. Cap1 increased from 38.3 Ah to 39.3 Ah, a 1 Ah hop.

How the new capacity was computed
I believe the measured capacity was computed based on SoC1 and Ah2 at the end of the pause at 100% shown above and Ah1 and SoC1 at the end of the 30% pause shown in the second graph from the top. This next equation is the simplest way to compute the capacity:

Capacity = 100 * (Ah2_100 – Ah1_30) / ( SoC1_100 – SoC1_30)
Capacity = 100 * (39.1 – 11.3) / (99.5 - 29.5) = 39.7 Ah

The reason Ah2_100 was used rather than Ah1_100 is that Ah1_100 was updated with the measurement of Voc. On the other hand Ah2_100 wasn’t updated and Ah2 _100 minus Ah1_30 was the actual number of Ah added between the SoC 30% and 100%. At the same time SoC1_100 – SoC1_30 was the true change in the SoC between 30% and 100%. Dividing the true change in the Ah with the true change in the SoC and multiplying by 100 gives 39.7 Ah, the measured capacity. This is greater than 39.3 Ah, Cap1 after being updated. I believe the BMU limits increases in the capacity to 1 Ah. Therefore Cap1 only increased from 38.3 to 39.3. This limit prevents possible errors in the measurement from causing wild changes in the capacity.

After 476 minutes, the measurement was complete. From then on, Ah1 and Ah2 were equal and they decreased by Coulomb counting. SoC1 and SoC2 were computed according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2

I don’t know why this process is so complicated. If the only objective was to measure the capacity then it could be much simpler. One secondary objective could be to have a SoC, in this case SoC2, that doesn’t exceed 100%. This then would be the SoC displayed on the left hand side of the instrument panel.

Cheers
David

[OBDZero]

I'm posting this again because there were a number of errors in the original post. Is it possible to for me to edit my posts?


Slow Charging the i-MiEV, CZero and iOn

Every time our cars are slow charged from SoC less than SoC 24% to 100% the battery capacity is measure by the BMU. Here is a detailed description of the process based on a slow charge I recorded a month ago.


Slow Charge May 2023

To start with here are some definitions.
Cap1 is the capacity reported by CaniOn and EVBatMon. OBDZero reports it as the Battery Management Unit (BMU) capacity. Ah1 is the present charge in Ah in the battery corresponding to Cap1. OBDZero and EVBatMon reports this but not CaniOn. SoC1 is the State of Charge equal to 100 * Ah1/Cap1. SoC1 is reported by EVBatMon as SoC. It is reported by OBDZero as SoC1. CaniOn does not report it. Range is computed using Cap1, Ah1 and SoC1.

Cap2 is a second capacity computed by the BMU. It isn’t reported by CaniOn or EVBatMon. It is reported by OBDZero as just the battery capacity. SoC2 is the SoC reported by CaniOn but not EVBatMon. It is reported in OBDZero as SoC2. Ah2 is the present charge in the battery corresponding to Cap2. It can be computed by
Ah2 = SoC2 *Cap2/100.
I have not found a PID containing Ah2 but I’m fairly sure that the BMU keeps an account of Ah2. In this case I have computed Ah2 based on the measured amps to the battery. This is called Coulomb counting.

Now the slow charge data
During the slow charge show in the graph above and before SoC1 reached 28 %, Ah1 and Ah2 increased by Coulomb counting by the BMU. The BMU computes SoC1 and SoC2 according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2
Cap1 was 38.3 Ah and Cap2 was 38 Ah.

On this day the charging pause that we often see at about SoC 30% began when SoC1 was 28%. Looking at other slow charges the pause can begin between 24% and 37%. It appears that the trigger is not the SoC but a battery voltage of about 339 V while charging.



During the pause shown here between 105 minutes and 120 minutes, charging stopped and the amps went from about 5 down to about -0.5. While the current was low, the BMU measured the open circuit voltage (Voc) and computed the true SoC of the battery. SoC1 is adjusted to the true SoC using a simple function such as:
SoC1 = a* Voc + b
The factors a and b are specific to the LEV50(N) cell but I don’t know what they are yet.
Cap1 didn’t change and Ah1 was updated according to:
Ah1 = SoC1 * Cap1/100
In this case SoC1 was 29.5 % when the pause ended and
Ah1 = 29.5 * 38.3 / 100 = 11.3 Ah
Studying other slow charges, SoC1 varied between 29 % and 32 % at the end of the pause.

Ah2 decreased by Coulomb counting but changed only slightly because the current from the battery was very small. Cap2 didn’t change and
SoC2 = 100 * Ah2 / Cap2

Other things like cell balancing may occur during the pause but I believe the primary purpose of the pause is to measure Voc and compute the true SoC of the battery.

After 15 minutes charging resumed and both Ah1 and Ah2 increased by Coulomb counting as before the pause. The BMU also computed the SoCs as before:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2



At 379 minutes shown in the graph above SoC1 was 89%. Both Ah2 and Cap2 were updated. Cap2
decreased from 38 Ah to 37 Ah and Ah2 was set equal to Ah2
Then SoC2 was updated according to the new values for Ah2 and Cap2.
SoC2 = 100 *Ah2 / Cap2
In this case SoC2, the light blue line, increased from 88 to 92.5%
At the same time, there were no changes in Cap1, SoC1 or Ah1.

This update always occurs when SoC1 is 89% during a slow charge. However, the changes in SoC2 and Cap2 are often too small to see.

After that, Ah1 and Ah2 were equal and both increased by Coulomb counting. SoC1 and SoC2 were computed by the BMU according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2



When SoC2 reached 100% at 461 minutes, it stopped increasing but Ah2 continued to increase due to Coulomb counting. Ah1 also increased by Coulomb counting and Ah1 and Ah2 were still equal. SoC1 also continued to increase beyond 100% according to
SoC1 = 100 * Ah1/Cap1.



When balancing of the cells finished at 461 minutes, charging stopped. However the capacity measurement wasn’t complete. All PIDs continued to flow on the CAN network for another 15 minutes. Ah2 decreased due to Coulomb counting but only slightly because the current from the battery was very small. During this time the BMU was busy completing the measurement. Among other things, Cap2 increased slowly from 37 to 39 Ah in order to match Ah2. I don’t know why Cap2 didn’t change immediately to Ah2 but instead increased slowly over 15 minutes. The change in Cap2 occurred before data stopped but my app didn’t record this change until 558 minutes, when I turned the car on and full data transmission resumed. By this time Ah2 and SoC2 had also been updated and
SoC2 = 100 * Ah2 / Cap2

During the period from 476 minutes and 558 minutes there were only 4 PIDs transmitted on the network at 1 minute intervals. These didn’t contain data related to the charging process. The reason for the 82 minute gap was that full data transmission stopped at 6 o’clock in the morning. It took me 82 minutes to wake up, drink a cup of tea and then go out to the car and turn it on. When I turned on the car, all PIDs became available on the CAN network again.



This graph shows Ah1, SoC1 and Cap1 over the same period as the previous graph. During the 15 min after charging at 461 minutes and until data transmission stopped at 476 minutes the current was about -0.5 amps, the BMU measured the Voc and computed SoC1 according to:
SoC1 = c*Voc + d
Like a and b above c and d are specific to the LEV50(N) cell and I don’t know what they are yet.
Cap1 doesn’t change and Ah1 is computed from SoC1 and Cap1.
Ah1 = SoC1 *Cap1 /100

When full data transmission restarted at 558 minutes, both Cap1 and Ah1 had been updated. Cap1 increased from 38.3 Ah to 39.3 Ah, a 1 Ah hop.

How the new capacity was computed
I believe the measured capacity was computed based on SoC1 and Ah2 at the end of the pause at 100% shown above and Ah1 and SoC1 at the end of the 30% pause shown in the second graph from the top. This next equation is the simplest way to compute the capacity:

Capacity = 100 * (Ah2_100 – Ah1_30) / ( SoC1_100 – SoC1_30)
Capacity = 100 * (39.1 – 11.3) / (99.5 - 29.5) = 39.7 Ah

The reason Ah2_100 was used rather than Ah1_100 is that Ah1_100 was updated with the measurement of Voc. On the other hand Ah2_100 wasn’t updated and Ah2 _100 minus Ah1_30 was the actual number of Ah added between the SoC 30% and 100%. At the same time SoC1_100 – SoC1_30 was the true change in the SoC between 30% and 100%. Dividing the true change in the Ah with the true change in the SoC and multiplying by 100 gives 39.7 Ah, the measured capacity. This is greater than 39.3 Ah, Cap1 after being updated. I believe the BMU limits increases in the capacity to 1 Ah. Therefore Cap1 only increased from 38.3 to 39.3. This limit prevents possible errors in the measurement from causing wild changes in the capacity.

After 476 minutes, the measurement was complete. From then on, Ah1 and Ah2 were equal and they decreased by Coulomb counting. SoC1 and SoC2 were computed according to:
SoC1 = 100 * Ah1 / Cap1
SoC2 = 100 * Ah2 / Cap2

I don’t know why this process is so complicated. If the only objective was to measure the capacity then it could be much simpler. One secondary objective could be to have a SoC, in this case SoC2, that doesn’t exceed 100%. This then would be the SoC displayed on the left hand side of the instrument panel.

David

[roger north]

Slow Charging the i-MiEV, CZero and iOn

Every time our cars are slow charged from SoC less than SoC 24% to 100% the battery capacity is measure by the BMU. Here is a detailed description of the process based on a slow charge I recorded a month ago.

hi
i have used the cap2 calculation in your app for my battery, it measure about 45Ah Bj2016 / 26000km
here the result
viewtopic.php?p=2092056#p2092056

but the bms capacity does not goes up, i have now tryed to recalibrate after 1200km
dischareged to 0 bars and 2km left range
slow charge AC 8A to full over night
interesting was it has the pause not at around 30% but at 70%
the Ah still the same 42,4

last recalibration was from 41,6 to 42,6Ah with the same 8a slow charge
i dont know how this works on the bms, when it will recalibrate at 1000km or 2000? is the low charging power important or can i charge it full power at AC 14A for recalibration

i also purchased hobdrive there is a function capacity measure, but i dont know how it works and the developer cant or dont want to explain me how this works.
do you know hobdrive and this feature?

at last, can you update your app to support landscape mode display because it is runing on my cars android head unit and wont display the parameters well on the rotated screen.

thanks for your fantastic work