A PIC based Battery Management System

fechter said:
It seems the more full featured system is not that much more expensive so would be a logical next step.
I seems like the communication would require 4 wires going to each cell circuit (RX, TX, Gnd and power).

There would only be one wire between every cellboard, going to the next board, Gnd and power will be taken from each cell it resides on.
Therefore the need for attiny V-version, since on the non V-version will have brown-out at a very the critical voltage 2.5v.
But there might be a use for optos between each cell. But I guess a pnp or npn transistor would be cheaper.

One idea is to have two version of the board but with the same pcb, so that there are end-of-pack boards that has a couple of extra ports, for direct control of charger cutback and throttle cutback, and in-pack boards that are as simple as possible.

I would go for a small pcb with cable and lugs to the battery terminals, because then it would be easy to glue the tiny to the cell to get the temperature as accurate as possible. And also it would be possible to have a positive and negative solderspot on both ends of the pcb so that the pcb can be situated in the same direction on all cells, making communication wiring simpler.

Best Regards
/Per Eklund
Sweden
 
I know i am going to take a flaming for this but...

Why not mimic the Flea tail lights with our slave sensor modules? In other words, yes increase the cost by adding a 1.5v lithium ion battery (or even a small 1.5v nimh) which we charge off the pack cells when they are operating normally (durring a charge cycle... you could even use this as the initial balancing drain).

Then each module is truly "self powered" and can continue to function even when cells fail, power is interrupted, etc.

I realize if we go li-ion it will be complicated to get the 1.5v but with a nominal current draw of even 50ma you could run 18-24 hours on a AAA nimh. These would only be tapped if the cell the module is connected to goes powerless or out of range.

Just an idea... flame away = )

-Mike
 
Acually I retract the flame invitation = )

Lets do it EagleTreeLogger style and use a seperate power source of rechargeables if our cell level voltage isn't sufficient or stable to use. Recharge the power source as we recharge the pack.

Now we can effectivly isolate the monitoring of cells from the pack as it's supply.

This wouldn't take much power to sleep/monitor/sleep cycle... Fechter you were looking at 200ua right? How long could we last at that draw against a 3300mah nimh pack or similar - and they are cheap and replaceable.

Again just an idea (slightly better than the first but still probably no good)!

-Mike
 
I started this last year but have been too lazy to work on the software. The design uses pics and serial communication between BMS boards. I planned to use a cell phone type display for the bike computer. I actually have the display portion working, but have been busy with other projects. I will start a new thread on this design, so I can get inputs and motivation to work on it. Here are pictures of the boards. The left one is not really ebike related, just a GPS data logger I planned to use to log my biking. The top right board is the bike computer; it requires a 5 volt source to run. I didn’t bother to incorporate a high voltage converter, since there are plenty of good dc/dc converters out now. Castle Creations has one that is really small. Bottom left is the BMS board; it is 1”x1”. I was going to make it SMT, but decided to keep it easy to build. The middle is an allegro current sensor, this is dependant on which version you use. The right is an interface board to attach a Nokia cell phone display.

Link to the new thread
http://endless-sphere.com/forums/viewtopic.php?f=14&t=12557
 

Attachments

  • bike computer and BMS.jpg
    88.4 KB · Views: 1,162
Thanks!

So your using a Max232 to marshall RS232 serial from the monitor modules? Adds a bit of complication... is there some reason your not using the PIC for serial interface directly?

One more question... if your using a BEC to get the 5v power supply off the pack in whole, what happens when the pack is not stable, over or under voltage somewhere, etc... how do you cutout your own power source? wouldn't having a small nimh pack as an alternate power source so the BMS can still function in the event of a cell failure or loose wire from pack, blown fuse, etc.?

Cool to see someone else working towards a simliar goal. Especially when they have PCBs ready form laying around for the project... you started last year? Tell me where to send the exploding lipos to light the fire under you = )

Seriously though, let me know if I can be of assistance (though I have cautioned in this thread against PIC use for this particular goal for a variety of reasons, I do write PIC code and have worked with them for years).

-Mike
 
The serial link is only for an external computer. It is not part of the BMS communications. BMS is done in bitbang 1 wire serial, similar to what you had with opto isolation. Pretty much the same setup as solarvan. I had room so I added the serial portion to it for debugging and data logging. Doesn't even need to be implemented.

I didn’t like the idea of having to have another power source for the bike computer since the battery from the bike should be plenty. The only issue is loosing data if the battery is disconnected. This can be solved by storing the data in the eeprom.

Yeah, it was pretty much around the time I saw the pic thread startup. I started liking the idea and quickly came up with a design. I was this year that I actually got the boards sent out and now I need to focus on getting them built and tested. I've been doing boards for years so I'm pretty confident that they are at least workable. If you follow my other links, you will realize I just have too many project going, and I get easily distracted with new projects.
 
kfong,

Sorry man... I meant no offense, I think we all have 12-15 projects going on and I for one drop more projects / ideas than ever come to fruition.

The boards look good and workable, I shoud have realized the Max232 was for PC communications... drrr = )

I have been examining Use Cases of powered vs drafted from eBike for power source. Both Use Cases end the same at the cell / sub pack level so I guess it's just as good to have a unit fail because the cell it's attached to is dead. This would trigger the master into an error state disconnect of some terminating FETs on the entire pack. The only real difference (besides logging as you previously posted, eeprom is not sufficient for logging imho because of the sample rate I would want to write to eeprom would wear it out too fast) is that in the Use Case with seperate power there are methods we can use for shunting a bad cell (possibly) to allow limp home operation and we will know that a specific cell in the pack is dead, not the pack. Truth be told, in the real world ... what can you do about it then? Nothing if your not at a shop or your home so... why bother with detailed analysis of data on the spot, it can be done later.

In short, after reconsideration... I suppose the UseCase is the same at the cell monitor level no matter if they are powered by the cells they are monitoring or seperate batteries... the main MCU controlling the whole show is another matter. This MCU needs to be able to disconnect the PACK durring these failures / error states & conditions for safety (doesn't it?).

I am no expert, nor am I claiming to be one... just a dude with alot of background in software & hardware design and development projects and mcus trying to help out the cause...just like everyone else I think (though I am certain that will draw out a few Experts... I have never been much on self proclaimed experts).

*I just noticed the PCB has a PLCC type footprint for the PIC... which were you planning to use for this? Personally I prefer the PLCC type of any MCU and in a Socket for easy replacement.

-Mike
 
I don't want to clutter this thread any more than it already is. please head over to the new thread specific to the design.
http://www.endless-sphere.com/forums/viewtopic.php?f=14&t=12557
 
mwkeefer said:
With regards to communications between slave units.... 1 wire would be sufficient but I think noise would be an issue while serial (2 wire) communications have built in error control/ detection we could leverage. The protocols are actually already supported by these chips so the source to implement is tiny and available for all = )
.....
Personally I don't care if we use slave/master, have a GUI or what so long as the BMS protects the RIDER from fault conditions and dangers such as over discharge, over charge or thermal run away. That is ALL I CARE ABOUT at this point and I am happy to lend my help in any effort and in any way I can.

-Mike

If you daisy chained the communications on a 1 wire system I still think you could have noise issues. When you have a controller drawing lots of current with some serious PWM spikes, I think it could ruin your day.
I'm pretty convinced the only reliable way is to use optical isolation on each cell. I think this means each cell needs a Rx and Tx pair of optocouplers.

The 'bare bones' system with no GUI or master unit does have some advantages. I think there should be some clever way to work the signals so that all the desired modes can be accomodated with a minimum of hardware.

Charging current control is the stickiest problem regardless of overall topology. One approach is to use the same kind of PWM throttling that my analog board uses. This is good for smaller systems under 20A. Another is to interface to the charger, which requires a custom charger. I'm still thinking about this.

After I give it some more thought, perhaps I can make a kind of program flowsheet and get some help converting it into actual code. The code examples are really helpful, it looks like I may actually be able to figure some of this stuff out on my own eventually.
 
Fechter,

The noise is another reason to go with external power source for the monitor / computer system. Then we don't have to worry about PWM noise so much since we don't need to sink power from the controllers or eBike batteries (yes I am trying to move away from opto couplers, at least we need to use in digital full on/off mode to avoid breakdown over time). The scaling of external power should be fairly simple to do... base it on the size of the pack, nominal life of the pack (between recharges) and just recharge it off the main feeds when recharging the pack.

Does this complicate parts of the design? Yes

Does it practically remove any and all issues with power line noise, battery failure (ebike pack), etc... Yes

imho, the advantages here far outweigh the disadvantages... engineering wise it is fairly straight forward.

Bare bones with the ability to upgrade.. yes that design is best from a cost / complexity perspective, add the UI, LCD screen, other parts if needed or desired but the base must implement the HVC, LVC and temp monitoring and communicate with the controller to effect these conditions.

For the charge current limiting: I think initially we should design a "path around" similiar to your analog designs, for the average users it should suffice (I am average and run between 5-15AH @ 15S 1-3P). That said, we can also do a 3-4 wire custom charger... use the MCU to set and regulate CV and CC so basically the charger would be a dumb brick supply of varying current / voltage levels. I can help here, as I posted elsewhere... I have a few chinese samples coming in for 50.4v and 63v chargers (CC/CV), my company is ordering a bunch of these for a product we will be bringing to market soon. That said, I can probably enhance the design to accept our systems input. For a final version we should standardize the interface to any custom charger and release the protocol specs.... encourage others to build acceptible chargers for this design.

Which code examples? If you need assistance in writing Use Cases, specs, requirements, etc... just ask. If you need assistance with coding, again please just ask... if I can't do it, I am sure someone here can =)

-Mike
 
mwkeefer said:
For a final version we should standardize the interface to any custom charger and release the protocol specs.... encourage others to build acceptible chargers for this design.
..............
Which code examples? If you need assistance in writing Use Cases, specs, requirements, etc... just ask. If you need assistance with coding, again please just ask... if I can't do it, I am sure someone here can =)

-Mike

Regardless of how the MCU is powered, it still needs to measure a noisy voltage, which can still cause problems. I've seen enough examples of cell powered units that seem to work, so I think you just need to pay attention to proper layout and bypassing to avoid power noise problems. Personally, I'd rather install brute-force filters than resort to a separate battery. I don't think it's too hard to do an effective filter.

Yes, a charger standard would be nice. Let me try and find out what they're doing on the Kingpan chargers. Otherwise, we could arbitrarily define one, but it would make more sense if it was something easy to implement.

Let me try to more precisely define exactly what I want the code to do, then I'll ask for help.
 
Can someone point me to any data on the expected noise power spectrum, as I don't have a good feel for what the internal pack AC currents would look like when supplying a switched motor. I'd expect some capacitance in the controller to cover transients, and maybe more could be added to the battery plus some inductive suppression. What I am getting at, is it totally out of the question to shield the battery from the outside world, and then communicate internally using pulses on the DC power bus?
 
fechter,

Not sure if this helps us or not but my company just got done researching the purchase of a few hundred 63v cc/cv chargers with variable cutouts in powers from 2.5 - 10 amps, the pricing was reasonable across the board (on par with a low cost PC power supply) when ordered in 100+ qty.

These follow a 6% cutout rule so they charge CC until CV and then they do the pulse cycle (charge, take reading) through the CV state until the draw is at 6% of rated power, the charger automatically disconnects when it reaches this level.

These could be had for between 25-75 each in 100+ qty.

I would think it will still be easier to design the charger and send out the specs to be manu (as my company has just done).. these items are simpler to produce in mass.

-Mike
 
I'm probably coming in way late here, and this may have already been addressed - or abandoned. I only made it about halfway through the thread before I gave up, then read the last few pages as a catchup.

Much earlier, there was a lot of discussion about simple ways to do the voltage measurement. The big problem is voltage offset for packs of more than a few cells. If that's still an area of interest, I have a proposed solution that I think is simple enough to be worthwhile.

There was a lot of discussion about differential amps, which are great little devices but not necessary here. You can do the subtraction in the uP, so all you really need to measure is the voltage at each balance tap of the cell. You can do this with voltage dividers and op-amps, and reference the whole thing directly to pack ground to avoid the offset voltage problem altogether.



The first cell doesn't need any divider at all. The second cell gets a divider with equal resistors, so the measured voltage is still ~1 cell. The 3rd cell has a 1/3 divider, 1/4th, etc all the way to N cells so the voltage at each op-amp is roughly 1 cell. If R is chosen as a few kilo-ohms, the current drain will be <1 mA each. You could set R higher (100's of k even) to make the drain negligible, but you'd probably want to add another op-amp for each channel to buffer the measurement and avoid errors.

Each channel gets an op-amp configured as a comparator. I've shown them here set up as Schmidt triggers, so they have some hysteresis for better noise performance. You'd want to set the hysteresis pretty small to reduce offset in the measurement (maybe low 10's of mV), but there are things you could do on the digital side to remove that. The other side of the op-amps are all connected either to a D/A output on your uP or to an external DAC. External DAC would likely give you more precision, if you could use a 12-, 14- or even 16-bit part to get really fine resolution. The uP would drive the DAC to generate a linear ramp function. When the ramp voltage is the same as that on the balance tap, the comparator triggers and the output goes high. It's the exact principle that's used in many PWM generators, in reverse. The advantage here is that the output is now just a digital signal. You can use a cheap digital mux to string together N comparators for N cells, and you still only need a single input (not even an A/D input) on your uP to measure the voltages! Plus, you need log2(N) outputs to drive the mux, and 2-3 more outputs if you use an external DAC w/ serial control. Still, this scales very nicely in that you'd only need 8 outputs and 1 input to measure up to 32 cells. You'd need either N or 2N op-amps, but any old quad-pack cheapie would do fine.

On the software side, it should be pretty easy. I'm not any sort of uP expert, but there are all sorts of fairly simple counter/timer structures that could be used to convert the timing of the comparator pulse back to the measured voltage. N-1 subtractions and you have all the individual cell voltages. You wouldn't want to run the ramp very fast to get the most accurate measurement, but something like 100 ms might be good. That would still let you cycle through in 2.4 s for a 24s pack which should be plenty fast.

Does that seem useful to anyone? I left off circuit details for now - resistor values, capacitors for bypass and filtering, etc.
 
"Safe" was posting earlier about using different dividers with the MCU doing the subtractions. I think straight ADC measurements would have been too noisy and the cumulative errors would end up too high. Your method of inverse PWM might solve that problem, but I think most everyone wants the BMS to be able to shunt current around charged cells as well.
 
dak664 said:
Can someone point me to any data on the expected noise power spectrum, as I don't have a good feel for what the internal pack AC currents would look like when supplying a switched motor. I'd expect some capacitance in the controller to cover transients, and maybe more could be added to the battery plus some inductive suppression. What I am getting at, is it totally out of the question to shield the battery from the outside world, and then communicate internally using pulses on the DC power bus?

There is not much data around, but I can guess that when you're pushing like 10kw into a PWM going to a motor, the noise will be brutal. Above a certain frequency, however, it will drop off. It should be possible to use a high frequency to communicate if it's high enough. Bluetooth?
 
mwkeefer said:
I would think it will still be easier to design the charger and send out the specs to be manu (as my company has just done).. these items are simpler to produce in mass.

-Mike

Probably correct, but I am unlikely to be able to afford any kind of large quantities. Therefore I would like to design around something that's already available if possible. My guess is if we only need a minor modification to an existing design, it would make things much easier.
 
dak664 said:
"Safe" was posting earlier about using different dividers with the MCU doing the subtractions. I think straight ADC measurements would have been too noisy and the cumulative errors would end up too high. Your method of inverse PWM might solve that problem, but I think most everyone wants the BMS to be able to shunt current around charged cells as well.

Yeah, I read a lot of that part of the thread. I don't think his method would ever work, using the non-ideal dividers and analyzing the whole circuit. That's a massive linear algebra problem, no way a little 8-bit PIC would stand a chance and you'd probably want to shoot yourself trying to program it. Using the op-amps is critical so you can do some hand-waving and make lots of ideal assumptions. The inverse PWM reduces the part count somewhat and avoids costly parts like analog muxes or high-voltage op-amps.

You're right, I didn't address the shunt side of things, just the voltage measurement. :idea: I just had a bit of a brainstorm. How about something like this:

https://ec.irf.com/v6/en/US/adirect/ir?cmd=catProductDetailFrame&productID=IR21363S

More info here: http://www.irf.com/technical-info/appnotes/an-985.pdf

IR21363, a 3-phase motor drive IC. It has three low-side drivers and three floating high-side drivers, with a built-in bootstrap to provide the necessary gate drive voltage. You could use one of those ICs to drive shunt bypasses for a 6-cell block. That's not the designed configuration, but each driver operates independently so it can be used this way. It's designed to take TTL or CMOS level inputs, which would have to be ground-referenced to the bottom of the 6-cell block. So, it doesn't totally get around the problem for something like a 24s pack, but it does allow a single uP to control a larger block of cells that it could handle by itself. Those IRF parts are about $3 so that's $0.50 per cell, not bad.

:idea: OR, You could use one of these for each cell:

https://ec.irf.com/v6/en/US/adirect/ir?cmd=catSearchFrame&domSendTo=byID&domProductQueryName=IRS2117SPBF

That's a single-channel floating driver. So, you could use 24 of those to control bypasses on all 24 cells from a single reference at the bottom of the pack. They're about a buck each, which isn't bad, but it's not super elegant and each one needs a couple external components. And you'd need a uP with 24 outputs to control the whole shebang. Not great.

Actually, I take that back, too. :D

:idea: Problem: controlling N shunts requires N outputs. You can't mux them because you need more than one on at once, it could be any arbitrary combination from 0-N on simultaneously.

Solution: use a T or JK flip-flop to hold the state of each shunt. (For those without some EE background, here: http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Toggle_flip-flops_.28T_flip-flops.29). All the shunts start in the off state. You use a mux with the appropriate number of channels to address the T output of each latch (or J and K together). When you want to turn a shunt on, address that channel to set T high, then issue a clock pulse (you can use one clock bus to connect all the latches) to toggle the shunt on, the flip-flop then holds that state. Another toggle will turn it off. Requires only log2(N)+1 outputs to control N switches, or 6 pins for 24s configuration. :twisted: Flip-flops are cheap 74-series logic, like $0.50 for a dual package. Total cost, IRF driver + flip-flop: ~$1.25-$1.50 per cell, no optocouplers or anything special required.

Whew. I think I'm done now. :shock:
 
fechter said:
There is not much data around, but I can guess that when you're pushing like 10kw into a PWM going to a motor, the noise will be brutal. Above a certain frequency, however, it will drop off. It should be possible to use a high frequency to communicate if it's high enough. Bluetooth?
One of the google hits was a robotic power bus sending commands to dozens of PWM motors!
http://www.yamar.com/ makes chips for that purpose.
DC bus data schemes seem to be mostly based on quadrature phase encoding, e.g. http://www.techbriefs.com/component/content/article/2487. Spread spectrum can operate at low power in a high power noise environment, if the noise is mostly concentrated into harmonics.

RF is a possiblilty and the chips are fairly inexpensive, but it won't be the cheapest. Digikey has a deal for an ATMega644P/AT86RF230 bundle for $6.68; the 'RF230 alone is ~$2 qty 100. It pulls around ~15ma at 3 volts for a ~10kbit/sec zigbee link out to 10-20 meters. They are rather simple from the software side, internally doing all the CRC checks, collision detection and retransmissions, and could be driven by an ATTiny. Having one inside the pack would be nifty, to talk to an external data recorder or control module. I have been working with them for the past year in the form of atmel "ravens".
 
Okay, one more then I'll shut up and let some others comment.

The problem with the previous idea, using flip-flops to control the state of the shunts, is they're binary - fully on or fully off. One of the nice features of the analog BMS setup is that the shunt current varies as needed. To accomplish this in the digital version would require PWM control.

Solution: digital potentiometer for each channel instead of flip-flop. They're cheap (for example, the MAX5462 is $0.42/ea) and widely available. They work just like an analog pot, except with digital control of the wiper position. Most of the cheap basic ones have 5- or 6-bit resolution, which should be plenty. This one has a simple control scheme with chip select pin and an up/down toggle (i.e. negative pulse decrements, positive pulse increments). This could still be controlled from the uP using a digital de-mux for the CS pins and a single up/down bus (log2(N)+1 outputs needed). The digital pot is connected from +5V (digital supply) to ground, so the result is a variable voltage on the wiper. As on the measurement side, use an op-amp comparator with a ramp signal on the other input, the result is PWM modulation controlled by the digital pot. Use that PWM to run the high-side drivers from before and you have variable shunt control. 8)

Also, there's probably no reason you need to control the shunt de-mux separately from the measurement mux, so they could share the same set of address lines. Measure the voltage, adjust shunt as necessary, then move on to the next cell. This whole scheme would only require something like 10-12 I/O pins on the uP to have full measurement and control of a 24s pack.

Example circuit here:
View attachment eBike Voltage Measurement.pdf
 
Kudos for your fast drawing skills. Wish I could prototype as quickly ;)
I suspect straight digital connections would be prone to noise in this environment without lowering the impedance quite a bit, which would add power drain and more parts. What mayhem would a few noisy bit changes cause?
 
dak664 said:
Kudos for your fast drawing skills. Wish I could prototype as quickly ;)

Thanks, but I didn't really draw those. I did those as quickie schematics in Cadsoft EAGLE, which is my favorite free/cheap schematic/layout software package.

dak664 said:
I suspect straight digital connections would be prone to noise in this environment without lowering the impedance quite a bit, which would add power drain and more parts. What mayhem would a few noisy bit changes cause?

Actually, the reverse should be true. Digital signals have quite a bit of noise immunity, especially high-level TTL signals. If you're holding the signal low at ~0V, it would take about 2.5V of induced noise to cause problems, which would be huge. A few prudent precautions in the design and layout should prevent any problems with lots of noise margin left. The place you'd have to be more careful is with the op-amp/comparators. Shouldn't be a problem if done right, but a little care is required for best results - a few decoupling capacitors, that sort of thing.
 
Hello all,

I just had to chime in... the idea of using the MAX5462 is excellent, cheap abundent and seems to serve the purpose.

In relation to the previous post... if were controlling current on a per cell basis (ie, shaping current) the we would only be shunting current when the cell (weakest or least discharged) reaches the HVC correct? If that's the case then binary on/off is not an issue... we really only need to bypass the cell.... then durring the next voltage level scan (charge v and c down to get valid measurement) check the "full cell" to see if it's voltage has dropped.... if it dropped, remove the bypass so it takes a charge again... if it didn't... leave it shunted.

This method allows for binary toggle off on HVC (per cell) then re-analysis in a few ms (or seconds) to see if it should leave shunted / bypassed or if it should continue allowing the current to pass.

Also....

I have been playing with the BM6 units and as yet have not managed to dump the HEX and EEP files however, I have identified and documented the ISP (Inline Serial Programming interface) to the Atmega48v in addition to pulling the specs for these chips and all supporting chips in the system. I have also configured (this is rough) some firmware which will allow an Atmega328P to monitor up to 6 BM6 units at once, as a hint I analyze the beep pattern because I found they all have the same frequency on HVC/LVC even if the amplitude varies, I use this pattern to create a square wave form and then count the digital 1s. This has (so far and again just for me, your mileage will vary) worked flawlessly.

The firmware (HEX/EEP) for the Atmega328P and the specifics will be posted to a "BM6 Technical Information" and "BM6 Alternative Uses and Modifications" threads I will create later this week. This will code will allow you to program your Atmega328 to detect LVC or HVC and based upon the mode of operation (Charge/Discharge) it will trigger events to happen.

Basically I have mine performing 2 functions: 1.) Light up LVC warning light on bar display, 2.) 5v trigger to unlatch power lead latching switch to provide cutout (other methods possible such as throttle interrupt, pulse, etc.)

This is crude at best but for my purposes of getting running now and not spending a fortune:
1 x Atmel Atmega328P: 5.00
6 x Chargery BM6 units: 12.99
Total: 82.94 (I had alot of transistors and other misc parts laying around)...

So for less than 100 I can monitor 30 cells in my 15S2P pack at teh same time.

-Mike
 
mwkeefer said:
In relation to the previous post... if were controlling current on a per cell basis (ie, shaping current) the we would only be shunting current when the cell (weakest or least discharged) reaches the HVC correct? If that's the case then binary on/off is not an issue... we really only need to bypass the cell.... then durring the next voltage level scan (charge v and c down to get valid measurement) check the "full cell" to see if it's voltage has dropped.... if it dropped, remove the bypass so it takes a charge again... if it didn't... leave it shunted.

In this case proportional control should perform better, i.e. less time to full charge. I'm not certain if it's a good cost-benefit tradeoff, though, I don't have enough experience with BMS and battery charging. Binary on/off switching (called "bang-bang control" in the controls world) would cause the cell voltages to vary up and down more than and adjustable shunt, but I don't know if we're talking 10 mV or 100 mV. The analog version of the BMS implements proportional control due to its analog nature.

Assuming that variable (proportional) control is better, an interesting question is if a more advanced control scheme would be better still. Proportional-Integral (PI) control is very commonly used and often better than proportional alone. The advantage of the integral term is a tendency to drive the system better to zero error (error in our case would be the difference between actual cell voltage and desired charge voltage). I've read some people talking about the analog BMS sometimes just tapering off without actually locking and finishing - the addition of integral control might help fix that. Proper PI control would be a pain in the a$$ to build in analog circuitry, so that could be a value-added advantage of the digital approach.

A little light reading for reference:
http://en.wikipedia.org/wiki/Bang%E2%80%93bang_control
http://en.wikipedia.org/wiki/Proportional_control
http://en.wikipedia.org/wiki/PID_controller
 
If the processors run pretty fast, a bang-bang control will be much like an analog PWM. That's pretty much how my analog circuit is functioning. With a 10Ah A123 pack, I see variations around 20mv during switching at around 200hz. Higher frequencies give lower ripple voltages.

The response time of the system is very fast in terms of current vs. duty cycle, so a simple feedback with gain tends to work. If the system oscillated, then I'd add the integral part. Actual cell voltage changes very slowly compared to the response time, so the cells act like an integrator already.
 
Back
Top