Switched ADC BMS

[skr]

Here is the kicad source + production files for a tiny adapter board to fit at the end of your BMS design to accomodate a 17 pin phoenix pluggable terminal + has 0603 footprints for extra inline fuses or 0R. Maybe someone finds it useful. Edited to update borked silkscreen order

[skr]

I finally got some time to hand assemble some bootleg copies for my scooter. Flashed both bootloader and fw ok, now slowly vibe coding fw for controller. My previous assumption of having uninterrupted 12V source on the scooter turned out to be wrong, so HV-12V dcdc will have to be added, no biggie, I already had provisions in place, but not sure what Iq will be on a relatively small battery which may see sporadic use.

The pins GND and 12V must be connected to a permanent 12V source in order to ensure correct operation. In other words, don't connect 12V for example to your cars ignition 12V that is interrupted whenever you stop the car.

Which lead me to wonder- what would the outcome be if 12V gets interrupted? Can the mux end up in a weird state and bork the cells? I must admit I have not carefully studied the schematic to probably come up with an answer myself.

[johu]

Which lead me to wonder- what would the outcome be if 12V gets interrupted?

Yeah this needs clarifying. The BMS uses the STM32 NVRAM to store some long term process values, most importantly SoH. If you don't care about the latter you might as well interrupt the supply completely.

[skr]

Johu -I wanted to ask - is there a reason why BMS waits for IDLE status to start balancing? I'd like to balance during CV phase as well. Any gotchas why not to do it? Theorethically now if I set idle current to 3.2A - a bit above CV current, it should enter idle and do balancing, haven't tried yet.
I have a large 200mV delta I need to tackle so now thinking of how to do it best, without resorting to wallwart external power every time I get a big delta.
I have added 3 more params and logic to the code which may be useful for others, maybe worth implementing on mainline?
Edit - or maybe idlewait was already there

image.png (8.59 KiB) Viewed 2557 times

[skr]

Another interesting thing, I kinda mostly did not touch BMS core functions, but during my first full charge cycle I noticed that Web tool started displaying borked voltages from between the modules.
Below is LLM summary:
Battery voltage values displayed as negative (-4063mV) on BMS nodes due to 13-bit CAN message fields misinterpreting high voltage values as signed. Fixed by adding a correction function that runs every voltage reading cycle to identify negative values in the range (-4096 to 0) and convert them back to positive by adding 8192.

The issue occurs naturally when battery cell voltages exceed 4096mV, particularly affecting values between 4097-4200mV.
The issue stems from how 13-bit voltage values are handled in CAN message communication:
Voltage values around 4100mV require 13 bits to represent (2^12 = 4096)
When bit 12 (the most significant bit) is set, it's sometimes interpreted as a sign bit
This causes values like 4128mV to be misinterpreted as negative values (-4064mV)

[Proton]

@ johu, can I use the BMS to get the state of charge of the battery and bypass the ISA shunt?

[johu]

Yes that is the plan. Right now you'd need to connect a separate analog current sensor to the first board but I do plan to make this CAN mappable

[skr]

So I ended up creating all sorts of voltage corrections, slave umax/umin caching, more extreme tresholds, special cases for outliers and whatnot for handling signed/unsigned value handling for voltages above 4100mV, to still have balancing not commencing properly on slave modules given that every other value may have been negative, until I found DCAN_SIGNED build flag. Now applied correction for only current handling and balancing chooches finally as intended. Imo worth a look at the mainline code, as far as I understand BMS is not handling any external canmaps unlike inverter, so this should be of no concern for end users, or I am wrong here? This bodge doesn't address params with negative values being stored as large positive numbers tho :/

[johu]

I have added explicit 2 ms dead time generation: https://github.com/jsphuebner/FlyingAdc ... 2483437d2c

The sequence is now:
t=0 ms - turn off mux
t=2 ms - switch in selected channel
t=4 ms - start ADC
After 21 ms the ADC is done converting and after 25 ms the ReadCellVoltages() task reads the result and requests the next mux change

So I ended up creating all sorts of voltage corrections, slave umax/umin caching, more extreme tresholds, special cases for outliers and whatnot for handling signed/unsigned value handling for voltages above 4100mV, to still have balancing not commencing properly on slave modules given that every other value may have been negative

uuh, that sounds ugly but I don't quite understand what is going wrong? Are cell voltages not stable?

[skr]

uuh, that sounds ugly but I don't quite understand what is going wrong? Are cell voltages not stable?

Please see post viewtopic.php?p=83070#p83070
Now 2 slaves are running DCAN_SIGNED=0, master is DCAN_SIGNED=1, need to fix it sometime, but otherwise over 4.1V I would get garbage for slave uavg target

[johu]

Thanks! Damn that's silly. Must have introduced it when switching to CAN_SIGNED. Will give more space to the values

[skr]

I was correcting the values on my end with DCAN_SIGNED, but at some point it was still failing. Without DCAN_SIGNED I would need to correct current and make sure not to touch negative params from web interface.

[johu]

Fixed it: https://github.com/jsphuebner/FlyingAdc ... ec23c2be29

Please test

[skr]

Thank you, will do, however I don't know when, this month probably. I am now not balancing, just letting the bike sit at idle consuming 250mA @36S and charging 3 weak cells with 100-300mA. Given the gigantic delta and size of MEB module- not sure if it will take days or weeks before I do another charge cycle, evenmoreso above 4.1

Edit:
Updated my fork to reflect latest commits from you, rolled back some of my own bloat. Works ok so far, had an issue hunting down why a task is not working for my VX1 comms only to find that Max_tasks = 4, from libopeninv https://github.com/skrubis/FlyingAdcBms ... 5482926196

So far working ok.

[skr]

Just checking in - so far the system has been working as intended, however I am contemplating maybe removing the series fuses to increase the balancing current flow. Now the battery sits at 30ish mV delta with maybe half a millivolt improvement a day, not improving much overall. My batteries come from trash, so not sure if the actual self discharge of the weak cells isn't > than that what the BMS can supply. The BMS and ESP now sits on external power supply balancing 24/7, the bike sees usage every odd day and cells sitting at 3900ish mV during this time.

[johu]

Hmm, interesting. How many Ah did you say they are?
You can also try playing with R23 and R28, down to completely bridging them. Then only the 10R (mostly 2 of them on most channels) inline resistors limit the current.

I let my LFP pack sit for one week and it improved from 55 to 20 mV. Those are just maybe 20-30 Ah but then again it's the flat LFP curve.

[Proton]

@johu

On previous version for BMS I was getting 2 digits for SOC. now with the new boards I am getting 3 digits. is that something you changed on the latest code? 0.26R

474 I am guessing is 47.4%?

[skr]

My full-ish discharges and integrated amp hours from bike MC against meb soc curve puts them around 148-155Ah depending on what phase the moon is at, so probably it is just a matter of capacity in question. Getting rid of 300mV delta took 2+ weeks when discharging all pack @50ish W and charging the weak cells with 200ish mA.
Will try playing with those resistors the next time I open the bike up, thank you for the advice!

I read your thread about giving up inverter projects and thought, that if you continue bms efforts - the same bms but on a din rail could gain some traction in ESS crowds if it speaks the various inverter/mppt protocols out there. I have a victron 48 5000 I need to set up this summer so probably forcing my spare boards to talk to it eventually, but I see this bringing more value to the more gatekept inverters with HV packs and no dumping price point chinese alternatives like 24/48V systems have

[johu]

On previous version for BMS I was getting 2 digits for SOC. now with the new boards I am getting 3 digits. is that something you changed on the latest code? 0.26R

Yeah that was a sort of recent change to show more resolution.

I read your thread about giving up inverter projects and thought, that if you continue bms efforts - the same bms but on a din rail could gain some traction in ESS crowds if it speaks the various inverter/mppt protocols out there. I have a victron 48 5000 I need to set up this summer so probably forcing my spare boards to talk to it eventually, but I see this bringing more value to the more gatekept inverters with HV packs and no dumping price point chinese alternatives like 24/48V systems have

That sounds very sensible. So making it DIN-rail suitable means changing dimensions and making the all IO side-accessible. I guess with the right parts the latter is already fulfilled.
CAN Map profiles would be an easy addition. One thing I noticed with the Sungrow is that it doesn't really like the additional "internal" BMS CAN traffic. It doesn't fault out and it does sort of work but drops power from time to time. I've tried higher CAN ids but that didn't help. Maybe a slower cycle time would help. Will play with that.

[Proton]

Yeah that was a sort of recent change to show more resolution.

Can I downgrade the v2.4 BMS version or that is not recommended? Even if I can make it show 47.4% it would not look good on the screen and is not needed.

[johu]

Can I downgrade the v2.4 BMS version or that is not recommended? Even if I can make it show 47.4% it would not look good on the screen and is not needed.

No way, pre-0.26 has to little dead time and will fry the FETs for sure. You can add a new custom mapping for SoC or change your display software to divide by 10

[Proton]

No way, pre-0.26 has to little dead time and will fry the FETs for sure. You can add a new custom mapping for SoC or change your display software to divide by 10

I tried divided by 10. maybe I need to divide by 100 just in case you are sending 4 digits.
Just delete and recreate the mapping or do I need to do anything special to display 2 digits?

[skr]

I am thinking more of larger storage systems, 1MW solar park with some, say LTO/LFP, ESS probably outsells all currently sold BMSes. There's plethora of 48V pretty nice BMSes out there, but not too many options when you want to have say 600V LTO pack.

Probably need to take a list of currently certified inverters for such cases and start with lowest hanging fruits. Most integrators probably choose a box from China, some want more flexibility once they realize the chinese box is half working and shipped with fw 0 with no later improvements.
For that probably much higher balancing currents are needed and rs485/modbus, but that would probably be a problem for esp32 to solve (can>whatever translation). A friend is setting up solar parks and told me it's painful with current BMS/BMU options out there, imo a big market opportunity for you, if you have the energy to go after it.

One thing I noticed with the Sungrow is that it doesn't really like the additional "internal" BMS CAN traffic. It doesn't fault out and it does sort of work but drops power from time to time. I've tried higher CAN ids but that didn't help. Maybe a slower cycle time would help. Will play with that.

Was it with Web tool connected or not?
Here is approx 10s without web tool:

Here with web tool:

With web tool it gets a bit more spammy on the bus.
I did try rate limiting the bms messages down to 1 second updates and it wasn't bad.
For ESS you would probably also want to send cell voltages (either 3 messages packing all cells or just delta update on any changes), now the esp web tool reinits the driver on node switch to interrogate each bms in an inefficient manner, packing cell data in a, say 1s PDO update rate cycle would probably be cool, as everyone wants graphs and whatnot.

[Proton]

I divided by 1000 and it works. I tried before 10 and 100 but I had to add another 0.