openinverter forum

I recently acquired some LG 16S battery modules. Each module contains an integrated BMS slave board with voltage measurement and bleed resistors. At the heart of these is a TI bq76PL455A chip. This chip has a daisychain communication protocol allowing up to 16 modules to be connected in a chain and controlled.

I have developed a BMS for these modules, allowing them to be monitored, balanced, and connected to a CAN bus. It was necessary to develop custom hardware to communicate with them. Full open source hardware, software, and documentation can be found here: https://github.com/catphish/lg-daisychain/

The module supports the following functionality:
* Automatic balancing of all cells in the chain
* Pack and cell voltages transmitted on CAN bus
* Temperatures transmitted via CAN bus
* Balancing target can be set via CAN or standalone

Some photos of the batteries and my BMS module:



I don't know how many of these batteries exist, or whether there are other batteries out there using this same chip, but hopefully this will be useful. I will certainly be using it in my own projects.

I have also built a version of SimpBMS that works with these modules. This is only very lightly tested, and probably requires more work, but could be useful for anyone wishing to integrate these batteries: https://github.com/catphish/LG-BMS

Nice project!) Are you have isolation at CAN BUS?

dimonlipko wrote: ↑Sat Dec 11, 2021 12:03 am Nice project!) Are you have isolation at CAN BUS?

My BMS module is powered from the low voltage system, so the CAN bus is not isolated, however the interface to the battery slave boards is isolated (both in my board and in the batteries), as the slave modules are powered by the HV batteries.

Nice work. Will be following progress.

RetroZero wrote: ↑Mon Dec 13, 2021 8:28 am Nice work. Will be following progress.

Thanks. This version is essentially complete (just need to do more testing with the SimpBMS firmware). It will balance one string of cells without any issues and CAN communication all works as it should.

These were originally developed as a simple battery <> CAN interface, but I've come to realise that I probably want to develop a more complex version with full BMS functionality.

* Multiple battery connections - I will be running 3 strings of cells, so it makes sense to run them with a single master BMS rather then 3
* Charger control - It makes sense for this board to do charger control including EVSE comms and cell voltage cutoffs.

I will therefore be developing a board with:
* 3 x Battery connections
* CP and PP connections
* Wifi header for easier configuration

These modules are used in Volvo PHEV's, I don't know what exact modules are used in what models. Also the 'London Cab' PHEV's have 3 strings of these style modules.

They exist also in 10s, (others also maybe) but I don't know if the BMS is the same.

And the BMW PHEV modules! (16s). Not sure how I missed this, seem to have been doing some work on these chips in tandem haha

https://github.com/mjc-506/bmsSerial contains working code to use the BMW CSCs, but I need to document the small hardware mods required (breaking into the UART connections on the first CSC)

mjc506 wrote: ↑Wed Dec 22, 2021 10:01 am And the BMW PHEV modules! (16s). Not sure how I missed this, seem to have been doing some work on these chips in tandem haha

https://github.com/mjc-506/bmsSerial contains working code to use the BMW CSCs, but I need to document the small hardware mods required (breaking into the UART connections on the first CSC)

Cool, I'll have a look at your code.

I wasn't comfortable breaking into the serial port on the first module, and luckily was able to communicate using the daisychain port. I think this makes for a neat solution.

I have no idea how I totally missed the other thread on this subject!

I chickened out of playing with the daisychain comms Yours looks much more 'plug and play' and ensures isolation, which is definitely a good thing. I'm using a level shifter at the moment, so battery ground = system ground, which is not ideal... an opto or two would be a better solution (and what BMW uses in their primary CSC)

I've built a second version of this with two slave BMS connectors. This will allow me to manage my full 18 module pack with a single device. It also matches the form factor of my new charge management unit, which adds the missing connectivity for EVSE etc.

How are the Pi Picos for power management? As having multiple micros running when the car is powered off can start adding up quickly.

tom91 wrote: ↑Sat Dec 25, 2021 10:54 am How are the Pi Picos for power management? As having multiple micros running when the car is powered off can start adding up quickly.

It's not nearly as impressive as the STM32, but it should draw 5mA at 3.3V when it's sleeping waiting for a pin wakeup, 25mA when running, and about 10mA when seeping with a timer. So with the right code, I hope to achieve at worst 20mA (3.3V) for the 2 boards, or 10mA from the 12V battery.

This isn't awesome, but hopefully a lead acid battery can maintain this for a while. I haven't implemented any kind of 12v voltage monitoring, so will have to be mindful of this.

I will do some real testing with my own code and report back when I can. In the meantime, there's a video here with someone else's tests, on which I am basing my assumption. These match up with the datasheet.



How does this compare to the teensy?

tom91 wrote: ↑Sat Dec 25, 2021 10:54 am How are the Pi Picos for power management? As having multiple micros running when the car is powered off can start adding up quickly.

To elaborate on my previous post, the current situation is that at 12V my boards consume approx:
* 10-11mA when active
* 6.6mA with the CPU core stopped and CAN active (this is my main idle state)
* 4.8mA fully sleeping

Unfortunately, I forgot to connect the sleep line of the CAN line driver to the MCU. If I did, an estimated 2.5mA reduction could be achieved by putting the transceiver in low power RX-only mode.

V2 of this BMS has now been completed. This is the version pictured above. It features connections for 2 battery chains, supporting a maximum of 32 modules (2x16). The firmware has more focus on standalone balancing and power saving. For my project it will be coupled with a charge controller, and so it outputs maximum and minimum cell voltages and temperatures for charging safety. It has a low power sleep mode and can be woken by CAN messages.

All hardware design, schematic, and source code here: https://github.com/catphish/ti-daisychain-bms

Since completing this. I have come to the conclusion that 3 improvements would still be beneficial if there is every a v3:
* 3 battery connections, just for neatness when running the modules in a 6s3p configuration.
* Connect low power pin on CAN transceiver to MCU to save approx 2.5mA in sleep mode by putting CAN in RX-only mode
* Add a 12v GPIO input to allow the device the option to wake on a 12V line rather than just CAN

Following testing of the v2 board, I have made the decision to build a v3 board, with the previously mentioned improvements. New design features:

• 5v - 12v power supply
• 3 x bq76PL455A daisychan interfaces - separate connectors for better HV isolation
• 1 x CAN
• 2 x 5v-12v "wakeup" inputs
• Readily available Molex micro-connect sockets

In order to improve battery life when idle, the new design aims to add a low power sleep mode, shutting down all CPU clocks, all daisychain interfaces, and the CAN interface. It will then be woken by a voltage on either of the wakeup inputs, which I imagine would come one each from the charger and the ignition switch. This allows battery monitoring to be enabled only when needed, and then for the module to shut down on its own after any necessary balancing is complete.

Schematic at https://raw.githubusercontent.com/catph ... ti-bms.pdf

Once I have the boards, and I've had an opportunity to write the power management code, I will update again, and hopefully have a finished device! I will also provided some updated power usage numbers, as I expect significant improvements with the ability to fully sleep the MCU and CAN interfaces.

The new v3 BMS boards arrived yesterday, and after some testing today, I'm very happy to say, I'm now happy with the results. Communication with CAN and 3 x 16 x bq76PL455A modules is working. Idle mode now consumes approx 600uA! The device can be woken by ether of 2 x 12V inputs (one for when charger is enabled and one for when ignition is live).

All hardware and software sources available at: https://github.com/catphish/ti-daisychain-bms/

Let me know if you have bq76PL455A modules and are interested in using one of these.

Great progress. No now just to start tying all these new ecus together.

tom91 wrote: ↑Tue Jan 25, 2022 4:29 pm Great progress. No now just to start tying all these new ecus together.

Thanks, and yes indeed! For my own build I'm trying to keep things both simple and modular, so each module will hopefully work independently, but able to act on messages from other modules in an event driven manner as needed.

If the charge controller receives a "max cell voltage" from the BMS that it's not happy with, it will shut down charging, but I don't envision a more involved interdependence.

My original plan was to use multiple slave "gateway" modules, and a central module (yours in fact) to sit in the middle and control everything else, but having written the code to make that work, I annoyingly decided to take a totally different direction! I still have lots of integration to do, and most of my electronics won't be of much interest to anyone else, but I'm hoping the tech in this BMS master might be of value to anyone else with these battery modules.

Very nice work!

Do you know whether these will work on any system based on the bq76PL455A? I'm thinking of the BMW hybrid packs here. Are you aware of any configuration on the chip, that BMW might have done, that could prevent it from working?

Is the data that flows on the battery daisy chain bus the same as the protocol documented for the UART (but with the extra physical bit encoding)? Have you looked at receiving the heartbeat on the fault lines too?

I'd been planning on using SimpBMS but this looks like it will integrate much more neatly and frees things from the BMW pack sizes.

Thank you

Pete9008 wrote: ↑Thu Apr 07, 2022 6:37 pm Do you know whether these will work on any system based on the bq76PL455A? I'm thinking of the BMW hybrid packs here. Are you aware of any configuration on the chip, that BMW might have done, that could prevent it from working?

Is the data that flows on the battery daisy chain bus the same as the protocol documented for the UART (but with the extra physical bit encoding)? Have you looked at receiving the heartbeat on the fault lines too?

I'd been planning on using SimpBMS but this looks like it will integrate much more neatly and frees things from the BMW pack sizes.

Thank you

This should work with any bq76PL455A based battery if it has a daisychain connector. I don't believe the OEM could have done anything to prevent this working. Some config can be saved in the chip, but they can always be dynamically reprogrammed by the daisychain interface, which my implementation does (non-permanently) on every boot.

Yes, the protocol is identical to the UART protocol, just with the special manchester encoding (yay). I did not bother with the heartbeat lines in my implementation. I believe they would be simple to implement, (the same hardware as the data lines, with a simpler protocol) but didn't seem necessary for my use.

As far as I know, SimpBMS has no way to support such a battery pack, unless it has its own slave modules that I'm not aware of?

Please do let me know if I can help in any way.

I've actually been testing this BMS in a couple of real cars this week. One substantial issue that's come to light is that the 1nf isolating capacitors on the data lines only allow a very short cable run (perhaps 0.5m). I have started removing (and bridging) these capacitors on my board, but if I build another batch, I will replace them with much larger capacitors. This problem might be exacerbated by the pull-up / pull-down resistors I've put on the data lines, so I think I would also make these larger values too.

That's great, thanks. Bet it was a relief when you found it was the same protocol!

I thought that SimpBMS could support the BMS packs but only by going through the BMW master via CAN (and so restricted to standard BMW pack sizes), could be wrong though, still learning.

Agree on the 1nF and 1k. 1nF sounds low but it's what TI specify. Have used larger pull ups/downs on RS485 quite happily in the past, you do need something there though (unless the TI chip provides them?).

Assume the 50cm limit is just from your board to the first module, not between the modules? If the former then I can't see it being a real issue (I'd plan to build the board into the first BMS module, replacing the BMW master, so the link would only be 10cm long - although thinking about it at that point isolation isn't needed anyway!).

Pete9008 wrote: ↑Thu Apr 07, 2022 7:21 pm That's great, thanks. Bet it was a relief when you found it was the same protocol!

I thought that SimpBMS could support the BMS packs but only by going through the BMW master via CAN (and so restricted to standard BMW pack sizes), could be wrong though, still learning.

Agree on the 1nF and 1k. 1nF sounds low but it's what TI specify. Have used larger pull ups/downs on RS485 quite happily in the past, you do need something there though (unless the TI chip provides them?).

Assume the 50cm limit is just from your board to the first module, not between the modules? If the former then I can't see it being a real issue (I'd plan to build the board into the first BMS module, replacing the BMW master, so the link would only be 10cm long - although thinking about it at that point isolation isn't needed anyway!).

Oh, I think you're right about SimpBMS and CAN. I didn't realise the BMW pack had a master module with CAN. That's certainly a neat solution if it works, but as you say, limited to OEM pack size.

I found the pull-ups / pull-downs were necessary, but never played with the values. The datasheet does mention them (I guess they're not necessary with their ASIC), so I guessed and perhaps made a mistake choosing 1k. The datasheet recommends 1uF but this can obviously be larger for longer cable runs. I didn't give it much thought when I was developing with a short cable, but definitely think it's worth tweaking. In the meantime, I simply remove them and rely on the isolation at the battery end.

The length limit is between the BMS and the first battery, and also (in theory) from each battery to the next. I wouldn't expect the latter to be an issue as batteries are normally immediately adjacent, and I suspect the OEM ASIC can reach much better distances than my implementation anyway.

Just curious - how did you do the Manchester encoding bit on the Pi, does it have support for it in the UART? Had a quick look at the code but can't see where it is done.

Pete9008 wrote: ↑Thu Apr 07, 2022 8:21 pm Just curious - how did you do the Manchester encoding bit on the Pi, does it have support for it in the UART? Had a quick look at the code but can't see where it is done.

It's implemented in PIO. This allows you to write extremely low level IO on the Pi Pico. The code is here, it's assembly, but I hope the comments are helpful in explaining it: https://github.com/catphish/ti-daisycha ... co/bms.pio