Everyone not know this exists?
1 Like
I know. I actually have one coming in.
The drawback of that smart BMS is:
Discharge current is far to small for any reasonable battery. So you have to bypass it.
Thus, it becomes a oversized charge only BMS with Bluetooth.
It they offered 80A+ options, or, ideally, a much smaller discharge only option, I wouldn’t have started this thread.
2 Likes
Yeah, if you want to discharge high amps you need size to deal with heat which sucks for most builds size constraints. If you used a much larger heat sink you could probably ignore the discharge ratings and use the medium sized BMS.
Not implemented yet, since it has to be also done on the firmware on the VESC side, but definitely possible
That will be a thing, it already is with DieBieMS using Metr
Still on beta, there was a shipping strike so not everybody got the beta boards yet, me included
Have you ever looked at the Github before talking shit? Lots of mergers and vedder responding to people implementations, 55 pull request closed, 9 still open and some with discussions going on about testing/modifying them before merging
4 Likes
This would exactly meet my expectations once implemented.
It’d be far better to just connect the B- to the VESC power with a high-current wire (as we do now) and connect the BMS’s P- to the VESC with a small current wire.
When the BMS cuts power to P- then the VESC could see this and cut power slowly until off, but leave braking enabled.
This would ensure the BMS was still responsible for managing the battery, by itself, no matter how many VESCs were connected, and ensure that the large currents were still bypassing the BMS.
It’d be win-win-win. Let the BMS manage the battery, but send the signal that somthing is amiss to the ESC. From a port that the BMS already has for this purpose.
Kind-of like this, but with the VESC able to see if the lights are on or not, and cut throttle if not.
5 Likes
I personally hope so see for a simple software implementation of BMS integration to the VESC. By this I mean for CAN equipped BMS’s which are able to communicate to the VESC, and when they notice something wrong based on a set of conditions (cell overheat, p-pack balance issue, etc) a command can be sent to the VESC to allow for reduced acceleration and braking only, effectively putting the board into limp-mode allowing the rider to get to safety.
That would be the best implementation imo, would effectively give us discharge capabilities through charge only BMS’s, while utilising hardware that we already have for the high currents that we run, whilst also keeping size to a minimum
5 Likes
Well, you can set it up for up to 200A discharge. So the current problem will turn into a cooling and connector problem (which will be fine for 99% since you never draw over 60A RMS for more than a couple of minutes; e.g. a 1kwh battery (13S, 20Ah) will only last 20mins on 60A RMS).
Also you can wire up charge and discharge separately and get the double amp rating (by separating charge and discharge mosfets and run each current only through one of the fets than through both). Then you have 120A discharge continous…that’s >5kW…which will be around 10mins for a 13S 20Ah battery (like 13S7P). Cant imagine anyone can put down that energy with a mtb…
Yes but there is no branch or release or tagging. So is impossible for anyone else to working on this or track change.
This codebase is not manage well at all.
2 Likes
Yeah, but let’s end this discussion here and focus on the topic of measuring cell voltages or this is another thread that will be turned into a shit show
3 Likes
Oh, so you can basically ‘overclock’ these because the limit can be set as user wishes?
Too bad I ordered the lowest discharge version as I planned on bypassing it anyways.
There is nothing like overclocking or something. There are some mosfets in parallel (depending on the amp rating different numbers) and some shunts (also depending on the rating how many). The bms measures the amp draw via voltage drop over the shunt. And software will then turn off mosfets at set limit in software.
For the old ‘60A’ version 200A was the limit you can set in software. But still the thermal design is made vor 60A continuous.
Well, order some mosfets and shunts (like from mouser or digikey). The 20A version is the same PCB like the 60A version but with less mosfets and shunts populated (hence the same dimensions).
2 Likes
We will have a smaller version of the DieBie in our Prject X board though.
2 Likes
That’s what I meant with ‘overclocking’ - running more current through them than they were designed to sustain continuously. 
Great Idea, thank you!
Lovely!
When will the first round be available?
We launch in spring
2 Likes
Seems to me like 2020 will be a big year for esk8 specific auxiliary parts.
1 Like
I agree this is the future.
In my mind, a small battery pack monitoring device with canbus, maybe a display driver (i2c?) and/on audible alarm interface, with optional cell balancing, and optional balance lead passthru for external balancing.
If a control protocol gets implemented vesc side, it shouldn’t be too hard to implement @b264’s idea with a small device between a dumb bms and canbus.
3 Likes