A PIC based Battery Management System

Tiberius said:
There has to be better ways than opto couplers.
A lot of people like the opto idea. The only other one that jumps out is the capacitor idea spanning the gap between cells. If the processor could just sense some variation in the capacitors charge that's all you need to communicate. No real current needs to flow.
 
For the basic functions of a BMS, you could skip sending actual data and just send a signal to operate the LVC and one to reduce the charging current.

One thing I'm still sort of stuck on: If the cell processor goes to sleep (which it would need to do when the battery was in standby), how do you wake them up?
 
One way is to make them periodically wake themselves up, by running an internal timer whilst they're "sleeping". The controller wakes up up, runs a bit of code, takes some action if needed, then goes back to sleep again. The power overhead for doing this every minute or two is very small.

Jeremy
 
I went ahead and ordered a bunch of parts to play with.

The parts I chose may not be ideal, but they will hopefully let me prove the concept.

I ordered (25) ATMEGA48V-10PU's, a bunch of optocouplers, and the serial LCD display referenced on the first page of this discussion.

I'll start with something simple that reads the cell voltage and communicates the voltage down the chain. The last one will write to the display. Once that's working, I can work on sleep modes, etc. Even without sleeping, it looks like it would run 400 days on a charge, unless I'm reading something wrong. It's also possible to slow down the clock to conserve power.

- Brad
 
bquick said:
...they will hopefully let me prove the concept.
You've got spunk!

I hope you succeed... it's always nice to see people invent a completely new approach and put themselves out on a limb to pull it off.

:arrow: You would have been a pioneer in the old days.

(to my knowledge no one has proposed the exact same idea... and for those that doubt, let's see proof otherwise)
 
bquick said:
I went ahead and ordered a bunch of parts to play with.

The parts I chose may not be ideal, but they will hopefully let me prove the concept.

I ordered (25) ATMEGA48V-10PU's, a bunch of optocouplers, and the serial LCD display referenced on the first page of this discussion.

I'll start with something simple that reads the cell voltage and communicates the voltage down the chain. The last one will write to the display. Once that's working, I can work on sleep modes, etc. Even without sleeping, it looks like it would run 400 days on a charge, unless I'm reading something wrong. It's also possible to slow down the clock to conserve power.

- Brad

Great! What will you be using for a development base for the Atmegas?

Those chips have lots of I/O and all the trimmings. If one way doesn't work there are many others to try ...


Richard
 
Safe,

I've been designing industrial machinery (including the software) for the past 24 years (http://www.jamesltaylor.com), so I usually have a pretty good idea of what can be done and what can't.

I'm working on my first conversion (Ninja 250) and I am awaiting a bunch of the cells that Jeremy just received. My two goals are to 1) protect my rather large investment in batteries and 2) be able to monitor battery usage.

While I wait for parts to arrive, I figure I'll play with some electronics. I've always wanted to play with one of these computer on a chip thingies.

I imagine that just about all of us who are interested in electric vehicles are pioneers in one way or another.

Richard,

I downloaded AVR Mac Pack which will let me program on my Mac using Xcode. This is great because I'm used to using Xcode already. I'm already able to compile code. I've ordered a USBasp for $16 to do the burning with. We'll see how long it takes for me to actually get a program running on a chip. There are lots of things that have to be just right before anything will run.

I'll let you know how I make out.

- Brad
 
Hi Brad,

Good luck, let us know how you get on.
Are you using the externally programmed Atmel chips?
We generally use the ones with in circuit programming; we use the STK500 starter kit. That way we get the choice between DIP and surface mount packages.

I too have a set of Headway cells on the way.

Nick
 
I won't get my programmer for 10 days or so, but this is the code I've come up with so far. It compiles without error, but keep in mind that this is my first AVR project, so there's still lots of debugging to do. I usually wouldn't write this much code without running it, but I needed to gather all of the information in one spot anyway.

For those of you interested in such things, please feel free to comment:
 

Attachments

  • main.pdf
    52.6 KB · Views: 130
Maybe one of you electronics guys can help me out here:

Is there any reason why I couldn't share a serial output by having it drive two optocouplers? I'm thinking I could disable one or the other by pulling the other side of the diode to ground with another output.

It this will work, I can make a complete loop of serial connections between processors. This allows for more intricate messaging to all processors.

- Brad
 
Woo Hoo...

I just received my batteries today from Headway. Eighty of the same cells that Jeremy got. Shipment time was just what they quoted. All in all, my experience with Headway was a good one.

- Brad
 
bquick said:
Maybe one of you electronics guys can help me out here:

Is there any reason why I couldn't share a serial output by having it drive two optocouplers? I'm thinking I could disable one or the other by pulling the other side of the diode to ground with another output.

It this will work, I can make a complete loop of serial connections between processors. This allows for more intricate messaging to all processors.

- Brad


Sounds like a sound idea. Software becomes more complex because the serial port is shared between two devices.

Marty

P.S. Your schematic looks good. I only saw some missing pull ups (which the Atmel might provide) when I glanced at it.
 
bquick said:
Can anybody see why this wouldn't work?

- Brad

Hi Brad,

As I posted earlier, there are simpler ways of signalling between the processors than using opto coupler. I just drew up a couple of example circuits to show how its done, but I haven't worked out how to post an image on here. I'm away from base at the moment so I can't even post it to my own webspace and link to it.

Nick
 
When you're posting, look below the text box for the browse button next to "filename".
Find the picture file, open, then hit the "add the file" button. You will see a box pop up while the file uploads. After that, you can locate the cursor in the text box and hit the "place inline" button if you want the picture to be in the middle of the text.

It seems like you could pass data from one cell processor to another in a chain so that the voltage difference between cells is not too great. The chain could be pretty long. Seems to make more sense to have each cell unit talk back to the main unit directly, although speed is not really an issue since battery voltage changes relatively slowly.
 
http://autos.groups.yahoo.com/group/EVBMS/files/CasaDelGato/4Batt/

You need to be a member, but......


This guy, in 2004, did a 4S cell per cpu (ATMEGA8) BMS. In his files are the circuits, pcb layout, ATMEGA software, and pc software for data logging.

For daisy-chaining multiple serial ports, have a look at RS485. All units in parallel receive, each unit only switches on it's transmitter when required, otherwise it tri-states. If you give each unit a unique id code, and use the pc as a master. PC sends a query string which contains the id number of the unit to be queried, so only that unit responds. Google "Modbus" might explain it better.

Amanda
 
I use the Arduino clones as cheap development platforms for the Atmel chips. A complete board can be had for as little as $11 and the gcc-based development software is downloadable for free. Plugs into your PC via USB or serial port. You edit and compile on your PC, click, and it downloads to the Atmel and runs. Quick, easy and cheap.

http://www.arduino.cc/
http://moderndevice.com/RBBB_revB.shtml

Richard
 
Tiberius,

I'm interested in seeing your drawings. The opto-isolators shouldn't be too bad. It only costs $.16 per cell.

Amanda,

I've used RS-485 quite a bit. A star topology would work, but it would require more optos and each unit would need it's own address. You would need a separate opto for each send and each receive.

I think my daisy chaining idea will actually be faster because a processor begins forwarding it's data before it has even received an entire message.

The only advantage I can see to the RS-485 type of arrangement is that if one processor stopped working, it would be easier to figure out which one went down and the rest of the system could keep going.

- Brad
 
You don't really need opto isolators, a transistor will do the job. Here's a rough schematic of the concept which only shows 3 cpus but you can obviously just continue to replicate the stages for as many cells as you like. Each CPU has separate Data in and Data out (RX and TX). The base of the NPN transistors are connected to Vdd for each cpu. When the TX line pulls the emitter of the transistor low through a resistor, it pulls the RX line of the CPU immediately above it low also. You can select your resistor values and data rates to make the total current drain of this very low. Also no current is drawn by the communications when the Data outputs are idling high. If you have an active low IRQ input line on the CPU you can connect it to the RX line and also have the communications wake up the next processor from a sleep state.
You can use an Asynchronous clocking protocol, manchester encoding, or if you want to go brute force you could just replicate the level shifter circuit for an additional data clock line.

The CPUs are all connected in a ring, the top CPU has a slightly different level shifting circuit that communicates with the bottom CPU. R3 is included to provide some current limiting protection for the CPU in case of voltage spikes or shorts. Everything is active low out, active low in. If you need an active high for your IRQ you could just implement this with PNP transistors and go the other direction.

I'll let you worry about the communications protocol. You can easily implement some time outs to handle cpu and communication failures etc and light an appropriate LED on each stage if a timeout occurs, which might help with system debugging. You can also fully receive a message at one cpu, and only then pass it on to the next and add it's own data, and then put the CPU to sleep till the next message comes in. This way the data packet is just chasing around in a circle but only 2 CPUs are awake at any one time. It would also be fairly simple to implement cell balancing during charging, and control the charging.
Hope you find this useful.
 
fechter,

Thanks. Here's a circuit for signalling to the processor above.
OneStepPassUp.GIF
And here's one for signalling many steps up.
ManyStepPassUp.GIF

Obviously you can do the same thing going down the voltage chain with PNPs instead of NPNs.
Clearly Randomly has been thinking on exactly the same lines, and connected them round in a chain.

Since I drew this up, I have thought that maybe passing messages serially between the processors might have a problem. What happens if one cell goes down completely - you lose the communications. That alone might be a reason for making the connections directly between the cell processors and a master. That can still be done with the level shifter circuits that Randomly and I have drawn.

Nick
 
Perhaps there's a way to use similar techniques with a single CPU with a floating ground. Select each cell in turn and match it's ground to the CPU to measure it's voltage.

Richard
 
Verbalization for the Amateurs

I've been patiently watching this thread (rather than saying too much) let me see if I can summarize what is going on for people that might be reading and aren't electrical engineers. (which I'm not either)

The problem with pack cell voltage measurement has been the "common mode voltage" issue which is that any time you try to centralize any information about the cells the voltage differences between the cells make things difficult.

By eliminating the centralized concept and switching to a cell-to-cell communication idea you only have to deal with the voltage difference between two cells. The data is passed from one computer chip to the next as "data" rather than as a voltage.

This is going from an "analog" treatment of the problem to a "digital" approach.

Okay... keep going... now other people will realize what's going on... :p
 
Thanks for the diagrams.

I can see now that the communication can be done with transistors instead of opto-isolators. In my case, I don't think the pull-up resistors would be necessary since the ATmega's inputs are internally pulled up. I already have my opto-isolators, so I'll stick with them for my test. I like the idea of isolating things anyway, but that's probably because of my limited electronic knowledge.

I posted the vehicle this will eventually go into here:

http://www.endless-sphere.com/forums/viewtopic.php?f=12&t=4546&p=67172#p67172

- Brad
 
bquick said:
Thanks for the diagrams.

I can see now that the communication can be done with transistors instead of opto-isolators. In my case, I don't think the pull-up resistors would be necessary since the ATmega's inputs are internally pulled up. I already have my opto-isolators, so I'll stick with them for my test. I like the idea of isolating things anyway, but that's probably because of my limited electronic knowledge.

I posted the vehicle this will eventually go into here:

http://www.endless-sphere.com/forums/viewtopic.php?f=12&t=4546&p=67172#p67172

- Brad
Cool.

So you already have an LVC (low voltage cutoff) and you're just looking to add instrumentation?

Richard
 
Back
Top