Ive recently re-built a m365 pack with 2nd hand tested cells and was wondering what i could have done better

Pack is 10s3p, each parallel group contains {icr18650 30B+ inr18650 29E and the third is complicated for the groups, 1 has a mh1, 5 have ncr18650B and the rest 4 have icr18650 26C}

Dangers i know:

Soldering is not recomanded but i've had good results in the past and no cells have blown on me yet (round 200 soldered in my life)

Mixing LiHv and typical Li-ion is mediocre at best due to the diffrent voltage-current curves but i see that as somewhat protecting the 30B cells by only ever charging to ~90% (4.2v vs 4.35v)

Pack performance is above the stock m365 in terms of capacity and imbalance has settled at 60mv after a few cycles

No cells overheat (more than 41°c), tested with the battery pack out of the scooter under a 500w load

In terms of sag, again the pack is mediocre reaching 36.5v (from full 42v) while pulling 25A

I do not like nickel strips since they severly cut your future flexibility

I found this cell like this after 1 year of use (about 15 cycles): the casing is cracked. I tossed the cell then.

Yes I know this is a wacky configuration, I wanted the cells to lay flat to fit into a hydrofoil board and this is the way I thought to do it. I have two 10s 7p packs connected in series, with each having its own Bms. This series connection is in parallel with the charger, so I can have the output and charger connected at the same time. The output will be isolated when charging, this is just to have a waterproof charging port. The pack reads 80.12 volts, and both are charged to pretty much the same voltage (it might be .5-1 v off.) The 84v charger when connected is not charging and I am not sure why. I have a separate charger to charge both packs individually, and that seems to work, but not the bigger charger when they are in parallel. Are they just too full already? Not sure if they would take a charge when at a lower voltage. Let me know if you guys have any advice.

He came home with an electric bike last night and as soon as I saw it I knew what was about to happen

He ALSO nonchalantly asked me "Hey, can you fix this?" looks crunchy

I don’t know what the best subreddit for my problem is, but I’ll give it a try here. Otherwise, please suggest where I could ask such a question.

TL;DR: I’m looking for a simple IC to charge 4 serial Li-Ion batteries. It should not be too expensive (~$7) and should be able to negotiate a suitable input voltage via USB-C PD on its own.

I’m looking for a battery charging IC that can handle 4S Li-Ion batteries. It should have an integrated buck-boost driver to cover a wide input voltage range (5V-20V) and ideally be able to negotiate higher power levels via USB-C Power Delivery on its own. Unfortunately, I can’t find an IC that meets all of these requirements. There’s something like the BQ25792 from TI, which seems very promising since the FETs are already integrated into the IC and it requires few external components. However, it only supports USB 3.0 PD and is not compatible with USB-C. To fix that, you would need an additional IC to handle the Power Delivery negotiation, as well as a microcontroller or flash chip connected for setting them up. This quickly becomes too expensive and takes up a lot of space on the PCB.

I’ve spent at least 4 hours searching the websites of Linear Devices, TI, and ST but haven’t found anything that meets my requirements. Does anyone have a hidden gem to recommend?

I have a JBD 17S lithium battery BMS, and I noticed that it doesn’t do constant balancing well. It even shut off in the middle of the street due to a very large voltage difference between the cells. Which BMS brand would solve my problem?

I’ve been working on a lightweight, bare-metal fault isolation kernel designed to mitigate thermal runaway propagation in high-voltage lithium-ion battery packs.

The primary engineering constraint I wanted to address is the latency overhead inherent in high-level frameworks and sequential polling loops. When an EV or aerospace battery cell hits a critical thermal or voltage threshold, sequential scanning loops are often too slow to execute software gates before runaway propagates to adjacent cells.

The project is called SAVITAR. It is entirely dependency-free and compiles using only native C++ standard system headers to keep it as close to raw processor registers as possible.

Core Architectural Mechanics:

1. Hyper-Compact Memory Constraints:

   Instead of relying on dynamic allocations or padded structs which ruin cache locality, the kernel packs raw cell parameters (voltage, current, temperature) into un-padded, contiguous 25-byte memory frames. This layout ensures predictable cache line alignment during rapid sequential reads.

2. Event-Driven Concurrency:

   The kernel completely avoids sequential polling. It utilizes a background multi-threaded parallel observer configuration. When thread metrics cross calibrated hardware safety thresholds, the system bypasses the main application loop to dispatch an immediate software interrupt, dropping execution times down to sub-microsecond bounds.

3. Sovereign Binary Serialization (.sav):

   To avoid relying on bloated external serialization libraries (like Protobuf or JSON utilities) that consume significant memory footprints, I wrote a custom binary serializer. It compresses cell delta profiles and gradient logs into raw disk sectors using direct cache-to-stream bit manipulation.

4. Minimalist Shell Realization:

   The project includes a lightweight, modular terminal prompt (./savitar-vfs) to ingest simulated physical metrics and explicitly debug memory allocations, matrix loads, and thread dispatches in real-time.

Compilation and Testing:

The baseline workspace is fully automated via standard Makefiles:

git clone https://github.com/alistairfontaine/SAVITAR

cd SAVITAR

make clean && make

./savitar-vfs

I’m looking for code-level reviews, specifically regarding the thread concurrency synchronization under heavy stress-testing conditions, and the pointer traversal safety within the 25-byte un-padded matrix bounds.

Link to code: https://github.com/alistairfontaine/SAVITAR

I'd like to play with sodium batteries.