ULTM8Z

I really need to stop jacking with this thing and put the ECM back up... lol... (it runs pretty much perfect, but I can't help myself!! )...

So my O2 sensor went out the other week and a I grabbed a spare I had sitting on my shelf. Both are AFS-74's. I had the spare one in the car until a couple of years ago when I put the WB in its place.

I noticed in some log data from the other day that the integrator is capped at 128. It'll go lower, but it'll never go higher. Even when the WB reads lean when in non-OL and non-PE, the ECM will not step in to correct the mixture.

The O2 sensor seems to be functioning correctly... it's bouncing around from ~0 to 900 mV and I get good cross-counts.

The calibration has the maximum integrator value set at 180.

BLM idle cell is behavior looks correct.

No codes are being thrown

I also tried a different ECM, but no change in behavior.

I went back a couple of calibrations thinking I jacked something up, but again no change.

Any thoughts?


EDIT: Just noticed in the data that I'm getting an ERROR 33 for High MAP sensor. But the log data is showing the MAP sensor reporting just fine?? Would a malfunctioning MAP sensor cause the ECM to cap the Integrator to 128? Intuitively seems like if the ECM was going into some sort of "safe" mode, you'd want the Integrator to bottom out at 128 such that the ECM can only add fuel and. Whereas by capping the integrator to 128, it can only subtract fuel when the integrator shows less than 128 (rich).

But the data showing this ERROR 33 was before I swapped ECM's. The 128-cap problem continued after swapping ECMs and I just scanned the car and it's showing no trouble codes.

Any rate, before I go out and buy a new O2 sensor or MAP sensor, just trying to see if I can nail down the problem by looking at the data.

ULTM8Z

Curiouser and curiouser... going back through earlier logs...

The 128 integrator cap started back on 1/2/2018. The log from 1/1/2018 doesn't show that behavior. So something I did between 1/1 and 1/2 seems to have caused the issue.

I pay so much attention to the BLMs, I guess I didn't notice the INT was never going above 128.

Problem is I don't correlate datalogs to calibration files... I guess I'll have to go back do some research on some of the changes around that time period to see what I did (or rather screwed up)...

But if anyone has any suggestions on what to look at, it'd be greatly appreciated!

Dominic Sorresso

How about just using the Difference Tool in TPRT. I use that all the time to compare one bin from another. Also, TPRT creates a text file for the changes saved to a previous bin file. I always “name”my bins by date code and then a brief suffix to indicate the major area I was focused on. Something like 3.19.18-SA as an example.

ULTM8Z

Thanks. Yeah, I actually keep pretty detailed records of all my changes. I'll probably go back to a calibration that pre-dates 1/2/18 and if the problem goes away, then at least I have a reference point.

Dominic Sorresso

Yeah sometimes u gotta backtrack.

ULTM8Z

Ok, I figured it out...

It was the change I made to keep the BLM from spiking during the decel enlean

https://www.thirdgen.org/forums/diy-...g-up-over.html

I have no clue what the mechanism is for why this change would cap the INT to 128, but as soon as I undid the change, the INT returned to normal operation. I put the change back in, and the INT gets capped at 128. So that's definitely the culprit.

Setting this DE MAP Enable to anything other than 0 seems to cause it (0 being the factory $8D value).

Any rate, maybe I just live with the lean spikes on decel. Unless there's a way to richen it up?

Dominic Sorresso

Odd so the change you made to disable BLM updates below 35kPa, actually capped the INT to 128 for all VE cells? That doesn’t sound like what was described in the other thread you linked to.

ULTM8Z

Yeah I don't understand why that change would have this effect...

the change did what I wanted it to in terms of solving the issue in that thread. But the side effect was that it capped the INT (and thus the BLM) to 128 everywhere.

84Elky

I've always been puzzled by the logic of this portion of the $8D code. Generally, if RPM is > 1200 (0x5AC default) and MAP is < 0x5AB, as you indicate the INT will always be forced to 128. Attached is a summarized flow of the logic that should explain what's happening. It appears this is done to avoid adjusting BPW (which occurs in CL if INT other than 128), when RPM is above a 1200 RPM threshold with a low MAP (that is if NOT in DFCO or Decel Enlean).

ULTM8Z

I've had this flag set for the longest time...

If NOT above in {} but 0x018 b1 (Reset INT TO 128 when in AE) is Set

It really helped out the AE tuning on the Miniram. But INT has been working fine for years with that flag set.

But yeah, It seems like it's part of this logic that's causing it...

If Decel Enlean (DE) ACTIVE ---AND---
; RPM > 1200 (0x5AC) ---AND---
; FAST o2 going Rich
; ---OR---
; FAST o2 going Lean ---AND---
; INT >= 128

Somehow setting the MAP enable to 35 kPa triggered that logic...

That last part "FAST O2 going lean INT>=128"... so then everytime the INT tries to go >128, it gets reset back to 128, thereby being "capped" at 128.

84Elky

1. No problem with 0x018 b1 (Reset INT TO 128 when in AE) being Set. Generally best.
2. Likely not the code area you cited, but this:
   ; If DE NOT Active--------------------------AND---
   ; MAP < 0 kPa (0 = 0x5AB default)-------AND---
   ; RPM > 1200 (1200 = 0x5AC default)---AND---
   ; FAST o2 going Rich
   ; ---OR---
   ; FAST o2 going Lean-----------------------AND---
   ; INT >= 128