Page 15 of 38

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 12:08 pm
by Dilbert
Looking at it now, that graph is weird.

In one direction the Blue/Grey graphs match, in the reverse direction the Grey/Orange match...

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 12:13 pm
by Jack Bauer
Oh yeah I see what you mean.

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 12:33 pm
by Dilbert
Its mad the one that is 1/2 the size has the same shape, but the peaks are filtered out! And then when the direction changes it has the peaks in it... what could they be at!

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 2:09 pm
by Jack Bauer
Perhaps my mind was clouded with all those $$$$ signs from the thoughts of ripping off Dilbert's hard work on the prius side but I had been a class 3 moron in the E46/Leaf arena. The can messages were fine. The can timings were fine. The inverter voltages were fine. But no spin and the inverter was setting the fault flag within a few hundred ms of receiving 12v power. What could it be.....

This morning when testing the bench prius I was amazed at how laid back the Toyota engineers are when it comes to comms. VCU drops dead? Meh, lets just wait until it wakes up again and pick up where we left off. Sync serial via a free running oscillator? whatever works for you.

Not so the Nissan engineers. They are an up tight bunch. Loose can for more than a second? AAAHHHHHHHHHH shunt it down! etc. Anyway, in the vcu code i was precharging , closing main then energising inverter power. Toyota totally down with that. Nissan not so much : WHAT! 360v aaaahhhhhhhhhhhaaaaa stuck contactor! shut it down! The solution : inverter power on first then precharge. All happy with our two favorite Japanese automakers:)

Got a special video over on instagram for you Matt:)

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 2:41 pm
by Jack Bauer
Ok I'm going to double post this here and on the GS450H vcu support thread. Now that we have E65/GS450H , E46/Leaf combos running and Prius on the way I am pushing the button on porting libopeninv to the SAM3X8E mcu. The purpose of this is to allow the firmware developed here for the Zombieverter to be backwards compatible with the existing vcus for both Lexus and Leaf. Once the code has been cleaned up from my mess by the people who have kindly helped, supported and contributed to this project it will be passed to an external developer (at my expense) who will do the actual conversion as although both the SAM and F105 parts are supported by libopencm3 and are both cortex m3 processors there are quite a few differences.

Once ready for release the binaries will be completely free and opensource however the source will remain available on Patreon only for a period of time before also becoming fully free and opensource. Expected timeframe on this is first half of 2021.

Now regarding the Zombieverter as of this point further hardware changes are required to add extra i/o and functions so the code will break from the SAM version at this point. If there are future modules developed that could be back ported to the SAM version that will be up individuals and/or the community to pursue.

A big thank you to all who support this project. I actually couldn't do it without you. I'll raise a glass to you from my beach house in Lanzarote:)

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 2:43 pm
by Jack Bauer
Now, back on the prius front I fitted the spare prius and yaris boards to the bench inverter (ct200h) and guess what? Motor spins:) So we know Yaris/Prius/CT200H inverter now follow the same comms protocol.

Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 3:17 pm
by Jack Bauer
Few short clips from today :



Re: The ZombieVerter VCU Project

Posted: Fri Jan 29, 2021 3:44 pm
by mdrobnak
So much progress in the last day. Excellent work Dilbert and Damien!

Dilbert - check to see that some of them are not more complimentary values or checksum values (ie 255 - X instead of X as a check -- some ABS units do this when they want MORE torque instead of less).

-Matt

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 9:16 am
by Dilbert
OK I had a look at the 3 graphs this morning, so here's something to try, to see if we can get reverse/forward working. The old code never set byte 30&31. This can just be slotted in where we break up the MG2 torque value.

Would it be worth zero'ing the MG1 torque value till we figure out MG2? as we don't want them fighting each other? so just comment out where we set bytes 75,76,5,6,11,12. In fact maybe do this before putting in the change below, to make sure we are running on MG2 alone.



//mg2 the MG2 values are now beside each other!
htm_data[30]=(mg2_torque) & 0xFF; //positive is forward
htm_data[31]=((mg2_torque)>>8) & 0xFF;

if(gear==32) { //forward direction these bytes should match
htm_data[26]=htm_data[30];
htm_data[27]=htm_data[31];
htm_data[28]=(mg2_torque/2) & 0xFF; //positive is forward
htm_data[29]=((mg2_torque/2)>>8) & 0xFF;
}

if(gear==-32) { //reverse direction these bytes should match
htm_data[28]=htm_data[30];
htm_data[29]=htm_data[31];
htm_data[26]=(mg2_torque/2) & 0xFF; //positive is forward
htm_data[27]=((mg2_torque/2)>>8) & 0xFF;
}

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 9:57 am
by Jack Bauer
Sadly no change in behavour. Just runs in "reverse" and refuses to move in forward. Here is my current 1ms routine :

Code: Select all

void GS450HClass::UpdateHTMState1Ms(int8_t gear)
{

    switch(htm_state)
    {

    case 0:
    {
        dma_read(mth_data,100);//read in mth data via dma. Probably need some kind of check dma complete flag here
        DigIo::req_out.Clear(); //HAL_GPIO_WritePin(HTM_SYNC_GPIO_Port, HTM_SYNC_Pin, 0);
        htm_state++;
    }
    break;

    case 1:
    {
        DigIo::req_out.Set();  //HAL_GPIO_WritePin(HTM_SYNC_GPIO_Port, HTM_SYNC_Pin, 1);

        if(inv_status==0)
        {
            if (dma_get_interrupt_flag(DMA1, DMA_CHANNEL7, DMA_TCIF))// if the transfer complete flag is set then send another packet
            {
                dma_clear_interrupt_flags(DMA1, DMA_CHANNEL7, DMA_TCIF);//clear the flag.
                dma_write(htm_data,80); //HAL_UART_Transmit_IT(&huart2, htm_data, 80);
            }

        }
        else
        {
            dma_write(htm_data_setup,80);   //HAL_UART_Transmit_IT(&huart2, htm_data_setup, 80);
            if(mth_data[1]!=0)
                inv_status--;
        }
        htm_state++;
        break;

        case 2:
            htm_state++;
        }
        break;

    case 3:
    {
        //
        // dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF);
        if(VerifyMTHChecksum(100)==0 || dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF)==0)
        {

            statusInv=0;
        }
        else
        {

			//exchange data and prepare next HTM frame
            dma_clear_interrupt_flags(DMA1, DMA_CHANNEL6, DMA_TCIF);
            statusInv=1;
            dc_bus_voltage=(((mth_data[82]|mth_data[83]<<8)-5)/2);
            temp_inv_water=(mth_data[42]|mth_data[43]<<8);
            temp_inv_inductor=(mth_data[86]|mth_data[87]<<8);
            mg1_speed=mth_data[6]|mth_data[7]<<8;
            mg2_speed=mth_data[31]|mth_data[32]<<8;
        }

        mth_data[98]=0;
        mth_data[99]=0;

        htm_state++;
    }
    break;

    case 4:
    {

        // -3500 (reverse) to 3500 (forward)
        if(gear==0) mg2_torque=0;//Neutral
        if(gear==32) mg2_torque=this->scaledTorqueTarget;//Drive
        if(gear==-32) mg2_torque=this->scaledTorqueTarget*-1;//Reverse

        mg1_torque=((mg2_torque*5)/4);
        if(gear==-32) mg1_torque=0; //no mg1 torque in reverse.
        Param::SetInt(Param::torque,mg2_torque);//post processed final torue value sent to inv to web interface

        //speed feedback
        speedSum=mg2_speed+mg1_speed;
        speedSum/=113;
         uint8_t speedSum2=speedSum;
        htm_data[0]=speedSum2;
        //htm_data[75]=(mg1_torque*4) & 0xFF;
        //htm_data[76]=((mg1_torque*4)>>8) & 0xFF;

        //mg1
        //htm_data[5]=(mg1_torque*-1)&0xFF;  //negative is forward
       // htm_data[6]=((mg1_torque*-1)>>8);
       // htm_data[11]=htm_data[5];
       // htm_data[12]=htm_data[6];

        //mg2
        //htm_data[26]=(mg2_torque) & 0xFF; //positive is forward
        //htm_data[27]=((mg2_torque)>>8) & 0xFF;
        //htm_data[32]=htm_data[26];
        //htm_data[33]=htm_data[27];

        //mg2 the MG2 values are now beside each other!
htm_data[30]=(mg2_torque) & 0xFF; //positive is forward
htm_data[31]=((mg2_torque)>>8) & 0xFF;

if(gear==32) { //forward direction these bytes should match
htm_data[26]=htm_data[30];
htm_data[27]=htm_data[31];
htm_data[28]=(mg2_torque/2) & 0xFF; //positive is forward
htm_data[29]=((mg2_torque/2)>>8) & 0xFF;
}

if(gear==-32) { //reverse direction these bytes should match
htm_data[28]=htm_data[30];
htm_data[29]=htm_data[31];
htm_data[26]=(mg2_torque/2) & 0xFF; //positive is forward
htm_data[27]=((mg2_torque/2)>>8) & 0xFF;
}


        htm_data[63]=(-5000)&0xFF;  // regen ability of battery
        htm_data[64]=((-5000)>>8);

        htm_data[65]=(27500)&0xFF;  // discharge ability of battery
        htm_data[66]=((27500)>>8);

        //checksum

		CalcHTMChecksum(80);

        htm_state=0;
    }
    break;

	/***** Demo code for Gen3 Prinus/Auris direct communications! */
   case 5:
    {
        dma_read(mth_data,120);//read in mth data via dma. Probably need some kind of check dma complete flag here
        DigIo::req_out.Clear(); //HAL_GPIO_WritePin(HTM_SYNC_GPIO_Port, HTM_SYNC_Pin, 0);
        htm_state++;
    }
    break;

    case 6:
    {
        DigIo::req_out.Set();  //HAL_GPIO_WritePin(HTM_SYNC_GPIO_Port, HTM_SYNC_Pin, 1);

if(inv_status>5)
{
if (dma_get_interrupt_flag(DMA1, DMA_CHANNEL7, DMA_TCIF))// if the transfer complete flag is set then send another packet
{
dma_clear_interrupt_flags(DMA1, DMA_CHANNEL7, DMA_TCIF);//clear the flag.
dma_write(htm_data,100); //HAL_UART_Transmit_IT(&huart2, htm_data, 80);
}

}
else
{
dma_write(&htm_data_init[ inv_status ][0],100); //HAL_UART_Transmit_IT(&huart2, htm_data_setup, 80);

inv_status++;
if(inv_status==6){
//memcpy(htm_data, &htm_data_init[ inv_status ][0], 100);
}
}
        htm_state++;
        break;

	case 7:
		htm_state++;
	}
	break;

    case 8:
    {
        //
        // dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF);
        if(VerifyMTHChecksum(120)==0 || dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF)==0)
        {

            statusInv=0;
        }
        else
        {

			//exchange data and prepare next HTM frame
            dma_clear_interrupt_flags(DMA1, DMA_CHANNEL6, DMA_TCIF);
            statusInv=1;
            dc_bus_voltage=(((mth_data[82]|mth_data[83]<<8)-5)/2);
            temp_inv_water=(mth_data[42]|mth_data[43]<<8);
            temp_inv_inductor=(mth_data[86]|mth_data[87]<<8);
            mg1_speed=mth_data[6]|mth_data[7]<<8;
            mg2_speed=mth_data[31]|mth_data[32]<<8;
        }

        mth_data[98]=0;
        mth_data[99]=0;

        htm_state++;
    }
    break;

    case 9:
    {

        // -3500 (reverse) to 3500 (forward)
        if(gear==0) mg2_torque=0;//Neutral
        if(gear==32) mg2_torque=this->scaledTorqueTarget;//Drive
        if(gear==-32) mg2_torque=this->scaledTorqueTarget*-1;//Reverse

        mg1_torque=((mg2_torque*5)/4);
        if(gear==-32) mg1_torque=0; //no mg1 torque in reverse.
        Param::SetInt(Param::torque,mg2_torque);//post processed final torue value sent to inv to web interface

        //speed feedback
        speedSum=mg2_speed+mg1_speed;
        speedSum/=113;
        uint8_t speedSum2=speedSum;
        	//Possibly not needed
		//htm_data[0]=speedSum2;

		//these bytes are used, and seem to be MG1 for startup, but can't work out the relatino to the
		//bytes earlier in the stream, possibly the byte order has been flipped on these 2 bytes
		//could be a software bug ?
        htm_data[76]=(mg1_torque*4) & 0xFF;
        htm_data[75]=((mg1_torque*4)>>8) & 0xFF;

        //mg1
        htm_data[5]=(mg1_torque*-1)&0xFF;  //negative is forward
        htm_data[6]=((mg1_torque*-1)>>8);
        htm_data[11]=htm_data[5];
        htm_data[12]=htm_data[6];

        //mg2 the MG2 values are now beside each other!
        htm_data[26]=(mg2_torque) & 0xFF; //positive is forward
        htm_data[27]=((mg2_torque)>>8) & 0xFF;
        htm_data[28]=htm_data[26];
        htm_data[29]=htm_data[27];

		//This data has moved!

        htm_data[85]=(-5000)&0xFF;  // regen ability of battery
        htm_data[86]=((-5000)>>8);

        htm_data[87]=(-10000)&0xFF;  // discharge ability of battery
        htm_data[88]=((-10000)>>8);

        //checksum
        if(++frame_count & 0x01){
        htm_data[94]++;
        }

		CalcHTMChecksum(100);

        htm_state=5;
    }
    break;


    }
}


Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 11:02 am
by Dilbert
Is it responding to the throttle pedal?

Does it turn in reverse direction in both forward and reverse on the ecu or does it stop.

We might grab some htm data to have a look at what we are generating.

Also we know from the Lexus that we've to feed back the speed on the htm frame, so possibly we aren't extracting that from MTH correctly

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 11:17 am
by Jack Bauer
So it runs in reverse but ignores throttle in forward. Will grab some data in a few minutes.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 11:56 am
by Jack Bauer
Ok so 3 sets of captures. All from a powered off stat.

1: power up with no hv and no torque request.
2:Power up, apply approx 62v hv , pause, shutoff psu hv decays.
3:Power up, apply approx 62v hv, put vcu in run, issue torque, motor turns, set torque to zero, switch off hv psu, hv decays, power off.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 12:56 pm
by Dilbert
OK, had a quick look at the HTM data, what's happening is due to that memcpy command not running, its not initialising htm_data[ ] array, so that's going back to all zeros after the first 6 frames.

So we either need to get the memcpy to work, or initialized the htm_data struct, with the last line from the 2D array.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 12:58 pm
by Dilbert
So where htm_data is defined we can add:-

unint8_t htm_data[100]={0,30,0,2,0,0,0,18,0,154,250,0,0,16,0,97,0,0,0,0,0,0,200,249,56,6,165,0,136,0,63,0,16,0,0,0,63,0,16,0,3,128,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,16,0,75,12,45,248,21,6,0,0,16,0,0,0,202,0,211,0,16,0,0,0,134,16,0,0,130,10};

The reason memcpy is not working is probably due to one of the pointers being bad, so it might be a copy and paste error by me.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:01 pm
by Jack Bauer
Ok I'll give that a whirl and see if I can figure out the memcpy issue.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:14 pm
by Jack Bauer
Ok, it don't like that one bit! at startup my 60v psu shows 600ma draw instead of 60ma previously and when a torque demand is made the motor gives a big jump and then the crappy psu shuts down.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:18 pm
by Dilbert
I wonder with the last version are we seeing the vehicle trying to roll forward when in drive with no torque command

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:20 pm
by Dilbert
Oh could mg1 be fighting mg2, could that also explain the rotation before a torque command ?

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:27 pm
by Jack Bauer
Ok scratch that. Removed the inverter hv connector cover. It really doesnt care less about the interlock:) and disconnected mg2. Results here :


seems we have been running mg1 all along and regening into mg2 via the motor speed reduction gear hence the slow revs.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:32 pm
by Dilbert
Interesting, as I captured the auris data in ev mode so no mg1 commands issued. Is there a sync off issue with the encoder on mg1, hence we are getting rotation

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:37 pm
by Jack Bauer
Possible but mg2 is not responding at all. I just tried with mg1 disconnected with both htm data arrays. With the mostly zero array it does nothing, with the new array it sits there with the psu showing 600ma.

edit : also its repsonding perfectly to throttle commands. sorry didnt show that in the video.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:40 pm
by Jack Bauer
oh ffs I've seen this with the lexus if we dont give it battery discharge and regen limits! it will motor mg1 all day to try and start the engine but wont run mg2!!

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:44 pm
by Jack Bauer
Also its probably why it wont reverse! Must start engine, why do you want reverse.... must start engine. and my gearbox has a welded psd so mg1 cant run on its own.

Re: The ZombieVerter VCU Project

Posted: Sat Jan 30, 2021 1:44 pm
by Dilbert
Ahhhh yes :)

They were 2 values I wasn't fully sure of the location so I was guessing based on what looked right