DIY open source lithium BMS (battery management system)

[Daox]

Thanks a lot for taking the time to look through this thingstodo! I appreciate it very much.

My code that is in the first post is quite dated. I have updated a fair amount of things from testing different portions of the code. However, I haven't put it all back together yet, thus I haven't reposted it.

I'm very glad you brought up the limitations of the float variable as it may be an issue. This is the latest code for the interrupt that I have been using. RawCurrentRead, CurrentRead, and AHused are all float type variables.

// interrupt to count amp hours used
ISR(TIMER1_COMPA_vect)
{
    // read sensor output
    RawCurrentRead = analogRead(CurrentPin);
    
    // calibrate sensor
    CurrentSensorCalib = analogRead(CurrentSensorCalibPin);
    
    // Convert currentread to amps
    CurrentRead = (RawCurrentRead - CurrentSensorCalib) * .78125;
    
    // Convert to AH used and add to total
    AHused = AHused + (CurrentRead * 0.0000002777);
}

I have yet to hook the arduino up to a more noise proof power source. I was going to do this but I am depending on the arduino's serial output to get feedback on the variables. I'm not sure how to connect the arduino to the computer without using the USB to power it. This is where a scope would come in quite handy.


Thanks for finding those chips! I'll have to take a look at them once I get the BMS in the car and running things properly.

[thingstodo]

Originally Posted by Daox

Thanks a lot for taking the time to look through this thingstodo! I appreciate it very much.

I'm on holidays - this is the kind of thing that I enjoy.

Since your CurrentRead can now be somewhere between 511 and 1023, 1023 - 0 (potentially worst case) = 1023 * 0.78125 *.0000002777 gives 0.000221943046875 so I've changed the 0.4 rollover to 0.0003.
I chose a single digit of precision to maximize the total A-h you are calculating.

After you get your code updated, you may want to re-run one or two tests and see if your AHused is still tracking.

This

    // Convert currentread to amps
    CurrentRead = (RawCurrentRead - CurrentSensorCalib) * .78125;
    
    // Convert to AH used and add to total
    AHused = AHused + (CurrentRead * 0.0000002777);

would become something like this

    // Convert currentread to amps
    CurrentRead = (RawCurrentRead - CurrentSensorCalib) * .78125;
    
   // Convert to AH & add to low portion of total
   AHusedLow = AHusedLow + (CurrentRead * 0.0000002777);

   // Update AHused
   if (AHusedLow > 0.0003) {
       AHused = AHused + 0.0003;
       AHusedLow = AHusedLow - 0.0003;
   }

This is the simplest and fastest code change - I hesitate to put too much extra code in the ISR.

With 6 digits of precision, adding .0003 would give you good accuracy up to 99.9999 A-h for sure. Likely a bit higher but I've lost a lot of the details on floating point accuracy ... I'd have to re-learn some of that.

[thingstodo]

Originally Posted by Daox

I have yet to hook the arduino up to a more noise proof power source. I was going to do this but I am depending on the arduino's serial output to get feedback on the variables. I'm not sure how to connect the arduino to the computer without using the USB to power it. This is where a scope would come in quite handy.

I sometimes find it difficult to get a scope to trigger on a small change in the measured signal. You are not expecting a periodic signal that can be triggered 10 or 100 times a second to give you a nice stable display, so how are you going to 'capture' the 15 mV change?

I thought that an externally-powered USB hub would still allow you to plug your computer and the Arduino both in - but my computer tells me that the com port is not found. I guess you already knew that!

[thingstodo]

Originally Posted by Daox

Thanks for finding those chips! I'll have to take a look at them once I get the BMS in the car and running things properly.

I was looking for myself - your comment that others have done this and some of the work should be packed into a chip struck a cord. And you were right. It's only fair that I share the info.

I've been looking through the various Battery Management Systems for the past couple of days. The Open source projects I can find seem to use PICs of some sort. A lot of them used quite a few discrete components so they had PCBs fabricated.

Many people seem to find PICs easy to use. I find the code pretty easy to read but have struggled to get anything running in the past. I've had trouble with missing libraries, the wrong version of libraries, with 'examples' that have errors and won't run, with defines for a specific chip that I can't locate so the code does weird stuff, and likely a whole lot of other stuff that I simply have not solved so far .... I must not be bright enough to use a PIC. I need this system to be RELIABLE.

I like the Arduino so far.

I'm not looking for a Management system so much as a Monitoring system. If you monitor each battery in the whole pack you should be able to identify the weakest of the bunch. From there you can deal with it in any way that you like. The key for me is to IDENTIFY it.

I like what you have so far.

*Begin Rant*

The auto-balancing thing scares me a *LOT*. I find that few people know about Failure Mode and Effect Analysis (FMEA). Assuming that parts DO WEAR OUT eventually and designing a system to survive the failure and continue to do safe things in that failure mode seems like an almost-lost art.

It's my family at risk if a Battery Management System fails in some strange way that burns down the garage that my car is in, which is attached to my house. I may be a bit paranoid, but that has worked for me so far.

Heck, installing things backward is pretty common. On most systems, wiring it wrong causes immediate damage to core components - and they recommend throwing it away and ordering a new one. What happened to fuses? And Buffer chips? Having to order another one is a pretty extreme penalty for a simple wiring error, particularly when you are expecting people who don't understand the wiring to paint-by-number it together.

*End Rant*

I am building an experiment platform - SalvageS10 - and it will (at least initially) be running off a mixed bag of batteries. Pretty much anything that I can find and that is cheap. Well, not anything - it has to be safe to bolt onto a moving vehicle. I presently have about 80 old NiCd cells (1.2V each) from an old electrical substation in various states of ill repair (not likely safe to put in a highway vehicle, but OK to use on my yard for testing with some precautions), 4 used deep cycle Lead Acid flooded batteries (12V), an AGM battery (12V), around 40 Panasonic 7.2 Ah Gel-cells from a UPS in pretty bad shape ... and I expect to acquire a couple of large and heavy forktruck batteries that have been traded in for the core refund but *may* still have a couple of hours of running time in them.

So I would like to connect arbitrary batteries of widely differing voltages and chemistries together in any order I like and just monitor the heck out of them. The LTC680x chips allow up to 12 batteries and a total of 60V, so I won't be able to put the batteries in ANY order ... but the chips appear to be pretty flexible.

I would like to have the batteries numbered something like this:

10A1 in the format PPBC

PP -Pack - group of batteries in series. Force 2 digits

B - Battery - one of a series within a Pack, can contain more than one physical battery in parallel - a single Letter gives 26 maximum batteries in a pack

C - Cell - The smallest unit. Not used if there is only 1 battery in parallel. Used if 2 or more are in parallel. Single digit gives 9 maximum cells in parallel to make a battery.

I'd like to start with an Arduino reading a current sensor, like you have, and build from there.

If I can get the Arduino to read a configuration file (CSV file) from an SD card, which labels all of the batteries in all of the packs and specifies minimum, maximum, and alarm voltages ... that should be a good start.

The Arduino would then read all of the information from the LTC6803-2 chips (I will likely have at least 4 of them) and place that information into 4 arrays, I can log that data to csv files on the arduino and alarm when a cell went into alarm and for how long. That gives me history for each battery as long as I track it through whatever location in a pack that I put it. I have a small LCD module that I hope to connect to the Arduino that can give me some information. The alarm values will be guesses to start, but I can use the data to compute averages, show some discharge trends for the batteries and figure out min, max and alarm values (hopefully) pretty quickly.

There is another Arduino that will be connected to the PLC I'm using on SalvageS10 that will be logging speed, tach, amps, pack voltage, motor current, motor voltage, as well as every input and every output. That logging will also be to an SD card as a CSV file. After the test runs I will be loading all of the data together - likely into a spreadsheet - and correlating the timestamps. Weak batteries will be placed in parallel with other weak batteries or simply removed from the packs and replaced with stronger batteries - at least that's the plan.

The LTC680X chips will also measure temperature of the cells, ambient temperature, etc. I'm not interested in thermal management right now but could be in the future.

SOC is an interesting topic. The PLC on SalvageS10 will attempt to count coulombs to determine when it is time to shut down the test and recharge. It will be interesting to compare the coulombs measured by the truck and the coulombs measured by the Arduino.

A mixed set of a specific battery type (Flooded lead acid deep cycle, AGM, Gell cell, NiCd) would not likely work well with series charging of the whole pack since they self-discharge at different rates. Mixing chemistries will make that even more impractical, so I'm not sure how to charge this system. Some experimentation and a lot of manual charging with a maximum timer is likely the ticket initially.

That's where I'd like to be going in the near future. If that fits with your ideas (or at least - MOSTLY fits with your ideas) I can post the information to your thread.

[Daox]

That sounds like a lot of work! But it also sounds like you know what you're doing with the electronics side of things. I'm just bumbling through it working things out as I come across them. I'd love to hear how things progress and glad my project could help you with yours.

[Daox]

I've been talking with one of the local makerspace guys on ways to improve the BMS, but I also started building the BMS for my Prius' PHEV kit. All the components are back in the car and the only thing I'm waiting on now is the BMS.

I started building the 'bms shield' for the arduino yesterday. I'm not making it look super pretty, so I reused the little board (taped up one) that houses the opto-isolators. I had been using it for the charging side protection previously. So, I just wired it to the shield.

I also have to update my schematic a bit more as I went through and missed a few things. I had to add one resistor and remove a different one.

Building the shield is almost done. I still have to add the current sensor stuff, but that is what I have been talking to my friend at the makerspace about. Anyway, the main portion left to do is the 'front of the vehicle' section of the schematic that has the on/on switch and the SOC meter. There aren't many components there, but lots of wires off that 16 pin shift register chip.

Here are the pics so far.

[Daox]

The other night I borrowed an oscilliscope from work and took a shot at troubleshooting this current sensor issue. I found out the 5V going to the sensor varied a bit, but the vref and output from the sensor were pretty solid (+/- 1mV). I put a capacitor on the 5V input to the sensor and it smoothed things out a bit. I also tried running the arduino off of a 12V battery. Each time the 5V input got a little better, but through the whole thing the sensor output was still very steady.

So, now I am wondering why the arudino is reading a voltage fluxuation on the vref and sensor output pins. According to the serial feedback on the arduino, I'm seeing voltages of 2.519V to 2.539V. The scope showed a pretty consistent 2.513V. So, not only is it showing a voltage fluxuation that isn't there, it is also reading an incorrect voltage.

[Daox]

Going back to the current sensor issue. I heard that the open revolt controller is using some filtering on that sensor. So I looked it up and sure enough its there. I'll probably start by just copying what Paul has done. If that doesn't do the trick I'll start tweaking things.

[ericbecky]

Tim,
In place of the $27 SSR in your diagram, I made a snubber circuit using three components. Total cost $6.83.

* Triac S216S02F Sharp Microelectronics | 425-2414-ND | DigiKey S216S02F $6.26
* 47 ohm resistor ULW3-47RJA1 TT Electronics/Welwyn | 985-1009-1-ND | DigiKey ULW3-47RJA1 $0.28
* 0.22µF capacitor B32922C3224M189 EPCOS Inc | 495-4200-2-ND | DigiKey B32922C3224M189 $0.29

And here is a link to my crude drawing of the snubber circuit. http://bit.ly/MO0qXb

[Daox]

Woohoo, great. Thanks for getting me that info Eric. That'll help bring down the cost of the BMS for sure.

Make sure to post the final version of your BMS when you get it all put together. AFAIK you're the only other person building one based off my design.