openinverter forum

chuuux wrote: ↑Fri Jun 18, 2021 12:51 pm There is the same NCV8402 issue with ZombieVerter V1 boards.
So I'll buy and resolder them.

chuuux wrote: ↑Fri Jun 18, 2021 12:51 pm There is the same NCV8402 issue with ZombieVerter V1 boards.
So I'll buy and resolder them.

chuuux wrote: ↑Sun Jun 20, 2021 7:30 am 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 wrote: ↑Sun Jun 20, 2021 6:48 pm

chuuux wrote: ↑Fri Jun 18, 2021 12:51 pm 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 wrote: ↑Fri Jun 18, 2021 3:40 pm 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.

Dilbert wrote: ↑Mon Jun 21, 2021 7:27 am 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;
}

Dilbert wrote: ↑Fri Jul 02, 2021 1:06 pm 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 wrote: ↑Fri Jul 02, 2021 1:59 pm 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.