The ZombieVerter VCU Project

[Dilbert]

I'm out at the minute I'll look at the captured data later.

I can also capture data as the auris charges the battery, I would expect the battery regen capacity goes down and discharge capacity goes up.

[Jack Bauer]

Cool:)

[mdrobnak]

LOL Love the lightbulb moment. Keep up the good work.

[Dilbert]

OK back looking at this now... I've attached my Diff spreadsheet, which looks at the difference between the car sitting static and driving in EV mode.

There's a couple of area's where the activity starts row ~350 (car put into drive i believe) and row ~1294 (motor starts to turn).

So I included row 350 and row 1294 in the last 2 rows of the data we are sending to the inverter. So i would imagine by row 1294 the vehicle should the battery capacities set in that data (even if we are a little unsure of the location).

I had a quick look at the code again, is it possible we are stopping MG1 when you select reverse:-
if(gear==-32) mg1_torque=0; //no mg1 torque in reverse.

We can probably get rid of that line for the Auris/Prius?

I know it sounds silly, but i'll throw it out there:- with the PSD welded on this, both motors will turn in the same direction (as far as i know), which is unlike the GS450s without it welded. So i just want to check the signs of what we are sending down to make sure both are pushing in the same direction.

We carried this code over from the Lexus

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];

Is negative still forward?

[Dilbert]

OK so the point around ~350 in the data log is when the pre-charge happens and the inverter has power, in the MTH data the voltage measurements seem to be 100-101 and 102-103, i'm guessing these are before/after the boost converter! scaling seems to be the same as the lexus (value-5/2).

In the MTH data for these bytes 38-39 40-41 seems to be MG2 speed.

[Jack Bauer]

Arrg! yes no mg1 torque in reverse:) And of course you are right about the welded psd forcing both motors to run in the same direction unlike the lexus where locking the input shaft actually has them running in the oposite directions. Good catch.

[Dilbert]

Does that explain what you saw yesterday, it was just mg1 and mg2 having a fight and maxing out the psu. I guess if they were running one might regen into the other, but when stopped both take current.

[Jack Bauer]

So commented out the mg1 zero reverse. No change. Also, in the current code all the mg1 commands are commented out also! We should be just running mg2.

[Dilbert]

I was wondering about that, so we are just sending zeros for the mg1 bytes.

In my data I've noticed that mg1 torque is sent in 3 places. In 5-6 11-12 and 75-76. The 75-76 bytes are used for engine start and the other bytes seem to be used to control mg1 when driving. Not sure why both are required, maybe the 75-76 values ignore the battery limits for starting the engine.

So the only throttle values we are sending us for mg2 but mg1 is responding, that's strange...

[Jack Bauer]

So went back for a few more tests. Right now this is all I am sending :

Code: Select all

       // -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];

everything else commented out and it spins up mg1.

[Jack Bauer]

Disregard all that, i'm a class 3 moron again. I was modifying case 4 and we are working in case 9! Reverse now working on MG1!!

[Jack Bauer]

Well, with the data in the right part of the switch statement we get some response from mg2 now but no rotation. It draws current from the psu but in a pulsing manner so either I have an encoder wiring error or we have the battery disch limit problem. Checking wiring now ...

[Dilbert]

[Jack Bauer]

Ok, encoder wiring verified correct. So either we are sending it something silly or not giving a disch limit its happy with.

[Jack Bauer]

Your gonna love this one. Double checked resolver. all ok. But its so like a resolver swapped feedback.....couldnt be the phase wires as I'm using oem loom.....check anyway....outer two phases swapped but cables only fit the "wrong" way. Chopped off a tab flipped it over and we have mg2 running:)

Only at low speed though and it demonstrates the limiting I saw on the lexus when the battery discharge limit is not specified. Good job I don't work at toyota:) Seems the ct200h inverter and prius cables end up swapping a phase on mg2 but not mg1!!

[Dilbert]

Let me check if the discharge limits are set after pre-charge in the data.

I'm wondering is there a speed value that needs to be set in the htm data. In the Lexus code we take up the speed and send it back down again. That's why I started looking at the MTH data again, to see if I could spot anything.

So we've removed the minus sign on mg1, but when mg2 is connected and the throttle pressed the inverter takes 600ma and just sits there.

Should we comment out mg1 commands now and see if we can figure mg2 in isolation.

I'm really curious about the 3 values sent to mg2 which I graphed the other day, how they flip with direction etc...

[Jack Bauer]

So just to check removed the regen and disch limits and the inverter doesnt go into ready mode.

[Jack Bauer]

So what I have so far :

-mg1 forward and reverse to high rpm no issue
-mg2 forward and reverse to low rpm no problem
-increasing mg2 rpm causes the speed to hunt and the inverter to stop sending torque, wait for speed to drop , resume torque
-mg1 and mg2 in forward and reverse to low rpm no problem.

[Jack Bauer]

Here is how mg2 on its own behaves as of now :

[Dilbert]

It's interesting but probably not surprising that it's just limiting on mg2... You know what, I bet that's how they get the car to 'creep' forward. So when I took the htm frame at row 1294 the car is starting to creep so it's limited. So if I look to where torque is applied the speed limit should also be increased.

The other option is that the system is reporting the speed on the mth frame and it requires the ecu to feed this value into the htm frame. The Lexus does this, perhaps for safety or to control the accel/deccel ramp of the vehicle. So the system commands a torque and allows the speed to have a max of the last speed + X

[Jack Bauer]

So as usual with this project just ignore that last video and check this one out. Oh and you know how you can kill a Tesla inverter by opening the hv supply when the motor is spinning? Not so Mr.Toyota:)

[Jack Bauer]

So yeah, that happened with 160v. When it got going it didnt stop even at 0 torque hence the "emergency disconnect" and the death of my 100w filament lamp precharge resistor:)

[Dilbert]

Looking at the graphs, it looks like the hybrid ecu is doing closed loop speed for the creep forward, so the inverter is just getting torque commands. Graphs make sense as my initial back and forth had no accelerator added.

Looking at the data the torque command is also repeated in bytes 36/37

htm_data[30]=(mg2_torque) & 0xFF; //positive is forward
htm_data[31]=((mg2_torque)>>8) & 0xFF;

htm_data[36]=htm_data[30]
htm_data[37]=htm_data[31]


Ok so it ran away when throttled up, even though we ordered 0 torque from mg2

[Dilbert]

Could that be a sync offset issue on mg2 ? ( I know I want to blame everything on sync offset )

[jon volk]

Flashed the current version from github to start messing with things. Parameters show and are configurable via wifi, but it wont update firmware from a .bin upload. Instantly shows 100% and there will be around a 500ms LED off period on the board then it happily goes about executing the firmware that was SWD loaded. Is OTA functional at the moment? Im trying to ascertain if I buggered up something on the esp3266 or if Im chasing my tail for no reason.