Thanks all,

I tried another iteration of KFMIRL/KFMIOP where I increased the values at the top of the range in KFMIRL (and adjusted the axis and values in KFMIOP accordingly). If anything, this resulted in even more limitation in rlsol_w, but I can’t say for definite yet and I’m just guessing. I’ll need a few more logs before I can see any definite trend.


Definitely. I think this is the most pertinent thing to log now.

For those curious, this is how I interpreted the FR:

Section FU LDRLMX 8.101.0 Berechnung LDR Maximalfuellung rlmax describes how maps like LDPBN, KFTARX etc are summed together. So rather than pick through each individual map, look at the output of the whole section. If that’s not limiting, then the individual maps aren’t limiting either. The output of the whole section is plxs_w (which in turn leads to rlmax_w in FU BGRLMXS 7.10.0 Berechnung der Maximalen Sollfüllung)

Maps in LDRLMX 8.101.0
LDORXNHDR
FKPBKISTHD
KFLDHBN
LDPBN
LDORXN
KFFLLDE
KFFWLLDE
KFFLDEO
KFFSLDE
LDRXN
LDRXNZK
KFTARX
KFTARXZK
KFTARXB

Put simply, if rlmax_w isn’t limited, then all the above maps are OK.

Hi all,

I logged the input and output of KFMIRL and can confirm that the input is being capped (and so the output is correspondingly capped as well). It took quite a while to find the right things to log - I don't know what it's like on ME7, but on MED9 I found that KFMIRL is re-used in the assembly code for several different modes of operation (homogeneous, homogeneous-lean, homogeneous split, stratified injection, catalytic converter heating) and each mode has it's own variables for input and output that it uses to call KFMIRL with.

Anyway, it's homogeneous mode.

By luck more than anything, I managed to get a log that contains a WOT pull without the problem and another WOT pull with the problem. Both in the same trip down the road, just a couple of minutes apart. I honestly can't see what's different


Here you go. mifa_w, rlmax_w and rlmx_w are fine, but pssol_w suffers from correction on the second pull.

First pull - no correction





Second pull - pssol_w being limited

Aaargh, my mistake!

I got the the column names mixed up in my CSV files I was using for ECUxPlot  

It's still the same as yesterday. rlsol_w is being capped, rlmax_w is fine.

I've updated the post and graphs accordingly.

Thanks for spotting it

BTW - what is the relevance of mifa_w? Does it provide any clues?

The limiting is due to to EGT model.

Rick

you figure this out yet?? I'm having the same issueissue. found that mdgat is the model, but no idea how that's used to limit requested boost. found limiting torque, but wouldn't that be load?

Hi guys,

A puzzle and interesting answer.

I’ve been looking into the fuelling at the moment and working with these maps.

KFPRSOLHKS
KFPRSOLHMM
KFPRSOLHOM
KFPRSOLKH
KFPRSOSCH

KLPRMAX

Even though the rail maps (KFPRSOLxxx) have been increased a bit and the rail pressure limit (KLPRMAX ) increased as well, my specified rail pressure (prsoll_w) never seemed to rise to its full potential Here are two logs from the same drive, a few minutes apart:



Specified rail pressure is the green line. The first (solid lines in the plot) is a good one, specified rail pressure is reasonable and actual lambda follows requested lambda. The second (dotted lines in the plot) is not so good. Actual lambda struggles to keep up with specified lambda. Bu this time specified rail pressure was lower as well. Now I’m hardly an expert, but surely if specified rail pressure was higher, then actual rail pressure would be higher as well and then actual lambda may be able to keep up with specified lambda? So I started digging into specified rail pressure.

Months ago, when I first began, I built a spare ECU to use for all these mods. I didn't want to open my original ECU to BDM-read it, instead I read my original flash via ODB (obviously only the flash). I then combined the flash of my original ecu with the e2p from the ebay donor ECU, immo-off'd the flash and e2p and wrote them both to the spare ECU with BDM.

I checked the coding, but I never thought to do any adaptations...

Fast forward to now and I've learnt that all the adaptations  and other non-volatile variables, are stored in the e2p. I don't know why I didn't think about this before So I did all the adaptations (throttle body, fuel pump and intake manifold runner) described in the VCDS wiki - http://wiki.ross-tech.com/wiki/index.php/2.0l_TFSI_(AXX/BGB/BPJ/BPY/BWA) and  I also cleared the fault codes which resets the LTFT and STFT.

You can see the difference in the graph. The green line is the specified rail pressure (prsoll_w).



P.S. One of the coil packs died during the last run, so I need to fix that before any more fun. But's that's a story for another day  

well i think i figured out the limiting pressure deal for my car. i was doing my fueling through the BTS maps, and i guess that will somehow limit the requested boost. so i changed those back to stock, and have been adjusting the LAMFA map to try and stay out of the BTS via EGT. it seems to be working better, but at the higher rpm i think bts is still intervening. could just be the stock hpfp dip sending it into BTS, but idk.  i also changed a little in the I-limit map too.

What's your I-limit look like?