|
jibberjive
|
 |
« Reply #45 on: November 06, 2012, 10:21:38 AM »
|
|
|
|
|
|
|
« Last Edit: April 12, 2013, 06:00:55 AM by jibberjive »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #46 on: November 06, 2012, 10:39:47 AM »
|
|
|
honestly, i think prj is pretty much the only one of us in a position to make real progress on it...
I'm definitely out of my depth for most of this right now, unless i spend a lot of time with a disassembler.
Actually, I think that there are at least a few people capable of contributing on here. I will be diving in shortly, I'm just wrapping up my current project. I think we need to be much more methodical about it though. I will start by identifying all of the functions related to pressure, work down to actual variables, and the follow the path of these variables. Looking into this a little while back, some deep google searching turned up a couple of supposed plug and play OEM sensors. I don't think hacking in some aftermarket sensor is the best option. |
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #47 on: November 06, 2012, 11:31:13 AM »
|
|
|
If i'm reading this right, even if we don't get a larger MAP, we can fix the ps_w limit problem this way?
Interesting, this question brought something up I didnt think about before. In short, yes to my understanding. But since ps_w is connected with the other pressure variables, the better approach would most likely be to scale the other pressure variables too(as prj also advocates). BUT, this rises the good question, since it is very common for the 2.7tt guys to underscale load. When underscaling load(scale MLHFM by x %?), ps_w is also scaled but not the other pressure variables it is connected with(pu_w, boost variables). If there is bad side effects by only scaling ps_w and not the other variables, it should surface when underscaling load, no? |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #48 on: November 06, 2012, 11:39:57 AM »
|
|
|
Bische: exactly. I was absolutely suggesting that.
I know the concept of underscaling load is anathema to many, but the fact is, it does work with some minor tweaks to get part/idle working right.
IMO underscaling KFKHFM and overscaling KFLF (as prj has suggested, albeit only at high load) does exactly this; the question is, can we just do it across the board? If so, underscaling ps_w across the board is probably ok too.
50% is probably too much, but certainly there is some ballpark where it will work.
|
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #49 on: November 06, 2012, 11:49:59 PM »
|
|
|
I think the best solution when in need to underscale load, is to do a complete ps_w/pu_w/boost scale as we discuss, and then downscale rl via KFURL to a desired level. This also lets you use any MAP sensor desired and control boost in closed loop up to 4bar.
I did not come as far as rewriting my tune to be completly downscaled yesterday, but I managed to find/define the maps I believe would be needed to scale. I think I can manage to rewrite my file tonight and flash it tomorrow and take some logs.
Anyone else currently working on this?
|
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #50 on: November 07, 2012, 12:52:03 PM »
|
|
|
Now finally I have scaled my file to the best of my knowledge, flashing it tomorrow morning to test it out. I ended up changing 18 maps/constants and I did a 50% scale, hopefully my tune now is capable of handling 5120mbar  I will write a clean version of my notes when I have spare time. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #51 on: November 07, 2012, 02:29:52 PM »
|
|
|
AWSOME
So, in theory, the only thing you should have to change for a different MAP is DSLGRAD?
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #52 on: November 07, 2012, 04:07:42 PM »
|
|
|
AWSOME
So, in theory, the only thing you should have to change for a different MAP is DSLGRAD? DSLGRAD and DSLOFS. Bische, keep in mind the list I gave was not complete. I am sure something was missing from it... But okay, let us know how you get on. I have an emulator 24/7 plugged into my car but I am just too busy right now... |
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #53 on: November 07, 2012, 08:13:07 PM »
|
|
|
DSLGRAD and DSLOFS.
Bische, keep in mind the list I gave was not complete. I am sure something was missing from it...
But okay, let us know how you get on.
I have an emulator 24/7 plugged into my car but I am just too busy right now...
Yes, I understand. I found some more in need to be scaled, KFDLULS and FRFLSDP for example. Im sure there is more stuff that will be floating up that needs to be changed, but we need to this started Then there is some stuff in %LDUVST/%DLDUV and possibly in %BGPLGU, I could not find my codeword for %BGPLGU. %BGMSZS is hard to follow at times, but I think I have got the maps/constants I need covered there. |
|
|
|
|
Logged
|
|
|
|
|
jibberjive
|
|
« Reply #54 on: November 07, 2012, 09:39:41 PM »
|
|
|
So I haven't dug into all of these functions yet, but just to make sure I'm understanding it correctly, in essence we are 're-scaling' all of the maps, to read correct numbers with regard to boost/load/etc above the current cap, as opposed to simply 'underscaling' one or two things to make the ECU think that it's running less load, etc, right? Or is this all just a more thorough 'underscaling' that will still not be the actual numbers?
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #55 on: November 07, 2012, 11:05:44 PM »
|
|
|
They're making the representation of all ps_ variables half as big, to give more headroom.
So, for example, the conversion factor for displaying ps_w is not 0.0390625, but 0.078125, such that 0xffff is 5120mBar rather than 2560mBar
|
|
|
|
|
Logged
|
|
|
|
|
jibberjive
|
|
« Reply #56 on: November 08, 2012, 01:32:39 AM »
|
|
|
So it'll have accurate readings for the values, just twice the max value (and half the resolution). Good, that's what I thought/was hoping, but the last couple of post made me want to double check.
|
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #57 on: November 08, 2012, 02:17:34 AM »
|
|
|
 Ps_w and boost is stock factor, ps_w2 has the factor doubled |
|
|
|
« Last Edit: November 08, 2012, 02:19:12 AM by Bische »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #58 on: November 08, 2012, 06:07:43 AM »
|
|
|
Awesome. Any side effects? Btw, if you want to make a screenshot, hit print screen  |
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #59 on: November 08, 2012, 10:43:10 AM »
|
|
|
Awesome.
Any side effects? Thanks prj I have just taken a quick look on the logs while in the car, but I noticed three things while driving it and from the quick gaze at the log: 1. When the car is cold, the warmup idle just goes to 1200rpm for 1 sec then down to warm idle RPM. But it runs 100% clean, which leads me to believe there is some map in need of scaling in the warmup idle function. 2. The negative gradient maps in %BGMSZS, PSSOLPGRD, PSSOLNGRD and PSSOLPF does indeed need to be scaled. I didnt think this would be noticeable at first, but I can tell just from driving the car these need to be scaled accordingly. 3. This is not really related to this hack, but I became aware that something is fishy with my FRLFSDP. I did scale the axis in this map -50%, and the car ran ~8% richer just as if I was adding 8% KRKTE. My axis definition must be wrong in this map, I need to go to the bottom with that one. Other than these minors I have yet to get any side effects, car runs great, boost control is still great. The biggest plus right now is that the stomache cringe when boosting is now gone, knowing the ECU is still in its reading range lol. 5120 hack FTW  Btw, if you want to make a screenshot, hit print screen  I was so excited I got this working and I had no internet in the car so i snapped a fast one with the phone |
|
|
|
|
Logged
|
|
|
|
|
