Lean for ~60 seconds after start up

[fastslvblkcar]

So, I have been told this is due to not having rear O2 sensors. Can this be tuned out (ish) by using Cold Warmup After Start initial adder and decay delays? I have been fighting this lean condition for a few years now, but spring, summer and fall get in my way. I also have been fighting a very lean (.2-.3 lambda) cold start condition. I think I have been working this latter out but was curious if the other can be tuned to not be an issue by using these tables too.

[edcmat-l1]

Seriously? How is anyone supposed to help if they have no idea WTF you're tuning or WTF you've done? Standard procedure is post the tune file, a data log and the complete vehicle specs and mods.

[fastslvblkcar]

I was just asking of this lean condition from the rear oxygen sensors can be tuned by using the initial adders and decay delay. I wasn't asking for you to inspect my tune file and see what I need to adjust for the other part. Also, the vehicle specs are in my signature.

[edcmat-l1]

I was just asking of this lean condition from the rear oxygen sensors can be tuned by using the initial adders and decay delay. I wasn't asking for you to inspect my tune file and see what I need to adjust for the other part. Also, the vehicle specs are in my signature.

The rear O2 sensors have no bearing on AFR right after start up. Why would they?

Where is it lean for the first 60 seconds of run time?

[fastslvblkcar]

Blindsquirrel responded to a post of mine about this earlier this year and I couldn't find the thread. I just found it. The lean condition isn't just over 1.0 lambda, it is higher than commanded lambda and results in engine surge and sometimes stalling. Since then I have found that the problem would start around 25 seconds after startup and go back to normal around 54 seconds of engine runtime. I am just trying to avoid wiring back in the rear O2 sensors and the idle surge when temps drop below 50 degrees. https://forum.hptuners.com/showthrea...after-start-up

[edcmat-l1]

Again, point out in your data log where this is taking place. I don't see it lean anywhere in the first 60 seconds of run time. It starts rich as it should and then goes into closed loop. The narrowbands reflect that. Looks like it's functioning normally.

You're logging way too many pids and not the right ones to diagnose any idle behavior issues.

[fastslvblkcar]

It never goes into closed loop as it is not enabled. Compare the desired to the actual Lambda and you can see the lean condition.

[edcmat-l1]

Rarely am I wrong about something in a data log I'm looking at. Both data logs show short term fuel trim activity along with oscillating O2 sensors. It's in closed loop sir.

[edcmat-l1]

It never goes into closed loop as it is not enabled. Compare the desired to the actual Lambda and you can see the lean condition.

I don't care what the desired compared to actual is. You said it's lean and it is not. Furthermore, it is most likely not the root cause of your issues.

[fastslvblkcar]

Is it not lean compared to the desired? Wouldn't this cause an idle surge? Especially in cooler temps?

[edcmat-l1]

Is it not lean compared to the desired? Wouldn't this cause an idle surge? Especially in cooler temps?

It's not lean. Stop saying that. Doesn't matter if it isn't exactly what you're commanding. It's not lean. Once you get past that you may be able to work at what's really going on. As long as you're focused on a problem that doesn't exist, you'll suffer from tunnel vision. You don't even know closed loop when you see it. Not sure you're up to speed here.

I'd get rid of at least half your pids, maybe 75% of them. Focus on the few you need to dial in your idle.

I don't know all the specs of all the goofy named cams out there. Depending on the cam, you might not be able to get away from some idle surge. On that same note, you haven't provided any data logs showing the idle surge. Only data logs showing a lean condition that doesn't exist.

All that being said, most of the time idle surging is caused by too much fuel, not too little.

[fastslvblkcar]

The reason I have so many pids is that I use standalone logging and I use this on multiple vehicles. I also log a lot of information because I race this truck and am a data whore. Here is a log from today along with the tune. Vehicle sat for 11 hours but it was 70? when I started it. The major surge begins when I put the truck in gear soon after startup and will go away if I put it back into neutral. This surge used to be bad enough to happen in park or neutral but has lessened over time with tuning.

[edcmat-l1]

The reason I have so many pids is that I use standalone logging and I use this on multiple vehicles. I also log a lot of information because I race this truck and am a data whore. Here is a log from today along with the tune. Vehicle sat for 11 hours but it was 70? when I started it. The major surge begins when I put the truck in gear soon after startup and will go away if I put it back into neutral. This surge used to be bad enough to happen in park or neutral but has lessened over time with tuning.

I can appreciate being a data whore but for a GEN3 that's way too many pids. You end up slowing the scanner sample rate down. Also, there really is no need for any of the misfire pids. That's like 16 pids all by themselves. There's no reason to monitor your generator F terminal. Or your fuel system status (2 dif pids). You can tell that by watching your fuel trims. That pid is incorrect anyway. Says open loop and it clearly is not. Fuel tank level, fuel level sensor, engine oil pressure, fan 1, all those are useless.

Not only are you logging too many pids you aren't logging the correct ones to diagnose this problem. If you're going to be a data whore at least pick the right pids.

I suggest making multiple pid lists instead of trying one size fits all.

Now, as far as the data log attached, you can see when it goes into the surging around 35 seconds, it's plenty rich. I don't care about the commanded versus actual. The narrowbands clearly show it's rich.

You're focusing on the wrong thing trying to fix this. And without the right pids you won't figure it out.

[SiriusC1024]

Hey Ed what's with the fuel trims functioning in OL? Is that STFT Open Loop?

[edcmat-l1]

Hey Ed what's with the fuel trims functioning in OL? Is that STFT Open Loop?

Probably. That's the only logical explanation.

[Alvin]

The reason I have so many pids is that I use standalone logging and I use this on multiple vehicles. I also log a lot of information because I race this truck and am a data whore. Here is a log from today along with the tune. Vehicle sat for 11 hours but it was 70? when I started it. The major surge begins when I put the truck in gear soon after startup and will go away if I put it back into neutral. This surge used to be bad enough to happen in park or neutral but has lessened over time with tuning.

The only fuel that burns is that which is vaporized. On a cold engine this is hard to do. So while the engine is cold a richer than normal AFR is commanded so that you saturate the engine with fuel hopefully getting enough vaporized fuel to burn. So while on first start the engine is commanding a 9:1 AFR.. the engine isn't actually 9:1. If it would be.. it would be smoking. A very well tuned engine will command richer than normal fueling while cold yet read close to but a bit rich stoich during the same period on with your wideband.


You might want to try disabling OL STFT. This will tend to run leaner than a cammed setup likes while too cold. In fact its helpful to delay OL until the engine is really warm sometimes with a cam. That may help your idle surge but I honestly didn't see any in your logs. Just a rough idle on one.

Also.. VE is very rough and likely contributing to surge. Timing is too high at idle. Good idle timing control would get the idle in line.

[edcmat-l1]

Good Lort I didn't even look at it. That's another WTF VE.