Sorry if this has been answered already but is the battery voltage measurable from the charging port with the FlexiBMS?
Something like this:
1 Like
No, there is a fully blocking charging Mosfet setup that doesn’t allow battery voltage to be measured on the charger side by default, unless the Mosfets are commanded open. This is meant to protect the battery and BMS from any kind of short-circuits on the charger side.
3 Likes
Is there a charge+discharge version yet? Flexibms pro?
Not yet.
I would almost prefer more to make a E-switch module with CAN-bus that can be added into a system (with a Lite already for the charging path control for example) and connected to the existing CAN-bus network or connect it with CAN to just the BMS. Add also an opto-isolated input, for power switch.
Discharge path control just usually means having to deal with more current then the charging path and that means paralleling Mosfets for higher current handling + bigger space need. A simpler module, would also be easier to design a simple heatsink for, but that’s just my current, slightly sleepy evening head thoughts.
7 Likes
I like this, and on top of that add a shunt for precise battery current measurement and you can either just leave at that or start playing with SOC and SOH calculations
1 Like
Maybe I’m being ignorant but I can’t imagine a use case for that.
The BMS can command it to shut down in case of any fault situation that would required the power to be cut, instead of having a BMS that can cut the discharge plus an e-switch, unnecessary redundancy that would take more space
1 Like
Don’t most people turn their boards off when charging? Well, now that I think of it, in the near future where everyone has a robogotchi uploading their rides when they get home and giving them a notification when the board is charged, maybe not… 
1 Like
You can still have it off and charge, the FlexiBMS would connect as it is to the battery, and the discharge wires would go through this new e-switch before going into the rest of the board
Ye ye, I was just thinking “no point in a smart e-switch protecting the ESC when charging if I just turn it off before charging” but I now see the point; thanks! 
1 Like
You can also add more accurate current measuring for the discharge path.
One of the key design decision/question that needs to be decided is in what configuration should the Mosfets be configured in. Aka, fully blocking or one-way blocking towards the battery.
One-way blocking would have the pro of having only half of the Rds(on) resistance compared to the fully blocking setup, as it only has one Mosfet inline instead of two and it would always allow current to flow from the ESC/Load towards the battery through the fet’s body diode, aka braking should always work.
The only pro I can think at the moment for the fully blocking setup is that if the battery is getting overcharged, then it could stop the current flow from the ESC, but in EV use case that would mean that the ESC side is generating, aka braking. I’d see that more as a safety hazard.
Thoughts?
1 Like
I had a blown FET from a battery disconnecting mid-ride (bad solder joint)
Wouldn’t this cause the same every time?
I’m guessing/assuming the blown Mosfet was on an E-switch? Was it the battery side + terminal that got disconnected? Was the E-switch a high-side connecting/disconnecting type?
I would hope that the ESC would be fast enough to catch the fast rising battery side voltage and be able to lower the braking regen, so that the battery side voltage doesn’t rise high enough to damage the E-switch Mosfets.
Nope, it was on the VESC. That board has no e-switch at all.
So the +Bat wire got disconnected from your VESC during a ride and the VESC blew a Mosfet?
Very interesting that the Mosfet died on the other ESC…
2 Likes
Agreed. Better to damage a battery than get injured.
For situations like this one, it would be great to have some kind of alarm (a loud buzzer).
3 Likes
One-way blocking for sure.
I’d also suggest one-way blocking on the charge port.
So the BMS can cut off a charger that goes too high, and can cut off an ESC drawing power if the battery is too low, but it can’t cut off an ESC in braking mode once the battery goes into overcharge, and it can’t cutoff a voltmeter on the charge port. Some chargers might also sense this voltage before kicking on, I think.
1 Like
Update
0.18 FW pre-release (not mass tested) coming this week.
Updates & changes:
-
New feature: Wake-up via CAN-activity. When in low-power mode, periodically checks for activity on the CAN-bus and wakes the BMS up if activity is detected. Slightly increases current consumption due to the need to turn on the buck regulator, to power up the CAN-transceiver.
-
State printout improvements
-
Battery voltage, Charger Voltage and Charging current are now shown with the Lowest-Latest-Highest internally measured values. This is useful as it is able to show otherwise missed values due to the internal sampling running around 300Hz speed and the state printout running once every second. -
Charging termination flag added -
Fault logging and behavior improved, divided into fault count and active faults. Fault count ticks up and has independent count for every fault, so it’s easy to check what faults have been triggering over time. Latched faults show the latest triggered fault flags, which caused the charging state machine to go into the faultState. After going into faultState, the state machine waits for a time specified by the $18 (FaultWaitTime) and will then try starting charging again, if faults are still found it’ll return back to faultState, log the fault flags and wait again until retrying. Fault counts can be reset with $G-command, FW restart or power-on reset. -
Status Led driver re-written, easier to add new states to indicate and program led animations to said states. PWM support coming at some point for fade action and RGB mixing.
Currently implemented indications:- USB-connected, solid blue
- Charging, solid green
- Balancing, solid yellow
- FaultState, solid red
- Charging ended, blinking green
- Fault count not zero, magenta
- StorageDischarging, white (orange planned, but needs the PWM implemented)
-
NTC-probe minimum and maximum temperature limits wrongly using values for minimum and maximum pack voltage.
-
GPLv3 license info added to source files written by me.
I ordered a couple different voltage rated TVS protection diodes for the charger side connection protection that I’ll be testing and adding to any boards I still have in my inventory. It should be easy enough to solder on with just a basic soldering iron, so if you’re able to solder on your battery and charger side wires, you’ll be able to solder the TVS diode on.
Damage to the charging Mosfet/s is/are most likely to happen when operating with 12S or 11S pack configurations, as the voltages are closer to the charging Mosfets max rating. This coupled with long charging wires and a charger that is powered up first, and then connected to the charging port has the possibility of generating the damaging voltage spike. I would recommend first connecting the charger connector to the BMS and then powering up the charger, as there isn’t the danger of sparking happening due to the charger side of the BMS being non-charged with the fully blocking Mosfet setup.
Currently I’d say that a good indication of a damaged charging Mosfet/s is when nothing is connected to the charging port, but the BMS still reports some voltage on it. This was the case with @janpom and @Zach with their charging ports hovering at 12V and 18V respectively, without nothing being connected to them.
7 Likes