FlexiBMS Public Support, Feature & Troubleshooting Thread

Why not just cover the PCB with Kapton tape ?
Did that on my DieBieMS and it saved it from short a couple of times (screws, spacers and other metal parts falling down on it).

The PCB is small and I want to keep access to all of the ports and mounting holes. I guess you could connect all the wires and then go nuts with kapton but I doubt that the result would look very nice. I used black liquid electrical tape and that worked, but perhaps @SimosMCmuffin would have less customers with problems if the PCB shipped with some protection :slightly_smiling_face:

1 Like

How is the status regarding setting parameters over CAN?
I would like to do some changes to my FlexiBMS parameters now while the board is closed and sealed up without opening it.
I have access to the VESC6´s serial interface wireless via bluetooth (metr). I can therefore send CAN commands to connected devices in the board.
Is it possible to change parameters this way?

You can change the settings inside metr app

1 Like

Anybody knows connection diagram if I want the BMS to be always on when the VESCs are on? Do I need to connect OPTO ENABLE 5V to CAN 5V? Ground to Ground too? While charging CAN works no problem, but I want to to be available while riding. :slight_smile:

If you want to wake-up the BMS when the VESC’s power-on, then the CAN 5V to the BMS’ opto-enable is the smart way to do it. It should be no problem to also hook-up the CAN GND to the VESC’s CAN GND to provide an always available return path for the opto-enable input current, but if you have the battery’s GND always connected to the VESC’s gnd (no low-side e-switch or low-side loop-key) then there is already a GND connection between the BMS and VESC so you don’t need to hook-up the CAN GND.

1 Like

Awesome. That’s exactly what I have (high side switch). So I will hook opto-enable as a bonus to the CANH and CANL. Thanks!

So far it has charged my battery no problem twice. Didn’t notice any discrepancies or issues. Will bump up the charger higher for later runs. :slight_smile:

1 Like

As promised, status report. :slight_smile:

Charging at 7A now without problems, opto-enable is hooked up, so I can see the BMS when the board is on. Everything is working smoothly, except the metr implementation. :smiley: Sometimes it loses FlexiBMS until the app itself is restarted, not board being power cycled. This also applies setting the values for the BMS via the Expert menu. It fails and loses the BMS completely. BMS is 0.8 FW, Metr is latest FW, latest app.



So I set the parameters up thro Ardieno

I know I have the drivers but I can no longer get the Flexi BMS to response thro the Arduino monitor now it’s installed with a batery. 3pc, 4cables and several hours later I have no idea what’s up.

It flash correctly on boot up to a battery and I get a blue led when I plug in a usb.

I have tried with and with out a Battery connected

I’m guessing I need to get it connected and do $R to check every thing

Is there any seating for discharge low cell voltage to activate the VESC soft or hard batery limits? Or was that some thing that never got implemented in the end?

Maybe you can add the Canbus wiring/ ground caution to the battery wiring guide and turn it into a wiring guide

So you successfully set up the $-parameters through the serial terminal in the Arduino IDE?

Do you have the correct COM-port selected? Does the STM32 MCU show up in device manager as what?

This would tell me that the firmware is intact and it detects the USB 5V and should initialize the USB-software stack.

That is not currently supported on the VESC end. The current CAN-handler stack does support value request that passes the lowest, average and highest cell voltage values, but these values are passed through the VESC to the Metr and not used internally AFAIK.

Good idea :+1:

I am experiencing occasional packet drops on CAN bus from Flexi. Sending COMM_FW_VERSION, missing answers for about 1 of 10 requests. Anyone seeing similar issues? @janpom do you get occasional red blinks on DAVEGA?

1 Like

Same here. It’s actually more than 1 in 10. I’d rather say something like 1 in 4.

Also, it gets worse with the charger connected. I have the charger cable routed along the CAN cable. Is it possible that it’s causing interference? I have a 4A charger and when charging with 4A, I can definitely see a difference in the success rate of the Flexi responses. Once the battery pack approaches the target voltage and the charge current is reduced, the situation improves dramatically.

I have a fairly long CAN cable that spans the whole length of my enclosure.

1 Like

What does your CAN wiring look like (VESC & BMS end)?

What’s your ground connection between BMS and VESC during charging?
EDIT: Also, what’s your charger?

I don’t have the GND connected. Only CANH and CANL. I thought it’s not necessary since they are both powered from the same battery and thus should be on the same GND.

The charger is this one:

Mainly I was after just confirming that there is a GND connection between the two. If the GND is available in this case through the battery GND terminal, then that should be fine.

Did you have 0.4 or 0.5 HW unit?

I don’t think there are any issues with wiring. I am suspecting the issue can be somewhere in CAN initialization code or message sending. For example I wonder if it would help to add small delay in between failed attempts. VESC / ChibiOS has 5ms timeout

uint8_t CAN1_transmit(uint32_t ID, uint8_t * data, uint8_t length){
	for (uint8_t i = 0; i < CAN_TRANSMIT_MAX_ATTEMPTS; i++) {
		if (CAN1_attempt_transmit(ID, data, length))
			return 1;
        // Maybe insert sleep here???
	return 0;

And this is VESC

canTransmit(&HW_CAN_DEV, CAN_ANY_MAILBOX, &txmsg, MS2ST(5));

So sometimes packets are lost when sent from Flexi’s direction?

After looking at the code I have a pretty good idea why this is happening, but could you clarify on the question above.

Yes. From Flexi’s direction.

I think Flexi has no problem reading packets. Because I can see that something is sent from Flexi’s direction, but probably incorrect order / missing frames. I am using Metr Pro CAN and for each request I am getting response, but checksum calculation fails. This could be incorrect frame order. When using VESC in between, I get nothing, but that’s expected. Most likely VESC fails on checksum calculation as well and does not send anything back to UART.


I actually do think there’s an issue with wiring. If I open my enclosure and move the charge port wires away from the CAN wires, the response rate improves significantly.

This is not to dispute there may ALSO be a problem in the firmware.

1 Like

Do we need to start shielding the CAN bus with all the devises coming out that’s starting to use it