Tesla Model 3 Battery Hacking

[Jack Bauer]

New Keysight scope purchased with Patreon donations. Now I can get back to work on the Tesla Model 3 BMS. Lack of a 4 channel fast DSO with SPI decode meant this project has been on hold since I had to give back the demo unit. As I don't get any sponsorship, things like this need to be purchased at normal price so delays happen. Thanks to the kind assistance of those on Patreon (and elsewhere) we can get back to hacking and publish a beta design for the M3 bms decoder.

[Isaac96]

I hope you take that with you to Lanzarote

[mdrobnak]

Are the PC based DAQs not good for this sort of thing? (PicoScope I think is one of the more well known ones)
-Matt

[Jack Bauer]

Lots of options out there. My experience with pc based scopes is that unless you get a good one (expensive) and a good pc (expensive) then its no use. Plus I prefer to have physical buttons to push:)

[retrEVnoc]

I have nothing useful to say, other than general praise and excitement at yet another milestone being achieved. Great work.

Same here, great work Damien, please unlock these awesome batteries for everyone!! Heading to your Patreon now...

[Ken_S]

I thought I would share this here, as an aside replying to the prior discussions about using edge connectors with the flex pcb cables on these modules. This is a photo of a partial solution, tested on a spare flex PCB from eBay.

As excited as I am following the developments towards decoding the Tesla model 3 BMS, my final pack assembly is happening in the next month, and therefore I am going with an off the shelf BMS... in order to simplify the wiring process I have been searching for a solution for connecting to the flex PCBs directly, and this is what settled on.

The blue connector is an Amphenol Flat Flex Connector (digikey PN 609-2193-ND). The contact is ideal, a very secure flat crimp insulation piercing design, but they are only available in 2.54 mm spacing connectors, while the Tesla flex PCB is 3.5 mm spacing. Therefore my plan is to remove the contacts from the connector and solder the pins into a PCB laid out for the correct spacing, designed to connect the flex PCB pads to a board mount connector for the BMS cell tap wires. The PCB will slide in behind the flex cable and provide a rigid backing for carefully crimping each contact.

Hopefully this helps someone! When I finish the pcb layout and test the boards, I will post the eagle and gerber files online somewhere to share them.

[muehlpower]

I would prefer to solder additional cables to the original board to use any BMS. Later, when the BMS has hacked, you can remove the cables and reactivate the tesla boards.

[Kevin Sharpe]

I am going with an off the shelf BMS...

I would prefer to solder additional cables to the original board to use any BMS

Not a topic for this thread but be extremely careful with "off the shelf" BMS systems and Tesla batteries. We have seen several examples of destroyed modules and very poor support by a 'reputable' supplier.

If you wish to discuss further then the BMS sub forum is the place to post;

viewforum.php?f=13

[Ken_S]

I am going with an off the shelf BMS...

I would prefer to solder additional cables to the original board to use any BMS

Not a topic for this thread but be extremely careful with "off the shelf" BMS systems and Tesla batteries. We have seen several examples of destroyed modules and very poor support by a 'reputable' supplier.

If you wish to discuss further then the BMS sub forum is the place to post;

viewforum.php?f=13

Thanks for the warning. I will continue the discussion there.

[Jack Bauer]

Right, back to the hacking. The next phase of this op requires a battery and slave board. Fun though it would be to haul around a full size model 3 brick, I decided to make a bench version from 25 x 18650 cells. This has the added advantage of allowing individual cells to be connected and disconnected allowing us to observe the data changes.

[Jack Bauer]

How to tell a good bms from a bad, Lesson 1: A good bms draws f%^k all current from its attached battery when in sleep mode:)

[Jack Bauer]

So time for a little bms update. Now that we have our bench battery and slave setup we can connect the whole lot to a hv controller. Looking at the pt can output on message 0x332 we see the cell voltages correctly reported. Then we can spy on the spi with the salea and actually see the data coming in from the slave board. But what we can now do most importantly is to cause changes in that data by messing with the connected cells.

[tom91]

Can you export raw hex data of the SPI bus? Then I would not mind having a look at it, I would suspect quite some likeness to the standard linear chip protocol.

[Jack Bauer]

Attached capture from Salae logic analyser. Can be viewed with free software : https://www.saleae.com/downloads/

Few points to note : The spi runs with Cpol=1 and Cpha=1. The capture starts with the hv controller powered down and powers on after about 0.5sec. One slave connected with all 25 cells attached.

[Jack Bauer]

Ignore my last. I am a clown. Attached capture as before but with correct spi decode pin assignments.

[Jack Bauer]

So a few observations from looking at the logic analyser data.

1)Looks like all transactions ar 16bit
2)Seems the controller spits out 0x2ad4 to wake the salves from sleep and get them to respond.
3)Slave responde with : 0x0fff
4)Master sends : 0x4e53 , 0x2500
5)Slave then sends an 18 byte response.

I have 2 hv controllers. One (mine) I have cut the tracks from Batman (Elon equivalent to the LTC6820) to the stupid NXP micro. This allows us to send isospi with our own device (arduino due) using the Tesla spec that the slaves will recognise. On the 2nd hv controller I can spy on the spi with the salae and watch the results over can to correlate what changes on the spi when I mess with the cell voltages and how that corresponds to the real life data sent out over can. Yeah, another Tour De Force:)

[tom91]

What voltage are your cells at?

The protocol does not look like "standard ISO SPI" for any of the Linear Chips i have reviewed.

[tom91]

So it turns out some way this works seems like:
2nd from last byte is echoed before the slave data.

It seems the the byte before it indicates some form of register or something.

Since there are two connected IC's We are are seeing the first IC and then IC2 send the same info, always 9 bytes per IC for a full response, the rest if buffered with 0xFF due to no other IC's/slaves present.

Seeing that I am seeing alot of values of around 0x9FCD - 0xA033 ish and then usually reported in sets of 3 (which is the way the LTC6813 usually reponds).

[tom91]

I get a wierd feeling Tesla is doing something along the lines of what the old chips used to do for comms.

Model S and other variants used this chip from TI with SPI translated on to canbus.
https://www.ti.com/lit/ds/symlink/bq76p ... BQ76PL536A

But then not using the fields as defined here but different and getting all ICs to respond in a burst. I have seen 3 byte commands and 4 byte commands in the capture.

[Jack Bauer]

Oh i bet it won't be straightforward. Cells are at about 3.25v each and reported temp was 19c at time of capture. I'll be installing some pots on the pack to allow varying the voltage of a few cells.

[tom91]

Oh i bet it won't be straightforward. Cells are at about 3.25v each and reported temp was 19c at time of capture. I'll be installing some pots on the pack to allow varying the voltage of a few cells.

If you vary a few voltages and send another capture I can figure it out.

[Jack Bauer]

Total of 6 captures now up on the repo with log detailing the events and pictures of received can data on 0x332 just after the log.
https://github.com/damienmaguire/Tesla- ... man_1Slave

[Jack Bauer]

Musk Vs Arduino.

Tried sending 0x2ad4 to the slave via spi on a due. Of course it didnt do anything. Seems the due will break the transaction into bytes whereas Elon uses words. Might be time for an stm32 here unless anyone knows better?

[tom91]

Musk Vs Arduino.

Tried sending 0x2ad4 to the slave via spi on a due. Of course it didnt do anything. Seems the due will break the transaction into bytes whereas Elon uses words. Might be time for an stm32 here unless anyone knows better?

How are you sending it? How about sending it as 0x2A and then 0xD4?

[Jack Bauer]

Tried that. Every option I have tried with arduino breaks spi transactions into bytes. Even this results in two bytes:
receive1 = SPI.transfer16(send1); // do a transfer