ZombieVerter VCU Support

[angusmf]

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

Whoops! Lucky for us we have spares from our v1c Prius boards. All 8 need to be replaced?

[Jack Bauer]

Yep all will be affected. That's why I did a beta release on this board.

[angusmf]

It happens. Have had my share of "oops" releases...

[Jack Bauer]

Thanks for understanding:)

[EV_Builder]

Yes that's exactly my point with the base class idea.

Yes you can also make specific device classes but I would not alive those states. The name of the class should tell you what it is doing in the running state or stopping state etc. In there there can be own state machines anyway.

[chuuux]

Finally I rewired all serial lines and got the MTH signal. ZombieVerter is recieves data from GS300h inverter now.
MTH frames from Camry 2012+ inverter are still incomprehensible to the VCU, and I can't capture the whole MTH frame with my cheep scope now.

What compiled file should I upload to the VCU by wed interface? .bin or .hex?

[EV_Builder]

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

I have missed this. Can you elaborate on it?

What do we need to buy? / resolder?

[Dilbert]

Finally I rewired all serial lines and got the MTH signal. ZombieVerter is recieves data from GS300h inverter now.
MTH frames from Camry 2012+ inverter are still incomprehensible to the VCU, and I can't capture the whole MTH frame with my cheep scope now.

What compiled file should I upload to the VCU by wed interface? .bin or .hex?

On the scope measure the length of the mth frame, the inverter is probably failing the checksum test if it thinks the frame is the wrong length.

[EV_Builder]

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

I have missed this. Can you elaborate on it?

What do we need to buy? / resolder?

Ok never mind found the thread....(viewtopic.php?p=28749#p28749)

Recap:

TAB is connected to DRAIN in certain models of FETS.
We had the wrong one on our board.

Ordered the correct ones.. : NCV8402ASTT1G

[collin80]

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.

I did something like that with GEVCU where there is a base class for all "devices" then children to that are device "types" like chargers, motor controllers, etc. Then the actual device drivers inherit from one of those device type classes. This allows for a common interface that you can count on. All motor controllers might store the currently selected gear for instance. So, code need not know anything about the actual motor controller or how it encodes the gear position. It just says "update the gear to drive" and that happens. This is the way that a generic VCU should operate. It takes a bit of planning - probably more than I put into the early versions of GEVCU. If I could engineer things better I would but it didn't turn out too terribly. Still, definitely talk it over a lot and figure out the object hierarchy and how you can best make generic interfaces.

[Dilbert]

Based on the above comments, this is a potential structure. The main application has an array of "chargers", "vehicles" and "inverters". The first element in this array could be a dummy item, which would be called, if a particular device wasn't configured.


#include <iostream>

using namespace std;

class Charger{

private:
int timebase;

public:
virtual void INIT()=0;
virtual void STANDBY ()=0;
virtual void STARTING()=0;
virtual void RUNNING ()=0;
virtual void STOPPING ()=0;
virtual void STOPPED ()=0;

};



class OutlanderCharger:Charger {

private:
int state;

public:
void INIT();
void STANDBY ();
void STARTING();
void RUNNING ();
void STOPPING ();
void STOPPED ();


};



void OutlanderCharger::INIT(){
cout<<"init";
}

void OutlanderCharger::STANDBY(){
cout<<"STANDBY";
}

void OutlanderCharger::STARTING(){
cout<<"STARTING";
}

void OutlanderCharger::RUNNING(){
cout<<"RUNNING";
}

void OutlanderCharger::STOPPING(){
cout<<"STOPPING";
}

void OutlanderCharger::STOPPED(){
cout<<"STOPPED";
}



int main()
{

Charger *charger_list[3];

charger_list[0]= (Charger *)new OutlanderCharger();


charger_list[0]->INIT();
charger_list[0]->RUNNING();


return 0;
}

[chuuux]

Is there a parameter in the web-interface for checking the connectionsof resolvers? I've seen the "angle" parameter in previous VCU videos, but it's missing in the Zombie web-interface.

[EV_Builder]

Based on the above comments, this is a potential structure. The main application has an array of "chargers", "vehicles" and "inverters". The first element in this array could be a dummy item, which would be called, if a particular device wasn't configured.


#include <iostream>

using namespace std;

class Charger{

private:
int timebase;

public:
virtual void INIT()=0;
virtual void STANDBY ()=0;
virtual void STARTING()=0;
virtual void RUNNING ()=0;
virtual void STOPPING ()=0;
virtual void STOPPED ()=0;

};



class OutlanderCharger:Charger {

private:
int state;

public:
void INIT();
void STANDBY ();
void STARTING();
void RUNNING ();
void STOPPING ();
void STOPPED ();


};



void OutlanderCharger::INIT(){
cout<<"init";
}

void OutlanderCharger::STANDBY(){
cout<<"STANDBY";
}

void OutlanderCharger::STARTING(){
cout<<"STARTING";
}

void OutlanderCharger::RUNNING(){
cout<<"RUNNING";
}

void OutlanderCharger::STOPPING(){
cout<<"STOPPING";
}

void OutlanderCharger::STOPPED(){
cout<<"STOPPED";
}



int main()
{

Charger *charger_list[3];

charger_list[0]= (Charger *)new OutlanderCharger();


charger_list[0]->INIT();
charger_list[0]->RUNNING();


return 0;
}

We could start simply by making this a baseclass for example bcVCU_SM (base class VCU statemachine).

Then the charger class could inherit this class (and many others) in the class we can then define private methods which are called in the implementation of the baseclass method (overwritten).
All ing ending states should be of type boolean (not void) and return true at default.
Further we need a Struct for the commands (property written) and a state property read only public.

[Jack Bauer]

Now on general sale :
https://www.evbmw.com/index.php/evbmw-w ... vcu-boards

Gerbers and pdfs on the repo master branch. Design files on Patreon only as of now.

[chuuux]

I've captured the MTH pulse with a good scope.
My GS450h gen1 inverter has 1ms length of the packet.
and Camry AVV50r gen3 (2012+) inverter has 2.8ms length of the packet.
I don't know how to count the length in bytes yet.

GS450h inverter is transmeeting with the VCU well, but it can't run the L210 gearbox (2012+) right way. Something like syncofs errors or resolvers misunderstanding = jerky moves etc.

Camry gen3 inverter has no transmeeting data with the VCU both in "GS450h" and "Prius gen3" modes.

[chuuux]

And I've also captured the MTH pulse from Aqua NHP10 inverter (G9200-52010 Gen3).
It has 2.8ms length of the packet again and no transmeeting data with the VCU in "Prius gen3" mode.

[Jack Bauer]

Easy way to capture the data is with an ftdi cable on the mcu side of the can transcievers. Dilbert might be able to help with that.

[Dilbert]

OK I wouldn't bother trying to log the data till we are sure you have 2 way comms. Reading the posts above it looks like you have valid data on the MTH line, the frame size of 2.8mS corresponds to what i measured on a new (>2017) Yaris inverter i purchased. On the older Yaris inverter (<2015) we see an mth frame of 2.4mS.

The fact that you are seeing an MTH frame of the correct size this means that your REQ and CLK lines are correct. I don't know why you are not seeing a HTM frame from the VCU, i would open the VCU and scope the TX pin on the CAN transceiver which sends the HTM signal.

[Dilbert]

For reference I'm keeping a spreadsheet (will add part numbers) of the different frame sizes to expect. I will be adding these to the WIKI page:-

[chuuux]

OK I wouldn't bother trying to log the data till we are sure you have 2 way comms. Reading the posts above it looks like you have valid data on the MTH line, the frame size of 2.8mS corresponds to what i measured on a new (>2017) Yaris inverter i purchased. On the older Yaris inverter (<2015) we see an mth frame of 2.4mS.

The fact that you are seeing an MTH frame of the correct size this means that your REQ and CLK lines are correct. I don't know why you are not seeing a HTM frame from the VCU, i would open the VCU and scope the TX pin on the CAN transceiver which sends the HTM signal.

Maybe I wrote it incomprehensibly. I see the HTM data from all of my inverters (GS450h, Aqua 2013, Camry 2013). But only GS450h data passes checksum (InvStatus ON) and I see something from invertor, like temp, INVudc etc.

And I've got different MTH pulse length then you. It's strange, or maybe I measured it wrong?
GS450h: 1mS
Camry 2012+ : 2.8mS
Aqua/Yaris 2013: 2.8mS
All my inverters are JDM RHD versions.

I think I should capture exactly the MTH and HTM digital frames. Can you advice me how I can do it?

[Dilbert]

The easiest way to capture the frames is with two ftdi cables (or any ttl to USB converter).

Connect the two ftdi rx pins to the rx pin on the VCU CAN transceivers. You'll need to connect the grounds too. You can then log from both interfaces using something like real term to a file on the disk. You will need two copies of real term open.

[Dilbert]

The newer Toyotas seem to have these longer 140 byte mth frames. I have verified that these have the standard checksum etc...

We also believe that the htm frames have increased in size too, but we have no proof of that yet.

Possibly Toyota have standardized the frames across models, so increased the sizes possibly for 3 motor variants etc....

[chuuux]

The easiest way to capture the frames is with two ftdi cables (or any ttl to USB converter).

Connect the two ftdi rx pins to the rx pin on the VCU CAN transceivers. You'll need to connect the grounds too. You can then log from both interfaces using something like real term to a file on the disk. You will need two copies of real term open.

I have one ttl to USB converter. Should I use couple of it to read data from MTH and HTM one time?

[Dilbert]

You'll only be able to read one side of the conversation, which isn't an issue most of the time.

Take wires from the 2 RX pins on the transceivers and connect to a switch, which will allow you to toggle the converter between HTM and HTM.

[Dilbert]

I've been doing some development on the code for the zombie inverter using an abstract base class (vcu_device), which all things (vehicles/chargers/inverters). It is actually looking quite good. The plan is to pass over the scheduler pointer and CAN object pointer so the devices can register themselves if required. The CAN call-back will check each of the objects to see if there is any of the required frames for servicing.

My plan is to make the generic "BasicVehicle" the hard-wired one, users can then expand on this and create new vehicle types, with CAN interfaces etc...

//create the objects for the charger, inverter and vehicle
BasicVehicle myCar;
OutlanderCharger myCharger;
ToyotaInverter myInverter;

//register scheduler and CAN interface!
myCar.Register(&s,&c);
myCharger.Register(&s,&c);
myInverter.Register(&s,&c2);

//Initialise the VCU main Task
//The VCU Task will need objects for the following: Vehicle, Inverter, Charger