Zombieverter and Tesla SDU Openinverter

[WeeLee]

Hello,

I have a Tesla SDU with the Openinverter board installed but have been following development of the Zombieverter with great interest. Would it be possible to have the Openinverter board control the SDU as normal but also have a Zombieverter onboard to control everything else such as coolant pumps, heating, chargers etc? I assume you'd need to choose a board to be the 'master' to control the HV contactors and set the other board to manual for the contactors or something like that?

Thanks,

Lee

[johu]

Yes you could just bypass Zombie for the drive functions and connect throttle pedal directly to SDU. DC switch and precharge must be controlled by Zombie because charging.

[nubster]

I'm also working on an Openinverter Tesla SDU-based conversion and would love to use the ZombieVerter. I noticed in Damien's latest video there's an inverter menu option named "OpenI" and had the same thought as @WeeLee. Is this menu option the correct one for this setup? Do the boards communicate over CAN when configured this way?

Yes you could just bypass Zombie for the drive functions and connect throttle pedal directly to SDU. DC switch and precharge must be controlled by Zombie because charging.

When you say "drive functions," does this include START and DIR signals as well as throttle? Wouldn't the VCU need to be aware of START and DIR status at all times in order to allow charging, or does the SDU notify the VCU over CAN or something? Are there any other caveats/wiring differences? Is support for stock Tesla SDUs on the roadmap at all?

Thanks,
-Nick

[allard]

Hi all,

How does Zombieverter, in combination with SDU (or LDU), handle the overcurrent event when it is not aware of the tripmode (=1) setting of the OI board in the DU?

Does it just not open the contactors while in drive mode? Or...

I just want to know for sure before deciding that combination of SDU and Zombiverter is a good choice.

Thanks!

[mextavour]

For what it's worth, I'm in a similar situation. Am fairly certain that Openinverter SDU board and Zombie VCU can be used together, interfaced with a combination of hardware and CAN control. I recently started messing with openinverter trying to control an SDU, and have ordered zombie VCU. I'll report back on any progress. I plan to get comfortable with CAN and integrating various subsystems on the bench before installing most EV hardware int the car, so I expect to be in this figuring-out-integration stage for a while...

[Tomas]

Would it be possible to make a simple drop-in board for Tesla driveunits and use a zombieverter to control it?

[johu]

Erm, like this https://openinverter.org/shop/index.php ... duct_id=62

[catphish]

How does Zombieverter, in combination with SDU (or LDU), handle the overcurrent event when it is not aware of the tripmode (=1) setting of the OI board in the DU?

Zombie would not be aware of the error. It will simply leave the contactors closed until you turn the ignition key off. This is the behaviour you want for a Tesla drive unit anyway.

[Volkmar]

Hello,

I have a Tesla SDU with the Openinverter board installed but have been following development of the Zombieverter with great interest. Would it be possible to have the Openinverter board control the SDU as normal but also have a Zombieverter onboard to control everything else such as coolant pumps, heating, chargers etc? I assume you'd need to choose a board to be the 'master' to control the HV contactors and set the other board to manual for the contactors or something like that?

Thanks,

Lee

Hi,

did you get your setup running? I have a nearly similar setup like yours. I bypassed the drive singlas and now they go directly to the SDU.

I have the Tesla SDU with the OI Board, the Zombie VCU, the ISA shunt and BMW LiM, and the master BMS Board from catfish.

Now my problem is: I get communication between Zombie VCU , ISA shunt and BMW Lim, but no communication between Zombie, SDU and BMS.

SDU, ISA and BMW LiM is on CAN1 and BMS is on CAN2.

I think I have to tell the Zombie the CAN IDs of the SDU and the BMS. But how can I setup the CAN IDs and how do I know which IDs are already used for the ISA and the BMW LiM?

I'm very curious to see how you managed the CAN bus communication. I'm probably just too stupid to see it...

thank you!

Best regards

[WeeLee]

I never went down the Zombieverter route. Just stuck with the OI board in the SDU and using ESP32s for various VCU functions. Not got everything working together yet and I just killed my SDU so will be putting things on hold until I get another SDU.

I think you are correct about needing to map the SDU can messages in the ZV. There is a page in the wiki about the CAN messages. https://openinverter.org/wiki/CAN_communication Also node that the SDU and ZV should be setup with different Node IDs to prevent conflict.

[johu]

Zombie uses some fixed CAN mapping for OI (it's probably documented somewhere...) and you have to add the appropriate mapping on the inverter side. That is until inverter firmware 5.27.R
From 5.32.R the inverter has a fixed mapping, not sure if Zombie is adjusted to that yet?

[Volkmar]

I never went down the Zombieverter route. Just stuck with the OI board in the SDU and using ESP32s for various VCU functions. Not got everything working together yet and I just killed my SDU so will be putting things on hold until I get another SDU.

I think you are correct about needing to map the SDU can messages in the ZV. There is a page in the wiki about the CAN messages. https://openinverter.org/wiki/CAN_communication Also node that the SDU and ZV should be setup with different Node IDs to prevent conflict.

ohh...I´m sad to hear that your SDU was killed! Hope you get soon a new one...I know how hard it is, if you are waiting for a component, that is so crucial for the progress of the project!

I have studied the wiki page intensively, but I understand very little of it.

Now I ordered this component: https://openinverter.org/shop/index.php ... duct_id=78 and hope to be able to read out and set the relevant parameters via the OpenInverter Ecosystem respectivley the programm from Mr. Hübner on github.

I will keep you updated!

[Volkmar]

Zombie uses some fixed CAN mapping for OI (it's probably documented somewhere...) and you have to add the appropriate mapping on the inverter side. That is until inverter firmware 5.27.R
From 5.32.R the inverter has a fixed mapping, not sure if Zombie is adjusted to that yet?

Thank you for your answer!

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]

By the way...I would like to thank ALL contributors of the Openinverterforum.

Johannes, Damien, Charly and all the others...thank you very much! You make things possible without which countless projects would only be dreams.

So to say...you make dreams come true!

[Steve16]

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 problem in my initial low voltage bench testing of the 2. I have put the SDU on Zombie CAN2 and confirmed impedance. Firmware for Zombie is 2.17A and for SDU is 5.32R. The only signals connected to the SDU are 12V, GND and CAN. I assume that with communication I will be able to read TMPM and TMPHS on the Zombie from the SDU. But this is not the case in the Off Mode. I can read the values directly from the SDU over wifi. Also, the SDU doesn't go into run mode when Zombie does. I'm wondering if I have a parameter set wrong or if I need to connect more signals. Parameters for both are attached.

[Bratitude]

Have you gotten the sdu running with the oi board first? I would get that working, then you can proceed to having the zombie run it over can.

There is not much you need todo to get the zombie running an Io board. Just changing the controllers to can, no need to set any id’s

[Steve16]

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.

[Steve16]

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]

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.

Okay good to hear so that if confirmed working.

Zombieverter:
set the same contractor controls parameters you had on the Tesla board, set the inverter pram to oi board.
Remove all other can devices from the zombie. just have your shunt and Tesla drive unit connected.
set the inverter can bus to what you have the Tesla board connected to.

Verify contractor control/precharge functions under zombie control



Tesla board: set throttle, start, and direction to can.


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

[Steve16]

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 throttle, start, and direction to can.

The only parameters I see on the SDU that can be set for CAN control are throttle and cruise. I don't see any for start and direction. There are options for CANbus rates. I have tried 500k and 250k without success.

After several experiments, I'm still unable to get the operation I expect. Maybe I'm expecting the wrong thing, so I will backup. With LV only connections, I can get correct contactor operation with the SDU and contactor control wired to the SDU and independently with the Zombieverter with contactor control wired to the Zombieverter.

When controlling the SDU via CAN, which device is wired to the contactor controls? I'm thinking it is to the Zombieverter - this works for contactor control but I never see the SDU go into run mode, it is "waiting for start." While operating via CAN, what changes made with the Zombieverter can I see in the SDU OI spot values. I have assumed that opmode, status, tmpm, tmphs will be the same on both. At a minimum, I expect to see the SDU tmp measurements on the Zombieverter and I have not seen this. Will the pot measurements also match? Is there another way to confirm that I'm getting CAN communication between the Zombieverter and SDU without a bus monitor? I have been able to confirm the CANbus operation of the Zombieverter with the shunt. I need to do the same with the SDU.

[johu]

Digital IO control is always on, you don't need to enable it separately.
The values you expect to see must be mapped explicitly on the SDU side, not sure where to but others will know.

[tom91]

https://openinverter.org/wiki/CAN_commu ... _CAN_-_new!

Here is the new info, I do not know if the changes been made to the ZombieVerter to align it after the Open Inverter software changed.

EDIT 1: I reviewed the Zombie code, it is all there according to the wiki. However all the recieved values are hardcoded and the Zombie is not coded to be able to flash this profile to the OI inverter so this will need to be manual input.

There is no documentation to be found on the wiki about what the OI inverter should spit out. Who did these code changes?!?

Edit 2: Damien wrote the section and will provide me some details tomorrow to dump onto the wiki, it is in one of his videos but no one has published the info onto the wiki.

[Steve16]

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.

[Steve16]

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 firmware and have tested with OI firmware 5.20, 5.27, 5.32, and 5.35 and found the following behaviors, which I need help in understanding. The actual testing order was 5.32, 5.35, 5.27, 5.20, 5.32 and several tries between 5.27 and 5.32. The Zombieverter was kept on permanent 12V and the SDU was on T15. To reset the Zombieverter and SDU to off mode, T15 was power cycled. Here are my findings:

OI 5.20 - parameters map but no information passes from Zombie to SDU, mapping lost with power cycle
OI 5.27 - parameters map and pass to SDU, mapping is maintained after power cycle. I do not know when the mapping was saved. I tried saving parameters earlier with version 5.32 and 5.35. They were automatically there when I flashed back to 5.27.
OI 5.32 and 5.35 - parameters map, pot data is passed to the SDU, canio is NOT passed, mapping lost with power cycle. Loading parameters from flash does not recover the mapping.

Canio is only passed with 5.27 and I can get the SDU in run mode using the Zombie start signal input as expected immediately after power-up. Versions 5.32 and 5.35 will NOT start from Zombie and do start from the SDU start signal. This behavior can be repeated by flashing between 5.27 and 5.32, no other changes needed. I have included the SDU parameters from my last test with 5.27 firmware in case it is useful.

[johu]

Mapping must be explicitly saved to flash which happens when pressing "Save Parameters to Flash".

Starting version 5.32 pot, pot2, canio and some others are no longer user mappable but are combined to one single, time-out and consistency checked message, read here: https://openinverter.org/wiki/CAN_communication . The reason was safety concerns.

So in this version the specified items are already mapped and any manual mapping to them is removed on each power cycle.

I'm not sure if Zombie uses this new method yet. I think Tom said it doesn't

Zombie uses the new method!