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

[heinzboehmer]

Damn, excellent work! Awesome to see the explanation behind some of the weird behaviors I've noticed when trying this out.

(Honestly if you haven't actually driven it and felt the difference in drivability you can't appreciate what it is that you're missing).

+1000. I've been beta testing and grabbing data for Bry5on since he started on the tune and it's incredible. You really don't know what you're missing until you try it out.

[karter16]

Hi all - this one is a bit of a PSA from Bry5on and I.

TL;DR: There is an area of the closed-loop tune that you shouldn't be targeting for stoich (lambda == 1) when VE tuning. If you do you will almost certainly end up with that area of tune too lean. IMHO anyone who has VE tuned should remediate this area of the VE table to ensure they aren't running leaner than they think. There's some ways to fix it, see the "So what do I need to do?" section at the bottom.


Background
A few weeks ago when discussing something else Bry5on mentioned to me that he'd found, and been working on, a region between 2000-3500ish rpm under heavier closed-loop loads needed more fuel in order to nicely transition from closed loop to open loop. A few days later I had my CAN-logger up and running and got to something I'd long wanted to do which was to log various intermediate variables in the RF calculation path. It's one thing to look in the code at what these variables do, but it's another to actually see the end effect that they each have.

I found a number of interesting observations, but for clarity will keep this post focused on one in particular, what I've named rf_korr. This variable is obtained from KF_RF_KORR_DRREL (one of the few CSL-specific parameters we know the actual name for).


KF_RF_KORR_DRREL


This table has x axis: N (rpm) and y axis: rf_tabg_modell - TABG. The output is a multiplier factor which is applied to RF.

rf_tabg_modell
So what is rf_tabg_modell then. It's nominal TABG (exhaust gas temp) as obtained from this table:

Essentially this is a table of expected TABG for a given RPM/RF. This is what BMW would have measured during testing.


Okay so why do we need this?
Obviously we don't know for sure all the reasons BMW might have done this because we don't have the documentation, so please keep that in mind when you read the below explanation, but I'm personally pretty confident that this makes sense, and indeed what we see playing out in reality aligns with this.

KF_RF_KORR_DRREL is needed to account for differences between the nominal gas temperature in the cylinder when BMW calibrated the VE table (and indeed the entire RF calculation path) (this would have almost certainly been done on a test bed with the engine and exhaust fully up to temperature) and the actual gas temperature in varying real-world conditions.

When the engine is at full operating temperature the gas is hotter, and therefore less-dense, requiring less fuel. In real-world conditions when you've been driving around for a bit and exhaust temps are relatively cold, and you then suddenly put load on the engine (for example when you're doing VE tuning runs 🙃) the gas temperature is significantly lower and therefore more dense.


What all this means in practice is that if you simply log lambda and aq_rel_rf you're going to end up with that area appearing rich (because the number you're looking at to chase stoich has been intentionally adjusted rich) and incorrectly leaning it out.

To prove this point here is the familiar histogram (note I'm using aq_rel_rf which is the previously noted correct input variable to be using for VE tuning).



There's a big rich patch in the middle there at higher aq_rel_rf that needs to be corrected right?

Let's have a look once we've corrected lambda for rf_korr:



As we can see we're actually still lean in some cells! These screenshots were from an early tuning run experimenting with this, which is why the corrected table hasn't converged on 1 everywhere.

How does it drive?
So all this academic stuff is interesting, how does it actually drive?

Enormously better. When I first tried this out I didn't need to read the logs to know it was a huge improvement. Power and smoothness through that higher load rpm range was massively improved. When I was logging on DS2 I thought this area of my tune was average due to not having done open-loop tuning with a Wideband. It was only when CAN logging that I realized this area was still in closed loop.


Validating the theory
Meanwhile Bry5on was approaching this same theory from another approach. I won't go into too much detail on this, he can if he wants to, but essentially we've now confirmed the same behavior and obtained the same results by approaching this in two different ways. The fact that we arrive at the same conclusions in different ways is very reassuring that we are on the right track. I believe Bryson's had some good feedback on the changes that he's made, and likewise I've found this has brought massive improvements to my tune as well.

Given all of this I'm pretty confident in saying that BMW tuned the VE table to target stoich, and have then applied corrections over the top where the actual target needs to differ lean or rich for varying operating conditions.


So what do I need to do?
Okay, the most important thing to be aware of is that you shouldn't be chasing lambda == 1 in the range that KF_RF_KORR_DRREL covers.


Option 1 (simple but rough): I found with my setup (Euro M3, stock exhaust, Euro headers, standard cams) that I needed the VE table to have MORE fuel than the stock CSL table in that range (which makes sense given the standard cams). If you currently have less fuel in that area you're almost certainly too lean, as an immediate fix I'd at least go back to the stock CSL cell values in that range where you are currently leaner).

Option 2 (complicated but accurate): If you're setup for it you can do what I'm doing and CAN-log the intermediate variable and calculate lambda adjusted for rf_korr, but appreciate most can't do that with their current setups as I'm using a custom program rom to enable logging those variables. What is more in reach would be logging TABG and then doing the math to calculate the difference between the model and actual TABG, which in turn would give you your rf_korr. It's a bit of excel math, but would be a reliable approach.

Option 3 (easy and accurate): Or in my ( karter16's) opinion, if you're able, even better would be to reach out to Bry5on and get onto the Mullet Tune, not only does it solve this problem but it is by far the most sophisticated tune available for these cars and you'll reap a whole range of other improvements as well. (Honestly if you haven't actually driven it and felt the difference in drivability you can't appreciate what it is that you're missing).


All questions/challenges/etc. welcome!

[karter16]

Can we log short term adaptations and watch for the first transition from 1? If I remember correctly, adaptations are forced to 1 during this period - hence the difficulty in tuning cold start fueling.

Ah good thinking - I'll dig into that but that sounds like a very good option.


Sent from my iPhone using Tapatalk

[Bry5on]

Can we log short term adaptations and watch for the first transition from 1? If I remember correctly, adaptations are forced to 1 during this period - hence the difficulty in tuning cold start fueling.

[karter16]

Okay so when it comes to the cold-start map I think the presumption has been to log up until the point that TMOT is at 80 degrees C at which point the engine is warm and on the standard map.

As I was chasing the last few parameters I came across this again and looked at it in a slightly new light. the Alpha N Kath table is blended in based on AVAN1_SOLL_FAKTOR. But why use AVAN1_SOLL_FAKTOR and not KATH_FAKTOR directly. Last time I looked at this I wasn't in the detail enough to question it, but it seems to be an interesting choice.



AVAN1_SOLL_FAKTOR is calculated on the slave here:



The key thing to note is if EVAN1_ST bit 4 is set then AVAN1_SOLL_FAKTOR ramps to 1 over a few seconds) if bit 4 is cleared then AVAN1_SOLL_FAKTOR ramps to 0. So it's either on or off with a bit of smoothing over the few seconds of the transition.

How is EVAN1_ST set?

bit 4 is set here:



What this is doing is using the curve KL_VAN_KATH_TMOT to determine how long EVAN1_ST should be cleared for before it is set.



First time the function runs and engine is in running state (LL/TL/VL) it checks current TMOT and looks up how many seconds the warm up period should last for. (e.g. if TMOT is 18 degrees C then the warm up will last for 120 seconds).

EVAN_1_ST bit 4 stays cleared for 120 seconds and is then set.

So the warm up period that the AlphaN Kath table is used is a set number of seconds based on TMOT at the time the engine starts, not a temperature target that is achieved by the end of warm up.

So back to my original question, why are we using AVAN1_SOLL_FAKTOR rather than KATH_FAKTOR. Thinking about it a bit more it actually makes a fair bit of sense. Use of the AlphaN Kath table is tied to the use of the VANOS Kath tables because the different camshaft tables affect the volumetric efficiency and therefore the AlphaN table needs to be tuned to the VANOS Kath profiles. Likewise they both use AVAN1_SOLL_FAKTOR as they need to switch together as well.


Anyway, why am I writing this in here? Because we should stop presuming that the AlphaN Kath table is used until TMOT >= 80 degrees and come up with a different strategy (We could probably log AVAN1_SOLL_FAKTOR over DS2, or we could log TMOT on engine start and work out how many seconds into the log file to take data from from there).

Not sure in practice how much this will really affect anything but might as well make sure we have the most correct knowledge :-)

[heinzboehmer]

Super wild how different the results are between the two cars after running the same optimization! I wonder if you have a looser ICV than I do? That’s the only thing I can think of that would need that much extra fuel down low.

Yeah I don't get it either. Injectors are the only other thing I can think of. Although our cars are dead on in the upper RPM/load ranges, not sure what to make of it.

I have a set of TT injectors in the garage, but haven't swapped them cause I haven't been ready to go down that rabbit hole.

[Bry5on]

Ran through the karter16 updated VE tuning method on my car today. Car is running Bry5on's latest mullet (v28) and I disabled MAP and adaptations during the data logging sessions.

Here's the final change compared to the baseline after three iterations:



There was a little bit of weirdness left down low (<1500 rpm and <~1.5 relative opening) before the tuning. It was mostly noticeable when pulling away from a stop and when feathering the throttle right before fully disengaging the clutch on upshifts. Was extra noticeable with the stock comfort throttle mapping.

But all that is practically undetectable post-tuning! I'm super happy with the results. Drivability is very, very, very close to stock now.

Super wild how different the results are between the two cars after running the same optimization! I wonder if you have a looser ICV than I do? That’s the only thing I can think of that would need that much extra fuel down low.

[heinzboehmer]

Ran through the karter16 updated VE tuning method on my car today. Car is running Bry5on's latest mullet (v28) and I disabled MAP and adaptations during the data logging sessions.

Here's the final change compared to the baseline after three iterations:



There was a little bit of weirdness left down low (<1500 rpm and <~1.5 relative opening) before the tuning. It was mostly noticeable when pulling away from a stop and when feathering the throttle right before fully disengaging the clutch on upshifts. Was extra noticeable with the stock comfort throttle mapping.

But all that is practically undetectable post-tuning! I'm super happy with the results. Drivability is very, very, very close to stock now.

[Bry5on]

How interesting - I've been trying to think through the order of events of multiple rounds of tuning and how you could converge on the right result anyway, I was seeing waves of lean and rich coming through the table in successive runs, but maybe yours just didn't drive the same behavior 🤷♂️




Yes correct - value on 7D0 is AQ_REL as per DS2. Given we now know how to convert AQ_REL to (what I am calling) aq_rel_alpha_n for the purposes of the VE tuning I figured it made sense to use standard AQ_REL in the CAN message to align with all other tables that use AQ_REL.

Thanks.

In my final fuel tuning I disabled all lambda control and tuned by AFR directly, i suppose the conversion was close enough, or steady state enough, that my multipliers worked? Some of my final tweaks were also manual/logical on top of the algorithmic AFR targeting. I guess this proves that my method didn’t suck! Hah. I also couldn’t really tell much of a difference after turning off adaptations and MAP compensation when driving. Just one mediocre downshift around 1500rpm or so.

[heinzboehmer]

How interesting - I've been trying to think through the order of events of multiple rounds of tuning and how you could converge on the right result anyway, I was seeing waves of lean and rich coming through the table in successive runs, but maybe yours just didn't drive the same behavior 🤷♂️

My car is still out of commission , but I plan on doing this as soon as it's back up and running. Am running the same exact hardware as Bryson (minus flap) and the same tune. Will be interesting to see if there's any variation from car to car.

[karter16]

Okay, I tried this one tonight and it looks like I had the mullet pretty spot on - weird!

How interesting - I've been trying to think through the order of events of multiple rounds of tuning and how you could converge on the right result anyway, I was seeing waves of lean and rich coming through the table in successive runs, but maybe yours just didn't drive the same behavior 🤷♂️

Also, karter16 I'm assuming that the relative opening value we're transmitting over CAN now is the same one as DS2, not the modified CSL one.

Yes correct - value on 7D0 is AQ_REL as per DS2. Given we now know how to convert AQ_REL to (what I am calling) aq_rel_alpha_n for the purposes of the VE tuning I figured it made sense to use standard AQ_REL in the CAN message to align with all other tables that use AQ_REL.

[Bry5on]

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.

Okay, I tried this one tonight and it looks like I had the mullet pretty spot on - weird! I'll load this new file up tomorrow and see if I notice any difference in fueling, although I'm not sure I will given how small the changes are. This was about 15 minutes of driving specifically focused on low RPM.


Also, karter16 I'm assuming that the relative opening value we're transmitting over CAN now is the same one as DS2, not the modified CSL one.

[karter16]

karter16 since converting to CSL MAP based software, have you noticed if the cold starts, with the euro section 1 and SAP enabled, smell quite a bit more rich than when it was running with the MAF?

On my current tune no, on the standard CSL tune yes absolutely - cold starts were significantly richer.

It's worth noting that I'm running my own CSL tune which I'm developing along the same philosophy as Bryson's Mullet Tune. I've adjusted approx 15 of the cold start maps, including the SAP and cat heating related maps. At this point a lot of that looks a lot more like the Euro M3 tune than the CSL tune which will be why it's no longer rich at cold start.

[Slideways]

karter16 since converting to CSL MAP based software, have you noticed if the cold starts, with the euro section 1 and SAP enabled, smell quite a bit more rich than when it was running with the MAF?

[MC346]

Great to have more people looking at this. You raise a very valid point re tank ventilation. What I'm not sure of though is for what period of time it's reasonably safe to disable ventilation for? Does anyone have any thoughts on this? There's certainly easy ways it could be disabled in the partial tune.

I do know for sure that tank ventilation is specifically accounted for in the MAP sensor RF calculations. I suspect that probably the tuning process will get the VE table close enough either way for the MAP sensor to be able to compensate when it's turned back on, but regardless we should try to understand this fully (as I would think those running pure AlphaN could take advantage of this tuning process in similar ways right?)


Sent from my iPhone using Tapatalk

I admit this might be a bit of an overkill for our purposes. Essentially what we are striving for is a judgment (and possible recalibration) of pre-control maps. Therefore, you'll want to get rid of as many components that will affect your fuel path, such as adaptation values (offset and factor), any dynamic compensation (which hopefully won't be in place anyway during steady state driving of load/engine speed points and, as mentioned, the ventilation system that will introduce fuel vapors into your intake.

I think if you are performing dedicated calibration runs and deactivate the ventilation for those occasions (i think there is a coolant temp entry condition, that you can set to max. value) you should be fine. Ideally, top up the fuel tank before and don't drive on high altitudes

God, i really need a wideband now...