Participants
Goal
Decide on the BMS system architecture:
- Daisy-chain vs addressable
- Distributed vs master
- Handling temperature sensors
- Cross-battery box connections
- Cell balancing
Summary
We decided on the LTC6811 (successor to the LTC6804) as our AFE. It's a 12-cell 16-bit ΔΣ AFE with 5 GPIOs that can also serve as analog inputs. It supports a 2-wire isolated, noise-immune SPI-compatible interface from LT known as isoSPI. This allows us to move the AFEs to their own board(s), reducing the number of wires that need to run to the controller board. Our plan is to use the LTC6820 isoSPI interface to communicate with AFE board(s) over a twisted pair.
We also decided on supporting active balancing through the LTC3300, 6-cell active balancer. Passive balancing is just dumping power, and at our module sizes, is impractical. Our goal is to support full pack balancing. We considered using the LT8584, which is designed to be used transparently with the LTC6804. However, the cost of the chips and transformers as well as routing concerns made it less appealing. Initially, we plan on verifying the AFEs without the balancing circuit. Once our AFE setup is verified, we can develop the cell balancing algorithm and populate the circuit.
Our choice of AFE raises some concerns about the number of temperature sensors we can support. In order to support more temperature sensors, we can either use external ADCs or analog muxes (LTC1380), either off of the AFEs or the carrier board. An arbitrary target of 3 thermistors per cell module was decided as an upper bound on the number of thermistors to support. We will most likely use 10k NTCs, although Kevin Chen (Unlicensed) suggested using RTDs. Originally, we considered building separate temperature sensor boards, but ultimately decided against it due to the added complexity and lack of addressable SPI ADCs.
We considered two main options for our system design:
Distributed, split LV/HV
Option 1 focused on a distributed architecture, placing a controller board in each battery box and running CAN and power to both boxes. Thus, we would essentially treat the two battery boxes as individual batteries in series. Since we wouldn't need to worry about temperature sensors crossing between the boxes, we could place the external ADCs or muxes on the carrier board. This would allow us to safely separate LV and HV circuits. It would also reduce the amount of data transferred on each isoSPI bus.
On a firmware level, using a distributed architecture raised some issues regarding responsibility and network architecture. For example, how would we handle SOC calculations or measuring the total battery voltage?Centralized, modular AFE boards
Option 2 focused on a centralized architecture, with master and slave battery boxes, connecting them through isoSPI. This simplifies things from a responsibility and network architecture, but results in increased traffic on one isoSPI bus. In this configuration, the carrier board is just the current sensor and an isoSPI interface. The AFE boards contain the AFE, 2 balancers, and a set of analog muxes into the AFE's aux inputs. If choose to use the addressable variants of the AFEs and balancers, we can theoretically run them all off of the same isoSPI bus.
We ultimately decided on Option 2, the centralized approach. This had the best flexibility and was also simplest in terms of responsibility and network architecture.
Next Steps
We're developing 2 boards:
- Carrier board: Handles current sensing and the isoSPI interface
- AFE board: Uses the addressable AFE and 2 balancers, 4 analog muxes into the AFE's aux to support up to 32 thermistors per board
The AFE board will pass an isoSPI line through the board and break off two stubs for the AFE and isoSPI interface for the 2 balancers. The board will be designed to support AFE operation without populating the balancing circuit. A set of jumpers or a DIP switch should be added to support changing the board's address. As an alternative (or in addition), we should support setting the address in the sense harness.
We need to decide on how many thermistors are actually necessary. As a reminder, the more data we collect, the more we need to transmit over CAN and then wirelessly. We can reduce the rate at which we broadcast data, but it's all a tradeoff.
Follow-up
After more research, we've found that most EV manufacturers (including Tesla) only use passive balancing. This whitepaper from Li-Ion BMS is a good comparison between active and passive cell balancing. Notably, there is a difference between balancing and redistribution. The goal of balancing is to equalize SOCs, while the goal of redistribution is to equalize capacities. Generally, it seems like the cell balancing algorithm used has a greater impact than the type of balancing. In addition, we determined that our powertrain, solar array, and aerodynamics will have a far greater effect on performance.
Overall, it seems like the practical benefit between active and passive cell balancing is minimal for our situation, as we're planning on building a matched pack and will be charging for an extended period of time. Since we'll be charging whenever we're coasting and we're looking at 5kW chargers, we should have plenty of time to use a slower balancing cycle. If we're able to implement an SOC-based balancing algorithm, we'll be able to balance anytime we want instead of just at the top of the charge curve, reducing the required cell balance current further. This whitepaper on balancing current is interesting.
So to summarize, the biggest concerns with active balancing are that hardware and software are complex and expensive, and that it may not even be necessary depending on cell tolerance, which is tested in every shipment. For BMS rev 1, the focus is getting the main aspects of a BMS to work reliably, balancing of any kind is really a secondary goal, which is why passive balancing will be used. It will be cheaper to switch to active balancing if we find passive balancing ineffective vs the other way around.
- Kevin Chen (Unlicensed)