Ebike Battery Monitoring and Control System

[Alan B]

Have you looked at revolt's bms?

Is there a thread for it?

I found some info here, but not much:

http://upverter.com/mwismer/307605a19fdbb313/Open-Revolt-BMS/

 

[Njay]

http://ecomodder.com/wiki/index.php/Open_ReVolt/PCB_Schematics#Open_ReVolt_-_BMS_Battery_Management_System_.28Rev1.29

 

[Alan B]

http://ecomodder.com/wiki/index.php/Open_ReVolt/PCB_Schematics#Open_ReVolt_-_BMS_Battery_Management_System_.28Rev1.29

Thanks for the link. More info there than on the other site, it appears to be the same design.

Interesting choices they made, nice the way they use half as many optos by series connecting the nodes. Interesting choice to draw almost half a milliamp from the cell all the time. This is less an issue for their application on very large cells, their board is designed for Thundersky celltop mounting.

Interesting also they do bottom balancing. The setup is capable of top balancing, but bottom balancing is easier to implement since no charger interaction is required.

 

[Njay]

I've been developing a similar BMS also for large LiFePO4 cells. I have used the ATtiny25V (note the V), with the single opto per board (ring bus), but I developed a different comms protocol, which adapts to the sender's speed. It's still in tests. On the ReVolt they use UART but I'm not convinced they won't have problems in some situations, as it relies on the clock accuracy and they're using the internal RC oscillator. I also ditched out the balancing part as I don't like dissipative balancing. I'll do balancing off-vehicle through a connector, if and when required. I'm aiming at 10Hz sampling rate and the system minimizes differences of the sampling moment, that is, I try to sample all cells "at the same time". I also try to balance the power consumption of the monitors as much as I can to reduce unbanlance build up, and I'm aiming at an "idle" consumption smaller than the cell's spec'ed maximum self-discharge rate (through things like an enable on the cell voltage measurement resistor divider). This is what I want from a BMS for a LiFePO4 cell (Battery Monitoring System only).

I would like to do a few more things on the cell monitor but I'm out of code space now, so I'm thinking of moving to ATtiny44, which is actually cheaper (mouser) than ATtiny25V (both SMD), has a few more pins to work with, and also works from 1.8V up.

 

[Alan B]

Interesting. My present design also uses the Tiny44, but I'm considering moving to a chip that has a real full duplex UART, which makes the ring communications design work much more easily. Examples include Tiny87, still only $1 in 100 quantity.

Of course you could move to the Tiny45, doubling the codespace but maintaining the same chip and pinout.

I also would prefer simultaneous conversions, which is hard with the ring comms unless you add a separate trigger signal. That's one reason I was leaning toward the broadcast bus type comms as that can trigger everything at once and read each one back individually, but requires two optos per channel.

I have planned to enable the voltage divider by using a binary output to the top of the divider, but I have not tested this, how is that working for you?

I'm not too worried about dissipative balancing since good cells stay so well balanced by themselves there is very little power loss, and it only occurs when plugged in where it is not much of an issue. Another reason to do gentle balancing as it avoids any significant heat buildup.

It looks to me like standby current can be in the low microamps region with a little care.

 

[Njay]

I have not done a formal analysis, but intuitively I have doubts the UART "method" will always work under all conditions of temperature and voltage, and at the speeds required to do 10+sps.

Yes I could go to tiny45V, but that's almost twice the price of the tiny44 and I can use some of the extra pins.

I have a "transparent" mode of operation, in which a monitor will forward each transition of the input communication line at the same time as it reads it, adding a few us of delay per each node. The "SAMPLE" command is issued in this mode. With more code space the sophistication can increase, and since the monitors all have id's I can set each one to do a small delay proportional to its id (knowing the total number of monitor on the ring) before sampling.

I've actually never tested the enable for the resistor divider, I have no more code space but the main reason is that I need the pin to program the chip while developing the code. I designed it to enable/disable the ground connection of the divider; I chose not to control the top as to avoid measurement interference because the top has to be connected to the cell+ and there is a series protection resistor from cell+ to the micro's positive supply.

I don't want such "heater" in the vehicle, rather have it outside, which has some other advantages, like sharing possibility, less BMS complexity and size, and it doesn't interfere with cell temperature measurement during a critical operation such as charging (my monitors are reporting cell voltage and temperature, using the internal Vref and an external temp sensor). I'm seeing balancing in these cells more like a infrequent maintenance operation than doing it on every charge, if they really behave as reported by many.

 

[Alan B]

BMS 2013 Requirements for my Ebikes

Or, what are we trying to do here?

The primary requirements are simple, safe operation of my ebike battery systems. I want simple automated charging, automatic protection against overdischarge, and be able to see what is going on with cell group voltages so I can review the balance situation. I want a single plug to either AC power with an onboard charger, or a single plug to an external charger that I can connect and have the details of charging and balancing handled, but with lots of information available when I want to review it. These black box BMS systems worry me, I can't easily verify if they are working. I want to see confirmation that they are doing the job, and be able to review the battery details. So this leads to the next set of requirements in more detail:

Derived Requirements

Manage charging and soft balancing (work with LED power supplies or similar CV/CC supplies)
Provide accuracy to 10mV on each cell, read all cells at the same time
Provide intelligent balancing to 150mA (soft balancing)
Handle up to at least 32 cells in series, at least 5 hz update rate (preferrably 10hz)
Provide High Voltage charge cutoff (disable charge current)
Provide Low Voltage protection (disable throttle or similar)
Have low standby quiescent current, the same for each cell to maintain balance (say under 50 uA)
Use readily obtainable components (avoid special ICs that are hard to get, make design last awhile)
Provide self-checking features to verify the BMS is working
Be highly reliable, especially against failures that could cause charging fires
Make it easy to change algorithms and update the firmware (eg USB programmable)
Provide a display for battery status including charge state, balance state, etc
Keep cost of parts low
Physically compatible with 6S Lipo packs, Greyborg ebike, etc

Possible future add-ons to leave room for
Integrated RFID keyswitch
Throttle management

 

[Alan B]

I have not done a formal analysis, but intuitively I have doubts the UART "method" will always work under all conditions of temperature and voltage, and at the speeds required to do 10+sps.
...

Let's review the asynchronous serial timing requirements.

Assuming a start bit, 8 data bits, and a stop bit we have 10 bits total. Assuming we need to sample the stop bit within plus or minus 25% of one bit time (half the available total sampling error). From the beginning of the start bit to the center of the start bit is 0.5 bits, and to the middle of the stop bit is 9 bits more for a total of 9.5 bits. So we need to have accuracy of 0.25 per 9.5 bits, or 2.6 percent.

I often see folks quoting 4.5% as the requirement, but that assumes the whole bit time can be consumed by this error source, which is not very conservative as there are other things competing for the available bit time error margins.

The RC oscillator has a 10% uncalibrated accuracy, and it can be calibrated to less than 1%. On top of that there is still temperature and voltage drift, and you have errors at both ends of the serial link to consider. So the RC might be marginal. Folks have indicated it does work, so it must be statistical.

A ceramic resonator costs about $0.15 in 100 quantity, and has 0.5% accuracy and 0.2% stability so will easily meet the requirement at 0.7% total. With these small micro chips that have higher pin count using 2 pins for the ceramic resonator is not taking too many pins. A crystal would be even better, but is not necessary for serial i/o and the cost and size are greater. Adding a resonator or crystal also obviates the need to calibrate the RC oscillator which saves time and effort.

I suspect if you do calibrate the RC oscillator, and all micros are in the same temperature environment they will drift together well enough for serial to still work, as people have reported. Especially if shorter word lengths are used. One could even program a wakeup RC clock calibration cycle, but a resonator just makes things so much easier.

 

[Teh Stork]

Most new AVRs (Xmega, new tinys) come with internal RC oscillators. Some can be tuned aswell.

 

[2moto]

Good thread, and very topical for me, too. I've had very similar thoughts and requirements for a BMS. What I designed is a module that can manage the typical 5S or 6S HobbyKing LiPo "brick", and is the same size as the narrow end of the brick, i.e. 40 x 50 mm. The modules can be daisy chained together and communicate via an optically isolated LIN bus with the master module. The modules include PWM shunt balancing and report battery voltages to the master for LVC/HVC purposes. The master module also manages the charging current, provides a programmable LVC lock-out signal to the motor controller, and uses a Bluetooth connection to dispay/log data to a smart phone. The Andriod app has not been designed yet, though.

Sleep current is 15-20uA per cell with a more or less equal current draw on each cell. The slave modules are working quite well and the communication seems to be reliable and fast enough. More development is required and I hope to have it all done in a couple of months.

All the above information is highly relevant to the issue you have to face when undertaking this, as I've found out. Reliable communication, accurate cell voltage measurement, and low sleep current were the most difficult for me.

 

[Njay]

I often see folks quoting 4.5% as the requirement, but that assumes the whole bit time can be consumed by this error source, which is not very conservative as there are other things competing for the available bit time error margins.

Yap, like the "slow" rising edges you'll get from the opto interface.

The RC oscillator has a 10% uncalibrated accuracy, and it can be calibrated to less than 1%. On top of that there is still temperature and voltage drift, and you have errors at both ends of the serial link to consider. So the RC might be marginal. Folks have indicated it does work, so it must be statistical.

Yep, I don't doubt it works most of the time; but I want it to work all the time under all circumstances. Some cells will get more airflow than others, and at the bottom charge some will sag more than others, and on top of that, the "main console" will have a crystal clock that will not drift.

A ceramic resonator costs about $0.15 in 100 quantity, and has 0.5% accuracy and 0.2% stability so will easily meet the requirement at 0.7% total. With these small micro chips that have higher pin count using 2 pins for the ceramic resonator is not taking too many pins. A crystal would be even better, but is not necessary for serial i/o and the cost and size are greater. Adding a resonator or crystal also obviates the need to calibrate the RC oscillator which saves time and effort.

Good point. I will nevertheless not have crystal/resonator, the communications protocol I implemented recovers the bit timing from the message itself. It's very simple. Every bit consists of a LOW time and a HIGH time. The length of the LOW time defines if it's a 0 or a 1. The 1st 2 bits of the message define the 0 and 1 bits time, which are then used to measure the remaining bits. So a message is 2 initial "timing bits" + 8 databits + 1 parity bit + 1 stop bit, transmitted in 1ms. I still code some information on the initial 2 bits; if the 1st is longer than the second it means a "control message", otherwise it is a "data message". The longer bit is always a 1.

You seem to have there quite an advanced system, 2moto. The thing with the low consumption is that, 1st of all, you care when not in use. Then you have to control power to the micro-controller external peripherals, such that you can turn them all off leaving only the micro eating power, and it can be made very efficient. Many devices can be powered directly from a micro pin, so it's a direct connection. Then the micro clock can be lowered for even lower power consumption. One of the things I want to implement and have no more space on the tiny25 is clock lowering when "idle"; the monitor goes into low clock after some inactivity time (thinking of using the watchdog for that), and the "console" will "shake up" the communication line to "wakeup" the monitors.

 

[2moto]

I think your approach is very sounds, Njay. I used the LIN bus because it uses a single wire is inherently timing tolerant. It was invented because CANBus was too expensive for every node in an automobile, hence LINBus is very cheap and doesn't require the MCU to have a crystal oscillator. I use a nanoWatt PIC24 in my slave boards which have a reasonably accurate internal RC oscillator (+/- 2%). I also group 5 or 6 cells together into one MCU thereby further reducing the number of optos in a system and reduced communication traffic. For e-bikes where packaging of all components is important, I don't really see the need for a "per cell" BMS's. It's more space efficient to group them together, IMO.

 

[Njay]

I'm going to take a look at that LIN bus, I've seen it mentioned but never read about it, thanks for the hint.

 

[Alan B]

I reviewed LIN bus again a few days ago. It is interesting, and somewhat appropriate for what we're doing.

 

[Alan B]

Lots of ways to do this, very interesting to see how different approaches are working out for folks, and nice to see several good efforts. Thanks for all your comments, and feel free to put links here to your threads or websites where you have more info about your BMS projects.

One interesting thing is the "picopower" variants of the AVRs. The brownout detectors take 15-20 uA if enabled on the AVRs, but the PicoPower AVRs have a trick where the Brownout detector can be managed and turned on and off in the software, since it is not needed when sleeping. This gets the processor current down to a bit under 1uA when sleeping, in some cases as low as 0.1uA!

To this we must add the leakage of the per micro zener of 5-10 uA, plus the leakage of the opto (which is typically under 1uA for one I checked, but could be higher). The zener is important when connecting a multi-cell connector as the make-up order of the pins is not known and can cause voltages across one cell circuit to exceed the 5.5V rating of the micro for a moment during connect/disconnect cycles. This is not needed for one micro per connector designs. Multiple cells per micro make it more difficult to maintain the same leakage current on all cells with the impedances of the voltage sampling circuits at different potentials.

It looks to me like a 10uA leakage on each cell is a reachable goal.

 

[Njay]

Took a look at the LIN bus. Too slow and complex for my requirements.

Humm, so that's the thing with the picoPower. I'm not having the BOD enabled at all. I'm relying on a Cell+ series diode (I think it's the same on the ReVolt) and a beefy capacitor (10uF) to survive through the rougher times. This combination also help keep the micro's Vcc stable, good for things like ADC measurements and RC clock stability.

 

[2moto]

[snip]...The zener is important when connecting a multi-cell connector as the make-up order of the pins is not known and can cause voltages across one cell circuit to exceed the 5.5V rating of the micro for a moment during connect/disconnect cycles. This is not needed for one micro per connector designs. Multiple cells per micro make it more difficult to maintain the same leakage current on all cells with the impedances of the voltage sampling circuits at different potentials.

It looks to me like a 10uA leakage on each cell is a reachable goal.

I would agree with all that and was born out in my experience in designing my BMS. Also, though, I am not so sure that absolutely identical current drain on each cell is required. If you can get it down to around 10uA, it's nearly irrelevant, IMO.

 

[2moto]

Took a look at the LIN bus. Too slow and complex for my requirements.

Humm, so that's the thing with the picoPower. I'm not having the BOD enabled at all. I'm relying on a Cell+ series diode (I think it's the same on the ReVolt) and a beefy capacitor (10uF) to survive through the rougher times. This combination also help keep the micro's Vcc stable, good for things like ADC measurements and RC clock stability.

Yes, it is a bit slow, but as I am using one micro per 5 cells, speed becomes less important. Plus, I really only use the physical layer of the LIN-bus which is not very complex. If you use a micro that natively supports LIN, it becomes pretty easy to get things working. Certainly a lot less complex than rolling your own comms protocol, especially when needing CRC checks and other error detecting methods to make it reliable.

Not trying to push LIN, or indeed one approach over another, just offering my experiences. And, I am certainly no authority on this stuff.

 

[Alan B]

I agree that with very low currents the equality requirements can be relaxed.

With a multicell per micro design, how do you get the current per cell equal? Where is the Micro powered, and how does the voltage sensing circuit maintain near equal per cell current? Is there a voltage regulator, and what is the quiescent power of that?

I agree that using just the physical layer of existing standards is a good thing to consider. CANBus has some nice transceivers, for example.

Another communication method I was considering is FM or MFM modulation as was used in floppy discs. It is extremely frequency tolerant.

 

[Njay]

Took a look at the LIN bus. Too slow and complex for my requirements. (...)

Yes, it is a bit slow, but as I am using one micro per 5 cells, speed becomes less important. (...)

In that case I totally agree with you!

As far as balancing current drain on the cells, probably not important for LiPO as they're balanced on every charge, but apparently important for TS style LiFePO4 which seems that don't need to be balanced for a very long time if you balanced them. Reports are that these cells seem to stay in balance for a very long time, but a single few uA of unbalanced drain slowly takes them out of balance. There's even a reported issue with a cell logger that had a small drain difference on different cells and this started to drift the cells over (I think) a few months. So I'm trying to cover all.

 

[2moto]

Mine auto-balances on every charge anyway. It does so throughout the charging process, and all cells become full at the same time. So, the sleep current is only a consideration for self-discharge. As I am using 5Ah or 10Ah cells, it would take somewhere around 200 theoretical years to discharge them. I am OK with that.

 

[Alan B]

Mine auto-balances on every charge anyway. It does so throughout the charging process, and all cells become full at the same time. So, the sleep current is only a consideration for self-discharge. As I am using 5Ah or 10Ah cells, it would take somewhere around 200 theoretical years to discharge them. I am OK with that.

Nice. Do you apply balance loads to the half of the cells above the average, or what is the algorithm?

 

[Alan B]

I've been looking at small AVR Micros that have USARTs and ADCs. Two that are interesting: the ATTiny87 and ATTiny1634, both around one dollar at 100 quantity. They both have 20 pins and are available in small surface mount packages. The 87 has a UART or LIN port and a temperature sensor. The 1634 has dual USARTS and lower power modes, and a number of other newer features. Both are 1.8-5.5V.

 

[Njay]

Thinking about multiple cells per micro? The tiny25 and 24 lines also have the temperature sensor, but I opted to have an external one because the internal one needs calibration. I don't have the temp sensor ref at hand but I'll post it later, it's a cheap low power device with analog output.

 

[Alan B]

I've used the Tiny25/45/85 in other projects, and the temperature sensor calibration is a problem, it is pretty poor and not all that easy to calibrate at two or more points, so using a separate sensor makes a lot of sense. Also the battery may be a few inches from the board, plus any balancing is going to skew the temperature of the CPU.

I'm still looking at one micro per cell, there just aren't many UART equipped small AVRs. The extra pins do make things easier with no multiplexing needed, and several can be used to drive the balancing loads to get more balance current.

As long as the chip is small, and the cost is low, I don't mind having some unused pins. Could put an LED on one for some status info I suppose. Looks like I'm using 16 pins at the moment, so 4 left over.

At the moment my per cell parts cost is under $3, not including the PC board, and that includes a $1 micro, an opto, a ceramic resonator, and the various other small parts. No temperature sensor at the moment. That would take 2 pins for a thermistor, one for power and one for analog input.