Pages: 1 2 [3] 4
Author Topic: 1.8t BT 5120 hack  (Read 37060 times)
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #30 on: November 13, 2017, 01:22:57 PM »

It is possible the boundary for that gear needs to be logged a set correctly.

Why not set them correctly and call it a day?
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
EuroXs4
Full Member
***

Karma: +15/-31
Offline Offline

Posts: 209


« Reply #31 on: November 13, 2017, 04:22:50 PM »

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.
Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #32 on: November 19, 2017, 09:23:47 PM »

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.
Logged
BoobieTrap
Full Member
***

Karma: +3/-0
Offline Offline

Posts: 74


« Reply #33 on: November 29, 2017, 03:42:43 PM »

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.
Logged
BoobieTrap
Full Member
***

Karma: +3/-0
Offline Offline

Posts: 74


« Reply #34 on: December 04, 2017, 06:40:52 AM »

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
Logged
BoobieTrap
Full Member
***

Karma: +3/-0
Offline Offline

Posts: 74


« Reply #35 on: December 18, 2017, 11:37:20 AM »

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.
Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #36 on: January 24, 2018, 12:06:58 AM »

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
Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #37 on: June 02, 2018, 02:36:18 AM »

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
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #38 on: June 02, 2018, 02:31:05 PM »

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

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #39 on: June 03, 2018, 11:55:10 PM »

Good to know Im not a complete idiot! Grin

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
« Last Edit: June 04, 2018, 11:56:05 AM by Poody » Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #40 on: June 04, 2018, 12:33:14 PM »

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.
« Last Edit: June 04, 2018, 12:47:23 PM by Poody » Logged
prj
Hero Member
*****

Karma: +905/-420
Offline Offline

Posts: 5790


« Reply #41 on: June 04, 2018, 01:38:14 PM »

Told you it's not so easy.

DSUGRAD and DSUOFS should of course be halved.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #42 on: June 04, 2018, 09:48:54 PM »

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  Grin


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
« Last Edit: June 05, 2018, 12:27:42 AM by Poody » Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #43 on: June 05, 2018, 06:14:55 PM »

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).
Logged
Poody
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 47


« Reply #44 on: July 28, 2018, 01:00:57 PM »

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)
Logged
Pages: 1 2 [3] 4
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 17 queries. (Pretty URLs adds 0s, 0q)