Honda Insight Forum banner
861 - 880 of 949 Posts

·
Registered
2003 Honda Insight CVT, 2001 Honda Insight MT, 2000 Honda Insight MT
Joined
·
153 Posts
Another awesome video! Push button testing!! That is great that it allows you to test it outside of the car and is able to check everything. You keep on rolling (even at 4 in the morning)!! ⚽💨
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #862 · (Edited)
Last night I realized that the automated tester didn't correctly test the cell discharge circuitry. I spent several hours debugging this... incorrectly thinking it was the code itself that was wrong. Ultimately there are two hardware issues:
-The LTC6804 IC doesn't use a charge pump to drive each PFET gate... therefore, as the cell voltage decreases, the gate drive decreases, too. Since my original goal in using the LED string was to provide a non-linear, high resistance string to the BMS system, that means that when the PFET is enabled (to discharge the cell, or in this case turn off the LED), the LTC6804's gate drive drops to essentially zero.
-The PFET I'm using has a 1.75 volt 'typical' Vgs, but the specified worst case is actually 2.5 volts, which made the above even more problematic.

In short, the existing LED-based BMS tester isn't able to reliably test that the discharge circuitry will turn on. However, it is able to test that the circuitry is NOT on (when it should be off)... so that's helpful. I could make the automated tester work by replacing the LED string with 75 Ohm resistors... that would cause the voltage to halve (e.g. from 4 to 2 volts) when each discharge element is activated. Maybe I'll do that in the future, but not right now. Note that I would still use the existing LED fixture to test the BMS adapter cables (which require visual feedback to the human tester).

...

Fortunately, the automated tester doesn't doesn't have issues testing for shorts between cells... which is without a doubt a more important test... shorts between (low resistance) lithium cells will damage the hardware, whereas a non-functional discharge circuit will only prevent cell balancing.

The workaround to test the discharge circuitry is that after running each PCB through the automated tester, I'm plugging the PCB into real batteries (super low risk, given that there aren't any shorts). I then run the same automated test code, which upon sensing the higher battery voltage (3.5 volts versus 2.0 volts for the LEDs) actually runs a different test: instead of running the actual automated test code, it turns on each discharge FET for a couple seconds. I then visually inspect each PCB with a thermal imager.

Since testing one cell at a time would take 240 seconds, I instead do the following:
For each IC in turn:
-enable all odd discharge FETs (1/3/5/7/9/11). Leave on for 2 seconds.
-While the FETs are on, I visually inspect with thermal imager.
-turn off all FETs, then wait 2 seconds (for resistors to cool).
-turn on all even discharge FETs (2/4/6/8/10/12). Leave on for 2 seconds.
-turn off all FETs, then wait 2 seconds.
-Advance to next IC.

This test 'only' takes 40 seconds... if it were automated it would take less than 1 second. Therefore, my QTY200 (LiBCM PCB) breakeven R&D time (to design a new test PCB and write new firmware) is around 2 hours... so it's a wash, and for now I'll just keep manually inspecting each PCB with a thermal imager.

...

This morning all the tables were 100% cluttered, with nowhere left to push old projects/piles. So today I spent several hours cleaning/filing/organizing, and am now ready for more tinkering.

...

Manufacturing notes on the first batch of QTY18 PCBs:
It took 106 minutes total to build each PCB. This doesn't include any external cabling (which probably takes longer).

The 106 minutes breaks down to:
-SMT placement, pre-reflow inspection/adjustment, and reflow: 43.3 min/PCB. There's plenty of room for improvement here, even without replacing the pick-and-place machine. One major issue was that the machine needs to be calibrated, which will improve part pickup reliability and placement accuracy. That'll prevent me from having to manually adjust part placements with a tweezer, which will save maybe 10 min/PCB.

-Post-reflow SMT visual inspection : 7.3 min/PCB. This will drop down to maybe 5 minutes on the next build... primarily because I (accidentally) programmed the pick-and-place machine to place several diodes backwards. Therefore I had to flag each part (for rework), which takes time.

-SMT rework: 15 min/PCB. This will drop down to 10 min/PCB on the next build. As mentioned previously, QTY111 (out of QTY114) LTC6804/LTC6820 parts required manual rework. I'm now an expert at reworking these parts, so I should be able to rework them faster in the future. Of course, I hope to place them better next time, so that rework isn't required. We'll see. These parts have 0.65 mm C2C pin spacing, which is less than half of the next-closest part. Besides those QTY111 reworks, there were only QTY18 additional defects (out of QTY11000 parts placed). So the P&P+pre-SMT-adjustment is generally doing well enough.

-Thru hole soldering: 29.7 min/PCB. Honestly this took much longer than I had anticipated. There are QTY234 thru-hole joints/PCB, plus QTY12 hand-soldering SMT leads (the temp sensors on the back). That works out to 8.3 solder joints/minute (which is 7 seconds/joint). I feel like I can solder faster than that... one issue is that my board pre-heater is more powerful than my exhaust fume hood... when the heater is off 99.9% of the solder fumes are evacuated; whereas, when the heater is on it's more like 90% (i.e. 10% of the fumes end up in my face). Hence I didn't use the preheater much, hence it took more time to heat each joint. Looks like i need a stronger fan... but the exhaust ducting is nearly 100' long, so maybe there's too much resistance in the plumbing. Anywho, more to figure out there for next time.

-PCB cleaning and final visual inspection: 5.8 min/PCB. The entire PCB is assembled with 'washless' fluxes, so cleaning isn't actually required... but I thought "why not make it look pretty, how long can it take?" The answer is: a long time. I bailed on cleaning off the entire PCB after just a couple PCBs. Going forward I'll only clean the LTC6804/LTC6820 ICs, as I must do so to visually inspect the tight pin-spacing for opens/shorts.

-Soldering grid harness: 4.7 min/PCB: There's no reason this should take more than a couple minutes. I now have a fixture that holds the PCB vertical... I'll probably make another fixture that holds the QTY4 wires in place... super annoying soldering wire harnesses directly to the PCB.


I'm certain I can remove at least 20 minutes/PCB on the next batch. That's the whole point of a "manufacturing production test" job. Time will tell.
 

·
Registered
Joined
·
14 Posts
I spent the last three hours reading and watching all your posts. So much hard work, so cool.
All four of the projects i'm working on at my job are redesigns due to Silicon part shortages.

I passed up on being a Beta Tester, but i'm eager to be an "early adopter", I hope i'm not too late for that.
My NiMH pack has given up only 5 months after changing out some dead cells, so i'm extra ready.

I have 4x 18s+ packs and have a post on your pack trading thread to get a 18s- pack.
I like your 18 to 12s conversion method, It looks a lot more professional then the wood spacers I was going to use.

I would like to put together a system as soon as possible, without causing you any inconvenience.
I have EE skills, HV battery skills, and equipment, and will rewire all the cell taps myself if I have too.
Is there some way buy one of these early adopter units, or one from the next batch?
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #864 · (Edited)
Thanks for spending three hours catching up. Eventually I will refine the relevant portions of this QTY863 post thread into an Owner's Manual, Installation Manual, and FAQ at linsight.org... so that future comers-by don't have to sift out the details themselves.

I've really enjoyed this project. It's been on my to-do list for about five years now, and has taken substantially more effort than I had imagined. I'm over the hump, and in fact (finally) just sent out the (hopefully) final production hardware to our beta testers (just got back home from USPS maybe five minutes ago).

The beta testers are going to need to have the hardware for a few weeks before I ship any units to new customers... the beta testers already know all the quirks and oddities with the existing firmware, so I won't have to support them as much... hopefully they don't find any new hardware issues, but we'll see.

...

Prior to opening the early access program, I need to:
-work on the firmware, which still needs substantial work.
-create final installation videos and written installation instructions.
-create a user manual
-create an FAQ
-create the safety quiz (mentioned below)
-create the legal documents (mentioned below)
-receive and validate the production polycarbonate covers

When the early adopter program opens (est: end of NOV), it will be open to anyone that meets the following requirements:
1: Watch the safety/installation videos, which will be located at linsight.org (but are NOT there now... I haven't even filmed them yet).

2: Take an online safety quiz, which will be located at linsight.org (but is NOT there now... I haven't created it yet).

3: Sign a liability statement that waives certain rights you would otherwise have if you don't follow the safety instructions and injure/kill yourself.

4a: Sign a "Limitations On Product Use During Early Adopter Program" statement, which will further limit my legal liability if Linsight does something wrong and burns itself to the ground. The two primary requirements are that you:
-don't park your LiBCM-equipped insight in a garage that is attached to any habitable space, and;
-maintain possession of the LiBCM hardware throughout the Early Adopter period (e.g. you must install LiBCM in a vehicle you own - and maintain ownership of - throughout the Early Adopter period).
4b: When the Early Adopter Program ends, the items in '4a' will no longer apply.

5: Early adopter LiBCM units will ship without preloaded firmware. You will need to program the firmware onto the LiBCM hardware. I do this to force you to learn how to do it. The beta customers have all figured out the process, and the production method will be even simpler: plug the USB port into your laptop, launch a program, and load the new firmware image. I will provide simple step-by-step instructions at linsight.org (but have NOT written them yet).

6: You must install new firmware in a timely fashion. To enforce this, LiBCM will erase its existing firmware every 40 days or so. If this happens (because you fail to update the firmware), the IMA system will not work (until you load the firmware again).
6b: When the early adopter program ends, I will release firmware version v1.0.0, which will remove this 'feature'.

7: During the early adopter program I strongly suggest you have some method to manually disable assist/regen (e.g. Calpod switch, C&C, etc). Otherwise, you might need to place the transmission in neutral to prevent regen when the pack is already full. LiBCM typically does a good job preventing regen/assist when they shouldn't occur, but when driving down steep mountains the firmware sometimes isn't able to convince the MCM to stop regen. We beta testers are working on firmware solutions (which certainly exist).

8: During the early adopter program, you alone are responsible for making sure the cell voltages stay within safe ranges. The existing LiBCM firmware already does so reasonably well, and a few weeks from now (when the early adopter program opens) it will certainly be substantially better... but ultimately you are responsible for verifying the cell voltages are safe (e.g. by monitoring the max/min cell voltages on LiBCM's LCD display).

9: You must install the LiBCM kit in a reasonable timeframe... maybe within two weeks of receipt. I don't want early adopters sitting on hardware without using it.

10a: If you are using Honda EHW5 modules (the ones LiBCM is designed for), you must already physically possess one of the following module configurations:
18S-/18S-/12S+
18S-/18S+/12S+
18S-/18S-/18S- (QTY1 18S- module will be converted to 12S+)
18S-/18S-/18S+ (QTY1 18S- module will be converted to 12S+)
18S-/18S+/18S+ (QTY1 18S+ module will be converted to 12S+)

The following module configurations ARE NOT ELIGIBLE for the early adopter program:
18S+/18S+/12S+
18S+/18S+/18S+


10b: If you are using any other lithium module (e.g. Nissan Leaf, etc):
-I will send you BMS ribbon cables as long as you want.
-I will send you #4 AWG HVDC current cables as long as you want.
-You alone are responsible for correctly connecting these cables to each cell.
-You must use a lithium chemistry whose charging range lies between 3.000 & 4.200 volts.

LTO & LiFePO4 modules ARE NOT ELIGIBLE for the early adopter program.

...

After you complete the above requirements, I will send you a payment link. You will enter the early adopter queue when I successfully receive your payment. Early adopters will be limited to QTY1 LiBCM kit.

When the program opens, I will immediately ship LiBCM hardware to the first QTY10 people that meet the above requirements. After that, I will continue shipping QTY10 additional early adopter units per week.
 

·
Registered
2003 Honda Insight CVT, 2001 Honda Insight MT, 2000 Honda Insight MT
Joined
·
153 Posts
@mudder , thank you for that write-up, very well written. Great explanations, steps, expectations, timeline, etc. We appreciate ALL of your efforts and time; everything in here is very well explained. Thank you for keeping us all appraised and for all the development...system, implementation, videos, releases, SAFETY, FAQs, etc
 

·
Premium Member
Joined
·
2,142 Posts
7: During the early adopter program, you MUST have a calpod-type switch installed in your vehicle. Calpod will allow you to disable the IMA system if needed. FYI: If you're not familiar with Calpod, then you (probably) aren't an ideal early adopter.
Ah RIP. I had planned on installing LiBCM in my turbo CVT, looks like it will go in my blue MT instead because you can't put a calpod switch on a CVT. At least until the full production comes out and I buy another kit for it.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #868 · (Edited)
@mudder - doesn't req #7 preclude us w/ 2006 5mt's?
Ah RIP. I had planned on installing LiBCM in my turbo CVT, looks like it will go in my blue MT instead because you can't put a calpod switch on a CVT. At least until the full production comes out and I buy another kit for it.
Both valid points. I've modified item #7 to allow both CVTs & 2005+ MTs to participate.
Note that our beta testers include both a CVT & a 2005+ MT.

More notes on the rationale behind item #7:
LiBCM's firmware doesn't presently 'know' anything about the size of the battery, and so it can only estimate SoC based on pack voltage, which is certainly the wrong (but easy) way to determine whether assist and/or regen are allowed at any given time. Therefore, given that LiBCM doesn't presently have any 'memory' about the SoC, LiBCM is always telling the MCM only the latest SoC estimate. Under certain conditions, this causes the SoC to change rapidly... which can cause the MCM to continue charging when it shouldn't.

The 'fix' for the above is to write a better SoC algorithm, which is high on my list of firmware features to add. It will be fixed, and hopefully prior to opening the early adopter program. I've hardly touched the firmware in weeks, as I've been focused on the final production hardware. Now that I've shipped said hardware to our beta testers, I'll be switching back over to firmware tomorrow.

Also, the production LiBCM hardware now has a super annoying beeper that will sound if any cell voltage exceeds hard-coded limits (e.g. below 2.8 volts or above 4.2 volts). Y'all can thank Peter for this (useful) feature... I really don't like audible annoyances and really protested adding it. However, Peter persisted and was ultimately correct: the buzzer is quite useful to alert the operator to potential danger (e.g. cells overcharging, etc). So yeah, if the buzzer ever activates, you need to do something immediately to make it turn off (e.g. calpod, neutral, turn the key off, turn the IMA switch off, etc). The buzzer will only turn on when all other steps have failed.
 

·
Premium Member
Joined
·
237 Posts
I've modified item #7 to allow both CVTs & 2005+ MTs to participate. Note that our beta testers include both a CVT & a 2005+ MT.
Awesome - I have an LSAS in my 04 CVT (I know it's not the same), but now I can spin the bottle as to which get's this 1st.
 

·
Premium Member
Joined
·
2,142 Posts
Both valid points. I've modified item #7 to allow both CVTs & 2005+ MTs to participate.
Note that our beta testers include both a CVT & a 2005+ MT.

More notes on the rationale behind item #7:
LiBCM's firmware doesn't presently 'know' anything about the size of the battery, and so it can only estimate SoC based on pack voltage, which is certainly the wrong (but easy) way to determine whether assist and/or regen are allowed at any given time. Therefore, given that LiBCM doesn't presently have any 'memory' about the SoC, LiBCM is always telling the MCM only the latest SoC estimate. Under certain conditions, this causes the SoC to change rapidly... which can cause the MCM to continue charging when it shouldn't.

The 'fix' for the above is to write a better SoC algorithm, which is high on my list of firmware features to add. It will be fixed, and hopefully prior to opening the early adopter program. I've hardly touched the firmware in weeks, as I've been focused on the final production hardware. Now that I've shipped said hardware to our beta testers, I'll be switching back over to firmware tomorrow.

Also, the production LiBCM hardware now has a super annoying beeper that will sound if any cell voltage exceeds hard-coded limits (e.g. below 2.8 volts or above 4.2 volts). Y'all can thank Peter for this (useful) feature... I really don't like audible annoyances and really protested adding it. However, Peter persisted and was ultimately correct: the buzzer is quite useful to alert the operator to potential danger (e.g. cells overcharging, etc). So yeah, if the buzzer ever activates, you need to do something immediately to make it turn off (e.g. calpod, neutral, turn the key off, turn the IMA switch off, etc). The buzzer will only turn on when all other steps have failed.
I'd rather just install it into my blue car, I have been driving that car more lately now that I fixed the herky jerky issues. I'll buy another once it's out of the EAP for the CVT car. The CVT car has a working pack anyway, and the blue car is bypassed with a stupid P1644 won't go away
 

·
Registered
Joined
·
14 Posts
Wow that's a lot of steps, but i'm up for it.
I have a CVT so I don't have a calpod switch.
Should I solder together "Peters IMA Boost Device" and install that?


I have always wondered, how come you are using an ol' AVR Arduino rather than a more modern microcontroller?
When I look at your bit shifts divides I think, wouldn't it be nice to have a FPU? :) I'm not saying you should change it, i'm just trying to learn more about advanced embedded programming.
 

Attachments

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #872 ·
Wow that's a lot of steps, but i'm up for it.
Wait until you see the installation instructions... based on our beta user feedback, a first time LiBCM installer needs to set aside an entire day to perform the conversion. At this point I can do a full swap in a couple hours, so expect to spend between two and eight hours start to finish. It's a lot of work.

I have always wondered, how come you are using an ol' AVR Arduino rather than a more modern microcontroller?
When I look at your bit shifts divides I think, wouldn't it be nice to have a FPU? :) I'm not saying you should change it, i'm just trying to learn more about advanced embedded programming.
Valid question. Here are a few reasons I'm using the Arduino MEGA2560:
-It's relatively cheap. I'm paying $15 for two MCUs, a USB port, an oscillator, a voltage reference, etc.
-It's in stock. I've had zero issues buying them, which is more than I can say for pretty much any other part right now.
-V&V is easier when I can remove the MCU as needed to troubleshoot signals... pulling off the entire MCU allows me to inject signals anywhere I want, without having to worry about how the MCU will behave.
-USB firmware updates are easy thanks to Arduino team's dedicated bootloader legwork. This is good for customers.
-People unfamiliar with embedded development environments can modify the firmware without having to install a complete embedded toolchain (e.g. IAR/Atmel Studio/etc). Arduino is hands down the easiest embedded toolchain out there.
-It's what I know. I'm not an embedded engineer by degree. Most projects I work on have a dedicated embedded guy... I get the signal to the pin... they write the code. This passion project doesn't warrant the budget to hire any engineering talent.

...

At this point there's no reason to swap CPUs... besides the occasional math issue, LiBCM works just fine with an 8b MCU. It would be nice to have an FPU, but I'm doing just fine without it. LiBCM is nearly feature complete and yet is only using 10% of CPU time, 7% of storage, and 22% of RAM. Long term I'll probably drop the CPU frequency down to 4 MHz to save power.

Certainly other MCUs can achieve all of the above, but in this case I chose the MEGA2560 because it works and I had it.
 

·
Registered
Joined
·
1,286 Posts
I have always wondered, how come you are using an ol' AVR Arduino rather than a more modern microcontroller?
Tool chain, tool chain, tool chain. I wrote embedded code when it was still just called firmware. Setting up any other tool chain can be a project in itself for someone with a full time job doing it for the first (or nth) time; wrapping your head around it just doesn't work if you only can afford an hour or two some evenings. Call me a simpleton, but the Arduino tool chain rocks because it can get you from zero to running code in five minutes and it runs on everything. For hobbyist projects, there simply is not that much going on to warrant something more, and one can go as deep as they need if needed (i.e., watchdog timers, interrupts, hardware registers, assembly, etc). One must take care with libraries, because as often as not they are either buggy in the corner cases or inefficient or don't implement something the way you need it or don't play nicely with something. But most are on GitHub and worst case you put their code on the same folder as your sketch and fix it yourself. And hardware-wise, the Arduino Mega has tons of IO and if you burn out the mega experimenting, you just buy another. There are alternate small form factors for the Mega as well. And the 5V processor is compatible with the Insight MCUs and many analog signals which are 5V. Most newer micros are 3.3v which require voltage conversion to adapt to 5V digital stuff or outboard SPI ADC modules like the ADC1115 if one needs to read a 0-5V analog signal.

What the Mega's MCU does not have is an encryption module or a secure enclave to store keys. This could be used to, say, implement a secure bootloader. Oh horrors, not closed source!!! No, the firmware can in fact be open source but this can ensure that only the tested build is used. One can have the device create an cryptographically secure unlock token that uniquely identifies the device; the unlocker can then provide the token on a website after agreeing that it voids the warranty, and receive an unlock code also specific to that device. Then if the experimenter destroys that which they are playing with, they are unable to blame the manufacturer for faulty firmware, because the manufacturer has a record of this exchange and can cast doubt on such a claim. (A user interface that advertises the alteration helps let downstream purchasers know that they own a modded device).

Other things one may want to implement include watchdogs and multiple copies of data or program in flash so that if something gets corrupted, the backup version can be used. This requires code to detect the fault and run the backup or some minimal, protective code. Here one has to roll their own solution, though some manufacturers of MCUs intended for automotive and similar applications may provide libraries or sample code for this stuff.
 

·
Engine-Off-Coast
Joined
·
2,187 Posts
I made a fix already for the opposite of #7, where you're assisting like a lot and a cell goes too low it sets the SoC to 20% and then like holds it there for a few seconds. And afterwards it only goes back up 1% max per n loops (currently n is 10 but I've been messing with n lately and usually have had it at 50). So essentially a negative recal. When driving the second the MCM sees 20% the assist immediately stops and the car goes into regen.

So that keeps my Insight at least safe from damaging a low cell. But I'm trying to work on it so that in the end the car will never get to that point. I want it to be seamless and invisible to the driver, so like if you are driving and you keep hitting assist it will preferably throttle that assist before a cell can get to that low point. We can do the same thing in reverse... at the higher voltages limit current first, and then if regen keeps happening force it to 80% and hold it there for a few seconds, before allowing 1% SoC increments going back down.

It would be really easy to write something that does the exact opposite.
 

·
Premium Member
Joined
·
111 Posts
Wait until you see the installation instructions... based on our beta user feedback, a first time LiBCM installer needs to set aside an entire day to perform the conversion. At this point I can do a full swap in a couple hours, so expect to spend between two and eight hours start to finish. It's a lot of work.
Honestly, that sounds quite nice compared to assembling the Prusa mk3s+ printer :).

I really loved this note "To enforce this, LiBCM will erase its existing firmware every 40 days or so. If this happens (because you fail to update the firmware) ". How often have I wanted to include requirements like that but couldn't becuase it wouldn't fly in commercial world (too many times). I want to hang that on a wall somewhere.
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #876 ·
If you think about it, SaaS is essentially the same thing: the software stops working if you stop paying or don't connect to the internet for updates every few weeks. I despise SaaS and generally don't enjoy forced software upgrades, but in this case it's for safety.

When it comes to what I can and can't do, I certainly don't miss working for other people ;).
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #877 · (Edited)
Background:
Panasonic rates these cells to 50,000 cycles with the following caveats:
-Test performed at 23 degC ambient
-10%-85% SoC
-Continuous 40 amp charge/discharge (100% duty cycle to failure)
-Test concludes when 80% of original capacity remains

Notes on cycle lifetime:
-If a Honda Insight is stored out of the sun and cold (e.g. in a garage), the EHW5 lithium modules have a nearly unlimited mileage lifetime... they're going to die from old age first (Panasonic rates them to retain 80% initial capacity after ten years). You could completely charge/discharge the pack 3x/day for ten years straight... and the battery is still going to die from old age first.

-Extreme temperatures will substantially increase cell degradation. Panasonic doesn't provide cycle lifetime guidance besides at room temperature, but does specify that EHW5 cells be used from -30 degC to 55 degC. We can reduce the temperature impact by limiting assist/regen at extreme temperatures. For example, if the temperature drops below freezing:
-LiBCM will limit regen.
-If enabled (by the user), LiBCM will attempt to heat the pack (using the onboard balancing resistors).
-With a fully charged pack, LiBCM can self-heat for more than three days non-stop.
-If the grid charger is plugged in, LiBCM will discharge (as above) and also turn on the grid charger (to balance the discharge losses).
-If the cabin temperature is warmer than the battery, LiBCM will turn on the fans (it can do so even when the key is off).

...

I Finally got around to characterizing these EHW5 Panasonic cells. Summarizing that data:
Rectangle Slope Plot Font Line



Rectangle Slope Plot Font Parallel

FYI: I'm using the following hardware:
-Programmable load: BK Precision 8500, with 4-wire remote sense.
-Power supply: TDK Lambda GEN30-50, with 4-wire remote sense.
-Calibration standard: Voltage Standard VREF10-002R810V Precision Reference. Calibration due: 2021NOV (yikes, that's now).


Thoughts on this data:
-LiBCM should prevent assist below 3.47 volts, which is 10% SoC.
-There is a small current-based correction, which will get worse as the cells age (and ESR increases). The existing firmware automatically applies a fixed adjustment for the cell-new-ESR, but eventually a better (Voc-nom vs. load) algorithm will be required (to account for ESR changes over temperature, age, etc).

-LiBCM should prevent regen above:
-4.07 V @ 50 A
-4.00 V @ 5 A
Using these datapoints, we can see an additional 70 mV with an additional 45 A, which works out to 1.56 mOhm ESR(DC), which is precisely what the EHW5 module is specified at. Therefore, to maximize cell lifetime, maximum regen voltage should not exceed 4.12 V @ 75 A. In general, the equation is:
V_disableRegen = packCurrent * 1.56 mOhm + 4.00 volt

With the above limits, a 48S1P EHW5 lithium pack (i.e. a 18S/18S/12S pack) will contain 887 Wh, of which 666 Wh will be usable (LiBCM uses 10:85% SoC).
Let's compare this to the OEM NiMH battery, which is nominally 936 Wh (6.5 Ah @ 144 volts), of which 515 Wh is usable** (OEM BCM uses 20:75% SoC).
Therefore:
-The 48S1P lithium EHW5 module stores less total energy than the OEM NiMH pack (887 Wh vs 936 Wh).
-The 48S1P lithium EHW5 modules has more usable energy than the OEM NiMH pack (666 Wh vs 515 Wh).

Simplified statement for customers that don't want to get in the weeds:
"LiBCM's lithium battery stores 30% more usable energy than the stock NiMH battery."

**Note that the OEM NiMH pack delivers substantially less energy "to the wheel". This is due to two reasons:
-The OEM NiMH pack's ESR is more than an order of magnitude higher than the EHW5. Therefore, given the same delivered current, the NiMH battery will internally convert more energy into heat.
-At the same delivered current, the EHW5 module will deliver more power because the nominal NiMH voltage is lower. Therefore, to deliver the same power, the EHW5 module will source less current, and thus the EHW5's ESR losses will be even lower.
If I had to guess, I'd say these two factors effectively add another 60 Wh advantage over the stock NiMH cells, which would change the above-simplified statement to:

"LiBCM's lithium battery stores 40% more usable energy than the stock NiMH battery."
 

·
Linsight Designer
Joined
·
2,782 Posts
Discussion Starter · #878 · (Edited)
Other notes on these EHW5 cells:

The cell under test was contained within an 18S module with zero airflow. During my several hours of testing (50/30 amps while charging/discharging), the cell did not rise more than 10 degF above ambient. Note that ESR is higher while charging, and that I charged at the OEM regen level (50 A). 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.

...

They recover to resting voltage in less than ten minutes. For example:
-At t=000- the cell is charging at 50 amps and is at 4.19 volts.
-At t=000 the charger is disabled (I = 0 amps).
-At t=000+ the cell voltage immediately drops to 4.12 volts, which works out to 1.4 mOhm ESR (70 mV / 50 A).
-At t=001 minute the cell voltage is 4.10 volts.
-At t=010 minutes the cell voltage is 4.09 volts.
-At t=060 minutes the cell voltage is 4.09 volts.
-At t=600 minutes the cell voltage is 4.09 volts.

Conclusions:
-To perform an open-circuit-based SoC estimation, we only need to wait ~10 minutes.
-Each time the key turns off, LiBCM can precisely update the SoC by adjusting to the open circuit voltage.
-LiBCM will separately calculate the pack size while driving and/or grid charging.
-LiBCM will use both values to determine the usable pack capacity
 

·
Premium Member
Joined
·
311 Posts
Mudder, I just want to say thanks for taking such a methodical and complete approach to designing LIBCM. This is impressive to watch!
 
  • Like
Reactions: mudder

·
Premium Member
Joined
·
2,142 Posts
That's honestly amazing. 30% more capacity and more ZOOMIES for passing. Awesome!!!
 
861 - 880 of 949 Posts
Top