Holset VGT Electronic Controller Project

[Mistaken]

So ive began working on developing a stand alone electronic controller for the newer generation Holset VGT turbos (ie: HE351VE). I'm a mechanical engineering major at Kettering university and im also being assisted by an Electrical Engineer i work with. I have a fairly extensive background in automation and automotive design for my age, since its what I do at work everyday.

I already have the basic electrical components selected and ordered. The goal for the project is a fairly basic, but effective controller, that has a 3 digit price tag only. I could easily make a hell of a setup using a nice motion controller but that would cost thousands.

I wanted to do some some research in the RB community before i started the programming aspect, just to see what kind of control you guys would like to see in the unit.

I was thinking about starting simple, by having it actuate the VGT stepper motor based on a MAP reading which it would correlate to a given position. I think that is a good starting point, as that in itself is a hurtle to overcome.

Are there any other future control options you would like to see? IE: TPS specific control curves, turbo speed control, EGT control

Or is allowing the computer to always attempt to build boost acceptable?

I really would like everyones input on the idea before I kick off programming,

[Cjmartz2k]

This sounds freaking AWESOME. I don't know anybody who wouldn't want a 600rwhp capable turbo that was at full boost by 2000rpm LOL.

Besides MAP input, I'd think TPS maps would help so the turbo would be helpful at part throttle, off boost driving. Not really an expert, but it makes sense in my head. I'll be on of your first customers for this if/when you get it up and working.

[WhatsADSM]

So ive began working on developing a stand alone electronic controller for the newer generation Holset VGT turbos (ie: HE351VE). I'm a mechanical engineering major at Kettering university and im also being assisted by an Electrical Engineer i work with. I have a fairly extensive background in automation and automotive design for my age, since its what I do at work everyday.

I already have the basic electrical components selected and ordered. The goal for the project is a fairly basic, but effective controller, that has a 3 digit price tag only. I could easily make a hell of a setup using a nice motion controller but that would cost thousands.

I wanted to do some some research in the RB community before i started the programming aspect, just to see what kind of control you guys would like to see in the unit.

I was thinking about starting simple, by having it actuate the VGT stepper motor based on a MAP reading which it would correlate to a given position. I think that is a good starting point, as that in itself is a hurtle to overcome.

Are there any other future control options you would like to see? IE: TPS specific control curves, turbo speed control, EGT control

Or is allowing the computer to always attempt to build boost acceptable?

I really would like everyones input on the idea before I kick off programming,

There has been a lot of talk about this in the past as well. There is also another guy on the net somewhere (240z I think has is name) that is essentially mounting his hardware to the stock housing and controlling that.

Sure you can cut open the box and mount a servo but the heat, and mechanics will definitely pose a challenge I think. In my eyes why bother re-inventing the wheel... FWIW the best solution is almost a completely FW/SW solution using the stock hardware. Even if you do get some sort of a servo mounted on there I'll bet the stock Bosch setup is a better and more reliable setup anyways.

So yea I say Just talk to the thing over J1939. Bosch was heavily involved in the creation of that protocol and I wouldn'tbe surprised one bit if the application layer stuff for VGT is explicitly spelled out in some of the SAE docs.

As for the control algorithm themselves they shouldn't be too hard. Could be table driven with a 3d base load vs. rpm. And/or a 2d TPS versus desired load (which would be nice and make the car feel a lot more NA like).

[WhatsADSM]

This sounds freaking AWESOME. I don't know anybody who wouldn't want a 600rwhp capable turbo that was at full boost by 2000rpm LOL.

Besides MAP input, I'd think TPS maps would help so the turbo would be helpful at part throttle, off boost driving. Not really an expert, but it makes sense in my head. I'll be on of your first customers for this if/when you get it up and working.

I don't think it will be full boost by 2000.. IIRC it knocks off maybe 1000 or so RPM of spool. If you search the net there is a nice PDF on it by Cummins I believe that has some graphs of spool difference.. Also, the transient response (assuming the controller is good) is amazing!

[WhatsADSM]

Speaking of...

Looks like these guys have got it pretty much figured out.

http://www.youtube.com/watch?v=7EDCKvkQoaE

[Mistaken]

Yah the idea is to retain the factory delphi control unit, as its built for the heat already. It comes factory watercooled, so as long as you dont overheat the motor it should stay under its maximum operating temperature.

The problem i found with using J1939 is that a control that will easily communicate with the CAN protocal is not gonna be a cheap option. We have found another way we think will work with a much cheaper unit. Although this unit will do CAN also, it would be a hell of a programming accomplishment to get it to work and work as smoothly as the other option.

A note on spool, although im not sure how correct what ive heard is, a few guys on the DSM forums were claiming 20psi by 2000rpms. I believe it could be close to that, but that seems a little fast to believe. The HE351VE i believe is a .31 a/r at full close, and close to a 2.00 a/r at full open. Even if the spool times werent that insane, you could make up massive power under the curve from added efficiency of opening up the a/r at top end to lower back pressure.

[Mistaken]

Good find on the video, wish I would have seen it sooner. O well I can always still try to make a little competition for them. The route im hoping to go should allow me to severy undercut them on cost.

On a side note, it looks like their controller taps into the factory unit. If you watch the one video you can hear a truck running in the backgroung with the sound of a turbo spooling as the one on the floor moves. My guess is they tapped into the factory wiring to demonstrate that their controller will modify the factory signal and just ran wires out to the second turbo.

I'm hoping to have a production version ready and tested by summer. I'll probably stay small scale on production, just selling em off of forums or to a select few retailers....rawbrokerage?

[WhatsADSM]

The stock units either talk CAN J1939 or PWM... Although Delphi specs a PWM unit I don't think I have ever been able find find one that was used by an OEM. I think all the OEMs went with the CAN unit.

As far as using CAN, it shouldn't be expensive at all... After all, software is "free" Just that the upfront cost for the engineering and/or reverse engineering might be a little more expensive.

I guess I am confused as to how you plan to keep the stock hardware and not talk CAN? If you use the stock hardware it needs to be CAN (and to clarify J1939 over CAN). Otherwise you can *maybe* play around with the existing PCB and take over direct control of the servo... but doing that on a larger scale may be hard. Also from what I gather it is not a simple unipolar or bipolar stepper in there.. It is a 3-phase brushless DC, with obviously some sort of encoder on it. Definately a little more complex.

The video has the truck running because that is their market. They also plan to have inputs feed the control algorithms from the existing CAN bus on the truck.... But from what I gather they are in direct control of the VGT actuator.

[Darius]

[Mistaken]

I located a PLC that will do j1939 CAN, just gotta find a supplier for it and figure out how much that would cost. Just to explore the option of it.

The only problem I see with trying the j1939 CAN route is attempting to figure out what the signal the current control unit is sending to the delphi control unit is.

[Mistaken]

A note on the 3 phase BLDC motor, if i can retain the original Holset drive system, all I have to do is run a single power and ground to the controller, and then my Hi and Low signals for the the J1939 CAN system. The wiring should be an absolute no brainer, the main challenge to overcome is gonna be the programming for the communication between the PLC and holset driver board.

[WhatsADSM]

A note on the 3 phase BLDC motor, if i can retain the original Holset drive system, all I have to do is run a single power and ground to the controller, and then my Hi and Low signals for the the J1939 CAN system. The wiring should be an absolute no brainer, the main challenge to overcome is gonna be the programming for the communication between the PLC and holset driver board.

Yes all that the box should have is +12v, gnd and CAN hi and CAN lo. You would also likely have some simple analog/digital inputs since you need some inputs to the control algorithms

Keep us posted on the PLC thing. My guess (and I work directly in the automation industry) is that the PLC won't work for any reasonable type of cost. Proof of concept, or a one off thing for someone with a TON of money in a race car maybe, but if you were actually looking to sell them kind of cheaply, that solution is almost surely out the window.

IMO when I was looking at doing this a while ago it was going to be a ground up approach... Or at least very close to it.

I do have a buddy that recently picked up the HE351 and was thinking about putting it on his 1g DSM and told me to take a quick look at the electronics. So I may take a look at it pretty soon as well. It is actually the second person to come to me with the same request so that kind of perked my interest, especially since it is for a very close friend. If I actually have some time to do it and find anything I can keep this thread updated.

[240z4u]

Mistaken, I have thrown in the towel on this project for now. Pretty much just don't have time to concern myself with it. I have an HE351ve in my garage taking up space.

Email me directly if you want it, ill make you a good deal. I gotta free up some shillings for my subaru.

Evan

[Mistaken]

Yah im still waiting to hear back on the PLC, my guess is that its gonna be an outrageous price tag on it, but we will see. It would be really nice to have something that does J1939 right out of the box.

Any information and input you can give from taking a look at the controller off that turbo will be great. I wont have my turbo/controller till sometime next week due to the holiday.

[Mistaken]

Mistaken, I have thrown in the towel on this project for now. Pretty much just don't have time to concern myself with it. I have an HE351ve in my garage taking up space.

Email me directly if you want it, ill make you a good deal. I gotta free up some shillings for my subaru.

Evan

I sent you an email.

[blownhemi]

Wouldn't it be cheaper (may be even simpler) to find a driver IC for whatever motor is in there moving the plate? And just control it with dime-a-dozen off-the-shelf microcontroller, which is fed with the signals RPM / TPS / MAP?Did you have a look at the insides? Maybe there's already a driver IC in there, which has simple STEP/DIR pins?

[Mistaken]

There is a stepper driver already integrated into the turbo, but it communicates with the primary VGT controller via J1939 can bus. So basically it recieves power/ground and a HI can and LOW can signal. From there the primary controller sends it a message of a specific format telling it what to do.

Also im still trying to use a off the shelf microcontroller to replicate the proper signals needed.

[240z4u]

Hey bud< I didn't get an email from you. Ill email you so you can reply.

[blownhemi]

I don't know, which uC you have chosen, you might be already working on this exact solution, for all I know, but I just thought I'd mention, Microchip has a J1939 library written in C for their CAN2.0b capable line of microcontrollers, so the tedious application layer part could probably be taken care of with this.http://www.microchip.com/wwwpr...20612

[zmannz]

Has anyone built a simulator or datalogger of some sort to record the states of the CAN wires to the operation of a correctly working stock application? Sort of a JimStim type device that speaks the language used. I think with some time this could be done, then you could try to copy the stock operation to x degrees before over complicating the whole thing with finding new ways to input data to it. I don't know much about CAN yet but I am learning, please don't flame if this was a stupid idea.

[Mistaken]

Naw Z thats a really good idea, ive been looking around to see if they make any sort of CAN "datalogger" i could maybe use to monitor signals sent by the main ECU.

I also looked into the possiblity of pulling the program off of the driver IC, but the main problem with that is once you burn the program to the chip its no longer in C language, its all compiled into a language the IC understands. Which would probably be impossible to decipher, unless u could make some reverse compiling program or something of the sort.

[WhatsADSM]

Hemi:

Again, I'll repeat it is not a stepper motor in there.

The J1939 library in C for the microchip could definately help a little bit but it would not take care of the application layer. But should take care of most of all of the data link layer.

[Mistaken]

Hemi:

Again, I'll repeat it is not a stepper motor in there.

The J1939 library in C for the microchip could definately help a little bit but it would not take care of the application layer. But should take care of most of all of the data link layer.

It's more or less a servo motor

[blownhemi]

The application layer IS J1939 (mostly). The physical and the data link layer is CAN, and that is taken care of by the uC's built-in CAN controller. Of course, we can consider the correct PGNs part of the application layer, and in that sense, you're right, the C library really does not take care of all of it.

Another possible approach:http://www.4btswaps.com/forum/...58919Some guys here already took the unit apart, dont't know, if you did already. There's an ST microcontroller in there, and a Freescale motor driver. I searched on Freescale for motor driver IC's, and they seem really simple, have a step/dir interface, and also some digital interface, and position feedback. I guess the ST is the CAN controller interfacing with the outside, and the Freescale is really just a 3ph BLDC motor driver. So I wonder if it really wouldn't be simpler, like WhatsADSM suggested earlier, to just cut away the ST uC, and interface directly with the motor driver (given the IC packaging and the PCB allows this to be performed safely). It won't be as elegant, won't be plug-and-play, people would have to send you their electronics to modify, but it could be an approach, if you can't get your hand on those Holset-specific(?) messages. For those, maybe you could find someone on big diesel forums, someone who is near you, and would be willing to let you connect a logical analyzer or DSO to the unit in its stock place (don't know what vehicles do...) and catch some messages.

[WhatsADSM]

The application layer IS J1939 (mostly). The physical and the data link layer is CAN, and that is taken care of by the uC's built-in CAN controller. Of course, we can consider the correct PGNs part of the application layer, and in that sense, you're right, the C library really does not take care of all of it.

Another possible approach:http://www.4btswaps.com/forum/...58919Some guys here already took the unit apart, dont't know, if you did already. There's an ST microcontroller in there, and a Freescale motor driver. I searched on Freescale for motor driver IC's, and they seem really simple, have a step/dir interface, and also some digital interface, and position feedback. I guess the ST is the CAN controller interfacing with the outside, and the Freescale is really just a 3ph BLDC motor driver. So I wonder if it really wouldn't be simpler, like WhatsADSM suggested earlier, to just cut away the ST uC, and interface directly with the motor driver (given the IC packaging and the PCB allows this to be performed safely). It won't be as elegant, won't be plug-and-play, people would have to send you their electronics to modify, but it could be an approach, if you can't get your hand on those Holset-specific(?) messages. For those, maybe you could find someone on big diesel forums, someone who is near you, and would be willing to let you connect a logical analyzer or DSO to the unit in its stock place (don't know what vehicles do...) and catch some messages.

Now I think we are all on the same page!

IIRC Yea the microchip library essentially handles the data link layer only. J1939 most certainly does put its own spin on the CAN 2.0 data link layer... mostly with the 29-bit identifiers. It is still up to the user using the library to package together all of the needed data for the SPNs, PGNs, periodic send rates etc. No way Microchip can write the application layer because they don't know what you are trying to do

Yea it would definately be interesting to see exactly what part of the motor control is being done by the ST micro and what by the freescale part. There is clearly some form of position feedback.... I wonder if it has an encoder on it, or hall sensors, or sensorless?!

[Mistaken]

Now I think we are all on the same page!

IIRC Yea the microchip library essentially handles the data link layer only. J1939 most certainly does put its own spin on the CAN 2.0 data link layer... mostly with the 29-bit identifiers. It is still up to the user using the library to package together all of the needed data for the SPNs, PGNs, periodic send rates etc. No way Microchip can write the application layer because they don't know what you are trying to do

Yea it would definately be interesting to see exactly what part of the motor control is being done by the ST micro and what by the freescale part. There is clearly some form of position feedback.... I wonder if it has an encoder on it, or hall sensors, or sensorless?!

Awesome find on the diesel thread.A theory I came up with after reading through that forum:

Now knowing that the drive has its own Eprom in the actuator, it sounds like it is only using the can bus to send it position signals. Maybe just rpm, egt, turbo speed?

If so, then all fleece performance is doing is manipulating the signals between from the sensors that are being sent to the turbo. Allowing them to "tune". Using the simple j1939 protocals for signals we should be able to send the turbo the information it is looking for to go to the proper position.

but of course just a theory lol

[blownhemi]

That could work. If it's just waiting for the standard J1939 broadcast messages from the other sensors, and works completely autonomous from those, then you don't need to look for any manufacturer-specific messages by tapping into buses, just read through the J1939/71 paper.Also, if it was working this way, it would also be much easier for an engine manufacturer to integrate the unit into their exising engine system, so there's a higher chance, that Holset went this way with the design.Still would have to find out, which parameters exactly it reacts to, but that could also be done by brute force. Maybe even one parameter is enough to cover the whole range, while leaving the others at their powerup-default value in the ST uC.

All you need now is a J1939 controller...

[Mistaken]

I'm already working on selecting an open source J1939 CAN controller.

I'm trying to decided if i want a PIC based one, since we found that J1939 library, or if I want to go ST since the delphi actuator already is ST.

Something arduino compatible would be nice, but the company that is working on the arduino based STM32 cortex-m3 board wont be releasing their production version for another few months.

[blownhemi]

Another thing popped into my mind, if that EPROM in fact contains lookup tables for vane ring settings based on RPM, TPS, EGT, MAP, etc., then it might contain completely different data on other models of VGT turbos, or even for the same turbo in a different application, and control methods might not have the same effect on a HE351VE as on a HE431VE... all of this is just assumption, of course, nothing is yet ceratin, just a thing to keep in mind.

I don't think it matters what kind of controller the turbo unit mounts, as they will be communicating over an industry standard interface, anyway. I'd probably go Microchip, but that's only because I've already worked with PICs a bit, so it's not completely unknown.

On another note, googling "delphi smart remote actuator PWM", I've found some further food for thought:http://www.theautochannel.com/....html"the smart remote actuator receives a position command from the engine control unit" - if true, it negates some of our previous assumptions...http://www.patentstorm.us/pate....html - a patent titled "Actuator controller for selecting a communication language".... filed by Delphi Technologies, Inc. oOhttp://www.freepatentsonline.com/20030028257.pdf - the PDF for the above, with figures, save with the little diskette icon. Good read. What it boils down to in my mind is that it might be possible to send the thing a PWM, and expect it to recognize it automatically, and switch to PWM control... but someone else should read it through, too. Unclear whether the same wires would be used for all comm. methods, and if yes, how? Maybe differential signaling of the PWM signal over the CAN-Hi Can-Lo wires?http://www.faqs.org/patents/app/20090108793 - some further mentions of the multiple language thing, another patent by Delphi.

[Mistaken]

I read through the patent, and to me it sounded like you could send it any one of a few different signals and the controller will automaticall recognize it. I've got an arduino sitting at home and I am picking up a turbo on monday. I'll just write up a simple pwm modulation program to try and get it to follow a potentiometer or something just to see if it will move at all. That would be amazing if it did, because again, it would make my life much easier then trying to figure out the j1939 can protocal position commands.