VGT Turbo M20 Sleeper ('87 325 Sedan)

[mikey.antonakakis]

Could it be Stiction in the valve? Possibly present at temperature but not when the engine is off?

Could be... although I let the car idle for 30+ min and as soon as I started driving and actually included any engine speed/turbo compressor, it started acting up a bit. My "bench tuning" at idle prior to this wasn't 100% repeatable either. I've got some more investigation to do.
A related point: I'm using a JGS wastegate (JGS400 v-band). Nicely made unit, piston-style actuator rather than diaphragm. The piston area is only slightly larger than wastegate valve area, different than many external gates that have a large-diameter diaphragm. This means the boost level is more sensitive to turbine pressure. This probably explains why my 130kPa (absolute) base boost with 65kPa (gauge) on the dome only gave me about 165kPa MAP (basic idea of dome control, that dome pressure adds to spring pressure, says I should have been at 195kPa MAP in this condition).

[Panici]

In addition to that, the opposite condition is also happening - I am undershooting in both directions despite a constant command to either fill or vent the dome.

Could it be Stiction in the valve? Possibly present at temperature but not when the engine is off?

[mikey.antonakakis]

Did some refinements to VGT algorithm, basically adding more adjustability. Have an occasional wild fluctuation at/near full boost where the algorithm closes the VGT a ton for some reason. Should be straightforward to figure it out.

Dome control solenoids are behaving a lot better at lower PWM frequencies, but by necessity I need to run the PID loop at a lower frequency as well, which gives a little more fluctuation. I at least got it fairly stable and repeatable, but there is a decent amount of error that doesn't entirely make sense to me. Like in the data below:

• before and during spool-up, I keep the dome pressure high to keep the wastegate seated.
• Then as I approach my target boost, I drop the dome target to the value that will net my boost target - in this case, 25kPa above barometric (105kPa absolute).
• The solenoid control at that point is commanding between -23 and -30, which means the fill valve should be fully shut and the vent valve should be venting a decent amount.
  • All it has to vent in this instance is the volume of air in the wastegate dome and a few inches of 1/4" OD hose.
  • Despite that constant vent command which should totally and immediately shut the fill valve and vent the wastegate dome to atmosphere (confirmed in testing at engine idle/engine off), my dome pressure is staying at 140-145kPa absolute.
  • So either:
    • The fill valve isn't shutting fully due to mechanical issue or incorrect command signal (should cause compressor in trunk to run a lot more often than it was, so I don't think it's this)
    • The vent valve isn't venting due to mechanical issue or incorrect command signal
    • Boost is leaking past the wastegate seals? It would have to be a big leak to overpower the vent solenoid if it's working properly

In addition to that, the opposite condition is also happening - I am undershooting in both directions despite a constant command to either fill or vent the dome. Prior to reaching the boost target in the log below, my dome target is 315kPa absolute and actual is 278kPa absolute, and the command is +26. This command value should fully shut the vent and open the fill a decent amount, which should very quickly bring me up to source pressure (~355kPa absolute).

One of the things I can also try is to change the plumbing for the vent solenoid. Currently fill solenoid is normally closed and vent is normally open (when not energized), ensuring the dome pressure stays at atmospheric if there's a wiring failure or something. But looking at diagrams from Holley or others, it looks like often they run both valves normally closed. This inverts the required signal at the threshold of opening/closing the vent solenoid, maybe the vent solenoid will be happier running normally closed. I have overboost protection turned on permanently, so not too much of an issue if something goes wrong.

vent_not_venting_2022-05-30 by Mikey Antonakakis, on Flickr

[mikey.antonakakis]

Another test drive tonight. Majority of bugs are fixed, will probably still make some refinements to parts of the algorithm. Overall though it is working smoothly and predictably, needs more tuning.

Facing one major frustration right now - boost solenoid inconsistency. It’s super important to get a good characterization of the solenoid open threshold (how much PWM to get it to start to crack open). On a 0-255 PWM signal range, it varied anywhere from 55 to 95 tonight for my fill solenoid. Vent solenoid was a little more consistent, but still problematic. This variation throws off the PID controller a huge amount. As I type this it’s just occurred to me that maybe I am being too aggressive with PWM frequency, currently set to 70Hz. Maybe too much dead time for that. Will try 20-40Hz tomorrow to see if that makes them more consistent.

[mikey.antonakakis]

Finally got the test drive in! There are a few bugs in the code, but I was able to sort some of them while driving. For instance, I’m using VE in part of my algorithm, assumed MS sent as 0.96 rather than 96%, which threw the math off by a huge amount. Easy fix that got the new VGT algorithm functioning on a basic level.

There are still a few issues, for example I offset the boost target a little before I include it in the VGT algorithm in order to ensure the vanes open fully at full boost - the new algorithm is a little too harsh with this at low rpm, though. The vanes snap fully open and cause boost to drop, so the vanes close, a nice oscillation.

I ran this whole session on wastegate-only, with a lighter spring. Getting me 135kPa MAP for full boost (“5psi” if I was at sea level). Even at this low boost the car is quick, absolutely shredded the tires on a first-gear rolling 2-step launch test (2.93 diff).

Dome pressure control PID code is working well in the garage at this point. The version rolled into the full display/VGT code must have some critical bug though. I made that section of the software switchable (enable or disable it), and enabling it caused the microcontroller to lock up, so I’ll have to see what that’s about… I have a feeling I know what’s going on, will look into it tomorrow.

Anyway, the VGT algorithm overall seems to work really well. For the purpose of running on wastegate-only (to measure wastegate-only boost level for the dome pressure control) I disabled the “keep the wastegate slammed shut during spool” feature, and from experience that means I wasn’t spooling as hard as I could be. With hardly any VGT tuning it already seems to spool faster, especially at lower engine speeds. Like, 1800rpm I can make a couple psi in a few seconds. 3000rpm I get to 3psi in about 1.5 seconds before the spool really takes off. The code is a lot more manageable now, a lot easier to change settings quickly for comparison.

Going to iron out some of the bugs/imperfections this weekend and get some data to compare old vs. new algorithms.

[mikey.antonakakis]

Oh and Ground Control coilover conversion and Koni sports are on their way, and I’ve got a Z3 rack waiting for my Garagistic order to ship… (ordered 3 weeks ago, but seems like the delrin steering flex disc was backlogged). Finally replacing the last of the original suspension! (Well, still need swaybars…).

I think the shocks may be original and the rack in the car now is worn causing play between the front wheels despite brand new tie rods, control arms, strut mounts, etc. It will be nice to have non-sloppy steering for the first time ever with this car! I might even wash it for the first time in, I don’t know, 9 years? Gotta be frugal with the washes, the clearcoat is long gone and you can wipe the powdery paint off the car with your finger!

[mikey.antonakakis]

After much convolution of thoughts and plans and algorithms I think I have the VGT code (and wastegate dome code) sorted out. Hopefully some testing tonight. Put finalizing the touchscreen OBC board/controller on hold so I could finish the VGT code, I wanna drive the car!

[mikey.antonakakis]

To demonstrate with some real data that the current algorithm isn't ideal, see the following snippet.

• You can see the vanes (white line bottom plot) stay "most-closed" until MAP (red line top plot) gets 65% of the way to boost target (yellow line top plot). At that point, it starts to open rapidly, marked with first vertical line.
• A very short time later (second vertical line), the vanes have opened significantly and boost starts to climb more slowly.
• However, between those two points, boost response is the best out of the whole plot!

So at the very least, once it starts to open the vanes again, it's WAY too aggressive at opening them. Boost is still rising after then vanes are fully open (hence the need for a wastegate...), but it rises much more slowly.

boost_flatshift_2022-05-19-2 by Mikey Antonakakis, on Flickr

[mikey.antonakakis]

Here's a quick and dirty model of the VGT response, comparing the previous algorithm to the new one. Qualitatively, it ramps the vanes open as soon as boost starts to build, and opens them fully once the boost target is reached. The old version kept the vanes fully closed until MAP gets to 65% of the boost target, then ramps to full open. So, kind of the opposite approach. There's a lot more nuance than that, but that's the simplest explanation. In practice I think this means I can get more aggressive when I initially close the vanes.

To add one level of nuance: the "most-closed" vane position is currently engine speed-dependent and has been tuned seat-of-my-pants. I shouldn't close the vanes the same level at 5000rpm that I would at 3000rpm, the flow would obviously choke more at 5000rpm. The concept here is to try to find this choke point empirically: measure things at a specific engine speed like initial boost response rate when going WOT, or monitor AFR, adjust the most-closed position, repeat. There's going to be an ideal "most-closed" position for a given engine speed where the initial boost response is best, and significant choking of the mass flow will show up in AFR. I have a feeling the point of best response is similar to the point where the flow starts to choke. Initial boost response vs. most-closed setting should have a hump shape, need to find the setting that gives us the peak.

Using the speed-density concept, should be able to then estimate relative mass flow from that initial response level, and map out in two or three dimensions how to open the vanes. Adjust from that calibrated ideal "most closed" point proportionally to engine speed, MAP, and VE (from the fuel table) and that should give a decent starting point for the VGT calibration. There will be a little error since VE table is set to richen the mixture, but heck, I could even correct that out by monitoring AFR. Might have to correct for EGT too. In any case, the math/algorithm is model-based, but model will be calibrated to match the real world as much as possible.

Example: Hypothetically I measure initial boost response a bunch of times at 3000rpm when MAP = baro (80kPa for me), and find the ideal most-closed nozzle area is 7cm^2. Now I want to calculate most-closed nozzle position at 5000rpm:

• Let's say VE at 3000rpm is 86%, and at 5000rpm 98%
  • I use that to calculate the most-closed area at 5000rpm: 7cm^2 * (5000rpm / 3000rpm) * (98% / 86%), gives 13.3cm^2
• As boost rises at 5000rpm, I now adjust my VGT nozzle size position proportional to boost:
  • Let's say I'm now at 130kPa MAP and baro is still 80kPa:
    • 13.3cm^2 * 130kPa / 80kPa gives 21.6cm^2.

VGT Algorithm analysis by Mikey Antonakakis, on Flickr

[mikey.antonakakis]

Weather is nice again. I think I figured out a better VGT algorithm and accompanying tuning process. Going to code it up and test hopefully tomorrow.

[mikey.antonakakis]

Yes, just for purely monitoring once the tune is dialed in.
Right now as ECU output I have a couple warning lights in my cluster and that's it.

Analog inputs would be fantastic. Could use your device as a gauge hub and get some pressure/temperature sensors to compliment my traditional VDO gauge senders.

Definitely going to have that feature (I use for oil pressure, fuel pressure, wastegate dome pressure). As long as total 3.3v power usage is less than 250mA, will support almost any analog and digital sensors (e.g. pressure, temperature, accelerometers, GPS, etc.). For reference, analog pressure sensors usually use 5mA or less, and there are up to 14 analog inputs available.

[Panici]

I don't think is what you meant, but just to be clear I don't have it set up to tune the Megasquirt parameters. I think it would actually be possible to do stuff like flash maps with this unit, but I haven't personally done it, and it doesn't sound fun to do on 2.8" screen lol. But in theory I think you can if you really want to. For purely monitoring though, it definitely beats the hell of out running 52mm gauges everywhere IMO. And having 8 extra analog inputs for MS2 is super handy.

Yes, just for purely monitoring once the tune is dialed in.
Right now as ECU output I have a couple warning lights in my cluster and that's it.

Analog inputs would be fantastic. Could use your device as a gauge hub and get some pressure/temperature sensors to compliment my traditional VDO gauge senders.

[mikey.antonakakis]

Thanks for the visit, it's coming together slowly but surely!

Amazing that you're making some of these displays. I commented on your other thread, I am definitely interested in one for my car.
Sure beats bringing a laptop around all the time, and A LOT cleaner then running a tablet.

I don't think is what you meant, but just to be clear I don't have it set up to tune the Megasquirt parameters. I think it would actually be possible to do stuff like flash maps with this unit, but I haven't personally done it, and it doesn't sound fun to do on 2.8" screen lol. But in theory I think you can if you really want to. For purely monitoring though, it definitely beats the hell of out running 52mm gauges everywhere IMO. And having 8 extra analog inputs for MS2 is super handy.

[Panici]

Thank you for the kind words! I was checking out your build thread last night, didn’t realize how tight the exhaust side can be on a M52! It’s looking great.

I’m actually working on making a few of the touchscreen OBCs available, will integrate great with MS3X (I just started a thread for that here. The idea is to have a separate enclosure for the brains and I/O of the OBC to make it easier to expand and give flexibility in placement. I will probably order a run of PCBs today, design is done I think:

Thanks for the visit, it's coming together slowly but surely!

Amazing that you're making some of these displays. I commented on your other thread, I am definitely interested in one for my car.
Sure beats bringing a laptop around all the time, and A LOT cleaner then running a tablet.

[mikey.antonakakis]

I just gave the thread a read. Excellent mix of fabrication and electronics! I've subbed for updates.

Metal work like your turbo inlet tube made to clear the rad hose is ace.

https://www.r3vlimited.com/board/filedata/fetch?id=9892293&d=1576458403

I also love that touch-screen OBC replacement. May have to explore a similar option for my E30 running MS3X (once everything else is done).

Thank you for the kind words! I was checking out your build thread last night, didn’t realize how tight the exhaust side can be on a M52! It’s looking great.

I’m actually working on making a few of the touchscreen OBCs available, will integrate great with MS3X (I just started a thread for that here. The idea is to have a separate enclosure for the brains and I/O of the OBC to make it easier to expand and give flexibility in placement. I will probably order a run of PCBs today, design is done I think:

Screenshot 2022-05-24 182951 by Mikey Antonakakis, on Flickr