Flying ADC 16 channel BMS 96S test

[Proton]

it was easier to make a video to explain

[johu]

Wow, that is really weird stuff.
Now 3 things:
1. What happens on nodes 11 and up?
2. Have you daisy-chained the enable signal correctly? First ENA_IN to 12V, ENA_OUT to the next ENA_IN
3. Can you go to "Files" page and check for all files called ".json"? Open them and see if they contain a long list of parameters or look strange. If the latter, delete

[Proton]

also do you have the names or links for the connector you have on this picture for the BMS? i was not able to find them online and I do not like the ones I got.

Screenshot from 2025-01-26 12-40-58.png (130.76 KiB) Viewed 6430 times

[Proton]

Node 11 to 15 same thing. but let me go out and check again

edit:
I also disconnected the inverter can wires and same result

[Proton]

Enable out to enable in look good, and first enable in is connected to the same 12v all 6 boards are connected to. SO enable in on the first board gets 12v at the same time all 6 boards get power.

[johu]

ok check those json files. And remove all bin and zip files so you don't run out of memory

connector part numbers added to wiki https://openinverter.org/wiki/16-cell_BMS

[Proton]

I deleted the .zip and .bin files but I think they were the Inverter board files even if I was on node 10 at that time.
I think it never fully connects so I have access to the files under node 10.

[johu]

The file system is static, no matter of CAN connection.
Now what is in those json files? If in doubt delete both and retry

[Proton]

Works after I deleted all 3 .Json files. Now I have to learn on how to use it. Thanks.

[johu]

Great

[mario]

I wanted to follow up on my last message...
I ordered and received the components and have now replaced all the resistors I previously identified as bad. The latest voltage readouts from all boards are available in the "0128_1800" sheet in this document:


Summary of the current status:

• All channels except u14 and u15 now return correct values.

• The last two channels still show incorrect readings.

• In my previous message, I mentioned that all other resistors measured correctly, but that wasn’t entirely true. I had only checked the ones in that specific part of the board (mostly 10Ω and 10kΩ resistors), and only the 10Ω ones were bad at the time.

Now, I’ve also measured resistors on other parts of the board and found three more potentially bad ones:

• R9, R12, and R16—their values don’t match the BOM.

• You can find the current resistor readings in the "diode_test" sheet.

Remaining issues and next steps:

• Q44 (which I mentioned before) is still questionable—I replaced it, but it measures the same as the one I removed. Since it’s on the same part of the board as u14 and u15, it could be affecting those readings.

• To attempt a fix, I’ll order and replace R9 and R12—hopefully, that will resolve the issue.

• I also lost one pad while replacing Q39 and had to do a hacky fix. So while I’ll give it my best shot, the final result may not be perfect that is why I'm considering to order a new replacement board and move on.

I got 3-60V charger and want to do manual balancing. After checking each series voltage I decided to:

• bring the two most extreme series (in boxes 2 and 5) up to their respective box voltages.

• Then, I’ll charge the first three boxes each until their voltages are close to the last three.

That should get all series close to 20mV delta and not take forever. From there will just leave it to BMS.

Question is: can I use board #4 as is to read voltages u0-u13? I did change balancing mode to off and I suppose if there is no balancing it could be used safely as voltage meter?

[johu]

Thanks for reporting back!

All channels except u14 and u15 now return correct values.

Yes I had to repair incremental as well

R9, R12, and R16—their values don’t match the BOM.

Yes, the BOM on Patreon is a bit outdated, will update. The values should be R9=100, R12=10k, R16=51k

Q44 (which I mentioned before) is still questionable

Q44 just puts some extra load on cell 16, so over time the BMS doesn't contribute to unbalancing the pack. For measuring it is not relevant.

can I use board #4 as is to read voltages u0-u13?

Yes, set numchan=14 to omit the upper channels.

[mario]

Yes, the BOM on Patreon is a bit outdated, will update. The values should be R9=100, R12=10k, R16=51k

Thanks, that makes R9 ok as it measures 100R, but other two not. I measured R12=8k5 and R16=12k2

[johu]

Ok, could it be it's because you measure in circuit? Is the 5V rail at the correct level? If so, don't change them.

[mario]

Ok, could it be it's because you measure in circuit? Is the 5V rail at the correct level? If so, don't change them.

I don't know if it's because measuring in circuit... I just know how to put probes on the pins and read value.
Thanks, I will check 5V rail level...

[mario]

Finally, I got all boards working… actually, they’ve been running fine for a few days now.

The issue with the last two channels on board #4 turned out to be bad solder joints on some of the replaced resistors. A second pair of hands and eyes caught it, and once fixed, everything started working.
R12 and R16 are left as is. 5V rail measures ok.

While board #4 was away, I connected the other boards to their boxes and did manual balancing as planned.

I used the 5 working boards to read voltages in their respective boxes and estimated box #4's cell voltages based on previous measurement logs.
I charged up the two lowest series first, then brought the first three boxes closer to the pack average.
It took some time due to the low total voltage of the charger.
Before the weekend, I reinstalled board #4 and turned on balancing with balmode set to Both and ubalance set to 3700.
Here’s a log showing min/max voltages across all boards. BMS0 values represent the whole pack.
The chart covers two days with no charging or discharging - the constant voltage drop is due to the ~70mA load from the electronics, and I assume the increase in delta is from varying SoC across cells.

Delta changes are also visible during charging. Here’s a log with a few amps of charge applied:

I was manually updating the spreadsheet from my previous message, but yesterday I wrote a Python script that sends CAN messages requesting every cell voltage and command 4 times per second. That seems to be about the max rate for the CAN network, given there's already about 300 messages/sec from other traffic.

I’m not sure if this interval is overkill - maybe once per second is more than enough. However, I get responses on the network and push them to a database. Now, I can monitor every cell voltage and command in real-time and log everything in greater detail.

Here’s how it looks on the dashboard - top chart shows the command per cell (0–3), bottom chart shows cell voltages, zoomed into the important range.

Now, I’ll let the system run until everything is fully balanced.

I ordered a replacement board for #4 since I wasn’t sure how this would turn out, but since everything is working now, I’ll keep it as a spare and leave board #4 as is.

Thanks for all the help!

[johu]

Great visualization! Will be interesting to see how long it takes to even out the rest. I take it one box is 1mV?

[mario]

Great visualization! Will be interesting to see how long it takes to even out the rest. I take it one box is 1mV?

Thanks. I'm still learning, but you can do amazing visualization with Grafana charts and loads of data for them.
It's not one box for 1mV, it really depends on the delta and with battery in current state it varies from 10mV to 25mV in cell voltage range 3650-3900V. on that picture I think delta is around 20mV and there are about 30 boxes in height.
I extended that dashboard to include additional data - every box min/max and overal info. Looks like this now:

I like viewing that dashboard at 250ms refresh rate, check 3 mins recorded:

[mario]

Status update after 24h:


And here’s the chart for the last 2 days, after charging to cca 3860mV:

I wanted to pull out balance states durations for each cell. Since I have detailed logs from BMS for the last two days, data is there, but I’m having trouble labeling graphs with many bars, like status OFF and DISCHARGE. Graph displays only cells that were in that state, not all 96, making it hard to read... Maybe I’ll revisit it later.
It should look something like this...

Last 24h:

24h before last:

[johu]

Great analysis, Looks to be working. What happened to 1.09 though? Looks like it was discharged too much? Also 2.00 is flickering. Is the connection good?

Maybe you could colour - code the balancing states. Also C+ and C- are the same really. Just odd cells are C+ and even ones C-

I'm thinking of dropping that detail

[mario]

What happened to 1.09 though? Looks like it was discharged too much?

It's actually 1.08, and it has been the lowest cell since the first measurements. I manually charged it a bit earlier, but apparently not enough. The "hole" in the graph above 1.08 makes the difference look bigger than it actually is—it's really just 3–5mV.

Also 2.00 is flickering. Is the connection good?

Yeah, I noticed flickering on other cells too. It happens sporadically, and I’m not sure why. I checked the connections, and everything looks good.

Maybe you could colour - code the balancing states. Also C+ and C- are the same really. Just odd cells are C+ and even ones C-

I can switch to a different type of bars and color them based on value, but then I’d lose the group coloring.

The D/C letters above the balance status command bar are already color-coded...Yellow is for Discharge and blue is for Charge

balancestatecoloring.png (11.71 KiB) Viewed 3388 times

Update on pack status:
Delta has been stable at 7–8mV for the last two days.
Reason? Cell 1.08—it's the lowest one. All other cells are within <2.5mV delta.
That’s strange since 1.08 should have been charging via balancing for more than two days now.

Voltage bars show a 10mV range across about 30 boxes.

State of balance during 24 hrs. Blue is charging, orange is discharging.

It looks like 1.08 charging isn't doing much—the delta is still 5mV+.

I checked the history for another cell that was actively balancing and found on BMS4 cell 4.04 that was discharging for about 9hrs in 24 hours and 4.11 as charging for about the same time. that resulted with 10 mV delta drop in about 12 hours.

From past experience, SOC can affect delta, but I don’t think that’s the issue here.

I decided to start OBC and start charging with low current - that should balance pack by discharging cells other than 1.08.

And it seems to be working!
After 6 hours, delta in #1 is now ~4mV and still dropping.

[mario]

What happened to 1.09 though? Looks like it was discharged too much? Also 2.00 is flickering. Is the connection good?

Could it be somehow related to the last and first series in the pack?
I managed to get screenshot with this behaviour on cells between boxes 0-1, and 4-5.
I can't catch it on the middle cells.

But most of the time it looks all ok:

[johu]

Interesting, I could change the sequencing so it doesn't scan 0,1,..15 but 0,2,4....15,13,11,...1 . So less potential jumps

[mario]

Interesting, I could change the sequencing so it doesn't scan 0,1,..15 but 0,2,4....15,13,11,...1 . So less potential jumps

Sure, if you think it's worth it. Happy to test it out!

[maiks]

Interesting, I could change the sequencing so it doesn't scan 0,1,..15 but 0,2,4....15,13,11,...1 . So less potential jumps

Hello,
I’m planning to switch to this BMS. What type of temperature sensors does it use, and can Nissan Leaf sensors be compatible with it?