Honda Insight Forum banner
581 - 600 of 798 Posts

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #581 · (Edited)
Post:
It took a bunch of work to determine the relative capacity of each cell in @mmdepace 's car.
To make this process easier, I'm going to add the following feature to the firmware (pseudocode):
Code:
uint16_t cellBalanceTimer_seconds[NUMCELLS]=0;
uint8_t balancingComplete = false;

if( gridChargerJustPluggedIn ) { clear cellBalanceTimer_seconds(); balancingComplete = false; } //set all array elements to zero

if( balancingFinished ) { balancingComplete = true; } //the first time balancing finishes, we stop accumulating the cell timers

if( hasOneSecondPassed && (balancingComplete == FALSE) ) {
   for(cellNumber=1; cellNumber<NUMCELLS; cellNumber++) {
      if(cellStatus[cellNumber] == BALANCING) { cellBalanceTimer_seconds[cellNumber]++; }
}}
This will give us a QTY48 element array, where each element is the number of seconds cell N has spent discharging during the latest grid charge event.

LiBCM can then display this data to the user. Assuming the pack was initially balanced at 75% SoC:
-if all cells are similar, then all array elements should have similar values (ideally they would all be 0).
-cells with less capacity will self-discharge more (at rest, at idle etc).
-cells with more capacity will span a narrower voltage range (compared to cells with less capacity).
-The absolute value stored for each cell in the cellBalanceTimer_seconds array isn't important, but the difference between the various cells is.
-Outlier cells (i.e. that spend more or less time balancing) are suspect.
-a weaker cell will tend to self-discharge more often than healthy cells. Since healthy cells won't lose this energy (through self-discharge), they'll spend more time balancing. Therefore, weaker cells will likely tend to have lower stored values in the cellBalanceTimer_seconds array.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #583 ·
OK, I've now spent the evening theorizing and supporting LiBCM... when I really should have been finishing up this other project. I'm super excited to get back to LiBCM, but for now I need to work on other things.

I'll continue supporting @BLS 's issue - so he can get up and running - but for now I need to sideline the cell balancing discussion. @mmdepace please feel free to continue supplying data and/or responding to my posts, but I really need to focus my effort elsewhere for the next couple days.

I'm super excited to get back into LiBCM firmware... later.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #584 ·
I will get in contact with a colleague who has an oscilloscope tomorrow.
See if they have a differential probe. If not, QTY2 standard (single-ended) probes will also work.
The goal is to measure the differential voltage across the MCM'E' connector. This isn't a DC signal, hence we can't just use a DMM.

If you can't get an oscilloscope, we can just try swapping the MCM out.

I do not currently (have a spare MCM).
PM me your address and I'll send you a known-good MCM...
...you'll need to send it back eventually.
 

·
Registered
Joined
·
223 Posts
Wow, thank you for this analysis. Very cool. I couldn't even get the data converted to a .csv this morning during a brief try at my desk.

I remember the calpod switch - background charge issue now that you have reminded. This makes sense.
I idle for an hour/day during lunch hour when in town. This won't be a concern if continuing to grid charge each night and/or after the future firmware update as mentioned.

I would like to begin gathering this data, but am hesitant to not grid charge each night in this heat. I try not to regen during the evening commute due to the battery will begin at over 40C every day when leaving work. Many crazier t=0 battery temperatures on the way soon, lasting until September. The amount of strong regen needed to overcome the A/C compressor drag in this Indy-500-like evening rush hour traffic is likely much harsher on the battery than the cool AM non-A/C datapoints provided, if I had to predict.

Arizona is definitely a corner case climate. Through two-years of reading lithium threads, I'm prepared for any outcomes this unique climate may throw my (battery's) way. The Gen1 Nissan Leaf failed miserably here. I decided that it was okay if the first battery cooks over the summer. Reason I mention this is becuase the delta was less than half, a month ago. If there is a threshold where it becomes dangerous, then I will abort if advised.

I want to gather this data, but maybe I should try to "nurse" the battery for the next 4 months of consecutive 105, 110, 115F+ temperatures (grid charge, limit regen). I've been trying to figure out a way to conrtibute something on this expert-rich board for a couple of years, now I have an opportunity to do the tiniest thing - grab some data, but am hesitant for the battery's sake, in light of possible first signs of degradation.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #586 · (Edited)
FYI: The EHW5 is rated to operate at up to 55 degC (60 degC storage). However, operating at higher temperatures is going to reduce their overall lifetime; Honda doesn't specify by how much, but I suspect that they should last a long time when used within the specified temperature range.

I wouldn't worry about 40 degC. Maybe when the pack is above 50 degC I'd limit assist/regen; certainly I'd turn Calpod on at 55 degC.

Based on the pictures you posted, it looks like your cabin air temp is able to drastically cool off the modules in just a few minutes. So maybe limit assist and regen for the first few minutes after you turn the car on?

Also, these batteries basically don't self-heat under load... so you don't need to worry about assist/regen further raising the temperatures.

...

You aren't going to additionally harm the cells simply by having a delta mismatch between them... so long as the min and max cell voltage stays within the limits printed on the 4x20 display, there's no additional risk... So even with a 90 mV delta, that's just going to mean you have less total power available.

If my theory is correct, then your voltage delta isn't actually going to get anywhere near 100 mV (where I proposed ending the test). I'm really interested to see if the resting delta gets worse as SoC decreases, but then gets better again (without balancing) when SoC increases. I think that'll happen, based on the above posts.

...

I certainly intend for LiBCM to "just work" even in Phoenix in the dead of summer. I think the primary issue is that in v0.7.5 LiBCM is blindly sucking in hot cabin air while cell balancing... whereas in v0.7.6 LiBCM won't turn the fans on (to balance cells) when they're above 35 degC.

...

In regards to the Nissan Leaf cells, the G1 and G2 cells had a terrible chemistry that was extraordinarily affected by temperature. Nissan didn't do themselves any favors by not having any cooling system whatsoever.

I've had QTY24 G2 Leaf modules for around 7 years now. When I first got them they were around 58 Ah per module (about 87% of new). I just performed my annual rundown test on them last week; they're down to 35 Ah (about 53% of new).

That mean these 197 pounds of Leaf modules I have are only storing 6.2 kWh (usable).
For reference, the 47 Ah FoMoCo modules I'm going to design into LiBCM weigh 104 pounds and store 6.3 kWh (usable)... so these (old) Leaf modules have half the energy density.
 

·
Registered
Joined
·
223 Posts
I definitely can pump cold air in, but it's actual effect on lowering the internal temperature of 9 hours of heat soaking the batteries, I'm not sure. I suspect they are hottest an hour after I get home - just a guess.

Let's begin grabbing data after the future firmware which modifies LiBCM to MCM current resolution. I will lose 20% SOC on lunch hour in the meantime (no big deal at all). It will be a happy-medium in needing to regen on the way home. For now, I will probably begin PM commute in the mid 40's SOC. After this update, likely can leave work in the mid 60's and still prevent as much regen as possible on the way home, while monitoring cell delta.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #588 ·
If you'd rather LiBCM caused the MCM to background charge the batteries (like it used to):
adc.cpp, line 72:
latest_battCurrent_amps = ((int16_t)((((uint16_t)latest_battCurrent_counts) * 55) >> 8)) - 71; //slow background charge (until full)
latest_battCurrent_amps = ((int16_t)((((uint16_t)latest_battCurrent_counts) * 55) >> 8)) - 72; //slow background discharge (until empty)
 

·
Administrator
Joined
·
13,900 Posts
You seem to be saying 'weaker' cells self discharge more? Source/info??
Weaker, do you mean less capacity, higher IR, higher self discharge or something else..
 

·
Registered
Joined
·
223 Posts
I did not grid charge last night. I regen-charged all the way to work this morning.

t=0 SOC23 d0.007
t=1565 SOC61 d0.007 <- arrival at work
t=1826 SOC53 d0.006 <- arrival back home

Thank you for the adc.cpp, line 72. I will use have now re-implemented this.
Glad to learn that in the event of an increasing delta, the system remains safe.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #591 ·
You seem to be saying 'weaker' cells self discharge more? Source/info??
Weaker, do you mean less capacity, higher IR, higher self discharge or something else..
From what I've read:
-unloaded weaker cells tend to self discharge more than healthy cells, due to the molecular chaos that develops inside the cells over time.
-loaded weaker cells tend to discharge more than healthy cells, due to higher ESR.

"weaker" means less capacity, which can be due to:
-higher ESR,
-higher self discharge
-other things, too... basically any cell that has less energy available than the others
 

·
Registered
Joined
·
88 Posts
I'm charging my LiBCM pack and I'm getting some odd behavior. When I plugged in, it was at about 65% charge. The charge started to slowly climb, then peaked slightly below CELL_VMAX_GRIDCHARGER (I changed it from 39000 to 39100.) Now, even though it's still plugged into the charger, the charge is not going up. In fact, it's falling slightly. I looked at the code in cellBalance.cpp and I don't see how this can be happening. Logs attached.

[Edit]
Okay, just to make me look bad, right after I posted this, the charge started climbing. Now it's at 75% and slightly over 3.900 volts. This is good, but now I'm flummoxed. I don't like being flummoxed.
 

Attachments

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #593 ·
There's a small hysteresis to prevent the grid charger from rapidly turning on and off when the batteries are full. I believe it's something like "stop at 75%, start again at 70%".
 

·
Registered
Joined
·
88 Posts
There's a small hysteresis to prevent the grid charger from rapidly turning on and off when the batteries are full. I believe it's something like "stop at 75%, start again at 70%".
Hmm... I'll have to look at that code. The SoC was < 75% while this SoC was bouncing around.

The hysteresis code I was looking at is in cellBalance.cpp. Maybe I was barking up the wrong tree. Or not. If the lowest cell voltage was so low that all the other 47 cells needed to be balanced, would that take all the juice from the charger? IOW, would that lowest cell not move, and the overall pack voltage would go down while those high cells were bled? (I'm just thinking out loud.)

Bottom line, the SoC does not increase monotonically as long as it plugged in until it hits 75%. It bounces around a little. Now that I know this, I'm not going to worry about it anymore. It charges eventually, and it doesn't overcharge. That's all I care about. (But you've piqued my curiosity about the code the shuts off charging.)
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #595 ·
Cell balancing now runs separately from the grid charger. Each cell balancing resistor is 75 Ohms, so each cell can discharge at around 200 mW (at 3.9 volts). If QTY47 cells are discharging, that's 9.5 watts. In comparison, the lowest-end LiBCM grid charger (the once shipped to all Open Beta customers) can charge at up to 84 watts (with QTY48 cells charging at 3.9 volts per cell). LiBCM can control the output power to any value from 0 to 84 watts, in 330 mW steps.

The latest firmware can simultaneously discharge cells at full power, while also charging at full power. However, as soon as the first cell reaches the charge cutoff point, the grid charger is disabled, but cell balancing is still allowed. A future firmware update will allow LiBCM to ramp down charge power (instead of hard disabling).

The reason SoC "bounces" around while grid charging is that the SoC is updated periodically based on the resting cell voltage. So if the grid charger is charging and then a cell gets full... that's going to make the grid charger turn off, hence the cell voltages will drop slightly, which will cause the voltage-based-SoC estimate to decrease (because the voltage dropped)... this is why SoC tends to stay in the 70:75% range - not exactly 75% - while grid charging.

Future firmware updates will improve this behavior... for now just tolerate the few percent fluctuation. I have SOooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo much work to do before I get to this improvement.
 

·
Premium Member
Joined
·
1,341 Posts
I'm not sure whether to ask this question here, or on the OBDIIC&C support thread. . . ever since I installed LiBCM, I get the occasional random beep and flash of my red warning light from my OBDIIC&C guage. It is not a sustained beep or warning light. It lasts a millisecond and it seems completely random as to when it occurs. Is this an interference issue with LiBCM? I know positively that this wasn't occurring before I installed LiBCM.

Thanks,
Bryan
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #597 · (Edited)
Known issue. See Q10 & Q16 in the Troubleshooting FAQ. I should probably just go ahead and include the large ferrite with the LiBCM kit... it'll slightly increase the BOM cost, but should eliminate all known noise issues. In that regard, it's a no brainer: I just added it to the BOM! POOF, $1700 gone! $2500 gone! Gotta love hidden tariffs and other fees! However, it's nice when things are just... in stock.

...

Update: I finally got covid the for first time... it's not too bad, but I've been quite tired for several days now. Not trying to discredit its horrible world impact, but I'm doing mostly fine. This hasn't immediately impacted LiBCM progress, as I'm working on a different project right now... but since that project is going slower, it is pushing out the date where I return to LiBCM.

In other news, the PCBs should have arrived today, but they're held up in Alaskan customs... no ETA yet... which again, is just fine, because I won't be finished with this other project for several more days.

I love having a large engineering team to accelerate product development, but unfortunately LiBCM isn't nearly a large enough project to justify an R&D budget.
 

·
Linsight Designer
Joined
·
3,904 Posts
Discussion Starter · #598 ·
THIS MESSAGE DOESN'T APPLY to those who have already submitted an LiBCM purchase form (either DIY or Certified Installer). You are already "on the list".

...

Right now I only have enough parts to accept QTY43 more LiBCM orders. After that, I will not be able to ship more units until I receive more LTC6820 ICs. I don't know when that will happen. This part is in high demand because it's used in nearly all electric/hybrid vehicles... no surprise, then, that it's out of stock everywhere.

FYI: This is the only part that I'm missing. Once it arrives, I'll have the parts to ship QTY250 total LiBCM units.

...

Possible methods to source additional LTC6820 ICs:
-The backorder I placed last June(?) was supposed to arrive "2021Q3" ...maybe it'll show up eventually?
-I've placed five different backorders (from Digikey, Mouser, Verical, Arrow, and even directly from Analog Devices)... if they all do eventually show up, then I'll have QTY1000** (I only need QTY1 per LiBCM). The estimated delivery date for these orders ranges from "2022AUG" to "2023OCT".
[email protected] Dog (and @retepsnikrep IIRC) placed additional backorders last fall.
-The ($80) DC11941D development board is readily available, and contains a single ($5) LTC6820 IC. However, that will add considerable cost to LiBCM's final price tag.

The following methods to source additional LTC6820 ICs won't work:
-I purchased a few LTC6820 units from AliExpress and Ebay. They work on the bench, but who knows how they will hold up in the demanding automotive environment. Based on my experience, these are either counterfeit or factory rejects. I'm not comfortable installing them in shipping LiBCM units... the recall/RMA risk is just too high.
-MANY distributors list this part "in stock". However, after submitting a PO, they aren't actually available. Examples: Win Source, Jak, ZTZ, Cytech, Pneda, Shengyu, YIC, Extreme, etc... I've contacted every "in-stock" distributor shown on octopart.com.

If you want to try sourcing this IC, the following part numbers will work:
LTC6820HMS____
LTC6820IMS____

**I'm well aware that attempting to hoard more parts than I need is "part of the problem".

...

I'm not trying to cause an "LiBCM rush".
I'm just providing transparency.
The supply chain is ruined.
 
581 - 600 of 798 Posts
Top