Replacing the VW BMU aka implementing high level BMS functions

[johu]

Now I'm using the VW battery modules together with their cell management units. They provide me with per cell voltage and per module temperature and allow me to dissipate energy from cells for balancing.

The BMU however I won't be using for the time being because it uses 2 MBIt CAN and I don't feel like reverse engineering it.

So all the high level BMS stuff has to be replicated in my VCU aka stm32-car https://github.com/jsphuebner/stm32-car/tree/touran-meb

Now for me one of the most critical parts is the charge curve. I think manufacturers spend a lot of time tuning them in a way that you have good charge speed and longevity. So I want to mimic as closely as possible what VW does.

So I went on the internet and searched for Björn Nyland recording a charge session of an ID.3 with the 62 kWh battery.

Then I wrote down the voltage and current curves and also tried to work out the internal resistance of the entire system by using the current step at the beginning of the charging session.

With that done I arrived at this:

It may not immediately jump out from the curve but it does when looking at the raw data: It seems like they are running 2 3 subsequent CC-CV curves.

The first: CC=310A, CV=3.93V (per cell). In the recorded session that runs to 50%.
The second CC=170A, CV=4.03V (60-70%)
The third: CC=114A, CV=4.25V - yes they actually go above 4.2V, 459V on the charger display and it is a 108S pack
In the session that started at 70% till 100%

From 3.93V to 4.03V they seem to run some A/mV profile that starts at 170A (cutoff of first CV) and ends up at 114A (CC2).
By using a P-controller only the CV point is very soft and approached linearly.

At least that's how I interpret it and programmed it. I like making it all cell voltage rather than SoC dependent because in the latter case errors in SoC calculation could screw up the charge curve.

I have no data on temperature derating but I'm thinking this ideal charge curve would start at 20°C and end at 40°C. Outside that window I plan to derate the CC values. Most of all it should stop charging before 45°C because arber says that's where the cells behave unsound.

Will probably linearly ramp down the power to 50%@0°C. And below - I don't know.

Any input appreciated

[johu]

And here is the code I'm currently running. I've tested it with a "battery model" and results look sane.

https://github.com/jsphuebner/stm32-car ... mebbms.cpp

When comparing with the stock curve be aware the x-axis is time scaled

I have also implemented low and high temperature derating, here is a charge session starting with a 15°C cold battery

The CC phase starts lower than normal and ramps up as the battery self-heats

And here is a charge session that overheats towards the end

My battery model uses a constant internal resistance, so it won't behave that way with the actual battery. Also no cooling is simulated

[Aragorn]

I'll try to remember to pull some data points from CarScanner for you. This is an older screenshot in my phone:

Hopefully you can cross reference these with your model and see that it lines up somewhat sensibly.

[johu]

Thanks, yes more of that

The Nyland curve is 220A @ 35% or 204A@40%. Seems like there is not much derating at 8°C. Unless of course it goes down once you actually start charging. This could be the regen limit, right?

[Aragorn]

Yeah that is in "drive" mode, not sure if it would then apply different limits when charging vs regen.

I've seen one log taken during a rapid charge (from someone elses car) where it was showing 80A on a warm battery, with the charger churning along at 37kw, but that felt like it was showing the charger limit or something, because theres no reason i could see for it showing that low a value. The battery was over 20c and the SOC was low enough that it should have been doing 100kw+. As soon as it was unplugged it jumped back up to over 200A.

My own car only has the "50kw" charging option as i didnt pay the extra to unlock the full 120kw, so not sure what mine would show when charging.

I will try to get some more points on the curve and also see if i can get some at much lower temperatures once the weather cools.

[johu]

While we wait for that next up is SoC estimation.So whenever the pack has been unloaded (say less than 1A current) I want to derive the state of charge from the idle voltage of the lowest cell. So I need a voltage->SoC curve for those cells. Anyone know where to find it?

Right now I use the Nyland derived values:

Code: Select all

const uint16_t socCurve[] =
{  /* 0%   5%   10%   15%   20%   25%   30%   35%   40%   45%   50%   55%   60%   65%   70%   75%   80%   85%   90%   95%  100%*/
   3380, 3426, 3547, 3622, 3671, 3694, 3703, 3719, 3734, 3757, 3777, 3808, 3848, 3890, 3931, 3977, 4033, 4082, 4120, 4168, 4200
};

But that will hardly be very accurate.

[Aragorn]

We can probably pull similar data from Carscanner as a cross reference, a different page can show us SOC and cell voltages (though for this particular screenshot i dont know if the battery was fully unloaded):

Two snaps from yesterday before leaving work and after getting home, bit warmer though so not giving us much data for low temps:

[johu]

I found a curve for NCM712 chemistry which apparently the MEB cells are.

It is not open circuit though... Loaded with 0.2C

Surprised to see these can go to 4.4V. Explains why it is allowed to reach 4.25V in the charge session (and then still has a top buffer)

[johu]

And next up is the "state of energy" or SoE. SoE as opposed to SoC takes the cell voltage into account. The upper 50% SoC contain more energy than the lower 50%. The voltage is then lower and the inverter will draw more amps for the same torque request.
Some cars only display SoC and even base the range estimate on it. Then you're in for a surprise when SoC drops much quicker at the low end.

I graphed it here:

grafik.png (9.67 KiB) Viewed 2548 times

Basically made 5% segments and calculated the energy left in the middle of that segment. That is then divided by the total energy.

For both SoC and SoE to make sense the actual capacity of the worst cell must be known. So that is up next

[johu]

Today I took the battery a little lower and I found the drop from 3.8V to 3.7V is rather steep. This step isn't represented in my SoC table so SoC I think is now estimated much too low. In my table 3.7V corresponds to just 30%. I think I will discharge as low as possible and then recharge like 5 Ah at a time, pause 5 minutes, take an cell voltage reading, and continue with the next 5Ah.

[tom91]

So the VW MEB LG cells are E78 cells. which is the same family as the E61V, made in the same factory.
https://gosavetime.com/specifications-l ... l-lg-chem/

https://www.lgensol.com/assets/file/LGE ... s_2022.pdf

https://www.batemo.com/products/batemo- ... chem-e61v/

giving you this curve

[johu]

Thanks! At the end of this video I found the result of a test


Put it in a spreadsheet

Code: Select all

const uint16_t vtgToSoc[] =
{/*2.80V  2.85  2.90  2.95  3.00  3.05 3.10  3.15  3.20  3.25  3.30  3.35  3.40  3.45  3.50  3.55  3.60  3.65  3.70  3.75  3.80  3.85  3.90  3.95  4.00  4.05  4.10  4.15  4.20 */
   0,     12,   31,   55,   80,   116,	153,	202,	239,	325,	496,	701,	1231,	1794,	2307,	3368,	4388,	5368,	5949,	6326,	6742,	7232,	7708,	8104,	8575,	8996,	9446,	9753,	10000
};

[rstevens81]

You really going to go all out with 4.2v/cell seems quite a bit more than the 4.1v we are used to but I guess if the OEM does it it's probably ok Not sure I would want to push it that far daily.

[johu]

No, not daily but the lookup table needs to map it correctly. Normally I limit to 80% or 3.95V

New SoC and SoE curve

[jrbe]

Are you doing anything to track degradation?

I just found this,
https://pubs.rsc.org/en/content/article ... d2cp00417h

Gets interesting around 4.1
PyBamm mentioned there is interesting too.

[johu]

Still on my todo list. Will study that. At first approach I was going to track the difference between Ah counting and voltage to SoC curve

[rstevens81]

I would, keep things simple and not bother with degregagtion calculation all you really want is soc calculation based on resting voltage and have a fall back where ah are used when voltage isn't possible e.g. motorway drive. a variable for battery ah is all that is needed and as we can record ah used (from shunt) this value can be manually updated every few years or so

[johu]

I guess you're right, will bring it out as a parameter that I can adjust with experience.

Will probably implement the extrapolation also strictly informative. It's not hard if you remember at which estimated SoC you started (dis)charging, at which estimated SoC you stopped and what the reported Ah are in comparison.

Edit: here's what I do after 2 minutes current < 1A

Code: Select all

      int32_t as = isa->GetValue(IsaShunt::AS);

      if (ABS(as) > 36000) //more than 10Ah difference
      {
         float estimatedAs = mebBms->EstimateSocFromVoltage() - estimatedSoc; //Calculate difference in percent to last estimation
         estimatedAs = ABS(estimatedAs); //only the absolute value is of interest
         estimatedAs*= mebBms->GetMaximumAmpHours(); //multiply with supposedly available amp hours
         estimatedAs/= 3600.0f / 100; //multiply by 3600 (Ah to As) and divide by 100 because percent
         float soh = ABS(as) / estimatedAs;
         Param::SetFloat(Param::soh, soh * 100);
      }

[johu]

The SoC table is still inaccurate. Probably because the table from the video is taken under load 8A/0.1C. So SoC estimation is always to high, depending on the slop the error can be over 10%! Certainly need to fix this.
I think I'll make a new curve with the remaining module. Empty it, charge 5 Ah, wait 5 min., take voltage reading, charge 5 Ah,...