openinverter forum

Well guys and girls, I simply cannot stop searching for the perfect BMS solution. The daisy chain version was already pretty cool in terms of cost but usability wasn't too great yet.

Wiki page: https://openinverter.org/wiki/16-cell_BMS

So here is another idea:
- Use a high performance Sigma/Delta ADC (MCP3421)
- The ADC is floating with its own DC-DC power supply
- Construct a discrete multiplexer that can connect a given cell to the ADC
- The mux is inherently safe to not create short circuits using 74 series logic
- The active cell can also be charged from the 200mA DC-DC converter that also powers the ADC, so we have a sort of low power active balancing
- Everything is implemented in discrete logic that does not require flashing firmware
- ADC, MUX and balancing switch all speak I2C
- multiple modules can be cascaded and one of them gets a master daughter board

I'm still in the schematic stage. Currently trading off the number of channels. The more channels you have, the higher voltage mosfets are needed increasing cost. The less channels you have the less the cost of the ADC other central components is divided up. So there is a sweat spot somewhere in between. The presented schematic displays 26 channels but I do consider dropping back to 16. What do you think is most practical?

The ADC allows trading off between speed and accuracy. At best it takes 4 samples per second at 18-bit accuracy or like 100 per sec (if I remember correctly) at 12 bits. So for SoC estimation the high accuracy mode can be used and during normal operation the high speed mode.

Software pipeline:

Features implemented:

1. CAN bootloader for SW updates
2. CAN communication via Daves OI CAN tool
3. Reading of all 16 cell voltages, obtainable via CAN SDO
4. Calculation of min/max/average/total/delta
5. Addressing scheme for chaining multiple modules
6. Communication between multiple modules (to be extended) (min/max/avg/tempmin/tempmax periodically sent via CAN)
7. Crude balancing scheme (using bleeding and charging) trying to match cell voltages at whichever voltage they are at
8. Current sensing with Coulomb counting
9. Temperature measurement, only supported sensor is that from Nissan Leaf. More could be ported from inverter
10. Configurable SoC lookup points
11. Configurable SoC dependent charge current lookup points
12. Configurable min/max cell voltage configurable
13. 3 balancing schemes: dissipative/additive, only dissipative, only additive (or none at all)
14. Keep BMS running even with car shut off if a lot of balancing is needed (on ESS applications the BMS runs 24/7 anyway)

Features to add

1. Limit current depending on cell temperatures
2. Limit charge current depending on length of charging session (seen some OEM cars do that)
3. Calculate "state of energy" i.e. % of kWh left vs. % of Ah left
4. Add diagnostics: cell reversed polarity, cell over voltage, cell not connected, cell poor connection (compare voltage with bleed resistor on/off), ADC comm error, balancer comm error, comm error with sub module(s) etc.
5. Add more temperature sensors
6. Incrementally estimate total capacity by taking a SoC estimate, then after a good deal of charge/discharge take another SoC estimate and see how much energy has flown through the current sensor since the first estimate. IIR filter with last capacity estimation.
7. Implement top balancing e.g. by remembering the voltages at charge end, then estimate how much charge should be added/subtracted from each cell so that they end up equal at the top end. That way balancing can take place at any voltage.
8. Store estimates etc. before shutting down

Optimizations:

1. Try using timer to bitbang i2c (currently gpio operations are used with delays...)
2. Slow down sampling rate e.g. when no current is flowing to draw less energy from cells
3. Improve balancing scheme so that more time is spent balancing cells that need it most

I've been through a myriad of ideas like this myself.
Unfortunately my eyes aren't what they used to be and I find the schematics a bit hard to read. but I get the gist and it does have legs.

I'd suggest starting smaller, say 12 or 16. There will likely be a practical limit to how many wires you want to bring together in one place.
I'd give it a go for sure.

Couple of questions.

Why wouldn't you just use a ADUM1251 to isolate-bridge the I2C to the MCP3421?

I haven't worked through the channel selection logic. Is there a dead-time between channel switching?

Good questions!

mackoffgrid wrote: ↑Fri Apr 01, 2022 10:35 pm Why wouldn't you just use a ADUM1251 to isolate-bridge the I2C to the MCP3421?

ADUMs are super expensive, but the main reason currently is, that I constructed some differential I2C (not in schematic) which needs separate TX/RX lines. The shown isolators are very cheap on JLCPCB. But will rework that anyway.

mackoffgrid wrote: ↑Fri Apr 01, 2022 10:35 pm I haven't worked through the channel selection logic. Is there a dead-time between channel switching?

No, just making sure no two channels on the positive or negative rail can be on at the same time.
Attached the KiCAD files so you see clearer

Finally got my Kicad updated to 6.
Much clearer thankyou.

Having done flying capacitor designs before, well switched capacitor. Thank goodness for JLC, all those little parts add up very quickly .

Do you think better than 12 bit res will give you a better SOC calculation?

mackoffgrid wrote: ↑Tue Apr 05, 2022 8:48 pm Do you think better than 12 bit res will give you a better SOC calculation?

Maybe not so much for NMC 3V-4.2V cells but certainly for LFP.

I think I will drop the number of channels back down to 16 for the first protoype.

Started layouting before actually finishing the schematic to see some progress.
Dropped channels to 16 and worked on the logic a bit more. Now a simple 0-15 4-bit word will select the channel and the msb will select whether any channel is connected at all.

Now I'm spending some thoughts on

• How can I address everything via I2C, including my custom logic?
• Should I come up with some polarity unification?
  Right now when you connect cell 0 and cell 1 the ADC sees a positive voltage, when you connect cell 1 and 2 it sees a negative voltage. Makes balancing harder, the ADC doesn't actually care as it's differential
• Should I supply the logic from the cells instead of adding another DC/DC converter?
  • Downside 1: makes it harder to use because you always need to connect voltage to input 16
  • Downside 2: cells are being slightly drained
  • Upside: cheaper and can be populated by JLC
• Besides the ability to slightly charge low cells via the ADCs DC-DC converter should I also add the ability to drain high cells with a resistor?

Also thinking about the best way to interconnect the modules. So far I considered RJ45 jacks and Ethernet cable but you could argue that's not vibration proof enough for EV use.

For the perennial cheapskates among us, I ask:

How much you figure it'll cost for a 100s BMS?

100S is mean, lets make it 96 or 6 boards
If I release it open my guess is that one board will be between 20-30€ at JLC plus say 50 for the processor board. So roughly 200€

johu wrote: ↑Fri Apr 22, 2022 12:26 am100S is mean, lets make it 96 or 6 boards

Okay fine.

If I release it open my guess is that one board will be between 20-30€ at JLC plus say 50 for the processor board. So roughly 200€

That'd be the cheapest BMS on the market, and, probably at the upper end of affordability for the cheap builders (maybe $500 would be okay). Above that, I'm pretty sure most would just skip it.

Rule of thumb seems to be a BMS is $1000. So, leaves you a lot of ceiling to make it worth your while to sell in the shop.

I'd say RJ45 is worth a try. Certainly you can get very high quality ethernet cables by spending a bit more on them, and RJ45 is a spring contact connector with positive locking (of sorts), I think it should be able to maintain contact and to not work loose.

Balancing resistors probably make sense as it allows people to use cheaper, older batteries that need more balancing.

MattsAwesomeStuff wrote: ↑Fri Apr 22, 2022 1:48 am That'd be the cheapest BMS on the market, and, probably at the upper end of affordability for the cheap builders (maybe $500 would be okay). Above that, I'm pretty sure most would just skip it.

Rule of thumb seems to be a BMS is $1000. So, leaves you a lot of ceiling to make it worth your while to sell in the shop.

Certainly if you make it yourself. You could argue it's just a set of PCBs with no enclosure, comes with no warranties or 1:1 support. I'd probably sell for a similar price as you say, like 100€ per 16 cells. We'll see, lets get it working first

celeron55 wrote: ↑Fri Apr 22, 2022 6:02 am I'd say RJ45 is worth a try. Certainly you can get very high quality ethernet cables by spending a bit more on them, and RJ45 is a spring contact connector with positive locking (of sorts), I think it should be able to maintain contact and to not work loose.

Balancing resistors probably make sense as it allows people to use cheaper, older batteries that need more balancing.

Will do. In fact I used RJ45 in Polo and it never caused a problem

I have made the SPI/I2C signals differential with some RS485 transceivers but now thinking that might not be necessary if they are in shielded Ethernet cable and twisted with GND. So I think I'll remove that for now as it comes with its own set of challenges

Just put some on order.

I've added an extra serial daisy chain for enabling mux control or ADC control on a respective board. Mux, ADC and the 4-channel port extender all run via I2C and I have made the SDA signal differential with a CAN transceiver.

The board contains no microcontroller just all 74 series logic. Will be testing it with my analog discovery first.

And here's the real thing.
So many mistakes!

• Wrong pinout for 5V reg
• DC-DC for mux not connected to supply voltage
• Wrong supply polarity on two logic ICs
• Wrong connection of incrementer
• Isolated I2C not really thought through
• Reset/Set inputs not tied high

Apart from that I was able to select channels on the multiplexer. Will see if I can work around all mistakes and do more testing

Tested a little more, mainly played with the balancing H-bridge and the ADC. The ADC has 18 bits resolution at best. At that resolution it still jitters a bit, I guess I should add an input capacitor. Otherwise linearity is really great. I calculated a division factor from code to voltage at 4200mV and got a 2000.3 mV reading at 2000 mV.
I found that for the second time in life I have made an eternal feedback loop on the I2C bus. Same as years ago when I connected 2 CAN transceiver back-to-back. I chose to make the SDA signal differential via a CAN transceiver and guess what? if you pull it low once, it stays low. So options I see are:

1. Use a specialized I2C isolator, scrap the differential signalling -> Makes the design less reliable and more expensive because I2C iso chips are not cheap
2. Use two separate twisted pairs for RX and TX -> not enough wires on Ethernet cable, would require separate wiring for power
3. Use two separate wires for RX and TX and run them through a buffer at each device -> how susceptible would this be to EMI on longer runs?
4. Put a controller on board and do CAN comms -> no, I want the devices to be HW only
5. Use a RS485 transceiver and run the output pin through the existing chip select chain

Any other ideas? requirements: uses TP Ethernet cable, does not require a local controller, works with I2C devices

C) NXP has PCA9605

That should work

Not easy to get a bidirectional open drain link like the SDA line on I2C to work over a diff pair. The moment you introduce active buffers you need to know which direction the data is flowing (which is why RS485 and CAN need separate Rx and Tx lines) and I2C master/slaves to not expose these control signals. If you post the relevant section of the schematic I'm happy to have a look though?

I'd try to keep the differential signalling. It gives better noise and common mode rejection and improved ESD robustness. If you do ditch the diff pair then I'd move to full 12V swing signalling to get the best chance of it working in the presence of noise.

Personally I'd put a small uController on there (AVR or even 8051 based). I assume your reluctance is based on reliability/bugs in software? If so these can be addressed to a large degree by keeping it simple (no bootloader, no c++, no/minimal interrupt use, good coding techniques, comprehensive testing ideally covering every decision path) and having a good watchdog implementation. Bear in mind the benefits of a uC in terms of comms robustness. On your current implementation could bit errors cause the wrong channels to be selected leading to erroneous readings? With a uC on there you can add checksums/CRCs to the comms and also have some degree of system monitoring to diagnose issues. It would also make it easy to add other features such as temperature monitoring. In terms of keeping it simple and low cost it would make sense to see if the internal RC oscillator would be accurate enough for comms (although you could always implement a clocked system similar to I2C if not) to avoid the need for a crystal.

The overall concept is similar to the monitoring system I built for my Lead Acid powered Scirocco 20 odd years ago.

That only had 16 channels total, giving a total of 192V from 12V modules (Optima YelloTops or BlueTops).

I used Omron DPDT relays, rated for "dry" switching (negligible current meeded to maintain contact integrity). No polarity issue and similar decoder logic eliminated the possibility of shorting adjacent blocks.

Only a quasi differential 12 bit ADC. I originally used a Burr Brown 1286, which allowed you to offset the negative input pin to anywhere in the input range, so that the 12 bit resolution could be concentrated above the knee voltage of the modules. That chip turned out to have an interesting problem where the bottom 4 bits were left shifting, rather than counting up in binary sequence and I changed to a pin compatible LT part. I later found out it was DC/DC converter noise causing the odd behavior, despite supply rail noise being within manufacturers spec.

A PIC16F84 drove a 2x16 line LCD to diplay total voltage and average, lowest and highest block voltages. My friend Lee Hart designed a system for his Lectric Leopard, a Renault LeCar (R5) converted from new by US Electricar Corp
(http://www.renault-5.net/usa_lectric.htm).
He used an off the shelf DVM with isolated data output and much higher current relays. He could use the output of the vehicles main DC/DC converter to assist a sagging block. This was so effective that it was only when he looked at the logs, that he could see that one of the surplus UPS modules was failing. http://sunrise-ev.com/balancerland/bala ... /balancer/

I love the sound of relay muxes, also some Agilent bench top multimeter could be equipped with these.
I haven't tried out the muxing yet, whether there will be shoot through or leakage of some kind. Maybe I shouldn't switch from channel to channel but insert a null-selection in between, deadtime so to speak.

I came up with an arbiter, I think it should work, given similar logic on the master side So when master channel is idle ("1") and slave (sub device in p.c.?) sends 0 the transmit enable of an RS485 transceiver will be enabled and receive enable turned off. That breaks the feedback loop. I have a return channel left on one oft the isolators, that's why I put it on the isolated side.

And early forum release:

So cool, can't wait to see this balance a few 18650s on a bench!

I"m so on board with this!
Once you've got connectors somewhat confidently placed, i'd love to contribute an enclosure design.

Currently working on the second iteration. Don't think I've changed connector positions so far

ltc 6820 is not espensisive 6€ protocolo ic2 bus master slave

anguicito wrote: ↑Sat Jul 16, 2022 7:06 pm ltc 6820 is not espensisive 6€ protocolo ic2 bus master slave

Seems to be SPI? Also 6€ is expensive when compared to the 0.3€ TwoPi devices