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

I'm designing LiBSU to be battery agnostic. It'll have several serial buses (USB, isoSPI, SPI, UART, CAN, etc), and will support pretty much any lithium battery with an onboard BMS (or a breakout BMS node that I will also offer, for the DIY crew).

My initial focus is Gen3 Prius (including Prius V), but Gen2 Prius is very similar mechanically from my product's PoV.

This will depend on the battery you use:
First offering is a complete drop-in unit that uses OEM Toyota cells, including Toyota's onboard lithium BMS.
Mechanically it will fit in the Gen2/3/V Prius and all similar.

Later offering is a blade-like daisy-chained isoSPI solution using what I call a '4xBlade' (because it's four OEM blades wide). There will be a single '2xBlade' for those cars whose OEM blade count isn't wholly divisible by four. 4xBlade considerably reduces cost, because a properly designed BMS has a fixed price per node (i.e. there's very little price difference between QTY4 & QTY8 cells... the cost is in the node, not the cell count). Mechanically it will fit in any Toyota vehicle that uses blades.

Not for the above products, but again LiBSU is battery agnostic (just like LiBCM).

I'm doing Gen3 Prius first, followed by Gen2.
I'm working on showing a working prototype soon.

 

FYI: Here's a color-coded preview of the Gen3's serial protocol:


...it's a little more complicated than the Honda Insight's BATTSCI frames, but still not too difficult to figure out if you know what you're doing. Fun problem to reverse engineer. For reference, the Honda system packs all this data into 16x fewer bytes (24 vs. 384). Not saying Toyota's method is bad... just very verbose.

I'm still trying to figure out what a couple bytes do, but the other QTY382 are fully deciphered. I believe one of the two unknown bytes is actually an error in Toyota's official serial data stream (0x37B10 is always identical to 0x37B11). For now I intend to just duplicate the as-found behavior, although for academic purposes I'd like to figure that out eventually.

Overall I think Toyota made some odd design decisions on the BSU. I prefer Honda's system of having separate battery and motor control computers (BCM & MCM, respectively). Toyota does things differently, which means the BSU ends up passing a bunch of pack-specific information to the main computer. It's less modular, but obviously it works.

 

The Gen3 Prius I just bought has/had a functional NiMH battery, too... yoinked it out day one to make space for this project.

You now have the #1 spot on my open beta list. You weren't the first person to join the list, but I've enjoyed working with you in the past.

¿que?

 

Just finished the LiBSU proof of concept:

This project is finally in full swing!
Excited to start the RevA schematic tomorrow!

 

Here's all the data the Gen3 Prius' OEM BSU sends the main hybrid computer:
-QTY14 blade Voltages, and;
-QTY3 battery temps, and;
-QTY1 intake temp, and;
-Pack current sensor, and;
-Battery fan RPM (but not control), and;
-HVDC isolation voltage, and;
-12V battery voltage, and;
-BSU version number, and;
-Pack fault flags.

In total, there are QTY384 bytes sent via QTY24 different 16 byte packets. Generating this serial data stream on LiBSU takes ~QTY620 lines of code, which is bolted onto my existing Honda Insight firmware (~QTY9200 lines of code). So it takes ~QTY10000 lines of code to generate this proof of concept. The final code will probably be closer to QTY5000 lines once I remove all the Honda-specific features the Toyota LiBSU product won't have.

Based on my analysis, I suspect the same serial data architecture is used on all modern NiMH Toyota vehicles. There's 'room' in the existing data structure for up to QTY20 blade voltages (i.e. QTY40 NiMH blades), and up to QTY6 total temperature sensors. I believe this covers all NiMH Toyota vehicles. Older (Gen2 and previous) vehicles use a different PHY (CAN), but the serial data stream is similar (once you abstract CAN's peculiarities).

First LiBSU product focus is the Gen3 Prius and equivalent (e.g. Prius V, CT 200H, etc).

 

Great questions!

The Honda Insight LiBCM project is already open source.

The Toyota LiBSU project will have both open source and closed source components:
-The LiBSU computer itself will be closed source, and reasonably priced. It's too soon to guess at the price, but I'm shooting for $300, which is an absolute bargain.
-The battery-side PCB reference design will be open source, with a permissive license. 3rd party battery manufacturers can use the reference design on their own closed source battery modules. Their modules – with my reference design inside – will then work with my closed source LiBSU computer. In case it's unclear, there will be zero licensing fees for using my reference design inside 3rd party lithium modules.
-I even intend to design and sell an open source "blade style" PCB that plugs into a standardized 0.1" header on top of each 1x/2x/4x blade (3rd party battery designer's choice). For example, a 2xBlade (i.e. twice the width of OEM) will have QTY5 pins that connect to my PCB (with no wire harness, it'll be a b2b connector with sufficient mechanical stackup relief).

Unlike the niche G1 Honda Insight community, the aftermarket Toyota community is too large and competitive for me to give my work away... there would be a race to the bottom that I just can't stomach. LiBCM for the Honda Insight is a passion project; LiBSU for the Toyota ecosystem isn't... it's just work, and a lot of it at that.

Team Jack might attack my position.
I'll remind them that NexPower has shared the same position from day one.

Correct, the initial focus is on a similarly sized pack (between 1 & 2 kWh).

Correct: The hardware you see in my proof on concept is literally a 47Ah LiBCM Kit kludged into the Prius. I literally grabbed a complete LiBCM Kit off the shelf and stuffed it into the Prius.

I haven't shown the proof you're looking for yet, but for now I'll just say there is a mechanism to encourage the car to deplete the battery. It's nowhere near as good as the various manual IMA controllers developed for the G1 Honda Insight, but there is a mechanism to encourage the Toyota hybrid computer to consume more than just the stock pack energy.

Maybe someone should start working on a manual IMA controller for the Prius? I can't imagine it's too difficult.

At this point I'm sure you're aware that you're first on the beta list... once those kits exist. No ETA... I'm retired. It'll be ready when it's ready. However, I will say I'm very excited, and my work schedule is 100% based on excitement.