Twizy Virtual BMS

COOL.

Hello Delvecchio, I would also like to replace the cells in my battery with 16 LIFEPO4 cells of 230Ah. I've seen that you've successfully completed the virtual BMS connection with your cells. Could you share the schematic and wiring details? Your help would be appreciated. Thank you.

If you didn't buy 16 Lifepo4 cells, please consider to use 14 CALB cells, which have the same chemistry of the original modules.
With no promises for the future, may be it will be possible in a short time to use for bigger battery the original BMS (also with decreased SOH), without reserve canister effect.
About your questions, you find a clear schematics in klaus's BMS implementation (it is linked in the dexter's virtual BMS github).
I started with it.
My adding to that project are working, but I need to improve some things (for example SOC calculation accuracy) before discussing about.

Do you check the "quick start"? In the first editions of the e-Driver BMS it was not supported.

Here's the English translation of your message:

Thank you for your prompt response. I haven't purchased the LIFEPO4 cells yet; I was evaluating what to do. Your reflection on CALB is not wrong; in fact, it turns out to be the simplest solution at the moment. I've read a lot on this forum, and I assume that some user should develop a BMS shortly, which would be great. I've ordered 14 CALB cells of 195Ah; other capacities were no longer available. Although it seems strange to me that with all the electronically skilled people present here, no one has managed to modify the original BMS. Perhaps there isn't much interest in doing so.

mio900 schrieb: ...no one has managed to modify the original BMS...

Yes, me! But we are off topic here.
You still have to wait a little until I complete the tests.

Delvecchio schrieb:

mio900 schrieb: ...no one has managed to modify the original BMS...

Yes, me! But we are off topic here.
You still have to wait a little until I complete the tests.

Perfect, then I'll wait for news from you, thank you.

Delvecchio schrieb: I have a question because I guess I'm suffering of timing problem.
In the timer ticker callback I read this note:
// Note: avoid complex operations, this needs to be fast.
How much could last the callback function?
I think for sure less then 10 ms, but is there a max timing value I can take as a reference?
I ask this because I'm using an ADC ADS1115 to retrieve voltage values for current sensors, cells voltage and temperature sensors and this ADC, also if set for the fastest reading, takes about 2,7ms to complete a reading with an arduino nano.
For this reason I'm currently taking two readings for each timer ticker call, but I can reduce to one.

Correct, you need to stay well below 10 ms to avoid ticker overruns.

A maximum time share available is hard to determine, as the time needed by the framework depends on the software configuration, the ECU state and the CAN bus state.

A major consumer of CPU time is the debugging (TWIZY_DEBUG_LEVEL & MCP CAN DEBUG_MODE), as the standard Arduino serial output is slow and may even block, when the buffer is full. Setting the highest baud rate available helps, but reducing and avoiding debug outputs as soon as possible is the best option. There may be new options available now, possible a better serial library replacement. And using an ESP type Arduino instead of course yields a much higher performance, and would also make using a Wifi network channel an option.

I never tried to determine a "safe" maximum, but I'd generally recommend staying below 5 ms in the callback, to keep enough headroom for the framework.

And, btw, very nice & valuable work!