openinverter forum

So both batman and robin have 6 pin 2.54mm headers. Seemed only right to populate them and go probing around. Results attached.

Soooo... in the attached chan3 (blue) is on the outputs of the iso transformers, chan1 (yellow) is on pin 3 of the batman header and chan2 (green) is on pin2 of batman header. Protocol decoder set to serial at 14.4k on chan1 just for kicks....

Forgot this is an MSO scope. Broke out the digital pod and probed all 5 pins on the batman header. Kicked on spi protocol decoder and bingo. Now we're cooking:)

YES! Go Damien Go!

Repo opened on github to hold data : https://github.com/damienmaguire/Tesla- ... attery-BMS

So far have an spi capture from the batman chip on the hv controller. Looks like some command data and lots of zeros that could be for cell data:) Of course I'm probably on the wrong track and seeing what I want.

Tom wrote in the YouTube comments (captured here for posterity);

"What you are seeing is; a messages, two bytes and a PEC (also two bytes) to wake up IC one in the chain, so Module 1 IC1, then the other 8 are to poke the chain lets say. So from Module 1 IC 1 to Module 1 IC2, to Module 2 IC1 ect. ect. When it is all zeros it is just waiting for a response"

Collin Kidder at 8:31 says "they transmit two different frequencies on the same bus, not at the same time... so they can use filter networks so each chip only gets the frequencies meant for that chip"

I have tried making some sense of what the SPI data would mean, but so far no luck.

However one thing to add, the signal you reffer to as analogue is ISO SPI pulses.

[url]https://www.analog.com/media/en/technic ... 6812-1.pdf[/url

So the big jist of it is that that you can see the spikes, which is a timing spike, then the way the spike decays indicates its value representation.
Excerpt below on the description from LTC.

One thing to note, Model 3 bms slaves originally came with both the LTC6811 derivative and the 6812 derivative populated.

It would seem after a certain date only one variant is populated, the LTC6812, so the square ICs instead of the rectangular ones.

As Damien mentions, it would be very useful seeing how a brick responds to these requests, once this gets deduced to be derived off the LTC base coding i would suggest hooking an Arduino DUE or similair up to the header and trying direct SPI comms using the LTC sketchbook examples.

https://github.com/analogdevicesinc/Linduino

Code I used: DC2350AB

Thanks Tom. Next move is to do some captures with battery modules connected. I've also ordered some LTC6820 parts and some of these boards to see if they talk : https://www.maleetronic.com/boardsproje ... pi-module/

If not then I reckon we are into an fpga to replicate the asic on the hv control board.

tom91 wrote: ↑Mon Mar 30, 2020 9:12 pm It would seem after a certain date only one variant is populated, the LTC6812, so the square ICs instead of the rectangular ones.

Interesting.

The battery I have is from a April 2019 registered EU car and only has the square chips. At least on the one I have a picture of. Can't get near it for a while because of the virus. I wonder could we turn this on its head and replace the musk chips with off the shelf LTC6812

Jack Bauer wrote: ↑Tue Mar 31, 2020 4:55 pm I wonder could we turn this on its head and replace the musk chips with off the shelf LTC6812

good luck not dying/not frying the board or equipment, 23-25 cells connected, quite a lot of voltage there. And removing the little fuse wires and reattaching them does not sound fun to me.

Jack Bauer wrote: ↑Tue Mar 31, 2020 4:55 pm I wonder could we turn this on its head and replace the musk chips with off the shelf LTC6812

Maybe replace the BMS PCB with a LTC6812 design and treat the gold fingers on the battery as an edge connector that you fabricate a matching connector for

Oh that is just naughty:)

Jack Bauer wrote: ↑Wed Apr 01, 2020 11:33 am Oh that is just naughty:)

Yeah

Looking at the Munro teardown the PCB edge connectors clean up nicely once the wires are removed... I wonder if we have enough space to slip the bottom of a mating connector under the flexi circuit... depending on the pad pitch we might even find an off the shelf part

If you cut the aluminum bonding wires, then you need to find a way to connect the new PCB to the flex cable. The traces on the flex cable are aluminum and can't be easily soldered to (I've tried). The only other option is to run individual wires down to the cell groups. There are access holes through the battery casing that would allow a wire to be soldered to the SS battery casing.

dougyip wrote: ↑Wed Apr 01, 2020 3:37 pm If you cut the aluminum bonding wires, then you need to find a way to connect the new PCB to the flex cable.

That's why I'm proposing a connector that slips onto the flex cable... I've done this a number of times in the past when hacking OEM components with exposed pads on the edge of a PCB

The flex cable is glued down solidly to the plastic case along it's whole length. I don't it can be lifted without damaging it.

More than one way to solve a problem : https://ie.rs-online.com/web/p/conducti ... s/1863616/

But let's stick with plan A for now which is to have the spi comms:)

Jack Bauer wrote: ↑Wed Apr 01, 2020 4:50 pm But let's stick with plan A for now which is to have the spi comms:)

Absolutely

Time for an update. Did a bit of reading following on from the links Tom posted earlier. Very interesting protocol and not that hard to decode into actual data once you get an understanding of the pulses. So as I said earlier I've gotten a few of these LTC6820 boards on the way from JLCPCB and it will be interesting to see if the LTC6820 works with the Musk variant. No idea until we test. But that said I'd like to double down and have a more generic solution than trying to rely on the LTC parts which could be just different enough to not work or worse give false data.

Then I came upon this :
https://www.analog.com/en/design-center ... b-overview

Reading between the lines it looks like they were using this before asics like the LTC6820 were available. So I went ahead and ripped of their design, changed some bits to suit JLCPCB and with luck we'll have a generic front end to decode two wire ISO-SPI into pos and neg 3.3v level pulses. These can be taken into an FPGA or microcontroller to reform it into usable data. I'll probably use the Mojo V3 FPGA board as it's very nearly identical to that used in the app note design.

Design is up on the repo including those all important JLC bom and placement files for those who won't be restrained.
https://github.com/damienmaguire/Tesla- ... attery-BMS

This thread just gets ever more awesome.

Here we see a full frame of data sent from the master (hv controller). From what I can see at a first glance this looks identical to the format described in the LTC6820 data sheet pages 11 to 15.

So far the only anomaly I have detected is a pulse on mosi that is not encoded on the isospi bus ...