openinverter forum

Analog front end for the isospi decoder in production at JLCPCB.

Got a chance to visit the battery today. Made some progress.

Test setup : hvcontrol pcb as before with logic analyser / scope on the batman header.

Connected to one port of one bms board at a time. At first nothing happened. No sign of data change on the analyser but could see extra data appearing on the scope. Then remembered I was not probing one pin (with test lead 4 in the pictures) as I had assumed it was just a 3v3 supply. Wrong as usual. When connected to a bms board this pin wakes up and squirts data.

Logic analyser files of this pin on the repo:
https://github.com/damienmaguire/Tesla- ... /OneModule

I'll upload the scope captures later. Log files taken with a Digilent Analog Discovery 2 and Saleae Logic.

Scope captures. "Umknown" is the pin 4 from above that wakes up when a bms module is connected.

Another delivery from jlcpcb. Let's find out if the LTC6820 speaks the same lingo.

So, I think we have an answer. Short version : The Tesla version of ISO-SPI uses chip select and data pulses with widths far outside of the spec for the LTC6820 so off the shelf LTC hardware will not work with Tesla Model 3 battery modules. Very boring video on the way explaining the findings.

Fascinating

Does the SLOW pin have any impact on the behaviour?

Kevin Sharpe wrote: ↑Mon Apr 13, 2020 4:19 pm Fascinating

Does the SLOW pin have any impact on the behaviour?

No. Just limits max clock speed to save power.

Jack Bauer wrote: ↑Mon Apr 13, 2020 5:12 pm No. Just limits max clock speed to save power.

Yeah... just looking for random things that might explain what's going on

It's interesting that the BATMAN delay you measured on chip select (~5us) is similar to the LTC6820 start up time tREADY (8us max). I wonder if BATMAN is expecting slaves to be in idle mode and waiting for them to wake up? Figure 15 in the LTC6820 data sheet looks interesting and maybe the EN pin has some significance

"Figure 15 demonstrates a simple procedure for waking a master (MSTR = 1) LTC6820 and its connected slave (MSTR = 0). A negative edge on CS causes the master to drive IBIAS to 2V and, after a short delay, transmit a long +1 pulse. (If CS remains low throughout tREADY, the LTC6820 would first generate a –1 pulse, then the +1 pulse when CS returns high). The long pulse serves as a wake-up signal for the slave device, which responds by driving its IBIAS pin to 2V and entering the READY state."

The pulse widths are the issue. The LTC6820 will reject the Tesla pulses as they are so far outside of spec. Chances are the tesla chips will do the same as the LTC pulses are probably far outside their spec. To talk to these things We'll need the analog front end board above (due from JLC this week) and most likely an fpga.

Very well documented Damien, hats off. I gave up when the LTC6820 solution turned out to be a none starter, did not dig into why.

If they literally increased all the pulses by a factor of 2 I wonder if any of the SPI data still holds true. But then again reverse engineering it will still be possible.

Jack Bauer wrote: ↑Mon Apr 13, 2020 7:41 pm The pulse widths are the issue.

OK, thanks for the clarification

Tesla BMS connector cell count

Got my little analog front end boards in from JLC. To my amazement they work:) We can now translate Musk-spi into 3.3v pulses ready to feed into an fpga or micro for decoding into data.

I now have a PACK 25S battery pack. Can I remove the original control board in the middle? Then connect a 25S third-party BMS to make it work?

Leo Max wrote: ↑Thu Apr 16, 2020 8:18 pm Then connect a 25S third-party BMS to make it work?

You can do anything you want but whether it's a good idea is for you to decide

If you want to discuss this further please start another thread so that we can focus on Model 3 battery hacking here.

Am I late to the party?
Thought I'd post some ltspice goodness.

This should recover a true SPI data stream with clock, data and CS that can be processed by a standard SPI peripheral.

Delayed clock and removed OR gate

Thanks Johannes. Building this will be fun:)

Connector used on the board for the isospi is Molex Mini50 Series, 34912 Series Number, 1 Row 2 Way Surface Mount Plug PCB Header.
Black for BMB-A (batman)
Part number : 34912-8020
RS Stock No. 131-4729

Grey for BMB-B (robin)
Part number : 34912-8021
Mouser No: 538-34912-8021

New design transciever board in production at JLC. Based on a Xilinx Spartan 6 FPGA running at 100MHz. Ultimately will provide receive and transmit with spi and uart interfaces. Couple this up to Simpbms and we should be good to go:)

....ok I was going to put a vga port on it but I stopped myself

Jack Bauer wrote: ↑Mon Apr 20, 2020 5:26 pm New design transciever board in production at JLC. Based on a Xilinx Spartan 6 FPGA running at 100MHz. Ultimately will provide receive and transmit with spi and uart interfaces. Couple this up to Simpbms and we should be good to go:)

....ok I was going to put a vga port on it but I stopped myself

Does this mean I can buy this product within a month?

Well done JB / DM! Connects to the 2-wire connection from the module boards?

Yeah will plug into the existing harness. Of course it probably won't work so don't get too excited just yet:)

Jack Bauer wrote: ↑Mon Apr 20, 2020 5:26 pm New design transciever board in production at JLC. Based on a Xilinx Spartan 6 FPGA running at 100MHz. Ultimately will provide receive and transmit with spi and uart interfaces.

This is fabulous

Can I suggest that you keep the FPGA design closed source and sell the PCB as a tested and supported product? We really do want to wave you off to Lanzarote one day