FlexiBMS Public Support, Feature & Troubleshooting Thread

As the FlexiBMS Lite boards are starting to be sent to a growing audience and the user base starts to grow bigger. I think now would be a good time to start the official support and troubleshooting thread where users can report problems and ask questions as they come up.

New FW releases will be found at Releases · SimosMCmuffin/FlexiBMS_Lite_FW · GitHub and most likely they will at the beginning consist of of lots of minor FW with bugfixes.

I will be writing guides at Home · SimosMCmuffin/FlexiBMS_Lite_FW Wiki · GitHub . Users can also ask for new guides and give feedback on the existing ones.

Hopefully as the community learns more about how to use the BMS and it’s usage, it can start helping other newcomers without always asking the experts. AKA, community helping the community.

I’ll be here at the start as there will likely be un-found firmware bugs left that need fixing, so I’ll be here to give low-level hardware and firmware support. If you’re interested in Metr or Davega integration, I’d say ask about that in their respective forum threads.


Battery Pack wiring guide:

All configurable parameters and their descriptions (will be updated with future FW updates):

Flashing new FW image via USB connection:


I would like to request a feature

  • report estimated time until full charge :pray:

And while on that, charge rate for a configurable consumption in km/h or km/min

And that being displayed on Metr off

1 Like

0.7 is out.
Bug fixes, improved balancing temperature handling and storage discharging implemented.

Parameter list updated

Commands list added

Quick start guide (will likely be expanded later)

Serial terminal setup guide

Serial terminal use guide


A simple version should be easy to implement, but an accurate one is a surprisingly hard thing to implement, as you would need to characterize the pack. I suppose a generalized discharge/charge curve can be used and that can be good enough to give the estimation based on configured pack capacity and charging current measured.

I suppose this time-remaining-to-full value would live on the BMS that connected devices can request?

I have discussed about this with an ex-Nokia cellphone hardware engineer (my current team leader) and all the problems and challenges that there were. In their case it was the accurate battery remaining percentage display. They used available fuel-gauge ICs from major suppliers, but there were still discrepancies between the indicated and actual battery capacities.

You mean like tesla shows when it’s being charged how much range is being charged back to it in an hour?

Being displayed on Metr off?

Could you clarify?


Did you forget to update commands.c


with new nonVol parameters? :slight_smile:

1 Like

The guys from Grin have a pretty neat charge simulator with a bunch of batteries characterized, you could take the most popular cells with a few data points at different charge currents and interpolate the rest


Exactly, useful for quick breaks when you just need enough to get home

Just so @rpasichnyk makes this number available on Metr somehow so we can see how fast it’s charging

1 Like

As asked by @SimosMCmuffin this is a copy of my original question I wrote privately and a copy of the answer:


1 Like

Hi! I received my FlexiBMS for testing, thank you! It is HW 0.5-1 version. I will be using this with 12S4P Molicel P42A pack, Unity and Metr Pro.

It had FW version 0.4, and I successfully updated it to 0.8. It took about 10 retries but eventually succeeded.

I noticed that out of the box, the FlexiBMS did not have cal values applied. No biggie. I was going to upgrade the FW anyway. So resetted the config values to defaults after flashing, and started applying the calibration values. I was able to set the gains, but it seems that there is an interesting bug when reading in the values. I sent:


Which returned:

$19=1.0080 (Gain for Battery voltage ADC conversion, Float)
$21=1.0181 (Gain for Charger voltage ADC conversion, Float)
$23=1.0139 (Gain for Current sense ADC conversion, Float)

Looks like $19 is reading in with a small error in the last decimal. That’s probably very insignificant but I suppose it would be good to fix it. If I send in 1.0082, then FlexiBMS returns the correct gain of 1.0081.

1 Like

Yes, at this point this is still the easiest way to update the FW that everybody should have access to. Maybe at some point make a little GUI app that will automate the flashing process and retry automatically.

This is most likely a rounding effect in the value reporting function for floating point values, as it only reports to 4 decimals and there is a conversion from float to integer that happens, so I’m suspecting that it rounds the last decimal down in some cases.

AKA, the 1.0081 value is actually something like 1.00809xxxxxx once it gets converted to real float value and then the last decimal gets round down when it’s turned back to integer from float, but the value in the memory should be an accurate one.

1 Like

I will be plugging in the BMS in a few minutes and doing my first balancing and charging with it. A couple of things I noticed:

  • The documentation does not have the pinout for the FlexiBMS. I know it is available on the underside of the PCB, but guess who coated the PCB with black liquid electrical tape… :grin:
  • The quick start guide could use a section for “BMS bringup” or similar. I am currently sitting here with my laptop connected. I know that I have to plug in the pack first and then plug in the balance connector, but can/should I have the USB connected while doing that?
  • As a continuation to the last point, what should I look for in the BMS status to verify that everything is going well? (i.e. what’s the syntax of the status msg stream)?
  • Looks like status stream might be reporting 5374mV for each cell when pack is unplugged. Why doesn’t this cause any active or latched faults for cell overvoltage? The max cell volt limit is set as 4250mV. My FW version is 0.8.
  • I think I will go to the Metr thread to ask about this, but is there anything I should do in VESC/Unity side to enable it to do something smart with the CAN? Anything I should know about CAN other than just connect CAN-L and CAN-H?
  • What’s the LED on the PCB telling me? It’s blue. Can it show faults for example?


Edit: Kept the USB in, plugged in pack, plugged in balance. No smoke, yay!


1 Like

Will add.

You can have the USB connected at any point and connecting the pack or disconnecting the pack should have no adverse effects. Of course the status led turn on/off and any relevant pack measurements will change if the pack is connected or disconnected.

Maybe “BMS first-steps” could be a good name for the initial connecting of things and then changing settings?

I’ll add an explanation for the state printout stream of what every parameter is reporting, as if you’re not in the know it’s a bit non-sensical somewhat.

The 5374mV reading for all cells when there is no battery pack connected is normal. This is because the LTC6803 pack monitor IC is not powered, which causes all communication to contain all 1s and that sets the all the cells to their maximum value of 5374mV that the IC can report.

Faults are currently only used during charging and they don’t have an effect apart from not allowing balancing outside charging.

I would say go with just the CANL and CANH connections if you’re connecting to an existing CAN-bus. Whether or not the CAN ground can/should be used depends on how you have wired your battery connections and if there is a physical loop key, e-switch or anything that cuts the ground connection from the battery pack to the ESCs. If you’re unsure, then leave the CAN GND unconnected.

Currently the LED has the following colors to indicate following states:

  • Blue - Shows that 5V from USB has been detected and USB is then initialized
  • Green - Charging going on or being attempted
  • Yellow - Balancing / storage discharging
  • Red - Fault found and in fault state waiting for fault wait time to clear

I’ll add an explanation for the LED colors.

So looks like 12S pack with all cells within couple millivolts from each other. Pack voltage looks pretty close to the sum of the cell voltages, so I assume you have entered the calibration gains for it. Charger not connected and temperatures measured by the LTC6803 and MCU around 27-30 Celsius, which is pretty nominal for having the USB connected.

1 Like

Status LED colors explained. If more colors added or their indication meanings changed they’ll be explained here.

State printout breakdown.

Calibration values explained.


Great, thank you very much! Yeah, “BMS first steps” sounds good to me. I left CAN gnd unconnected, let’s see if Metr Pro finds the FlexiBMS… Support for 0.8 FW is apparently coming very soon (in review).

And yeah, this is a new 12S4P P42A pack with relatively well balanced cells out of the box. Calibration values have been applied. I did notice something like 0.1V delta between what FlexiBMS reports as total pack voltage and what my UNI-T UT61E says. I don’t trust the UNI-T enough to blame the FlexiBMS calibration. I suppose its good enough. Might check it against a higher end Fluke at work some day. What are you using as calibration reference?

The pack voltage is not super accurate, considering it has a resolution of ~19.6 mV LSB, and there is usually couple LSB of noise in either direction, so even with perfect calibration it’s still accuracy wise somewhere between ±40mV.

I personally just use a non-reference accuracy benchtop power supply set to 50V and calibrate the gain on that, if you have a good reference voltage source then you can use that to do your own calibrations.

But if you’re using cell sensing (packCellCount != 0), then the pack voltage is not actually used for anything, it’s just indicated what it’s measuring. The cell voltages measured by the LTC6803 have much tighter accuracy and therefore it’s measurements if cell sensing is enabled.

1 Like

Excellent, thanks for the great explanation! I don’t think I will touch the cal values for now. BTW any plans on making an enclosure for the FlexiBMS? Or some sort of conformal coating like Hoyt receivers use? I used black liquid electrical tape to coat the PCB.

Do you mean the enclosure should protect from dust and water ingress or just accidental short-circuit protection?

I suppose a light 3D-printed case would be easy to design and offer protection from any wires or bigger debris coming into contact with the board.

Dust and short circuit protection would be much more important than water ingress in my opinion. A 3D printed case or some coating would take care of that.