advice setting Closed Loop Lambda

[Bud]

Hello,

i have Subaru plug in G4X with Link CAN Lambda

can you help me for setting correctly Lambda Closed loop.

For correct setting of "Gain Control Table" and "Update Rate TAble"

Thanks in advance for your help

Ludovic

 

[Vaughan]

Typically update rate is smaller (like 1Hz) at lower rpms and faster (like 10Hz) at higher rpms, Gain control typically has a smaller gain at smaller lambda errors and a larger gain at larger lambda errors (for my car I use 2,3,6,6,6,6 but have a play to see what suits your car)

[Bud]

16 minutes ago, Vaughan said:

Typically update rate is smaller (like 1Hz) at lower rpms and faster (like 10Hz) at higher rpms, Gain control typically has a smaller gain at smaller lambda errors and a larger gain at larger lambda errors (for my car I use 2,3,6,6,6,6 but have a play to see what suits your car)

 

Thanks for your answer,

i will test your setup

before  i test also this setting

[Vaughan]

gain table should get more aggressive with bigger errors, the setup you have will cause large oscillations at small errors and very little change at big errors, mine looks like this:

 

[dx4picco]

My experience shown that having a high coefficient in the last rows will lead to unwanted behaviour during shifts and pedal release. Because of wall wetting (or drying in that case) you get a rich condition that the CL is trying to compensate and once the fuel film is consumed you will be lean, too lean and engine will jerk. 

[Vaughan]

During shifting you should typically hit the TPS Delta lockout meaning no CLL over the shift, when in overrun it is disabled by the overrun fuel cut (if you are using it).

[Adamw]

You guys are pussies. Lol.  

Here's mine.

 

keep in mind the sensor location and exhaust volume will have a large impact on the amount of gain you can get away with and the update rate.  My sensor is right in the turbine exit so responds to changes in fueling quite quickly.

The current software may not allow numbers as big as mine, I am running a beta version which has some updates to CLL but it should be available soon.

 

25 minutes ago, dx4picco said:

My experience shown that having a high coefficient in the last rows will lead to unwanted behaviour during shifts and pedal release.

I just have my trim limit table set to zero trim in the high-vacuum region.

[Bud]

20 hours ago, Adamw said:

You guys are pussies. Lol.  

Here's mine.

 

keep in mind the sensor location and exhaust volume will have a large impact on the amount of gain you can get away with and the update rate.  My sensor is right in the turbine exit so responds to changes in fueling quite quickly.

The current software may not allow numbers as big as mine, I am running a beta version which has some updates to CLL but it should be available soon.

 

I just have my trim limit table set to zero trim in the high-vacuum region.

Thanks Adam

can you explain why you setup like this?

i really interest to understand

thanks in advance

ludovic

[Adamw]

The main purpose of the update rate table is to account for "transport delay", this is the time it takes for the lambda sensor to sense a change in the fuel mixture and reach a stable value.  To test this you can log injector PW or fuel table number and lambda, hold the engine at a constant RPM and apply a step change of say 10% to the whole fuel table, the transport delay is how long it takes after you have changed the fuel table until the measured lambda reaches the new value corresponding to the change in fuel input (~10%).  The more gas that is moving through the exhaust system, then the faster this delay will be.  So you can update at a faster at higher RPM because more gas is moving through the system so the delay to reach and saturate the sensor is shorter.  Your update rate can be close to the transport delay time.

If your update rate is too fast then you have to use much less gain to prevent oscillation.

The gain is basically how "big of a bite" the CLL system will take at correcting the lambda error.  To tune this I just log CLL trim, Lambda error, lambda target & lambda 1 and watch response while making step changes to the whole fuel table (just multiply the whole table by say 10% or -10% as well as smaller and larger changes).  Then play around with gain to achieve the fastest correction possible without significant overshoot/undershoot or oscillation.  Especially the 3 cells at the left hand end of the gain table are the ones that make the biggest difference.  You can do a pretty good job of this just free revving, holding at constant RPM, you dont really need to be on a dyno or anything.

 

[bradsm87]

Wouldn't it be best to put a load axis on the update rate table as well and increase update rate with higher load for same RPM as well?

[Adamw]

Correct, the update rate should be more closely related to mass flow rather than RPM, in the next firmware update you have the ability to enable user configurable 3D table for update rate and gain.  

However, my policy with tuning is usually to only add complication where necessary, in my car even though I have the ability for a 3D table and I have tried it, I find just the 2D table referencing RPM is all I need.  I suspect just a 2D table with something like "Air per Cyl estimated" on the axis would be a good easy option but I havent personally tried any alternatives like that yet.

Edited the first line of this post as the 3D table comment should have only applied to the update rate, I was mistaken about the gain table.

[bradsm87]

I like the idea of air per cyl estimated as the axis. I think I'll try that first.

[Vaughan]

13 hours ago, Adamw said:

in the next firmware update you have the ability to enable user configurable 3D tables for update rate and gain

When Trim Limit tables is set to 3d tables the update rate is changed to a 3d table

[d1zguy]

On 6/7/2020 at 6:30 PM, Adamw said:

You guys are pussies. Lol.  

Here's mine.

 

keep in mind the sensor location and exhaust volume will have a large impact on the amount of gain you can get away with and the update rate.  My sensor is right in the turbine exit so responds to changes in fueling quite quickly.

The current software may not allow numbers as big as mine, I am running a beta version which has some updates to CLL but it should be available soon.

 

I just have my trim limit table set to zero trim in the high-vacuum region.

Does this work on traditional fuel mode or only modelled?

[Adamw]

Fuel equation wont make any difference.

[thorns]

Have been watching HPA vids in regards to this (granted it was the G4+ older course). 

I have the Link CAN Lambda installed and operating, is this the best method for getting the car running okay at low loads and speeds, enough to let me 'limp' the car to the dyno tuner?

[Adamw]

No I wouldnt use CLL for that, probably best to just bump the master fuel up or down so that the lambda is somewhere in the normal ballpark.  

[d1zguy]

On 10/11/2021 at 2:20 AM, Adamw said:

Fuel equation wont make any difference.

Okay great, I got it running with your values, I see some correction i uploaded my base map on my main thread

[ChrisUR]

having read this interesting topic I wonder what should be the reactivation delay (samples) as found in the G4X software in regards to your update rate and gain control tables ?

[Adamw]

From memory the gain and update rate table examples given by me above are from my Evo road car (pretty much dead stock evo 7) the lambda probe is very close to the turbine outlet probably at the most 500mm from the exhaust port, in this car I have the reactivation delay set to 3 samples.  In our WRX11 test car which also has the probe right after the turbine - but has much longer manifold primaries etc (probably more like 1500mm from port to probe) I have reactivation delay set to 5 samples.  The update rate table is similar in both cars, the subaru could actually do with less than 1Hz at idle as it takes about 3 secs to respond to a change of PW but 1Hz is currently the lowest it can do. 

So what this means is in my evo with the reactivation delay set to 3 samples, if CLL was temporarily disabled due to over-run fuel cut or similar around idle where my update rate is 1Hz (1 sample per second), then CLL would be re-enabled 3 secs later.  To give an example at the other end of the table, if I hit the RPM limit at 7000RPM where my update rate was 10Hz, then CLL would be disabled for only 0.3s.