Honda Insight Forum banner
881 - 900 of 948 Posts

·
Registered
Joined
·
1,286 Posts
I did not have LiBCM in my car long because of a short circuit, but I can say that it made it a different car.

And for the cells, the temperature rise data is wonderful news. I forgot to plug in the fan for a NiMH pack during a raid trip and it was not too long before I no longer had IMA. Having a cooler pack is great.

Therefore, I conservatively suspect these cells won't self-heat more than 20 degF during even the harshest regen/assist. That's favorable for hot climates, but less beneficial in cold ones.
It sounds like you found some manufacturer data. Do you have peak charge and discharge current versus temperature?
 
  • Like
Reactions: Natalya

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #882 · (Edited)
It sounds like you found some manufacturer data. Do you have peak charge and discharge current versus temperature?
Everything I've gathered in regards to these EHW5 modules is on github.

I don't have manufacturer's data versus temperature, but I did find the following general specs:
Recommended charge/assist current: 200 A
Maximum charge/assist current: 300 A
Power density: 4.9 kW/kg


LiBCM uses the pack well within this range...
...but it would be cool if we could get up to 300 A, which would be 52.6 kW** (71 horsepower).

**52.6 kW = (4.1volt - 1.5 mOhm * 300 A) * (48 cells) * (300 A)

Of course the IGBT driver would explode, the MCM would set the overcurrent flag, the stator would melt down, and in general you'd need a new IMA system... but we can dream, right?

...

I did not have LiBCM in my car long because of a short circuit, but I can say that it made it a different car.
Just to clarify for those that aren't living and breathing LiBCM:
The short circuit Sean mentioned occurred while connecting the BMS sense leads to an 18S module. It had nothing to do with LiBCM, per se, but we did learn that mating those connectors requires intense scrutiny... and should be done outside.
 

·
Premium Member
Southern California
Joined
·
899 Posts
-If enabled (by the user), LiBCM will attempt to heat the pack (using the onboard balancing resistors).
In my opinion, this will be so useless it's not even worth considering implementing it as a feature. :/
I don't remember the balance resistor value, but going off your 666Wh and 3 days of heating figures, that's about 10W. Pretty paltry on its own considering the mass of the cells, even if it were somehow 100% perfectly coupled to the cells.
The fact that all the balance resistors are on a separate PCB with no thermal coupling other than the ambient air and the plastic casing means all the heat will just radiate away. And of course the ESR and currents are so low that there will be insignificant self-heating.
I would wager that spending the entire 3 days running the balance resistors wouldn't raise the furthest cell's temperature by more than 2-3C, if that.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #884 ·
Yes, it's around 8 watts, which isn't much. I'm thinking the heat that escapes from the back of the PCB has to go somewhere, and it would rather go into the metal support around the modules than the thick plastic battery enclosure. It's not much, but I do think it's worth trying just to see... maybe before winter next year.

I was thinking about how putting an incandescent bulb underneath shop equipment that is then covered in a blanket will keep it from rusting... because it slightly elevates the metal's temperature above the condensation point.

Anywho, yes, you're probably correct that there would be at most a couple degC temp rise, which isn't worth the constant load on the battery. Maybe it would only be used if the grid charger was plugged in while out in the cold.
 

·
Premium Member
Joined
·
1,126 Posts
I'll defer to people that know more than me, but speaking as somebody in the upper Midwest, 3 degrees Celsius is significant when the outside temps are often -17 to -28 C in the winter.
 

·
Premium Member
Joined
·
2,142 Posts
Mudder will there be an option to disable the temperature thing? It never gets below 30F when I live.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #888 ·
Which specific temperature thing? I don't see any reason why you'd want/need to disable any specific temperature-controlled component... it'll only activate when the temperature threshold is crossed.
 

·
Premium Member
Joined
·
2,142 Posts
Yea that makes sense. Really excited for this. More videos tho! I love listening to your 'rambling'. I learn more and more everytime I watch a new video.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #890 · (Edited)
Here's the coulomb counter = current accumulator = current integrator proof-of-concept:

Now I just need to make sure the math is all correct (as discovered in the video, I have at least one sign backwards).

Update: I was able to remove the multiply/shift entirely... replaced with an intermediate uCoulomb-accumulator buffer. Whenever 3,600,000 uC are accumulated in that buffer, LiBCM adds/subtracts 1 mAh from the battery SoC. Positive side effect: no more rounding errors during the conversion from uC to mAh; the remainder stays in the intermediate buffer.

Update: Had a couple minor math corrections... my result was off exactly by 4, which is due to how LiBCM oversamples the 10b ADC. Working perfectly now: LiBCM's mAh result matches an inline precision battery Ah gauge. Yay, I reinvented the wheel!
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #892 ·
LiBCM now has a primitive understanding about State-of-Charge.
Right now LiBCM calculates the SoC and displays it to the user, but doesn't actually 'use' the SoC to make any decisions.
Once I'm convinced SoC is working correctly, I'll change LiBCM to respond to the SoC value (e.g. disable regen if pack full, assist if pack empty, etc). This will allow LiBCM to (safely) extract more energy from the cells (compared to the existing instantaneous pack voltage algorithm, which isn't very good).

Related:
I've condensed the information displayed on the 4x20 screen, which allowed me to add several new parameters:
-SoC
-highestTemp (not implemented yet)
-lowestTemp (not implemented yet)
-packCurrent (need to add a few lines of code)
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #893 · (Edited)
LiBCM is tracking SoC well enough for a first attempt.

The long term SoC drift is acceptable, but not great. For example, after leaving the key on (but not started) for 48 hours, LiBCM thinks a starting 3000 mAh pack has dropped to 870 mAh. However, since the IMA motor is off and the DCDC converter is disabled, the only load on the pack is the ~20 mA load (when key is on) from the BMS voltage sensing circuitry. Therefore, the actual remaining charge should be 2040 mAh, whereas LiBCM reports 850 mAh, which is a 1190 mAh error (24%).

Fortunately, the above test results requires you to leave the key on for 48 hours straight... pretty unlikely. However, there's still going to be a 0.5% uncertainty per hour the vehicle is operated without turning the key off. Ultimately this error will cause positive/negative recalibration (identical to how the OEM BCM behaves).

Fortunately LiBCM corrects this accumulated error each time the key turns off. Underneath the hood, LiBCM measures the open-circuit cell voltage when the key turns off, and then again every 30 minutes as long as the key is off. This V(oc) is then used to estimate the true SoC. Ultimately I need to build this same code into the keyOn code... but that's more difficult due to the wildly varying assist/regen.

For now if LiBCM miscalculates the SoC, it'll realize that's the case and perform a negative/positive recal if:
-a cell hits a max/min allowed voltage, or;
-the SoC gets to max(85%)/min(10%) and yet all cells are still within a 'good' voltage range.

For now LiBCM will continue to estimate and report SoC, but won't actually use it to determine whether to allow assist/regen... that'll remain solely a function of the instantaneous cell voltage, including a current-based adjustment.

...

I just went for a test drive under the following conditions:
-First I charged the pack to 4.200 volts, which I define as 100% SoC.
-then I manually discharged 2.9 Ah from the pack, leaving 2.1 Ah remaining charge (42% SoC).
-I then drove the car uphill until the SoC was 10% (500 mAh).
-I then autostopped and measured resting cell voltages around 3.460 volts.
-Based on my previous pack charging/discharging (with calibrated test equipment), 10% SoC is 3.468 volts.

The above test shows that LiBCM is very accurately tracking SoC over the short term.

...

I then drove back down Lookout Mountain in 2nd gear, regenerating 1565 mAh (278 Wh) by the time I got to the bottom.
Aside:
-On paper, the vertical elevation I drove up/down the mountain required 2.1 MJ of energy.
-On the way down, LiBCM regenerated 1.0 MJ of energy into the pack (278 Wh).
-So basically the IMA is recovering 48% of the downhill energy into the lithium battery... neat!
For reference, each ounce of unburned gasoline is approximately 1 MJ... so the IMA system effectively 'recovered' an ounce of fuel that we would have otherwise had to burn later on (if the IMA system wasn't present).


I constantly applied regen as I dropped down the mountain. As I approached the bottom:
-the 'old' (cell-voltage-based) 'SoC' algorithm was estimating that the pack was nearly full. This is because the heavy regen caused the cell voltages to rise, which caused the old algorithm to start limiting regen, but then as soon as that happened the cell voltages dropped and regen was allowed again... causing the constant hunting that the beta testers are well aware of... certainly not ideal. As soon as I got to the bottom (onto flat road), regen was once again allowed (because the cell voltage dropped).

Production vehicles don't use this algorithm for precisely this reason... I started with it because it's easy to implement and safe to operate (i.e. the cells won't explode). It's always been on my radar that I need a better algorithm, which is what I'm working on now.

FYI: even after I replace the 'old' algorithm with the new one, the 'old' one will still run in the background to prevent severe over/under-charge at the cell voltage limits. The 'old' algorithm will take over whenever it decides a negative/positive recal is required... which is hopefully never (if I design the new algorithm well enough).

...

-During the same downhill test, when I got to the bottom, the 'new' (current-counting) SoC algorithm determined the pack was actually at 48% SoC... which means once LiBCM uses the new algorithm, it'll allow full regen all the way to the bottom... plus another couple thousand feet. This is a huge difference, because it will allow LiBCM to provide higher assist/regen levels for longer time periods.

...

Still lots of work to do before I switch over to the new SoC algorithm, but it's fun to look at how well the first version of the code appears to work. Beta testers: It's up on github... version 0.4.0 (the latest)
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #894 ·
In other news, one of my machinists just sent me the vacuum plate he'll be manufacturing LiBCM's polycarbonate covers on.
Plate with part:
Circuit component Rectangle Font Hardware programmer Metal


Plate (no part):
Rectangle Slope Triangle Wood Font


His model is showing 1000 pounds of clamping force, which should be enough to keep the polycarbonate from sliding around.
 

·
Premium Member
Chicago & Detroit
Joined
·
1,299 Posts
actual remaining charge should be 2040 mAh, whereas LiBCM reports 850 mAh, which is a 1190 mAh error (24%).
I would say this error is actually greater than 24%. By what means did you calculate 24%?
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #897 ·
LiBCM can now sample its QTY7 external temperature sensors in degrees celsius.
The ADC result goes into a lookup table with QTY116 elements... which uses considerably less space and is many times faster than the actual math would be (which has QTY3 multiplies, QTY3 floating point divisions, QTY1 natural log (!), and QTY3 add/subtracts)... that's how non-linear temperature sensors are. Anywho, I did all the math in a spreadsheet and then copy-pasted the results into a LUT.
I have a bit more work to do until I can measure the QTY11 onboard temperature sensors... QTY10 of them interface via the LTC6804s' 24b ADCs.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #899 ·
@retepsnikrep
From your BATTSCI notes, the BCM represents temperature to the MCM as:
singleHexByte = T_degC * 2;

Example:
If the battery is 29 degC, the BCM sends 0x3A.

So how does the MCM expect to receive negative temperatures?
I assume it's using 2's complement?

If that's the case, then the type is int8_t, which would then mean the MCM can only receive temperatures up to 63 degC (+127/2)... because 64 degC would overflow, technically causing undefined behavior (but actually causing MCM to interpret 64 degC as 0 degC). Right?

Am I overthinking this?
 

·
Administrator
Joined
·
13,145 Posts
Not sure where you got that note? Must be old.. :unsure:

Temp in BATTSCI is simply offset by 32C~ or something IIRC.

If the MCM receives 00 hex it knows the temp is -32C (That's as low as it can go)

20 hex (32 Dec) would be 0C

It can receive values upto 255 - offset (32) = 223C (y)
 
881 - 900 of 948 Posts
Top