NefMoto

Hi, to get into the underscaled MAF stuff, I did some runs with only underscaled MAF on F-Box without changing anything else but undercaled MAF + adjust fueling like mentioned by prj in another posting. Just to learn from it step by step.

After a short log, I recognized the expected result on rl_w.

With stock MAF curve rl pretty quick hits 191,7 on VCDS so you get to the last column in KFZW.

With underscaled MAF rl stays much longer on lower values and does not hit 191,7 anymore. Maybe with more boost it will.

So the timing table runs totally off, because the real amount of air in cylinders is higher than the calculated load signal. So this will result in to much timing for the real load points if do not change the entire timing table. (remember stock file only MAF scale)

I wonder nobody ever mentioned the effects from downscaling MAF on ingintion maps - or am I missing something?

Are there more side effects?


 :-[

Why not scale the maf so max load is always right around 191? That way you're using the entire map, not just parts of it? There are degrees of underscaling, you can tailor it to your own requirements.

I know but if I modify the ecu with more boost and scale the MAF to a range of 0 - 191,7 the real rl will be f.e. 0-250.

So at rescaled rl 140 the real rl will be f.e. 191,7

So if I leave the KFZW/2 stock (only for example) I will get to much timing on mid range load areas.

Top rpm Timing at 140 load:
19,500
19,500
22,500
24,750
23,250

Top rpm Timing at 200 load:
6,000
8,250
10,500
11,250
9,750

So I get 23,250 deg at real load 200 instead of 9,750 cause ecu thinks it is only 140

I can see this behavior on VCDS because the ecu starts pulling timing via knock control with rescaled maf

So don't scale the MAF, and use 16 bit axes for ignition.

Now I'm confused...

If you are maxing out the MAF and underscale, even turning up the boost will not help... 5V is the max the MAF will "see"

this is clear..  the MAF is not maxed out, its just underscaled. Like to prevent to hit max rl_w. 

The question is not if it is right or wrong to do this, its only about understanding the relations.

the only question is - if somebody is underscaling his maf, does he only scale KFLF at the same time as mentioned:

http://nefariousmotorsports.com/forum/index.php?topic=2747.0 (http://nefariousmotorsports.com/forum/index.php?topic=2747.0) and on S4WIKI

because I see, it will harm correct timing by reading the wrong columns in KFZW/2 etc.

so there is a lot more to do - right?  cheers  ;)

You have to tune timing near the top of the load range anyway... if anything, underscaling near the max gives you a few more cells to play with.

Be advised, though, I ran into an odd problem with underscaling on one car (still dont know why)

http://nefariousmotorsports.com/forum/index.php?topic=3562.0title=

So, is the only way to be able to break the 191 rl_w limit and have a fully scaled MAF by doing the 5120 hack?  This is assuming that the car is hitting the limit, of course.

the 5120 limit is only good for ps_w.

to break the 191 rl limit you need RS4 or ME7.1.1

What are we talking in terms of the rs4 limits? I hear a lot of talk about a 16bit load axis in the m-box, but haven't seen it implemented.

Just curious.

Admittedly, I haven't delved much into the specifics of the 5120 mod yet.  So that in no way resolves the 191 rl_w cap then?  And if one were to make the load axes of the m-box 16bit, that still wouldn't resolve the 191 limit, would it?  Isn't the limit based on the variables, and not the axes?

rl_w is NOT limited to 181

Actually I should have known that, as all of the _w variables are 16 bit, right?  So what is the root of the 191 limit with the m-box then, as the axes of corresponding maps don't actually limit load, they will just use the highest value for anything above 191? I will have to review all of the 191 limit threads shortly, so excuse my ignorance if it's clearly worked out already in those threads.

It was my understanding that KFZW/2 had axes limited to 191. So you could not tune ignition timing with loads >191, and it would just use the value found in the last column of the table. Only ways to circumvent this is to use RS4 flash, or change the axes to 16bit.

by the way, I am talking about rs4 f-box

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.

There's no problem on that.

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.

 

There is no hard limit at 191.25% rl. If you had logged rl_w you'd know this, rl_w rises past rl that's stuck at 191.25 because it's a normed 8-bit value. rl_w does have a hard limit however, which is due to ps_w indeed.

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?

rl is NOT used for calculations! rl_w is always used.
The only thing that rl is used for in M-box is map lookups. In the K-box the map axes use rl_w as well on the important maps.

That's the only difference. This 191 rl thing is not a problem at all unless you use the 5120 hack, because load maxes out at 220 or so, so you don't want anything higher than 191 anyway on the map axes!

...

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.

The axis can't just be rescaled.

rl is hard limited to 191.25.

To convert to 16 bit, rl_w is used vice rl, 16 bit lookup routine is used, and a 16 bit axis must be added.

There is another way that I've worked out that will be better overall, but I'm not revealing that until the 5120 is done.

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.

So we are all just saying the same thing, I'm just wording it differently, but at least now I'm confident that my understanding is correct.  Thanks!

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.

how is ps_w calculated?

is it right from reading, that rl_w is just a calculated value and not a value given by the MAF?

rlroh_w -> ps_w -> rl_w

thats what I got from reading but I dont get the sense from page 993.

rlroh_w - rl_w /.../ --> ps_w

Well, look around a little bit more and understand how the model works.