Closed Loop Load Scale - Explanation and Issue

[articzap]

RB20 ECU on 11U0H rom. So first is the question, and how exactly are these tables used? Are they referenced when the fueling map is in a closed loop cell? If so, are they reaching out to previously learned values corresponding to this table? So if I'm right, it'd be an 8x8 self learned table?

The issue is the Closed Loop RPM Scale seems to be referencing the RPM as the value, and not the actual RPM, so when running it stays pegged in the last column, at least according to the highlighting of the cells upon watching the log playback. Only noticed it because I happened to have a log that the car died, and noticed it.

[Matt]

Short answer is we don't have the documentation to explain the tables. We decode and provide the tables for editing, but we obviously don't have the design documentation from Nissan to explain each one. This is the same with a lot of factory ECU remapping software.

What I can tell you is that the closed loop RPM/TP scales reference an area of memory where it stores the trims. So as STFT/LTFT adjust, it puts updates in this table based on the current RPM/TP and uses that for future reference. So if one area of this range is leaner, then it will be adjusted accordingly here

Normally these tables are 16x16 but in this vehicle they are 8x8. I think that is why the tracing is off on this model, so it may need a fix for display (but the accessing in the ECU will follow that you see in the column headings)

So that might explain the trace jump to the higher columns.

The table here one we are concerned with is the load scale, as that is referenced by TP. So where K is moved around and TP column references are changed, this is where we might adjust this table.

[articzap]

Perfect, thank you. I figured it was likely just a tracer issue and not an ECU issue.