rusefi.com

Another subject near and dear to my performance needs is boost control. In the 70s and 80s, and for some even in the 90s still, boost on turbo-charged cars was pretty much controlled by a mechanical wastegate. A wastegate is a flapper (valve) that sits between the exhaust manifold and the downpipe, essentially offering the exhaust gases a path to bypass the turbine wheel of the turbo. The flapper was (and still is today) actuated by a diaphragm that reacts on boost. In the simplest configuration it is held closed by a spring (closed means all exhaust goes through the turbine) and the diaphragm opens the WG progressively as pressure after the compressor increases, bleeding exhaust from the turbine.

This works OK, but has two major issues:
- The boost curve is essentially set by a mechanical spring. No complexity is possible
- Due to the linear nature of the setup, the WG already starts opening before target boost is reached, essentially delaying the rpm at which the turbo is fully spooled

The obvious solution for both issues is having the ECU control the WG. The most common implementation of this idea is putting a valve in the pressure line feeding the WG actuator. This valve can be proportionally closed/opened with a pwm signal. If the valve is closed all the way, no boost will ever reach the WG actuator, essentially keeping the WG firmly shut and routing all exhaust gas through the turbine. This creates maximum boost, in some circles referred to "allofit"(tm). Obviously not many setups can handle this. If the valve is all the way open, it serves no function and the WG runs off the spring again.

The target of boost control is usually two-fold: Set a boost target curve, which is usually based on rpm and throttle position (3D table) and implement a control strategy to get there.

I know of two main implementations for this (and I apologize to @ for using the terms open- and closed loop below- I know he doesn't like them):

1. Open loop control
Create a table with PWM values, based on throttle position (y-axis) and rpm (x-axis). These values are fed into the boost control solenoid valve

2. Closed loop control
Create a 3D table, again based on rpm and TPS, showing target boost. Then create a PID controller for the solenoid valve, using MAP as feedback
The most successful implementation of this for me so far has been using a classic PID controller with a twist: a table of offset values to "seed" the PID loop. This is again a 3D table, in this case with rpm on the x-axis and target boost on the y-axis that displays the start-value that the PID gets seeded with.

One main feature that is also very, very, very important for boost control is boost cut. Boost cut means cutting spark and/or fuel if the boost exceeds a pre-determined value in case something goes wrong. This hopefully protects the engine from major explosions. Boost cut can again be based on rpm (a simple table is enough)

Boost target curves can also be dependent on gears, if you want to go really fancy with it.

There are many other things that this type of control would apply to with only minor tweaks. One that comes to mind is valve angle control (Mazda calls it VVT for example) this is very similar: You have a target table, based on engine conditions, a feedback value (CAM angle) and something that is usually pwm controlled that changes the CAM angle.

So if the code for the FW is kept somewhat open- not pre-determining the parameters, but having those set by the tuning software (i.E. Tunerstudio), should make for some easy configuration by the tuner without having to re-invent the wheel in FW again and again.

One last thing: Different PWM-able valves and actuators respond well at different frequencies. For example my boost control valve reacts 'softly' using a PWM frequency of 19.5Hz and much more aggressively using 39Hz. So this is obviously an important parameter to be able to choose. Not sure how rusefi is handling PWM, but some outputs may share timebases.

To illuminate the target boost issue, here is my current target curve: please note that the value we're reading should not really be percent[%], but MAP [kpa].

I really need to start dubbing with my red suby, AKA CPU controlled turbo and potential test mule. I seem to recall the blow off is also CPU controlled. It's been a while sense I got to poke my head under the hood of that beast.

I kind of wonder if it's wroth while to have a generic table mechanism, similar to the flexIO thing, where you can set a table, then set how it's connected to things via flexIO. I see these kinds of tables being used for many things.

In terms of turbo, I suspect there is more to it, AKA turbo lag, dumping extra fuel, retarded timing to get more back pressure. My daily has a bypass valve, which is used to keep the turbo's inertia as you drive through a corner. When it closes as you come out of the corner, the turbo's inertia allows you to get back on boost very quickly. I guess it also functions as a blow off for throttle snaps. I believe the OEM ECU is also adjusting the waste gate, to keep the turbo's RPM's up, while it's controlling the bypass valve. This allows you to have lots of inertia energy stored and ready to build boost when you tromp on the long pedal.

Might also be of interest. this is a Software Defined Radio SDR approach, but perhaps similar concepts could be applied here. It's software blocked, pre-compiled and connected with a python program.



Any how, lots of complicated things that could happen. The question is what is a manageable bite to take? Also is there hardware required for it? I'm best at helping with software. Do we need to find pneumatic valves, or developer drivers for those valves?

I'd say first attempt should try to get close to what the standard aftermarket units offer. I only know Megasquirt and the -now defunct I believe- Link.

So the status I described is close to the current status of the Megasquirt.
All those flappers, valves etc. could be controlled via programmable outputs. Current level of MS development has free outputs depending on simple logic combination of inputs: Example: RPM>4000rpm & MAP <60 & CLT>50

Having freely configurable 3D and 2D tables for generic IO would be the way to go I think.

Thank you for the detailed overview on this subject! It is definitely helpful - I am mostly software, very little car guy.

I will implement table-based PWM control for any auxiliary device under https://sourceforge.net/p/rusefi/tickets/127/ - as you see that's an old ticket, this was always the plan and now seems like there is finally a use-case for that. Also spark cutoff if MAP above specified threshold, do I understand it right? https://sourceforge.net/p/rusefi/tickets/272/

stefanst wrote: The most successful implementation of this for me so far has been using a classic PID controller with a twist: a table of offset values to "seed" the PID loop. This is again a 3D table, in this case with rpm on the x-axis and target boost on the y-axis that displays the start-value that the PID gets seeded with.

Is that what we call "offset" in our PID implementation? You can see it in the alternator PID videos for example.

stefanst wrote:One last thing: Different PWM-able valves and actuators respond well at different frequencies. For example my boost control valve reacts 'softly' using a PWM frequency of 19.5Hz and much more aggressively using 39Hz. So this is obviously an important parameter to be able to choose.

PWM frequency for FSIO is already configurable! So the way it is right now is you have static frequency (maybe dynamic frequency one day) and you can control the duty cycle with your formula. For instance VICS logic is implemented like that. Now I simply need to add 3D table support into these formulas.

russian wrote:Also spark cutoff if MAP above specified threshold, do I understand it right? https://sourceforge.net/p/rusefi/tickets/272/

Yes, but I would also cut fuel- no point in dumping fuel into an engine without spark- might even prove dangerous at some point. Or leave it to the user- offer both.

russian wrote:Is that what we call "offset" in our PID implementation? You can see it in the alternator PID videos for example.

Yes, but not just a single value, but again a 2D or 3D table.
In your alternator example, I would probably have a 3D offset table with rpm on the x-axis and target voltage on the y-axis. Every time the PID loop runs, read the offset table and just add the value to the calculated PID value. In a perfect world, with a perfect offset table taking all possible variables into consideration we would not even need the PID part then. This table just takes care of the known influences and makes it easier for the controller.

Of course if you have an alternator that reports current, I would probably go with a 3D table with rpm on the x-axis and current on the y-axis. Or maybe two offset values added. Or a 4D table? You can go infinitely complex I guess....

The way you tune the offset table is actually fairly simple: Once the PID controller works reasonably well without too much oscillation, run it without using any offset or maybe just a static offset. Then look through the logs and just record the PID output depending on operating conditions. These values then go as seeds into the offset table. Re-tune PID and repeat. A fun way to spend days of your live driving your car, pretending to do something productive.
As always in tuning there will be a healthy amount of guessing going on....

Another area where the generic 3D PWM control may be useful is for idle control. Here a 8x8 matrix would definitely be sufficient. Target RPM on the x-axis, CLT on the y-axis. PWM% as value. Either in open loop, or closed loop with seed (...offset value, start value, whatever you call it...). Target value should be 2D (CLT).
This is an area where I would like to see a 3D control, with 2D target, but then I would add a 2D or 1D modifier to that. For example in idle I would like to have the option to increase the target and/or the PWM value depending on other conditions like for example AC, electric load, power steering. Basically if we have any additional parasitic load, we need to add a little to our idle.
Come to think of it, we probably need to add some conditions about entering into CL idle. Open loop can be running all the time- I don't see any problems there, but for CL, we need to at least have TPS below a certain value and the RPMs dropped to within reach, so we don't have CL starting too early and over-reacting. Also only enter CL idle if clutch is depressed or neutral engaged.

All the sudden this doesn't sound so generic to me anymore. Ideas?