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

It's crazy that TE makes "wire-to-board" connector housings (1473143-1) that they don't also sell mating headers for. In other words, a company that solely manufactures mechanical connector systems expects me to design my own header to mate with their connector housing. OK, seriously?

Looks like I'll end up cutting off the OEM temp sensor terminals (1123343-1) and replacing them with another connector system. Another thought is to kludge a 0.100" 2p shrouded header to work with their 1473143-1 connector housing.

 

Daily PCB layout update:

Notes:
-HVDC section 100% placed.
-Connectors 100% placed.
-Should have all remaining parts placed tomorrow.
-Almost certainly a 2 layer board... almost every signal routes on bottom layer.
-Planning to order PCB Monday.

 

There are several ways to retrieve debug info from LiBSU:
1: The most verbose output is via USB. Here's the existing method for my Honda Insight product. Note that while I'm using Arduino's IDE in the video, any standard serial putty terminal will work... LiBSU isn't running Arduino code, but that platform is the easiest for computer novices to use.
2: LiBSU will report all OEM parameters to the hybrid computer, which are readable via OBDII. This will only narrow the failing cell down to QTY4 cell segments. You would need to use USB to narrow down to a single cell.
3: The (optional) 4x20 LCD displays the following parameters:
KEYON_SECONDS
VPACK_ACTUAL
VPACK_SPOOFED
BMS_ERROR_FLAG
CELL_VOLTAGE_HI
CELL_VOLTAGE_LO
CELL_DELTA
POWER_kW
CELL_MAX_SINCE_KEYON
CELL_MIN_SINCE_KEYON
SoC
PACK_CURRENT
TEMP_BATTERY
FAN_STATUS
CHARGER_STATUS
HEATER_STATUS
CELL_BALANCE_STATUS
WATT_HOURS_SINCE_KEYON_ASSIST
WATT_HOURS_SINCE_KEYON_REGEN

As I mentioned previously, no wireless options are available. The FCC certification is expensive and annoying, and I just don't plan to do it. If someone wants wireless, they'll need to develop an expansion module that plugs into LiBSU. Some of my Honda Insight customers use an Android phone with USB OTG for wireless comms.

 

0x04D8

0x00DF

0x0002

Native support all the way back to Windows 7, and MacOS 10.7. Any machine made in the past fifteen years will see it.

No additional drivers required.

 

Should have the board finished later today:

 

Yes.
More info to follow later.

I'm willing to work with almost all existing manufacturers who wants to add LiBSU to their product. Send me a PM and we can talk.

...

PCB is finished. Happy to route it on just two layers:

I'll order it tomorrow morning, after giving it one final look over.

FYI: I ended up axing the backup isoSPI port (which isn't required for safety). There wasn't enough room on the board, and also there wasn't enough room for the second 2p connector.

 

Was up late talking with a supplier... just ordered PCB now:

 

Uneventful hardware build. All the ports line up where they should (which was my biggest concern).
My only footprint issue was accidentally ordering 249k resistors with 0805 footprint; will replace with correct 1206 part on next build.

Maybe this RevA will ship? Too soon to tell... still need to test all the functionality.

 

Sorry for the delay... getting the PCB right before the Thanksgiving holiday didn't help.
dl;dw: Got the toolchain set up and programmed the MCU to blink an LED.

 

Alright, I got the code to build on the new MCU... haven't tested anything yet, but there aren't any compilation errors so that's a start.

For those unfamiliar, I just migrated the proof-of-concept firmware (running on a MEGA2560) over to a completely different processor (AT64DB48). In the process, I also deleted/disabled numerous features present in the existing LiBCM codebase (my Honda Insight product), which are not present on LiBSU.

I've left hooks into the grid charger logic, since I do plan to release that add-on option. The heater will stay, too, since every LiBSU pack will contain a heater capable of heating each cell at ~4 watts (~240 watts for the entire pack). I can't wait to talk more about it; it's pretty clever and only costs a few cents extra per cell.

The most difficult section of code to rewrite is the low level power saving features, which are fundamentally different between MCUs. The alpha LiBSU product probably won't support low power sleep states. However, the "turn off because battery is below 10% SoC" feature remains present, so we're not going to over-discharge packs during the alpha period. Until I write this firmware, alpha testers should expect SoC to drop ~1% per day. After that, keyOff standby time should increase to around four years with a full pack, or around one year with an empty pack.

I suppose now begins integration hell . Shouldn't be too bad.

My favorite part of this rewrite was finding the header file "dirty_tricks.h", which begins with the comment:
//Okay... This was getting f@#$ing absurd.
//We (those who speak fluent avr asm) all knew we needed unholy tricks like this.
///We wish we didn't. But while the GCC part of avr-gcc does a pretty thorough and consistent job optimizing...
//The AVR part is piss-poor. It's f@#$ing awful.

...this goes on for another few dozen lines. Top quality commentary.

 

I decided I don't like LiBSU's existing HVDC inrush current limiting circuit. Inserting the service disconnect causes a brief 5 amp spike, which slightly exceeds the onboard fuse's i2t limit. Even though most people aren't going to be installing the service disconnect plug often enough for this to become an issue, I want to make sure people who do it often don't end up blowing out the fuse prematurely.

Option 1 is an NFET whose gate is RC LPFd to limit HVDC ramp to 10 V/ms or so. This will add a constant ~10 mW load to the pack, which is roughly 1% SoC consumed every two months. You could mirror the circuit and use a PFET if desired. I prefer NFETs because electrons are better than holes. This option requires a board spin.

Option 2 is a higher resistance inline NTC to limit inrush current. However, LiBSU pulls so little power from the HVDC bus (17 mA max) that the NTC will never warm up... so then a 200 ohm NTC will consume ~58 mW when LiBSU is actually running. This option doesn't require a board spin.

The tradeoff between these two options is whether to ALWAYS pull 10 mW from the pack, or SOMETIMES pull 58 mW from the pack.

One might wonder why not just use inline resistors to limit inrush current (e.g. 200 ohms)? The answer is that NTC ICL's can handle the inrush energy much better than resistors. The moment you connect the service disconnect, whatever current limiting element is used has to briefly survive the full pack voltage across it until the HVDC input capacitors are charged. With 20 uF input capacitance, the HVDC inrush current limit circuit has to transfer ~650 mJ in a few dozen milliseconds without exploding. A fixed 200 ohm inline resistor must briefly handle 310 watts!

 

Yes, but I don't know the limits yet, but will explore them in due time. Voltage spoofing isn't my initial focus with this project.

It's odd because the Inverter doesn't seem to care that the spoofed battery voltage is different than the voltage measured separately by the inverter. I know there's a power stage between the battery and inverter, but you would think it would cause issues... and yet in my very limited testing so far it doesn't.

I don't know the limits yet. I also haven't analyzed the entire HVDC powertrain component set to verify your example is safe.

In my existing LiBCM project (for Honda Insight), I safely replaced a 144 VDC(nominal) NiMH system with a 235 VDC(nominal) lithium system. Honda way over engineered the entire powertrain... the lowest rated voltage component is 350 VDC. With a 25% safety derating, that limits the Honda system to just over 250 VDC. No idea if Toyota was as conservative in their design.

You have to manipulate the limits indirectly with adjusted data. The available parameters appear to allow complete current limit control, even disabling current entirely if/when needed.

In the Honda Insight, the continuous electric motor power increased from ~7 kW to ~21 kW. Peak current increased from ~12 kW to ~24 kW. With voltage and current spoofing, LiBSU should also increase power in the Prius. Actual values TBD, as I have barely explored this... but it should be easier than the Honda Insight because there are fewer sensors to spoof.

I've added you to the list.

 

Parts for previously proposed circuits arrived today. Results below for anyone curious.

Pros: supplies a nice smooth ramp that limits inrush current to 1.5 amps peak. No additional power loss proportional to load.
Cons: Constant power draw consumes ~8% SoC/year.

Pros: Power consumption is only proportional to input current; no standby power loss. Peak current limited to ~2.0 amps.
Cons: Power loss strongly proportional to input current; less efficient at high load current.

After gathering this data, I'm going with Option 2. If the footprints fit, I'll add both options to the circuit board (and only populate option 2).

Related: After more testing, I removed one of the two HVDC input electrolytic capacitors. This reduces cost slightly and also gives me room to add both options.

 

QTY14 blade voltages
QTY3 batt temps
QTY1 intake temp
Pack current
Fan RPM
HVDC insulation resistance
Actual 12V voltage
Fault flags
HW Revision
Firmware Version
Session boot code

Final algorithm TBD, once I get RevA PCB working in the car and have some time to gather test data.

Thanks for these data points.

Correct.

No, BSU doesn't provide SoC.
The inverter calculates SoC based on coulomb counting when current is high, and Voc->SoC LUT when current is low.
You can lie about both pack current and pack voltage and the inverter doesn't seem to care. Haven't gathered enough data to know that's always true, but it's sometimes true.

Correct, LiBSU can limit/disable assist and regen my spoofing parameters as needed.

Both power and current and voltage readings.

Inverter has separate current and voltage measurement circuitry... and doesn't seem to care if the voltage and/or current values don't agree with BSU (at least in my limited testing so far).

Yes, I know for certain this is true based on test data. I don't know the boundaries/limits, but certainly you can spoof the voltage 20 volts lower than actual voltage for a little more pep. Once I gather more data we can see how hard the inverter can go... I hear they're still under warranty so might as well have fun .