Idle RPM timing wrong after startup

[elaw]

I'm running a self-customized version of the 1.4.0 firmware, and yes I've made changes to the idle code but only batt v correction - nothing else! But I'm having a strange problem and am curious to know if it's maybe a known issue with the 1.4.0 code?

If you look at the attached log, you'll see that maximum-retard idle correction advance is being applied right after startup, even though RPM is well below target. That results in timing that's actually ATDC which is not exactly beneficial at that phase of engine operation!

If you look a little later in the log (starting around the 14.9 second point), you'll also see CL idle trying to kick in, which causes a dramatic change in timing, which causes an RPM spike (= large RPMdot), which causes CL idle to kick out and you get a repeating cycle.

Does anyone have any insight on these issues, especially the first one?

.msq file and an .ini that can be used to open it attached, as well as the log.

[elaw]

Nobody?

[CRSTune]

The reason it's pulling 18 degrees while cranking is because it's below target idle. For some reason, the idle target is 0rpm while cranking. Since the cranking RPM is higher than the target, the ECU is pulling timing. I don't know why.

Try changing the CL timing correction to "PID Idle Activates: Use PID idle activation." That will keep it from separately using timing correction when not in CL idle.

The next odd thing is those idle timing correction spikes you were talking about. Yes, the RPMdot does spike and exceed the programed values to kick you out of CL. The thing is what's causing that is a change in the idle RPM target. For some reason, the idle target is stepping up incrementally. Each step changes the RPM error, causing the timing to spike as it's no longer far below the target. After 4 steps, the idle target falls to a normal value in the log.

[elaw]

Hey... thanks so much for looking at this and good catch! Clearly (IMHO) something is awry if the idle target is 0 right after starting.

Your solution of activating idle timing correction with CL idle should work, although I prefer to have it activate as soon as the throttle closes. That worked with the v1.2.3 code I was running previously.

I think I know the reason the idle target is going up (when it actually should be going down) in steps. What happens is that CL idle tries to engage with the "ramp to target" after-start function in effect. So it grabs the current RPM and sets the target slightly lower. Since the target is now closer to the actual RPM, the idle timing correction shifts from very negative to slightly positive. The increased advance causes the engine's RPM to jump up, kicking CL idle off. A few moments later something happens (presumably the delay to enter CL idle times out) and it tries to enter CL idle again. With the actual RPM now higher, it increases the target accordingly, causing a sharp change in idle timing, causing the RPM to increase, and starting the cycle all over again.

The "after-start ramp-to-target" code in this version seems nasty. It seems like it won't stop trying to "ramp to target" until it's achieved a stable idle no matter what happens. I've driven halfway to work with the thing still trying to ramp, since whenever the throttle is opened, it seems like it just "freezes" (or maybe restarts?) the ramping and resumes when the throttle closes again. So if you're driving and only make brief stops that aren't long enough for the ramping to finish its task, it never quits trying.

[elaw]

Actually I just looked at the full log some more and there's some really weird stuff going on with the CL idle target.

As I describe above, the "ramp to target" didn't seem to finish until about the 195-second point.

But it also seems that most but not all times that CL idle engages, the target will jump up 100-200 RPM for no apparent reason. By "no apparent reason" I mean as far as I know it should only be dependent on CLT, and CLT is not changing (except very gradually as the engine warms) at those times.

If anyone wants to download the full log showing the problem, it can be found at http://www.thelawsplace.com/2016-10-25_06.09.26.zip

[CRSTune]

It's been a while since I really looked at PID closed loop parameters but yes, it likely is the "PID Ramp to Target Time" that's causing it to sporadically increase in steps. Increase your "PID Disable RPMdot" to help mitigate popping out of CL. Try 300 or 400. The other option is to use VSS to activate CL if you have a speed input. This disables the RPMdot parameter and uses vehicle speed to determine if it should or should not be in CL.

You may also want to decrease the total range of timing correction. If you make the rpm delta range too small or the timing corrections too large, the system will be too responsive and unstable. Try no more than 10 degrees of timing change rather than 18. On my own vehicle, I have a change of 5 degrees over a 300RPM delta in both directions.