Battery Maintainer
In late November I started a project to build a Battery Maintainer. Yeah, exciting name. So what it will eventually support is:
- measuring capacity of individual batteries in series string(s)
- charging or discharging said batteries
- balancing the batteries
- monitoring the batteries, including the pack's SoC and KWh remaining, etc and estimating same per battery in the pack
- logging to uSDcard
- serial/bluetooth stream to phone/tablet app (like EMW's Android EV Dashboard (some links at http://evdashboard.codeplex.com/workitem/19313 , which is a forum for a WindowsCE/Mobile equivalent
and/or
- alternative display/control via serial/bluetooth, which could be a PC of some form.
It is Prop-based, and I've been prototyping the hardware. It is modeled after Lee Hart's Battery Balancer (http://www3.telus.net/nook/balancerland/balancer/rev_b/index.htm), but uses a Prop instead of a Basic Stamp. If you can afford the space for such an item, Lee's version is available off-the-shelf or build-your-own, but you can't fit much in the way of an algorithm into the BS. You can instead use another micro/phone/tablet/whatever to control it as a slave if you tweak up the code, and implement the smart algorithms in the external controller. Just occurred to me, maybe with IFFT... okay getting off the tangent...
My first electronics project in a long time, covering the gamut from parts selection, to soldering, to code, and eventually a specialized android app (unless EV Dashboard proves sufficient).
I'll be using it to maintain the strings of 12v blocks in my GE Elec-trak, an Ariens Amp24, and a Greenworks 20" 24v battery electric pushmower. And whatever else. I'm making this prototype to fit into the 'stock' space within the Amp24 in the Winter, but in Summer it will move over to the Elec-trak, and be cabled into the other 'Summer' items as necessary.
As always, the manufacturers of these 'tools' tend to provide chargers that murder batteries rather than maximize their lifetime. My implementation will support up to 30A of boost charging (effectively replacing the current that a weak battery may be asked to provide).
More details to follow, including possible obex object submissions.
- measuring capacity of individual batteries in series string(s)
- charging or discharging said batteries
- balancing the batteries
- monitoring the batteries, including the pack's SoC and KWh remaining, etc and estimating same per battery in the pack
- logging to uSDcard
- serial/bluetooth stream to phone/tablet app (like EMW's Android EV Dashboard (some links at http://evdashboard.codeplex.com/workitem/19313 , which is a forum for a WindowsCE/Mobile equivalent
and/or
- alternative display/control via serial/bluetooth, which could be a PC of some form.
It is Prop-based, and I've been prototyping the hardware. It is modeled after Lee Hart's Battery Balancer (http://www3.telus.net/nook/balancerland/balancer/rev_b/index.htm), but uses a Prop instead of a Basic Stamp. If you can afford the space for such an item, Lee's version is available off-the-shelf or build-your-own, but you can't fit much in the way of an algorithm into the BS. You can instead use another micro/phone/tablet/whatever to control it as a slave if you tweak up the code, and implement the smart algorithms in the external controller. Just occurred to me, maybe with IFFT... okay getting off the tangent...
My first electronics project in a long time, covering the gamut from parts selection, to soldering, to code, and eventually a specialized android app (unless EV Dashboard proves sufficient).
I'll be using it to maintain the strings of 12v blocks in my GE Elec-trak, an Ariens Amp24, and a Greenworks 20" 24v battery electric pushmower. And whatever else. I'm making this prototype to fit into the 'stock' space within the Amp24 in the Winter, but in Summer it will move over to the Elec-trak, and be cabled into the other 'Summer' items as necessary.
As always, the manufacturers of these 'tools' tend to provide chargers that murder batteries rather than maximize their lifetime. My implementation will support up to 30A of boost charging (effectively replacing the current that a weak battery may be asked to provide).
More details to follow, including possible obex object submissions.
Comments
If there is sufficient interest, I can submit it to the obex.
It uses Tracy's FDS4port http://obex.parallax.com/objects/856/, but could be changed over to any other as desired.
Incidentally, I switched to Tracy's object after having some trouble with some other serial objects; I'm currently using 2 ports at once with FDS4port; 1 port to Parallax's PST @ 115.2K, and the other at 38400 through a bluetooth/breakout/antenna board (good up to ~25 feet). On others when running the BT just at 9600, the PST port wouldn't run reliably @ 115.2, but would at half that (57600).
HW overview
- connects a common 'bus' (wire pair) to a single module of the set of batteries
-- via relays, (I chose 30A units, but the controller doesn't care what capacity, size, style, etc of relay is used), off-board
--- relays driven by a ULN2803
-- via other relays, to loads and chargers, all off-board
- uses a MCP3208 for current and temp measurement, up to 8 inputs.
-- 'currently' uses the Pololu current sensors, off-board
- has a BT/serial dongle, currently use either SENA BTerm or EMW Display with it, off-board
- has a V/F converter for voltage sampling
- SDcard for logging
- Parallax Prop (used the 1st rev proto board)
I would probably make some different choices on a 2nd iteration. Probably build off Peter or Cluso's architecture, my application requires 'smaller', and modular is nice.
SW overview
- SPIN/Pasm, been using Prop Tool, but just ran into the "Object exceeds 32k" design flaw
-- http://forums.parallax.com/showthread.php/122185-Object-exceeds-32k
-- above thread will detail what direction I take
-- moving more detail code into objects and creating a serial 'wrapper' put me into the 32k bug
- MCP3208 object
- Serial, Tracy's FullDuplexSerial4port (856)
- Wrote a composite serial port object, a VT100 support object, and a PST support object, and a wrapper that allows be to switch all of my code over between the available options (one line change). The composite allows duplicate Output to two+ ports at once, which can be a mix of VT100 (SENA BTerm) and PST for example, and can accept input from either
- 'command line' serial process that can be used from SENA or PST.
- Wrote a 'driver' for the EMW EVDash, outputs a compatible serial stream from my data structure
- SD card logging using SD-MMC_FATEngine, logs periodically from same data structure
- rewrote "Stack Length" to eliminate serial, moved the VARs into the stack in a header, including a linked list
- wrote a cog utility object, which also supports serial output of the current cogs and stacks in-use + status
- calibrated V and misc inputs objects, in-progress
-- test code objects for exercising them
- higher level code is in-progress as well, but started bumping into the 32k bug, after some refactoring
- a 'text-based display' object, outputs from my data structure
- wrote a 'text' display simulation of a 8x8 LED array, to see if I like the format I had in mind for conveying relative V or charge of batteries
- there is more, but this is enough for one post.
So far I have used the project to take data from a serial string of batteries while discharging in a mower, and charging via the 'stock' charger and 'balancer' charger. My next test will be a discharge and recharge logging test in the electric snowblower. I just have to plug the harness in, it currently uses WeatherPack connectors. The quantity of batteries (B1,B2,...) varies by application, my current build supports up to 8.
Sample logged data, showing V rising at the beginning of a charge. KWh isn't plumbed in yet. A(mps) is in tenths, B1...Bn is voltage in hundredths. Counter is based on the ~54-second prop clock, incrementing the 4th digit at clock rollover, and the first three are milli-54-second units. No RTC at the moment, so this is the timestamp. A work still in progress, but functional.
counter,B1,B2,Bsel,A,Blow,Bavg,Bhi,KWhFull,KWhNow
...
1878,1285,1295,1,43,1285,1290,1295,0,0
2022,1288,1298,2,43,1288,1293,1298,0,0
2094,1288,1300,1,43,1288,1294,1300,0,0
2184,1290,1300,2,42,1290,1295,1300,0,0
2310,1290,1301,1,43,1290,1295,1301,0,0
I've come to wish for the ability for a an object to expose a subset of a contained object's interface, rather than have to duplicate the desired interface. And I have to remind myself to check for inadvertent use of >= when I meant =>.
The display looks like (below) presently, also a work in progress. Upper left is the 8x8 text display, upper right is a listing of cogs available, cogs in use, and stack objects created (this includes a test output). simulated-RTC in the center (2.022). The center area is 'text scope' with a 54 second period, showing when relays are turned off (v) or on (^) and when, and when samples (s) are taken. The bottom is a scrolling message area showing sample readings, with A/D counts in parens. I can view this on either SENA via BT or on PST. I can control it via serial commands from either as well. The 8x8 shows 4 batteries, the first one is a bit higher in V than the other 3 (by 0.01V). Imagine lit LEDs where the '*' are. Above it are the max and min V samples (simulated 4-digit led displays).
More functional than pretty. Got tired of trying to read through intermixed lines of output from various stuff when integrating and testing at the high level.
You need to use code tags to preserve spacing.
[c0de]
Text with spacing to preserve.
[/c0de]
Except use an "O" instead of a zero in the word "code".
I don't have need of the "EV Display" protocol myself right now, but I hope you post the object you made in case I or others need it in the future.
Very cool project. Thanks for posting it.