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 2172 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.