Idle stability troubleshooting, G4+ Fury, FD RX7 with DBW throttle

[Pete_89t2]

I'm a bit stumped at this point trying to solve a somewhat intermittent idle stability issue I'm having with my FD. It will sometimes have an unstable, oscillating idle where idle speed error swings wide of the target in both directions and may sometimes even get close to stalling. It does this most frequently when returning to idle speed from low speed/low RPM/light load maneuvers, like you would have in a parking lot or for example when I come to a stop/idle after goosing the throttle to climb the slight hill up my driveway to park in my garage.

This Google Drive link contains my current tune file and a PC log of it behaving this way: https://drive.google.com/drive/folders/1HPzL_D1X3PD_X1ck0d3zerRav5QcjCgG?usp=sharing

You can see the erratic idle behavior happening between time index 7:02 - 7:28, after I stopped for a traffic light where the idle was simply a bit unstable but never close to stalling. At index 9:00 - 9:35, again after stopping for a traffic light, the idle was consistently overshooting the target, and then towards the end of that period it started to oscillate wildly. Just after index 12:12, which was after I pulled car into my garage (i.e. low RPM/higher load to climb driveway hill), it returned to an unstable idle with several near stalls until the end of file when I shut it off.

Since I also have closed loop lambda control enabled at idle, and the Lambda1 is oscillating around the target lambda while idle is acting up, I'm not sure if this is a chicken & egg issue - unstable idle control causing the unstable lambda, or CL lambda instability causing the unstable idle? Anyway, I would appreciate any tips I could get to help me figure this out from the more seasoned experts.

[Adamw]

The oscillation is closed loop lambda, mostly the update rate is too high, possibly excessive gain as well, but start with the rate.  Reduce the update rate to 1Hz at 1000RPM, 2Hz at 2000RPM and maybe 5Hz at 3000. 

 

5 hours ago, Pete_89t2 said:

At index 9:00 - 9:35, again after stopping for a traffic light, the idle was consistently overshooting the target, and then towards the end of that period it started to oscillate wildly.

 The overshoot is excessive base position and fan step I think.  If we look at time section 2:25, you are idling close to target RPM with 2 fans running with the throttle open 4.5%.  But you have 4% commanded in E-throttle target, plus 2.0% in base position, and a further 1.5% fan step, so you are telling the ecu to go to 7.5%, when it only needs 4.5%.   You can see the "E-throttle ISC CL trim" is pulling 3% out to achieve the idle target.   The oscillation is initially caused again by CLL, but this does then cause the RPM to drop low enough to hit the anti-stall gain which upsets things further.  Reduce the anti-stall gain to 1.5 or 2.0.  

 

5 hours ago, Pete_89t2 said:

Just after index 12:12, which was after I pulled car into my garage (i.e. low RPM/higher load to climb driveway hill), it returned to an unstable idle with several near stalls until the end of file when I shut it off.

This is the same CLL and anti-stall gain issue as above.  

 

Not really related to idle but something I noticed in your log - the engine fan 2 only has a 1deg hysteresis on it which causes the fan to bounce on and off rapidly when the temp crosses the threshold.  ECT only has a 1 deg resolution so your hysteresis needs to be bigger.  This will be pretty hard on the relay and fan motor.  

[Pete_89t2]

15 hours ago, Adamw said:

The oscillation is closed loop lambda, mostly the update rate is too high, possibly excessive gain as well, but start with the rate.  Reduce the update rate to 1Hz at 1000RPM, 2Hz at 2000RPM and maybe 5Hz at 3000.

Thanks Adam. I'll try reducing my CLL update rates below 3000RPMs as suggested first and see if that improves things at idle & below 3000RPMs. I need to take a closer look at some of my other logs for the higher RPMs, but previously I was using slower sample rates and slightly lower CLL gains across the board, but found that CLL was rather slow to converge on target lambda's, especially above 2500 RPMs or so. It wouldn't oscillate around the target lambda, it was just very slow to converge from whichever direction (rich or lean) that it needed to go.

Which I think means that my gains & update rates >3000 RPM are probably close to where they need to be? I'm using the 3D CLL correction table to allow +/-10% CLL correction in vacuum, but in boost I'll allow it to go up to +10% richer, but limit the % fuel I allow it to pull out based on boost level (more boost ==> allow less % correction in the lean direction)

15 hours ago, Adamw said:

 The overshoot is excessive base position and fan step I think.  If we look at time section 2:25, you are idling close to target RPM with 2 fans running with the throttle open 4.5%.  But you have 4% commanded in E-throttle target, plus 2.0% in base position, and a further 1.5% fan step, so you are telling the ecu to go to 7.5%, when it only needs 4.5%.   You can see the "E-throttle ISC CL trim" is pulling 3% out to achieve the idle target.   The oscillation is initially caused again by CLL, but this does then cause the RPM to drop low enough to hit the anti-stall gain which upsets things further.  Reduce the anti-stall gain to 1.5 or 2.0. 

Ok, if I understand correctly, first thing to do here is to reduce just the anti-stall gain to 1.5~2.0, and then if I still have idle overshoot/stability issues, try playing with the E-throttle target/Idle base/fan step, using the E-throttle ISC CL trim data from logs to inform how much/which direction to tweak those?

I initially got the E-throttle step, Idle base position & fan step numbers all set up before CLL was enabled, and idle was pretty stable back then, so is it safe to assume only the anti-stall gain is really out of whack here?

15 hours ago, Adamw said:

 Not really related to idle but something I noticed in your log - the engine fan 2 only has a 1deg hysteresis on it which causes the fan to bounce on and off rapidly when the temp crosses the threshold.  ECT only has a 1 deg resolution so your hysteresis needs to be bigger.  This will be pretty hard on the relay and fan motor.

Interesting, I have E-fan 2 set for 2*F hysteresis, but because it only has +/- 1* resolution that's effectively the same as setting the hysteresis to 1*? I'll increase that to 3~4*F then. FYI, these are not separate fans, but multiple speeds for a pair of fans that run together. I basically replicated the FD's OEM fan operation - when EFAN 1 comes online, both fans start at low speed; when EFAN 2 comes online, both fans speed bumps up to medium speed. If the A/C is turned on, the factory wiring bumps up the fan speed one level from whatever speed it was running at the time, or if not running, starts the fans up at low speed

 

 

[Adamw]

7 hours ago, Pete_89t2 said:

Ok, if I understand correctly, first thing to do here is to reduce just the anti-stall gain to 1.5~2.0, and then if I still have idle overshoot/stability issues, try playing with the E-throttle target/Idle base/fan step, using the E-throttle ISC CL trim data from logs to inform how much/which direction to tweak those?

I initially got the E-throttle step, Idle base position & fan step numbers all set up before CLL was enabled, and idle was pretty stable back then, so is it safe to assume only the anti-stall gain is really out of whack here?

No it looks like base position table is way off as well, this is what causes the idle to sit higher than target and slowly come down.  So you have likely changed something else that effected the amount of air the engine needed after the original open loop tune - most commonly mixture or timing, but possibly the engine has got freer, thinner oil etc.  The antistall gain is only kicking in when the oscillation gets real bad, from memory the RPM needs to drop more than 150RPM below target. 

[Pete_89t2]

13 hours ago, Adamw said:

No it looks like base position table is way off as well, this is what causes the idle to sit higher than target and slowly come down.  So you have likely changed something else that effected the amount of air the engine needed after the original open loop tune - most commonly mixture or timing, but possibly the engine has got freer, thinner oil etc.  The antistall gain is only kicking in when the oscillation gets real bad, from memory the RPM needs to drop more than 150RPM below target. 

Yesterday I applied the suggested changes to the CLL rate below 3000RPM, reduced the anti-stall gain to 1.5 and went for a test drive. The near stalling and wild idle & lambda oscillating behavior is gone now, but you're correct that I still need to adjust the idle base position table and probably the base E-throttle target, fan & AC steps - the idle was still overshooting frequently, taking a long time to converge on idle target and sometimes oscillating, though not with wild swings in magnitude like before. Didn't have the time to tune it further yesterday, but before shutting it down, I let it idle at full operating temp for a while to collect log data.

After looking at the logs, idling with the ECT at 190~194*F and both E-fans running, I was seeing the E-throttle ISC Trim between -2.8 and -3.8 whenever the idle status was reading RPM Target, so on average it looks like I need to go -3.3 total. Same conditions, but with the AC on, the ISC trim was at about -4.3 to settle on RPM target. Will test & tune this further today, but here's the plan:

- Reduce E-throttle base target for idle from 4% to 3%; Reduce Fan Step from 1.5% to 0.5% - these two should take -2% out of the -3.3% ISC trim average

- Reduce the AC step from 3.5% to 2.5% - This change plus the above changes should take -3% out of the -4.3% ISC trim when the AC is running

- Start the car cold & run the car at idle while monitoring the run time data for E-throttle ISC Trim & RPM target, making adjustments on the Idle Base Position table as needed to null the ISC Trim to as close to zero as possible when the car hits its RPM target. This should get the table right from whatever temp it is at startup to full operating temperature.

[Pete_89t2]

Update to my idle & CLL tuning. I've done some further tuning per Adam's suggestions, and things have improved quite a bit - idle is much more stable, and CLL seems to be working much better. Google drive link below has the current tune and a log that captures a cold start & drive for about 25 minutes or so.

https://drive.google.com/drive/folders/1_MTn87vUJtRVB760aJPZs1y3SRk-ERR6?usp=sharing

The one problem I'm still having is when driving around at full operating temperature in a residential neighborhood (i.e., 25MPH max, stop signs on every corner, barely hit 2nd gear before having to clutch & coast/brake for the next stop sign), the engine wants to stall, though in this log you can see where the idle control catches it before it does. You can see examples of these near stalls between time indexes 21:11:426 and 21:14, and again between indexes 22:33:224 and 22:35, from where I depress the clutch and the engine RPM should drop to idle, but undershoots idle speed to a near stall.

My car lacks a non-driven wheel speed sensor, though I do have a driven wheel speed sensor, so I think the ignition idle control feature is ignoring the idle speed lockout, but the DBW throttle closed loop idle control isn't ignoring the speed lockout because I do have a driven wheel speed sensor fitted? Anyway, I tried to setup the RPM lockouts on both to coincide at 1500 with the car running at full operating temperature

Does the closed loop lambda control at idle look good enough here, or could I expect to do better with further tweaking of the CLL gains?

[Adamw]

Can you zero the CLL trim in the overrun/idle entry area to see if that helps the near stall.

[Pete_89t2]

51 minutes ago, Adamw said:

Can you zero the CLL trim in the overrun/idle entry area to see if that helps the near stall.

Sure, I'll give that a go and post up a log after I take a drive to collect one. Should I zero out both negative AND positive CLL trims in the overrun/idle entry areas, or just the negative CLL trim as pictured? If the intent is to completely disable CLL in that region I'd assume I'd need to zero both out.

[Pete_89t2]

Ok Adam, I went ahead and zeroed out the CLL trims (+ & -) in the overrun/idle entry areas as suggested. Google drive link to the current tune & log file of it running with that change: https://drive.google.com/drive/folders/1wUKlKTnfxWezpxcjkIOnhgXaIJZRaXtE?usp=sharing

I basically replicated the same drive as last time, though ambient temps were a few degrees cooler today than last time. From behind the wheel, the undershooting on return to idle is less pronounced and recovers quickly so the drive ability is much better, but it's still happening and evident in the log. You can see this behavior (minimal RPMs/worst undershoots) around time indexes 12:23; 13:09; 13:55; 17:08; 17:38; 18:03; 18:24; 19:27 and 19:38.

In most of those cases, it looks like CLL was still trying to trim the lambda towards target, unless RPMs dropped below the CLL RPM lock-out. Should I zero out the CLL +/- trim limits in the 5.8psi MAP row out to 3000RPMs as a test?

Looking at my Lambda/AFR target table and Fuel Table, would it be smart for me to adjust those axes to better suit my application? I only plan to boost this engine to 15~16psi MGP max, so I was thinking since the engine practically never sees the 0psi MAP cells in practice, I could get rid of that row, start at 2.9psi MAP instead and put the maximum row at 16psi MGP/30.7psi MAP, which would buy me a row or two of extra load (MAP/MGP) resolution to use in the vacuum regions.

[Adamw]

The CLL is not pulling much out in that area now so I dont think that is the remaining problem now.  Im a bit unsure if the lean spike is now a cause or a symptom of the idle undershoot.  What happens if you add say an extra 0.25-0.5% to the base position table for that temp?

[Pete_89t2]

43 minutes ago, Adamw said:

The CLL is not pulling much out in that area now so I dont think that is the remaining problem now.  Im a bit unsure if the lean spike is now a cause or a symptom of the idle undershoot.  What happens if you add say an extra 0.25-0.5% to the base position table for that temp?

 I'll give that a try, but I suspect that whatever I add to the idle base position table will end up being pulled back in the E-throttle ISC CL trim, no?

[Adamw]

Closed loop is not active in any of your undershoot examples.

[Pete_89t2]

11 hours ago, Adamw said:

Closed loop is not active in any of your undershoot examples.

Which closed loop control are you referring to as not being active? In those previous examples, the Ignition Idle Control goes active first, as soon as my RPMs drop below 1500. Since I only have a driven wheel speed sensor, the speed lockout is apparently ignored by the Ignition Idle control, but the speed lockout for the E-throttle idle control prevents that from activating until speed drops below 10mph.

Anyway, I went ahead and tried your suggestion to add back another 0.25 to the Idle Base Position table in that temperature range (cells from 176* thru 212*F), and reverted the +/- CLL limit tables back to where they were in the overrun/return to idle areas, then took another drive with it. Tune file & log from that drive is here - https://drive.google.com/drive/folders/1BD40aTlvR6pv38NBl1PH9v0BcI5OA_Ow?usp=sharing

I'm seeing a bit more oscillation of lambda & idle errors after making the above changes, see log between time index 13:08 to 13:55.

[Adamw]

2 hours ago, Pete_89t2 said:

Which closed loop control are you referring to as not being active?

Idle speed control.  In the areas you get undershoot the idle speed control is in speed lockout, so increasing the base position would not be removed by E-throttle CL ISC until after ISC status becomes active.  

From that last log it is starting to look more like a fuel issue, the oscillation at 13:30 and after 22:30 seems to be linked to the oscillating lambda, the throttle is nearly dead still.  

Can you try the 3 changes below separately to see if either makes a difference:

1. Zero out the SPWA table. 
2. Make the lambda target around idle something like 0.87.
3. Put 10 right across the idle ign table.  

[Pete_89t2]

8 hours ago, Adamw said:

Idle speed control.  In the areas you get undershoot the idle speed control is in speed lockout, so increasing the base position would not be removed by E-throttle CL ISC until after ISC status becomes active.

 

Understood, I was thinking the initial undershoot is being caused by the ignition idle control acting alone first because of the speed lockout on E-throttle CL ISC. In those cases where I clutch in & coast, you can see the ignition idle control goes active as soon as the RPMs drop below the 1500 RPM lock out, ignoring the 10mph speed lockout and that's where the undershoot happens. So I was thinking of trying one of the following: (1) Lower the RPM lockout on Ignition Idle Control to be closer to warm idle speed, say about 1000RPM, or (2) Put all 10's (normal timing @ idle) in the Ignition Idle Control table where the error is overshooting idle, which essentially prevents ignition idle control from doing anything if the idle overshoots. Neither approach is perfect; (1) would likely degrade idle during warm-up, and (2) would make idle overshoot conditions tougher to manage I would assume.

8 hours ago, Adamw said:

From that last log it is starting to look more like a fuel issue, the oscillation at 13:30 and after 22:30 seems to be linked to the oscillating lambda, the throttle is nearly dead still.  

Can you try the 3 changes below separately to see if either makes a difference:

1. Zero out the SPWA table. 
2. Make the lambda target around idle something like 0.87.
3. Put 10 right across the idle ign table.

Just to clarify, are you suggesting I try each of these changes (1), (2) & (3) individually, log & then revert to what I had before trying the next one & repeat?

That SWPA suggestion is interesting; I got my SWPA data & dead time data table direct from Injector Dynamics when I purchased the new injectors. But I also see that the leaner than typical target lambda's (for a rotary) I'm running at idle are resulting in small injector duty cycles & pulse widths, so maybe it's trying to operate in a non-linear area?

 

[Adamw]

6 minutes ago, Pete_89t2 said:

I was thinking the initial undershoot is being caused by the ignition idle control acting alone first because of the speed lockout on E-throttle CL ISC. In those cases where I clutch in & coast, you can see the ignition idle control goes active as soon as the RPMs drop below the 1500 RPM lock out, ignoring the 10mph speed lockout and that's where the undershoot happens.

Engine torque typically responds almost instantly to spark advance, you will notice the idle ignition adds significantly more advance as the RPM comes down close to target so I think it is probably helping reduce the undershoot, not causing it.   Typically you want idle ignition working at higher speed and RPM to the air flow control so I dont think the lack of speed lock out is doing you any harm in this case.  If you want the speed lockout to work you just need to set non driven wheel speed source to LR wheel as well. 

 

11 minutes ago, Pete_89t2 said:

Just to clarify, are you suggesting I try each of these changes (1), (2) & (3) individually, log & then revert to what I had before trying the next one & repeat?

Correct.

 

12 minutes ago, Pete_89t2 said:

That SWPA suggestion is interesting; I got my SWPA data & dead time data table direct from Injector Dynamics when I purchased the new injectors. But I also see that the leaner than typical target lambda's (for a rotary) I'm running at idle are resulting in small injector duty cycles & pulse widths, so maybe it's trying to operate in a non-linear area?

ID data usually works better than most, however, they test the injectors with a Motec injector driver and a test fluid that is only somewhat similar to gasoline, the SPWA is only determined at one specific voltage and one specific pressure and is only an average of a large batch of tested injectors, so there is still a lot of room for error.  The reason I think it is worth zeroing it out as a test is your wideband is reporting a swing in lambda of about 20% where the reported inj PW is only varying a few % more than MAP   

[Pete_89t2]

5 minutes ago, Adamw said:

Engine torque typically responds almost instantly to spark advance, you will notice the idle ignition adds significantly more advance as the RPM comes down close to target so I think it is probably helping reduce the undershoot, not causing it.   Typically you want idle ignition working at higher speed and RPM to the air flow control so I dont think the lack of speed lock out is doing you any harm in this case.  If you want the speed lockout to work you just need to set non driven wheel speed source to LR wheel as well.

^ I didn't even realize that was an option! Since I'm not using traction control, but limited to the one driven wheel speed sensor I have, I suppose it wouldn't hurt to try this so both the ignition & throttle based idle CL controls have the same speed lockouts.

5 minutes ago, Adamw said:

Correct.

 

ID data usually works better than most, however, they test the injectors with a Motec injector driver and a test fluid that is only somewhat similar to gasoline, the SPWA is only determined at one specific voltage and one specific pressure and is only an average of a large batch of tested injectors, so there is still a lot of room for error.  The reason I think it is worth zeroing it out as a test is your wideband is reporting a swing in lambda of about 20% where the reported inj PW is only varying a few % more than MAP   

 

Thanks for confirming. I'll give those tweaks a shot & post logs when I get a chance.

[Pete_89t2]

I had a chance to test zeroing out the SWPA table for my primary injectors, and do another test drive/log. I also set my non-driven wheel speed source to the same sensor as the driven wheel speed source, so that the Ignition Idle control and E-throttle idle CL control have the same speed lockouts. Google Drive link to the files is here: https://drive.google.com/drive/folders/1DlabmLEpip2GFLkRar7Ia2MqIfUkWQ2s?usp=sharing

From behind the wheel, the drive-ability feels much improved - feels like there's a smoother transition into idle from those low speed clutch/brake & stop traffic situations, and the idle settles down and smooths out faster. From a quick look and comparison to previous logs, I still have some lambda/lambda target oscillation happening initially after the transitions to idle, but the magnitude of the swings are not as large as before, and it seems to flatten out quicker. Same for the idle speed error - settles to target quicker, and for the most part stays on target.

BTW, I only zeroed out the SWPA table of my primary injectors - the staged secondaries don't come online until I'm a few psi into boost, so I didn't mess with the secondary injectors SWPA table.

Being a noob at this, I guess the question I have is this good enough? Does my target/actual lambda track well enough, and is this the best I can expect here from CLL control?

I'm also wondering if the occasional ignition miss at idle would cause the CLL control to get wonky? Seems reasonable, as a single ignition miss on one of the 2 rotors would show up at the WBO2 sensor after a short delay as a lean reading, but because the CLL update rate can't be any slower than 1Hz in the G4+, it might end up over correcting on the transient lean reading. 

[Pete_89t2]

Ok Adam, I had a chance today to test out all 3 of your suggested changes individually. Link below has the tune & log file for each test, file name describes each one. https://drive.google.com/drive/folders/1mwQ4HPjgyoO-hV6gGRl3iuXew-9GpmW5?usp=sharing

Summary results:

For drive-ability, best idle quality and the least oscillation in either idle error or target/actual lambdas, suggestion #2, "make target lambda something like 0.87 around idle" worked the best. When I did this I set it at 0.880 in the entire idle region, and I undid the changes made from suggestion #1 (zero out the SWPA table).

The drive-ability, idle quality and idle/lambda oscillation did improve slightly in suggestion #1, "zero out the SWPA table", but it wasn't improved enough (on the road or in the logs) for me to say conclusively that the SWPA table was the root cause - those oscillations are still there in the logs, just with generally smaller magnitude swings.

Suggestion #3, "put 10 right across the ignition idle table" made idle quality and the idle/lambda oscillations significantly worse than my original baseline

So I'm concluding two things from this exercise - (1) My FD really needs the idle ignition control to assist with maintaining a steady idle, and (2) It would appear it would be happier with a richer target lambda than I've been running in the idle region. Which is unfortunate, because I was hoping to get it to idle as close to stoich as possible. I suppose I can try to iteratively lean out the idle region target lambda until I reach the point where idle/lambda target tracking just starts to get wonky again?

Thoughts?