NefMoto

Any thoughts? rl_w went from 220 to 290 on the same tuned file, just with 5120. rlmx_w is still 220, but rl_w is about 100 higher. Car runs 2 points richer as well (which I assume is because of the inflated rl_w). I'm just getting started working my way through, and must be missing something.

Considering you only posted one log, it is going to be awful hard to figure out what changed.

My bad. Here's one before 5120.

Totally different requested boost, totally different WG profile, totally different actual boost (complete with chronic underboost), completely different MAF readings, completely different load.

What did you expect?

Also guessing totally different i limit, but you didn't log that.

They are in diff gears. I don't (yet) have one with it in the same gear. Only changes (I believe) between these two files is 5120 related.

I'm baffled as to what "problem" you are trying to solve here.

Maybe you should worry that requested boost isn't anywhere near actual first?

I was under the assumption not much would need to be changed when going 5120. Attached graph is of the file before going 5120. Request and actual look ok.

Even though charge pressure is lower, rl_w is through the roof after 5120. 5120 boost profile is a combination of running rich, higher gear, no imx trims yet, and timing because of the exaggerated load.

Guessing combination of IAT difference and one or more unscaled rfagr calculations that nobody has investigated yet...

I'd just tune around the differences.. otherwise you'll end up having to log the entire req load and load->boost conversion path to find the missing scaling.

I thought about that. My part trim went -10+ so I can bring krkte down to probably get it to where it was afr-wise, but I didn't want to do it that way. I'm convinced something is missing from the 5120. I also figured with all the 5120 talk on here, someone must have noticed the same (assuming my 5120 is correct).

I didn't but I confess I didn't do a apples to apples comparison on the same car with 5120 vs not 5120. I just tuned 5120 files every time from scratch more or less on each car.

If you really want to figure it out, i'd start by logging all of the req load path or the load to boost path and looking for differences.

I'd be glad to help if you manage to get good logs.

A big problem will be controlling for IAT and such, since that alone can move things around quite a bit.

Unfortunately, my car is still dead so I don't have a way to log for you

If/when I get it back I can try a 5120 conversion on my file and see what happens vs stock (i'm not currently running 5120 on my own car)

Thanks for your input, Nyet. I'm going to try and tune around it for now, and see how it goes. I saw in another thread someone mentioned using your "5120 base file" so I thought you had something out.

0A 51 to 85 28 at 0x50926.
At least I noticed that different between my RS6 5120 conversion and whatever public M-box 5120 file.
That's "10.13 [hPa/%]" multiplier on page 289 of FR.

Just throwing this out there are you using a definition file that is modified for 5120? That can throw values out of whack.

rl_w is supposed to stay the same.

agree,  when I switched on my MKIV, there was no diff in load.  The base file you are using just might not be 100%.

Thanks for the hint, nub. I didn't use a base 5120, rather used my tuned file (which I was happy with, but riding the map limit), and made all the changes myself based on what I've read on here. I did not have those values you mentioned changed in my file. Thanks also for verifying rl should not have changed, wasn't sure on that.

rl_w is still high after changing those values. I also wanted to add, changing those values nubcake suggested created a big dead spot when getting back on the gas after a shift. Maybe this can clue me in to where the issue is? I didn't notice these ASM changes in any of the other 5120 files I've seen posted on here (Nyet's and Britishturbo's). Going to go through the file again, to see if I can spot anything.

Double-check KFPRG/URL and asm divisions/multiplications.
Here's the abstract of my old 5120 cheat sheet. Expected result and var name. It could be partially inaccurate, but hopefully will be of some help.

EDIT: or just try the public 5120 file, possibly with that fix I mentioned. :P

half:	same:	double:
fvisrm_w	fho_w	psrlro_w
plgrus_w	fpvdkds_w	fupsrl_w
plsol	pspvds_w
plsol_w	pspvdb_w
pirg_w	pspvdk_w
pirgro_w	psspvdk_w
ps_w	vpsspls_w
psfg_w	vpsspu_w
pssol_w	fpvdkds
pu	pspu
pu_w	ftsr
pus_w	fbakl_w
pvdk	frhodkr_w
pvdk_w	psspvdkb_w
pvdkds	psspvdkd_w
pvdkds_w	vpssplg_w
pvdkdsl_w	fpvdkdsl_w
pvdks_w
pvdksf_w
pbr_w
pbrint_w
pdpld_w
plgru_w
plgruo_w
plgruso_w
plmaxa_w
psmp_w
psmx_w
psp_w
pspmx_w
pukor_w
pukorf_w
pumean_w
pvdkmx_w
pvdkr_w
dpus_w
pte_w
pterw_w

Thanks for the help, nubcake. Are these the public files you speak of?

http://nefariousmotorsports.com/forum/index.php?topic=3027.msg29815#msg29815

I've compared them to mine, and they are the same except for the values you change for different map sensors. I'm using a 4 bar.

Guys, please let me know if you find errors in that file!

Really, I'd super lots appreciate it.

Can someone say what maps need to be changed, and their values when using a 4 bar sensor (03K 906 051)? Also, are there any asm changes required?

DSLGRAD
DSLOFS
....

.kp I have -  DSLGRAD 0.015625*eprom
.kp you posted for the 5120 changes - DSLGRAD 0.031250*eprom

but DSLGRAD is also changed between the stock map, and 3 bar file. I thought maybe change the factor or the value, but not both.

?

From the Manifold air pressure:Rescale project

DSLGRAD      - Divide by 2
DSLOFS      - Divide by 2

but

DSLGRAD       (stock M box) 541
DSLGRAD (Nyet' 3 bar 5120) 329

DSLOFS (stock) -16.40
DSLOFS (Nyet 3 bar 5120) -31.75

Is this because he's using a 3 bar sensor in that file? If so, it doesn't seem like the math adds up. It's also late, and I'm exhausted.  :)

Then going by this, I get a different number. Do you use DSLGRAD calculated from the sensor (894.091) and then divide that by 2? Or just input DSLGRAD directly.

If you have the full kp (not the one in the thread linked above), input the calculated DSLGRAD directly IN THE 5120 FOLDER of that kp:

http://files.s4wiki.com/defs/8D0907551M-20130729.zip

Outside of that folder, the DSLGRAD should be half of that (there are two DSLGRADs/DSLOFSs maps in that kp. the xdf linked in the other post/thread above only has a few maps).

Thanks, Nyet. I don't see a 5120 folder in that .kp though?

I'm not sure if this will be any help to you guys but I've attached the .xdf I used to convert my 1.8t to 5120.

There's a folder 5120 with a full list of variables I changed with division/multiplication in the description, serves as a list if nothing else.

Hope it helps (apologies if I'm just cluttering).

To be sure about correct numbers in dslgrad I would set the values to stock (check factor), change them according to the map sensor and then divide by 2.
Also, I have found it to be very easy to change the wrong values if you work from hex. In a disassembled file you can see much better what you are doing, not all divisions are supposed to be changed. Don't know if you copied from hex or worked from a disassembled file, but its worth the check  :)
Here is my asm changes for a working 1.8t wideband file: (also tested on a narrowband ecu, works fine)

Thanks for the help, everybody. I'm going with DSLGRAD calculated from the spec sheet/wiki and dividing by 2. Should be able to test shortly. I've collected 4-5 "4 bar 5120" files on here and every one of them has different values for DSLGRAD and DSLOFS. :) I wonder if these other folks just end up tuning around it.

When referring to "tuning around it" I was speaking about the load/boost and boost/load oddities you were seeing, NOT something strange about DSLOFS/DSLGRAD, which should always be the same for a given map sensor.

I would prefer we get together and try to figure out what went wrong with those other files' DSLOFS/DSLGRAD..

Sorry, maybe I posted the wrong one.. I will dig around my laptop next time I get a chance.

No problem, thanks Nyet. I understand what you meant. Actually, after doing the 5120 the only thing that tipped me off, was the car was running 2 points richer than before (wideband installed). I didn't (knowingly) change anything fuel/ boost pid related, so logged it, and noticed rl_w, and here we are. Car felt/ drove the same except for being sluggish because rich. Wondering why the asm nub suggested makes it fall on it's face getting back on the gas after a gear change. I've flashed it back and forth trying it with all the other changes, and with the nub asm modified, always the same result.

try this..

Still no folder labeled "5120" in that .kp

Am I missing something?  ;D

yea ill have to check my laptop :(

maybe this one

Yes, It's there now. Thanks!

KFLDRQ2 and KFDLULS axis are missing in that xdf, are they not necessary?

and KFLDRQ2 table is divided by 2, is it correct?

I will take a look, time permitting. The issue is that in winols, you can edit the axis w/o a separate axis def, whereas tunerpro you cannot, i think?


It should be, yes, if you are talking about the values (not the axis)

Yep.  One of the biggest reasons to ditch tunerpro and use winols.

Some things I'm unsure about.

1. In post #414 of the 5120 thread, Nyet states

 * pus_w:

Two more divisions, one at 0x5193E another at 0x51978, 16 bit, change 0x0287 (647) to 0x050E (1294)

For the last 2 address' the bytes are reversed in the stock binary (0x8702, 0x0E05). Is this because they are 16bit? typo? Just making sure the changes are correct. I'm accustomed to address' being listed in the order they appear in the binary, but that means nothing. :)

2.I think bische? states again in the 5120 thread :

KFURL + KFPRG to tune your ps_w, KISRM to tune the ps_w I component. All of them needs to be halfed in a 5120 hack.

Yet in all the 5120 hacked files I've used for reference, KFURL is doubled. Seems there was some debate on these variables.

Can someone verify address and factors for 551M 0002
LDEIAP
LDEIAU
?

Replied in PM, but once again for the sake of completeness: doubling of KFURL is correct.
KISRM should be left untouched if the assembly hack I mentioned above is implemented. If not - you can get away by halving KISRM instead. Do only one of those!


C167 uses LoHi for word (16 bit) variables, you can't just look at two 8 bit values in hex and then combine them to make 16 bit, the order has to be reversed.

Thanks for the response, nub. It sounds like the hack is a better solution than KISRM? I'll at least try that today, and log AFR to see if the dead spot remains, and if so, why.

Should be essentially the same as one is getting multiplied by the other. Asm looks neater to me as I'm changing the "hpa constant". :)