BMS/Master brain

[Simy]

This was what was removed from the post I made in the Simple BMS thread. I like the idea however I want more... more flexibility as well as a single decision maker. The post removed part of that post follows:

------------

What I'm thinking is there are 2 basic types of battery voltages, the single cell battery access (eg lipo, nimh,li-ion, etc) and multi cell access batteries (agm, sla's etc) The hardware differences between the two as far as a BMS node are concerned are not too much different and if your running a multicell battery a simple addition will keep the voltage in spec.

For each cell variation the differences in voltage are not that extreme so the hardware can have an adapter for multi-cell batteries, and for single cell batteries it wouldn't need it. The rest seems to mostly be a software issue. If we need to change a resister to handle a different battery that is fine by me, and seems to be a reasonable solution to that problem as well. The software can take the input (adjusted or directly) and compensate for it in SW. I'll write up a block sketch of what I'm talking about and go looking for parts. I plan to buy the pickit 3 and a few parts to get me going on Friday, but I may just get them when I get off work I think PIC's are awesome I can't believe I never knew about them or took notice if I did....

For software and input what I'm thinking is each cell when it starts will be numbered. Master (0) the nodes will simply add 1, and when communicating will identify which cell it is. The numbers I care about are number of reporting nodes, highest voltage, lowest voltage, highest temp, lowest temp, and average temp, and average voltage.

There will be an extra non daisy chained node that should detect current flow and volts of the entire pack. If we take the average voltage from the nodes and the voltage of the pack and it dosn't add up (accounting for voltage drop/resistance in lines etc) then we know something is wrong!

I'm not sure if it can work that way and right now I'm at work on my netbook so when I get home like I said I'll look at what and how I want it all to work.

I personally want the master node to monitor the controller, charger, and motor, as well as actually control them in as simplistic a way as. Plus be the main input/output. This way it handles all energy decisions, from a single source and I think in the end will be cheaper as an entire system. You would always be able to omit whatever you wanted from the module sets (EG controller module, BMS node modules, charger module, input module, output module). I think this would give everybody the most amount of DIY flexibility while having the potential to be the cheapest. Any one component can be redesigned without mucking up everything if one device is the decision maker, and it can be reprogrammed if needed for updates or an 'exotic' module that I can't think of currently.

Thankfully most of the work is done, I just need to 'dumb down' the open source charger, controller(s) (both DC and AC when its done), etc... The input side of it should be straight forward. Output can be added at any time, as well as data logging (which I think can be very helpful!)

This way you have a mix and match system tailored to your current needs and if they change you just add or subtract a (cheap!)module, the SW does the rest.

Feel free to correct me when I'm wrong (I'm sure I'll give you plenty of times to do so...) And give suggestions! I'm just getting restarted in electronics (which I never really did anything with anyways) and just learning PIC's! I would wait until Paul and company has everything done but I want something to do too

[Simy]

I just ordered the pickit 3 and most of the parts required by harlequin2's BMS Nodes. I'm going to play with the PIC that it uses for awhile and then look into changing the HW around until it does what I want it to do. As far as the block diagram I have one half done on paper but I'll give all the details in text here:

Inputs:
__Motor Temp
__Controller Temp (high current portion)
__Charger Temp (high current portion)
__Motor Current (ammeter) [between input of motor/output of controller]
__Charger Current (ammeter)
__Total Pack Current (ammeter)
__Total Pack Voltage
__Charger Voltage(maybe ?)
__Throttle Position
__Brake Position

-BMS Node (from harlequin2's design)
__Cell voltage
__Cell temp
__(Cell Node's will self-number each other in SW)


Outputs:
__Controller Safety Cutoff (Relay to disengage the controller from pack)
__Charger Safety Cutoff (Relay to disengage the charger from pack)
__Pack Safety Cutoff (Relay to disengage the pack's mid way to reduce voltage) [maybe]

-Advance output module
*TBD

-Basic output module (dash lights/gauges)
__Speedometer
__Temp (User programmable)
__Tach (User programmable)
__Volt (User programmable)
__Fuel gauge
__Check engine, oil, coolent, transmission, etc lights


Software ideas:
Use the temp. gauge and dash lights to indicate if there is an issue. For example if the motor is too hot light up the check engine light, and show a relative (cold/normal/hot) measure of temp of the motor.
If the battery is hot or cold light up a user selected light and show the temp gauge at the relative temp.
This can also be applied to the speed controller and the charger.

This board should handle the "logic" circuit of driving a motor, and may be best incorporated with Paul's upcoming universal motor controller; I plan to integrate his design on this board, or at the very least communicating and controlling it.

The basic principal is that most of this stuff is redundant. You need to monitor pack voltage for the LVC and HVC in the charger and controller, as well as the BMS for balancing the cells. If each component uses $2.50 in parts that is $5 that could be spent on an LED dome light upgrade

This system should maintain a 'safe' car regardless of how haphazard a device is. The speed controller for example will be cut off if it is giving power with no throttle command, and the charger will be cut off if its voltage is too high or too low, or if it is putting out to much current.

I'm not sure if I want one or more parts broken into "nodes" besides the cell nodes. The least amount of parts tend to be less expensive, on the other hand I don't want excessive wires running about if the cost of the wires would seriously offset the cost of making a small node board. A 2 wire com's system should be fine for talking to some small nodes, for example you could have a node in the front that tells you all this information, or you could simply have a node behind the dash board with smaller length wires plugged into each light socket and dial versus running them to where ever the main board is at.

I'm open to any suggestions, ideas, comments, etc. Tell me if its a good idea, bad idea, etc I don't mind provided you can answer 'why' or 'why not'

[sawickm]

Originally Posted by Simy

I'm not sure if I want one or more parts broken into "nodes" besides the cell nodes. The least amount of parts tend to be less expensive, on the other hand I don't want excessive wires running about if the cost of the wires would seriously offset the cost of making a small node board. A 2 wire com's system should be fine for talking to some small nodes, for example you could have a node in the front that tells you all this information, or you could simply have a node behind the dash board with smaller length wires plugged into each light socket and dial versus running them to where ever the main board is at.

Simy

Your BMS project sounds like a very ambitious undertaking !!!

A good resource of info on BMS's is Elithion they are an industry standard, this is a link to their whitepapers on BMS and batteries: Li-Ion BMS - White Papers their paper on "Spaghetti in my battery" talks about centralized and distributive BMS systems. It might give you some ideas.

-Mark

[Simy]

Originally Posted by sawickm

Simy

Your BMS project sounds like a very ambitious undertaking !!!

A good resource of info on BMS's is Elithion they are an industry standard, this is a link to their whitepapers on BMS and batteries: Li-Ion BMS - White Papers their paper on "Spaghetti in my battery" talks about centralized and distributive BMS systems. It might give you some ideas.

-Mark

Great, now everything is out the window. =) Seriously though, that was a good (albeit quick read without getting their $100+ book)

I was originally trying to more or less consolidate different projects into one unified modular system but I think I'll start with redesigning the energy managment system. Everybody seems to use the term BMS but to be quite honest an EMS would be better in two respects. It can 'cut off' the load (or controller in the case of EV's) and control or cut off the charger.

I think a good system should be adaptable to almost anything, like harvesting renewable energy and handeling the batteries in that.

Given what I've recently read I've got an idea. Thanks to DJBecker's comment on the Integrated ReVolt System thread here I think we should opt not to daisy chain them, and not have more wires then needed. Originally I was wondering if it wouldn't be possible to just take a 2 wire thing and clip it to each BMS as it goes by. I'll look into a good way to implement that.

However I'm unsure about using CAN and DJBecker is welcome to comment here on why CAN would best be used and further why its best used as one large single comm's array. I believe it would be best to divide the entire system into two communication networks. The one being all the BMS nodes with the master, the second being EVERYTHING (BMS master included)

I'll start on a revised graphic and post it soon... for real this time


Edit:
I think this is a basic outline of DJBecker is requesting: A standards based comm. network. He suggested using CAN specifically.

This is a *simple* block diagram of what people seem to want and what is likely. I didn't put the BMS nodes on the main array for a reason, they need to communicate VERY quickly. Nothing should interfere with them. Sensor nodes can be added and programmed when to alert or not. For example a sensor could be put on the motor to tell when it is hot so the controller can cut back.

If that is going to be the case then I think we will need to add a module to make decisions and sent reports out. I'm not sure how this will all work but anything could be tied into it simply enough. If there is support for this, or suggestions before I go down this road I would like to hear about it otherwise I will not likely get into a system wide comm's network. I will however use one for the BMS.

System wide and BMS comms is in the picture which I hope will be posted below:

Picassa Link: HERE

[Simy]

I guess with the CAN system they need a resistor terminator. I'm still reading about it and thinking about how to utilize this type of system. Please bear with me =)