A PIC based Battery Management System

I've put the first full ATTiny85 12 cell BMS shunt board togetherView attachment labelled_tiny85s.jpg
A trick I picked up on avrfreaks.net is to program the '85 in an identical circuit (I set it up on an STK500 at 3.5 volts with a 5.75K sense resistor) so the first startup can measure the power supply voltage and write the correction factor to EEPROM. Then I selected 5.65-5.85K resistors from my stock of quarter-watt 5% resistors for use on the board. The header is compatible with the Headway BMS harness. The '85s don't get warm when shunting ~50ma.
Note the row of LEDs. Right now they blink the cell voltages, but I hope to connect them with a light pipe of some kind for charger cutoff/controller LVD/logging MCU.

Attached is the c source, which contains a rough schematic.
 

Attachments

  • headwayshunt.zip
    4.5 KB · Views: 275
Fechter,

A follow up on our previous discussion on Bulk Chargers or rather customized bulk chargers...

As I see it, voltage regulation within a switching power supply is done just that way within a switching regulation, limiting scenario.

Why don't we design a simple charger designed for charging 1P at 5-10A but more importantly...

we can incorporate a variable voltage regulator output and when the BMS signals a cell is maxed out, the BMS doesn't shunt but signals the charger to drop 1 cell of voltage or even better a specific voltage (whatever the cell that's done reached) and then rather "removes" the entire cell from the charge flow. If this were a 12S pack, this type of approach would reach weakest cell HVC first but then it would reconfigure and charge as an 11S until the next one hits and so on and so forth. Thus we can eliminate the shunting and simply isolate the cells (relays work, are cheap and failures can be detected prior to critical system failures).

This is just an idea that dawned upon me as I work on reading the BM6 assembler code to determine how to calibrate the damn things... When I got mine, 1 was out of calibration... my Fluke and my iCharger both said the cell was 4.1626 but the damn BM6 saw it as > 4.25 and began tweeting away. I am fairly certain given the choice of 10% smt resistor/divider bridge they must have calibrated these durring manufacture ... not all that well it seems. My hope is that by reading the eeprom data I can locate the storage area for these calibrations and reverse engineer them then create a simple GUI to do it via parallel port atmel programmer...

Actually it more hit me as I look for my dremel cutting bits in prep for dissassembly of a 6A 6/12V SLA smartcharger (damn thing has no screws).

-Mike
 
dak664 said:
I've put the first full ATTiny85 12 cell BMS shunt board together labelled_tiny85s.jpg...
Attached is the c source, which contains a rough schematic.
Click to expand...

Cool. Thanks for posting the code. That helps me a lot.

Any idea how much variation in the voltage calibration there is between MCU's?

mwkeefer said:
we can incorporate a variable voltage regulator output and when the BMS signals a cell is maxed out, the BMS doesn't shunt but signals the charger to drop 1 cell of voltage or even better a specific voltage (whatever the cell that's done reached) and then rather "removes" the entire cell from the charge flow. If this were a 12S pack, this type of approach would reach weakest cell HVC first but then it would reconfigure and charge as an 11S until the next one hits and so on and so forth. Thus we can eliminate the shunting and simply isolate the cells (relays work, are cheap and failures can be detected prior to critical system failures).
Click to expand...

The problem there is you'd need a humongous relay for each cell. Normally all the cells are in series, so the current through each cell is the same. If you try to switch a cell out of the loop, it means the relay has to be in series with the cell. This means it's in series during discharge too, so it has to handle massive amps.

By using a shunt, the cells are always connected in series and there are no switches in the discharge path.
 
Twelve '85s bought at the same time had a range of 84 millivolts correction offset at 3.5 volts, which translates into ~20 millivolts at unity gain, or 20 counts out of 1024. Repeat programming of several MCUs gave the same correction to within 1 count.

Although when placed in the charged battery they all gave correct voltages, after a ride they were off by as much as 40 millivolts at 3.2 volts. That could be a temperature issue, or perhaps a two point correction needs to be done. I think the offset at zero can be measured internally. I will look into that some more.
 
Hello everyone,

Since I have been such a proponent of the BM6 units I felt obliged to post this... they are still very useful and the issues I detail can be compensated for, these are still the cheapest simplest off the shelf way I know of to protect Li cells, that said... there are a few issues you should know about.

http://www.designsforbusiness.com/ebikes/videos/BM6-CalibrationIssues/Edited_IMG_0047_BM6_OutOfCalibration_Proof.avi

This video shows the variation and incorrect HVC triggering of the BM6 when testing 4 of them on the same turnigy 6s lipo.

I have edited out the swapping the BM6 units (4 tested and demonstrated on the same 6S pack with nothing connected to it... btw, the fluke and the iCharger show all cells between 4.179 and 4.185 there are .002mv differences between the Fluke and iCharger but that is not of concern... you can see as these 4 BM6 cycle through their various readings they are widly off. You will also hear the HVC beep cut in... look it thinks some of my cells are 4.22+?

The good news here is the error is on the high side, so a cell of 4.18 could read as 4.22+ and trigger HVC alarm... atleast it will prevent overcharge. There are some variations (much more limited scale .010mv) in the LVC detection also... so 3.2 could be 3.21 but... again it's to the side of caution so it's not dangerous but to have finite control and get the most from your packs... you should test / calibrate each BM6 so you know it's offset. This will allow you to select a more appropriate LVC and to determine based on the displayed value if you should ignore the HVC alarm on a particular BM6 unit / cell.

Really, hope this helps!

-Mike
 
dak664 said:
I've put the first full ATTiny85 12 cell BMS shunt board togetherView attachment 1
A trick I picked up on avrfreaks.net is to program the '85 in an identical circuit (I set it up on an STK500 at 3.5 volts with a 5.75K sense resistor) so the first startup can measure the power supply voltage and write the correction factor to EEPROM. Then I selected 5.65-5.85K resistors from my stock of quarter-watt 5% resistors for use on the board. The header is compatible with the Headway BMS harness. The '85s don't get warm when shunting ~50ma.
Note the row of LEDs. Right now they blink the cell voltages, but I hope to connect them with a light pipe of some kind for charger cutoff/controller LVD/logging MCU.

Attached is the c source, which contains a rough schematic.
Click to expand...


Have you considered using internal bandgap measurement, that would help you get rid of one more component I think.
Here is a thread in avrFreaks.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=57559&highlight=internal+bandgap+adc+battery

Otherwise interesting.
I'm really itching to setup a couple of test boards also.
But with transistor and power resistor for shunting and also some communication to the next board in the chain.

Best Regards
/Per
 
pm_dawn said:
Have you considered using internal bandgap measurement, that would help you get rid of one more component I think.
Click to expand...
Drat, even specifically looking for it I missed the VBG selection for the ADC multiplexer and thought the '85 didn't have that option. Thanks for knocking me on the head!
I'm really itching to setup a couple of test boards also.
But with transistor and power resistor for shunting and also some communication to the next board in the chain.
Click to expand...
Optical communication could work, see http://www.merl.com/publications/TR2003-035/. I am thinking red LED's for each cell I/O and a shorter wavelength LED for the pack MCU output, and separate infrared detector for pack MCU input. If necessary a light pipe bus could raise the signal levels considerably. Bidirectional optical signals may not be necessary though, the reset pin on each cell could be pulse coupled to the pack MCU which could then wake a specific cell and trigger its optical readout. Then the cell MCUs would not need unique addresses, as the cell position would be hardwired in the reset pulse multiplexer.
 
You might take a look at this device family:

http://www.analog.com/en/interface/digital-isolators/products/index.html

They use an internal pulse encoder, isolation transformer, and decoder, rated for something like 600V isolation. They're pretty nice devices, and they have a whole range of them. The basic isolators come in various sizes (from 1 to 4 channels, and different direction arrangements) and speeds. They also have isolated gate drivers, isolators with a built-in power supply for the isolated side, and drivers for I2C/RS232/USB, etc. Might be a touch more expensive than optoisolators.
 
I got a working infrared link with some ATTiny85's using an accelerated RC5-ish protocol. I only have enough LED's for three cells at present. They were pulled from an old TV remote and two PC mice. The detector comes from an old cable TV box.

Here's the setup. The three cells being monitored are at the bottom left (the upper right tiny's have red leds which aren't picked up by the IR detector) The leftmost Tiny wakes every 4 seconds and transmits a pack ID and voltage, then pulses the reset pin of the one to the right. Normally that one wakes every 8 seconds to check the cell voltage, but on a reset wake it transmits its value and resets the next, and so on up the line. Voltages from 12 cells (12 bits each) would take about a second to transmit. Transmissions are extremely reliable so far, although a fluorescent light can cause bit errors. Clustering the transmitting diodes and moving the receiver closer would help, or enclosing the pack entirely.

View attachment 1

RC5 chops at 38KHz and the standard detector blocks visible light, autogains, filters, and outputs through a schmitt trigger, so all the receiving MCU has to do is time the bit transitions. It could log to an SD card or set outputs to turn off the charger or throttle, but at present I am just using another '85 to send the data through USB to a laptop. Normally a crystal would be needed since USB has precise timing requirements, but the '85 can calibrate its internal oscillator against the USB bus at startup so all that is needed is three resistors and the IR detector. It uses Christian Starkjohann's USB library which is free for personal use, and attaches as a keyboard so the output can be captured by any text editing program, and saved as a .csv file for spreadsheet graphing.

I posted a graph to the Headway pack thread. which shows the Headway BMS trying to keep the first cell from overvoltaging at a 500ma charge rate. It was about to shutdown the charger so I reduced the current to 150ma which it could handle. Also visible are the effects of the Tiny85's shunting at 3.5 volts once the current dropped below 50ma and particularly when the charging stopped completely.

It might be possible to use red LED's if a similar detector could be found, newer TOSLINK SP/DIF receivers might work but the old ones I have don't seem to work at low frequencies. It would be nice to use also use the LED's for a status display, and watching the transmission propagate up the pack would be cool.

Attached is the current BMS code. It measures the internal bandgap against Vcc so no need for a resistive divider, which frees up another pin. It also does a two point calibration after being programmed, but every chip so far has read 0x0000 when connected to ground so a single slope correction would probably be adequate. It is <2K and would fit into a ATTiny25V but Digikey has those on back order so I will order some Tiny45V and see how they work.

I need to put together a proper package with the licensing files before I can post the USB receiver code.
 

Attachments

  • tiny_bms_small.jpg
    52.5 KB · Views: 2,279
  • Tiny85_USB_BMS.zip
    7.9 KB · Views: 352
dak,

That is very cool...

I had thought of using IR LEDs -> Detector method but... had the misconception that I would need an independent receiver for each LED - (sometimes I wish I was still 6yr old and thought santa was real and anything I could think of was possible - my invention then, a machine like a wood chipper which you would put anything - ie: street signs, dirt, wood, metal, silver, gold,etc and the other end would put out it's value in currency. The point is I would have realized that I could gang the HV side and use a single detector for multiple LEDS.)

So ... now that I'm out of the box, seems to me ... it wouldn't be difficult to make a simple mold to gang 6,12,15 however many LEDs together ... then a simple focus lens could be implemented with a funnel design to concentrate the IR beams towards a collector (also in the mold)... finally mix ABS + Acetone and pour the mold.

Whalla, nice enclosed multi -> 1 optocoupler.

This is far better than my semi-isolated transistor design for extending my BM6 units usefulness so I am going to do this tonight/tommorow with my BM6 units (augmenting the piezo with a low consumption SMT IR LED) and will do the first version of the circuit with a simple mold carved with foam, lined with plastic wrap and wooden dowels of appropriate diameter for the parts then pour a WAX connector (yep candle wax, it's dirt cheap, non-toxic, safe and easy to make castings with, machine, tweak and finally make new molds with for the revision design process) to build the first version... if it works I will cast them with ABS/Acetone (How I make all my custom connectors or imitations).

Thanks for the idea (and the removal of the same old mental blockage I suffer constantly, the "thats not possible" block).

Regards,
Mike
 
It wouldn't be necessary to encapsulate the IR links as TV remotes can operate up to 10 meters, although I expect they use drive currents of 20ma or more while I am using 10ma. There would be some advantage to letting the IR flood the area to allow one or more external receivers to log the data or control the charger. The loading on the battery is small, around 10ma*3msec = 30 microamp-seconds for the 12 bit transmission from each cell.

How are you going to coordinate the sending from each LED? It should be possible to receive using the same LED, which I haven't tried yet. Now that would benefit from encapsulation. Consider provision for an LED on the receiver side to possibly broadcast commands addressed to a particular cell.

I have a Windows program originally written for solar logging through a USB CDC device (COM port) that has a window showing the text from the COM port as well as whatever the user types in, with the COM text parsed and sent to a real-time graph. It wouldn't be hard to modify it to graph the data typed by the battery "keyboard". If anyone is interested in that or the USB bridge code, PM me.
 
Wow, this is quite a thread. I've just read the whole damn lot (over 3 nights), and it's been highly educational. At various points along the way I had numerous things to say, but I'm pleased to see that the sorts of designs people seem to have settled on fit with my way of thinking (mcu per cell or cell-group). opto-isolation for data comms.

The one part I didn't understand was the fancy capacitor/inductor-switched shared-power balancing - that was too much analog 'lectrics for me, so I have no idea if it was a really good idea or not.

Lots of stuff in here was nifty in one way or another but I must say that rhitee05's voltage measurement scheme was genius. That's the only design that made me wonder if maybe that was better than mcu-per-cell/group. Could well be worth persuing.

I'm an embedded linux person with a smattering of electronics knowledge (enough to follow nearly all of this thread). I've got a moped which is about to get a 72V 20Ah pack fitted (headways probably). I was planning to fit a G/F analog BMS, but am now wondering if it's worth going digital. It looks like none of this stuff is sufficiently developed for that quite yet, although there appear to be at least 4 prototypes that have been built, and maybe sometime soonish there might be something ready for hacking?

Anyway, I can help with coding (I'm a C, shell and assembler person), although my AVR and PIC foo is pretty weak. I am extremely keen on all software and development tools being Free Software so things are platform independent (I don't have any access to Windows, for example), and am happy to muck in on that basis. Like most people here I already have a pile of projects, so I shan't promise much, but I am interested, and hope I can contribute usefully. I have bucketloads of Free Software and collaborative development experience which might be useful.

I favour using the MCU's built-in bus for comms. Most of them support I2C or SPI or Smbus or similar. I2C and Smbus can be considered equivalent for our purposes, and are quite easy to bit-bang. I have a circuit for I2C power-isolation which I just reverse-engineered from my Solar PV inverter. 4 opto-isolators and a few passives for bidirectional interface. I note somewhere in this thread someone pointed out the ADUM1250 I2C isolator which is a neat single-chip solution, but seems to costs rather more than the discrete solution.

One thing about this, unless one goes for daisy-chaining, is that I2C needs an address for each chip, so if we are to send messages _from_ the master then we need some way to set the addresses differently for each device in a pack, which could be a bit of a pain. Being able to have each mcu runing exaclty the same code and config is a definate advantage. How have people got round this? If they only send data out _to_ the master then it's not an issue.

I note that at least one simple module-per-cell solution already exists, and doesn't appear to have been mentioned on this thread: http://www.evworks.com.au/index.php?product=BMS-CM060-V6 It only deals with the HVC shunting and charger limiting part, not the LVC, but the mechanical design is good.

It seems to me that mech design for the prismatic cells, one mcu-per-cell is obvious, but for cyclindrical cells or cell-groups it's less clear how it should be set out.

That's all for now. Congrats to many people for the efforts so far.
 
You must log in or register to reply here.

Similar threads

V
Impulse based battery management system
Replies
3
Views
852
BlueSwordM
BlueSwordM
marka-ee
design for an arduino balancer , what do you think ?
Replies
8
Views
1,203
fechter
fechter
thunderheart
Samsung 21700 battery battle - 50G vs 48G vs 50E
Replies
0
Views
2,893
thunderheart
thunderheart
B
FOC Help Needed
2
Replies
45
Views
6,296
Breville
B
frk1206
68Kw/140Nm DCFC capable street motorcycle prototype
Replies
8
Views
2,082
larsb
L
Back
Top