Surging Idle while Coasting

[gpr]

Got the car tuned in pretty well and idling nicely, however I have notice one annoying thing which i can't figure out. For some reason if the car is coasting to a stop at idle it will begin to surge. once you stop the idle tables must change and the surging will always stop, but any time your rolling with 0% throttle at an idle rpm it will surge... Any suggestions on what to look at or change? I have enclosed both a screen shot of the scan, and the tune. File

I thought it was possibly the fuel or spark cells it was pulling from had drastically different values causing the surge, so i put all the same values in for the timing and smooth out the fuel tables. this didn't help.

[gpr]

bump, anyone got any ideas or pointers on where to look? I thought maybe throttle cracker or throttle follower but I am at 0% throttle when the issue happens and the rolling idle tables don't really have anything addressing this issue.

[joecar]

That depression in your VE table (since MAF is failed) at 1200rpm/40kPa does not look right, and may be under-computing airmass... and in your log it looks like spark advance might be being used to attempt to control engine speed...

[ferocity02]

Mine does this too ever since switching to COS5 2bar SOLSD. It was perfect before. I just haven't gotten around to trying to fix it.

Throttle cracker opens up the throttle if you're moving, so that could be a place to start. Also, the idle spark control isn't active until you stop, so that's another thing to consider.

[gpr]

I copied the high and low learned values from the idle section to the rolling idle high and low learning idle correction. This seemed to help with the surging but did not completely eliminate it.

btw, i did change the VE table at that spot. I had stft enabled, so i'm guessing when logging data that was throwing off the ve calculations?

[Wheelz]

btw, i did change the VE table at that spot. I had stft enabled, so i'm guessing when logging data that was throwing off the ve calculations?

If you did not account for the stft in your calc_pids file then yes they will cause errors with your VE table. Been there before...

[gpr]

If you did not account for the stft in your calc_pids file then yes they will cause errors with your VE table. Been there before...

How do you add the stft into the calc_pids file? i have been using the one posted on here in the calc.maft thread.

[joecar]

OL STFT trimming must be first disabled (before doing tuning)...

OS: disable B4206.
COS: disable B4206 (if it exists), and avoid having stoich cells in B3647.

[gpr]

OL STFT trimming must be first disabled (before doing tuning)...

OS: disable B4206.
COS: disable B4206 (if it exists), and avoid having stoich cells in B3647.

B4206 doesn't exist in the COS5, it is B4108 to disable stft at idle.

Why are you not suppose to have stoich cells in B3647? I thought they were all suppose to be stoich values except the last column or two which are richer?

[Chevy366]

B4206 doesn't exist in the COS5, it is B4108 to disable stft at idle.

Why are you not suppose to have stoich cells in B3647? I thought they were all suppose to be stoich values except the last column or two which are richer?

Because Stioch in B3647 in a COS causes stft mode, you need to eliminate all such modifiers.

[gpr]

Ok, any recommended values to enter in that table? Do you put values just slightly off stoich so stft are disabled, yet you aren't commanding a right value.

[joecar]

Yes, choose either EQR 0.98 or EQR 1.02

( you will see those commanded )

[Rich Z]

I've got a question about this method of working with table B3647. If you set the low to mid kPa cells to something like 0.98 (mine is set to lambda, btw) and do the calibration of the VE table with these values, when you go back to setting those cells to 1.00, does that throw the STFTs off kilter? Is this enough to matter, or simply one of those inconsequential differences things?

Would it be better to set those cells to something like 0.999 instead to be as close to 1.00 as possible without triggering the STFTs into operation?

[gpr]

I've got a question about this method of working with table B3647. If you set the low to mid kPa cells to something like 0.98 (mine is set to lambda, btw) and do the calibration of the VE table with these values, when you go back to setting those cells to 1.00, does that throw the STFTs off kilter? Is this enough to matter, or simply one of those inconsequential differences things?

Would it be better to set those cells to something like 0.999 instead to be as close to 1.00 as possible without triggering the STFTs into operation?

I was also wondering this, but figured it would be only 2% off and that if my trims were only 2% off I'd be extremely happy! :)

BTW, I finally figured out what was causing the engine to surge. It was the throttle cracker B4309. In the idle tuning tutorial it says to add air the entire row at 400 rpms. Once i zero'd out row 400 it cleared up the surging.

[joecar]

I've got a question about this method of working with table B3647. If you set the low to mid kPa cells to something like 0.98 (mine is set to lambda, btw) and do the calibration of the VE table with these values, when you go back to setting those cells to 1.00, does that throw the STFTs off kilter? Is this enough to matter, or simply one of those inconsequential differences things?

Would it be better to set those cells to something like 0.999 instead to be as close to 1.00 as possible without triggering the STFTs into operation?No... you will see STFT oscillation get smaller and tighter... you will see your wideband do the same thing.

[joecar]

I was also wondering this, but figured it would be only 2% off and that if my trims were only 2% off I'd be extremely happy! :)

BTW, I finally figured out what was causing the engine to surge. It was the throttle cracker B4309. In the idle tuning tutorial it says to add air the entire row at 400 rpms. Once i zero'd out row 400 it cleared up the surging.You have to remember that whatever EQR you're commanding, the BEN factor takes this into account...


BEN = COMMANDED EQIVRATIO * WIDEBAND LAMBDA


( remembering that wideband lambda = 1 / wideband EQR )

[joecar]

B4309 TC... ok thanks for posting that.

[gpr]

I wanted to revisit this. I got the car back up and running and was doing more tuning on it. I have table B3647 setup as follows, however when logging commanded AFR or EQ it is commanding 9.71 (i'm running e85) or 1.00 EQ. Why is this?

I know when I first changed this table it showed in the logs a different commanded value, but for some reason it is now commanding a stoich value again... Any idea's? (I'm wondering if I have changed something else along the way that would affect it?) I have STFT disabled at idle, but am wondering if they are really disabled if on the logs it isn't commanding the correct value?

[joecar]

E85 stoich has stoich AFR 9.7 which corresponds to EQR 1.00, which also corresponds to Lambda 1.00 (lambda = 1/EQR).


i.e. EQR 1.00 is stoichiometric (the AFR depends on the fuel).


Avoid logging AFR, and log EQR and/or Lambda instead.

[gpr]

I should have been more clear. Earlier in this thread we were talking about changing table B3647 so that the values aren't at 1.0 EQR, this way STFT are disabled. The attachment in my last post shows the B3647 table with values of 1.02 EQR, yet in the logs it is commanding a 1.0. Attached is a screen shot showing the commanded EQR.

When logging the EQR and AFR commanded should not be at stoich since in B3647 I am commanding a value slightly off stoich (to disable STFT), so why am i seeing the discrepancy?

[joecar]

Ah, I see...


Do you have parameter B4206...?

[gpr]

No I do not have that in my tune.

[gpr]

Here is my tune if you would like to look at it.

[joecar]

Can you also post a log file.

[gpr]

Here is the latest log from this afternoon. I went and changed the tune to display EQR as I had it in lambda and reloaded the tune. Anyway you can see at the beginning of this log it was commanding a eqr of 1.02 for a while, then it goes back to 1.0 for some reason....