As some have stated already, the problem is that rl (8 bit) is being used instead or rl_w (16 bit).

I have a few solutions for this and I was going to tack one onto the end of the 5120 project.

I need to replace some capacitors in my laptop before I can make progress on anything as right now I only get a few minutes of use before it shuts down on me.

Ok, I just went and re-read through some of the older threads relating to the load limit (including the original 5120 thread), and I think I got a grasp on it.  I am sure many of you here can confirm (and you already did confirm half of my re-learning with the reply above).  So the hard load limit cap is two-fold:

1. The first cause of the hard limit is from where rlroh_w is converted to ps_w and then back to rl_w, as ps_w in its unmodified state is limited to 2560.  This limit on ps_w caps rl_w as well.  The 5120 mod relieves this limit on ps_w, and consequently relieves the limit on rl_w as well.

I haven't disassembled the files myself, so I'm just going off of what other people say, and I got the info regarding the load calculations from this post:  http://nefariousmotorsports.com/forum/index.php?topic=2747.msg26339#msg26339

This, however still leaves another cap on load.

2.  Like phila_dot said, the issue that remains with the load cap is with the maps that reference the rl variable instead of the rl_w variable (such as KFZW and KFKHFM in the 2.7t M-box), as the rl variable is 8 bit and thus limited to its max value.  So this doesn't necessarily have anything to do with the axes themselves being only 8 bit (as one could just rescale the 8-bit axes to read higher than 191 if they wanted), but rather is only concerning the fact that it is an 8-bit input variable for load.


Sorry tudor for the quick thread derail, just wanted to shore up my knowledge on the causes of the load cap, if someone wouldn't mind confirming that the above is correct.

Regarding the OP, that does make sense that underscaling the MAF would have those issues, and the subsequent maps would be reading completely different cells, if not compensated for.

 

Yeah, that's what I'm saying.  If you look at #1, I mention a cap at 2560 for ps_w, which translates into a cap of rl_w (which I suspected might be higher than the 191 caused by the 8 bit rl, so I didn't mention the value 191 explicitly in #1).  I did mention 191 above that though, so I'll rephrase that.  So there are those two limits, one which limits rl_w to some limit that I don't know because I haven't logged any value high enough to cap rl_w out, and one that limits rl to 191.  The first is corrected by the 5120 mod, and the second is fixed by going with a file that uses rl_w for all of its subsequent load-based calculations (like the RS4 k-box), rather than rl (like the m-box).  Correct?

...

Edit:  I think this might be a confusion of semantics.  You say rl is not used for 'calculations', and is only used for map lookups, but when I said 'subsequent calculations' above, I was considering (possibly using the wrong nomenclature) that using rl to look up a value in the surface of a 2-variable map was a 'calculation'.  Does that make things different, or am I still wrong? 

So, someone couldn't reference any load above 191 in the stock KFZW and KFKHFM maps on an M-box, independent of if the load axis was to be scaled to the moon, because rl is used as the input, and rl is capped, correct?  That one question should clear it all up for me.

191.25/.75 (factor)=255=FF

Can't just rescale the axis because anything higher is still FF/191.25. That's where a 16bit axis comes into play.

Yeah but it makes nada difference for vehicle running.
It's just that the highest column you can define is 191 and any load higher than 191 will run off of that column.
And load maxes at 210-220 anyway due to ps_w so this is not a problem, as you would not want to define a value in the column that is higher than 191 anyway.

This only becomes a problem when the 5120 hack comes into play to work around the ps_w limit and you start seeing higher loads.

rlroh_w -> ps_w -> rl_w