openinverter forum

I have these Mercedes EQS modules. I am integrating these into my 1971 Beetle project, and right now I am trying to find the least expensive path forward for charging and BMS.

What I know: These are from a Mercedes EQS. They are CATL modules, 18s1p, 66v, 9+ kWh each. I have five, which I selected because they will fit in custom floor-mounded boxes and give my Beetle decent range and power. The prime mover is a Tesla rear SDU.

What I think I know: The black boxes on each module is a slave BMS. The 26 wires coming into this slave are probably 18 cell voltages, ground, temp, current sensors, etc. The open connector has 4 wires, which I ASSUME is for the CANBus.

What I don't know: So much!

CanBus is 2 wires, CANH and CANL. But there should also be a 12v in and a ground, right? Without 12v the CAN won't wake up and send signals? I have a CANBus logger, but I need help trying to figure out which wire is which. Is there a procedure to figure it out? So, I tried using a multimeter across the pins, and I did see 12v from a couple pins, which diminished to zero. Assuming that I discharged a capacitor? Can I assume that the pin that was 12v temporarily was the 12v in wire? I have 4 other modules that probably have charge in their capacitors still.

I have tried researching these connectors and these BMS, and there is not much info out there. One German website inscrutably calls this a "control module". I also haven't had much luck decoding Mercedes wire colors. Although each wire is orange with a stripe, I would guess that orange/black is B-, orange/red is B+, and orange/green, orange/blue is the CAN signal? I don't want to fry anything by tinkering without more knowledge.

My goal: I want to verify that I am dealing with a BMS slave, and log the CAN signals, so that I can send those logs to Vero Electric to see if they recognize the format and possibly if the Vero BMS 2.0 can run them. That would be an ideal solution.

If I cannot figure that out, I can go a full BMS. I would love to use the OpenInverter BMS cards, but they are 12-channel and ideally I would have 1 18-channel BMS board per module?

This is the advice that I am looking for. Happy to share what I learn, because these EQS modules tick a lot of checkboxes for EV conversions: They are compact, relatively light, sturdy, high-voltage, and at the very least have easy-to-access wiring harnesses!

Open up the slave module and take detailed pictures of the slave boards.

No point speculating.

Thanks in advance for your help!

Okay, what I see: 18 voltage channels, 2 CAN channels?

The traces are so tiny I need a magnifying lens. But it appears the 4 wires in the harness use the outer 4 pins on that connector (out of 8) which each seem to go to a diode and an oscillator? No obvious 12v or ground. Can you make sense of this?

I don’t see any traces on the back so I think those inner 4 are just part of the Hella connector and not used in this circuit.

LTC6813 so its has ISO-SPI

https://www.analog.com/media/en/technic ... 8134fa.pdf

Old chip for something so "new"

Excellent, thank you.

On the one hand getting a CANBus reader was a waste. On the other hand reading the specs of the chip makes more sense. It can handle 18 cells which is probably why Mercedes went with 18s1p in the module.

Does “Passive cell balancing up to 200 mA (max.) with programmable pulse width modulation” mean it can do some balancing without the master IsoSPI controller?

Daveturpin wrote: ↑Fri May 31, 2024 1:22 am Does “Passive cell balancing up to 200 mA (max.) with programmable pulse width modulation” mean it can do some balancing without the master IsoSPI controller?

No, passive balancing means it balances by switching resistors across the cells. It is a a dumb front end slave so will report data to the IsoSPI master and the master will do the calcs and logic and then send commands out.

Gotcha.

And... Do you know of a BMS that can communicate via isoSPI, or am I going to need to build something custom, centered on this LTC6820 chip I keep reading about?

This unit is pricey but it appears to have the same LTC 6813 chip my slaves use...

https://stealthev.com/product/aem-batte ... em-master/

You will need to write custom code to work with the setup you have. The Dilithium bms https://www.thunderstruck-ev.com/mcu.html might work

As their satellite uses the same chip https://www.thunderstruck-ev.com/bms-satellite.html

Best to reach out to Thunderstruck

I will do that, thank you. I will post additional information here for others when I get it and if I get the OEM satellite BMS working. (I realize that I have been using the antiquated "slave" terminology; apologies)

Looks like the DC1941D demo card is what I need to test and log these isoSPI signals. $88.

Thunderstruck said that the MCU can “theoretically” run the satellite BMS modules but recommended against it. (Even if it would work I’m sure they’d say that for liability reasons)

I’ll maybe get it anyway and then use my new demo board to explore further…

Okay I’ve learned that the DC1941D will probably work but you also need either the DC590B usb interface or the Linguino interface for it. Picked up the former on eBay and trying to get the SPI wires right to see if I can get data.

Also the connector to the SPI interface: found it on Digikey:

https://www.digikey.com/en/products/det ... 1/10478170

Here is my setup: Computer connects to the DC590B demo card. This can interface with a bunch of stuff (including a gas gauge driver I also have) but I am connected to the DC1941D. The RJ45 uses ONLY pins 1 and 2, which I connected to a connector so I can experiment with the final connection to the Mercedes BMS satellite. Now I don’t know which is SPI in and which is SPI out, and of those choices and don’t know which is IM and which is IP… so 4 possible configurations to test.

I still don’t know if the MCU will work; don’t want to drop $480 just to test it, at least without more data.

More progress! So, long story short. The "Quickeval" software and DC590 board does NOT work with the LTC6813 18-cell monitor.

So I tried using an Arduino Uno to read the cell voltages directly. That doesn't work, without building a separate LTC6813 circuit for isoSPI to SPI conversion.

Finally I broke down and bought the Linduino One (DC2026C), which interfaces with the LTC6820 isoSPI board.
Took a little setting up. The LTSketchbook available on GitHub doesn't seem to have the right part number, but I found the right code and installed it, and using the above setup, was able to talk to the modules!
And I immediately freaked out. I checked all 5 modules, and 2 of 5 are reporting less than 3 volts per cell (bad!)

But then I checked the MODULE voltage, and each are at more than 64 volts... Then I realized each of those "bad" cells are showing EXACTLY 2.7306v. I checked the documentation and this corresponds to a return of 0x00. And then I further realized those two modules are "left handed" modules. Which means I am probably reading the wrong "side" of the isoSPI...

So... Phew. I believe that I have a working way to communicate with the satellite BMS cards on the modules, and I believe that all my modules are good (and apparently at about 50% SOC?)

Also big takeaway: If I can communicate then the Mercedes modules are not using some sort of proprietary control suite. So... PERHAPS I will be able to use this to act as the Master BMS with some additional code (I found some SAE team code that might work) Or PERHAPS I can use the Thunderstruck BMS off-the-shelf?

So you are finding so far what I said is true.

Good to know Mercedes have not opted to try and lock down their BMS for no real reason what so ever.

Another option to communicate with ISOspi modules is Arduino shield DC2617A from Analog Devices (they are in short supply though), this will plug into an Arduino board (Uno a bit slow?, Uno R4, Duo) this provides CAN bus and ISOspi. I have hacked the Simpbms code to work with Uno R4 and LTC6812 based Polestar 2 satellite modules, could be adapted to work with LTC6813 satellite modules. It would be nice to see a ISOspi version of EVS-BMS(new Simpbms) hardware, this would make it simple to use ISOspi based BMS modules.

johnlr wrote: ↑Thu Jul 11, 2024 11:31 am It would be nice to see a ISOspi version of EVS-BMS(new Simpbms) hardware, this would make it simple to use ISOspi based BMS modules.

The demand of this has been low, I have designed the EVS-BMS with an option board. I will review if ISOspi with the LTC6820 is possible, did not look into when doing the design due to the chip being on impossible lead times.

I have also ran the DC2617A, but with a teensy 3.2 (simpBMS) and the polestar modules.

tom91 wrote: ↑Thu Jul 11, 2024 9:14 am So you are finding so far what I said is true.

Good to know Mercedes have not opted to try and lock down their BMS for no real reason what so ever.

Yes, and I am very appreciative of the help you are giving me. When I talked to Thunderstuck, though, they recommended against using their MCU without also using their satellites. (Which are expensive and would require me rewiring EVERYTHING which seems both counterproductive and hazardous)

Everything sinse then has been me learning what you already know! Last month I didn't even know what isoSPI was (or that Arduino uses SPI; I have used Arduinos for ages and didn't know this).

I haven't used the LTC6812 but from what I understand it is pretty similar to the '11 and '13. The '11 Does 8 cells, the '12 15, and the '13 18.

Hey, i plan on using the exact same modules, did you get the BMS Interface working? Maybe you can post your code Snippets here so we can work on getting it running together

Time to announce an answer to the question: Can the MCU run the Mercedes BMS satellites?

YES.

Here's what you need to know. First, make sure you follow all the Thunderstruck MCU instructions. You need to set up a serial communication port using PuTTY, configure it correctly, then, at a minimum connect the 12v AND KSI to 12v, and the associated ground to ground. Here is the basic setup, I am using my LiFePO4 battery for power:
The MCU can handle 16 satellite BMS boards, for a maximum of 288 cells. I am 96 cells in 5 modules, so I only need to use one of the two provided IsoSPI ports. To test, I crimped open female tangs on each wire and tested:
There are 4 wires on the Mercedes communcation plug. Just have to figure out which are which. 4 possible options for connecting them correctly, and I got it right literally on the fourth try. Test by running the "show ltc" command in the serial prompt, until:
So that's one down. Important data: orange/blue is IPI, orange/green is IMI. Which means the orange SHOULD be IPO and the orange/black SHOULD be IMO. Made another long twisted pair to go from there to the next module:
And... This time, first try.
Now that I confirmed those, the other 3 are easy (assuming no damage to the satellite modules, but I checked those previously).

So, finally, Thunderstruck MCU orange (IPO_A) to Mercedes orange/blue (IPI) and MCU brown (IMO_A) to Mercedes orange/green (IMI), then Mercedes orange (IPO) to the next orange/blue (IPI), and Mercedes orange/black (IMO) to the next Mercedes orange/green (IMO), etc.

(Note I am getting "In HVC!" warnings on each cell. HVC is "High Voltage Cut-off", which I have not configured yet. The individual cell voltages are ar 3.55v, or somewhere between 20-50% SOC)

The wiring harness done, and now my eyes hurt:

Did you ever get a BMS to talk to the EQS modules? If not, I have developed one that can. Let me know if you are interested. It's still in Beta test, but I think you can handle it.

Thanks to Daveturpin for figuring out the isospi wiring procedure!

I work at Thunderstruck Motors. Here are some Thunderstruck MCU compatibility issues we noticed with the EQS satellite boards and the proposed wiring (above):

Isospi errors show when connecting modules to both A and B neworks on the MCU.
Missing cells show on the 5th module in series when using a single isospi network with 5 modules - network A for instance on the MCU.
Enabling balancing in the MCU does not appear to create actual balancing current at the cell. Testing in progress.

The first two issues are corrected by connecting the module connector wires so that the IPO/IMO (out) wires are reversed with the IPI/IMI (in).
This can be done by connecting the MCU isospi "out" terminals to the satellite "in" terminals (change noted below).

Module wire color (manufacturer harness):
org/blu = IPO
org/grn = IMO
org = IPI
org/blk = IMI

It should be possible to connect the MCU to the opposite end of the module string if you first made connections with the method Daveturpin discovered.

Balancing is still being tested. I'll enter results here if we have any positive results.

Any errors noted here? Please reply with corrections.
Thanks!

I managed to get my hands on an EQC batterypack too, so very interested to see how far people have gotten with this!

I don't know yet If I want to use the packs as home energy storage or to replace my current (extremely deteriorated) 30 kwh leafpack.

Both are an option though!

My buddy and I bought an EQS pack for our conversion projects, and I was excited to stumble upon this thread. We will each be using half the pack (6x modules) in our projects.

I appreciate everyone’s help here; it gave me a huge head start!

With the wiring recommendation from TSMJPalm, I have one module talking to an AEM BMS Mini Master.

I’ve confirmed that balancing works with cells 1, 2, 3, and 4. I cut the POS wire going to cell 1 and 3 and put a multimeter in series with them. There is 20-60mA of current when balancing is commanded. I plan to order a current clamp that can measure down to 10mA to test that all balancing works.

Balancing was initially tested by controlling the AEM BMS Mini Master with just Busmaster (PC CAN program). It also works when the AEM VCU275 is controlling the AEM BMS Mini Master. The balancing feedback works as well.

I have discovered 2 issues around temp sensing:

1. From what I can tell from online pictures of the unsealed AEM BMS Satellite, the AEM BMS uses different GPIO pins on the LTC6813 chip for cell temp sensors than the EQS BMS board.
2. On the EQS BMS board, I’m not seeing board mounted temp sensors.

Issue #1: It looks like the AEM BMS uses the following GPIO pins:

AEM BMS from online pictures looks like:
GPIO1: Batt temp sensor 1
GPIO2: Batt temp sensor 2
GPIO3: Batt temp sensor 3
GPIO4: PCB Therm 1
GPIO5: PCB Therm 2

EQS BMS board GPIO pins:
GPIO1: Goes through a 1k ohm resistor to Vref2 (it’s not actually the LTC6813 Vref2, but let's assume it’s the same function)
GPIO2: Goes to a via
GPIO3: Goes through 1k ohm resistor and then a via mid tap 10k ohm resistor to Vref2
GPIO4: Goes through 1k ohm resistor to black temp sense wire. (Has 10k ohm resistor to Vref2)
GPIO5: Goes through 1k ohm resistor to brown temp sense wire. (Has 10k ohm resistor to Vref2)
GPIO6: Goes through 1k ohm resistor to light blue temp sense wire. (Has 10k ohm resistor to Vref2)
GPIO7: Goes through 1k ohm resistor to the via and mid tap 10k ohm resistor to Vref2
GPIO8: Goes through 1k ohm resistor to the via and mid tap 10k ohm resistor to Vref2
GPIO9: Goes through 1k ohm resistor to the via and mid tap 10k ohm resistor to Vref2



On the EQS board, I cut the trace on GPIO1 going to the 3V Vref2 trace and attached it to GPIO6. (Don’t judge my soldering yet, I ordered smaller wire to replace this with ).



I'm now getting resistance for temp sensor 1, but it isn’t the correct value. My theory is that the ISO-SPI output resistance valves are scaled differently on the EQS Chip. Scaling the thermistor resistance calibration values by 40% seems to fix this issue (this needs more testing).



One weird thing is that if I unplug the EQS BMS from the battery and plug it back in, the temp resistance data is wrong for some time. I’ve had all of them read 13.2k ohms and go up and down together. After some time, it goes back to displaying the actual values (around 5k ohms for room temp).

Issue #2:
In the AEM BMS manual, it says that the BMS board temp is monitored so that balancing can be turned off if the resistors/board gets too hot. I’m not seeing temp sensors on the EQS board.

I need to do a long balancing test with a thermal camera. If it doesn’t get too hot, I can probably have the 2x GIPOs for board sensing tied to cell temps. Since the thermistor resistance calibration for the board PCB isn’t available in AEM Cal, the VCU thinks the BMS PCB is 40ºc for the board at room temperature. I’d assume it shuts balancing off around 70-80ºC, so we should be ok there.

Unknowns:

• I don’t know if GPIO1 is for monitoring the 3V supply for the thermistors and if there’s custom programming on the chip. So far, no issues
• I don’t know what GPIO2 and 3 are doing / what will happen when I connect cell temp sensors to them.

I'm looking forward to diving into this more, it would be a really clean setup to use the original BMS!

TLDR: Cell voltage reporting and balancing seem to work. But BMS PCB and cell temp sensing are an issue.