ZombieVerter VCU Support

[chuuux]

Have you selected GS450H from the inverter menu?

Of course. I've choosen GS450H and E46.
It was my fault with serial wiring (+/- swap). Now pulse seems similar with yours.
But still no data fron inverter in web interface and inv status is "off".
I'm going to try with another Lexus inverter tommorow.

[chuuux]

OK, i can select GS450H now and i'm seeing HTM / REQ & CLK being generated. All 3 signals look good.

I'm not getting anything back from my inverter on the bench on the MTH line, so i'll need to investigate that a bit more. I have flipped REQ and CLK in the harness, so that should be ok. I'm going to scope the inverter connections and see if i can spot anything.

So, I have exactly the same troubles with serial communication between the inverter and VCU. HTM / REQ & CLK being generated and nothing on the MTH line.
Should every line be connected to negative pair contact on the other side, right? like REQ+ -> REQ- ?
And also I don't have any voltage on the "Inverter power", "Precharge" and "Main contactor" pins in the "Run" opt mode.

[EV_Builder]

On differential comms + goes to + en negative goes to negative.
I do think that tx goes to RX and RX to tx.
As seen from both devices.

Damien can you confirm?

[Jack Bauer]

Setting up a support thread for the ZombieVerter VCU. Please post questions regarding hardware and software in this thread and do update the wiki with information as it becomes available.

11/06/21 : NOTE : This project is on BETA release only at this time!

[Jack Bauer]

First : make sure you are wirring as per the wiki : https://openinverter.org/wiki/Lexus_GS450h_Inverter

Is it a GS450H inverter or some other variant?

[Dilbert]

OK, i can select GS450H now and i'm seeing HTM / REQ & CLK being generated. All 3 signals look good.

I'm not getting anything back from my inverter on the bench on the MTH line, so i'll need to investigate that a bit more. I have flipped REQ and CLK in the harness, so that should be ok. I'm going to scope the inverter connections and see if i can spot anything.

So, I have exactly the same troubles with serial communication between the inverter and VCU. HTM / REQ & CLK being generated and nothing on the MTH line.
Should every line be connected to negative pair contact on the other side, right? like REQ+ -> REQ- ?
And also I don't have any voltage on the "Inverter power", "Precharge" and "Main contactor" pins in the "Run" opt mode.

My problems were all of my own making and based on my wiring .

Based on your above description, you are seeing nothing on the MTH lines coming from the inverter. So either the inverter is not seeing the REQ signal or the inverter is not seeing the CLK line. Once the inverter gets both these signals it will output data on the MTH.

One technique i used for debugging mine was doing continuity checks from the 4 CAN drivers on the VCU all the way to the inverter connector, checking that each pair was connected correctly.

[chuuux]

First : make sure you are wirring as per the wiki : https://openinverter.org/wiki/Lexus_GS450h_Inverter

Is it a GS450H inverter or some other variant?

I use Camry inverter G9200-33171 (2013 - newer that described in the GS450H wiki). Bassmobile said that he has not any issue with it and GS450H Drive unit in the Lexus GS450H VCU Support Thread.
About wiring: I've tried both variants of serial wiring. Both unsuccesful. What is correct? REQ+(vcu) <-> REQ+(inv)?
I've met this kind of serial protocol in the first time, so I'm not sure how tx and rx are calling.
Other wiring is correct I beleive.

[chuuux]

My problems were all of my own making and based on my wiring .

Based on your above description, you are seeing nothing on the MTH lines coming from the inverter. So either the inverter is not seeing the REQ signal or the inverter is not seeing the CLK line. Once the inverter gets both these signals it will output data on the MTH.

One technique i used for debugging mine was doing continuity checks from the 4 CAN drivers on the VCU all the way to the inverter connector, checking that each pair was connected correctly.

Thanks. I'll try to move this way.

[Jack Bauer]

The 2013+ is a different inverter and most like uses a different serial stream to the older model.

[Dilbert]

The 2013+ is a different inverter and most like uses a different serial stream to the older model.

Sorry i thought he wasn't seeing any mth data at all from the inverter on the scope.

Ok so he needs to capture the mth data on the scope so we can work out the length and see if it's similar to prius / auris etc...

[chuuux]

I've checked the serial lines wiring on both ends by buzzer and all looks good.
Now I try to understand the order of status changes and switch outputs activations.

1. Ignition On = Pin "Ignition T15 In" +12v = optmode "Off" = status "WaitStart"
2. Push Start button = Pin "Start" +12v momentary = optmode "Run" = status "None"
but switch outputs: "Inverter power", "Precharge" and "Main contractor" are still 0V. I've understood "low side switch" meaning now.

[chuuux]

Can a lack of cable shielding critically degrade the REQ and CLK signal, so it doesn't start MTH send? I use simple foiled twisted pair with no connection shield on the inverter side.

[chuuux]

I've tried to get MTH signal from 3 different inverters with the same results: Camry 2013, G9200-30070 (Lexus GS300h I guess), and Toyota Aqua (I choose Prius Gen3 in the web interface with it).

[Dilbert]

I've tried to get MTH signal from 3 different inverters with the same results: Camry 2013, G9200-30070 (Lexus GS300h I guess), and Toyota Aqua (I choose Prius Gen3 in the web interface with it).

When you look on the scope at either of the MTH pins (+/-) are you not seeing any data?

That is very strange that no data is coming out on MTH, I've worked with the GS450H inverter and a range of Yaris/Auris/Prius boards, once they get a valid CLK and REQ signal, they all output an MTH data frame.

To answer your above question, no shielding won't make any difference in getting this to work on the bench.

I'm not sure which board you are using, but on the STM32 based Zombie inverter board, we flipped the REQ and CLK pins, as there was no timer available on the CLK pin, so we made that the REQ pin. I would disconnect the connector at the inverter end and verify CLK and REQ are on the correct pins.

[Dilbert]

I want to start developing the main state machine, based on the above diagrams. I've updated my fork so i can see the GD_Zombie branch now. I'm having a problem compiling the firmware:-

include/stm32_vcu.h:7:10: fatal error: stm32_can.h: No such file or directory
#include "stm32_can.h"

It doesn't look like this file is in the repository.

[Jack Bauer]

Did you do make get-deps?

[Dilbert]

Did you do make get-deps?

My forked copy doesn't seem to have libopeninv present locally which is causing the issue. I can build from the main GD_Zombie repository, I'll need to look at it some more. I'll probably just clone down my fork again on my laptop.

[EV_Builder]

I think that If you use the clone option you need to doit with the recursive option. Then it will also get the dependencies.

[Dilbert]

I think that If you use the clone option you need to doit with the recursive option. Then it will also get the dependencies.

I cloned my fork and everything came down and is compiling too. I'm actually using the linux sub-system on windows and it works quite well.

[Dilbert]

Here is the initial enum for the VCU States, I'll code up something in the next couple of days to test on the GD_Zombie

enum VCU_STATES{
SYSTEM_INIT_STATE,
SYSTEM_LOW_POWER_IDLE_STATE,


SYSTEM_PRE_CHARGE_B_MINUS_CHECK, // should see zero current as we close pre-charge relay, if a B- contactor used
SYSTEM_PRE_CHARGE_TEST, //should see zero current as we close B- contactor
SYSTEM_PRE_CHARGE_ACTIVE, //close Pre-charge contactor
SYSTEM_PRE_CHARGE_COMPLETE,//close B+ Contactor
SYSTEM_PRE_CHARGE_FAULT,


SYSTEM_INIT_CHARGE,
SYSTEM_CC_CHARGE,
SYSTEM_CV_CHARGE,
SYSTEM_CHARGE_COMPLETE,
SYSTEM_WAIT_FOR_CHARGER_DISCONNECT,



SYSTEM_HV_READY, //waiting for throttle == 0
SYSTEM_NEUTRAL, //waiting for gear selection
SYSTEM_STOPPED,
SYSTEM_MOVING, //provide torque request to inverter

SYSTEM_DISCONNECT_CONTACTORS,
SYSTEM_DISCONNECT_WAIT, //return to low power state

SYSTEM_DISABLED,

SYSTEM_GENERAL_FAULT

}

[chuuux]

I've drawn the pinout from the table. It can be useful in the wiki.
It's how I connect serial lines to the VCU.

[Jack Bauer]

Many thanks Dilbert

[EV_Builder]

Here is the initial enum for the VCU States, I'll code up something in the next couple of days to test on the GD_Zombie

enum VCU_STATES{
SYSTEM_INIT_STATE,
SYSTEM_LOW_POWER_IDLE_STATE,


SYSTEM_PRE_CHARGE_B_MINUS_CHECK, // should see zero current as we close pre-charge relay, if a B- contactor used
SYSTEM_PRE_CHARGE_TEST, //should see zero current as we close B- contactor
SYSTEM_PRE_CHARGE_ACTIVE, //close Pre-charge contactor
SYSTEM_PRE_CHARGE_COMPLETE,//close B+ Contactor
SYSTEM_PRE_CHARGE_FAULT,


SYSTEM_INIT_CHARGE,
SYSTEM_CC_CHARGE,
SYSTEM_CV_CHARGE,
SYSTEM_CHARGE_COMPLETE,
SYSTEM_WAIT_FOR_CHARGER_DISCONNECT,



SYSTEM_HV_READY, //waiting for throttle == 0
SYSTEM_NEUTRAL, //waiting for gear selection
SYSTEM_STOPPED,
SYSTEM_MOVING, //provide torque request to inverter

SYSTEM_DISCONNECT_CONTACTORS,
SYSTEM_DISCONNECT_WAIT, //return to low power state

SYSTEM_DISABLED,

SYSTEM_GENERAL_FAULT

}

Please implement in C++ with a base class which can be inherited by the application. Then we can easy customize the base class behavior. If you make the states more generic we can use the class as a base class for more devices. The next step is then to couple those statemachines in-between them. I prefer a statemachine per device instead of one big catch all state machine.

For a reference and examples i invite you to take a look at the packml standard.

For a VCU it means we should identify states of the vehicle only.
INIT
STANDBY
STARTING
RUNNING
STOPPING
STOPPED

Now in code it would be this (coming from the 'hidden' base class logic).

INIT()
STANDBY ()
STARTING()
RUNNING ()
STOPPING ()
STOPPED ()

In the stopped method we check if the charger is connected and we could start the charger statemachine to starting etc...

[chuuux]

There is the same NCV8402 issue with ZombieVerter V1 boards.
So I'll buy and resolder them.

[Dilbert]

Here is the initial enum for the VCU States, I'll code up something in the next couple of days to test on the GD_Zombie

enum VCU_STATES{
SYSTEM_INIT_STATE,
SYSTEM_LOW_POWER_IDLE_STATE,


SYSTEM_PRE_CHARGE_B_MINUS_CHECK, // should see zero current as we close pre-charge relay, if a B- contactor used
SYSTEM_PRE_CHARGE_TEST, //should see zero current as we close B- contactor
SYSTEM_PRE_CHARGE_ACTIVE, //close Pre-charge contactor
SYSTEM_PRE_CHARGE_COMPLETE,//close B+ Contactor
SYSTEM_PRE_CHARGE_FAULT,


SYSTEM_INIT_CHARGE,
SYSTEM_CC_CHARGE,
SYSTEM_CV_CHARGE,
SYSTEM_CHARGE_COMPLETE,
SYSTEM_WAIT_FOR_CHARGER_DISCONNECT,



SYSTEM_HV_READY, //waiting for throttle == 0
SYSTEM_NEUTRAL, //waiting for gear selection
SYSTEM_STOPPED,
SYSTEM_MOVING, //provide torque request to inverter

SYSTEM_DISCONNECT_CONTACTORS,
SYSTEM_DISCONNECT_WAIT, //return to low power state

SYSTEM_DISABLED,

SYSTEM_GENERAL_FAULT

}

Please implement in C++ with a base class which can be inherited by the application. Then we can easy customize the base class behavior. If you make the states more generic we can use the class as a base class for more devices. The next step is then to couple those statemachines in-between them. I prefer a statemachine per device instead of one big catch all state machine.

For a reference and examples i invite you to take a look at the packml standard.

For a VCU it means we should identify states of the vehicle only.
INIT
STANDBY
STARTING
RUNNING
STOPPING
STOPPED

Now in code it would be this (coming from the 'hidden' base class logic).

INIT()
STANDBY ()
STARTING()
RUNNING ()
STOPPING ()
STOPPED ()

In the stopped method we check if the charger is connected and we could start the charger statemachine to starting etc...

I think we need to consider the structure of the entire application and that the vehicle logic being developed needs to communicate with a range of vehicles, chargers, and inverters. So as there are multiple variants of each there will be a large number of combinations. Yes i see what you are saying about hiding the actual states of the inverter/charger/vehicle inside their own classes. Are we proposing that each of these classes would then have an "update" method that gets called from the VCU every say 10mS to update it's own state?

I would propose that a separate abstract class is developed for "vehicle" "charger" and "inverter", which has the basic interface for each of these objects. So it doesn't matter if it is a leaf or a Toyota inverter, they have the same interface to the vehicle logic. If someone is to add a new inverter they will use the "inverter" abstract class as the base, similarly if someone adds a new vehicle.