Flying ADC 16 channel BMS 96S test

[PetersonOctavius]

The 2.4 Version works no problems so far. still do not know how to make them balance. never seen them saying "balancing"

check all the down in the spot values tab. you ll see if the cells are being discharged of charged

[Proton]

Quick update:

the boards have 12v all the time. When I turn the car on sometimes board 5 and 6 do not power on, sometimes just board 6 does not power on. I have to turn off the 12 v to all boards, then turn it back on and then turn on the car.

[johu]

Quick update:

the boards have 12v all the time. When I turn the car on sometimes board 5 and 6 do not power on, sometimes just board 6 does not power on. I have to turn off the 12 v to all boards, then turn it back on and then turn on the car.

Ok, will test that but that if for after my holiday

[Volkmar]

Hi,

I´m building an electric car with Volvo Battery Packs 96S. I use a Telsa SDU with the OI Board, a ZombieVCU ISA Shunt and the Foccci. For the BMS I use the board, which Catfish developed.
viewtopic.php?t=2123

Now my problem: the BMS does not submit MaxChargingCurrent and no SoC to the CAN bus and I can not perform successful charging. I think this Information is essential and crucial for a successful charging via the Foccci.

Since I have no idea about programming at all, I think the best option is to switch to the Flying ADC BMS.

Does anyone knows if or when the Flying ADC BMS will be integrated to the ZombieVCU? (in the moment Relelase V2.22A does not yet support)

Thank you for your support!

Best regards

Volkmar

[Jacobsmess]

You could (as advised to me by Tom91), use the simpBMS class on zombie and map the required information from the Flying ADC BMS to those IDs.

[Volkmar]

You could (as advised to me by Tom91), use the simpBMS class on zombie and map the required information from the Flying ADC BMS to those IDs.

perfect! Thank you!

[skr]

So I removed PTCs in front of cell taps, paralleled another F1 on top of outp ptc fuse and paralleled 2 balancing fet resistors (now 5R each), if my understanding of current flow is correct- I should now see about double of balancing current. In 48h module with cell delta of 16mV is still at 16mV at 4050mV avg voltage, 157Ah.

[johu]

Hmm, have you checked balance currents? Maybe with testchan and testbalance?

[skr]

I have a nice hall sensor I want to test the balancing on a bench with, will see. I am discharging the battery slowly and today the delta has moved from 16 to 13mV, not sure if because of SoC steepness reduction on the voltage curve or because of balancing. Will give it some more time and do a full charge to see if the delta has actually moved, will report back in about a week. But the good thing is that the v2.3 boards have been power cycled for most likely 100-200x with no muxshorts, so, if anything, the deadtime, pint state and cap fixes are probably doing something.

[PetersonOctavius]

i ll be soldering my 6x17 caps today. and fix so muxshort fets.
the caps fit nicely between the fets legs. so that would make it easier to solder

[skr]

Now with the aforementioned mods delta seems to be falling a few mV every day, with most noticeable movement from the outliers, given the "adaptive balancing cycles" I added to my fork. The 16mV delta is now 9mV at the same cell voltage.

[Proton]

@johu I am looking at a Charger form China and the seller said that they have a CAN version. Can I control this charger with your BMS?

CAN document attached.

Screenshot from 2025-09-12 13-35-46.png (111.98 KiB) Viewed 2120 times

Charger CAN.pdf

(138.94 KiB) Downloaded 31 times

[arber333]

@johu I am looking at a Charger form China and the seller said that they have a CAN version. Can I control this charger with your BMS?

CAN document attached.
Screenshot from 2025-09-12 13-35-46.png

Charger CAN.pdf

I used that charger type before. It is Elcon CAN protocol at <1000ms interval.
The charger expects every second to receive a CAN message from the BMS with extended CAN ID 1806E5F4 and 8 data bytes with voltage and current required. For example 98V and 16A would be 980 = 03D4 hex and 0160 = 00A0 hex so the 8 data bytes would be 03D4 00A0 0000 0000. If the charger does not receive a valid CAN message in 3 seconds, it stops charging

Here is the wiki for BMS
https://openinverter.org/wiki/16-cell_BMS

This BMS works with CAN bus at 500kbaud speed. If you would want to use this with your charger you would have to use all components on the same line at the same speed. What is your charger communication speed? I see multiple options...

I am sure it would not be difficult to program a BMS to output 0x1806E5F4 telegram when in charge mode. Also there could be a status check so that if there would be an error the 0x1806E5F4 msg would cease and charger would stop....within 3s...

[Proton]

This is the Chinese version of the ELCON, I guess.

Was trying to find out if I can send a custom message from the Open inverter BMS. not sure if anybody tried it.
If this works then I can reuse this charger in the future for a different voltage if needed.

[arber333]

Your options are...
1. connect charger to BMS CAN bus line at the same speed and reprogram BMS master to send charger command telegram and insert stop conditions
2. use a different CAN controller to observe BMS and command charger on the same line...
4. the same but with dual CAN lines to bridge different BMS and charger CAN

[skr]

if adding a new module/functionality to the openinverter bms to send other CAN comms, please do a check for RUN mode or add arbitrary delay (i.e. 5 seconds) before sending messages, as on older hw versions (below 2.3) there was an issue in my VX1 fork last slave init - last board would not initialize properly and error out. Disabling or delaying extra comms until run mode solved this.

[johu]

I guess this applies also to sending the mapped CAN messages?
I hope no code modification is needed and the message can be generated with the mapping

[skr]

at this point it is hard to tell as my fork has deviated in some ways, most notably it runs 250k baud, but doing a sanity check for RUN mode imo is worth saving time chasing issues before other comms are initiated. On hw 23 it worked without issues even if sending extra can comms as soon as the master board boots, but on hw 22 or 21 that you recently shipped last board in a chain of 3 had issues initing. I though maybe the init broadcast should be retried a few times, but delaying extra can comms until all boards are up fixed it.

[arber333]

I guess this applies also to sending the mapped CAN messages?
I hope no code modification is needed and the message can be generated with the mapping

If I remember correctly with charger command there is one byte that has to be 01 or 00. And 00 means stop. So if you could couple that byte to BMS state you should be safe in case of any overvoltage...

[skr]

imo for a proper charger handling some more logic should be added, i.e. target cell voltage (some people want to charge to 3.95, some to 4.15), chemistry type, some way to monitor abnormal temp rise, actual CC/CV curves depending on chemistry. For my flatpack charger I am handling this all inside of the charger, relying only on high/low cell values and temperature values.

For simple go at one constant setpoint and current it should work as is.

[mario]

Reporting status of my BMSes...

I did capacitor patch on all boards and uploaded newest firmware on August 28th. First I powered BMSes without battery and it was ok.
Then I powered up with battery connected and all worked like a charm. Balancing about 1 mV per day.

On September 2nd I decided to test what power Prius inverter will handle and fried it (have a record of 894 A for 10 ms from the battery with ISA shunt) and welded main contactor also. Was driving it on 140+ kW from the battery few days before that.
That resulted with car stationary until I sourced replacement inverter and, because I noticed that smallest delta is when cells are above 3900 mV I kept battery in that range.

Result is that yesterday all cells were under 5 mV delta. All great. In the mean time I got replacement inverter and contactors and today I decided to replace contactor and inverter and disconnected battery. That means turning BMSes off because they are powered from the HV battery via Meanwell DC/DC.

After replacing inverter and contactor I powered BMSes up and forth BMS in the line id: 13 reported muxshort, errinfo 988. When I reported muxshort few months ago, it was other board but also on the id: 13 and I was thinking it is because of my dodgy work on that board and replaced it with new one. Now, that new board is also reporting muxshort.

If it matters, I'm powering boards by applying 12V and then enable signal. Enable is always live.
First power up 8/28 was with battery about 375V and today it's 390V+.

I know that I need to go and replace broken FETs but, do you have any idea why this happened on the same id (13) twice and with different boards?

status13.txt

dumpall for id 13

(4 KiB) Downloaded 23 times

HV and delta

[johu]

errinfo=988 means it got a 988/8192 reading from the ADC despite all FETs should be turned off. So around 0.5V or so. Apparently a rather soft connection. Can you verify 0.5V on the ADC input?

So the module wasn't damaged from your high current experiment but died afterwards from power cycling?

Sucks to hear this still happens. Which hardware is it exactly?

[mario]

errinfo=988 means it got a 988/8192 reading from the ADC despite all FETs should be turned off. So around 0.5V or so. Apparently a rather soft connection. Can you verify 0.5V on the ADC input?

Sorry, I pulled the boards out to check FETs but didn't get time to that yet. Can do it when I connect them to battery again.

So the module wasn't damaged from your high current experiment but died afterwards from power cycling?

Correct.
High current damage happened on 09/02 and boards were up and running for the next 2 weeks without issues. The car was in the garage whole time. Boards were running for few days before incident also, so I would say about 3 weeks total.
Error is reported yesterday for the first time and it was after power cycle.

Sucks to hear this still happens. Which hardware is it exactly?

That is the board that you sent in February or something like that.

This is from sample13.txt attached in my previous reply:
version : 0.26.29.B
hwrev : v2.1

It says 2.1 on the board and all others are the same:

board #4 id: 13

Is that info you were looking for?


I would really like to solve power cycle issues, It's not that I'm power cycling them all the time. I do it in really rare cases and I hate this happens.

[mario]

@johu I tracked it down to Q5 being defective and replaced it.
All the other components look fine, and I’ll connect the BMS back to the battery.

Do you have any recommendations to avoid stressing or burning components on startup?
Would it make sense to disable balancing before power-up, or is there a better approach?

[Jacobsmess]

@Mario How did you diagnose Q5? I have some possibly unrelated issues with my boards but looking for ways to test different components to identify issues. @Johu also, which component and pins are the ADC input that should show 0.5V? Thanks