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

[karter16]

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

[karter16]

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

[karter16]

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:



Copy of the ALPHA_N_FAKT table:



The Calculations:



And the output:



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

[heinzboehmer]

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?

[karter16]

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



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)

[karter16]

Please note that I fixed a bug (typo in formula) just now. heinzboehmer if you took a copy of the sheet already then you'll want to grab the latest version.

[heinzboehmer]

Okay cool, just making sure. Appreciate the references

As for the sheet, I'll wait until it's validated by a few of us before making a copy.

[karter16]

Okay cool, just making sure. Appreciate the references

Yeah absolutely - The more we constructively challenge each other's work the better - no one is immune to mistakes or misunderstandings, so we all benefit from robust discussion :-)


I did a test drive just now.

I took my most recent VE log (note this was first one with MAP sensor disabled which I think is why it shows slightly lean across the board - I think the MAP sensor was compensating for/hiding this) and ran it through the spreadsheet, then imported to MLV, then into your spreadsheet Heinz, to generate the new VE table. The result was as I was expecting, that the mismatched AQ_REL values were previously making low RPM appear richer than they actually were (e.g. more fuel was needed).



I then went for a (reasonably quick) run (about 6000 log lines) focusing on the low RPM and could tell the improvement pretty much immediately, no-throttle, low-rpm downshifts were particularly noticeable, rev matching was even better than previously, the car had even more pep than previously (remember I'm currently doing these runs with the MAP sensor turned off as well, so when I'm making these comparisons it's on pure AlphaN without the MAP sensor correcting anything).

And I think the MLV view speaks for itself - Lambda around the high change areas is significantly better, and a lot of values that were quite wrong are now spot on. There's those couple areas between 870 and 1100 RPM to clean up (that previously weren't clearly identifiable and kept moving around - which makes sense given AQ_REL was being misinterpreted) but all in all this is quite a lot of improvement for a single run, and it's very noticeable when driving.



I'll do another run tomorrow off the back of this to prove further that this converges on a neat end result, but I'm pretty confident from this first run that this is the missing trick to really nailing down the low RPM.

Important to note as well that I am running pure AlphaN with the MAP sensor disabled. I think this is really key when logging as well to not end up masking inaccuracies in the VE table.

[Bry5on]

I’m still not clear on why we need to do this correction. If we’re seeking a stoichiometric 1.0 number, then using only that multiplier to determine the cell in the fuel map, we should not be modifying the end result.

In the case that we do need to make this correction, that would mean that the DME is deliberately targeting a ‘lean’ mixture in throttle transients and using the O2 sensors to bring it back to stoich in steady state. Seems a little odd to me, logically.

edit: Nevermind, I see now! This is changing the actual throttle opening position, not the fueling amount. Makes sense. Leaving this here in case I was not the only one misinterpreting.

[karter16]

I went for another run this morning (about 5 degrees cooler than last night).

I didn't need to look at the log file to know that this is the right approach. Honestly was like driving the car with the MAP sensor enabled.

As you can see from the log there's still some tuning to go, mostly around the very low rpm range which is really hard to consistently hit while driving (especially with SMG). But essentially all the cells are pretty rapidly converging at 1.0 (those that still have some work to do are where they didn't have good coverage in the previous logging run).



I'm stoked. I'm very confident now that this is the trick to nailing down the low RPM, and just need some others to further validate what I'm seeing.

There are two key learnings out of this:

1: It is important to make sure the DME is actually functioning the way you think it is. In this case the assumption was that AQ_REL (Relative Opening) was used by the Alpha_N (VE) table the same as it is in the VANOS tables, etc. Digging into the disassembled code showed that this was not the case and that the Alpha_N (VE) table y-axis uses a modified form of AQ_REL at low RPM. The effect of this is that, if not corrected, MegaLogViewer attributes Lambda Integrator values to the wrong Relative Opening cell. This results in lower RF (relative fill) values being entered into the VE table, which in turn has the effect of making that cell leaner than it should be.

2: Disabling the MAP sensor is the second key to this process. The way the MAP sensor works is to compensate for the difference between the Alpha_N (VE) table calculated RF and the real-world RF calculated from the MAP sensor readings. This means that if the MAP Sensor is left enabled during this process it has the effect of covering up error in the Alpha_N (VE) table. With the MAP sensor enabled I had a pretty reasonable VE table, but with some areas that weren't quite right and seemed to keep moving around and couldn't quite be nailed down (the MAP sensor was masking inaccuracies). Disabling the MAP sensor takes that variable away and helps target a more accurate VE table more quickly.

[Obioban]

How are you disabling the MAP?

[heinzboehmer]

This is awesome karter16! I'm excited to test this out on my own car.

[karter16]

How are you disabling the MAP?

Yeah good call - I mentioned this in the disassembly thread but hadn't really expanded on it here. For reference for everyone here are the details below of how I'm now setup for VE tuning.

The steps below will use the naming conventions as per V3.2 (newly published today) of the XDF I've put together here: https://nam3forum.com/forums/forum/s...p-csl-0401-xdf

1: Disable and clear Long Term Fuel Trims
In TunerPro (with the XDF above loaded along with your current 0401 partial (tune) binary) Open the K_LAA_TMOT_MIN parameter and set it to 100 degrees C. As noted in heinzboehmer's earlier post this has the effect of raising the point at which the LTFTs are updated above the operating temperature of the motor (e.g. the LTFTs will never change).



2: Clear current engine adaptions in INPA.
Again as heinzboehmer notes this is necessary because the above step only stops LTFT's from being updated, not used. So you need to reset them to 1.00 so that they have no effect.

3: Disable the MAP Sensor Integrator
The MAP Sensor is a good thing under normal conditions in that it, in real time, accounts for variation between the AlphaN VE table and actual real-world conditions. This is why running the MAP Sensor results in a smoother drive. However this correct is counter-productive when performing the VE tuning process. To disable the MAP sensor input to calculation of Relative Fill and rely solely on the AlphaN VE table set k_rf_cfg to 0x02 (if you would like more reassurance that this does what I say it does see here: https://github.com/karter16/CSL_0401...put-parameters)



4: Go for a drive and log in TestO.
Log the following Parameters (you can log other parameters as well, just need at least these):
- Relative Opening
- RPM
- Lambda Integrator 1
- Lambda Integrator 2
- Motor Temp (if you're going to log from cold, otherwise only start logging once car is completely up to temp)

5: Process the log file to correct the AQ_REL (Relative Opening) values
Take the resultant log file and run it through https://docs.google.com/spreadsheets...it?usp=sharing to adjust the Relative Opening values to scale correctly for the AlphaN VE table.

6: Load the processed log file into MegaLogViewer
Load the processed log file into MegaLog Viewer.

7: Calculate the new VE table
Copy the lambda table from MegaLogViewer into heinzboehmer's spreadsheet and process as per the instructions there.

[Bry5on]

Ah there’s another fuel trim that you need to disable that’s active near idle conditions. I found this one out during my early testo logging which was fun. Some early versions of the mullet ended up super rich near idle because of it when combined with this fuel trimming process. This is partly why I switched to AFR based final tuning. Will see if I can get to my laptop before I head out of town to dig it up.

[karter16]

Ah there's another fuel trim that you need to disable that's active near idle conditions. I found this one out during my early testo logging which was fun. Some early versions of the mullet ended up super rich near idle because of it when combined with this fuel trimming process. This is partly why I switched to AFR based final tuning. Will see if I can get to my laptop before I head out of town to dig it up.

Ah nice! I hadn't figured that out! - that would be great if you could! If we can identify all these factors and how to address them we should be able to come up with a really solid process anyone can follow to do this.


Sent from my iPhone using Tapatalk