[FW MOD] ms2extra 3.2.1 gslender v2.2b

[Greg G]

For the CL idle crowd, there should be an additional condition on AIA entry. AIA should only kick in once the car is in CL idle close to the target, not come on early while we're still ramping down from i-v-t.
Then, AIA must stay on until we're not idling anymore. AIA is for fine adjustments once we're near target.

I partly disagree with this- I find that AIA does a good job of 'conditioning' the RPMdot just before closed loop entry conditions are met. The idle valve can only catch up to a certain negative RPMdot (in my case, I should be ~ -700 @ 1200 RPM. Any more negative, and I get droop. The AIA does a good job of fine tuning the rate of deceleration when near target.

Here's a graph to illustrate- notice the AIA working before closed loop entry. Note that AIA has stabilized the RPMdot such that when PID is engaged, it doesn't freak out.

[juansh2385]

hey guy sorry to be ignorant but i have not test this one yet (really happy with the last of the v2 mod in the other post) what are the main difference from the other?

[pmbrunelle]

For the CL idle crowd, there should be an additional condition on AIA entry. AIA should only kick in once the car is in CL idle close to the target, not come on early while we're still ramping down from i-v-t.
Then, AIA must stay on until we're not idling anymore. AIA is for fine adjustments once we're near target.

I partly disagree with this- I find that AIA does a good job of 'conditioning' the RPMdot just before closed loop entry conditions are met. The idle valve can only catch up to a certain negative RPMdot (in my case, I should be ~ -700 @ 1200 RPM. Any more negative, and I get droop. The AIA does a good job of fine tuning the rate of deceleration when near target.

Here's a graph to illustrate- notice the AIA working before closed loop entry. Note that AIA has stabilized the RPMdot such that when PID is engaged, it doesn't freak out.

AIA is still reactive. It can't do anything until the rpm delta is negative - you still have a droop. Droop/stalling needs to be addressed with the fixed dashpot adder for now, and the rpmdot sensitive dynamic dashpot later. PID delay just needs to be long enough so that the oscillations have decayed before CL idle turns on.

From a throttle lift, if we have say 10 degrees of spark retard from the nominal idle timing, that will make the IAC return to its normal position (with normal spark timing) take longer, as the RPM error will be low. CL idle will only be able to reduce the number of steps as AIA slowly returns to zero correction. In the meantime, we're stuck with an inefficient idle - lots of idle air, but little advance. We even see that in your datalog to an extent - lots of idle duty change with little corresponding change in RPM.

The following feature can also be deleted:

Code: Select all

if (outpc.rpm <= rpm_thresh) {
        idle_wait_timer = 0;
        pwmidle_reset = PWMIDLE_RESET_CALCNEWTARG;
        valve_closed = 0;
        return;
}


Getting rid of the feature would mean always using the lockout settings to get into CL idle, and you wouldn't care about trying to make sure that the dashpot adder or i-v-t table value would land the RPM below the target + adder. Then, more conservative (higher) dashpot/i-v-t values can be used, further addressing the droop/stalling issues.

If the lockout settings are correct, CL idle will turn on quickly enough. RPM and TPS should not be sufficient conditions for entry into CL idle. The thing about this setting (unlike the rpmdot related idle features) is that I can't tune it out with appropriate settings.

Now I figured this would be easier to just ask. What happens if we're in CL idle, then we put the car in gear, does that kick up the idle to i-v-t, or do we only go to i-v-t on a throttle lift?

[gslender]

hey guy sorry to be ignorant but i have not test this one yet (really happy with the last of the v2 mod in the other post) what are the main difference from the other?

You could read the 1st post, but to avoid being a forum bitch, i'll explain here too....

1) it is based on the "released" 3.2.1 code.

2) it contains median sliding window filters for rpm, map, TPS and lambda (ego).

G

[muythaibxr]

The following feature can also be deleted:

Code: Select all

if (outpc.rpm <= rpm_thresh) {
        idle_wait_timer = 0;
        pwmidle_reset = PWMIDLE_RESET_CALCNEWTARG;
        valve_closed = 0;
        return;
}


Getting rid of the feature would mean always using the lockout settings to get into CL idle, and you wouldn't care about trying to make sure that the dashpot adder or i-v-t table value would land the RPM below the target + adder. Then, more conservative (higher) dashpot/i-v-t values can be used, further addressing the droop/stalling issues.

I've thought about getting rid of that feature, but opted to keep it since it often makes initial tuning of things easier for newbies.

Now I figured this would be easier to just ask. What happens if we're in CL idle, then we put the car in gear, does that kick up the idle to i-v-t, or do we only go to i-v-t on a throttle lift?

That's what the PID disable RPMdot is for. It disables PID if RPMdot spikes over a certain value. It was added specifically for the situation you describe.

Ken

[Greg G]

From a throttle lift, if we have say 10 degrees of spark retard from the nominal idle timing, that will make the IAC return to its normal position (with normal spark timing) take longer, as the RPM error will be low. CL idle will only be able to reduce the number of steps as AIA slowly returns to zero correction. In the meantime, we're stuck with an inefficient idle - lots of idle air, but little advance. We even see that in your datalog to an extent - lots of idle duty change with little corresponding change in RPM.

From throttle lift- it will go to the duty commanded in IVT, and start moving only when CL idle entry conditions are met. So the AIA gets the RPM close to target, avoiding a large step from the idle valve on CL entry. Yes, AIA is still reactive (though much faster than the idle valve). I do agree that a revised dashpot action would help immensely.

Regarding my graph above- which parts show the inefficient idle? The idle valve spikes come from the battery voltage correction, and the plateaus come from the dashpot/IVT/AC adder. This was taken with the car in neutral, free revving. So yeah, my goal was to make RPM not change much. But if there's room for improvement, I'm all for it!

[gslender]

pmbrunelle, why not post some graphs and examples after using the 2.2b mod to show where you think it needs further improvement ??

[pmbrunelle]

That's what the PID disable RPMdot is for. It disables PID if RPMdot spikes over a certain value. It was added specifically for the situation you describe.

Ken

I was asking about the gslender neutral switch interlock. Scenario:

Car stopped, Idling in neutral, CL idle active
Disengage the clutch
Put the car in gear (activating the neutral interlock), without touching the throttle, clutch still disengaged

Will the simple act of putting the car in gear (but engine still spinning freely) kick up the idle speed to i-v-t? I also use an IAC close delay of zero (don't use that feature) if that changes anything.

From a throttle lift, if we have say 10 degrees of spark retard from the nominal idle timing, that will make the IAC return to its normal position (with normal spark timing) take longer, as the RPM error will be low. CL idle will only be able to reduce the number of steps as AIA slowly returns to zero correction. In the meantime, we're stuck with an inefficient idle - lots of idle air, but little advance. We even see that in your datalog to an extent - lots of idle duty change with little corresponding change in RPM.

From throttle lift- it will go to the duty commanded in IVT, and start moving only when CL idle entry conditions are met. So the AIA gets the RPM close to target, avoiding a large step from the idle valve on CL entry. Yes, AIA is still reactive (though much faster than the idle valve). I do agree that a revised dashpot action would help immensely.

Regarding my graph above- which parts show the inefficient idle? The idle valve spikes come from the battery voltage correction, and the plateaus come from the dashpot/IVT/AC adder. This was taken with the car in neutral, free revving. So yeah, my goal was to make RPM not change much. But if there's room for improvement, I'm all for it!

I wasn't talking about the spikes, but idle immediately after a throttle lift. We can tell it's fuel inefficient - lots of idle air (compared to once we're idling in closed-loop at the target, in equilibrium) is required to maintain that idle, because of the spark retard from the AIA. MAP is also high during that period. MAP normally increases as we reduce idle speed - here as we "ramp down" the idle, MAP is decreasing. The MAP being high at the "high" idle after lifting is an indicator of excess spark retard. Manifold pressure is a good indicator of efficiency at idle. That's why we generally tune idle timing to maximize vacuum.

pmbrunelle, why not post some graphs and examples after using the 2.2b mod to show where you think it needs further improvement ??

I haven't used any of your firmwares besides 3.2.1 release. And my car is sleeping for the winter until the snow is gone. Anyway, these are ideas of mine that I'm implementing on my car no matter what in the spring - I figured I'd share my ideas with the community, and if they were to be integrated the releases, it would be less patching for me to do come springtime. So there won't be any datalogs with your straight 2.2 firmware.

However, I do have old datalogs demonstrating the effects of idle spark timing on fuel efficiency, which I will post shortly.

[pmbrunelle]

Here is an example of the effect that spark timing has on idle fuel efficiency.

The datalogs were taken in the same sitting. I attempted to keep most variables the same between both tests. I used CL EGO control to keep AFR almost the same. CL idle adjusted the IAC to maintain an idle RPM target of 800 RPM in both cases. My engine idles nicely around with around 28 deg of idle advance. Around 30, further advance does little to decrease manifold pressure, so I left it at 28, close enough (on the retarded side) to MBT.

28 degree idle.msl is my normal baseline.

22 degree idle.msl shows the effect of 6 (nominally) degrees of retard. You'll see the spark fluctuate in that one, because it was my own adaptive spark experiment (done by fiddling with the main spark table), but the point is to show the effect of retarded spark.

We see the MAP is higher, the IAC is opened more, and of course, fuel pulse width is higher. Under the test conditions, I estimate an injector dead time of ~0.9 ms, so you can see the effect of spark retard on idle fuel efficiency. Compare the before and after PW.

It looks like Greg's car is pretty obviously stuck in the excessively retarded/high idle airflow scenario after throttle lift, because idle control and AIA are counteracting each other. Because the spark is retarded (and thus less RPM error), the idle duty isn't being pulled down hard, which keeps the spark excessively retarded... It's pretty clear that spark and idle duty are mirroring each other.

[pit_celica]

I just want to to share some calculations here so you can see that the difference in fuel consumption between a near MBT idle and a retarded idle is :

Assuming a RPM of 800, 4 injectors that are flowing 540cc/min with a dead time of 0.9 ms.

From your logs, injector PW are around 2.52 ms for the 22 deg idle and 2.4 for the 28 deg idle.

Doing the flow calculation, this gives us 1399 cc/hr for the 22 deg idle and 1296 cc/hr for the 28 deg idle. That's 100 mL for 1 hour of idling time...

My point here is that trying to get the idle near MBT only for a better fuel efficiency isn't worth it at the expense of a more rock solid idle that can be obtained by having a torque reserve from a more retarded timing in case of sudden perturbation.

Sam

[Red_Baron]

stock ECU idles my car at 6/7 degrees so it has that 'torque reserve' too. Minimum PW is around 23-25 degrees so miles away.

Love the maths though! 100ml an hour saved

IMHO I'll take the rock steady idle too

RB

[Black99rt]

Ditto, my stock ECU uses 5 degrees for base idle and is very reactive with advance to maintain smooth idle. The IAC counts barely every move, the strobe jumps all around.

[pmbrunelle]

I just want to to share some calculations here so you can see that the difference in fuel consumption between a near MBT idle and a retarded idle is :

Assuming a RPM of 800, 4 injectors that are flowing 540cc/min with a dead time of 0.9 ms.

From your logs, injector PW are around 2.52 ms for the 22 deg idle and 2.4 for the 28 deg idle.

Doing the flow calculation, this gives us 1399 cc/hr for the 22 deg idle and 1296 cc/hr for the 28 deg idle. That's 100 mL for 1 hour of idling time...

My point here is that trying to get the idle near MBT only for a better fuel efficiency isn't worth it at the expense of a more rock solid idle that can be obtained by having a torque reserve from a more retarded timing in case of sudden perturbation.

Sam

You did the math yourself - (I actually have 6 x 300 cc/min injectors, but the before/after ratio is still fully valid) 8% penalty in fuel flow rate for 6 degrees of retard. A substantial amount if you ask me.

While I don't pretend to be green, and I fully intend on wasting fuel for the non-functional cool factor of having a non-moving tachometer needle, there's no need to go with excess retard either (I found 6 degrees of reserve was enough). Why retard further than necessary?

My suggestion here is to only turn on (and then keep on) the AIA once our closed-loop idle control valve has brought down the RPM very close to target, because the act of turning on AIA while we're still at the i-v-t idle valve position keeps the spark advance further from MBT than is necessary until the idle air SLOWLY drops and we're at the back to the normal amount of torque reserve.

[gslender]

Why retard further than necessary?

My suggestion here is to only turn on (and then keep on) the AIA once our closed-loop idle control valve has brought down the RPM very close to target, because the act of turning on AIA while we're still at the i-v-t idle valve position keeps the spark advance further from MBT than is necessary until the idle air SLOWLY drops and we're at the back to the normal amount of torque reserve.

I think you are wrong here.

The current code has AIA follow the adjusted target idle rpm - which is ramped down from current rpm the moment we enter CL (from the moment we step off from IVT).

So the AIA is not fighting the IAC valve at all. It is matching the current target rpm and advancing/retarding based on that moving target until it reaches the desired clt-target rpm (and the ramp has finished). This keeps the IAC valve stable and duty errors to a minimum.

The current method of AIA is exactly how the OEM do it AFAIK - I figure their research and methods are probably worth looking at before we just assume "meh, what would they know"

[Red_Baron]

If people are finding that their car is 'glugging' on heavy retardation, then they need to address their PID Idle parameters.

Remeber in simple terms - AIA will only have HEAVY RETARD if the idle is FAR FROM TARGET. If it's FAR FROM TARGET then idle valve PID should be CLOSING THE VALVE.

If it's bang on target then AIA will be advancing/retarding NOTHING

RB

[pmbrunelle]

Why retard further than necessary?

My suggestion here is to only turn on (and then keep on) the AIA once our closed-loop idle control valve has brought down the RPM very close to target, because the act of turning on AIA while we're still at the i-v-t idle valve position keeps the spark advance further from MBT than is necessary until the idle air SLOWLY drops and we're at the back to the normal amount of torque reserve.

I think you are wrong here.

The current code has AIA follow the adjusted target idle rpm - which is ramped down from current rpm the moment we enter CL (from the moment we step off from IVT).

So the AIA is not fighting the IAC valve at all. It is matching the current target rpm and advancing/retarding based on that moving target until it reaches the desired clt-target rpm (and the ramp has finished). This keeps the IAC valve stable and duty errors to a minimum.

The current method of AIA is exactly how the OEM do it AFAIK - I figure their research and methods are probably worth looking at before we just assume "meh, what would they know"

Look at period of idling indicated by the leftmost yellow arrow in Greg's log. Each "tick" mark on the time axis represents about 6 seconds. After about 10 seconds of idling, spark advance/idle duty still hasn't reached equilibrium. Spark advance still slowly increasing and idle valve duty still decreasing, MAP decreasing. That's not "noise", that's a clear trend. After about 10 seconds, the AC is turned on, so that's all the data we have. A high idle duty compensating for a low spark advance, when they could both be at more moderate values.

Whatever it is the the OEMs do, I'm fairly certain that idle air and idle spark would be at their equilibrium values more quickly than 10 seconds considering the need to balance fuel consumption, perceived smoothness and emissions.

And not to paint all OEMs with the same brush (each will do things differently), but in hacked GM ECMs, idle spark control is enabled as VSS approaches zero. While the vehicle is rolling in open-loop idle, there's no spark correction.

The other issue is that I don't want idle spark to be changing by itself while the engine is connected to the wheels simply because TPS == 0. Tying it to CL idle stops any intervention when the engine isn't really idling (in an ideal world if the lockout settings are working for you; I use VSS).

[muythaibxr]

TPS isn't the only thing that enables/disables the closed loop timing compensation feature in the MS3 or MS2 firmware. There are several parameters that determine when "idle" is reached for the purposes of each feature.

In MS3 I'm considering creating a state machine of engine states with the following states:

Accelerating
Decelerating
Overrun
Idle,
etc...

These states and their interaction together will be used to turn off/on Idle advance, Closed loop idle, Closed loop idle timing assistance, and any other feature I can think of that needs to be based on one of those states (long term), and in the near term, I'm going to add the option to just turn on this idle feature when PID is enabled. Even with this, PID is enabled before you reach your desired target since the target is actually just set to whatever your current RPM is and scaled down over the course of the ramp to target time.

In the meantime, the oscillations that you're talking about in Greg's graph should not be looked at as just the interaction of the timing feature with the Idle valve. He also has the voltage correction and the AC idleup feedforward feature enabled which can all fight with one another if not tuned exactly right. There's no reason why the new idle advance feature and the existing closed loop code couldn't be tuned to work just fine together.

Ken

[ol boy]

In MS3 I'm considering creating a state machine of engine states with the following states:

Accelerating
Decelerating
Overrun
Idle,
etc...
Ken

This would be nice just for data logs so you can see what state your in while driving or idling.

[Red_Baron]

If you want the idle to drop faster, then surely just setup your PID settings differently with heavier I and P terms?

I find with the AIA working I can use MASSIVELY larger numbers because the Idle valve code never gets massive Delta's to work with because AIA prevents this, so you don't need to tune-out oscillation as much using PID values and can actually have fast-acting PID values.

Just an opinion from a novice tuner!

[muythaibxr]

With all the feedforwards, I have found that I don't need any P term at all, and the I trrm is set just high enough to get to target. So really the opposite of you. The only thing we don't feed forward now is power steering activity, which I think would make you want P to remain on. I don't have power steering though (I removed it) so no P term.

Ken