FlexiBMS Lite - New approach to get past Vaporware stage

Hey, It’s been a while since I’ve been active in the forums, but spring is finally approaching Finland. Roads are finally starting to loose their ice coatings, the air is warming and the light time outside is getting longer, so I feel like it’s to become active again (3D printing some mudguards for my board atm, so I can get on the roads once the ice melts).

I would first like to have a look-back on my first approach for a BMS for the esk8 community (https://www.electric-skateboard.builders/t/flexibms-0-2-hw-under-work-flexible-configuration-and-charging-bms/46117) and identify the problems with it and how to solve them at least partially with the focus being on developing something functional that can be shipped.

The problem can be summarized as “Trying to do too much cool stuff at once” this caused high component cost, while hamstringing performance of the board as a whole. Even though the BMS was functional it had multiple tripping points on it’s way for mass-production.

So my solution will be to simplify/streamline and cut back features to bring down the component cost, lower assembly costs and make the board more sensible as a whole. I will list below some of the changes and the reasons for them:

  • Design ethos/focus should be aimed at the layman esk8 hobbyist and battery builders BMS doesn’t need to loaded with all the imaginable features, because the layman esk8 user doesn’t need them or will never in the most cases use them. Most people just want to charge their battery safely and don’t need to have all their components interconnected. They need something simple, flexible (series cell count wise), reliable and affordable.

  • Remove the whole boost SMPS block It was a cool idea IMO, but now in hindsight it really didn’t make sense. Thermal limitations were the biggest problem, plus it was quite expensive as a block. Easiest solution for this is to externalize this feature to the charger, and even with it, you would still have needed an external power source. Higher charging power ceiling as well due to heat generation being much lower on the board itself. You can get decent battery chargers (CC/CV) from china for good price these days.

  • Remove extra module connector Save costs, KIS

  • Cheaper MCU Moving from STM32L433 to STM32L052, lots of unneeded peripherals. Cuts MCU cost roughly in half from 5€ to 2,5€

  • Cheaper 5V buck SMPS Moving from MAX17502 (1 Amp) to MAX15062 (0.3 Amp). Overkill, price and size.

  • Higher balance current With more board space available and less heat generation due to no SMPS block, we can switch to bigger package bleed resistor and increase balance current from ~90 mA to ~140 mA.

  • Cheaper current sense circuitry ISL28022 is a really good IC, but maybe a bit overkill. I’m testing with a INA180 for price cutting.

  • Full blocking charging switches Problem with the earlier implementation was that battery voltage was always present at the bulk charger connector (flowed through the P-channel body diode). This was a safety concern for me personally. Charging switches are now 2 n-channel mosfets with common drain, controlled by BQ76200, enabling a fully blocking setup.

  • CAN and USART removed Cheaper MCU doesn’t have CAN support. Maybe USART can have some solder pads, but no connector. Opinions welcome.

So what are the planned BMS’ features?

  • 3S-12S series cells support Flexible series cells support
  • 140 mA balance current Higher balance current
  • 9 A max charging current Higher maximum charging power
  • Pack temperature NTC probe for thermal monitoring Solder pads or a dedicated connector.
  • USB connectivity for parameter configuration and charging monitoring Configurable parameter: Max charging current, charging end current, max cell voltage, cell balancing behavior, temperature limits.
  • Buzzer for audio signaling Interested in opinions on implementation
  • On board status LED Interested in opinions on implementation
  • Smaller PCB With a lot of components removed, I can shrink the board down further.

I’m planning on splitting the FlexiBMS into a Lite and Basic versions, with Basic being more feature rich and Lite being the no-bells-and-whistles version meant for battery pack builder integration/basic functionality for controlled charging.

Layout WIP picture. image

Currently when I’ve been sourcing the components from Digi-Key with the planned amount for 100 boards and the total is standing a bit over 2000€ or 20€ per board, which is MUCH lower than with the earlier approach and is something that even I feel safe to pull a trigger for ordering.

I aim the sell price to be between 40€-60€

And as always I welcome comments and questions from the community and invite everybody to the conversation.


I would keep CAN, go for STM32L0 ?

would be careful here, those resistors will get real hot even when only pulling 1/2W

probably useless inside an enclosure, especially it’s a pretty big component


Only STM32L4’s have CAN connectivity (re-checked).

Will have to check thermal performance once I have the first prototypes on hand.

This was one of the concerns with the buzzer implementation. It’s cheap though, only 29 cents in volume, but quite large size-wise. Could maybe even shrink down the board further without it. My other question is how should the audio warning be implemented if there isn’t a button on the board or externally to clear warning states? Play warning tune for couple seconds and repeat after couple of minutes if warning state is still true, let’s say for example cell undervoltage.

And considering the BMS might wrapped in a kapton layer and inside a foam padded enclosure (pic below)… Not sure if you need the status LED for the same reasons…

My mistake! i meant STM32F0

1 Like

I like the idea to connect a Bluetooth module to the BMS and get the info in my phone, even if it’s only monitoring I’m happy with it


I feel like uart connection to the VESC is a fer better idea the BMS having its own bluetooth module, most peoples VESC already has some type of wireless module built in and support relaying BMS information to phone apps.

Additionally a small charge only BMS paired with a Focbox Unity which already has antispark built in could be super low cost and easy settup configuration.


What would you say about the idea of the Lite being the barebones version and then making the Basic, bigger and more expensive with better connectivity?

1 Like

So would say it would make sense to have the bare-bones charge-only Lite version, and then a Basic version with better connectivity?

By the way, here are some of the cheap series cell specific chargers that I mentioned:






11S charger seems to be a bit exotic


I think you need some sort of power switch in your system somewhere to shutdown in fault conditions. If there was a “lite” charge only version with no large (expensive) power switching then adding UART (basically free) allows you to send shutdown command to Unity or similar with built in antispark.

Im not aware of another bms that works this way. it could result in a very low cost BMS with lots of features that is perfect for easy DIY builds.

Then for the “power users” a variant with high current power switching, bluetooth, CAN and all the fancy stuff built in. But honestly not everyone needs these things and there are lots of products that already offer these features. what we seem to be missing at the moment is a cheep, simple reliable BMS for the new generation of more integrated VESC’s that is arriving.


I would keep CAN or build in wifi or bluetooth. - ditch the buzzer and just go with an led that can show charging states eg: charging->balancing->chargedandbalanced.

I think the trick will be just giving a good compact BMS with solid specs and some connectivity but importantly shows the info quickly and simply.


& @Friskies

Good point. If the buzzer is ditched, there is ample space for a dedicated USART connector, which can be hooked up to a VESC-derivative or used to disable an independent E-switch, if it supports low-voltage fault signal.

CAN would cost roughly 2€ in components to implement (transreceiver + STM32L4). Worth it?


This looks amazingly small! Good work, after some time passes and people prove its reliable, I will recommend it to my battery customers to support forum members :slight_smile:

This probably is answered in the other thread, but does this bms balance all the time or only when charging?

1 Like

Please keep CAN :slight_smile:


So this BMS is not passing the main power and just monitoring/balancing the cells?

And yes pls keep CAN

1 Like

I don’t see any reason why it couldn’t balance when not charging. At that point it’s just firmware implementation question. It’s going to have to monitor cell voltages anyway to look for un-balance, under- and overvoltage conditions.

I’ll look into integrating it tomorrow.

This planned Lite model won’t have a discharge path mosfet control, but is rather just used to control charging via external charger and then monitor cells and communicate via USART or CAN.

The Basic model could have discharge path control mosfets integrated onto it.


OMG THIS IS WHAT I DESIGNED IN MY HEAD LIKE A MONTH AGO :smiley: … after I realised that I won’t get DieBieMS and that I wasn’t happy with the discharge current limitations anyway.

Can I go in as a prototype tester/builder(that’s my actual work)? I can solder down to 0402 no problem or whatever uC package.

Make sure you design it to alarm the VESC/Unity through CAN when one section is low on voltage and trigger shut down in the ESC

Here’s a updated block diagram for the board


I’m planning on keeping the MCU always powered on via the LTC6803 5V regulator output dropped down to 3V3 via linear. This is a low power supply, about 4-6mA max and power all the other devices through the 5V buck smps and another 3V3 linear. I can then shut them down by disabling the 5V buck while still leaving the MCU powered.

I also checked the STM32L431 datasheet and discovered for my delight that most of the I/Os are 5Volt tolerant, so I can for example use 5 Volt CAN ICs without level translator between the CAN and MCU.

1 Like

Not 13s capable? A button integration would be sweet. Side note, someone could thing of a design for a bms and antispark in a single unit maybe. With simplified connections.

Isn’t 13S a bit exotic? 12S should be plenty high for the majority of the users. Implementation costs also jump a LOT when moving past 12S if you also want balancing.

What would this button be used for? If it’s mean for the anti-spark switch, then why not wire the switch directly onto that?

This is the Lite version, Basic version would most likely be bigger in size and include integrated discharge path control switches.

SIDE NOTE I have taken couple days free from work and I intend to use the rest of the week to design the first iteration of this BMS, so I will be available on the forum for the rest of the week.