Pages: 1 ... 18 19 [20] 21 22 ... 37
Author Topic: The 5120 hack - Running up to 5bar absolute pressure on ME7.x  (Read 334117 times)
phila_dot
Hero Member
*****

Karma: +173/-11
Offline Offline

Posts: 1709


« Reply #285 on: June 17, 2013, 04:19:56 PM »

I don't think IOP or IRL will help. It would be evident in rlsol.

Like prj said, the answer's in FUEDK.
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #286 on: July 17, 2013, 08:10:30 AM »

Anybody has pre 5120 hack log showing PSSOL_W values?

What are they showing at idle/low load, is it at/over 1000mbar or does it is below 1000mbar anywhere?

I am still having weird issues with part throttle where car goes into palpitations mode and the pssol_w sticks out having values under 1000mbar, it is about 370-400mbar at idle and 700-800 in the area where engine starts jerking at around 0-1psi where the  pvdks_w shows positive small pressure at throttle.  In ME7 logger, I have the conversion set to x 0.0781250 like any other 5120 hack pressure variables from stock x 0.0390625.

I don't think it is me7 logger conversion though as during high-part and WOT the pressures more or less match.

I am just wondering, provided the logger shows true value of pssol_w, if there is something missing in 5120 changes that screws up pssol_w and confuses the hell out of the car.

Thanks in advance for suggestions.
Logged
Bische
Sr. Member
****

Karma: +25/-4
Offline Offline

Posts: 397



WWW
« Reply #287 on: July 19, 2013, 03:44:10 AM »

pssol_w is requested manifold pressure.

Im going to give some hints as I havent seen this up for discussion yet: Put KISRM back to stock, it has nothing to do with scaling ps_w, it is just an integrator. It is there to tune the response of ps_w vs. airflow.

All scaling to ps_w is done in KFURL, both down and back up. KFURL along with KFPRG is imo the two most important maps as they are stating the engines VE for the fueling, throttle control and boost control.

« Last Edit: July 19, 2013, 03:46:41 AM by Bische » Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #288 on: July 19, 2013, 08:04:50 AM »

pssol_w is requested manifold pressure.

Im going to give some hints as I havent seen this up for discussion yet: Put KISRM back to stock, it has nothing to do with scaling ps_w, it is just an integrator. It is there to tune the response of ps_w vs. airflow.

All scaling to ps_w is done in KFURL, both down and back up. KFURL along with KFPRG is imo the two most important maps as they are stating the engines VE for the fueling, throttle control and boost control.



KISRM is used to calculate fvisrm_w which then is used as multiplier to obtain ps_w so I think that not scaling KISRM will make ps_w completely off, 2x as large as it should be?
Logged
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035


« Reply #289 on: July 19, 2013, 08:11:14 AM »

KISRM is used to calculate fvisrm_w which then is used as multiplier to obtain ps_w so I think that not scaling KISRM will make ps_w completely off, 2x as large as it should be?

Correct.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Bische
Sr. Member
****

Karma: +25/-4
Offline Offline

Posts: 397



WWW
« Reply #290 on: July 19, 2013, 08:26:45 AM »

Correct.

Wrong. Look at the algorithm.
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #291 on: July 19, 2013, 08:55:56 AM »

Wrong. Look at the algorithm.

Please explain... I am not seeing where that is wrong.... unless the assembly code does things differently which I would not know about Smiley :

Logged
Bische
Sr. Member
****

Karma: +25/-4
Offline Offline

Posts: 397



WWW
« Reply #292 on: July 19, 2013, 09:17:29 AM »

Please explain... I am not seeing where that is wrong.... unless the assembly code does things differently which I would not know about Smiley :



The answer is right there in your first pic, it is an recursion where rlroh_w is always subtracted by rl_w and turns the KISRM mulu into its role as an integrator.

The KFURL/KFPRG calcs is by far the most brainmelting section to get a grasp of.
Logged
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035


« Reply #293 on: July 19, 2013, 10:33:06 AM »

Wrong. Look at the algorithm.

So in your opinion, which variable do you change to scale ps_w?

There is a 1013 multiplication in fvisrm_w, but whether you scale this multiplication OR you scale KISRM makes no difference per algorithm.
« Last Edit: July 19, 2013, 10:36:08 AM by prj » Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #294 on: July 19, 2013, 12:27:08 PM »

On a side note:

I noticed that supplied converted value of KISRM was wrong due to not enough decimal points defined in XDF and tuner pro rounding up stuff based on number of decimal places displayed (lol on that one...). Original M-box 0.122513, bin 0.059998, should be 0.061249 (closest to prefect value). The difference was 2%, not a huge one but it was there.

I am still awaiting the outcome of KISRM discussion though.
Logged
Bische
Sr. Member
****

Karma: +25/-4
Offline Offline

Posts: 397



WWW
« Reply #295 on: July 19, 2013, 01:35:15 PM »

So in your opinion, which variable do you change to scale ps_w?

There is a 1013 multiplication in fvisrm_w, but whether you scale this multiplication OR you scale KISRM makes no difference per algorithm.

KFURL with the offset of KFPRG. The mulu in fvisrm_w is 10.13, which saves 2 decimals in the final compution/sync, likely to stay inside 8bit limitation and/or give more granularity to KISRM.
« Last Edit: July 19, 2013, 01:46:07 PM by Bische » Logged
phila_dot
Hero Member
*****

Karma: +173/-11
Offline Offline

Posts: 1709


« Reply #296 on: July 19, 2013, 02:58:43 PM »

Just checked and I didn't touch KISRM either.
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #297 on: July 19, 2013, 04:57:34 PM »

Ok then, I will revert to stock and see what is going on with the changes.
Logged
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035


« Reply #298 on: July 20, 2013, 12:18:22 AM »

KFURL with the offset of KFPRG. The mulu in fvisrm_w is 10.13, which saves 2 decimals in the final compution/sync, likely to stay inside 8bit limitation and/or give more granularity to KISRM.

Except that KFURL has no effect whatsoever on ps_w and KFPRG is just an addition, which is added AFTER ps_w gets calculated.

So, what do you modify to scale ps_w?

Also, KISRM is 16 bit, and ftsr is movbz'd to a word anyway. So the KISRM by ftsr mult is also 16 bit, and the 10.13 mult is 16 bit as well.
No, you are not gaining any useful precision whatsoever.
« Last Edit: July 20, 2013, 12:25:32 AM by prj » Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Bische
Sr. Member
****

Karma: +25/-4
Offline Offline

Posts: 397



WWW
« Reply #299 on: July 20, 2013, 01:36:04 AM »

Except that KFURL has no effect whatsoever on ps_w and KFPRG is just an addition, which is added AFTER ps_w gets calculated.

So, what do you modify to scale ps_w?

Also, KISRM is 16 bit, and ftsr is movbz'd to a word anyway. So the KISRM by ftsr mult is also 16 bit, and the 10.13 mult is 16 bit as well.
No, you are not gaining any useful precision whatsoever.

Yes it does really put the shape on ps_w, it is the map to tune ps_w(and requested, pssol_w). As I said, this algo is really hard to get a grasp of, but once you do youll be saying "oh shit" to yourself. Just make a 10% change to cell affecting idle and slap it your RS4 and tell me what results it had.

I know KISRM and ftsr is words, but you need to look further. Where actual load rl_w is extracted, it is also calculated in 8bit as rl which is our imfamous big game variable.
Logged
Pages: 1 ... 18 19 [20] 21 22 ... 37
  Print  
 
Jump to:  

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