Communication BMS Controller

Joined
Nov 27, 2012
Messages
22
Hi,
I am developing an innovative BMS for managing the ebike batteries. My BMS provides the use of a microcontroller to enhance the performance of the BMS. Now I am trying to implementing the connection between the controller and the BMS. I don’t know if it is necessary for my project, because I cannot understanding if the controller only asks information from the BMS (for example cell voltages) or also gives instructions to the BMS. In the first case I will don’ t care about the communication between controller and BMS. Can you please help me giving me information about the communication between controller and BMS?
Thanks.
Regards.
Gaetano
 
Gaetano welcome to the forum! For information, we like to only see one post per topic. I have removed your two duplicate posts, and left this one in what I think is the most relevant forum.

Good luck with your project!
 
there is not communication between the controller and the BMS. how much do you know about what a BMS does? have you ever examined a BMS, or looked at the dozens of different BMSs that are already commercially available?
 
Gaetano,

Welcome to the ES forums!
If there are any controllers that do communicate, I'm pretty sure each will have their own comm. protocol ("language"). Thorough research on your part will be critical here.

Good luck!
 
Thanks for your answers. What I need to know is what type of information are exchanged between BMS and controller. I can manage the communication between the controller and my innovative BMS (is CANOpen protocol). But this complicate the architecture of my BMS. So I need to know if eliminating the connection between controller and BMS create problems in the bike usage.

Regards.
 
gaetano.sciacovelli said:
Thanks for your answers. What I need to know is what type of information are exchanged between BMS and controller. I can manage the communication between the controller and my innovative BMS (is CANOpen protocol). But this complicate the architecture of my BMS. So I need to know if eliminating the connection between controller and BMS create problems in the bike usage.

Regards.

To the best of my knowledge, I've not ever seen a single commercial BMS that communicates with the controller and it's hard to see why such communication would be needed.

Certainly some DIY BMS designs have used the low voltage cut-off signal to activate the controller ebrake line, as a means of preventing further battery discharge once one cell reaches the lower cut-off voltage limit, but this isn't a great thing to do, IMHO, as having the controller suddenly cut out with no warning isn't very user-friendly.

It seems more important for the BMS to communicate with the rider, by informing him/her of the battery status, charge remaining etc, so that an informed decision can be made as to whether to continuing riding or recharge the pack. There seems no good reason for the BMS to communicate with the controller, unless, perhaps, the LVC signal is translated into a gradual reduction in controller power, as a means of reducing discharge rate as the battery gets low.
 
Jeremy Harris said:
gaetano.sciacovelli said:
Thanks for your answers. What I need to know is what type of information are exchanged between BMS and controller. I can manage the communication between the controller and my innovative BMS (is CANOpen protocol). But this complicate the architecture of my BMS. So I need to know if eliminating the connection between controller and BMS create problems in the bike usage.

Regards.

To the best of my knowledge, I've not ever seen a single commercial BMS that communicates with the controller and it's hard to see why such communication would be needed.

Certainly some DIY BMS designs have used the low voltage cut-off signal to activate the controller ebrake line, as a means of preventing further battery discharge once one cell reaches the lower cut-off voltage limit, but this isn't a great thing to do, IMHO, as having the controller suddenly cut out with no warning isn't very user-friendly.

It seems more important for the BMS to communicate with the rider, by informing him/her of the battery status, charge remaining etc, so that an informed decision can be made as to whether to continuing riding or recharge the pack. There seems no good reason for the BMS to communicate with the controller, unless, perhaps, the LVC signal is translated into a gradual reduction in controller power, as a means of reducing discharge rate as the battery gets low.

I understand what you say. But battery data are not sent to the ebike display through the controller ?
 
gaetano.sciacovelli said:
I understand what you say. But battery data are not sent to the ebike display through the controller ?

Few controllers actually have any form of integrated display, and those that do tend to use a proprietary interface that varies from one manufacturer to another. These displays don't usually have any meaningful data from the battery, just, perhaps, a fairly crude indication of battery voltage.

The only commercial system that I'm aware of that provides a very useful battery status display is the Cycle Analyst, but this can work perfectly well with any controller, and doesn't need to be integrated with it. The Cycle Analyst can make use of things like the signal from the controller current measurement shunt and the motor rpm signal from the Hall sensors, but it has no need to interface with the BMS.

My personal view (based on my own home made "smart battery" system) is that having intelligence within the BMS that can drive a display to keep the rider accurately informed as to state-of-charge, number of charge cycles, battery voltage etc would be useful. The main problem with most battery monitoring systems (with the notable exception of the Cycle Analyst) is that they don't provide accurate battery state-of-charge information when the ebike is used several times between battery charges. My DIY systems do the same as the Cycle Analyst, in effect, by keeping track of total energy used from the battery and displaying the useful energy remaining to the rider, even if the bike is turned on and off or not used for several days or weeks.
 
Your post and this thread in general gave me an idea, which I posted over here:
http://www.endless-sphere.com/forums/viewtopic.php?p=670426#p670426
It's unlikely to be implemented anytime soon, if ever, but it would enable a small part of what the OP of this thread appears to want--a way to have cell-level voltages affect the operation of the bike.

The actual idea as-posted couldn't, but it's easy enough to extend the idea so that a cell-level LVC can exist in the CA, and it checks the data in the stream against that and anything below that LVC results in whatever action is programmed into it by the user. (or picked from the options).
 
Jeremy Harris said:
To the best of my knowledge, I've not ever seen a single commercial BMS that communicates with the controller and it's hard to see why such communication would be needed.
For example, our BMS does.
The information includes, but is not limited to, maximum allowed power/current/speed. In high power applications you can't just use a bunch of mosfets to cutoff the power whenever you like. First reason is losses in mosfets. Other reason - this may be life threatening in some traffic situations, etc. In high-powered applications, contactors are used instead of mosfets. Not only due to power losses, but also for security reasons. Contactor is another reason not to cutoff power randomly, because it welds together after few such incidents.
So the BMS should cut off power (contactor) only as a lats precaution. At first it communicates with controller (either by CAN or analogue means) and, as voltage sags, gradually lowers power limit. The contactor is switched off only when there is zero amps flowing.
The same goes for charging - BMS does not do hard switching of power elements, it lowers the current first.
 
circuit said:
Jeremy Harris said:
To the best of my knowledge, I've not ever seen a single commercial BMS that communicates with the controller and it's hard to see why such communication would be needed.
For example, our BMS does.
The information includes, but is not limited to, maximum allowed power/current/speed. In high power applications you can't just use a bunch of mosfets to cutoff the power whenever you like. First reason is losses in mosfets. Other reason - this may be life threatening in some traffic situations, etc. In high-powered applications, contactors are used instead of mosfets. Not only due to power losses, but also for security reasons. Contactor is another reason not to cutoff power randomly, because it welds together after few such incidents.
So the BMS should cut off power (contactor) only as a lats precaution. At first it communicates with controller (either by CAN or analogue means) and, as voltage sags, gradually lowers power limit. The contactor is switched off only when there is zero amps flowing.
The same goes for charging - BMS does not do hard switching of power elements, it lowers the current first.

Sounds good, I'd not seen this before. I like the "soft degradation" feature as the battery nears fully discharged, that addresses my main concern over those BMS units that either just switch the power off or apply the controller ebrake when a cell drops too low (I used such an ebrake BMS a long time ago and it wasn't safe, in my view).
 
Back
Top