Ebike Battery Monitoring and Control System

Batteries, Chargers, and Battery Management Systems.
Post Reply
User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Ebike Battery Monitoring and Control System

Post by Alan B » Mar 04, 2011 11:52 am

I'm collecting Lipo batteries and setting up my ebike. I'm starting with RC chargers and a simple balance tap paralleling board, but I would like to be able to monitor and collect data on my battery pack. Initially I thought I would use celllog's for this, and they are cute, but I just can't see myself dealing with the downloading of three or four of them more than a few times. I would also like to be able to experiment with some different charging and balancing algorithms, and have a readout that was easier to deal with on the bike. I want to learn more about what is really going on with these batteries. Eventually I want to have one-plug charging from AC.

My pack is still evolving but will probably be 18S4P of 6S 5AH 25C Turnigy packs, so 20AH total. So I'll have 18 sets of paralleled cells to monitor, charge and balance.

So what I want to do is more than a battery management system, it is a data acquisition and control system for batteries. So I'm looking at what that might be:
  • Read each cell's voltage, display, store for later analysis
    Measure temperature
    Provide low voltage protection (probably ebrake or throttle control output)
    Compatible with 5S and 6S Turnigy packs
    Connectors for paralleling 4 balance connectors (JST-XH balance connector)
    Small and modular to fit in the available bits of space, integrate with battery pack
    Low standby current drain
    Programmable for data acquisition and charge algorithm development
    Cabling Minimization
    Testing Port - for reading out cell voltages and doing balance charging with an external charger when needed
    System must be self-testing, give some verification that it is actually working
This leads me to something physically similar to Fetchter & GGoodrum's BMS boards - four JST-XH connectors for the balance taps, but with totally different electronics. Something that can be mounted in the little leftover spaces available in a compact ebike battery build.

Some questions:
  • Cell Voltage Measurement Resolultion and Accuracy requirements? (is 10 bits adequate?)
    Balance current requirements? (is 100 mA enough?)
    Standby Current Drain requirements? (How much is too much?)
Other considerations?

Thanks for your comments,
Last edited by Alan B on Oct 02, 2013 3:19 pm, edited 6 times in total.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Control System

Post by Alan B » Mar 05, 2011 1:40 pm

A 10 bit unipolar ADC with a full scale range of 5 volts is about 5 millivolts resolution. Accuracy is about plus or minus 2 counts so 20 millivolts with the micro I'm planning to use.

I decided to go directly to surface mount on this project. More rugged and smaller, and the parts are less costly. It appears that the JST-XH connectors will be through hole but the rest can be surface mount. I can load small quantities of surface mount boards in my shop.

I'm considering the ATTiny 24/44 micro which has more I/O pins and is available in a package 4mm by 4mm that is not too hard to handle. Cost is under a dollar in quantity. Planning to use one micro per cell plus a couple of optical isolators to a serial bus for communications. A master micro will poll them all and make the decisions. The schematic is coming along. It has about 12 parts per cell.

From reading lots of info from ES and the internet it seems that 100mA is generally considered sufficient balancing current for a 20AH pack. I would like to keep heating in or near the pack to a minimum. The main downside to a low balance current is taking more time to balance. Since the balancing takes place near the end of the charging cycle this should not be a big problem. When the charge time is too short for full balancing just quit before balancing is complete. At home when more balancing time is available it will do a better job of it. Once a pack is well balanced very little balancing time is required anyway. Controlling the balance algorithm with a micro will allow it to be a bit more accurate and start a bit earlier so it won't take as long. At least that is the theory.

KiCad is not quite doing what I need easily enough, so I'm switching to FreePCB which is a lot simpler to get started with. Perhaps later I'll get back to KiCad but it is slowing me down too much now.

I'm going to use BatchPCB to make boards for this. Quality is high and costs are reasonable. Not as fast as I'd like but I have lots of other projects to work in parallel anyway.

Standby current is interesting in a one micro per cell design. The standby current of an ATTiny24 in shutdown is less than 2 uA. So that, plus the leakage of the protective zener and balance control FET will still only be a few uA. So if we can avoid turning on other features that draw more power we can probably stay under 5uA total standby drain. That is quite low. It is over 100 years to drain a 5 amp hour pack, so far longer than the life of the batteries.

There are several things that might increase the standby current drain. The watchdog timer clock, the brownout detector, and the voltage scaling resistors. I don't plan to use the brownout detector or watchdog timer. The voltage divider for the ADC is required since the ADC input is 1.1V max. But I'm planning to turn that divider off when not making an ADC reading so it will not be drawing current during standby.

Waking up the processors will happen by interrupt. The master will send out a command via serial and the optical couplers route it to all micros in parallel. The change of state on the pin wakes all the micros up. They use a timer in the software to shut back down after an interval without activity. The micros draw a few mA when running, and they can sleep after a few seconds of inactivity.
Last edited by Alan B on Oct 02, 2013 3:20 pm, edited 1 time in total.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 05, 2011 4:17 pm

Here's an updated schematic of the circuit thus far:

Image

This larger micro with more pins also allows the use of a ceramic resonator which is helpful in keeping the serial communications synchronized and is one less thing to calibrate.

There are a few available pins for other purposes such as temperature measurement.

User avatar
dak664
1 kW
1 kW
Posts: 320
Joined: Aug 17, 2008 1:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by dak664 » Mar 05, 2011 6:27 pm

Search the forum for ATTiny if you haven't already, there are some similar ideas. I used ATTinyx5's which are cheaper but have fewer pins. Note on either 'x4 or 'x5 temperature sensing and Vcc measurement can be done without using any pins. I'd definitely get the V version to operate down to 1.7 volts (at 4 MHz). Then you can still get messages when the cells drop below 2.5 volts.

Why the crystal? The internal RC oscillator should be good enough.

100 ma is wimpy for big-time balancing if done the usual way of kicking in when the cells reach some high trigger. But even 50 ma could do the job if the balancing occurs over the entire charge cycle. That would require passing information to all cells about the highest and lowest ones so each could decide how much to shunt. The mcu should be able to shunt 50ma internally so that could get rid of the FETs.

All the pictures seem to be gone in the other threads, but this link to my source code still works
https://endless-sphere.com/forums/downlo ... p?id=28244

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 05, 2011 8:17 pm

dak664 wrote:Search the forum for ATTiny if you haven't already, there are some similar ideas. I used ATTinyx5's which are cheaper but have fewer pins. Note on either 'x4 or 'x5 temperature sensing and Vcc measurement can be done without using any pins. I'd definitely get the V version to operate down to 1.7 volts (at 4 MHz). Then you can still get messages when the cells drop below 2.5 volts.

Why the crystal? The internal RC oscillator should be good enough.

100 ma is wimpy for big-time balancing if done the usual way of kicking in when the cells reach some high trigger. But even 50 ma could do the job if the balancing occurs over the entire charge cycle. That would require passing information to all cells about the highest and lowest ones so each could decide how much to shunt. The mcu should be able to shunt 50ma internally so that could get rid of the FETs.

All the pictures seem to be gone in the other threads, but this link to my source code still works
https://endless-sphere.com/forums/downlo ... p?id=28244
Thanks for your comments. I'll have to find the trick for Vcc measurement without pins. Perhaps that involves using Vcc as the reference and measuring the Vref source? Cute. I was planning to use 1.8-5.5V parts.

I was looking at the pin current limitations. One place says 40 mA per pin 200 mA total absolute max, another says 10 mA per pin max 60mA total continuously. So 50mA is certainly possible. I like that idea and I was planning to start balancing earlier in some manner.

The Tiny25 is the other candidate I was considering. I have used those in a few projects.

The resonator was a suggestion from someone off the forum. It would make it easier since calibration is not required, and the stability of the RC oscillator over the temperature range might be an issue, but perhaps they track together well enough? Or I suppose temperature correction could be done. I have used the internal temperature sensor in the Tiny25.

Thanks again, I've looked before but it is sometimes tricky to know what to search for. Will try that. I did read the whole pic bms thread at one point but that was some time back.

Great suggestions.

User avatar
dak664
1 kW
1 kW
Posts: 320
Joined: Aug 17, 2008 1:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by dak664 » Mar 05, 2011 9:09 pm

Here's the only full jpg that still shows up from my previous posts. 10 amp-hour Headway cells, both Headway BMS and TinyBMS are in parallel. The nominal 2 amp NiMH charger was turned off midway it was probably only putting out 50ma at that point. After 15 minutes a 50 volt power supply was connected through a series resistor to give a constant 150ma charge rate. The plateau is where all the cells are being shunted by the headway BMS; briefly the charge rate was raised to 500ma to see what overwhelming the shunts would do.

The Tinys are doing no shunting, just monitoring the voltages. The blue line is not to be believed, I had an ammeter in series with Vcc on that Tiny. I'll try to locate some pix of the hardware and upload them again.
Image

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 05, 2011 9:36 pm

I found David's C source code and ascii schematic. Looks like the Vcc measurement is using the pullup and an external resistor as the divider, requiring 2 pins. Saves one resistor. Cute. For others following this thread:

https://endless-sphere.com/forums/viewto ... 85#p190465

Note that I found this by searching for attiny85

Another trick I thought about is to use some balance shunts to +V and some to -V so as to distribute the shunting current between the Vcc and Gnd pin to increase the capacity. Would need more pins to get very far with that, but the Tiny24 does have more pins.

Interesting to see your comment that the Tiny85 doesn't get warm at 50mA through two pins. Good data.
Last edited by Alan B on Mar 05, 2011 10:05 pm, edited 1 time in total.

texaspyro
1 MW
1 MW
Posts: 1519
Joined: May 12, 2010 6:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by texaspyro » Mar 05, 2011 9:43 pm

I don't think the ATtinys have a Vcc input to the ADC... no way to measure Vcc without using a pin. Their on-board temp sensor is rather crappy, but can be calibrated.

Ditch the resonators... they will increase your power drain.

Put a filter cap on the ADC input...

Consider AC coupling the balance FET gate drive and perhaps drive it with a PWM signal. You can adjust your current in software. AC coupling also makes it a whole lot less likely that a hung/glitched processor will turn on the FET and kill the cell. You have to intentionally drive the balance FET with a waveform to keep it on. I'd use a software bit-banged PWM instead of the hardware PWM... less chance of inadvertently driving the FET. Does add a couple more parts per cell.

You can increase the ADC res by averaging several readings. WIth careful selection of divider resistors you can get direct 0.1 millivolt resolution without having to do any divides, etc. Just sum the proper number of samples and the count will be in 0.1mV steps (0..6.5535V). My high power LED driver does this to monitor the battery pack voltage and temperature sensor.

My LED driver uses a tiny13a. It is always powered by the pack and draws 20uA in standby. Most goes to the LM2936 regulator and the voltage divider on the battery pack. I use a divider with around 5 megohms impedance... the chip is spec'd at 1 uA leakage current, but it is closer to 1 nanoamp.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 05, 2011 9:53 pm

I see further down David converted to the zero pin/parts method.

Here is a discussion of measuring VCC vs Vref without using any pins or parts (AVRFreaks) (link from thread linked above):

http://www.avrfreaks.net/index.php?name ... dc+battery

One problem with this is precision. It is about 8 bits accurate at 4 volts, so 2 bits of accuracy/resolution are lost.

The way this works is to set the Vref to Vcc and measure the 1.1V bandgap with the ADC. Then work backwards to the unknown Vcc from the known bandgap.
Last edited by Alan B on Mar 05, 2011 10:06 pm, edited 1 time in total.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 05, 2011 10:04 pm

texaspyro wrote:I don't think the ATtinys have a Vcc input to the ADC... no way to measure Vcc without using a pin. Their on-board temp sensor is rather crappy, but can be calibrated.

Ditch the resonators... they will increase your power drain.

Put a filter cap on the ADC input...

Consider AC coupling the balance FET gate drive and perhaps drive it with a PWM signal. You can adjust your current in software. AC coupling also makes it a whole lot less likely that a hung/glitched processor will turn on the FET and kill the cell. You have to intentionally drive the balance FET with a waveform to keep it on. I'd use a software bit-banged PWM instead of the hardware PWM... less chance of inadvertently driving the FET. Does add a couple more parts per cell.

You can increase the ADC res by averaging several readings. WIth careful selection of divider resistors you can get direct 0.1 millivolt resolution without having to do any divides, etc. Just sum the proper number of samples and the count will be in 0.1mV steps (0..6.5535V). My high power LED driver does this to monitor the battery pack voltage and temperature sensor.

My LED driver uses a tiny13a. It is always powered by the pack and draws 20uA in standby. Most goes to the LM2936 regulator and the voltage divider on the battery pack. I use a divider with around 5 megohms impedance... the chip is spec'd at 1 uA leakage current, but it is closer to 1 nanoamp.
Some great suggestions here. Thanks. I have noticed how poorly calibrated the temperature sensor is.

texaspyro
1 MW
1 MW
Posts: 1519
Joined: May 12, 2010 6:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by texaspyro » Mar 06, 2011 1:08 pm

Alan B wrote:The way this works is to set the Vref to Vcc and measure the 1.1V bandgap with the ADC. Then work backwards to the unknown Vcc from the known bandgap.
It still won't work... there seems to be no way to connect the bandgap internally to the ADC...

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 1:20 pm

texaspyro wrote:
Alan B wrote:The way this works is to set the Vref to Vcc and measure the 1.1V bandgap with the ADC. Then work backwards to the unknown Vcc from the known bandgap.
It still won't work... there seems to be no way to connect the bandgap internally to the ADC...
David did it with the Tiny25, as I understand it.

I don't plan to do that as I don't want to give up the precision. On the Tiny24 there are plenty of pins available and a pair of precision resistors are only 4 cents.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 1:31 pm

Here's another concept schematic with a fairly minimal approach:

Image

Direct drive the balance resistors, no external FET (limited to about 50 mA balance current), no Resonator, added filter cap on input voltage.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 1:34 pm

Planning to use this commercial Sparkfun board as the "master" micro to poll the cell controllers:

Image

Note - not sure these are available anymore, consider Teensy or Arduino boards.
Last edited by Alan B on Oct 02, 2013 3:21 pm, edited 1 time in total.

User avatar
dak664
1 kW
1 kW
Posts: 320
Joined: Aug 17, 2008 1:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by dak664 » Mar 06, 2011 3:45 pm

I'd breadboard something first to see how accurately you can measure the voltage, and a possibly related issue, what the minimum sleep current is. A fixed voltage divider draws current all the time; An internal (10K nominal) pullup to supply Vcc to an external resistor to ground (or in your case to ground the low side of the divider) allows turning it off while sleeping but there is still some leakage. The mux bits for Vbg is 1100 on the x5 and 100001 on the x4. Vref bits for Vcc is 00 on either. I add 4 readings using the CPU sleep during conversion to reduce clock noise, the result rarely differs above the last bit. I measured the sleep current to be a bit less than a microamp.

Attached is the code I am using now. The default configuration is for the usual cell, it wakes on reset, measures the voltage, reports it through an infrared led, and then either activates shunts or goes to sleep. A #define of "TOPBANANA" makes it wake after 8 seconds so it can trigger the reset cascade of the other cells. There is also a define to do a high-gain measurement across a sense resistor and report that through IR as well. I use the ~11 milliohm resistance across the mid-pack polyfuses as the sense resistor. Measuring the current takes one of the pins used to send the reset pulse to the next cell, so that has to be the last cell in the trigger cascade. Consequently the TOPBANANA is on the other end of the polyfuses at midpack voltage, and the reset pulse has to jump the full pack voltage halfway down the chain. I changed the resistors to capacitors to accomplish this, they work as well most of the time but when the cell voltage is <2.5 volts or so the reset chain doesn't make the jump . Putting the fuses at ground potential on one end of the pack would fix that and would allow current measurement with an external MCU, but that has to be weighed against them no longer protecting any cell-to-cell shorts in the pack.

A couple other points, the MCU of course doesn't have to dissipate all the shunt energy, just the current times the voltage across the i/o pin when it is grounded. Most of the heat is to resistors or LEDs.

On the first startup after flashing the program it can detect there is no calibration data in EEPROM and go into a routine that writes it by measuring the programmer Vcc. The STK500 has adjustable Vcc so the calibration can be done at 3.5 volts (I measured it to be 3.460 volts). One could also calibrate the temperature sensor that way. That makes it easy to program a calibrated batch of MCUs!
Attachments
headwayshunt.zip
(6.22 KiB) Downloaded 108 times

Njay
10 kW
10 kW
Posts: 871
Joined: Sep 09, 2010 10:43 am
Location: Portugal

Re: Battery Data Acquisition and Charge Control System

Post by Njay » Mar 06, 2011 3:48 pm

If you are not doing constant dynamic equalization of the cells, why are you doing equalization on charge?...

User avatar
dak664
1 kW
1 kW
Posts: 320
Joined: Aug 17, 2008 1:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by dak664 » Mar 06, 2011 4:05 pm

In fact I rarely do equalization, I only use ~6 AH on my ride and recharge with a Bionx LiMn charger that stops around 41 volts. When the headway low voltage disconnect triggers, after 80 cycles or so, then I do a Bionx charge followed by a 100 ma equalization using a 50 volt power supply and a chain of 5 ohm resistors with an alligator clip tap to select the current.

I am not convinced equal voltage on each cell means equal remaining capacity, but if that is true then a continuous transfer from high to low cells would get a little more out of the pack, and make for more efficient charging . But resistive shunting during charge does bring up low cells which for whatever reason are not getting charged as much as they have discharged each cycle.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 4:35 pm

dak664 wrote:I'd breadboard something first to see how accurately you can measure the voltage, and a possibly related issue, what the minimum sleep current is. A fixed voltage divider draws current all the time; An internal (10K nominal) pullup to supply Vcc to an external resistor to ground (or in your case to ground the low side of the divider) allows turning it off while sleeping but there is still some leakage. The mux bits for Vbg is 1100 on the x5 and 100001 on the x4. Vref bits for Vcc is 00 on either. I add 4 readings using the CPU sleep during conversion to reduce clock noise, the result rarely differs above the last bit. I measured the sleep current to be a bit less than a microamp.

Attached is the code I am using now. The default configuration is for the usual cell, it wakes on reset, measures the voltage, reports it through an infrared led, and then either activates shunts or goes to sleep. A #define of "TOPBANANA" makes it wake after 8 seconds so it can trigger the reset cascade of the other cells. There is also a define to do a high-gain measurement across a sense resistor and report that through IR as well. I use the ~11 milliohm resistance across the mid-pack polyfuses as the sense resistor. Measuring the current takes one of the pins used to send the reset pulse to the next cell, so that has to be the last cell in the trigger cascade. Consequently the TOPBANANA is on the other end of the polyfuses at midpack voltage, and the reset pulse has to jump the full pack voltage halfway down the chain. I changed the resistors to capacitors to accomplish this, they work as well most of the time but when the cell voltage is <2.5 volts or so the reset chain doesn't make the jump . Putting the fuses at ground potential on one end of the pack would fix that and would allow current measurement with an external MCU, but that has to be weighed against them no longer protecting any cell-to-cell shorts in the pack.

A couple other points, the MCU of course doesn't have to dissipate all the shunt energy, just the current times the voltage across the i/o pin when it is grounded. Most of the heat is to resistors or LEDs.

On the first startup after flashing the program it can detect there is no calibration data in EEPROM and go into a routine that writes it by measuring the programmer Vcc. The STK500 has adjustable Vcc so the calibration can be done at 3.5 volts (I measured it to be 3.460 volts). One could also calibrate the temperature sensor that way. That makes it easy to program a calibrated batch of MCUs!
Very nice, David! You've been running this for quite awhile. What has been your experience with the reliability, long term accuracy, etc?

If the polyfuses open the voltage on the current detection input may be quite high. Hopefully that doesn't cause a problem.

I have the STK500 programming board. Great for DIP style processors.

I'm planning to use spring loaded pins to pads on the board for programming. Sparkfun has some nice info on how they do that on their website. Basically they use the PCB software to make a couple of boards to support the pins at the right spacing so they match the pads on the board. That way the programming setup doesn't take a lot of space on the target board. I'll program in-situ with these SMT parts, and that way the resistors as well as the ADC calibration will be compensated for. It is important to make this easy since quite a few need to be programmed!

Have you had any problem with the nonvolatile calibration getting messed up? Do you use the brownout detector to protect against that??

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 4:46 pm

Njay wrote:If you are not doing constant dynamic equalization of the cells, why are you doing equalization on charge?...
My plan is to do gentle equalization on the cells as the voltage rises toward the end of charge using a moving threshold based on the low cell. Reign the others back gently in this charge region. The problem is the highest cell must be held to a safe voltage and this limits the charge we can deliver to the lower cells. If we do this gently at the end of each charge cycle we should be able to head off an imbalanced pack early.

To do this will require some control over the charger. This has been done but is beyond the scope of this particular thread at this time.

User avatar
dak664
1 kW
1 kW
Posts: 320
Joined: Aug 17, 2008 1:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by dak664 » Mar 06, 2011 7:20 pm

Alan B wrote:What has been your experience with the reliability, long term accuracy, etc?
No problem with reliability except for my recycled connectors. Have never seen any change in voltage calibration compared to 2.500 and 5.000 precision references. All measurements done in a comfortable bench environment.
If the polyfuses open the voltage on the current detection input may be quite high. Hopefully that doesn't cause a problem.
Vcc would also be 36 volts for that Tiny. Basically I'm waiting for that to happen, to see what kind of a catastrophe it would be, with the capacitor coupling of the cells. If major I'll probably move the shunt to the minus side and go back to resistors for passing the trigger cascade.
Have you had any problem with the nonvolatile calibration getting messed up? Do you use the brownout detector to protect against that??
For the reader, eeprom can be corrupted if writing during a power failure, and the internal brownout detector can prevent that from happening. There are no eeprom writes after the initial calibration on the STK500 so no corruption possible. The brownout detector uses 50 microamps while sleeping so I'd give it a pass. If you need to write eeprom data, write everything in complement duplicate or with a final checksum, then if corrupted do nothing dangerous until getting new parameters from the host.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Mar 06, 2011 9:00 pm

It is great to hear that you setup has been reliable. So many BMS type systems have problems.

Yes, I would rather avoid the brownout protection power consumption too. For the benefit of others reading this thread, if there is any flash/eeprom writing code there is always a chance it will get executed randomly during brownout (when the supply voltage gets too low and cpu operation becomes unpredictable), but realistically that doesn't happen very often in this application (only when a cell gets overdischarged or a cable is disconnected or fails). One thing I sometimes do is perform the calibration with one program, and then replace it with a second operational program that has no capability of writing eeprom/flash (only reading it), so random execution cannot cause writes with this operational code. The brownout protection draws quite a bit more current than the sleeping processor so in ultra low power operation it is desirable to avoid it. Using some form of verification on retrieval and transmission is also good design and can make these systems more reliable and self-diagnostic. For example if some nodes don't check in then the master can assume that the corresponding cell is dead and take appropriate action. Watchdog timers are good on the master, the slaves don't need them, but if the master has a problem and gets stuck the watchdog causes a reboot automatically. Reboots on these micros take very little time, so the user might not even notice when it occurs. It can make the micro work well even with a few bugs.

I have a parts list, and most of the parts selected. Still need to review some design details and start on a pc board layout. I could build a prototype, but that would consume time that I'd rather put toward a first article pc board layout. Even if it is less than perfect, it is quicker than doing a prototype followed by a pc board. I need enough of these boards for several packs, I would definitely not want to prototype that many circuits. A six cell board will have about 80 parts on it. With surface mount you can solder them all at once with hot air. The parts are smaller and more rugged and cheaper. I have tools for small quantity surface mount work which I don't use often, so this is a good thing to do with it.

texaspyro
1 MW
1 MW
Posts: 1519
Joined: May 12, 2010 6:53 pm

Re: Battery Data Acquisition and Charge Control System

Post by texaspyro » Mar 07, 2011 8:29 am

Great! I was looking at an old datasheet that did not have the Vbg mux selection listed...

It's a very good idea to not use page 0 in the EEPROM. It tends to get corrupted the most. After any EEPROM access, I read location 0 to keep the EEPROM address pointer at the sacrificial page.

One of the modes in my LED driver supports a push button to cycle through a table of intensity values. It also supports using a pot to control intensity. You can use both at the same time. The state of the button table index and the pot setting can be kept in EEPROM (for the version that does not keep the CPU continuously powered).

They spec 100,00 write cycles (testing shows at least 5 million cycles is typical). The LED driver code can do EEPROM wearout protection. Every write is read back. If there is a mismatch it bumps an index pointer to use the next page. There is lots of debate whether a write to a single location in EEPROM writes all locations in the page (via a read-modify-write cycle). Best to assume it does.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Sep 08, 2013 11:46 am

Found my old thread here. Have been thinking about this subject again lately.

Lots of good ideas here, may evolve this a bit and build one for the Greyborg.

User avatar
Alan B
100 GW
100 GW
Posts: 7022
Joined: Sep 11, 2010 7:43 am
Location: San Francisco Bay Area, USA
Contact:

Re: Battery Data Acquisition and Charge Control System

Post by Alan B » Sep 08, 2013 11:22 pm

One suggestion above was to use the internal pullup as half of the resistive divider to prepare the battery voltage for the ADC, but I see the internal pullups range from 20K to 50K on the datasheet. Perhaps in silicon they are more consistent, but that is quite a range, so not sure that is a great way to design just to save the cost of one resistor. I'll put the resistor on the pc board layout, and perhaps we can try it by leaving the resistor off, but if needed it will be easy enough to put it on.

My 2013 revised design has a number of changes over the 2011 version. There are four balancing load resistors for about 150mA balance current, all driven from the micro directly. The opto arrangement is slightly different which saves one resistor and lowers the power consumption. It has four semiconductors per cell: the micro, the protection zener, and the two optical isolators. All other parts are passive. Parts cost per cell group is very low, currently estimated under $2.50 at 100 quantity rates not including pc board, shipping, loading, calibration and testing, etc.

I've also been looking at the serial communications setup. The ATtiny44 has a Universal Serial Interface which is not quite a UART but can be used for various serial protocols. I'm looking at ways to use it that make the software simple. It only needs to talk to the master node, no need for it to be a standard protocol. The master node will have a lot more codespace and be much easier to modify code in, so the goal is to make the slave code very simple, and use serial and USB to talk to the master node, perhaps even CANBUS later on. The master node will generate the low voltage cutoff output, battery status display, and control charging and balancing, and possibly do the RFID keyswitch as well. One of my goals is to have an onboard charger and be able to just plug in AC and have it charge safely.

The slave functionality will be basically read the battery voltage, apply the calibration, send the result to the master when requested, and control the balance loads on/off as directed by the master. Otherwise it will power down and go to sleep, and have timeouts and watchdog timers to ensure the slaves don't hang up. Also, some sanity checking code in the slave can prevent it from turning balance loads on at low cell voltages. Checksums will prevent acting on bad data.

The master node I was planning to use, the terminal shown earlier in this thread, has disappeared from my supplier, and possibly been discontinued. So I'll probably look at using a Teensy 2.0 or something similar for that functionality. Arduino code can be used on the Teensy so development is easy, and it has a USB interface so no programmer is needed to load it with code.

The balancing is still fairly gentle, but since I use LED power supplies with adjustable voltage and current regulation, and a microprocessor will control the balancing, it can patiently balance at the top of the charge, cycling the charger off if any cell starts to get too high. This won't work well for bad cells needing lots of balancing every cycle, but it will stay safe, stopping the charging before any cell group gets too high, and leaving some groups low if balance is poor. It will advise the user of the balance condition and keep things safe. If cells are getting out of balance every cycle then the pack probably needs an overhaul, though leaving the charger on will eventually allow it to balance them unless leakage is similar to the balance currents. My packs stay balanced well with no balancing, so it won't take much to keep them aligned.

Current estimates show about a 5 hz scan rate for a 24S pack. This will occur during charge and discharge, and shut down at other times. Idle current will be very low when shut down, so this won't be a danger to the battery pack.

Njay
10 kW
10 kW
Posts: 871
Joined: Sep 09, 2010 10:43 am
Location: Portugal

Re: Battery Data Acquisition and Charge Control System

Post by Njay » Sep 09, 2013 10:50 am

Have you looked at revolt's bms?

Post Reply