I have a RAM variable that is a bit array of flags used heavily in the fuel routine. A brief drive from a warm start today showed there may be some correlation between this bit array and the issue I've been noticing.

Anyway, I'll grab a log tomorrow morning when the issue is very apparent and see if there is an actual correlation.

I'm guessing it may be due to the adders that are part of the load selection that mrfred has posted about in his thread on logging various load parameters.

 

Grabbed a couple logs and there looks to be some correlation to my issue. I will post the actual log tonight, as I can't post from my laptop right now.


RAM: FFFF8A26/8A27
8A27 is MUT18

This memory address is a flag that controls around 15 different fuel related sub-routines. It is used in several routines to select what load variable is used for lookup to tables. It controls the main fuel look up too, but I don't think the issue I am noticing is related to the main fuel table.

The car goes lean when that value goes to one of three values: 12288, 8194, 2
The car is not lean when the value is: 12508, 8414, 13021, 8350, 222



Under the conditions I feel the change over, the car goes from 2 to 222.


It is immediate too, as soon as it changes over, actual AFR goes from 17:1 or leaner right down to 13:1-14:1 and driveability is great again. The log also has some points of oscillation where it bounces between 2 and 222 and the actual AFR bounces from 17:1 to 13:1 right in phase with it.

It looks like potentially bits 3, 4, 5, and/or 8 may be the related to the issue based on the patterns.

 

Here is a log. This was the most dramatic for length, lean condition lasted about 5 seconds.

MUT18 steps from one value (12288) to the next (12508 then 13021). Shortly after, actual AFR comes right down to what is programed in the main fuel map.
The number in MUT18 were different in this log than mentioned above, however, as noted, there are a couple values where it runs good, and a couple where it's lean. This log happened to be the larger set.

Sorry, the big values in MUT18 make it a PITA to see things. I need to rescale the axis in EVOScan.

 

Here is a log with some oscillation.

This one is between 2 and 222.

The AFR change is less dramatic in this one.

 

Did you use Eval="x" for MUT18 in the second plot?

 

Yeah, I think in that particular log I may have been grabbing only 1-byte. Not 100% sure though. The oscillation shows up regardless, it just bounces between different values.

MUT18 has a ton to do with front O2 feedback and then a couple different fuel routines besides closed loop.

It looks to start as EFFF when in closed loop and 0100 if in open loop. From there, it gets written to a couple times and read from about 20 times. Closed loop obviously makes this value bounce around a ton. If I recall, the issue was there when in open loop too though, so I'm going to grab some logs in open loop to see if it can get rid of a couple of the values I've logged and go from there.

 

Here's the lowdown on lower eight flags in MUT18 (using your nomenclature where bit1 is the lowest bit):

bit1 - 1 when load > OL load, 0 when < (OL load - hysteresis), when 1 use (OL load - hyster), when 0 use (OL load)

bit2 - 0 when bit13 = 0 and when BA load <~20. Used for enabling closed loop, must be = 0 for closed loop.

bit3 - 1 when front O2 signal is on rich side (>= 0.51V for open loop, varies with rear O2 voltage for closed loop)

bit4 - 1 when front O2 signal is on rich side (>= 0.51V)

bit5 - 1 when front O2 signal is on even richer side (>= 0.61V)

bit6 - used for enabling closed loop, must be = 1 for closed loop to be possible.

bit7 - 1 when bit3 = 1

bit8 - 1 when front O2 signal is on rich side (>= 0.51V for open loop, varies with rear O2 voltage for closed loop)

***

The changing state of the flags in MUT18 that you mentioned are not triggering the issue, but instead they are just an indicator of lean or rich conditions.

 

Haha, typo on my part. Binary starts at zero. Not trying to change industry standard.

I didn't necessarily think it was triggering the issue. Just that the issue and the signals were correlated and it would hopefully be SOMETHING to show a direction to head in. They are correlated, just likely a result and not a cause.

I threw the car is open loop (through FAA bit.4), thought I captured an amazing sample of the car running 22:1 for like 10 seconds solid and then like a light switch, going right back to normal. Get home, open the laptop and it didn't save the log at all... SON OF A *****!

Anyway, even in open loop MUT18 in 2-Byte is active as hell. Not nearly as active as in closed loop though. Does the routine that checks for rich and lean conditions still run when FAA bit.4 is set to 0? Seems odd if so.

 

Does the lean afr events happen in both open and closed loop?

 

Yes

Probably the best thing I could grab is a log of it cutting out fuel and then a log with the same load and RPM with a good AFR.

Only issue is, it is pretty intermittent and un predictable. I can get it to misfire probably 70% of the time when it's cold. But once it warms up, it's 50/50 on if it does it or not.

 

Next time you try to log this event, include AFRMAP in the log.

 

It's in that first log. Targets 14.7:1 to 13.8:1, no correlation to when the AFR changes.

 

AFRMAP is not shown in the plot you posted, but ok, that tells me that the lean issue is not being caused by something funny happening in the subroutine where AFRMAP is generated.

 

Brown line, middle of graph, labeled "Mapped AFR"?

 

I am going to retune with baro set to my ambient pressure to see the long term tuning effects.

As I'm starting fresh, I would like to tune on statistics, however, I want to limit it to only conditions where the main fuel map is used and only with the normal load. To do so, I want to filter the data so that any data using a load other than 898A is not used. I will also filter based on when IPW is below a 1.28ms and then when accel and decel are both 0.

To do this, it looks like I should be able to log MUT18 (8A27 1-Byte) and when ever bit 1(0x02) is active, I can filter that data out to limit this to 898A loads only for fuel?

Is this correct?

Also, would it be possible to get the "Sync Base FPW" patch that was in MrFred advanced fuel control thread?