Announcement

Collapse
No announcement yet.

A quick and easy way to street tune your CSL conversion for drivability.

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • karter16
    replied
    Originally posted by heinzboehmer View Post

    Hell yeah, thank you!

    I just have one dumb question that came to mind. The y axis on the VE table for CSL FW is AQ_REL_ALPHA_N and not AQ_REL, right?
    Yessir

    Line 14 (and line 17 for the warm-up table).

    Click image for larger version

Name:	Screenshot 2025-06-11 at 7.19.17 PM.png
Views:	111
Size:	84.5 KB
ID:	308018

    And here's the evidence (lines 38 to 43) that aq_rel_alpha_n is aq_rel modified by aq_rel_alpha_n_fakt (which in turn is lookup based on RPM from kf_aq_rel_alpha_n_fakt table)

    Click image for larger version

Name:	Screenshot 2025-06-11 at 7.21.37 PM.png
Views:	96
Size:	145.5 KB
ID:	308019

    Leave a comment:


  • heinzboehmer
    replied
    Originally posted by karter16 View Post
    Okay - I spun up some google sheets to handle the conversion of AQ_REL to AQ_REL_ALPHA_N in TestO logfiles in a somewhat general manner.
    Hell yeah, thank you!

    I just have one dumb question that came to mind. The y axis on the VE table for CSL FW is AQ_REL_ALPHA_N and not AQ_REL, right?

    Leave a comment:


  • karter16
    replied
    Okay - I spun up some google sheets to handle the conversion of AQ_REL to AQ_REL_ALPHA_N in TestO logfiles in a somewhat general manner.

    - Read the instructions sheet first.
    - It can take input log files with up to 26 variables and up to 100,000 rows. It doesn't matter what order the variables are in, so long as Relative Opening (relativer Oeffnungsquerschnitt) and RPM are present.
    - The Calculations tab shows all the working to show exactly what it does.

    https://docs.google.com/spreadsheets/d/1d4vk_oGeeSSSVz16fhjv68uoRAsH7UjmET_CeJ6chhQ/edit?usp=sharing

    Import Raw logfile:

    Click image for larger version  Name:	Screenshot 2025-06-11 at 7.43.53 PM.png Views:	0 Size:	264.1 KB ID:	308020

    Copy of the ALPHA_N_FAKT table:

    Click image for larger version  Name:	Screenshot 2025-06-11 at 6.27.44 PM.png Views:	0 Size:	121.8 KB ID:	308012 Click image for larger version  Name:	Screenshot 2025-06-11 at 6.28.52 PM.png Views:	0 Size:	22.3 KB ID:	308013

    The Calculations:

    Click image for larger version

Name:	Screenshot 2025-06-11 at 7.45.57 PM.png
Views:	99
Size:	162.2 KB
ID:	308022

    And the output:

    Click image for larger version  Name:	Screenshot 2025-06-11 at 7.43.49 PM.png Views:	0 Size:	139.6 KB ID:	308021

    I will put this through its paces with my car, and would be great if some others can do so as well.

    heinzboehmer once a few of us have tried this out and we are all comfortable with this it would be super awesome if you'd be happy to add these sheets to your file so that we can keep everything in one place (and I can remove the separate link above).
    Last edited by karter16; 06-10-2025, 11:46 PM.

    Leave a comment:


  • karter16
    replied
    Originally posted by heinzboehmer View Post

    Wow, yeah, that's significant. Should probably incorporate that factor into the spreadsheet.

    Coincidentally (or maybe not...), the parts of the map affected by AQ_REL_ALPHA_N_FAKT are where I most notice a drivability difference between stock and franken-CSL.

    Have you gone out to do some rounds of VE tuning with the correction applied? Curious to see how noticeable the difference is. I'll give it a shot myself once my car is put back together (probably next week).
    I haven't yet but I'm itching to as soon as I'm not busy with work.


    Sent from my iPhone using Tapatalk

    Leave a comment:


  • karter16
    replied
    Originally posted by Bry5on View Post
    Is this just a fixed multiplier? If so, I suppose we can apply it directly on top of any given part throttle fuel tuning, no?

    I did have to tune some of these regions with AFR so this would explain some of that!
    The adjustment needs to be made to each line in the TestO log. Reason being that MegaLogViewer is summarizing that info.

    Because the adjustment factor varies between 0.7 and 1.0 between 900 and 2400 rpm the raw Relative Opening data points need to be adjusted before the log is summarized by MLV.

    At this point I'm envisaging an extra sheet in Heinz's spreadsheet where you import your log, it applies the linear interpolation for RO for each line, then you export the log file and open in MLV.

    Only accurate alternative is to run a modified prog binary that sends AQ_REL_ALPHA_N over DS2. And for the casual user that's a lot more involved, so I think the log file correction approach is best for now.


    Sent from my iPhone using Tapatalk

    Leave a comment:


  • Bry5on
    replied
    Is this just a fixed multiplier? If so, I suppose we can apply it directly on top of any given part throttle fuel tuning, no?

    I did have to tune some of these regions with AFR so this would explain some of that!

    Leave a comment:


  • heinzboehmer
    replied
    Originally posted by karter16 View Post
    And to visualize it better here is the difference:

    Click image for larger version  Name:	Screenshot 2025-06-10 at 8.46.38 PM.png Views:	20 Size:	536.9 KB ID:	307882

    It's important to remember here that a nominal value is 1.00. This means that a difference of 0.058 is significant. It's the difference between too lean (1.059) and bang on (1.002). This of course only affects 2400rpm and under, but the effect is not small, especially given this is prime low rpm, low throttle, drivability territory.
    Wow, yeah, that's significant. Should probably incorporate that factor into the spreadsheet.

    Coincidentally (or maybe not...), the parts of the map affected by AQ_REL_ALPHA_N_FAKT are where I most notice a drivability difference between stock and franken-CSL.

    Have you gone out to do some rounds of VE tuning with the correction applied? Curious to see how noticeable the difference is. I'll give it a shot myself once my car is put back together (probably next week).

    Leave a comment:


  • karter16
    replied
    Okay so I've now conclusively confirmed that Relative Opening (AQ_REL) as logged in TestO is NOT the same as the Relative Opening value used in the AlphaN map. The AlphaN map uses a modified version of AQ_REL based on the kl_aq_rel_alpha_n_fakt table in my last post. I am calling this modified Relative Opening value AQ_REL_ALPHA_N.

    To show that the effect that this has isn't purely academic I took a VE tuning log I captured a while back and used kl_aq_rel_alpha_n_fakt to do a linear table interpolation exactly the same as the DME does to work out AQ_REL_ALPHA_N for each log line based on AQ_REL and the RPM.

    This is the before in MegaLogViewer:

    Click image for larger version

Name:	Screenshot 2025-06-10 at 8.52.19 PM.png
Views:	112
Size:	696.8 KB
ID:	307880

    And this is the after:

    Click image for larger version

Name:	Screenshot 2025-06-10 at 8.52.33 PM.png
Views:	108
Size:	691.5 KB
ID:	307881

    And to visualize it better here is the difference:

    Click image for larger version

Name:	Screenshot 2025-06-10 at 8.46.38 PM.png
Views:	96
Size:	536.9 KB
ID:	307882

    It's important to remember here that a nominal value is 1.00. This means that a difference of 0.058 is significant. It's the difference between too lean (1.059) and bang on (1.002). This of course only affects 2400rpm and under, but the effect is not small, especially given this is prime low rpm, low throttle, drivability territory.

    Leave a comment:


  • karter16
    replied
    Originally posted by Pavlo View Post

    I am not using one. I am under the impression that relative opening is a mixture of ICV/TPS/MAP and is directly tied to the load table. This definitely corrects the whole table as I would otherwise have a run-away condition if my cells weren’t in the right places. I’ve asked many moons ago on this forum if aq_rel is load and was told it was, what is your reasoning for the question?
    For what it's worth I've just been working through this in my disassembly project and thought it would be worth noting here. Below is a summary of how it comes together:

    AQ_ABS (absolute cross-sectional opening) = AQ_ABS_LLS (absolute cross-sectional opening of idle control valve) + AQ_ABS_WDK (absolute cross-sectional opening of throttle plates)

    AQ_REL (relative cross-sectional opening (%)) = (AQ_ABS - K_AQ_ABS_MIN (minimum possible cross-sectional opening)) / (K_QA_ABS_MAX (maximum possible cross-sectional opening) - K_AQ_ABS_MIN)

    This AQ_REL value is what's used in the standard M3 software, a commonly referenced example of this is the VANOS maps - AQ_REL is the y-axis in those tables.


    The important thing to know is that AQ_REL isn't used directly in the CSL AlphaN maps. It's actually a modified version of AQ_REL that is used.

    For the purposes of this explanation I will call this modified value AQ_REL_ALPHA_N it is calculated thusly:

    AQ_REL_ALPHA_N = AQ_REL / AQ_REL_ALPHA_N_FAKT

    So what's AQ_REL_ALPHA_N_FAKT? It's just my name for the output of the lookup curve at: 0xE056


    Click image for larger version  Name:	Screenshot 2025-06-02 at 8.25.50 PM.png Views:	0 Size:	22.7 KB ID:	307058

    x axis is N (rpm) and the output is a scaling factor.

    Essentially what this means is that AQ_REL_ALPHA_N will be a smaller value (between 0-30% smaller dependent on RPM) than actual AQ_REL beneath 2400 RPM.

    Additionally there is another value that is also calculated in the same routine, let's call it AQ_REL_ALPHA_N_PT_KORR which is additionally scaled based on P_UMG (Ambient air pressure) and TAN (Intake air temperature).

    Click image for larger version  Name:	Screenshot 2025-06-02 at 8.31.34 PM.png Views:	0 Size:	26.9 KB ID:	307059

    This value isn't used in the CSL AlphaN maps (or in other operational code), but it is used in two routines which seem to be involved in the sending/export of data (I haven't figured out yet if these are the DS2 routines or something else). Crucially AQ_REL_ALPHA_N is NOT referenced in any sending/export routines. Which raises the possibility that the "Relative Opening" datapoint that we are logging in TestO isn't even the same data point that is actually used as an input to the VE table (indeed it could even be the standard AQ_REL variable). Looking at the two tables above they are normalized around 20 degrees C intake temp and ambient air pressure of 962mbar, so it's not going to be too far off either way, but for example today in Auckland was 1016mbar at 20C, so PRESUMING THIS IS THE CASE I'd be looking at a 4% variance.

    I will spend more time looking at this to see if I can establish with certainty which of the two variables "Relative Opening" represents.


    Also worth mentioning that the MAP sensor does not have any part in the calculation of AQ_REL. The MAP sensor is used in the calculation of air mass, which in turn is used in the calculation of final Relative Fill (an adjustment to the value obtained from the VE table).


    I realize this post is more focused on the "academic" side but hopefully of use to the collective understanding.
    Last edited by karter16; 06-02-2025, 12:49 AM.

    Leave a comment:


  • ac427
    replied
    Originally posted by bmwfnatic View Post
    Filtering the log and compiling the logged data into the required table.
    Thanks, Are there any suitable alternatives to MegeLogViewer HD ?

    Would https://datazap.me/ do ok or is MLVHD worth the $50 ?

    Leave a comment:


  • bmwfnatic
    replied
    Originally posted by ac427 View Post
    Sorry for another thicko question.

    If TestO is used to log the data and then Excel or MathLab is used view and to manipulate the data.
    ​​​​​​
    What purpose does MegaLogViewerHD serve?
    Filtering the log and compiling the logged data into the required table.

    Leave a comment:


  • ac427
    replied
    Sorry for another thicko question.

    If TestO is used to log the data and then Excel or MathLab is used view and to manipulate the data.
    ​​​​​​
    What purpose does MegaLogViewerHD serve?

    Leave a comment:


  • ac427
    replied
    I have Testo running ok but how and what do i need to log?

    Leave a comment:


  • YulCmr
    replied
    Originally posted by Bry5on View Post
    The WOT table is a multiplier applied over certain cells in the VE table. So changing your VE table can affect your WOT map. The correct way to tune WOT is actually to tune the VE table, but as you state, the car runs open loop in these sections so this method should achieve the same outcome. No, this method will not change your WOT tuning and AFRs.
    Thank you for your answer.

    After a quick reading of the tune, full load table was indeed modified, but so was the big Alpha N table. (now richer on bottom end and leaner on top end).

    If I get corrections in my VE table using this method, can it "fine tune" the tune I got ?

    From my understanding, as my VE table keeps dropping after 3 passes, it means that I was running a bit rich with this tune ?

    Click image for larger version

Name:	Screenshot 2024-10-18 191943.png
Views:	315
Size:	162.3 KB
ID:	281713

    As far as I can tell, drivability has been GREATLY improved after 3 passes !

    Thank you guys.

    Leave a comment:


  • Bry5on
    replied
    The WOT table is a multiplier applied over certain cells in the VE table. So changing your VE table can affect your WOT map. The correct way to tune WOT is actually to tune the VE table, but as you state, the car runs open loop in these sections so this method should achieve the same outcome. No, this method will not change your WOT tuning and AFRs.

    Leave a comment:

Working...
X