FlexiBMS Lite - Flexible Configuration BMS w/ CAN-bus

He said it right here.

1 Like

I was just wondering if there were any other specs that where important like clamping voltage, if bi-directional diodes would work (I assume they won’t) or if a 51v diode would be fine.

Clamping and breakdown voltages are pretty much all the same based on the reverse standoff voltage, as shown in the image below. All that really changes is the max clamping current, which is higher for bigger packages, as they can soak and dissipate more heat.

I would recommend uni-dicrectional in this case.
51V is a little high, as the operating window is quite narrow, but still better than nothing.

4 Likes

@SimosMCmuffin ive ordered 2 units that were shioped a couple days ago. Does those have those diodes soldered already?

1 Like

Yes.

2 Likes

I was looking around on the Flexi Github but didn’t understand what consol to use to send commands to the bms? Is it just me? :sweat_smile:

4 Likes

Is the BMS turned on as long as it’s plugged in with the terminals, Or only while charging? I guess it can’t kill a pack just by sitting there?

To turn on one of the following needs to happen

USB, charging, 5v on the opto isolate also plans to check the can-bus periodically for activity.

2 Likes

I should probably write a wiki page for the different power-states that the BMS can be in, as it can be a bit complex to get a good understanding how to properly use the available $-parameters to customize the power handling for your use-case.

But there are 3 power states currently:

  1. Active mode, 5V regulator on. Entered when Charger and/or USB is connected and/or the Opto-enable pin is activated.
  2. Standby mode, 5V regulator off. In this mode when the above mentioned flags are not true and the stayActiveTime hasn’t expired.
  3. Low-power mode, 5V regulator off, oscillator down-clocked from 16MHz to 100kHz. Periodically power-up 5V-reg. to check for activation flags.

For the CAN-bus to be active, the 5V regulator needs to be ON, as the CAN-transceiver IC is powered from the 5V-rail.

There are $-parameters that allow you to change the power behavior in the different run modes. For example $32 (keep5ValwaysOn), can be used to force the 5V-regulator to be on, regardless of power state. This of course increases power consumption, but might be needed for some use-cases. $38 (duringStandby5Von) allows you to keep 5V-regulator on in the standby mode, but off in the low-power mode.

1 Like

@SimosMCmuffin, I installed the v0.18 today to test the CAN-awake functionality and unfortunately it’s not working for me. If I set $32=0, I don’t get Flexi readings on DAVEGA unless the charger is connected. With $32=1 it’s working correctly.

I only have CANH and CANL connected; not the enable pin.

Let me know if there’s anything I can do to help you troubleshoot this.

1 Like

Turn $38 (duringStandby5vOn) on, so the 5V-regulator stays on even if the aforementioned flags are not active in the standby mode, otherwise the CAN-transceiver will stay unpowered.

I’d recommend lowering the $31 stayActiveTime to something like 5 hours, so the BMS doesn’t stay too long in the standby mode with the 5V-regulator on, which is relatively a big increase to the current consumption. Besides with the CAN wake-up activated, the BMS will wake-up if the ESCs are turned on.

EDIT: you might also want to set $39 (canRxRefreshActive) to 1, so that any CAN-traffic will allow the activeTime to refresh up to 1 hour, so that it doesn’t go to low-power mode, disrupt comms, wake-up and come back on for the stayActiveTime.

3 Likes

I confirm that $38=1 helped. Great! :+1: Thanks for the quick response.

Am I right thinking that with $38=1, there’s essentially no difference between active and standby?

Why would I want the stayActiveTime to be more than zero?

2 Likes

Yes, this is correct. The reason why standby and active modes are there is to optimize current consumption.

I’d say at minimum set it to 1 along with $39, if you’re using the CAN wake-up. Otherwise, if stayActiveTime is set to 0, the BMS might start jumping between low-power and standby mode, disrupting the CAN-comms.

EDIT: If you were using the opto-EN to wake-up the BMS, then you could set the stayActiveTime to 0, as the opto-EN would keep the BMS in the active state.

Should the stayActiveTime and canRxRefreshActive be in minutes, rather than in hours to allow better control over the power mode? They are uint16_t, so max time would be roughly 65000 minutes, which equates to 45 days.

EDIT2: timeToStorageDischarge can be in hours, as it’s doesn’t need as tight of a time resolution.

1 Like

Makes sense. Thanks for explaining.

With the $39=1, will each received CAN message extend the active timer by 1 hour?

That sounds like a good idea to me. Though maybe it’s unnecessary since the extra energy the BMS consumes in 1 hour of the active mode is probably negligible?

1 Like

Can’t recall from the top of my head what the current consumption was in active mode, but I think it was roughly in the ballpark of 10mA.

Up to 1 hour.

For example, if stayActiveTime is 5 hours and $39 (canRxRefreshActive) is 2, then the CAN-traffic can only refresh the activeTime to 2 hours if it’s below that. So in the 5-2 hour period CAN-traffic won’t refresh anything, but once the activeTime goes below 2 hours and it gets a message, then it’ll refresh the timer to 2 hours.

Then if charger, USB or opto-EN flags are activated, then those will refresh the activeTime to 5 hours.

1 Like

I see. I think the documentation would benefit from a different wording. If you say “can refresh up to 1 hour”, I personally read that as “it will somehow decide on a refresh time somewhere in the 0-1 hour interval and use that” while what it actually means (if I understand correctly) is “it refreshes the time to 1 hour unless it’s already more than 1 hour”.

2 Likes

Same below with different wording.
“it refreshes the time to 1 hour if it’s less than 1 hour”.

Right. That sounds very clear to me.

BTW, do you actually need that option? Wouldn’t it be best if it always refreshes to whatever the $31 value is?

Do you have a use case for $39 being different from $31?

I think I implemented it that way with the future vision, if and when there are devices available to connect to the I/O-port and they get powered from the BMS. I saw that it might be beneficial to keep the two activeTime refresh methods separate.

But currently there isn’t necessarily a use-case for the two refresh methods.