Old BMS Hardware Thread

[GregsGarage]

I'm going to stick with the SV2000 video chip for now for the next Master which will be V2 as we all have some.

At least I will be able to put my SV2000 chip to use. I agree the master has come a long way. I have also wondered how readable the TellyMate display would be on a small screen in a car, it might be just too small for comfort, although it does have the option of double wide and double tall characters, so it could be that the main display is in large format and diagnostic information could be displayed smaller.

[Fufunka]

Next question. what data available from the Master should I/we log to a PC spreadsheet/data file via the wireless link? I'm assuming here the wireless link is only going to be used when the car is parked up and charging as a safety feature.

Pack Voltage?
Soc?
Charge Current?
Battery Temp?
Charging finished?
Any Alarms?

This is perhaps more general feature "request"..
What about max. SOC ETA (and max. SOC selectable)?
By default it should be 100%, but it might be usefull to have it selectable, lets say it is hot summer, you know the car will not be in use for perhaps another 24hrs or more, so why "kill" the batts. leaving them in prolonged 100% SOC, I think Tesla calls it "storage charge mode", therefore>>

example #1:
60% max. SOC user selected => e.g. at 45% SOC the max. SOC ETA prints on display
"max. SOC% charge ETA in ~30mins"

/before driving user-operator selects back to 100% as max. SOC and tops the batteries

example #2:
100% max. SOC user selected => e.g. at 70% SOC the max. SOC ETA prints on display
"max. SOC% charge ETA in ~1hrs"

--
btw. sorry for poluting this hw thread with sw talk, so on another subject
I liked and appreciate your way of thinking towards future gizmos like SimpleLAN/Twitter-PIXACE etc.

[Fufunka]

The following issue/topic has been briefly mentioned perhaps a year ago.
In case of HV system with a dozen ~48VDC modules (full voltage seen
during drive only - broken into modules while charging for safety),
would it be still possible to somehow accomodate this very BMS?

Theoretically, could there be added another layer?

Imagine these modules/subpacks being polled by semi-master pcb, which will then refer up to single top master unit (display out and other functions)? However, these semi-master boards will have to be able to control their local charging units/smart power supplies.

[GregsGarage]

The following issue/topic has been briefly mentioned perhaps a year ago.
In case of HV system with a dozen ~48VDC modules (full voltage seen
during drive only - broken into modules while charging for safety),
would it be still possible to somehow accommodate this very BMS?

Theoretically, could there be added another layer?

Imagine these modules/subpacks being polled by semi-master pcb, which will then refer up to single top master unit (display out and other functions)? However, these semi-master boards will have to be able to control their local charging units/smart power supplies.

No problem with the slaves since they are all opto isolated from each other. The master would need some reworking though. You could use your suggestion, but you might also get away with the master controlling all your charging modules in parallel. So it would start to cutback all the chargers equally based on the highest cell in the pack. A simpler solution, hardware wise, but the software would require some work. Of course your limit is the number of slaves the master can accommodate, can't remember this number, but should be in the thread somewhere.

I will say that is much more voltage than I would feel comfortable working with.

[retepsnikrep]

Thanks for the questions/ideas.

I'll consider them for future versions of the software.

The limit for cells is 256 at present without any major changes to the software. That's about 750v or so and high enough for me.

I've got another project on the go so won't be getting back to the BMS hardware for a bit. But I havent forgotten about multi cell slave or change to assembler and native pics etc etc. Peter

[Fufunka]

I will say that is much more voltage than I would feel comfortable working with.

Well, as mentioned before and in fact you won't see such a high voltage, the concept is based on braking the ~600vdc pack into -/+ 300v lines feeding the controller. And for charging only ~48V packs dis-connected via relays are utilized, the same holds for parked vehicle. So, one can even argue it's much safer than any 100V conversion during charging or service mode.. There have been even some 300vdc offshoots from this "industrial components" approach as well.
http://www.evalbum.com/1149

The issue is not finding a LVC or BMS for it, but rather identifying suitable integrated system, similar to Peter's. Which in this case will have to somehow accomodate the fact that the dc bus is either disconnected during charging and also connected while driving. So there will have to be some sort of aggregate of info polled from these ~dozen subpacks going into the master-board => display etc. under both these modes.

[GregsGarage]

The issue is not finding a LVC or BMS for it, but rather identifying suitable integrated system, similar to Peter's. Which in this case will have to somehow accomodate the fact that the dc bus is either disconnected during charging and also connected while driving. So there will have to be some sort of aggregate of info polled from these ~dozen subpacks going into the master-board => display etc. under both these modes.

I can't see any reason for this BMS not working with your proposed setup. Put your current sensor on either the first or last 48v box. When they are disconnected for charging you will only be measuring current for that box, but it would be safe to assume the rest of the boxes will have the same current going into them as well so I don't see a need to monitor the current on them. The pack voltage is made by the master adding up individual cell voltage. Having the master continue to calculate voltage this way, even with the dc bus disconnected, won't really affect anything. It will still control the charge based on the highest cell. So if you have all the chargers cutback when the master signals this you will still get a charged and balanced pack. Yes it would be better to have each charger controlled based on its 48v pack, just depends on how much you want to spend in time and money. You could even add this later, there is no reason you have to use Peters master, I had thought of makeing an Arduino based master, but no reason to really as Peters works very well. The only other problem is battery tempurature, you should have 1 temp sensor per box at least, so you will need to think abourt that, but shouldn't be difficult, several possibilities come to mind.

The main issue with the slaves is that if you go with the multi-cell slave module, you will need one for each 48v box (16 cells). Peter had proposed a 32 cell slave board which would be fine for my next project, a 46 cell vehicle with battery boxes split between front and rear, not necessarily evenly though. The 32 cell module would give me flexibility in layout of my cells, but in your case you would be paying for a lot of circuit board that you won't use. The multi slave pcbs still need to be designed and made. I am going to start work soon on a 32 cell slave pcb, but if you or any one else wants to help work on the layout of a pcb, 32 cell or otherwise I am open to any help or suggestions.

[GregsGarage]

I am going to have a go at the multi-slave pcb. Using Peter's scematic I have redrawn it slightly, my version is here - http://www.go-ev.co.uk/projects/bms/old_files/slave.jpeg

This circuit is for a single cell. I have designed it so the circuits "stack". That is cell 2 sits above cell 1, etc (cell 1 positive is also cell 2 negative). Instead of trying to put a single, large multi-pin connector for the cells on the board, I will solder wires to the board for each cell's positive terminal and the first cell's negative terminal, and put the connector on the end or the harness. The harness will be just long enough to attach to a connector on the battery box. This means only one connector between the slaves and the cells, so less chance of a poor connection causing problems, and also large connectors on circuit boards in vehicles are a potential problem with vibration taking its toll over time. It also simplifies the board layout.

For programming I have added J2, next to the programming connector J1, to supply power while programming. The board should be disconnected from the pack for programming and then each picaxe can be programmed in turn using a programming lead and 4.5-5 volt supply tied to the programming leads earth.

Anyone see any obvious mistakes or have suggestions to the layout? Next step is to decide on how many cells per board. Peter had suggested 32. I am considering something smaller, maybe 12 or 16. A 12 cell layout would suit me best, but a 16 cell layout may be more useful for others. Anyone have any thoughts on this?

When Peter first suggested the multi-board layout I suggested possibly designing the board so it could be cut into smaller sections if required. It may be possible with this layout, if anyone wants it. Of course a board doesn't need to be fully populated, just attach the slave bus out in place of the next slave's opto and you are ready to go.

Greg

[retepsnikrep]

Well done Greg. I've looked at your schematic and seems OK.

A few comments.

I like the idea of J2 to supply power I suggest make that a 2 pin sil 0.1" so that you have a simple connector to push on it powered from 3xAA batteries. Or you could make J1 a 4 pin connector (the 4th pin to +ve) and just make up a special programming lead which incorporates the battery supply.

My main concern was about how the final connection would be made to the board. You are proposing a multi connector at the battery box is that correct? My multi cell connector was going to be on the board.

Imagine the board is ready to go and we plug in a multi cell connector if say the top and bottom pins make contact first how would that effect the board? Or imagine any other combination of pins does it make any difference and is it/could it be detrimental blow the board?

Remember when stacking the multicell slave boards the last + on the bottom board becomes the first negative on the next board up and needs a connector between the two or two wires from that/those terminals at the battery, one for the last + on bottom board and one for first - on next board up.

Need to try and design it so high current will not try to flow in these wires as well.

Finally I think 16 cells is a good number. Because the Master can cope with upto 256 slaves and that divides nicely into it.

256/16 = 16

256/12 = 21.333333333

As aside I'm learning PicBasic Pro (A compiled much faster system) for my current project, and I may be able to port this knowledge over to make a non picaxe slave which would reduce the cost as we could buy naked chips. (Rick is already tinkering with this) This could be a year away for me though as my current project is pretty tough.

If we wanted to be able to program in situ with this we would need to include the ISCP pins for each slave. I'm not sure about those for the PIC12F683 (Picaxe 08M) or how they would fit in along side the slave schematic. ICSP may not be so much of a necessity as the current picaxe digital slave software I'm using has worked for over a year without any changes or issues. If it works in my Insight I reckon it will work anywhere!!!!

[GregsGarage]

Well done Greg. I've looked at your schematic and seems OK.

A few comments.

I like the idea of J2 to supply power I suggest make that a 2 pin sil 0.1" so that you have a simple connector to push on it powered from 3xAA batteries. Or you could make J1 a 4 pin connector (the 4th pin to +ve) and just make up a special programming lead which incorporates the battery supply.

Will do the 4 pin connector.

You are proposing a multi connector at the battery box is that correct? My multi cell connector was going to be on the board.

Correct, I will have a harness coming from the slave with a multi conector to join a matching connector on the outside of a sealed battery box.

Imagine the board is ready to go and we plug in a multi cell connector if say the top and bottom pins make contact first how would that effect the board? Or imagine any other combination of pins does it make any difference and is it/could it be detrimental blow the board?

I don't think it will be a problem, R5 on each board should act as a voltage divider to protect individual boards until full connection is made, not sure how D1 in series will affect this though.

Remember when stacking the multicell slave boards the last + on the bottom board becomes the first negative on the next board up and needs a connector between the two or two wires from that/those terminals at the battery, one for the last + on bottom board and one for first - on next board up.

I can add pads if you wanted to connect this way, in my case I will have seperate battery boxes, so it would not be an issue

Need to try and design it so high current will not try to flow in these wires as well.

I will have 1 amp fuses on each cell connection including the first cells negative.

Finally I think 16 cells is a good number. Because the Master can cope with upto 256 slaves and that divides nicely into it.

I like 16 as well.

As aside I'm learning PicBasic Pro (A compiled much faster system) for my current project, and I may be able to port this knowledge over to make a non picaxe slave which would reduce the cost as we could buy naked chips. (Rick is already tinkering with this) This could be a year away for me though as my current project is pretty tough.

If we wanted to be able to program in situ with this we would need to include the ISCP pins for each slave. I'm not sure about those for the PIC12F683 (Picaxe 08M) or how they would fit in along side the slave schematic. ICSP may not be so much of a necessity as the current picaxe digital slave software I'm using has worked for over a year without any changes or issues. If it works in my Insight I reckon it will work anywhere!!!!

I did actually draw the schematic with a ICSP header as well as the picaxe header, refer to the datasheet for the circuit. Only one issue came up and that is the CLK pin connects to pin 6 of the picaxe, the one that is being used for vref. So D1 would limit any signals to 1.2 volts. I don't know if this is a problem, so I removed it. It could be a feature for the next version though.

EDIT 26/10/09: Cleaned up up the schematic in my previous post.