LiBSU - Redesigning the "Battery Support Unit" to Support Lithium

Thanks. It's taken a while for me to get to this project, but now it's full steam ahead. Spent the day penciling in LiBSU's blank hardware canvas.

I've added you to the beta waiting list (no ETA). If you turn PM notifications on in your priuschat user settings, you'll get an email whenever I have beta LiBSU units.

This guy sees the forest through the trees: LiBSU will work just fine with sodium if it does ever take over. I'm not convinced, as solid state lithium will absolutely trounce sodium cells – as well as all lithium cells – whenever they release sometime in the (perpetual) "next five years".

Bingo. LiBSU doesn't care which cell chemistry it's monitoring; it'll do them all just the same.

In this particular case, I suspect it's the other way around: we'll eventually be replacing NexPower's sodium packs with lithium and LiBSU. Congrats on the first year, I guess.

Right now there's ~2500 GWh of installed lithium capacity worldwide, versus 40 GWh for sodium. By 2030 lithium is expected to grow to 8000 GWh, versus 100 GWh for sodium. In other words, lithium's installed capacity will increase more rapidly than sodium's in the next five years.

In general, I don't see sodium taking over the automotive market. Sodium's energy density is just too low, and that's not a solvable problem at the fundamental level; sodium ions store less energy in both volume and weight. And of course there's always the promise of solid state lithium on the horizon... which will absolutely dominate the automotive market if they're ever commercialized economically ("five years out" for the past fifteen years and counting).

In short, sodium isn't a lithium killer by any means. The energy density alone isn't even the same ballgame. Sodium without a BMS is less safe than lithium with a BMS. And of course it's worth repeating the fact that LiBSU will work with sodium cells, too.

This is a false comparison. Show me sodium sweeping over the EV/hybrid automotive market. Sodium is a stationary storage solution at best.

I don't get why Team Jack continues to think that knowledge is hostile.

Are you referring to the one where there's (still!) no BMS and also for a while there was no HVDC fuse or service disconnect? Lol.

 

Sounds like you understand the development process. Yes, your question is premature, but we will need to figure it all out eventually. For now, I've only just verified that YES, I can completely disable regen and/or assist as needed to keep the pack safe. I'll wait for functional RevA prototype hardware before I continue exploring these details. The car is parked until I get RevA PCB.

I haven't tested your exact example, but the car does allow at least some voltage spoofing. I tested with a +16 volt delta without issue. I haven't researched the Prius' inline HVDCDC converter enough to know if too much voltage spoofing will blow it up. However, I read that that is a common issue with the Gen3 Prius... so at some point I'll need to research the safe voltage spoofing limits.

Yes, and it does both continuously during a drive cycle. Under load it favors coulomb counting, but at rest it will slowly recalibrate based on Voc->SoC LUT.

The G1 Honda Insight is more controllable in this regard because:
-I've had time to fully explore the OEM system's response to the various stimuli (which will happen with the Prius in due time), and;
-Insight's BCM computer generates SoC internally, hence LiBCM (which replaces BCM) can always just tell the OEM system the SoC.

There are other variables besides voltage and coulomb counting. For example, we can send fake current sensor data and manipulate pack temperature. These are just hand wavy concepts right now. The key point is that I know we can manipulate the system as needed to keep the pack in a safe operating area.

Thanks for the background. I'll explore this much later in the development cycle. For now I need to convert my PoC to a functional prototype.

Good data to capture eventually.

Reminder: I don't intend to ship LiBSU with 47Ah Samsung SDI modules (i.e. 'Ford cells') anytime soon. However, I do have the manufacturer's full specification sheet for these modules, which lists assist/regen limits at numerous temperatures.

Yes, we will need to limit regen/assist below freezing. Temp spoofing is the prime candidate, but again those are future details to figure out. For now the focus is prototype hardware. We'll do the firmware minutiae later.

I would never run a lithium cell at 4.2 volts... much too high for such a demanding application. Right now I'm using 60S, and wouldn't go below 56S in a production system. Note that I've run the car at 245 VDC without issue, so seems like the Gen3 limit is slightly higher (or the battery voltage dropped between when I charged to 245 VDC versus when I turned the key on).

No need to offer forgiveness; I'm always grateful when others offer their experience/feedback. You are taking the time to potentially turn unknown unknowns into known unknowns. While many of these questions are unanswerable at this moment, we'll need to figure them out eventually.

 

Are you referring to NexPower V1, V2, V2.5, V3, or V3GT, or whatever new version they're announcing next month? Just wondering.

Please reread my previous reply to your previous misguided statement.

So you're saying NexPower already redesigned their product to add supervisory control? Wow, I guess I missed that. Link please. You're comparing an automobile to a horse and carriage.

...

I'm probably already done responding to your uninformed talking points.
Keep shooting your shot I guess, but please understand that I might stop responding.
Eventually I'll let the product do the talking on my behalf.

 

Pegged!


Almost done with the schematic... starting my weekend now, but I'll be back at it when I get back. So far I've reduced the BOM cost by ~90%. I'm revisiting every existing part (from my low volume Honda Insight project). It's amazing how much you can reduce cost if that's a design goal (which wasn't the case with my existing BMS hobby product).

For example:
-switched from a $17.50 MCU on the proof of concept to a better in every way $0.75 MCU for RevA PCB. I'm not thrilled about the 0.5 mm TQFP pin spacing, but that's standard on modern MCUs at the density required for LiBSU.
-switched from a $4.30 Cadillac LT RS485 PHY to a $0.35 equivalent that will work just fine in this low speed application.
-saved $5 by downsizing the HVDCDC converter, since LiBSU will pull much less current.
-reduced bypass capacitor QTY where appropriate.
-added new PNs for same-valued low voltage DC capacitors ($), versus using just one HVDC part ($$$) for both HVDC & DC. HVDC caps are 20x more expensive.
-etc.

All these cost savings are passed onto the customer. I can see a path where LiBSU's MSRP is under $300 in QTY.

...

Other notes:
I'm trying to design the PCB such that I can submerge the entire assembly into a conformal coating, versus having to manually apply with brush (time consuming). This requires placing all connectors higher on the board than all SMT components (so the SMT pins and traces are all coated). Conformal coating is required IMO for this application.

I'm ditching the OEM temperature sensor harness entirely. LiBSU has a single air intake temp sensor input. All pack temperatures will be located on remote BMS PCBs, and read via serial.

LiBSU has the following onboard serial interfaces:
-isoSPI (it will have two separate buses, assuming they both fit, TBD)
-CAN
-RS485 (to communicate with hybrid computer)
-USB

In addition, LiBSU will have either QTY2 or QTY3 expansion port headers (e.g. for grid charger option, heater option, etc). Each port has a 2x5 shrouded header, which will accept 10p ribbon cables for each accessory. Space is the deciding factor for how many make it onto the board. Each port can simultaneously access the following signals (i.e. they are unique to each port):
-USART, and;
-buffered SPI, and;
-switched 5V power source (to save power), and;
-device identifier (so LiBSU knows what's plugged into each port, if anything), and;
-hardware PWM timer, and;
-QTY2 analog inputs (12b ADC), and;
-hardware interrupt.

That's a LOT of GPIO! I wish my Honda Insight product had even half this expansion capability.
Related: I'm using every single MCU pin (because why not?).

 

"HVDCDC" means the isolated switch mode power supply that converts the HVDC pack voltage (e.g. 240 Vdc) to a local 12 volt rail, which then powers LiBSU's low voltage circuitry. I hadn't initially planned to connect LiBSU's main PCB to HVDC. However, it turns out the BSU is responsible for verifying the HVDC bus remains electrically isolated from the vehicle chassis. Therefore, since I already had to connect HVDC+ and HVDC-, I figured I'd just power LiBSU directly from the pack.

My Honda Insight product is also powered from the traction batter, so this power architecture isn't new territory.
On that product, the continuous keyOff standby time is:
~11 months with a starting 20% SoC, or;
~35 months with a starting 60% SoC, or;
~48 months with a starting 80% SoC.

The Toyota product will consume substantially less power than the Honda product mentioned above.
My guess is LiBSU will have four times longer standby time (e.g. ~4 years with a starting 20% SoC).

FYI: LiBSU needs to stay on when the car is off to balance the cells, run the grid charger, etc.

LiBSU is designed for use with multiple different remote BMS architectures... basically anything with a serial bus will work. Yes, I will offer an open source reference design using LTC68xx parts, which is similar to my Honda Insight product. The primary difference between the two designs is that my Honda Insight product uses LTC68xx-2 parts, whereas the Toyota product will use LTC68xx-1 parts. '-1' parts use a dedicated point-to-point isoSPI bus between each LTC IC, whereas '-2' parts are individually addressable on the same shared isoSPI bus.

This is really in the weeds:
The reason for the '-1' parts is high frequency noise generated by the hybrid system. That noise took a lot of work to overcome on the Honda Insight product, which was all on a single PCB. That '-2' design is highly unlikely to work reliably on a distributed design. Moving to a '-1' design drastically increases common mode noise rejection, because we can treat the isoSPI PHY as a true terminated transmission line. This isn't possible with '-2' architecture because each IC introduces an RF stub onto the isoSPI bus. This causes reflections which aren't easily fixable because you physically can't terminate each stub (but you can when there are only two devices on each dedicated '-1' device.

Again, you don't need to use isoSPI to connect to the BMS... my reference design will, but if you want to use CAN, SPI, USART, etc... that'll be on the table, too.

User interactivity is zero unless a cell enters an unsafe operating area, in which case LiBSU will brick your car until you fix the issue. This is the very definition of "supervisory control". Unfortunately, LiBSU must brick your car when a cell is unhappy... otherwise, customers would keep driving the car until something really crazy happened.

LiBSU will be field upgradable, but I don't anticipate having any user configuration settings. This is a departure from my Honda Insight product, which has lots of user configurable firmware options. We'll revisit this as needed in the future, but initially all LiBSU customers will run the same firmware build. It's possible/likely this will change in the future, but not on day 1.

LiBSU won't ship with any intentional radiators (e.g. bluetooth). Adding that feature would force the product to undergo FCC certification. Per 47 C.F.R. § 15.103(a), LiBSU is only exempt from FCC testing if it's not an intentional radiator (i.e. it does not contain a wireless transmitter).

I've gone through the FCC process numerous times with numerous products. It's not a pleasant process, hence my hesitation to subject myself to that bureaucracy. There are exceedingly few product categories exempt from FCC's purview, but fortunately LiBSU falls into an exempt category (i.e. it is "a digital device utilized exclusively in any transportation vehicle").

JLCPCB is a quality PCB manufacturer.
A have my own PCBA mini-factory in my garage. I can place ~QTY17000 parts per day with this setup, which should easily handle my initial sales volume. I will eventually switch to a PCBA provider, but likely not JLCPCB due to some shenanigans they've recently subjected their community to.

Thanks, yeah it's a rare trip indeed where I don't see at least one Prius. I saw a few dozen on my 600 mile round trip to Asheville yesterday and today.

 

I agree: LiControl wasn't amenable to the massive feature creep our loving Insight community thrust upon it . LiControl was never intended to take on the myriad tasks... it was designed to do one thing well... and well, not one thing more. Feature creep kills products... particularly those with small design teams.

I've collected zero data to support this, but in general the entire point of CAN is that 'listeners' keep quiet unless they receive their address.

Absolutely:
-LiBCM (for Honda Insight) is a monolithic design, which was stubbornly adapted way beyond its original purpose.
-LiBSU (for Toyota) is a modular design, designed from the start to work in any Toyota vehicle (but initially only the Gen3 Prius and related).

 

Excellent questions! I've replied inline.

LiBSU has an I2C port, which I will use for my own debug purposes with the same 4x20 LCD that I use in the Honda Insight project. If customers want to use this screen, too, they can connect an off-the-shelf LCD. They could also gather data via USB.

My Honda Insight project also has an optional LCD touch screen (called "LiDisplay"), which another Insight owner has designed the user interface for. I don't intend to incorporate that LCD on the Prius product, although it is technically possible to add via the QTY3 expansion ports.

Absolutely. I ended up driving around with a suitcase sized HP spectrum analyzer in the passenger seat to troubleshoot an isoSPI issue on my RevA Insight prototype. Lots of aluminum foil revealed my RF noise issue was conducted by the high current cabling connected to the three phase IGBT module. I squashed said noise with a monster ferrite core (2" OD, 1.5" OAL), which heats up slightly while driving.

Agreed, particularly if/when more cars switch over to a 48 volt LVDC architecture. ABS is likely the most noisy LVDC subsystem in EVs.

Yes, each bus is individually terminated on both ends. That way you can run data either way through the token ring (or both ways if the ring opens anywhere). This gives redundancy without a ton of extra wires; the token ring only requires QTY4 total wires between LiBSU and the BMS daughterboards, no matter how many daughterboards you have. You only need QTY2 total wires if you don't 'close' the ring, which still meets ISO 26262 ASIL C requirements.

I actually have two different 'desktop' machines, and am about to purchase a third one (because the most recent one I purchased is terrible).

I built my own reflow oven based on the (excellent) open source Whizoo controller kit. It works really well after you abandon their default reflow profile (which is much too slow).

I'm trying to remain as transparent as possible without giving away the design. Almost every product I've designed over the past decade is open source, but not this one (at least not yet). I will probably eventually make LiBSU open source, but not initially.

Much larger battery reserve, plus it allows LiBSU to balance the pack when the car is off. The OEM BSU wire harness doesn't have 12V_KEYOFF, so I'd have to run wires to the battery. Since I already have to run the pack HVDC± to LiBSU to measure isolation resistance, it's easier to just power LiBSU from HVDC, too.

I can't run the pack fan with the car off; it's controlled by the main hybrid computer. The BSU only connects to the fan's tachometer (to send RPM data to the main hybrid computer via the RS485 port). A fan likely isn't required due to low ESR; if the pack is too hot, LiBSU just won't charge. Another option is to power a fan from the HVDC bus... issues for a different day.

In my existing Honda Insight product, the pack heater is powered directly from HVDC. That requires more safety isolation, but it's not too difficult to achieve. I intend to replicate this design on LiBSU.

I initially considered implementing this architecture on the Honda Insight product. My plan was to rewire the OEM HVDCDC converter, which can output 75 amps into the 12V bus. The problem I ran into is that the idle power consumption was too high (~1.3 watts). One positive with this architecture is that it would allow the 12 volt battery to stay fully charged all the time.

It's much more efficient to just power whatever you need from the HVDC bus. On my Honda Insight project, the max current draw from the HVDC pack is only 70 mA (with three fans running full speed). LiBSU's max current draw is much lower, at ~20 mA under full load.

This is a contributing factor, although even if it was available I'd probably still just use HVDC. The Honda Insight does have 12V_ALWAYS, and yet I don't use it, either. Instead, I draw all power from the HVDC pack.

Note that LiBCM (and LiBSU) can both almost entirely turn off... LiBSU will draw ~200 uA when it's 'off'. Put another way, LiBSU will consume well under 1% SoC per year when it's 'off'. The lithium cells will self discharge faster than that.

Powering LiBSU from the HVDC pack removes an entire cable assembly. Wire harnesses are expensive; certainly more expensive than the isolated buck supply. This wouldn't be true if I didn't already need the HVDC harness from the pack to LiBSU.