Tesla Model 3 Battery Hacking

[retrEVnoc]

Just emailed them over Tom, thanks.

[tom91]

I am looking into this again and realised I only have a 24s BMB.

The weird part is that the 23s BMBs are reporting wrong amounts of cells where the 25s BMBs are fine.

If anyone has a spare 23s BMB I would be happy to do bench validation in exchange for it.

[1ni3shi]

Does anyone have any experience with a 2024 Highland battery?
Cannot get HVIL loop satisfied, to close the contactor.
From researching schematics online it seems the new 2024 battery HVIL system have changed.

[OOP]

i dont have a Highland battery right now, if i find one, i can check this out if something was changed. In my project i use 4 Model 3/Y Batteries and one Plaid battery for solar storage at home. But i dont see a highland battery for a good price on the market.

[muehlpower]

The weird part is that the 23s BMBs are reporting wrong amounts of cells where the 25s BMBs are fine.

I think I know why things are going wrong with 23s modules. With the 23s modules there is a gap with an invalid value between cell 13 and 14 when reading out the data

[tom91]

I think I know why things are going wrong with 23s modules. With the 23s modules there is a gap with an invalid value between cell 13 and 14 when reading out the data

Not quite, its cell 8 is skipped. I have this sorted and someone is testing these fixes. But I think there are issues with their comms between modules.

Will probally push an update to github soon.

[tom91]

https://github.com/damienmaguire/Tesla-M3-Bms-Software

Update for 23s modules is now online.

[retrEVnoc]

Thanks Tom!

Anyone having success getting the balance function to work on 1+ modules?

[kastein]

yeah, it's definitely bi-directional. If it thinks there is a break going one way it tries to reach the rest of the modules by transmitting from the other direction. That will allow for reading all modules so long as there is one one break in the wiring. Pretty cool stuff.

Excellent, thanks for answering the question I actually joined to ask. I was wondering if it was just redundancy for reliability/safety or a loop type setup that requires full pass through all the way around.

I am quite terrible at verilog but I am going to take a stab at making the FPGA version work soon, as I need it for my own project. If I get it working I will of course provide the results to the community.

(The quoted post is the last I've read in the thread so far, I'll be reading the rest tonight, so if I'm answering things that have already been done, sorry, I'll get to those existing answers shortly.)

[collin80]

If you're going to take a crack at it, let me quickly lay down some info that is probably covered in Damien's videos but here it is in the reader's digest version:

Comm is in the form of a proprietary version of isoSPI. Standard off the shelf things like LTC6820 do not work.

Unlike standard ISOSPI, the long pulses for Tesla are 325us long and the short pulses are 125us. You might then see the problem here. ISOSPI says long pulses are 150us and short pulses are 50us. So, a Tesla short pulse will look like an isospi long pulse. This makes the two completely incompatible. Both Damien and I have tried OTS stuff. It's a dead end but I assume you knew that as you were going to continue down the FPGA pathway.

There is one other big difference. IsoSPI says the slave does not send 1's in it's reply. A lack of a bit is implied to be a 1. Only 0's are sent in the slave bit stream. Tesla, on the other hand, sends all bits from the slave.

Other than these two differences, it's isospi at 1 megabit. The tesla slaves basically split the 1000ns bit time down the middle and send their bit right in the middle of the time. I think I measured the start to actually start around 450ns from the start of the bit time.

I'm working on completing the isospi work too. I've tried a lot of different boards but I always end up having weird timing or signal issues and then try something else only to have some other issue. Never have gotten it to work reliably enough though I have gotten my own comm to be recognized and replied to by M3 slave boards. Right now I'm trying a raspberry pi pico using the programmable PIO interfaces. This seems promising but now I'm also experimenting with using RS485 transceivers for sending and receiving as this is a lot less fooling around trying to create a nice driver and receiver section. My reasons for this are thus: with my own hardware or trying to use Damien's test board, I always see that transmitting seems OK if done in isolation or receiving works in isolation but trying to do TX then reading back replies seems to result in the voltages fluttering all over and being impossible to get a good read on. So, I hope that replacing all the complexity with an RS485 transceiver will simplify things.

The big problem with RS485 transceivers is that they are really only two state. They completely hide the differential nature of the bus from you. Its possible to turn the TX section on and off (when off the bus is sort of in a third state - floating) and get decent results but the RX section then only has two states, high and low / 0 and 1 so when the bus is idling you read all 1's and then it's interesting to try to find the isospi traffic in all that. But, I think it'll be possible and then the only stuff on board would be a pico, an RS485 transceiver, some biasing resistors, some filtering, and an output transformer. I think all this can work as RS485 transceivers can be sourced with 50Mb operation. That's 20us resolution and as shown above, the signals are 325 or 125 so 20us resolution is reasonably suitable. Those signals can turn into 320us and 120us and be fine. The isolation transformer and resultant conversion from digital pulses to sort of analog blips stretches out the signals anyway.

Well, that's the state of where I'm at. There is old code from my pico adventures that works with Damien's test board: https://github.com/collin80/model3_isospi

We all want this to happen so, by all means, work on it! If you beat me, well, won't be the first time, won't be the last. I'm dying to see someone, anyone, whether it's me or not, crack this egg and get a fully open source solution going.

[jpwhit]

I have one of the boards from Damien and have transplanted a batman chip. My board has the v0.03a firmware that came installed. It appears that I'm hitting the 23 cell group issue with this version of firmware. I'm trying to upload the current firmware from github to the board via the Open Inverter web interface, but I'm not having any luck. I get an SWD Error. I'm completely new to the OpenInverter ecosystem as well as the STM32 MCU family. Have a lot of experience with dev environments and tools for other MCUs.

I downloaded the latest zip from GitHub and it looks like the "stm32_m3bms" is the latest compiled binary, but I had to rename it to have a .bin extension. Maybe that's not a valid approach. Can anyone help with the pointer to info on the right way to update the firmware? Do I need to setup a build environment and build the code from source? Do I need to flash the code on the board with an STM32 specific flash adapter?

I do have pretty much every version of the Tesla Model 3 and Model Y packs. So, if this hasn't been tested with all variants, that's something I'm happy to do. I have a standard range Li-ion pack with the four short modules, I have the Li-ion packs with the 25/23 cell group arrangement. And I have 60kwh LFP packs with the 26/28 cell group format. I have one of the older standard range Li-ion packs with the full length modules where there are non-populated cells in the modules. That one is in not great shape, so I'm not confident in if all the BMBs are operational.

[tom91]

Provide pictures of the hardware and the "issue" please.

Have you reviewed this thread? https://openinverter.org/forum/viewtopic.php?t=6685

You need to build it yourself or wait for a release. I can request a release since I had some feedback, but very little feedback really so not sure how stable it all is right now.

[jpwhit]

Thanks, I see the build instructions in the thread you posted. I'll build it and test with the latest code. And post what I'm seeing. All my battery packs are at my lake house and I'm back at my primary house now. So it'll be a few days at the earliest.

[jpwhit]

Here's my setup. This is with a Tesla RWD Model Y Long Range pack. Both ends of the ISO-SPI ring are disconnected from the HV Controller in the pack. The PCB being tested is connected to one end of that loop.

I'm only seeing cell voltages from one of the 23 cell block packs in the spot values. But I do see the correct overall pack voltage and the right voltage summaries from each of the BMBs down towards the bottom of the spot values.

TeslaLR-23-25-25-23.pdf

(1.47 MiB) Downloaded 4 times

I'm going to try it with a couple of additional packs shortly that have a different arrangement of cell blocks per modules.

[jpwhit]

Did another test, this time with a Model 3 standard range LFP pack with just the bare modules. These modules have 26-28-28-26 cell blocks.

You can barely see in this picture that the module to module ISO-SPI interconnection jumpers are in place

It did show 26 cell voltages, which would be the right number for the first module, but the last value was truncated by 1/10.

TeslaLFP-26-28-28-26.pdf

(1.47 MiB) Downloaded 3 times

[jpwhit]

One last test on the LFP modules. I moved the board to connect to the second module with the first module emitted from the loop.

Strangely showed 27 cell blocks instead of 28 for the first module.

TeslaLFP-28.pdf

(1.47 MiB) Downloaded 1 time

[jpwhit]

Tried 2 Tesla Standard Range Li-Ion 24 cell group modules.

Sort of the same pattern as all the other tests. Looks like I'm just getting cell voltages for 1 module. But on these modules I had recently checked all the voltages recently. Every cell group is around 3.6 volts. The voltage reported by the board for U13 - U24, which are all around 4V, are not correct. I reverified with a meter. There are no cell groups in either of these modules with those voltages.

TeslaStdLiIon-24-24.pdf

(1.47 MiB) Downloaded 2 times

[jpwhit]

Btw, this is the same results I was seeing with the V0.03a firmware installed. I've been setting the number of BMBs in parameters and pressing [Enter]. I see a "Set Ok" message come up on the screen after pressing enter. I've also been pressing the "refresh" button at the top of the screen to see updated spot values. I see the loop counter increase when I do that, but not being terribly familiar with the standand Open Inverter web user interface, perhaps I'm doing something wrong....

[tom91]

Please run the newer firmware, the one I sent you in DM. You need to save settings to flash for them to stay permanent.

[jpwhit]

I think I am running the firmware you sent. This is the version shown in the spot values "0.07.TA". Is that the correct version number for what you sent?

[jpwhit]

Not saving the parameters to flash was certainly a problem. Now that I understand that, the standard long range pack with 23-25-25-23 cell groups seems to be working properly. I'll try the other pack configurations shortly.

[jpwhit]

Here are the results from the Standard Range Li-ion and LFP packs.

For the Li-ion pack, I tested with just two modules. I can do all 4 modules as soon as I have someone to help me move the other 2 modules close enough to connect ISO-SPI jumpers. For this one, Chip-1,2,3 cell counts look correct. But the Chip 4 cell count it Zero. Also, the U13-U24 voltage values are incorrect.

TeslaStdLiIon-24-24-v2.pdf

(1.47 MiB) Downloaded 5 times

For the LFP pack, the cell block configuration is 26-28-28-26. Chip1,2 cell counts look correct. Chip 3 is 13 and I would think it should be 14. Chip 5,6 cell counts look correct, Chip 7 is 13 and I would have expected 12 or 14, Chip 8 cell count is zero. The cell voltages that are present look correct.

TeslaLFP-26-28-28-26-v2.pdf

(1.47 MiB) Downloaded 6 times

[tom91]

Im going to need raw SPI logs of the comms on the BMS board to batman.