A PIC based Battery Management System

[dak664]

What with the rain and new packs slowly balancing I was going to start on a single-cell ATtiny85 shunt regulator tomorrow! One per cell would reduce short potential and make programming easier. The spec sheet says it can sink 60 ma continuous, so just the chip and a resistor might be all that is needed. I was thinking of an obligatory LED to indicate bypassing, and at other times maybe flash the voltage as e.g. 4 long two short=3.42 volts. They are $1.73 each right now, not the cheapest (a 75 cent MCU would do the job) but I have a couple dozen on hand, 8 pin dips.

There may be some hacks to get wireless communication without added components, e.g. emulate an RFID tag, another possibility is infrared to a master MCU inside the battery case.

 

[dozentrio]

Alright. An ATtiny per cell comes out cheaper than using expensive high voltage parts. 20 cells x $1.06 per chip = ~$21

Why not use the SPI port for communication though?

I am prepared to order 25 of these and a suitable master chip, and join the effort.

In general though, is this the plan?

LVC: Monitor each cell for voltage, if it is below limit, disconnect the battery (how exactly is this done?)
Balancing: If the voltage of a cell differs from the neighbouring cell switch on a FET to supply current from the cell in question to the neighbouring cell?
Charging: If the voltage is above limit (4.2 or so) then stop charging that cell.
Extras: Monitor current drawn from battery by sensing a voltage drop ... somewhere? (how exactly would this be done?)
Extras: Count "equivalent battery cycles"
Extras: LCD to display pack voltage, individual cell voltages
Extras: Serial port for diagnostics, pack information, etc

Is it possible to use some kind of "power multiplexer" and a capacitor to distribute charge between cells? Use two multiplexers and switch the legs of the capacitor so they are across the cell you are taking charge from, and then switch it to the cell you want to supply charge to?

I can help with the programming, but I'm afraid electrics/electronics is not my forte

 

[dak664]

Great!

No need to buy anything at this point, download AVR Studio and you can simulate the program. I have a rough draft but am looking for a better simulator that will allow varying the voltage and monitoring the LED(s) and shunts in real time. VMLAB would seem to be the best but the free version supports only the similar but obsolete ATTiny15 and I can't get it to work with the '85 hex file. Don't want to spend $5K to see if the commercial version works any better

Without any other components all a single MCU could do is introduce a small ~60 ma shunt to alleviate overvoltage during charging. Undervoltage could turn on an LED to signal a master MCU to use hefty FETs to shutdown the pack. Any direct connections among MCUs would have voltage breakdown issues; a magnetic coupling on a single toroid might work cheaply but would be rather time consuming to fabricate. The common toroid could possibly pass excess current to other cells but cost would be an issue.

An interesting possibility is that an LED can be both a transmitter and receiver, so possibly a protocol could be set up to eliminate message collisions inside the pack. Similar to how Atmel's QTouch technology works through the miniscule changes of voltage on an input pin from the capacitive effects of touching a pad.

 

[fechter]

There are several possible overall topologies that could work.

For me, I would want the processor to drive a transistor that activates a shunt resistor for higher current. Since processors are kinda binary output, I think a PWM function would be needed to vary the shunt current. So when the cell voltage gets up to the upper limit, the PWM starts out at a low value, like 10%. On the next measurement cycle, if the voltage is above the set point, increment the PWM duty cycle. If the voltage is below set point, decrement duty cycle.

Once the duty cycle reaches, say 90%, send an output to decrease the charger current. This way the charging current can stay as high as possible.

A simpler approach would be to have the shunt either on or off, with no PWM. Whenver the cell voltage goes over set point, shunt turns on. When it's below, shunt turns off. When any shunt is on, the charger current must be dropped to a value slightly less than the shunt current to prevent overvoltage. This will work, but the balancing time will be somewhat longer.

 

[dak664]

The program I am cutting and pasting from uses PWM so I will leave that in on a conditional. The '85 is way overkill, it can bitbang USB when clocked at 16 MHz. Probably 1 MHz would be adequate for this application

Anyone have any experience in setting up a sourceforge project? I could give it a try once it has a good name. Sourceforge also has a new idea-development application that could be useful.

 

[fechter]

Never heard of sourceforge. What's that?

What about an ATTiny 13? is that enough?

In the overall system, the signals from the cell processors could be like my analog system, where the main control circuit is just basically a switch with no processor and all the 'smarts' are in the cell circuits.

In a more advanced system, a central processor could possibly get voltage and shunt current data from the cell circuits. It would be even better if the central unit could detect a communication failure of any cell circuit. In actual practice, the cell circuits will be connected by some kind of wires that will have a possibility of failure, which would be bad.
Optocouplers are OK for isolating the communications lines, but there may be other methods. Since the cell voltages could spike badly during vehicle operation, this has to be accounted for.

The final output, other than a display, would be to interface the LVC and Charge control. In most systems, the LVC can be an open drain or open collector that pulls to ground when you hit LVC. This can kill the controller output, or simply activate an audio alarm.

The charge control output would be something that drives the emitter in an optocoupler for direct charger interface, or the same FET switch setup I use on my analog system.

 

[dak664]

Never heard of sourceforge. What's that?

http://sourceforge.net/about
The main use is SVN (subversion) hosting of source code, where all releases have a detailed audit history and changes made by project members are easily reverted. Other uses are project website hosting, mailing lists, wikis. Accounts and project hosting are free. I am a member of the contiki project which you can browse as an example.

I just saw that someone set up an open source battery management project last month!
http://ocbms.sourceforge.net/
but all that is there is an empty folder.

Here is my ideatorrent app to play with:
http://sourceforge.net/userapps/ideatorrent/dak664/

What about an ATTiny 13? is that enough?

Probably, with fancy led flashing the code is ~500 bytes. The '13 has two PWM channels but no temp sensor. The '85 has one PWM and a temp sensor. Both have 10 bit DACs and 20MHz clock max.

I was thinking mount the circuits on a plastic strip acting as a light pipe with led's stuck into depressions. Then set up an protocol for orderly reporting once a second or so. That would be much like the ipv6 autoconfiguration I have been working with for wireless motes.

 

[dak664]

Whew, I just read this entire thread!

I conclude that linear forums like this are not effective for discussion of a complicated project. Each contributor obviously has motivation and expertise in one or another aspect of the problem but suggestions that are not immediately relevant to other contributors tend to get ignored to the eventual alienation of many. The NASA model from the 60s seems better, have some experienced and very smart people break a project into subtasks which can be creatively solved by focus groups working more or less in isolation. Maybe the ideatorrent software can accomplish the same thing without the smart overseers, it might let the subtasks naturally form. We could give it a try.

It seems very few had the expertise and equipment needed to actually make something; the ones that did were hit with noise problems. My background in instrumentation and control on 30MV Van de Graafs and 30MW klystrons suggests you combat noise by using high power sensors, not really a problem for battery drain as the MCU would sleep at <1 microamp, waking via a watchdog timer maybe once a second to measure voltage and send the reading to the main MCU if it changes. Once noise is overcome token rings are reliable but require all MCUs to be awake, which conflicts with the low power requirement in a way similar to that of wireless networks running on batteries. So paradoxically a high power common bus would seem to be the lowest power method of communication. This could be optical, magnetic, RF, or capacitive. How many cells per MCU is not a pressing issue; I'd start with one to get things working and add more if it proved cost effective. Master MCU programming and display is a fairly well-separated task that could be done in parallel. If I was project manager I'd get that going first to attract money and talent for the rest of the project.

Memorable quote from the thread :

I'm going to re-structure my code today to see if I can't get it to fail in a desirable manner.

 

[fechter]

Yes, the forum is not the best way to solve a complex problem, but it's what we have.
Money would be nice. That's the thing stopping me the most.
Correct that everyone has a different approach and in many cases, a different objective.

I love the idea of doing a single cell unit first to work out the bugs. I have plenty of exprience with the analog parts and the overall topology. I need help with code. I did find I have a copy of AVR Studio that came with my AVRISP. I didn't realize I can use that to simulate the code.

Capacitive coupled communication may work if the frequency is high enough so the capacitors can be very small. The relative voltage on the pack could see some serious transients during operation, so noise could be an issue. Optical coupling is a bit more expensive, but pretty bulletproof in this kind of environment. Transformers could work too, but tend to be expensive.

 

[mwkeefer]

I hope fechter was being sarcastic with the "what is sourceforge"? I am going to just assume that you were man = )

Once we decide upon a hardware platform to work upon and a design strategy, creating a sourceforge project and using them to host our CAD/CAM/Gerbers/Schematics and tracking revision history using CSV or SVN is smart... but we need to get to the stage of deciding as a collective what designs we are going to entertain and which we are tossing out.

Collabarative development is somthing I have been doing (open and closed source) for the better part of the past 15 years (longer actually)... software, hardware, desktop, web based, microcontroller, etc... doesn't matter I have been doing exactly this (as I am sure many of us have) and we do need to determine direction before creating a project else we will have that horrible empty project syndrome that effects so many open source projects started on a whim.

fechter;

You are correct about the transmission lines... if my memory serves me correctly I solved this problem long ago on i2c bus by simply writing a keep-alive routine into the master controller so it would poll for specific and calculated response once each few seconds from each of it's slaves. Any failed respose indicated a communications failure, if the checksum (mod 10 I think, may have been CRC16) was off = failed/corrupted communications.

Do you think that level of error detection is sufficient or do we need to step it up a notch and actually piggy back some other communications protocol with error detection built in (ie: lightweight TCP over 2 wire?)... this wouldn't be too difficult and really we will have serial communications bus (I assume) either rs2322, i2c usb, etc...

What are your feelings on this...

In regards to isolation:

Tear open a BM6 from HobbyKing, I have 5 of these right now (should be 6) connected to 5 of my 6 partial packs in discharge mode (serial as 15S2P). These suckers are spot on (the 5 that worked out of the box, waiting for replacement of #6 whch was sort of DOA) and activate a piezo transducer for alarm. @ 12.00 ea US thats a bit much for our uses but... they are isolated (must be or I would be shorting everything out ... and no KFF (Kentucky Fried Finger) this week - so far)

They are based on a simple Atmel MCU but other than interfacing to each piezo element as a trigger for a 6 pack monitor LED display and throttle interrupt line usning some transistors and 10K resistors I had laying around I havent had the time to reverse engineer them looking for alternate triggers... changes to the code, method of isolation, etc.

I will tear my disfunctional BM6 apart and take tight pictures of the PCBs and post if anyone wants them (maybe I should start another thread for this)... once I actually draw a schematic and PCB for my interface board I will post it but right now it's electrical tape and perfboard from the hip... but it works wonderfully and where I am located we have massive cricket action right now which kept me from hearing the alarm on the BM6 one night recently. WIth the LED display and throttle interrupt you don't have the problem but you are rght about the connections from the battery balance taps -> the BM6 and then from the BM6 to my interface board. No method of monitoring that each is functional (NOOP) command.

In case you werent being sarcastic about sourceforge - NOOP = No Otherwise Obvious Purpose and is a command worked into many of the client protocols that make the web work for the purpose of keep-alive, communications checking... etc at the program layer of the TCP stack.

We could do the same similar thing by hooking into the 5v line of the LCD display and when its not +5v assume the BM6 is failed (or the slave unit we design, whatever) - When my cables come loose the BM6 goes off and the LED turns off the low voltage supply regulator turns off and the +5v rail dissappears. Just a thought, would be easier than inventing some NOOP and protocol to support it.

-Mike

 

[mwkeefer]

fechter and dak664,

Please accept my humble appology if my previous post came off wrong... I just re-read your entire postings to date and see where I may have mis-construed some things.

I suppose that we are at the point (nearly) of creating a source forge project... I just didn't think there was enough talent / experience / desire to do this for real (without laying all the heavy lifting at fechter's feet) in a community manor but between you both, myself and all the others in this thread with MCU and electronics experience... we have a chance = )

Further to that point... I have some $$$, equipment and time for R&D at work after pitching and succeeding at redirecting our focus from LiFePo4 for our final commercial product to LiPo... the R&D has already yeilded a CC/CV charger (laptop style) for LiPo 12s and 15s packs (the first wave of chargers will be 5A and 10A, next wave we will up to 20A output) and will deliver to the users of ES (I already cleared this with the boss) a brick style CC/CV charger for their 12 or 15S lipo packs at a shade over cost once s&h are factored into the equation.

Anything I can offer to further the BMS project ... just say the word. I have been trying to center a design around commonly available or/and low cost parts - the arduino mega was a quick and dirty way to get the master controller running without farting around (alot of libraries of code exist already for arduino mega platform, allowing much re-use) with sourcing and such. If we were to follow this design method, converting to final product would be simple as using Atmega1280 and just pin to pin duplicating the required parts of the arduino system. Now we can rapidly prototype (ugly and large as it may be) and then once we have working HW/SW for master slave... we just move the circuit(s) to their own PCBs and continue using the arduino base libraries.

Again, this is just IMHO... and my preference is to lean towards tech that users here can easily obtain and assemble. If we base this thing in Arduino MEGA and MINI (for slaves) then anyone with very little knowledge or skill will be able to use our BMS software with Arduino building blocks and our wiring details. End result is a BMS with high degree of accuracy, safety and parts availability for the average user.

One final thought...

The master MCU and slave unit MCUs should be surface mount types for space considerations but... desoldering for repair is a PITA so I suggest we implement a design with a retaining plastic bar that screws down on either side of the MCU holding it firmly in place, similar to what a PLCC or DIP socket may have been in yester year... and boy how I miss those days!.

This works excellent with a small piece of FOAM or Neoprene between the MCU and the retaining bar/clamp (think watch battery retainer). Once in place, they will NOT MOVE ABOUT... I HAVE SMASHED PCBS trying to get them to move without success.

This is a trick I figured out long ago so a MCU which suffers an ESD and gets fried or in our case a breakdown of current isolation or a short circuit of some kind) can be replaced easily without desoldering (which nearly always ends up with a lifted trace and jumpers to repair) which enables "average joe" to affect the repairs needed.

We would also need to implement a JTAG connector of some sort for loading of the MCU units (Master and Slave), I can help alot here as I have written more bit banging GUI applications to SPI load atmels than I care to admid, I have code for them in VB.NET, VB6 and C# and the code exists openly in Java for all platforms.

Since we are already using an MCU for the BMS (that much it seems has been decided by the collective) should we not include the ability to monitor discharges (discharge counter) for teh pack the BMS is assigned to... not to mention the other possible off shoots and features to consider... hall style current sensor on pack level to measure current the pack has provided and keep log for tally in addition to cycle counter. Make it even more expensive (and detailed) and record the discharge and charge records for each cell / pack, etc.

This would be very useful stuff to have for analyzing issues with EV/EBike and the pack they are using (well actually would be usefull in nearly any application except maybe a flashlight).

Just a few more random ideas I felt compelled to share with the world = )

-Mike

 

[mwkeefer]

**** I AM OFFICIALLY AN IDIOT *****

Found the issue with my "broken" BM6 - BM6 is fine, my damn 2x3S -> 6S wiring was FRACKED!!! I pulled a newbie stunt and clipped the "spare lead" instead of paralleling it with the next (ie: connect cell balance wires #3 GND to #4 + as they should be).

That will teach me to build packs and adapters in the middle of the night... NOT!

- Mike

 

[fechter]

You are correct about the transmission lines... if my memory serves me correctly I solved this problem long ago on i2c bus by simply writing a keep-alive routine into the master controller so it would poll for specific and calculated response once each few seconds from each of it's slaves. Any failed respose indicated a communications failure, if the checksum (mod 10 I think, may have been CRC16) was off = failed/corrupted communications.

Do you think that level of error detection is sufficient or do we need to step it up a notch and actually piggy back some other communications protocol with error detection built in (ie: lightweight TCP over 2 wire?)... this wouldn't be too difficult and really we will have serial communications bus (I assume) either rs2322, i2c usb, etc...
-Mike

I guess one of the first decisions is what kind of communication to use. Other systems I've seen use CAN, but I2C may also be adequate. This is one of my weak areas as far as hardware goes. Not exactly sure what it takes. I don't think the error correction needs to be very sophisitcated. It just needs to detect when a cell circuit is no longer connected.

One really nice feature will be the ability to program the voltage set points, both charging and discharging. This will make it possible to program for Lipo, LiMn or LiFeP04, or whatever they come out with next year.

If programming of all the cell circuits could be done through the master processor (if there is one), it would be a nice feature. I am OK with individually programming the cell circuits to keep things simple, however. The programming of the votlage set points really only needs to be done once, and you need to load the code onto the cell processors anyway. I'm extremely clueless on how to make a GUI for programming the cell circuits.

 

[dak664]

Well, I've got something working with an ATTiny85.

Short video at http://dakx.com/headway/ATTiny85_Headwayshunt_try1.mpg
AVRStudio project at http://dakx.com/headway/AVRStudio_Headwayshunt.zip

Some hardware comments are in the c file. Comparing battery voltage to internal 1.1 volt reference, with two internal pullups in parallel and an external ~5.6K resistor to ground. The advantage of internal pullups is they can be tristated while sleeping. However the sleep current is 200 ua, way too much. May be a bad cap I scrounged from an old computer motherboard, or a bug in the program. Oops, it just occurred to me I left the brownout fuse enabled, that is 50ua right there.

Flashing the LED takes 10ma, and it has a duty cycle around 25%. That's too much battery drain, and the flashing is kind of annoying after a while anyway. Probably would be better to just flash the tenths of a volt once every 5 seconds or so, and that would reduce the duty cycle to ~5%. Of course, it does no flashing if the cell is <3 volts.

Gotta package it better so I can go for a ride and see how it behaves with a motor.

 

[mwkeefer]

Cool.. I gotcha, so once per second keep alive requests between the host (primary) and slave units (bms interface to cells) would be simple to implement (no matter what communication protocol we use) in software. Another option is to just pull a line from each slave that goes +5v when alive, gather them through a latching transistor trigger so that if any of them fall off it will pull a line low on the A2D of the host (host / master not slaves) to indicate a failure. This would be much faster as we can use an Interrupt in the Master MCU to react to this EVENT however... we loose the ability for cell level or BMS slave level resolution using a single interrupt and a "gathering method" which uses a transistor as a trigger.

That's all uber simple stuff to work out, the question is resolution and diagnostic ablility from the main MCU...

GUI - I can do this for us, and you are right about individual loading being a PITA but... when first mounting the master and slave MCUs we will need them to be loaded to communicate via whatever bus we settle on (I suggest i2c becuase it's implemented in AVR and PIC platforms on a wide variety of size and speed MCUs but also available and standard for eeprom interface and in some cases MUX standardized - if we go back down that path). Once the initial programming is completed (the programmer is as you know nothing more than 4-5 resistors and a DB25 off the parallel port to the ISP interface of each MCU) although if you connected the devices together first I could use the main MCU as an i2c interface to address the remaining chips and program them.

No matter what if we implement i2c between the master controller and slaves (I am envisioning 2 seperate black boxes, one we interface to the cells and temp sensors and then the master controller mounted elsewhere) or any other multi addressable protocol then we can set the voltage (HVC, LVC) and the temps sensors from the master and push the updates to the slave interfaces.

That brings a new design issue: Do we give the primary MCU a user interface at the HW level for adjustment or do we use a PC and cable ? There are obvious advantages to both arguments / methods. I would suggest a hybrid approach where we have a full PC based GUI capable of interpreting logs, changing any and all cell cutouts (on a cell by cell resolution basis), etc. Also we should have atleast somthing simliar to the Cycle Analyst from a user interface perspective (perhaps the entire master module lives in the display box) with user feedback and perhaps 2 button interface to switch between screens and enter a programming mode so users can program changes without a PC.

I would go further and suggest:

Since we can use eeprom memory if needed, we should allow the user to store "profilles" such as a good balancing charger does, these profiles could be created on the PC GUI side and named. Then the user could select profiles from the Cycle Analyst style UI box. This approach keeps evertyone happy and keeps the MCU code for UI and user input simple.

Again, these are just suggestions.

-Mike

 

[dak664]

Cool.. I gotcha, so once per second keep alive requests between the host (primary) and slave units (bms interface to cells) would be simple to implement (no matter what communication protocol we use) in software. Another option is to just pull a line from each slave that goes +5v when alive, gather them through a latching transistor trigger so that if any of them fall off it will pull a line low on the A2D of the host (host / master not slaves) to indicate a failure. This would be much faster as we can use an Interrupt in the Master MCU to react to this EVENT however... we loose the ability for cell level or BMS slave level resolution using a single interrupt and a "gathering method" which uses a transistor as a trigger.

I'd go for event driven communication; if the cell voltage hasn't changed don't use the power to clutter the channel with traffic. Maybe once a minute do a short keepalive message.

GUI - I can do this for us, and you are right about individual loading being a PITA but... when first mounting the master and slave MCUs we will need them to be loaded to communicate via whatever bus we settle on (I suggest i2c becuase it's implemented in AVR and PIC platforms on a wide variety of size and speed MCUs but also available and standard for eeprom interface and in some cases MUX standardized - if we go back down that path). Once the initial programming is completed (the programmer is as you know nothing more than 4-5 resistors and a DB25 off the parallel port to the ISP interface of each MCU) although if you connected the devices together first I could use the main MCU as an i2c interface to address the remaining chips and program them.

I2C for sure, but maybe with an optical path. I will experiment with bidirectional signals using LEDs on a plastic lightpipe.

No matter what if we implement i2c between the master controller and slaves (I am envisioning 2 seperate black boxes, one we interface to the cells and temp sensors and then the master controller mounted elsewhere) or any other multi addressable protocol then we can set the voltage (HVC, LVC) and the temps sensors from the master and push the updates to the slave interfaces.

That brings a new design issue: Do we give the primary MCU a user interface at the HW level for adjustment or do we use a PC and cable ? There are obvious advantages to both arguments / methods. I would suggest a hybrid approach where we have a full PC based GUI capable of interpreting logs, changing any and all cell cutouts (on a cell by cell resolution basis), etc. Also we should have atleast somthing simliar to the Cycle Analyst from a user interface perspective (perhaps the entire master module lives in the display box) with user feedback and perhaps 2 button interface to switch between screens and enter a programming mode so users can program changes without a PC.

Yes, at a minimum keep track of the current and number of cycles. LCD display on the bike could be optional, but not necessary if all you want is logging, an SD or transflash card could do that for transfer to a home computer application. Home computer could also write files on the card that would be used for programming the cell micros. I've used 2gig FAT32 SD cards with an ATMega644p, it takes around 25K of code and 2K of RAM. Leave us not forget GPS logging for the well-heeled.

Since we can use eeprom memory if needed, we should allow the user to store "profilles" such as a good balancing charger does, these profiles could be created on the PC GUI side and named. Then the user could select profiles from the Cycle Analyst style UI box. This approach keeps evertyone happy and keeps the MCU code for UI and user input simple.

I haven't seen a CA in operation, what are these profiles?

 

[fechter]

Great ideas!

Keep in mind that the current consumption of my analog board is around 200uA on standby, so that is an acceptable level for design.

I was thinking of having the cell processors sleep most of the time. If consecutive voltage measurements are nearly the same, it should sleep. If the voltage is changing, then it should stay awake. Even under fairly extreme operating conditions, the cell voltage is not changing that fast. I think the batteries would be plenty safe if the measurements were only 1 per second, or even slower when the pack is in standby. When the shunts are active, then we want the current consuption to be high :wink: so a really bright LED to indicate shunt active would be fine.

I think the onboard display only needs to communicate urgent or frequently needed information. I don't care about individual cell voltages unless one of them is out of whack. If there was a current sensor (more $) then all the features of a CA could be added, and you could have a very accurate SOC indicator (gas gauge).

 

[mwkeefer]

Fechter,

Glad you like the ideas = )

To be perfectly honest, I hadn't even given a second thought to consumption... I just assumed we would wake/sleep the slaves durring use/standby when needed so we would really only be concerned with the power running for the master controller.. that too can "throttle back" it's sample rate when in standby mode (maybe even down clock the CPU to get lower current drain...). I will perform some crude measurements to assess consumption of such a controller in both standby and active use tommorow when my son goes back with his mom.

If 200ua standby is okay then I think anything we come up with will be fine so long as it follows this Master awake at all times, slaves on demand. Makes things a bit more complex in some ways, but mostly in the software/firmware... I would rather hack out the issues in SW than hardware (<$$$).

We most certainly require a pack level current sensor, the question is what type... Do we use a mere shunt or do we go a few $$$ more for a hall based current sensor? My vote is the hall based sensor since it will be more accurate over a wider range of input voltages even though it will cost a few dollars more. The increased range of voltage, the inherint isolation, the better sensitivity across hot and cold weather or operating conditions. Well, you know my vote = )

I have assumed (there I go again) that we would want to implement some form of SOC indication system. Further I just figured we would display pack v, current (real-time when > .5a - peak when idle) and perhaps either mah discharged or a simple fuel guage (0-100%). We might as well include inputs for either motor hall sensor or wheel attached to calculate speed from wheel size. The additional code is minimal, the components are roughly 0 since most ebikes will have hall sensor for speed or included with the motor so a 5-10k ohm resistor inline with a tap to existing hall should be high enough impedance yet still provide signal strong enough to atmel digital input pin.

I guess this is another discussion of scope for this project... Do we want to build this in some User Interface manor similiar to Cycle Analyst (my vote is yes) or just use LEDs of varying color or intensity to provide visual user feedback. Both designs have advantages but ... when were talking about 15-30-90 cells of BMS that's alot of LEDs to drive... seems to me that displaying error conoditions on an LCD would be the way and then just do the CA style display normally (configuratble via PC SW).

The group hasn't really spoken on how this should be designed... I have ideas (as we all do probably) but that's not to say my ideas are any good or original in any way = )

-Mike

 

[mwkeefer]

I nearly forgot...

I would also like to suggest we implement a stdio lib in the master MCU and provide a USB host interface for Mass Storage. This would be so we can plug in a USB keychain drive and have our BMS log to the external drive.

Complications with this are few (I use bitbanging and stdio pins on wireless routers all the time to implement either USB Host or SD Card Interface) but I suppose it could add 5 or so dollars to production cost (for the USB female jack). An alternative would be an SDIO card slot, those are only 2-3$ from most online vendors... I only need 2 resistors and a 0.01uf cap (electrolytic) to interface to either USB or SDIO but now that I write it down on "paper" the idea seems better suited for an SDIO card due to it's size, weight and capacity. Not as rugged as a USB keychain but it will be enclosed within our master controller so who cares right?

What are your thoughts on this? We have all the data already available to us from the various inputs... I can see no reason not to incorporate logging into the design (it's all sw once we have media / flash memory in place)?

I look at it this way...

If we log the data for people, then we can also analyze those logs with our Gui software. Those logs would reveal cells leaning towards bad, thermal or other possible issues. This is similar to the way WebTrends analyzes web server logs to deduct traffic patterns and also a type of analysis software which I have experience writing. If we want to limit to Windows only we use SQL Server 2005 Expresss Edition (free) which makes the job much easier or if we want to stay cross platform we can go with mysql engine or even sqlite3 or other open source db implementation.

Once I have a RDBMS (SQL Server, SQLite3, MySQL) performing analysis and trending is simple work. I say SQL Server would be faster for development but really it wouldn't, I was just thinking of the advanced stored procedure ability and some of the analysis and reporting features... really I could do this all in say an Atmega1280 with some addtl eeprom memory but, why should we crunch more numbers than we should in the MCU when we have PCs anyway.

Before you ask... yes SQLite3 is the DB format of the iPhone, and yes we could add a simple plug to connect our iphones to the MCU (ssh over usb) or even go nutz and add adhoc wifi for wireless control and reprogramming. But then whyh should we add an LCD, we could all use our iPhones as the GUI (yes I could write a small app to do this for the iPhone, I am a registered iPhone app dev)... if we all had iPhones (wouldn't that be nice). LOL

That is my own project down the road - rebuild the GUI to work mobile on WM5-6 and iPhone, but noone really cares about that now = )

-Mike

 

[dak664]

I would also like to suggest we implement a stdio lib in the master MCU and provide a USB host interface for Mass Storage. This would be so we can plug in a USB keychain drive and have our BMS log to the external drive.

Complications with this are few (I use bitbanging and stdio pins on wireless routers all the time to implement either USB Host or SD Card Interface) but I suppose it could add 5 or so dollars to production cost (for the USB female jack). An alternative would be an SDIO card slot, those are only 2-3$ from most online vendors...

The transflash-SD adapters make good sockets, and the gold plating is a joy to solder
Prepackaged with transflash, old ones are often below cost when the "standard" amount of memory increases.
Bit banging is fine indoors, but what happens when the regenerative braking kicks in?
It would appear the direction of USB sticks is to incorporate removeable transflash or SD anyway, so maybe the picky USB2 timings can be left to more benign environments. Someone needs to invent a better method for handling the little buggers, though.

By all means log. Measurement leads to improvement. Personally I know more about Windows than Linux GUI programming.

Can the iPhone act as a peripheral as well, or does it require the cynosural position?

 

[mwkeefer]

I agree that transflash can be had cheaper than the USB variety and is somewhat easier to deal with at higher speeds without interference so... I am also perfectly happy going with microSD which can also be had in large sizes with adapters for very cheap as SDHC memory becomes more promenint.

I have been tooling around with the BM6 trying (with some success) to tap into the LCD display serial IO and analyze it with Atmega1280 A2D by bit banging. I can pick up all the various display data in a cycle and then determine how many cells are being monitored by each BM6, first step to moving forward and monitoring 6-10 of these BM6 units.

The BM6 are fairlly well made and should probably be a good starting point as an example of the per channel slave monitor MCU. We can skip the LCD driver at the slave level.

Since these are based on tiny little SMT atmel atmega mcu which we can source cheaply from any of the online vendors I figued spending a few moments reverse engineering these and an interface to them would be a nice shortcut to a functional multi MCU based BMS... The pack level alarm is fine for a LVC and an HVC, more resolution is required for logging and can be obtained from these BM6 units @ 12.99 ea which was acceptible to me for 6 of them (enough to monitor 2 x 2x6S + 2 2x3S individually). When I ordered I had no clue they were atmel based, or that I could tap the interface ... I just wanted a cheap LVC option that could scale between 12 and 15s easily.

For my purposes, these perform all I need. That said, they don't perform all I WANT, not even close. So even though these are fairly low cost (esp when you have already paralleled the packs at cell level) and need between 2-3 of them to build the slave side of an inexpensive LVC/HVC they are not my preferred solution as we can (even on my own) do better and should.

-Mike

 

[pm_dawn]

Hi !

I have also been looking at this kind of BMS, attiny25v on every cell with a daisychain communication to a master probably atmega based.
It has been discussed here in the swedish EV forum.
http://www.elbil.forum24.se/elbil-about1884-20.html
But no one has yet started to work with it. I'm really interested in this project and would really like to start a open source for it.
I have no tinys yet but I'm thinking of buying a couple to play with.

There is also this guy that has done his own on the same specs.
http://hr-ev.blogspot.com/2009/06/bms-charging-system-works.html?showComment=1250847837310#c5258212788519156250

My object is minimum parts count for the cellboards to reduce the price
and a master with options that can be added (like current sensor for SOC calculation, data logging)

I think that is a decent approach for medium size battery packs (10-60 large cells or something)
It will probably not be suitable for larger batterypacks say 80+cell packs because of the board per cell approach.

Best Regards
/Per Eklund
Sweden

 

[fechter]

There is also this guy that has done his own on the same specs.
http://hr-ev.blogspot.com/2009/06/bms-charging-system-works.html?showComment=1250847837310#c5258212788519156250
/Per Eklund
Sweden

Dang! that looks almost exactly like what I had in mind.

I tried to load up the code posted here AVRStudio project at http://dakx.com/headway/AVRStudio_Headwayshunt.zip into AVR Studio. I can read the code, but I seem to be missing something to actually run it on the simulator. I've never done this, so I need to read some more help files. I'd like to learn how to do all that stuff myself eventually.

To me, the main reason to use MCUs in the first place is to reduce the component count and get the price down. A better feature set is just a fringe benefit.

Just as a learning experience, I may want to try designing a setup that does not use a central processor at all, but simply relies on the cell circuits to behave like my analog system (with a few differences). Of course there would be no cell monitoring other than a LED on the cell circuit, but most of the time we don't really care about the battery as long as it works. The LEDs are there to help you locate a bad cell.

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).

 

[dak664]

It looks like the one-wire cell to cell connections can be done without isolation since the voltage difference is small, but I'd like to see how he protects against a catastrophic cascade failure.

Anyone buying ATTiny's, I'd get the V version which can operate down to 1.8 volts. I bet his code with the communications protocol is a tight fit in the 2KB tiny25!

For AVR Studio simulation, under the debug menu select the simulator platform (simulator 2 is newer but is not well documented and may not support the '85 yet). Then build and start debugging. You can step through looking at the C code or assembler and watch PORTB bits change. The ADC input has to be entered manually or through a .stim file, which is a pain.

I did get something working on VMLAB which shows the LED flashing and shunts turning on and off as you change the battery voltage with a slider. But the free version supports only the obsolete '15 which has no RAM, so there are a couple of hoops to go though to get the '85 hex file to run (as AVR Studio/GCC won't compile for a '15). You either have to patch the .hex file or set the Z bit at the right point to get past the C initialization code. If anyone is interested I can put that on my web site, but frankly working with the hardware is easier, particularly if you want to implement PWM. The commercial VMLAB may be a different story, and diddling with temperatures, resistances, and voltages while watching the power consumptions could be very useful, but that costs $5K.

 

[mwkeefer]

Guys,

I have AVR Studio (full version) and many other IDEs including a nice package called BasCom which is a basic compiler for Atmel MCUs and it is sweet for rapid prototyping using actual devices... also it's slighly easier for non-programmers to work with as it compiles BASIC source down to optimized ASM.

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 = )

I see the work and planning the sweedish ev people have done, it is very similiar to what were talking about doing... we could likely invite them into our planning group since they are in the same direction of research and development that we are at this point.

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