ESP8285 parallel cell based BMS

completelycharged

completelycharged

Active member
Joined
Mar 7, 2018
Messages
1,083
Having looked at a lot of BMS systems I thought I would have a go at createing one with a difference.

My setup is going to be 33s8p modules (18kWh at 72V) and each of the 8p cells will have a separate balancing unit.

My plan is to use ESP8285 (2) to monitor and balance individual parallel sets of cells and have them powered from the cells they are monitoring and communicate via wireless so there is no wiring from or between cells. Also the whole thing then becomes completely scalable because you just add one ESP8285 for each parallel set of cells that you have.

I have part of the code written and tested so far and the majority of the electronics sorted in my mind (some parts on orde) with the view that each BMS point will cost less than 5 per point and provide 1 second resulution data to allow current spikes to be profiled and analysed for battery condition and failure detection.

In my case I aim to have 33 units, one attached and mounted on each parallel set of cells, talking wireless back to my computer with no wires trailing around.

Are there any comparable cheap/reasonable BMS systems that are wireless and cell based with good lessons to learn from ?
 
33s? Thats above 100V so are you sure= Or do you use a 2.3V cells?

There are not many BMS system that are cheap and do the job good enough if you ask me. The Slave approach make it so much more complicated in terms of software :) But your idea is a simple and working one.
 
. daromer said:
33s? Thats above 100V so are you sure= Or do you use a 2.3V cells?

There are not many BMS system that are cheap and do the job good enough if you ask me. The Slave approach make it so much more complicated in terms of software :) But your idea is a simple and working one.
Click to expand...

33s LTO, they are 40Ah cells at 2.3V so I get the 72V range that will work with 3 UPS units I have bought second hand.
72V UPS units are cheaper than 48V on the 2nd hand market. I would have liked to have gone 192V (really, really cheap UPS units) but could not justify all the cells to do it. Plus I intend on taking half the setup away on breaks to the middle of nowhere and I can then take a third of the overall capacity with me..

Trying to keep the hardware minimal and let the software do all the tricks.
 
Ah ok LTO :)
 
So, for the code.. This is the code outline for the unti that is attached to the cell.

Basically, collects data every second from the ADC and tags this with an index and seconds since start (to use to link the data to other cells).

Every minute it will then turn the wifi on, hook up to the local wifi and send the previous block of data as a message and then wait for any incomming responce for 3 seconds before turning the wifi off again. Will reduce the 3 seconds after somt other testing.

By not having all 33+ units shouting for the wifi all the time this method should scale well and the units should end up spacing themselves out from collisions.

Still to add in the full sleep mode and more error handling....
Slight variation on this will be used for the switches (possibly ADC amplifier and shunt to get current flows).

Code: 
local myid = 'm01c01'
local myin = 'm01c01a'
local adv = 0
local tn = 0
local qin = 0
local qout = 0
local adq = {}

tmr.create():alarm(1000, 1, function (myt)
 qin = qin + 1
 tn = tmr.time()
 adv = adc.read(0)
 table.insert(adq, {qin, tn, adv})
 if (qin - qout) > 100 then
  table.remove(adq,1)
  qout = qout + 1
 end
end)

cfg = {}
cfg.ssid = 'yourssid'
cfg.pwd = 'yourpassword'
cfg.save = false
cfg.auto = true

wifi.setmode(wifi.STATION)
wifi.sta.sethostname(myid)
wifi.sta.config(cfg)

mymqtt = mqtt.Client(myid, 120, "mqttusername", "mqttpassword")

wifi.eventmon.register(wifi.eventmon.STA_GOT_IP, function(T)
 mymqtt:connect("192.168.0.33", 1883, 0, function(T)
  mymqtt:subscribe(myin,0,function(mqs)
   mqttsend()
  end)
 end)
end)

mymqtt:on('message', function(mqc,topic,msg)
--Switch stuff on and off
end)

function mqttsend()
 if qin > qout then
  mso = sjson.encode(adq)
  for k in pairs(adq) do
   adq[k] = nil
  end
  qout = qin
  mymqtt:publish(myid,mso,0,0, function(mqt)
   tmr.create():alarm(3000, 0, function (mqw)
    mymqtt:close()
    wifioff()
   end)
  end)
 end
end

function wifioff()
 wifi.setmode(wifi.NULLMODE)
end

function wifion()
 wifi.setmode(wifi.STATION)
 wifi.sta.sethostname(myid)
 wifi.sta.config(cfg)
end

tmr.create():alarm(60000, 1, function (pollt)
 wifion()
end)
 
completelycharged said:
My plan is to use ESP8285 (2) to monitor and balance individual parallel sets of cells and have them powered from the cells they are monitoring and communicate via wireless so there is no wiring from or between cells.
Click to expand...

Bummer the ESP8285 has max voltage of 3.6VDC. For Lifepo4 it would be great though.
 
noaano said:
completelycharged said:
My plan is to use ESP8285 (2) to monitor and balance individual parallel sets of cells and have them powered from the cells they are monitoring and communicate via wireless so there is no wiring from or between cells.
Click to expand...

Bummer the ESP8285 has max voltage of 3.6VDC. For Lifepo4 it would be great though.
Click to expand...

Just use a couple of resistors as a simple divider for the ADC input. The power supply that I am going to use is just a small 0.99 buck, boost that will cope with 1.2V to 6V. Will work with all LTO and LiPo cells.
 
completelycharged said:
Just use a couple of resistors as a simple divider for the ADC input. The power supply that I am going to use is just a small 0.99 buck, boost that will cope with 1.2V to 6V. Will work with all LTO and LiPo cells.
Click to expand...

Sounds good. Care to share the PSU model?

Resistor should not affect the precision too much, andyou canpick a balanced pair to start with. Its only a 10bit ADC though, so not super accurate but still good enough? Interesting to hear how it works.

Same idea could be done with Raspi + CellLog8 + USB + wifi for each 8 cells, with high accuracy and reasonable cost. More than your idea sure, but not that much.
 
Hi @completelycharged i have the same idea on my TODO list for the power wall. Waiting for china stuff :D
My plan is that the server will answer to each ESP with a target voltage and to add also a load controlled by the ESP to make the balance.
 
Bit of an update - test setup with 12 ESP nodesactive at 30 second reporting interval (simulating wifi activity of 24s BMS) works reasonably well at the moment - few more adjustments...

Power draw for 11 battery points (the same as an 11s configuration) in the test setup works out to20Wh per day and should be able to reduce that a lot further with the full sleep mode and changing the active time for the wifi.

2W 3.9Ohm resistors and some MOSFET are on order for the bypass balancing load and control.

With an average expected balancing voltage of 2.25V (LTO) and a parallel capacity of 180Wh (2kWh per pack at 24V as 11s2p) for a 10% imbalance (18Wh) the bypass should take around 14 hours to balance through a 3.9Ohm resistor.

The difference with the approach that I am taking is that the balancing can be active for hours at a time (not just at top or bottom of the cell cycle) to bring the overall energy balance of the cells in line so the upper and lower active cell voltage is within the planned charge/discharge range (approx 1.95V to 2.5V with a tollerance as there is no need to keep the cells exactly equal).

Current costs
2.50 per ESP8285
1.15 per 0.8-6V buck boost to 3.3V
0.20 per 3.9 Ohm resistor
0.20 per PCB
0.11 per MOSFET

Total 4.16 per parallel battery point (per s)

Once the code and electronics are sorted will get a custom PCB done which will allow cheaper components to be used and reduce the overall size.

Planning to have a hot plug (15 pin D-Sub) balancing unit to start with for testing - anyone have any experience on how fast a parallelset of cells can drift in a pack ?
 
are you satisfied with accuracy of the esp. of course the esps have to be calibrated against each other, but 10bit isnt very precise...

best
karl
 
10bit against 3.3V is 3mV per bit and +/- say 5mV an accuracy of 10mV is sufficient.

One of the differences is to match the voltage provile over a period of time and particularly during a large change in current flow as this will amplify the voltage difference for a give cell charge state. Conside the voltage profile like a knee at the lower 5% charge state and this is amplified significantly at lower states of charge with a higher current flow.

My goal is not to try and balance to within 10mV of 2.7V (LTO full charge equivalent of 4.2V) but rather within around 50mV of my set points because if you are running cells 10% to 90% then the upper and lower tollerances give some additional volt range to use or not, so accuracy can give a little.

Also, the approximate 0-3.3V range of the ADC with my expected voltage range of around 1.7V to 2.7V this will fall outside the upper and lower non linear segments of the ADC.
 
Bit more of an update, the buck/boost units I have will not successfully power up an ESP8285 below 1.5V input on all instances. The initial startup surge from the ESP pulls the voltage down and hangs the device/boost state. This may be partly an issue with the startup voltage profile of my PSU rather than the buck/boost (without hooking the scope up and a bit more analysis). The reason seems to be that once the EPS and boost is powered with a low voltage when the voltage is increased further the output voltage from the boots is still held in a low state that prevents the boost from recovering/starting properly (guessing the boost oscillator is not starting) and the current draw increases to 1.7A when the input is increased to 1.4V before dropping back normally this should not cause any issues unless powering the devices from a very low starting point.... Normally I will not expect to see 1.5V.... but an interesting voltage range to avoid...

Had 12 untis runnign for a few hours yesterday and then had 6 units running for 8 hours today via the buck/boosts. Two of the units restarted (no real issue as the data is taggeg) and suspect this was due to the poor quality plugboard leads I have - the pins had a very thin layer partly insulating them !!!
 
This is still on the to-do list and been pushed back a bit as I am have "borrowed" (switching remote wifi mesh units on/off) a few of the ESP units for a different project.

Update is that I plan to power them from a step down buck from 2 cells rather than a single cell step up boost. The reasoning is that the startup process is a lot more reliable as the voltage builds quicker the ESP is less likely to enter a locked up state. Major issue is pricing as the small boost units are multiples more than a comparable buck...

Cell 1 + Cell 2 = power ESP1
Cell 2 + Cell 3 = power ESP2
Cell 3 + Cell 4 = power ESP3
......
The reasoning for this is the ADC input runs off the -ve line so each ESP has to have the -ve line connected to each cell(s) that is is going to measure. This would also allow each ESP to be boxed separately, very much like the single cell balancing units that are sold appart from these will use WiFi rather than a can/single wire network.

The last cell would then use a boost unit or buck and voltage divide.. still thinking through the last cell because the power drain has to be balanced out as well ideally....
 
I started down this rabbit hole when I was looking at using an APC UPS with 384 volt battery pack that required ~160 LTO cells in series.

I planned to use the ESP-12F ESP8266modules, using thebuilt in WiFi for communication.

Due to the large number of cell modules required and the possibility of overwhelming an AP I planned to use scheduled reporting and check-in back to a central web server, likely an RPi.

The plan was to have each module connect every ~60 seconds,report it's current voltage to the central server, read the average cell voltage as reported by the central server then decide if the unit needed to balance with other cells or not. Once this communication was complete the wireless would shut down to conserve power and network noise.

Locally the unit would monitor the cell more frequently so that it would know if it was charging/discharging to help with this decision, and go into bypass if the cell had reached maximum charge voltage

The central server would be responsible for alerts: pack voltage high or low, individual cells high or low, cells not reporting, etc.

As yet I haven't progressed past early planning stages.

I am interested to see how yours progresses.
 
Add my 2 cents here:

Why not just use an opto-isolator to do the communication link?
You could even use the opto to move the data from the pack mcu to a transmit mcu on the same pack, then use wire directly from transmitting mcu to mcu, and those are powered by the buss.
Opto's aren't super fast, I know. But we don't need to have constant updates 1000's of times a second. Just send burst updates every few 10ms or so.
 
Korishan said:
Add my 2 cents here:

Why not just use an opto-isolator to do the communication link?
You could even use the opto to move the data from the pack mcu to a transmit mcu on the same pack, then use wire directly from transmitting mcu to mcu, and those are powered by the buss.
Opto's aren't super fast, I know. But we don't need to have constant updates 1000's of times a second. Just send burst updates every few 10ms or so.
Click to expand...

You can buy such a device for just a few dollars.
 
Well then you are in the path of opto isolated i2c communication between slave on cell basis and central unit... no more wifi but more complexity.

Thats why i gave up that path ;-)

Regatds
Karl
 
You must log in or register to reply here.
Back
Top