Low cost BMS

[harlequin2]

Send me a pm with your email address and I'll send you the current files.

[dcarlson]

Thank you for the files harlequin2! I am working on the voltage divider now and will hopefully post an updated schemtic for AGM's soon.

I found this link googling voltage dividers:

www DOT electronics-lab.com/projects/test/016/index.html

Looks like this divider would work well!

Doug

[toledi]

Nice work on the BMS !

I to would be interested in Pb BMS.
I am using 9 AGM 12V / 100Ah for my car.

Keep up the good work !

[harlequin2]

I'm not interested in PbA batteries myself as I think they are a complete waste of money as far as powering an EV is concerned! However, I have sent my files to dcarlson and he is keen to develop a version for these batteries, so watch this space and hopefully he will give us updates on his progress.

[filip]

Hello everybody,

harlequin2, when I came across your BMS design, I really loved the daisy chain
idea - full isolation and two way communication possible while being
really cheap - excellent thing.

While reading this thread I came across three ideas - maybe we could
discuss them?

1. Use only transistor in a TO220 package for shunting

This would mean that the module would have to be calibrated (the MCU would have
to output the right voltage for the MOSFET to pass for example 1A), but we
could screw the transistor to the positive battery terminal and have it dump
the heat into the battery.

Advantages:
- higher shunting current possible
- it could double as a cell heater for winter charging (but the currents of all
the shunts in the system would have to match closely) when fed from the
charger
- less component count

Disadvantages:
- current calibration step required
- possible thermal coefficients issues (the Vgs / Rdson curve)
- DAC or PWM (and a low pass filter) required from the MCU
- TO220 case component possibly more expensive than SMT

The calibration could be a feature of the control unit.

2. Use optical link in the daisy chain setup

Your project used transoptors connected with cables.
How about replacing the cables with a ray of light?

Example:

tefnet.pl tmp filip optical_daisy_chain.png
(please replace spaces with slashes)

Batteries from GBS like GBS-LFMP60AH
have a cool feature - they have bumps and corresponding holes on sides of their
casings so that when you make a pack out of them then they are nicely aligned.

This means that if we put the pack together then we could just have diodes and
phototransistors on adjacent modules' sides and just shine from one module
to another. It should be quite reliabe on such a short distance, especially
with short tubes mounted on photo elements (to narrow down the angles).

We would have to have mounting points for both phototransistor and
diode on each side so that we could link them disregarding orientation.

The only problem is joining ends of battery strings - we could go
back to wire there or use something like toslink (2 or 3 pieces
should not drive the cost up very much).

Your battery pack would not gain much from this setup
(parallel-series combination), but I plan
to have two or three long strings of batteries in series and
this could work out nicely.

Advantages:
- less wiring
- less connectors
- vibration/time wear resistant
- easy "loss of link" debugging - just look at your
pack with a camera - IR will show up as white
- better EMI resistance

Disadvantages:
- possibility of interferences between links
- better battery alignment required
- slightly higher power usage (IR diode vs transoptor diode)
- communication might be slower
- IR diode and photo transistor combo might be slightly more expensive
than a transoptor
- better electrical isolation

3. Use optical link in a star configuration

We could put an IR diode and an integrated IR receiver
on each module. Let's say we'd emit 26kHz with the diode and receive 40kHz with the receiver
to reduce interferences between sending and receiving sides.

Then we could have one additional module in the battery box which would emit
40kHz with an IR diode and receive 26kHz with a receiver.

IR protocols like RC5 seem very robust (more than 10 meters with the daylight),
so communicating over 1m in a closed box should be trivial.

Advantages:
- no wiring
- no connectors
- vibration/time wear resistant
- better EMI resistance
- module connectivity does not affect other modules
- easy "loss of link" debugging
- asynchronous alarms from the modules with a good IR protocol
- perfect electrical isolation

Disadvantages:
- needs a bit of space over batteries for the light to pass
- higher cost of an IR diode and a receiver (compared to a transoptor)

So, what do you think of these?

Also a question - the battery terminals visible in post #43
look like they were reinforced with something like tubular rivets.
Can you share some details on this?

[filip]

And one more thing - I have developed an MCU (attiny) based module for cars
which communicated with a main board over a 9600bps RS232 (TTL levels).

I had used the internal RC oscillator to clock the MCUs and it resulted in a failure - when the temperatures outside dropped below around 0 degrees C, I was unable to communicate with some of the modules, because the RC clock
drifted too much and the main unit could not understand RS232 frames
anymore.

I had to come up with a second revision of the module with a crystal clock.

Your design seems to use an internal oscillator - do you have any precaution worked out for this issue?

[harlequin2]

First off, you can't use a fet as a load without some form of stabilisation - simply applying some voltage to the gate results in a completely unknown and quite unstable current flowing. "Calibration" as you suggested does not work, it is simply too unstable to be even thought about.

I did experiment with using photo-emitters and receivers in lieu of wires and optocouplers, but have not been able to obtain reliable results and I wanted a working bms in my car, so that idea has been temporarily shelved. One of these days I will re-visit it.
Item 3 - I don't understand how the addressing might work.

No rivets used on the pcbs, I think you are looking at some solder on the plate dthrough holes.
The internal oscillator in the PIC is +- 2% from 0 to 60 deg C and only +- 5 % down to -40 deg, so its much better than the AVR R/C oscillator. It is stable enough for the RS232 to work over that temp range.

[filip]

Originally Posted by harlequin2

First off, you can't use a fet as a load without some form of stabilisation - simply applying some voltage to the gate results in a completely unknown and quite unstable current flowing. "Calibration" as you suggested does not work, it is simply too unstable to be even thought about.

And a feedback loop would kill the component count gain, so I guess the idea goes down the toilet.

Originally Posted by harlequin2

Item 3 - I don't understand how the addressing might work.

We start with assigning a one or two byte integer to each board as an address and then query them one by one in a loop (M - battery module, C - main controller):

[...]
C: battery no 27, report status
M27: voltage is 4.18V, temperature is 28C, shunt is off
C: battery no 28, report status
M28: voltage is 4.21V, temperature is 28C, shunt is on
[...]

We need a kind of a board -> battery location mapping (to know which cell actually has the problem) anyway.

Address could be assigned over IR during an initial setup phase (a new module would have to be introduced face-to-face to the main controller) and saved in the battery module EEPROM.

Originally Posted by harlequin2

The internal oscillator in the PIC is +- 2% from 0 to 60 deg C and only +- 5 % down to -40 deg, so its much better than the AVR R/C oscillator. It is stable enough for the RS232 to work over that temp range.

That explains a lot .

Thanks for the feedback on the ideas.

[harlequin2]

Originally Posted by filip

We start with assigning a one or two byte integer to each board as an address and then query them one by one in a loop (M - battery module, C - main controller):

Yes, that "assigning" might be the difficult part. You might be able to do it by having a jumper on each board to control the power - the controller would assign the next vacant address to the next module to respond and you would control that by powering them up via the jumper, one at a time. You'd need to make a map. The modules would need to store their own addresses in eeprom.
With the wired system, the connection order determines the address. There is no need to store any addresses and all modules are identical, its just the order in the daisy chain that determines the address.

Anyway, keep on thinking; good, new ideas are always welcome!

[filip]

Originally Posted by harlequin2

Yes, that "assigning" might be the difficult part. You might be able to do it by having a jumper on each board to control the power - the controller would assign the next vacant address to the next module to respond and you would control that by powering them up via the jumper, one at a time.

I'd rather avoid such delicate mechanical connectors if possible - maybe an 'address assign mode' jumper would be better - it wouldn't fail when using the car, because it wouldn't be there.

Couldn't we just use the ISP connector to set up the addresses?

Another possibility:

When programming the cell modules the primary controller unit IR diode is covered with something similar to a pen cap (or disabled by software) and another one is hooked up with a wire. The second IR diode works with much less current (let's say 2% of the current of the main diode) and is enclosed in a tube so that you can put this tube over any cell module's IR receiver and talk just to this one.