DIY BMS design and reflection
- Thread starter BiduleOhm
- Start date
I had just assumed you would read from your computer or phone however an on-board display would be nice
I thought a lot about that and here is what I came with:
The Arduino I use (Nano v3) will not have enough I/Os and probably not enough RAM/flash too, especially with the ethernet driver, to drive a screen (not even a 2x16 chars LCD).
So I'll use LEDs for the most important infos (optional external board) and since the BMS has ethernet you can use anything connected to the same local network (or any other network correctly routed to this one) who has a web browser to see the informations.
What I don't know for now is how advanced the formatting of the infos will be, and I don't know if I can even fit a basic parameters edition interface as I'll quickly get limited by the RAM and flash of the Arduino even with my best efforts (and FYI I'm of the kind who use a char instead of an int if I need to store a small number for example, so I'll really try to fit a maximum of things). You need to keep in mind that at first it was a personal project and I just wanted a JSON API to interface with others DIY devices. I try to open it to a maximum of people but it's not the primary goal of the project so there's some limitations.
Now that's not a big problem if you don't mind having an app on your device which can then format the infos all the ways you want (graphs, ...), have a very complete and pretty edition interface, etc... You can also have a dedicated Raspberry Pi with a screen near the battery (not expensive and you only need one to monitor as many BMS as you want) with said app instead of your PC/tablet/phone.
I know it's not a perfect solution but it's the best compromise I can think about, I hope it's ok for you.
The Arduino I use (Nano v3) will not have enough I/Os and probably not enough RAM/flash too, especially with the ethernet driver, to drive a screen (not even a 2x16 chars LCD).
So I'll use LEDs for the most important infos (optional external board) and since the BMS has ethernet you can use anything connected to the same local network (or any other network correctly routed to this one) who has a web browser to see the informations.
What I don't know for now is how advanced the formatting of the infos will be, and I don't know if I can even fit a basic parameters edition interface as I'll quickly get limited by the RAM and flash of the Arduino even with my best efforts (and FYI I'm of the kind who use a char instead of an int if I need to store a small number for example, so I'll really try to fit a maximum of things). You need to keep in mind that at first it was a personal project and I just wanted a JSON API to interface with others DIY devices. I try to open it to a maximum of people but it's not the primary goal of the project so there's some limitations.
Now that's not a big problem if you don't mind having an app on your device which can then format the infos all the ways you want (graphs, ...), have a very complete and pretty edition interface, etc... You can also have a dedicated Raspberry Pi with a screen near the battery (not expensive and you only need one to monitor as many BMS as you want) with said app instead of your PC/tablet/phone.
I know it's not a perfect solution but it's the best compromise I can think about, I hope it's ok for you.
Last edited:
I’m more of a Teensy fan compared to the Raspberry, especially when interfacing with an Arduino. Teensy has a ‘Teensyduino’ IDE snap on which allows all code to be generated on a common platform. That being said, I was gifted a Red Lion CR1000 display (which has both serial and TCP/IP interfaces with JSON drivers) to be used as my BMS/SCC/AIO HMI. Really looking forward to interfacing with a prototype! PayPal trigger finger ready to pick one up from you...
Well there's one big advantage with http over TCP/IP it's that it is very very standard and a lot of things have it. You can use whatever you prefer/used to.
As long as you can send/receive queries with JSON parameters/body then you should be ok. However I need to look in more details about the queries specs (things like the headers for example) as I never used ethernet on arduino before, I just looked to see if it was feasible or not before doing the hardware.
As long as you can send/receive queries with JSON parameters/body then you should be ok. However I need to look in more details about the queries specs (things like the headers for example) as I never used ethernet on arduino before, I just looked to see if it was feasible or not before doing the hardware.
Another design consideration: for larger DIY packs (4p16s, for example) with a single BMS it is difficult to troubleshoot a problematic cell. Ignoring additional cost, the preferred approach would be to assemble four 16s packs in parallel (16s4p), each with their own BMS. In this situation, each BMS would need its own IP address, ideally with peer-to-peer data sharing between each BMS. Thoughts?
boboxx
New Member
Yes, of course, you can have as many BMS as there is available IPs on your network. My solar install will be exactly what you described in your example: 4 packs in // of 16 cells in series each
For the data sharing directly between BMS however I've not planned to do that but you can have a central device acting as a gateway between the BMS if you want.
Or you can change the code (will be released under the GPL license) if you want to implement direct com between BMSs (but again the flash/RAM space available to add that will be very low as I'll probably use pretty much every byte available... you can always remove other things you don't need for use case if you need more space though).
I'm curious to know what would be the main purpose of direct com between BMSs? I don't want to miss something important (it's hard to think about everything on your own...)
The ESP32 is nice but a bit overkill for what I'm trying to do I think. The power requirement is also a problem, it would probably eat more power on its own than the whole arduino based BMS, and you need to add ethernet com power on top... I also prefer a MCU to a SoC as it's more reliable and doesn't depends on an OS.
All of these reasons are why I chose the Arduino over the Raspberry Pi too.
boboxx
New Member
I was playing with a STM32 befor switching to the ESP32. I'm using Arduino on both and power consumption are very similar. I only have a small pack to monitor and it's in a camper so my project is a bit different than yours.
I just thought about something: the ethernet module is optional (at the hardware level the BMS can work 100 % without it) so for those of you who don't want ethernet you can avoid it and you now have the SPI port available. So you can either communicate directly via SPI or use another module (wifi, BT, ...) as long as it can talk to the arduino via SPI.
You can even ditch the SPI protocol and bit bang your own protocol. You have 4 I/Os available (D10 to D13) so you can use pretty much any protocol you want (UART, I2C, CAN, ...) as they often use only 2 or 3 I/Os.
Keep in mind the SPI port is still used for the ADC (only D12 and D13 though so you have D10 and D11 fully available for you) so you need to be a bit careful with what you do (i.e. don't select the ADC (via D9) while your doing your com and don't do your com while the ADC is used).
Also D0 and D1 (serial port) are not used on the BMS so you can use them to do whatever you want to. But you need to be careful as they are also used by the arduino to communicate via USB.
Of course doing any of this will need some software changes.
You can even ditch the SPI protocol and bit bang your own protocol. You have 4 I/Os available (D10 to D13) so you can use pretty much any protocol you want (UART, I2C, CAN, ...) as they often use only 2 or 3 I/Os.
Keep in mind the SPI port is still used for the ADC (only D12 and D13 though so you have D10 and D11 fully available for you) so you need to be a bit careful with what you do (i.e. don't select the ADC (via D9) while your doing your com and don't do your com while the ADC is used).
Also D0 and D1 (serial port) are not used on the BMS so you can use them to do whatever you want to. But you need to be careful as they are also used by the arduino to communicate via USB.
Of course doing any of this will need some software changes.
Last edited:
Guys/gals, I need your input on something: what about the balancing section being on a separate board from the BMS?
The idea is that not everyone want it so the BMS would be simpler and less expensive for those ones.
It also means I have a better chance to fit the BMS on a 100 * 100 mm board (if you go bigger than 100 mm the board cost tends to be a lot higher) even if I can't guarantee that for now as I haven't started the PCB routing.
If I do that I'll try to make the boards stackable to simplify the cabling.
The idea is that not everyone want it so the BMS would be simpler and less expensive for those ones.
It also means I have a better chance to fit the BMS on a 100 * 100 mm board (if you go bigger than 100 mm the board cost tends to be a lot higher) even if I can't guarantee that for now as I haven't started the PCB routing.
If I do that I'll try to make the boards stackable to simplify the cabling.
I think this is fine as it can lead to using different size in Amps of balancing. Plus might not be needed at all for some.
I exported the current schematic as a PDF (sorry for the black and white but I use custom colors to work with less eye strain and Kicad don't export the background color and always uses white so everything is hard to read if I don't export in B&W), you'll find it as an attachement to this post.
Of course there's still things to do; mainly the safeties (basically a bunch of comparators with some resistors), watchdog (resettable monostable), and connectors + some support components for the disconnect/precharge, balancing and LEDs boards.
I have two spare inputs for temp sensors and one spare input on the final mux before the ADC (I'll probably add a connector so we can measure whatever we want as long as it is between 0 V and 4.096 V relative to B-).
The actual max power consumption is around 1.6 W (0.9 W just for the ethernet), that's not including the disconnect, balancing and LEDs HMI (but that shouldn't add too much as it's mainly control logic) so not too bad I think.
Of course there's still things to do; mainly the safeties (basically a bunch of comparators with some resistors), watchdog (resettable monostable), and connectors + some support components for the disconnect/precharge, balancing and LEDs boards.
I have two spare inputs for temp sensors and one spare input on the final mux before the ADC (I'll probably add a connector so we can measure whatever we want as long as it is between 0 V and 4.096 V relative to B-).
The actual max power consumption is around 1.6 W (0.9 W just for the ethernet), that's not including the disconnect, balancing and LEDs HMI (but that shouldn't add too much as it's mainly control logic) so not too bad I think.
I was pondering the benefits of comparing charge/discharge currents between packs to identify capacity differences.
Oh man you're a genius, multiple balance boards to increase balance current, how come I didn't think about that?
Now there's some limitations (i.e. you can't stack boards forever...) and the first one will be the current limitation of the inter-board connectors.
Stackable connectors are expensive (quick looking yesterday told me about $5 minimum per connector for a classic 0.1" pitch connector) and there isn't 1 million models available, so high current ones would be very hard to find and very pricey. Then we can do stackable connectors for everything but balancing wires and have one connector per board for the balancing wires. It would solve the problem and also solve the other problem of current limitation of the balancing wires, but you would need a lot of balancing wires so the cabling would be a bit less clean.
Then there's the power supply limit: the main power source is a DC/DC converter who takes B+ and outputs +12 V @ 250 mA max and -12 V @ 250 mA max. There's a second DC/DC converter who takes the +12 V and outputs +5 V @ 400 mA max (mainly to avoid the bigs losses of the linear regulator of the arduino).
I currently use half of the max available on the + 12 V, only a few mA on the -12 V and half of the max on the +5 V. I still need to add some things so I'll probably be around 2/3 of the max on the +12 and +5 V when I'm finished. The balance board shouldn't use much (wild guess 10 to 20 mA) but the DC/DC converter isn't a beast either so sooner or later we will cross the limit.
I'd say stacking more than 3 balance boards will be hard. But each balance board will have a decent balance current (I planned 2 to 5 A but there's some serious heat limitations if I keep the dump resistors on the board, so I may downgrade to 0.5 or 1 A, still better than 90 % of the ready made BMS if I'm not mistaken) so even 3 boards should be plenty enough for a big battery.
NB: I'll not do active balancing because it's costly, complex and not really useful for what I do. But if someone wants to design a board for active balancing I'm all for it
Ok, so you can definitely do that with a central device, that would be the easier way (it even makes more sense than each BMS comparing itself with each other).
Last edited:
An alternative to stackable connectors is two parallel rows of 0.1” holes, traced identically. Solder male pins facing one way, female pins on the other side of the board. Downside is additional board real estate required.
Another idea is to use brass standoffs in each of the 4 board corners to pass power rails. +12, -12, +5, gnd.
Another idea is to use brass standoffs in each of the 4 board corners to pass power rails. +12, -12, +5, gnd.
Similar threads
