Thanks, I will begin looking for the best pressure equalization valve and add my findings to the wiki.

I'm in the process of designing my battery box. Checking the forum and wiki, it seems the general consensus is that it is better to seal the box. My climate has an annual temperature range of -5 to 40C. Is it a good idea to include some sort of pressure equalization valve and/or a drain for moisture?

Yes when supplying just 12v and ground the power light stays on but actty led does not light. Any ideas on what I could try or test to further figure out the issue? I’m just stuck here


Just to confirm, did you disconnect from the PCS for this test? Also, you might try removing the wifi board ...

I have hooked up the Zombieverter and shifter on my bench and it works beautifully. Thank you to all who developed this feature. I tried it with Can buses 1 & 2 individually and together - all worked. Does the Zombieverter use the redundancy of the 2 buses, or is there a reason to connect both buses ...

I assume the CAN-able bootloader is flashed to the VCU as well?


Is there a way I can verify the version of the bootloader? I'm using the version that came with the Zombie board.

I looked into boot at powerup more closely. The Zombie will send the "hello" frames on 0x7DE until it gets a ...

What are the settings of your CAN logger when logging? Is it set to listen only?

It sounds like possible that Tesla SDU does not acknowledge any CAN frames.


I found the settings. My logger was set in normal mode. When I changed to listen only, the Zombie does not start the SDU. It does start ...

I was not able to easily find the settings. I also questioned if it was just listening. I will look again. The program I'm using is BusMaster.

The SDU and Zombie are terminated.

In trying to get as close to Damien's implementation as I can, I added an ISA shunt to the bus (I don't have any of the other components). It is stubbed about 1/3 of the way between the Zombie and SDU and is unterminated. With power to the shunt, Zombie DOES start the SDU. To summarize the rest of ...

I tested with SDU power supplied by a relay controlled with the inverter power relay pin. It seems to be part but not all of the solution. It does not put the SDU in run mode alone. When I tried to get a log, it does put the SDU in run mode. I believe I isolated the difference: when the logger is ...

tom91 wrote: ↑Wed Dec 04, 2024 10:18 am Please use the Zombie- Inverter Power relay pin. This is a pull to ground pin to switch a relay that then provides power to SDU.

I will do the test when I get home this afternoon.

I have attached a log. Wasn't able to get my hardware working with savvycan but got it working with busmaster.

Power sequencing was mentioned earlier. My bench setup has both the SDU and Zombie power up at the same time (including T15) from a 12v car battery through a 5A fuse. I do not have a ...

I have tried upgrading to Zombie firmware 2.20 and then loaded Damien's parameters. In both cases, the SDU stays in waitstart when Zombie goes into run mode with Zombie start. I have compared Damien and my parameter files for Zombie and the SDU/LDU but have not recognized any differences that might ...

When I start on Zombie, din_start remains "OFF" in the web interface. I assume that is low.

Yes, the SDU shows WaitStart and will go into run mode when I apply the SDU discrete start signal, independent of Zombie state. I will check din_start.

I went back to bare bones wiring of power and CAN between Zombie and the SDU. I also used the Zombie start signal. After mapping the transmit values on the SDU as listed by Tom, Zombie receives data from the SDU, Zombie does not put the SDU in run mode using the Zombie start signal. After power-up ...

I reviewed the section of the video again where Damien says can control is working, but he does not give any details. Since he is very good about giving details, I assume none are needed beyond selecting OpenI for the inverter. After clearing all mappings, I tried again and got an overcurrent error ...

Johu, thank you for your patience and for repeatedly explaining the fixed mapping change here and in other topics. I believe I finally comprehend the can mapping described in the wiki and Zombie behavior: Zombie does not have the user selectable or automated capability (as of firmware 2.17) to ...

I have been experimenting with can mapping the parameters needed to pass between the Zombieverter and SDU and have found interesting behavior. I have been trying to map the values canio and pot to address 0x3f as directed in the CAN communication wiki listed above. I'm using Zombieverter 2.17 ...

Thank you. I had looked for a video but clearly missed it. I will look again. I will also be happy to update the wiki If I find anything to add.

What zombie schematic are you referring to? I know there was a pinout that had can 1 and can 2 flipped.


I'm using the pinout currently on the wiki. I can successfully get voltage data from the shunt using either bus correctly corresponding to the names in the pinout.



Tesla board: set ...

Yes, the SDU is running with direct inputs to the OI board. This has been done with 12V only, no HV. Is there a parameter on the OI board that needs to be set for CAN control? From what I've read on the forum it is automatically OR'ed with the direct inputs.

Bratitude wrote: ↑Fri Nov 22, 2024 3:44 pm Have you gotten the sdu running with the oi board first?

Yes, the SDU was previously running with the OI board. I will check it again.

Yesterday I updated the Zombie...and today, I will update the Inverter...I hope, the communication to the inverter will be running then...I am very curious to see what happens...

I will keep you updated!

Volkmar, did you get your Zombie to communicate with the SDU? I'm currently having the same ...

I decided to try this on my Tesla SDU with OI board using 5.32 firmware. It appears to operate the same as the zombie. I believe consistency across the OI family of products is more important than making a change to the zombie, especially since no one has noted any previous issues. Thanks for all of ...