Its time to provide your valuable feedback on another potential Open Source innovation: Open Source Flexible Battery Management System for off-grid energy storage. One of our core evaluation criteria for every innovation solution is to understand if the proposed innovation is addressing the sector level need. We decide this based on your interest to adopt such solutions in your business operations, should this solution get funded and available as open source.
Share your feedback directly in the forum here for everyone to see and participate.
These are the questions we are trying to answer:
Would the list of deliverables be sufficient for you to adopt this innovation?
How disappointed would you be if we did NOT go ahead in developing and open sourcing this innovation?
e.g. Very disappointed, Somewhat disappointed, Not disappointed
Can you share potential scenarios when this innovation would NOT work for you?
Anything else we should know?
Open Source Innovation: Productive use appliances like milling machines as well AC microgrids require safe, reliable and powerful Li-ion/LiFePO4 batteries . This project will develop a modular and fully open-source Battery Management System (BMS) for 12V, 24V or 48V systems (up to 16 cells in series) and continuous currents of up to 100A. Multiple battery/inverter units can be connected in parallel to flexibly increase the power.
Proposed Deliverables
The deliverables will include all documents to rebuild, manufacture and integrate a battery including the developed BMS:
Electronics hardware (schematic and PCB design made with KiCad)
Heat sink and plastic enclosure design (made with FreeCAD)
Embedded software (based on existing Libre Solar BMS firmware and Zephyr RTOS)
Software to communicate with the device via mobile phones or computers (payment system integration, diagnostics, configuration, remote management)
Cloud integration via MQTT protocol
User Manual containing extensive documentation of all features and functions
Hi there, decent quality Second Life battery cells from electric cars will soon be available in abundance. These can be cheap storage components for minigrids and stand alone systems for rural electrification. 48 V busbars are the standard for safety purposes and battery inverters for this voltage level are widely available. There are some commercially available BMS on the market. To make developing countries more independent of these electric equipment suppliers from industrialized countries, an Open Source product makes sense. The commercial products are also far from perfect. Flexibility is missing. Parallel opreation of cells is very much limited in most cases. An Open source product may help providing the flexibility required to roll out Second Life Li Ion in minigrids for rural electrification. The focus should however not be on LFP but NMC technology, as this is the type of second life cell coming from the car industry. The more complex LFP technology may be an added value for new systems.
The BMS will provide support for both NMC and LFP cells (and basically any other cell chemistry) as it will be possible to calibrate the open circuit voltage lookup table, safety thresholds etc. in the firmware.
As Nico already stated, LFP is the more complex technology. State of charge estimation is more difficult and LFP cells also require larger balancing currents as they can only be balanced at the very end of their charging phase. This adds unnecessary hardware cost for systems where it’s not needed. Hence, the current plan is to have additional headers which allow stacking of an active balancing board based on (rather expensive) chips like EMB1428Q or LTC3300-1. This way the hardware can be easily adapted to the actual application.
We at Connected Energy are interested in this and have already utilised some of the products from the Libre Solar project. An innovation that would allow locally upcycled/assembled batteries, and supports the move away from lead acid, will be usable and highly useful.
A bit more information on the cloud communications would be appreciated. Many thanks, Vijay.
We at Nunam are developing tech to facilitate adoption of second life Li batteries, which as some of you have stated is an important part of the energy eco-system going ahead. For the 2nd life pack Energy Storage Systems (ESS) that we are developing these are the requirements we have, which look to be satisfied with this proposed BMS.
As Martin mentioned ability to do Active balancing would help second life packs, especially as we have seen one or two weak cells in parallel in a XsYp configuration (14s4p for example) bringing the entire pack down.
When multiple XsYp packs need to be used in parallel to increase the capacity, each of these packs would need their own BMS. This increases the complexity significantly which is well described in this article by Orion BMS. In this case what we see is there is a need for (a) option to enable either only charging or only discharging by the BMS and (b) communication between the BMS to synchronize their activities especially when there is a fault in one of them with host knowing which has fault.
An external power board would help as this can be varied for different capacities of batteries and also can be replaced by a contactor based system if needed.
For battery modeling and prediction which will boost second life adoption, higher accuracy in cell voltage and pack V/I measurements would help. One possibility would be to place current measurement sensor with ADC close to shunt resisitor in the power board.
Many of the hybrid inverters with grid/solar charging don’t have explicit outputs to the BMS for charging. So detection of charger/charging is tricky and important. One way is to have two levels of cutoff, a higher voltage where only discharge is cutoff and a lower voltage where both charging and discharging is cut off.
Thanks for this initiative. This open source BMS would go a long way in helping us at Nunam.
The hardware will be equipped with a Universal EXTension port which allows to plug in different communication modules. Multiple off-the-shelf modules are available at Olimex and some more board designs (e.g. for LoRa and WiFi) are available as open hardware from Libre Solar.
On the firmware side Zephyr RTOS provides many communication protocols already out of the box, so it will be fairly easy to adapt the firmware to meet particular requirements. Most important communication features:
MQTT via GSM
Zephyr has a built-in generic GSM modem driver which requires comparably high amount of RAM and flash because it uses its own IP stack instead of offloading it to e.g. SIM800. As an alternative, the Cicada library can be used. Also the Cicada hardware module can be adapted for the BMS with minor modifications.
LoRaWAN
Provided by Zephyr out of the box and successfully tested with Libre Solar charge controllers.
WiFi / Bluetooth
This will be provided using an ESP32-based extension module running esp32-edge-firmware and communicating to the BMS via the ThingSet protocol. The firmware supports HTTP and encrypted MQTT via WiFi already and is soon going to be extended to support Bluetooth aswell.
Not especially – our current strategy is to purchase pre-assembled packs including BMS. We may change that in future but in the short term we aren’t planning to develop our own BMS.
Would recommend the designers consider the supply chain of chips before locking in a design based on a particular microcontroller. Certain popular STM chips have been incredibly difficult to source recently due to the global semiconductor shortage, and it is uncertain when the supply will return to normal.
Recommend choosing a chip with no current supply chain issues, and keeping design as flexible to other chips as possible.
Overall, we are interested in this and would consider adopting it depending on the cost benefits we could get as compared to our current solution.
We at ‘Specialised Solar Systems’ strongly encourage the development of this highly adaptable BMS. Energy storage is a key asset in our micro-grid systems, and consequently we recognise the importance and need for a well designed and highly configurable BMS. We would greatly benefit from the plethora of customisation and communication options inherent in the open source nature of this offering.
The list of proposed deliverables ticks all of our boxes
It would be greatly disappointing to us for this project not to be awarded
A small concern arises around the availability of STM32 processors.
Compatibility with active balancing systems as well as support for multiple parallel batteries are amazing features for any BMS…
Thanks all for the additional feedback. Really happy to hear that the proposed features would match your expectations.
I agree that the supply shortage of STM32 is a real pain at the moment. As we will use an external analog frontend IC, we don’t rely on special features like good ADCs, timers, etc. for this design, so we are quite free to choose any microcontroller that has sufficient RAM and flash and is supported by Zephyr. I was thinking of adding a second footprint for a Nordic chip with Bluetooth (e.g. nRF52840) as a stuffing option. If anyone has a preferred microcontroller series other than STM32, please let me know so that I can further investigate the feasibility.
I recently came across the RP2040, which seems to be widely available, and very well priced. As far as I can see, the Zephyr support is still in early development - although I feel confident that the popularity of this micro-controller will encourage adequate Zephyr adoption within the next 12 months. External flash also allows for more flexibility, extended logging capabilities, and sophisticated lookup tables for SOC estimation.
Great innovative, and would very much like to see such work in an open domain!
Few questions:
a) Which battery chemistries will be supported?
b) Can these BMS be operated in parallel?
c) Which battery health indicators (SOH, SOF etc) will be computed?
d) Which communication channels will be supported (CAN, 485, UART, I2C, BLE etc)?
e) Will the design be capable of working with second life cells?
f) Will the design be capable of working with second life modules?
g) Which data recording functionalities and storage capacity will be available (to collect data for advanced analytics).
h) Is it targeted to meet specific standards (e.g. automotive)
In terms of deliverables, it would be great to share a bit more detail about the Android APK and IoT backend part?
a) It will be tested and calibrated with LiFePO4 (LFP) and NMC/Graphite cells, but other chemistries like NCA/Graphite or even Titanate-based cells will also be supported, as all thresholds and lookup-tables for OCV, etc will be configurable.
b) Yes, to a certain extent. The batteries have to be of the same type and need to be equalized prior to connection in order to prevent high equalization currents. For dissimilar batteries (especially with different numbers of cells in series), parallel operation can be achieved by coupling them to the same AC or DC grid.
c) SOC via coulomb counting will be included for sure. We’ve currently got a student writing his master thesis on more sophisticated SOC + SOH estimation based on Kalman filters. These results will also go into the firmware, but we don’t have enough data yet to estimate how accurate the indication will be. In addition to that, multiple error and status flags will be continuously reported (including overvoltage, overcurrent, short circuit, over/under-temperatures etc.).
d) CAN, UART, I2C and SPI will be on-board. BLE, WiFi, GSM, LoRa, RS-485 (and others) will be possible via extension modules for the UEXT connector.
e) Yes.
f) Yes. Only the wiring harness will have to be adapted.
g) Main idea is to send out the data continuously to the cloud. There is currently no large data storage planned on the device itself, it is possible to connect an SD-card to the UEXT connector, though. If there is high demand for a larger on-board flash memory, we can include this to the requirements. We are planning to have a community-based requirements definition phase at the start of the project.
h) Developing a fully certified BMS for automotive applications requires a budget in the millions of dollars range, which is out of scope for this project. Also a certification would have to be done on system level and and include more parts than the BMS. However, we will follow best practices to provide a good basis for a safe system and a potential future certification: The most safety-relevant protection mechanisms like over-voltage and short circuit will be implemented in hardware on a dedicated IC, so that they are fast and not directly affected by software bugs. In addition to that, the firmware is running on Zephyr, which will soon become certified according to ISO 61508 (similar to ISO 26262 automotive functional safety). This is quite unique, Zephyr will be the world’s first open source RTOS with functional safety certification.
The IoT backend is out of scope of the project, as most companies will already have their own solutions. The approach is to make it easy to integrate with existing backends by using Zephyr, which provides APIs for relevant communication protocols already.
Regarding Android app: For other Libre Solar projects we are currently taking a web-based approach, where the ESP32 provides a web interface that can be accessed directly with any browser. For the Bluetooth interface to the BMS we will integrate the same frontend into a mobile phone app using Apache Cordova or Capacitor, which allows to deploy the app even for iOS and not only Android.
I hope this answers your questions. If there are some more open points, just let me know!
Yes, please! We at Agsol would be very much interested, this would be a perfect fit for our product development roadmap!
We do need a BMS that can handle LFP, can handle 48V, and is flexible to fit to our application, so all the specs are spot on! We don’t need a 100A rating, only a fraction of that, but it’s always much easier to downgrade specs, than to upgrade them. One question: would this solution has some basic serial communication capability? To query basic measurements, like voltage, SOC, (or maybe even current)?
Answering the posed questions:
Would the list of deliverables be sufficient for you to adopt this innovation? - Yes, more than sufficient!
How disappointed would you be if we did NOT go ahead in developing and open sourcing this innovation? - Very disappointed; we would have to invest significant internal resources to do basically the same.
Can you share potential scenarios when this innovation would NOT work for you? - Nope.
Hi there, i am from OpenSourceEcology Germany and a strong OpenHardware-enthusiast. As far as i know there are already a few nice BMS-developments in this field, that are based on the ISL94202, even one from the LibreSolar project (the BMS 8S50-IC) which are quite nice but restricted to 12V or 24V.
We have a need for a 48V BMS in the field of rural micro- or nano-grid storage applications and would quite appreciate to see this voltage range covered too. The advantages of an OpenHardware-approach (like flexibility and extensibility) in combination with sophisticated communication protocols as essential prerequisite for an intelligent load-management would perfectly fit to our needs, so we would love to see this project coming into life.
Furthermore we know the good work of LibreSolar from other related OSHW-projects like the MPPT-chargers and therefore we are convinced on their expertise.
We have been introduced to this community by @vsbhopal1 a partner providing us with remote monitoring charge controllers for our standalone solar installations in West Africa. Since March we have been converting ICE motorcycles into Electric motorcycles and running into a major challenge. It is expensive for us to ship in assembled Li-Ion batteries compared to us assembling locally. To do so, we will need a flexible BMS.
We would like to thank OSEA for the hard work on developing an OS Flexible BMS and we are eager to be one of the first to test them out in our various solar applications.
Please let us know how we can help accelerate the process.