Lexus GS450H VCU Support Thread

[AdrianB]

I’ve been through both sets of Damien’s setup videos and I don’t think I’d have a problem with the programming of either. Adding components to the circuit boards isn’t anything I’ve done before though. Is there more of that to do on the Zombieverter VCU?

I would choose based on which processor you like programming. But if you won't be programming at all, then Zombie as it's more configurable without programming.

[celeron55]

The gs450h vcu firmware is really barebones and buggy so you kind of want to rewrite half of it for a road worthy vehicle in my opinion. Not the same for Zombie.

[catphish]

The gs450h vcu firmware is really barebones and buggy so you kind of want to rewrite half of it for a road worthy vehicle in my opinion. Not the same for Zombie.

There are quite a few firmwares for the GS450H now. It would be nice if we could do some testing, come to an accord and merge them! I'm happy with mine, however it needs a working vehicle to do more testing and finish the gear ratio change functionality.

Ultimately though, it doesn't really make sense to maintain both forever, so if Zombieverter does the same and more, the work should probably focus there.

[ggeter]

The gs450h vcu firmware is really barebones and buggy so you kind of want to rewrite half of it for a road worthy vehicle in my opinion. Not the same for Zombie.

I've had zero problems with the user version of the firmware. What are you experiencing?

[catphish]

I've had zero problems with the user version of the firmware. What are you experiencing?

It' definitely primitive, but I wouldn't say buggy either. The only bug I found while rewriting it was this buffer overflow vulnerability: https://github.com/damienmaguire/Lexus- ... 7.ino#L341

Otherwise as far as I can tell, it's simple and reliable. I added a web interface and lots of code comments, but can't complain much about the original.

[ggeter]

I've had zero problems with the user version of the firmware. What are you experiencing?

It' definitely primitive, but I wouldn't say buggy either. The only bug I found while rewriting it was this buffer overflow vulnerability: https://github.com/damienmaguire/Lexus- ... 7.ino#L341

Otherwise as far as I can tell, it's simple and reliable. I added a web interface and lots of code comments, but can't complain much about the original.

I'll admit the only problem that I had was setting the the max torque too low. When the max torque is less than a thousand, the motor will hitch and start and not accelerate very well at all. I had to set the max torque to maximum 3200 and everything has worked out fine since.

[celeron55]

I guess the "buggy" part is mostly me as a software engineer not trusting the code at all after reading it. But when bench testing, the motors occasionally kick very hard, in a way that seems like full torque is being applied for a split second, when I have the torque configured down to very little.

Of course in an actual vehicle application, full torque for a split second is probably almost undetectable and assuming it stays at that duration it's not unsafe either. But it does not give me the confidence I need for my project. For me, this does not matter, as I will in any case rewrite most of the code to heavily integrate with the rest of the vehicle. But it might to someone who isn't going to touch the code.

[catphish]

I guess the "buggy" part is mostly me as a software engineer not trusting the code at all after reading it. But when bench testing, the motors occasionally kick very hard, in a way that seems like full torque is being applied for a split second, when I have the torque configured down to very little.

That's interesting, I had a couple of issues during my rewrite where I accidentally cast a signed int to unsigned, causing a -1 torque to become 0x7FFFFFFF torque (which is quite dramatic), but I'm not aware of any such errors in the original code. Ultimately, there really isn't much that can go wrong, all we do is send a pair of integers to the inverter to request an amount of torque.

[Jack Bauer]

If there is a problem or bug in the code then please identify it and submit on github so it can be remedied. I'm not a software engineer by any measure and the assistance of someone who is would be invaluable in this and other projects.

[catphish]

If there is a problem or bug in the code then please identify it and submit on github so it can be remedied. I'm not a software engineer by any measure and the assistance of someone who is would be invaluable in this and other projects.

Absolutely this! Unfortunately, my fork is too large for a pull request (it's basically a rewrite), but I'd seriously encourage people to do pull requests where at all possible for small fixes.

[PatrcioEV-ATX]

I guess the "buggy" part is mostly me as a software engineer not trusting the code at all after reading it. But when bench testing, the motors occasionally kick very hard, in a way that seems like full torque is being applied for a split second, when I have the torque configured down to very little.

Of course in an actual vehicle application, full torque for a split second is probably almost undetectable and assuming it stays at that duration it's not unsafe either. But it does not give me the confidence I need for my project. For me, this does not matter, as I will in any case rewrite most of the code to heavily integrate with the rest of the vehicle. But it might to someone who isn't going to touch the code.

Check out Catphish's code on his github (it's in this thread somewhere). You can pick and choose what parts of it you want to use, but his code is super clean. I rewrote the User version along the same lines as his code. At this point, I think most of us are using our own particular code based on the User code.

[catphish]

Check out Catphish's code on his github (it's in this thread somewhere). You can pick and choose what parts of it you want to use, but his code is super clean. I rewrote the User version along the same lines as his code. At this point, I think most of us are using our own particular code based on the User code.

Thanks! Here's the link again: https://github.com/catphish/gs450h
I can't claim that it's any better than any other version but it has some interesting features including web interface, and hopefully it's easy to read and understand.

[celeron55]

I agree catphish's version looks very readable. I'll try it out once I have the time.

[evMacGyver]

Just a small caution if anyone uses due_can library with this board..

I got long debugging session for some weird behavior, during that I found out due_can library does use enable pins and one is by default same as GS450h board uses for OUT1:
#define CAN0_EN 50 //these enable pins match most all recent EVTV boards (EVTVDue, CAN Due 2.0)

I did not check code more, at least on initialization it does set this pin HIGH. On my case it was HV+ contactor, not so good. As enable pins of CAN transcievers are not used on gs450h board, you may remove digitalWrite lines from library as I did. After doing this there was one mystery less for me, yippee!

[Gregski]

for those of us who prefer to listen to the Beatles on vinyl and control our GS450hayches using the [ahem] Classic controller I just got word that the Cinch 40 Pin Header Connector Part# 5810140011 is back in stock at Digi-Key by popular demand

[ianhora]

Hi Damien,

Just wondering if you realize that the pin numbers on the drawing of the Toyota 40-pin header are not the same as the numbers on the back of the header? On my header (on a 2010 Toyota Crown hybrid inverter, part number G9200-30070) pin 1 is where you have pin 32 and vice versa.
Please correct me if I'm wrong. It was doing my head in when buzzing out that internal loom!
I needed to buzz it out to check that the Crown inverter 40-pin header wiring was the same as that on the GS450h inverter.
As it happens, it is!
So with the internal looms and 40-pin header being identical, and the logic board part numbers of F1759-30010-01 being the same, can one assume that everything's going to work?

Also, pin 8 of the 32-pin connector on the GS450h inverter/converter internal connections drawing is missing its GND label.
ie. should read MG2 SINE GND.

Ian

[dadiowe]

On my build the capacitors in the Lexus inverter are not discharging and even after 24 hours they are HOLDING HV VOLTAGE almost to the level of the battery pack i.e. 400 Volts. If I take a voltage reading, with the HV battery completly disconnected, at the terminals of the inverter I have just short of 395Volts.
As I understand it the inverter capacitors are supposed to discharge through the MG1 and MG2 connections to the GS450H Transmission.
Obviously not a great state of affairs!!!

I hope no one else has experienced this issue.
Any guidance regarding this would be really appreciated.

[Romale]

On my build the capacitors in the Lexus inverter are not discharging and even after 24 hours they are HOLDING HV VOLTAGE almost to the level of the battery pack i.e. 400 Volts.

there should be a ceramic resistor at 15 kohm or so current connected at + and - high voltage. its purpose is to smoothly discharge the capacitor after disconnecting the battery. it's probably missing or not connected to you.
mg1 and mg2 motors are not involved here

[dadiowe]

Hi Romale,
Thanks for the reply.
Is this the sort of thing you mean?

https://uk.farnell.com/ohmite/45f15ke/r ... dp/2448950

Thanks again

[Romale]

Hi Romale,
Thanks for the reply.
Is this the sort of thing you mean?

https://uk.farnell.com/ohmite/45f15ke/r ... dp/2448950

Thanks again

hello. the link doesn't open for me. here is a photo for example, this is in the Nissan em61 inverter, but the same detail is in all high-voltage inverters of Toyota, Lexus, Tesla and others. one end of it is connected to the + and the other to the - high-voltage input in the inverter. when the main contactor is turned off, the voltage of the conductors will discharge to this resistor.

[xp677]

On my build the capacitors in the Lexus inverter are not discharging and even after 24 hours they are HOLDING HV VOLTAGE almost to the level of the battery pack i.e. 400 Volts. If I take a voltage reading, with the HV battery completly disconnected, at the terminals of the inverter I have just short of 395Volts.
As I understand it the inverter capacitors are supposed to discharge through the MG1 and MG2 connections to the GS450H Transmission.
Obviously not a great state of affairs!!!

I hope no one else has experienced this issue.
Any guidance regarding this would be really appreciated.

No, it doesn't discharge through MG1 or MG2. There is no mechanism for that. There is instead a ceramic bleed resistor inside the converter housing.

[dadiowe]

hello. the link doesn't open for me. here is a photo for example, this is in the Nissan em61 inverter, but the same detail is in all high-voltage inverters of Toyota, Lexus, Tesla and others. one end of it is connected to the + and the other to the - high-voltage input in the inverter. when the main contactor is turned off, the voltage of the conductors will discharge to this resistor.
IMG_20221025_161226_1.jpg

Thanks Romale that sorted my inverter discharge problem

[Bookie]

Hey guys, first post here. Been lurking a while and wanted to share the pinout I'm using for the Molex replacement inverter connector, I didn't see this documented anywhere so apologies if this has been covered before. If it looks good I'll add it to the wiki.

[Dan--T]

Hi all, apologies for probably too simple a question. I am a mechanical engineer way out of my comfort zone with all this talk of coding, and I do not have capabilities to write my own code.
I have the "classic" VCU (ver2). In a video about a year ago ( ) Damien mentioned that the SW developed for the zombieverter would be able to be back ported onto the gs450h VCU. And from memory that this would include some more user friendly config setup and features etc. For us non electrical/software engineers.

Does anybody know if this has already happened or is still planned to happen?

Thanks
Dan

[crasbe]

Does anybody know if this has already happened or is still planned to happen?

Unfortunately I think that at the moment it's not very high on the priorities list. HOWEVER it shouldn't be impossible to adapt the ZombieVerter code to run on the old VCU because libopencm3 supports the SAM3X8E.

For the time being I'd recommend sticking with the serial configuration interface of the old VCU, it's not terrible to use, just not as fancy as the web interface.