NefMoto

Hi all, fairly new to the forums here, but have lurked for a couple years now. I have a big turbo 1.8t gti and have been tuning it with Maestro for almost 5 years now. Recently my ECU shit the bed and I'm finally biting the bullet on switching over to TunerPro/WinOLS demo. I've been working through a couple speed bumps to get flashed for the first time but I figured I would organize my thoughts here, and hopefully learn from any of the gurus around here.

I should have my ft232r blue flash cable next week, but in the mean time, I really want to slap a tune together, and have a plan of attack for when it arrives so I can drive my car again. Its been sitting for 6 months and I'm driving a Turdcel, I really miss the power haha. Anywho, just hoping somebody can confirm my thinking is correct.

So before anything, I will need to immo defeat or clone my old eeprom and using bootmode, flash it to my new ECU. I know Eurodyne files can't be flashed over with NefMoto, but i will still be able to rip my old 95040 from my Maestro ecu to get the immobilizer working on my new ECU, right? Second, my new ecu is a 032NL, old is a 032PL. Im hoping crossflashing with an 032HS file will not cause problems? I found huge .xdf/.kp file somewhere on here and none of the other ECUs I have found are as well defined as the HS.

So far, I have worked out how to add params to my xdf in TunerPro in order to edit the map axes, and have essentially put together what looks like a Stage 3 base tune from Eurodyne plus or minus a few things. I think I coded out my emissions stuff properly in the hex editor. I plan to flash and very carefully work my way up to a stable tune, but in the meantime, I also want to try to get a 5120 hack working for the HS.

Im choosing the HS because it is the best defined ECU I could find, and as I'm new to this software, I dont want to throw myself at too steep of a learning curve by reading and defining my own .bin. I have sifted through the s4wiki, Bische's thread, and a few other threads here, and have made edits to all the scalars, tables, and axes listed here:
http://s4wiki.com/wiki/Manifold_air_pressure:Rescale_project

There are quite a few that either don't exist on a 1.8t ecu, or aren't defined in my .kp or .xdf files. If anybody could steer me in the right direction that would be awesome! Here are the IDs in question:

FHOKH
KFDPVL
KMLTESG
DPDSVLU
DSUGRAD
DSUOFS
PUE
PUMN   (I do have UADPUMN. Is that the proper map?)
PUMX   (I do have UADPUMX. Is that the proper map?)
PVDKMN
ZDSU
PBKVVSTG
PUEBKV
NLDIAPU
FRLFSDP    (Might be improperly defined. My axis values are 2776.25|3166.88|3557.50|3948.13|4338.75|4729.38|0.00|390.63|781.25|1171.88|1562.50 and I would bet money that those values are not correct)


I dont need anybody to spoon feed me addresses or anything, but if anyone has done this before for a 1.8t, let me know if those tables exist on our ECUs, and if so, give me some direction on how to locate them. I will attach my 5120 file and my xdf, and for anyone who feels like helping, thanks in advance!



edit: wont let me upload the xdf file. Heres a link to the definitions I am using, however, the params for axes are not added in
http://nefariousmotorsports.com/forum/index.php?topic=4936.0title=

AFAIK you still need to effect a few changes to hardcoded values using IDAPro.

Interesting. Okay, I'll look into that.

ASM changes required:

pvdk_w
pus_w
fvpdkds
fho_w
frhodkr_w
SDLDSUA axis calculation

For the M file

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

See the 5120 folder:
http://files.s4wiki.com/defs/8D0907551M-20170411.kp
http://files.s4wiki.com/defs/8D0907551M-20170411.xdf

See the bottom of this list:
http://files.s4wiki.com/defs/8D0907551M-20170411.csv

I have updated the wiki page you referenced, which isn't really complete, it was a work in progress.

Thanks nyet! youre a legend man   ;D

Havent had a chance to try the ASM divisions in IDA pro, not even sure where to start with that haha.

For now, I have managed to build a bench harness to clone my old 95040 file and copy it to my new ECU, and also flashed my basic "Stage 3" tune. I'm getting 4 CELs right now. Two for my MAF, one for pressure drop between throttle and turbo, and one (p0441) for improper evap flow. I have all the emissions components coded out via ESKONF. Ive read a few other threads and people seem to steer everyone to ESKONF for disabling CEL related to emissions components. Are there other maps/bytes I should be looking at? Despite the codes, my car runs better than it ever did on Maestro, and Im looking forward to improving my tune even more

ESKONF values Im using:

AA FF 00 F3 FF FB FC

NONE of the 5120 changes will work unless you do ALL of the required ASM changes.


Forget about ESKONF until you fix the MAF problems.

MAF will be dealt with tonight. Considering the pressure drop code, I'm 90% sure the MAF code is due to a boost leak. Im not running my 5120 file as of yet. I want to get everything else running right before I start deviating that far from the factory ECU settings.

For now the 5120 is my side project and Im just making any edits I do on a file I flash to the car, and then also to my 5120 file.

Once I get boost regulated with n75 and figure out how to set up boost by gear I will transition to the 5120 file

So it's been a fun month and a half. Had to spend the majority of my free time replacing pads and rotors, doing a timing belt/water pump job, fabbing new intercooler pipes to fix my boost leak, and doing body work on my other project car, but I'm finally in a position where I can focus on tuning the VW again.

I am running into trouble getting datalogs to work. I have me7logger and the GUI set up properly AFAIK, but I'm getting a timeout error when trying to start logging. I've read that I might need to wire in a secondary/solitary K line wire, but I'm not sure how to go about it. For anybody who has had to do that before, do I just strip and splice the proper wires on the ECU/OBD plugs, or is it a temporary wire that is only connected while I'm taking logs? And could the K line really be my issue comsidering Maestro allowed me to take datalogs just fine?

You can run a direct line from your ecu to a obd plug.
Right now, designed by vw, you have some connector for the k-line where every device shares the obd plug.
so your dash, ecu, abs, climatronic and so on, everything with k-line is connected to your obd plug.

the goal is to have only the ecu on the connector.

OR

try to change the seetings in me7logger, start it with ignition on, if its running, start the engine afterwards and so on.

there are a lots of tricks to make it work. have a look into the according thread.

Can you not just code the ECU in properly rather than immo-ing off?

ECU has already been properly coded. 95040 was cloned from my original ECU and flashed to my new one.

And I've played with the settings in every combination I've been able to think of, hence my consideration of the K line wire. Just want to make sure I'm understanding this, because I'm a total newb when it comes to electronics; Do I need to bypass the old K line wire, or just run a direct line from ECU to OBD in parallel with the existing line?

Temporarily make a direct connection (with no T's) direct from the OBD port to the ecu. Some people makes relays, or use a toggle switch so they can go back and forth easily.

Wire the k-line direct to the OBD2 port. It will save you many headaches in the future. I wrote about how it did it in this post: http://nefariousmotorsports.com/forum/index.php?topic=6679.msg69866#msg69866

I expanded on it with a diagram a few posts later, but thanks to Photobucket I lost the image. I think I have a copy on a hard drive a 1000km away, so I'll draw another if you don't understand. But the principle is simple. You are using a double pole switch to either bypass the cluster and associated components or running it like stock. You cut two wires and connect all four ends as I describe.

I'll check my Bentley for pin numbers on the connectors, but the K-line on my car (02 Jetta) was grey with a white stripe. Pretty sure it went from the plenum by the ECU to the green plug on the cluster, and should be the same colour on the OBD2 connector...

You just made my headache go away. I'm terrible at designing electrical circuits so your explanation made everything much more clear. I was thinking I could get it done with a SPDT but apparently not. Thanks for sharing  ;D

Not a problem man. What year is your GTI?

I'm looking at my Bentley and for 2001/02 (like my Jetta) the K-line (grey/white wire 0.35 mm2) comes from the ECU to pin 1 on the orange T10 plug in the plenum (in the rain tray). It then goes from there to the green plug on the cluster (pin 5 of T32a). I cut it just before the green T32a connector.

On the other end it looks like pin 7 on the T16 OBD2 connector. Again I cut just before the connector. Four short pieces of wire to extend to your chosen switch location and you should be good...

Its the cluster that screws comms up, so you could even just bypass to the blue T32 (pin 25? Sorry my Bentley is a poor scan and hard to read) plug on the other side of the cluster if you want to do that. My car came with an aftermarket deck so I had no idea what wiring abortion lay within, so I chose to go direct to the OBD port.

Car is a 20th AE GTI (so 2003). I plan on cutting just shy of the plug on the OBD and ECU side of the factory harness just so I can be 100% positive that I'm not going to run into issues down the road


In other news, I started with IDA Pro today and will hopefully figure out how to get the ASM divisions done sometime in the next week or so. I couldn't get the beginning of the AutoIt script to work, so I deleted everything prior to the includes while I followed the instructions it was giving, setting up the split binary and memory layout by hand, and am currently letting the script analyze the file for me. Hopefully it will finish by the time I get off work and I can start peeking at functions. I'm starting with zero knowledge of how to even perform these edits so my plan is to compare the stock m box file to a hacked m box file and hopefully make the edits that way.

For clarification, how does the process play out? Do I use IDA Pro to find hex addresses of the necessary values, then change them with a hex editor? I've tried searching around these forums on how to do the ASM changes but haven't found anything, and I can't make much sense of it by reading other How To projects for IDA pro.

Okay, so I'm hoping I have this right...

As far as the ASM changes go, I have gone through the following process:

-Load .bin file into IDA pro following directions of AutoIt script.
-Set dpps and create segments for RAM iRAM etc.
-Run AutoIt script (analyze, then cleanup)
-Search for byte sequence "654D" returns 8 results, 3 of which have instructions "mov r(3/4), #654Dh".
-Search for byte sequence "287" returns 15 results, 5 of which have instructions "mov r2, #287h"  and 4 more have  instructions "mov r14, #287h".

 Looking at the CSV attached in nyet's post, there are 3 ASM changes necessary pertaining to a 654Dh/25933 value. These are pvdk_w in two locations, and frhodkr_w in a third location. My locations are different (understandably due to having a different ECU) than those listed in the CSV, but are located at 51930, 51AEE, and 5416E. Also according to the CSV, there are 5 necessary changes to values of 287h/647. Am I underthinking things by making the assumption that I need to change the 3 "mov r(3/4), #654Dh" results from 654D to 32A6, and the 5  "mov r2, #287h" results from 287 to 50E?

I've read posts about these changes being trivial to anyone who has been on these forums for longer than 6 months and should only take 20 minutes tops, so I hope I am thinking this through properly.. Also, I am stuck on the SDLDSUA axis calculation portion of the edits as well. I was planning to verify my intended changes by going through a modified M box .bin, but it took almost 4 hours just to run the AutoIt script so I figured I would ask here first before I spend those 4 hours  :P

You're on the right track.


HA! That is definitely ridiculous. I think most people with experience should be able to tune and make a map pack, but imo disassembly (and patching) is not trivial for anyone, no matter what anyone claims.


Kudos, you are doing just fine. Keep it up.

Just remember when you are ready to log, use IDA to find additional ram locations to log to confirm that your ASM changes are correct.

Okay guys, I THINK things are looking good.

There are 12 maps not defined in my .xdp/.kp files that are documented as necessary changes, however, I'm not sure if those maps are even available on my ECU. I plan to look into those when I get home from work tonight. Other than that, the only thing I think I am missing is the SDLDSUA ASM change. I dont know what to look for in reference to this in IDA, because the map isnt defined for me, and I dont know what bytes I should be looking for. Anyone with a 1.8t dealt with this before?

Im attaching my edited .bin and .xdf for anyone that wants to take a peek and let me know how things look so far

Anybody have feedback on that file I posted? I'm still waiting for my map sensor to get here from Germany but I'd like to have time to make any more edits if they're necessary.

Also, I'm having an issue with my WOT fueling. As per the s4 wiki, I have calculated proper TVUB and KRKTE for my injectors and fuel pressure, and at WOT I'm seeing stft from 1.1 to 1.2 in areas, but for the most part it holds steady at 1.15. My requested and actual AFR line up quite nicely still, but I would prefer to have a lower correction value considering I'm almost maxed out in a few areas.. I have scaled up my maf curve by 15% and see the same numbers at WOT. Scaled maf again and still see 1.15. I have verified my intake is leak free up to 45 psi (only running 15 at the moment) so what's the deal here?

Did you get the 5120 file running properly in the end?
I am also running a 1.8T BT, so am considering investing the time into the 5120 mod.

Never got it running right, but I also never bought a higher bar MAP sensor to use. Currently dealing with getting the car running properly and controlling boost via n75.

I am having two issues with the car currently:

First, I dont have cruise control in 6th gear. I believe I have properly set up NVQUOT, and I have verified that my soft coding is right via VCDS. Probably some issue with having a second hand ecu from a 5 speed car, but I dont know what do to remedy this. Cruise control works flawlessly in 1-5, I will log gangi tonight to verify whether or not the ECU is detecting that I am in 6th gear, but I doubt it will

Second, my WOT fueling is really messed up. I have fixed my intake leak mentioned earlier in the thread, fuel trims look good, and part throttle is mostly where it needs to be. Thats not to say I dont have the random +/- 15% correction showing up occasionally, but those will be ironed out after I figure out my WOT woes. My issue is that I am losing o2 corrections under full throttle conditions. I am not getting a large positive or negative deviation before losing corrections, it just goes from -6% STFT to losing correction, and targeting .75 lambda all the way from slightly after boost onset (~4000) to redline (7500). This is with the car running wastegate pressure of 10psi. All fuel maps in my current tune are set to request .82 lambda just to rule those out. I have verified my fuel pressure is good under boost, and using an MBC and steadily increasing boost while logging, I am not going lean or losing any pressure up to 30 pounds of boost (base pressure of 56psi, total rail pressure was ~85psi). Not sure what to take away from that. Hardware seems good, only guess I can throw out would be a bad o2, but this one only has about 3k miles on it. Will post logs later?

And while the .75 lambda target thing is my main priority, I cant get n75 to accurately control boost pressure. Does an aftermarket EWG require substantial tuning of the PID? Because at the moment, I have LDRXN set to cap load at 200. My first pull of every drive I see 85% WGDC and boost will ramp up and exceed 30psi, while WGDC settles down to 60-70%. Every subsequent WOT run, WGDC is locket at 5% (too little to even produce extra charge pressure). Do I need to seriously tweak my PID tables considering my turbo/wastegate setup has deviated so far from stock?

Ive been reading like crazy for the past 3 weeks and trying small edits here and there to no avail so any pointers would be appreciated.

The reason you dont have cruise in 6th gear is because the ecu software is missing those tables if the ecu is from a 5 speed car.I ran into this with some audi a4 ecus.Luckily  a good portion of ecus that were 5 speed can be reflashed with 6 speed ecu software.I believe audi had a update for misfires for those cars and all of them got the 6 speed ecu software.

I did some logging last night and confirmed that the ECU does in fact accurately calculate which gear I'm in, including 6th, from the NVQUOT values I calculated.


If this is accurate then I may be screwed. Does anybody have a well defined 6 speed box .xdf? It seems

I smell some bullshit right there.
Never seen ME7 where NVQUOT didn't go to gear 6.

I can’t say for sure just talking based on my experience.It is possible the boundary for that gear needs to be logged a set correctly.Should be changing or looking at the gear ratio.Im sure it needs to be changed.


Sent from my iPhone using Tapatalk

If you want to give the attached one a try, my cruise control works in all gears and I am currently running 1.8T BT setup as well. All maps I needed so far are in the attached .xdf. I based the .xdf on a file I found on these forums originally but I have added ALOT of variables. I think this should crossflash onto your ECU.
The attached .ols was also found on these forums, it is not exactly the same as the binary but I have managed to find most of the tables I need from it via WinOLS.

If you do give this a try, let me know, maybe we can work on the 5120 hack together then.

Wasn't able to attached .ols file to previous post, but I used the Audi TT 1.8T BAM 225 PS 8N0 906 018 CB.OLS from here:
http://nefariousmotorsports.com/forum/index.php?topic=62.15

Your inexperience rather. Every ME7 has all the NVQUOT maps to run 6 speed gearbox. Yes, they are not calibrated on 5speed only cars - why should they be?
But be careful with absolute claims like "missing maps".

Why not set them correctly and call it a day?

As mentioned by Nyet it should be as easy as logging and setting the boundary for 6th gear or a copy form a file that has it set for 6th gear already.

Except the boundaries are already set properly, i have logged gangi and verified that the ECU is accurately calculating the current gear selection. I still have no cruise control in 6th gear.

BTW, I think I got my 1.8T running with 5120 hack. I used BOSCH 0281006059 (03K906051) sensor. Done some limited testing already and so far looks good!
There is a couple of 1.8T 5120 xdfs floating around but none of them covered the issue I was seeing; my throttle plate was not opening to 100% on WOT.
Turns out there is a map called KFPLGUB which is used instead of ambient pressure for calculating pressure ratio across the throttle plate (used in throttle maps) if CWPLGU = 0.
Apparently on most cars CWPLGU = 1, hence this map is not mentioned in the 5120 hack threads, but on mine this was set to 0.
I think the solution is to either divide both the axis and the table by 2 or change  CWPLGU to 1. I've done both just to be safe and now the throttle behaves correctly.

Unfortunately I cannot upload the xdf as the forum tells me that the site storage is full! If you'd like to have a look send me a PM.

Had some requests for the .xdf, so here is a link for anyone interested - for 8N0906018H ECU but should be similar to other 1.8T.
https://drive.google.com/file/d/1WnXTQVyaWEv_LiEi_onZVl5iC6I-nMp9/view?usp=sharing

Regarding cruise control issues, last week I bought a spare ECU (after an unfortunate misflash 200 miles away from home and no MPPS cable to perform boot mode flash), and to save some cash I though why not give the ME7.5 off an 2L N/A a go... It was about 1/2 price of a 1.8T ME7.5 ECU.
Anyway, it crossflashed with no issues and at first I didn't get any issues (even N75 worked correctly), however, after a few days I noticed a few things:
- Cruise control did not work at all
- Lamba control was stuck at 1
Reverting back to the first ECU (with exactly the same binary) has fixed these issues.

So if you're still having cruise control issues, I would suggest trying a different ECU.

So considering the ECU in the car is a 1.8t ECU and the car has a 1.8t engine, what ECU would work for me?

I believe the current ECU is a 1.8t Jetta automatic, and it is installed in a 20th AE GTI. Do I need to match my original ECU code, and remake a new definition file from scratch to go along with it as opposed to cross flashing an HS file onto the current or original ECU? I'm trying to avoid investing more than its worth and to be honest, the $300-$600 that the 20th ECU goes for doesn't seem worth the money just for a cruise control issue.

I would love to use my stock ECU but an O2 sensor short fried my throttle drivers or something and that box is toast now, hence me abandoning Maestro and learning to use Tunerpro instead. Either way, I just moved across the country and left the VW at my parents house, so I won't be able to test anything until I fly back for the car in July.

It just seems odd that it would be a hardware issue or something to do with the chipset in the ECU considering my correspondence with Chris Tapp, in which he told me ANY 1.8t ECU would work with my car. I feel that there is something obvious I am overlooking that is preventing cruise control from being active in 6th.

I have already confirmed that NVQUOT is set properly and datalogs show gangi accurately displayed for all gears. Soft coding is accurate for my transmission, and cruise works in all gears but 6th. It seems like there has to be a map somewhere for setting cruise control active for each gear, but I have yet to find one whilst digging through the FR. Then again, I have dug relentlessly through the forums here and various other resources online, and have yet to find something that works. Perhaps you're right and I just need to fork over the money for an LP box and learn to make a definition file from scratch

Its been a while since I posted here, but I believe I'm finally starting to wrap my head around the whole 5120 hack.

I just finished digging through a few completely defined files in winOLS to find the maps I was missing, defining them in my tunerpro .xdf, and making all of the changes necessary to run the file. The current owner of my car will be testing it out tomorrow, and if it all runs okay, I will be posting my xdf here tomorrow, as well as an excellent excel spreadsheet I used (didnt create)  that listed all the necessary changes, as well as their locations in the .bin file. Im planning on making some changes to the xdf parameters, I want to get a couple things clear just to make sure I'm having sane thoughts first...


When performing the hack we are essentially redefining the meaningful value that corresponds with a given hex value.
For instance, DSLGRAD is the scalar for hPa/volt at the MAP sensor. On a completed 5120 file running a 4 bar MAP, the final value of DSLGRAD is ~435hPa/V compared to a stock value of 541hPa/V. DSLGRAD All maps and scalars in a 5120 file intuitively look wrong when comparing values to a stock file.

My question is this, does it make sense to take the change made in the hex values, and make the opposite change to the conversion factor in the xdf file? I'm thinking that it would make everything much more readable when looking at a tune. In theory, this is the proper way to tackle it. The value of hPa/V doesnt decrease when installing a larger sensor, we have just put the hex values on a different scale, and the map axes and outputs should reflect the changes we made to that scale.

Lets look at the math-
Stock MAP resolution(ie the conversion factor) = 10mbar/hex with a max of 2550mbar because MAP value is stored as an 8bit value (FF/255 max)

We are taking the stock resolution and halving it by making the resolution 20mbar/hex for a max value of 5120mbar. The original hex value on this new scale would now be double its original value, so that hex value is divided by 2 (which is the basis of the whole 5120 hack).  Lets pick a random hex value and work through it.

On the original scale
B8h =184d*10mbar= 1840mbar

Resolution is doubled so
B8h= 184d*20mbar= 3680mbar

Same sensor voltage or calculated hex from a map = double the actual value, so divide that hex value by 2 and the proper value is produced.
B8h->5Ch = 92d*20mbar= 1840mbar

The problem is that the conversion factor isnt hex coded into the maps we change when we are doing the edits, thats all stored in the definition file. So to create the right output value from the now halved/doubled hex value, we should compensate by performing the opposite mathematical operation on the matching conversion factor.

At least thats how it looks to me. Somebody please correct me if Im wrong

yes, the xdf should have the alternate scaling (2x or 1/2).

If you look at the S4 Mbox kp/xdf I made it has both 5120 and stock versions of each affected map.

Same with ME7Logger .ecu files.

Good to know Im not a complete idiot! ;D

I dug through a log of the first drive with the 5120 file and things look to be off. rl_w doesnt exactly follow rlsol_w under WOT, they track fine until ~125, and then rl_w shoots to a max of 234, while rlsol_w maxes at 136. pu_w is at 250, and trims are also hugely negative, with a .84 correction factor under WOT, and losing corrections at points as well. On the plus side, ps_w doesnt cap and limit calculated load, so this is the first time I've seen rl_w > 215.

As far as the rich condition, would pu_w cause this, and to get pu_w back to normal, do I need to undo the change of DSUGRAD/2? For now, I have changed DSUGRAD back to stock but if this is wrong, let me know.

Theres also a 287 value I found in IDA (0x62834) that wasnt on the excel spreadsheet. I left it unchanged but I'm not sure if thats right?

Im attaching a few files, including my .bin/xdf, the excel spreadsheet of changes that were made, and the log of this file on the car.
Excuse the subpar log, the driver had his kids in the car, and I told him to take it easy until I verified that the car was running okay.

Edit:
The excel spreadsheet is also color coded as follows:
Green= maps/scalar edits that I have defined in tunerpro
Cyan= values that were changed using a hex editor
Blue= calculated values for bosch 4bar map sensor
Yellow= stock values

Second update:

Resetting DSUGRAD to stock has fixed the low pu_w reading, and using the standard conversion values in ME7Logger shows requested load at a reasonable value now. Still not sure if DSUGRAD should be scaled down and my problem lies elsewhere, car still has huge negative LTFT. Digging through FR and the above spreadsheet to see if I can find something. I only see 2 things related to fueling: FRLFSDP, the axis of which I divided by 2, and PSAPES, which I have also divided by 2. My map values for FRLFSDP are all set to 1.01581 from the factory so I have my doubts that this would cause any issues, and on top of that, the map appears to be a correction factor applied for returnless fuel systems, which doesnt even apply to this car in the first place.

Told you it's not so easy.

DSUGRAD and DSUOFS should of course be halved.

I kinda figured it wouldnt be so simple. Oh well. Ill just keep reading my daily verses from the ME7 bible and it will all make sense eventually. I appreciate the tip and I respect the hell out of you and everyone else who got this working the first time around.

For now I'm still trying to figure out how to efficiently use IDA to locate variables/define functions. I did notice in my disassembly that two of the ASM division hex addresses appear to have their function labels swapped in that spreadsheet I have attached. The two in question are the %BGMSZS locations. Im hoping to put at least a small dent into further disassembling the HS.bin tomorrow and have a better running tune by the weekend. I know its not an easy task, especially considering this is my first time ever playing with hex code/disassembly, as well as the only time I've ever had to actually read the FR, but considering that you and Bische and all the others here have already done all the hard work, I just need to figure out how to translate that to my application. I think that should be manageable  ;D


EDIT: I found a problem. I accidentally scaled NLDIAPU map instead of the pressure axis. Hopefully that, and ignoring my spreadsheet and making the 1013 divisions I found in IDA will do something about the rich condition

Happy to report that my issue is solved. It was caused by NDLIAPU map being scaled instead of the axis. Fueling was off due to the maf being scaled incorrectly. Pre-5120 my scale was working fine because load froze at 210 and I had made edits to KFKHFM to deal with part throttle. Setting KFKHFM flat and rescaling the MAF/lowering KRKTE solved my issue. Will post logs after I get the PID set up (currently running fixed duty cycle).

Small update:

Load calculations are working properly, boost is registering properly, but I'm getting some really weird behavior with the fueling.

I just double checked, and both before and after the 5120 hack, ps_w > pvdkds_w on WOT pulls. I have scaled MLHFM down significantly (incrementally up to -25%) and I'm still seeing ps_w exceed actual boost by about 700mbar.

Fueling looks good on the stock map, but I'm seeing lean spikes randomly appearing in low load situations. At times I'm seeing lambda reading of 1.5 for about 1/4 of a second and then things return to normal.

I will post a log for anyone thats interested in taking a look (note that the WOT corrections have been addressed)

700 mbar is insanely huge. That is a bad sign.

Any idea what could cause that? Scaling the MAF curve has had no effect whatsoever on ps_w on standard and 5120 files

Forgot that the forum isnt letting me attach .csv files.

Here is a .zip with the current tune and a datalog.

Note the MAF scaling used for an audi v8 MAF and also the ps_w/pvdkds_w deviation

Is your krkte near what you'd expect it to be?

If not, your MAF scaling is completely wrong still.

KRKTE was calculated at .030xx and is at .027xx in the attached file.

Fuel pressure is 50psi measured with a gauge using a 3.5bar FPR


My tuning philosophy would be to use the calculated KRKTE/TVUB values and see where things are at, then scale MLHM to get WOT fueling as close as possible. However, doing this on either a stock or 5120 file produces the issue with ps_w you can see in the above log.

Scaling MLHFM down as per the wiki seems to be the go to solution for ps_w>pvdkds_w. Should I be looking at KFURL/KFPRG instead?

It does't make much sense.. you shouldn't have to touch either :/ I have no way of explaining what you are seeing, unless your maf is hugely overscaled and you have a large boost leak.

The above log has the stock MLHFM from a 4.2L file and given that it will read slightly too high because of the filter location in relation to the sensor, it is probably reading a bit higher than actual. I just verified that there were no boost leaks, but the silicone hose on the turbo inlet was a bit loose.  Same issues as before in regards to both ps_w and lean spiking. I'm running out of ideas here and its difficult to do any troubleshooting because the car is 1000 miles away
 

Hello Poody,

I was reading a lot about 5120 hack last week and came across your post. I'm running HS file as well and trying to learn 5120 hack as I have upgraded to Big Turbo.
It would be nice to hear about your 5120 progress and the reason of rich running. Was that 5120 related or some other issue?

Regards,

Figured I would this just because there were unanswered questions and it may help somebody in the future.

Issues with ps_w were fixed by playing with the VE model. I had to scale KFURL mostly, and a tiny bit of changes to KFPRG at idle. From my understanding, KFURL is part of the calculation that the ECU does when calculating for fueling. Its output is a scaling factor using inputs of differential manifold pressure (MAP - ambient) and RPM. It was scaled roughly to match the % difference in airflow at a given pressure for the new turbo vs stock turbo. Scaling was heavier in the higher RPM regions due to the low efficiency of the k03. I then used my histogram tracer tool and used (pvdkds_w - ps_w)/pvdkds_w as a scaling factor and logged those variables along with RPM to further refine the scaling. ps_w came down nicely, and follows pvdkds_w nicely. It isn't perfect, and ps_w is sometimes up to 200mbar in excess of pvdkds_w but it is much better than before, and fueling looks good up to 35psi on the 5120 hack.

None of that makes sense. You'd have been better served to properly calibrate MLHFM and KFKHFM. KFURL DOES NOT DEPEND ON TURBO.

And had normal calibration of the MAF scale and its correction map worked properly or made any difference in logged values, thats where I would have quit. But it made zero difference on ps_w with MASSIVE changes. Fuel pressure was measured with multiple gauges, KRKTE was calculated properly, and scaling MLHFM down incrementally to under 1400kg/hr @ 5v (~2000kg/hr stock) made zero and I mean ZERO difference to ps_w. The only change I saw from scaling the maf curve, or introducing corrections to KFKHFM was leaner WBO2 measurements/higher lambda sensor correction. This was on a standard tune as well as a 5120 tune. Huge excess in ps_w on every single log I took. The first tune with KFURL alteration of about 15% brought ps_w into the realm of reality and fixed most of the WOT fueling issues. From there, the stock 4.2 MLHFM and a few passes over KFKHFM took care of the rest.

As stated, it is imperfect, but leaps and bounds closer than it has been since I began this project from a stock base file on an already complete build. I know this isn't the first time you have addressed the "You shouldn't have to touch KFURL/KFPRG" topic. I've seen you make that claim a couple of times in a couple off threads, but from everything I can tell, it seemed to be necessary in my case for whatever reason. Something was very wrong with the ps_w calculation and it wasn't 5120 related. This is the only thing that made a difference   :-\

That said, I always try to do things the right way. I made every effort to correct things the way they are typically handled and using maps the way they are intended to be used (except for FKKVS  ;D). If I'm somehow overlooking something or there was a better way to accomplish the same task, I'm open to suggestions. The only other thing I could think of would be a hardware difference between the original fried ECU and its replacement

I honestly can't explain what you are seeing, since ps_w depends on MAF readings :(

MAF changing w/o ps_w changing doesn't seem possible to me, AND goes against everything i've seen, since maf underscaling is commonly used to keep ps_w artificially low