96 cells are now in. To my surprise still no burnt BMSes, despite even 2.1 hardware being in there.

Using a 16A breaker for cable protection and grounded the shelve to trip the GFCI when there's a problem.

Cables and bus bars are way oversized as I'm running max 15A here.

It's 14 kg, so 50€ for shipping.
No guarantees whatsoever, it has been sitting for years

Now I have boxes big enough for the Prius 3 inverters

Yep, Deye is also on this list: https://github.com/dalathegreat/Battery ... rters-list

I use SunGrow viewtopic.php?p=76529#p76529

Well the procedure hasn't changed, you have to check the diode inside the FETs with a multimeter in diode mode.
Q1 and Q5 (BSS123) are likely culprits so check them first. Also Q52 and Q39 (ST1005SRG)

The good thing about the power on self test is that no other FETs are destroyed in a chain ...

Can you repair it, install the caps and latest firmware?

Great watch :) imagine having to do this with a clutch!
Do you have some metrics for us? Like how much energy did you use that day vs. a fossil burner? How was the car perceived?

Not sure if creep mode from the inverter made it into Zombie... Hill hold will just work with replacement board as it ...

I still have around 150 LFP cells from Polo lying around and to my surprise many of them still hold some charge. I bought them 2010 and they were grossly overcharged once. So the plan is to hook them all up in series and keep swapping cells until only the good ones are left.

I will probably end up ...

Didn't look through everything, but first mistake: you haven't flashed FOC firmware https://github.com/jsphuebner/stm32-sine/releases

LRBen wrote: ↑Sat Jun 07, 2025 6:26 pm
I also think I have found the current limit message in 0x29C, the last two bytes.

The one that reads 0x57? So 87 decimal. Does it charge with 8.7A right now?
Or 0x5700 22272 mA?

Yeah I'd consider the open loop test sort of good enough. Would be nice to see it spinning but I think you can skip ahead to FOC software now and see if you get it spinning when following our video.
The the open loop test the resolver mustn't be connected, so that's not the issue.

Based on that I still vote for intermittent connection problem, caused by moisture or wear.
a) cracked solder joint of connector on OI board. Diagnose with microscope or by wiggling every single pin with tweezers. (I don't think a continuity test will discover this because intermittent).
b) Corroded ...

Indeed the "incorrect voltage readings" are differently incorrect than discussed in said thread. They essentially read 0. Have you checked whether the cell voltages make it to the board at all in those positions? Doesn't look like failed FETs.

The boards that don't power up must have a broken 5V ...

You're not gonna get around reading this thread: viewtopic.php?t=5665

There is no parameter focctrl. Where did you read about that`?
At this stage motor feedback is irrelevant. Can you scope the phase output? Probe ground on HV-, probe tip on L1, L2, L3. Are you getting the PWM with varying duty cycle there?

If only someone had programmed it that way

extern "C" void tim1_brk_isr(void)
{
if (!DigIo::desat_in.Get() && hwRev != HW_REV1 && hwRev != HW_BLUEPILL)
ErrorMessage::Post(ERR_DESAT);
else if (!DigIo::emcystop_in.Get() && hwRev != HW_REV3)
ErrorMessage::Post(ERR_EMCYSTOP);
else if (!DigIo ...

Does "won't start" mean it faults out with OVERCURRENT? If so it would be worthwhile checking the 7 fault signals Maybe even go as far as soldering wires to them and scope if they look fine statically?

I'm inclined to say never change a running system. The firmware doesn't add a new feature.
On the other hand it adds another verification point if you do install it.

I swapped one module into my 64S pack and it works. Of course that doesn't say much as the old one worked as well.

To patch modules to this state first install this software: https://github.com/jsphuebner/FlyingAdcBms/actions/runs/15473329191
Never run a v2.4 BMS or one patched to that state with ...

This is the switching waveform with 5k1 || 22nF
image.png

The 2ms dead time is plenty even for the FETs that have 10k || 22nF.

Had to remove R10 (that is supposed to put some extra load across cell 16 to avoid passive disbalancing). I connected it behind the 10R inline where it caused too much ...

maiks wrote: ↑Thu Jun 05, 2025 12:44 pm ok lets wait for the solution . Thank you

On it!

The muxshort error that some users are experiencing is mainly caused by cascading multiple BMS units together. That's why I’m exploring the option of running the BMSes independently without interconnecting them.


Ok, interesting approach. Yes they'd need something along the lines of this https ...

If I’m not interconnecting the BMSes, does that mean I need to connect all 6 BMS boards to the same current sensor to keep them alive and synchronized?

No, the current sensor must be connected to the first board and transmits its value to the other ones via CAN


If the BMSes are not networked ...

yeah. Wouldn't mind trying again but the installation process is somewhat intransparent. You invoke some package manager and it does things. So rather reluctant to try this on the production wiki. Currently don't have the resources to set up a second one

You can't "convert" a schematic to PCB, you'd have to re-route the whole thing.
As far as I know the schematic has been published for reasons of repair-ability not to help people rip off the design.

Just buy the board if you want to use it. Damien & friends rely on an income in order to keep ...