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.

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.

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.

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

Good to know Im not a complete idiot!

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

Told you it's not so easy.

DSUGRAD and DSUOFS should of course be halved.

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).