Feature request: PID gain tables & air temp comp

[arghx7]

Short version:

Can we add rpm vs gain tables for closed loop fuel and boost rather than rely on global values? (same as AEM Infinity)
Can we add air temperature and baro compensation to the boost control initial duty table and open loop table? (same as a ~15 year old 16bit WRX ECU)
Can we add a load component to the air density correction table for fueling? (same as a Haltech Platinum SPort)?

Detailed version:

Hello,

I am currently working with a turbo 1.6 Miata with sequential fuel (yes, it's a 1.6 with sequential rather than a 1.. I'm overall happy with the Megasquirt 3 pro and the car is running well. I'd like to request a few feature updates that would make add some flexibility to closed loop tuning and to air temperature compensation.

The main thing I am asking for is expanding the flexibility of PID control so that we are not using a single set of PID gains for an entire control system. For example, I have to use a single set of PID terms for closed loop fuel. That has to cover idle, cruising, WOT, and transition into boost. One set of gains gets the job done but it necessitates compromises. There's always a tradeoff between response and stability. Idle is mostly steady-state, except when accessory load comes on. Cruising is almost always steady-state, except for sudden tip-in. WOT and transition to boost are almost always transient, unless you are on a loading dyno. On an AEM Infinity, however, the closed loop gains are 2D tables based on engine speed. That adds a lot of flexibility.


That's the lambda I-gain vs rpm table on an AEM infinity



Those are gain vs rpm tables for closed loop boost control on an AEM Infinity



Bottom table shows that the proportional gain on an 02-05 WRX is scaled based on error, rather than relying on global control. That's a probably a more complicated and unnecessary implementation compared to an rpm-based table. My point is that a 15 year old ECU isn't relying on global controller gains either.

[arghx7]

The second thing I am asking about is air temp compensation for the open loop boost control and for the initial duty table for closed loop. You can see in the 3rd screenshot in the previous post that the 02-05 WRX ECU has 2D tables for this, along with baro compensation.

This makes it a lot easier to keep boost under control when you have a drastic change in weather. You're not stuck with an initial duty table and gains that were tuned in summer, and then not be able to make compensations in winter time. Again you can bake a lot of this in if you use a lazier duty and gain response settings in summer time, but it's not ideal. Baro compensation would be good as well, as different turbo setups have different amount of margin on the compressor map at higher altitudes.

The final thing is load compensation for air density correction. Haltech and other systems have this. What happens is, during a hot soak (stopping at 7 Eleven in July), the air temp sensor heat soaks. So now on hot start you can run lean at idle. You could bake in compensation for hot soak into the table, but now when you go boost the engine you are too rich. That's where the load based compensation comes into play.



Now you can rely on closed loop feedback to help you, but as I pointed out above, you've got a single set of PID gains to cover ALL aspects of engine operation. That doesn't mean you can't make it work, but you are stuck making compromises.

So in conclusion, the existing tables work, but they require a number of compromises due to "one size fits all" temperature compensation and PID gains. The MS3 would benefit from additional flexibility in 3D air temp compensation and 2D closed loop gain tables rather than scalars.

[muythaibxr]

Short version:

Can we add rpm vs gain tables for closed loop fuel and boost rather than rely on global values? (same as AEM Infinity)
Can we add air temperature and baro compensation to the boost control initial duty table and open loop table? (same as a ~15 year old 16bit WRX ECU)
Can we add a load component to the air density correction table for fueling? (same as a Haltech Platinum SPort)?

Detailed version:

Hello,

I am currently working with a turbo 1.6 Miata with sequential fuel (yes, it's a 1.6 with sequential rather than a 1.. I'm overall happy with the Megasquirt 3 pro and the car is running well. I'd like to request a few feature updates that would make add some flexibility to closed loop tuning and to air temperature compensation.

The main thing I am asking for is expanding the flexibility of PID control so that we are not using a single set of PID gains for an entire control system. For example, I have to use a single set of PID terms for closed loop fuel. That has to cover idle, cruising, WOT, and transition into boost.

Why run closed loop fuel on idle? Also, widebands are known to be pretty inaccurate at WOT and in boost. Most controllers don't compensate for this. I wouldn't want to remain in closed loop in these situations. Factories don't for a reason.

One set of gains gets the job done but it necessitates compromises. There's always a tradeoff between response and stability. Idle is mostly steady-state, except when accessory load comes on. Cruising is almost always steady-state, except for sudden tip-in. WOT and transition to boost are almost always transient, unless you are on a loading dyno. On an AEM Infinity, however, the closed loop gains are 2D tables based on engine speed. That adds a lot of flexibility.

Have you looked into editing the delay table? This should give the same behavior (slows down correction or speeds it up based on RPM vs Load).

Those are gain vs rpm tables for closed loop boost control on an AEM Infinity

People have enough trouble tuning a single set of PID gains. In any case, with a properly tuned bias table (1.4 betas) you barely even need PID anyway. Just enough to account for air density differences (temp, baro)

Bottom table shows that the proportional gain on an 02-05 WRX is scaled based on error, rather than relying on global control. That's a probably a more complicated and unnecessary implementation compared to an rpm-based table. My point is that a 15 year old ECU isn't relying on global controller gains either.

So they couldn't figure out a way to make it work without even more extra tables. PID is already difficult enough for most people without changing the gains every time conditions change.

Ken

[muythaibxr]

This makes it a lot easier to keep boost under control when you have a drastic change in weather. You're not stuck with an initial duty table and gains that were tuned in summer, and then not be able to make compensations in winter time. Again you can bake a lot of this in if you use a lazier duty and gain response settings in summer time, but it's not ideal. Baro compensation would be good as well, as different turbo setups have different amount of margin on the compressor map at higher altitudes.

This I can probably agree to, and we can reasonably default it to do nothing. I'll think about it for 1.5.

The final thing is load compensation for air density correction. Haltech and other systems have this. What happens is, during a hot soak (stopping at 7 Eleven in July), the air temp sensor heat soaks. So now on hot start you can run lean at idle. You could bake in compensation for hot soak into the table, but now when you go boost the engine you are too rich. That's where the load based compensation comes into play.

This or something like it has been on my list for a long time. I've seen what other ECUs do and have never been terribly happy with how they try to solve the issues.

Ken

[Reverant]

Why run closed loop fuel on idle? Also, widebands are known to be pretty inaccurate at WOT and in boost. Most controllers don't compensate for this. I wouldn't want to remain in closed loop in these situations. Factories don't for a reason.

I can't think of many factory cars that don't run closed loop fueling at idle. If there's one region where it's needed, it's at idle.

[muythaibxr]

Why run closed loop fuel on idle? Also, widebands are known to be pretty inaccurate at WOT and in boost. Most controllers don't compensate for this. I wouldn't want to remain in closed loop in these situations. Factories don't for a reason.

I can't think of many factory cars that don't run closed loop fueling at idle. If there's one region where it's needed, it's at idle.

Hrrm, then the cars I am thinking about are old. In any case, it is not needed at WOT or in boost, and the delay table should be able to compensate load and RPM changes.