Lexus GS450H VCU Support Thread

[steveknox]

Ah wait, does the Park / Neutral Position SW need to have power in order to actuate the gear solenoids, specifically to +B.
I have that connector currently disconnected as I'm not using the signals from it to identify drive / neutral / reverse.
Would that explain why MG2 is spinning without moving the shaft?

Just to follow this up, i now have MG2 spinning the output shaft, and the wheels! What i was missing was oil pressure. Without oil pressure, the clutches can't engage, regardless of what the solenoids are doing. Once the transmission was filled with fluid and the pump was going, MG2 came to life.

[xp677]

With no oil pressure, the 2-speed transmission will just stay in the higher gear. MG2 will still drive the output shaft.

I've done plenty of bits of brief driving without the oil pump running during testing, etc.

[catphish]

Is there a guide for compiling the code / flashing the controller?

Here is my the function for selecting gears:

Is your code available on Github, or would you be able to send it to me? I am about to set up a GS450H for someone who is particularly interested in getting the gear shift working at speed. I'd prefer to build my own version, so the more examples of how people are using it, the better.

[Bryson]

Mine is posted here, basic shifting at very low speed plus low to high shifting at very low torque loads. No PWM on the solenoids though. If you figure it all out I would love to incorporate it into my code.

https://github.com/Bry5on/Lexus-GS450H- ... es-testing

[PatrcioEV-ATX]

Mine is posted here, basic shifting at very low speed plus low to high shifting at very low torque loads. No PWM on the solenoids though. If you figure it all out I would love to incorporate it into my code.

https://github.com/Bry5on/Lexus-GS450H- ... es-testing

This looks like you're running in High unless you tell it to shift to low, correct? Then.... let off accelerator for a sec to let it go back to high? Kind of like an old fashioned overdrive.

[catphish]

I am working on a fairly major rewrite of Damien's code to suit my own project. One thing I haven't been able to find is documentation of the structure of mth_data[] and htm_data[]. Is this documented or discussed anywhere? Damien's implementation of this works flawlessly, but I'm keen to understand it.


Similarly, I'm keen to understand the timing relationship between mth, htm, and pin_inv_req.

Thanks!

[catphish]

I have created my own fork of Damien's code which I have substantially refactored. The aim of this version is to create a very simple base on which I can build new functionality. I thought I'd share it here in case it helps anyone with their own projects.

The main changes I have made are as follows:
* Refactor inverter communication code to use a single timer only, receiving and sending data in a more event driven manner.
* New throttle mapping code. This is a middle ground between the complexity of the full regen map, and the simplicity of the no-regen version.
* Strip out everything else. This code is intended as the first step on the way to a more complex version that meets my own needs, so CAN, serial and wifi have all been temporarily removed.
* Add lots of comments in the hope that others will read it and find it useful.

https://github.com/catphish/gs450h

For my own project, my next step will be to implement wifi, for both monitoring and configuration, so that tuning can be carried out more easily. Please let me know if you have any questions or suggestions about this, or if you find it useful, or think it's awful.

I also hope to implement gear changes, but I don't have the oil pump up and running yet, so this will have to wait!

Edit: I realise I may be flogging a dead horse here, but I have a board in hand, so might as well make the most of it

[xp677]

Early discussions were in this thread:

viewtopic.php?f=14&t=205

The VCU was created by Damien based partly on the code and circuitry which we developed from that thread.

[xp677]

Similarly, I'm keen to understand the timing relationship between mth, htm, and pin_inv_req.

Pulsing the inverter request pin causes the inverter to output one HTM packet.

This was done every 4ms in the GS450h.

HTM packets were transmitted every 4ms as well, these do not have to be synchronised with the MTH packet.

In reality, you can send or request packets whenever you like, it doesn't seem to care.

[xp677]

One thing I haven't been able to find is documentation of the structure of mth_data[] and htm_data[].

Look at the variables in the code and rebuild the structure from there. Bytes which don't have anything attached are either not used, or we don't care about them.

I delved a lot deeper into this after the VCU was forked off from my project, there are all sorts of things in the such as byte 1 (inverter state) being status bits for the current sensors, see here:

Code: Select all

  if (inv_state == 0)Serial.print("Missing/Not ready");
  else if (inv_state & 0b00000001)Serial.print("Boot");
  else if (inv_state & 0b00001100)Serial.print("Ready");
  if (inv_state & 0b10000000)Serial.print(" - Current Sensor MG2-1 Missing");
  if (inv_state & 0b01000000)Serial.print(" - Current Sensor MG2-2 Missing");
  if (inv_state & 0b00100000)Serial.print(" - Current Sensor MG2-1 Missing");
  if (inv_state & 0b00010000)Serial.print(" - Current Sensor MG1-2 Missing");

The current sensor values can be read out from mth, as well as rotor current position, I don't think these ever made it into any project. There's loads of data in the MTH stream, it's just a case of taking what you want from it.

I hooked up a Toyota scantool to the original donor GS450h and I have a list somewhere of all the motor and inverter related info that can only be found from the MTH packets, so it would just be a case of decoding the ones you want.

Probably best to let mth_data[1] to reach 12 before declaring inverter init complete, although it seems to reliably get there on its own from state 1.

[catphish]

Pulsing the inverter request pin causes the inverter to output one HTM packet.

This was done every 4ms in the GS450h.

HTM packets were transmitted every 4ms as well, these do not have to be synchronised with the MTH packet.

In reality, you can send or request packets whenever you like, it doesn't seem to care.

Thank you, I did manage to understand this part in the end. My new implementation oscillates the request line at 250Hz (ish), and sends a command frame immediately each time it receives a status frame. The timing didn't seem critical so I did it this way to keep everything event driven.

The part I'm still fairly clueless about (apart from what is obvious from Damien's code) is the content / structure of these packets. I guess some is still unknown? Also, there are some puzzling things in there, like why the command packets contain the sum of the current speed.

I'm definitely getting there with my understanding though. Thank you for your assistance. I will read the other thread properly and see what else I can earn there.

[catphish]

I delved a lot deeper into this after the VCU was forked off from my project, there are all sorts of things in the such as byte 1 (inverter state) being status bits for the current sensors, see here...

This is exactly the type of information I am interested in. I had hoped it might be fully documented and I just hadn't found the document! Obviously the more information I can pull from the inverter, and document in my code for future use, the better. Thank you again for the pointers.

[xp677]

I only documented the things I was interested in. The whole point of the htm masking in the serial diag for the VCU was that I was midway through finding things when I sent the code over to Damien. The mask was there to show me what was still left to decode without unnecessary clutter. Have fun.

I wrote a windows program in the end which pulled the same data out of the Due over UART and displayed it in a live spreadsheet which made it easier to read. I was finding that I had so much diag data that sending it out at 115200bps with any kind of real time updates was not possible while also sending the text headings etc, so I sent the data as a stream and decoded it on PC, where I could add the headings.

If I remember correctly, the Due shares the same serial buffer for all it's UARTs, and outputing too much diag data over UART can cause a bottleneck which slows down communication with the inverter.

[PatrcioEV-ATX]

By my math, even when railed high the ADC should be calculating a number lower than 109 C - is this just because of the fidelity of the variables in the code versus the fidelity of my excel sheet?

Did you ever get this solutioned? Right now, the temp readings are of no use. I don't even see the oil pump temp being used in the code. I've been working on cruise control and was thinking of using that 0-5v input as a trigger, but in testing, I can't get an analog read value below 808 on it.

[xp677]

Nobody ever looked at the temp sensors. Someone please sort this, I don't know how.

[evMacGyver]

For my own project, my next step will be to implement wifi, for both monitoring and configuration, so that tuning can be carried out more easily. Please let me know if you have any questions or suggestions about this, or if you find it useful, or think it's awful.

Edit: I realise I may be flogging a dead horse here, but I have a board in hand, so might as well make the most of it

Thank you for sharing! I earlier asked here about implementing new wifi for gs450h VCU, new wifi interface would allow configuration and monitoring, I highly suggest to research that. Personally I have not had time yet to research what needed to be changed. Priority is to get the car drivable hopefully soon.

I also like to implement new things to this VCU as I have this board to use, it should be powerful enough and suits for my need quite nicely.

[catphish]

I am looking at implementing temperature sensing. From what I've read, the board has a 1.8k pullup to +5v, but the NTC sensor is 47k @ 25v. If this is the case, I won't be able to measure anything below about 100C, and potentially risk damaging the MCU. Should I modify the board, or is this configuration fine for general use? What is normal operating temprature for the motors?

[xp677]

The 1K8 resistors were placeholders, and were not meant to make it to the final boards. Please specify a suitable alternate for the 4 temperature sensors. Then from there we can figure out the code.

Yes we should modify the boards for these resistors.

[steveknox]

Hi All,
I've taken my car for its maiden voyage, and I'm experiencing a an issue at low speeds. As I pull away, the box is really jerky, making a big racket. It was described as sounding like a machine gun. It reminds me of a motor that's not tuned to its resolvers properly, except the issue only manifests when MG1 and MG2 are both active -- when I run them on their own (by setting the torque value for the other to 0), the car pulls away smoothly.
Once I have some speed the issue goes away. Has anyone else experienced this?

[catphish]

Please specify a suitable alternate for the 4 temperature sensors. Then from there we can figure out the code.

Discussion on another thread states that the sensors are 47kOhm at 25C. This means the options are as follows:
A 47k resistor will allow a minimum temp of approx 10C.
A 22k resistor will allow a minimum temp of approx 27C.
A 15k resistor will allow a minimum temp of approx 36C.
A 10k resistor will allow a minimum temp of approx 47C.

The benefit of the smaller value resistor is better accuracy at higher temperatures, but accuracy is probably not critical, so 47k is probably a reasonable value to use for sensing the full range.

Once the hardware is fixed, the software shouldn't be too hard. It's not a trivial calculation, but plenty of documentation on the maths / code examples here: https://learn.adafruit.com/thermistor/u ... thermistor

NB. I haven't measured these resistors myself. It will be worth checking all 4 before reworking the board!

[xp677]

Oil pump temp and internal oil temp have vastly different sensors to MG1 and MG2 and will need different biasing resistors to suit.

The measurement is not trivial, the resistance is not a linear curve. It will follow a Steinhart-Hart function, the coefficients of which must be found through experimentation (measuring the resistance at known temperatures). Since the transmission will not fit in an oven or fridge, this will have to be done in ambient temperatures, giving a small range of readings. In reality, you want a reading from each extreme end of the desired scale and one in the middle.

In the GS450h, the motor temperatures often exceeded 70C.

https://www.thinksrs.com/downloads/pdfs ... ulator.pdf

I wrote a SHH function and some associated bits with this, never got the A B or C values sorted though. Here's a snip from my cooling code, this isn't active yet in my project, I just run pumps at full and fans at full when radiator water temp gets above 40C.

Code: Select all

//temperature sensors = final temps are in main file.
//#define TEMP_MG1 0 //these are in main file, just here for reference
//#define TEMP_MG2 1
//#define TEMP_TRANS 2
//#define TEMP_OIL 3
//#define TEMP_INSIDE 4
//#define TEMP_RAD 5
//#define TEMP_HEATER 6
//#define TEMP_OUTSIDE 7
float ntc_temp[8] = {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}; //temperature output in c

uint16_t ntc_raw[8] = {0, 0, 0, 0, 0, 0, 0, 0}; //0 to 1023 input
float ntc_ohms[8] = {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}; // R1* (1023.0 / (float)ntc_raw - 1.0};
float ntc_bias[8] = {249000, 249000, 18000, 680000, 100000, 10000, 15000, 100000}; //bias resistor in ohms
float log_ntc_ohms[8] = {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}; //working variable
float ntc_a[8] = {1.484778004e-03, 1.484778004e-03, 1.484778004e-03, 1.484778004e-03, 1.484778004e-03, 1.484778004e-03, 1.484778004e-03, 1.484778004e-03}; //steinhart-hart function
float ntc_b[8] = {2.348962910e-04, 2.348962910e-04, 2.348962910e-04, 2.348962910e-04, 2.348962910e-04, 2.348962910e-04, 2.348962910e-04, 2.348962910e-04}; //steinhart-hart function
float ntc_c[8] = {1.006037158e-07, 1.006037158e-07, 1.006037158e-07, 1.006037158e-07, 1.006037158e-07, 1.006037158e-07, 1.006037158e-07, 1.006037158e-07}; //steinhart-hart function

void process_ntc(uint8_t i)
{
  //at this point, we have already read ntc_raw from the input
  ntc_ohms[i] = ntc_bias[i] * (1023.0 / (float)ntc_raw[i] - 1.0);
  log_ntc_ohms[i] = log(ntc_ohms[i]);
  ntc_temp[i] = (1.0 / (ntc_a[i] + ntc_b[i] * log_ntc_ohms[i] + ntc_c[i] * log_ntc_ohms[i] * log_ntc_ohms[i] * log_ntc_ohms[i]));
  ntc_temp[i] -= 273.15;
  if (ntc_temp[i]>200)ntc_temp[i]=200;
  if (ntc_temp[i]<-200)ntc_temp[i]=-200;
}

void run_cooling()
{
  ntc_raw[TEMP_MG1] = analogRead(pin_temp_mg1);
  ntc_raw[TEMP_MG2] = analogRead(pin_temp_mg2);
  ntc_raw[TEMP_TRANS] = analogRead(pin_temp_trans);
  ntc_raw[TEMP_HEATER] = analogRead(pin_temp_heater);

  //demux: oil is Y5=1, radin is Y4=0, radout is Y6=2, outside is Y7=3
  ntc_raw[TEMP_INSIDE] = demux(0);
  ntc_raw[TEMP_OIL] = demux(1);
  ntc_raw[TEMP_RAD] = demux(2);
  ntc_raw[TEMP_OUTSIDE] = demux(3);


  //temp_dcdc1 and 2 are from CAN bus
  //6x module temps and 3x inlet temps from charger over CAN bus
  //battery temps from CAN bus
  //inverter temps from MTH

  for (int i = 0; i < 8; i++)
  {
    if (ntc_raw[i] > 0 && ntc_raw[i] < 1023) process_ntc(i);
    else ntc_temp[i] = 0.0f;
  }

[catphish]

Oil pump temp and internal oil temp have vastly different sensors to MG1 and MG2 and will need different biasing resistors to suit.

The measurement is not trivial, the resistance is not a linear curve. It will follow a Steinhart-Hart function, the coefficients of which must be found through experimentation (measuring the resistance at known temperatures). Since the transmission will not fit in an oven or fridge, this will have to be done in ambient temperatures, giving a small range of readings. In reality, you want a reading from each extreme end of the desired scale and one in the middle.

In the GS450h, the motor temperatures often exceeded 70C.

Thank you! Sounds like it will be more than than I'd hoped, as I'd assumed they would all be the same sensor. I'll see what I can find out by measurement. The exact coefficients probably aren't critical for a real world application, but would be useful if we could gather as many data points as possible.

In the meantime I have written a simple gear change process, and reinstated serial configuration code in my rewrite. Sadly it'll probably be another week or more before my motor is in a car and I can test it under real load conditions, so if I have a chance, I'll look at the temperature sensors in the meantime.

Code: Select all

  // If a gear shift is in progress, additional shenanigans are in order
  // here to ensure parts of the transmission dont end up in the road.

https://github.com/catphish/gs450h/blob ... L135..L154
https://github.com/catphish/gs450h/blob ... L445..L458

[xp677]

Good to see more gear shifting code - The current outstanding issue seems to be very rough shifts, even when limiting or zero torque applied at the time of shifting.

Pages 47 and 50 (38 and 41 indicated) will help with understanding the gearing arrangement: https://www.osti.gov/servlets/purl/947393

Agree that the temp sensor functions can be approximated, the issue is that the points of interest would be at the higher temperatures (>50C) where one would normally want to have their program act. Simulating these would be tricky! We cannot assume a linear relationship.

Thinking about it, a thing I missed was the opportunity to splice an adjustable resistor network into my GS450h's temperature sensor inputs, changing the values, and looking at the temperature readouts on the Toyota scantool. That way, I would have been able to plot resistance vs result and work back from there. Sadly the car is no longer with us!

I also imagine that these sensors would not be accessible even after opening the transmission.

Regarding your shifting points, try the shift up at MG1 > 5800. Shift down at MG1 < 3500 as you've done. Don't worry about MG2 speed, since with a locked input shaft, MG1 speed is limiting.

[catphish]

Good to see more gear shifting code - The current outstanding issue seems to be very rough shifts, even when limiting or zero torque applied at the time of shifting.

Pages 47 and 50 (38 and 41 indicated) will help with understanding the gearing arrangement: https://www.osti.gov/servlets/purl/947393

Thank you very much.

Please correct me if I'm barking up the wrong tree here, but my reading of this leads me to understand that there are two separate clutches, one for each ratio, and only one should be engaged at a time. If this is the case, is it not plausible that one solenoid deactivates the high ratio gear, and the other activates the low ratio gear? If this is the case, the correct procedure is to activate one solenoid ahead of the other, preventing both being simultaneously engaged?

On Monday I will wire up my oil pump and experiment with this on the bench. Hopefully I'll be able to observe the affect of activating each separately at rest and at low speed.

Regarding your shifting points, try the shift up at MG1 > 5800. Shift down at MG1 < 3500 as you've done. Don't worry about MG2 speed, since with a locked input shaft, MG1 speed is limiting.

In the first instance I intend to make this a manually activated shift, with only the downshift RPM limit for safety. I may look at automatically triggering it later though, depending on the driving experience.

Agree that the temp sensor functions can be approximated, the issue is that the points of interest would be at the higher temperatures (>50C) where one would normally want to have their program act. Simulating these would be tricky! We cannot assume a linear relationship.

Agreed. It looks like if we could get 3 points at wide enough intervals, then it would be possible to approximate the simplified B-only curve. However, I can't think of a good way to do this

Edit: I realise the questions about the gearing are a little off topic, and a Ravigneaux gearing is somewhat more complicated than I can wrap my head around at the moment. I will start a new thread about this. I found Damien's presentation on this gearbox. It certainly implies that the sensible thing to do would be to deactivate one clutch (brake) momentarily before activating the other. It also seems plausible that only one should be activated at once (as opposed to neither / both together. I will test when I can.

[xp677]

Please correct me if I'm barking up the wrong tree here, but my reading of this leads me to understand that there are two separate clutches, one for each ratio, and only one should be engaged at a time. If this is the case, is it not plausible that one solenoid deactivates the high ratio gear, and the other activates the low ratio gear? If this is the case, the correct procedure is to activate one solenoid ahead of the other, preventing both being simultaneously engaged?

On Monday I will wire up my oil pump and experiment with this on the bench. Hopefully I'll be able to observe the affect of activating each separately at rest and at low speed.

I struggled to follow exactly what happens in each scenario but you may well be correct. I think the best procedure would be:

Set torque to zero
Disengage motors from output shaft (if possible)
Match MG2 speed with new output shaft speed
Engage new gear selection
Reapply torque (ramp up)

In the first instance I intend to make this a manually activated shift, with only the downshift RPM limit for safety. I may look at automatically triggering it later though, depending on the driving experience.

This makes sense. From experience, the High gear gives plenty of acceleration already, you may find yourself never using the Low gear.

Agreed. It looks like if we could get 3 points at wide enough intervals, then it would be possible to approximate the simplified B-only curve. However, I can't think of a good way to do this

I was thinking about doing it the long way - testing in the winter and then the summer when the ambient temperatures are quite varied (at least, where I love). I looked at the document I linked earlier in a hope of finding out where the temperature sensors are located. Likely the MG1 and 2 sensors are buried in the stator windings can can't simply be removed.

Edit: I realise the questions about the gearing are a little off topic, and a Ravigneaux gearing is somewhat more complicated than I can wrap my head around at the moment. I will start a new thread about this. I found Damien's presentation on this gearbox. It certainly implies that the sensible thing to do would be to deactivate one clutch (brake) momentarily before activating the other. It also seems plausible that only one should be activated at once (as opposed to neither / both together. I will test when I can.

Yes, it would be good to generate a truth table for the 4 possible states for this. This could maybe be as simple as running MG2 on the bench, applying a small load (gloved hand may be enough) to the output flange to see what's engaged and at what speed, in the various states.