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

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

[SliM3]

Thanks heaps for this - Correct me if I'm wrong but doesn't this straight up disable the lambda controller?

Yes, that scalar will shut down the lambda controller completely however Lambda regulator shutdown is rpm/rf based. You'll have a blast disassembling the lambda module! I don't miss it one bit, LOL…


Sent from my iPhone using Tapatalk

[karter16]

I was doing so much at once back then that I don't remember what steps I took exactly, but there was some drift with each successive cycle. The car ran fine the whole time, and it presented as stumbling from the transition from cold start open loop to regular closed loop operation, due to a sort of binary change in fueling.

Now that I think of it a little more, this might have only been an issue during AFR based tuning. I tried a bunch of different things to get the transition from part throttle to full throttle AFR right, which is challenging as the DME goes open loop at different relative openings based on RPM. Then the latency from polling the d-bus messes with your numbers.

Perhaps it's not needed after all, I should have thought more before posting! But tuner beware if you're using AFR

Okay cool - it will be good to get some more feedback from others before discounting this I think, I am but one data point. It has driven me to look further into the lambda controller disassembly which is also a good thing.

It will be good if I can make some progress on the CAN bus message to get fast data acquisition for this as well so we can stop worrying about the data point latency issue.


Sent from my iPhone using Tapatalk

[karter16]

Hi gentlemen, trying to play catch up as i've just startet following your work. A suggestion i would propose is to deactivate tank ventilation too.

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

[MC346]

Hi gentlemen, trying to play catch up as i've just startet following your work. A suggestion i would propose is to deactivate tank ventilation too.

[Bry5on]

Thanks heaps for this - Correct me if I'm wrong but doesn't this straight up disable the lambda controller?

When you were doing your early tuning runs and ended up rich at low RPM how was that presenting to you? Was the lambda integrator reporting 1 for those cells but the wide-band was showing it was actually rich? Or was there some sort of feedback loop where it was being driven rich on each successive run? Just curious as I'm not really seeing that (second scenario) play out for me with this current testing I'm doing. The low RPM idle range has mildly more fuel than the stock CSL tune, but only slightly so and has consolidated around a lambda of 1.0 after 3 tuning runs.

I was doing so much at once back then that I don’t remember what steps I took exactly, but there was some drift with each successive cycle. The car ran fine the whole time, and it presented as stumbling from the transition from cold start open loop to regular closed loop operation, due to a sort of binary change in fueling.

Now that I think of it a little more, this might have only been an issue during AFR based tuning. I tried a bunch of different things to get the transition from part throttle to full throttle AFR right, which is challenging as the DME goes open loop at different relative openings based on RPM. Then the latency from polling the d-bus messes with your numbers.

Perhaps it’s not needed after all, I should have thought more before posting! But tuner beware if you’re using AFR

[karter16]

Ok here we go, set to 00 to disable:

Thanks heaps for this - Correct me if I'm wrong but doesn't this straight up disable the lambda controller?

When you were doing your early tuning runs and ended up rich at low RPM how was that presenting to you? Was the lambda integrator reporting 1 for those cells but the wide-band was showing it was actually rich? Or was there some sort of feedback loop where it was being driven rich on each successive run? Just curious as I'm not really seeing that (second scenario) play out for me with this current testing I'm doing. The low RPM idle range has mildly more fuel than the stock CSL tune, but only slightly so and has consolidated around a lambda of 1.0 after 3 tuning runs.

[Bry5on]

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

Ok here we go, set to 00 to disable:

[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

[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]

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.

[heinzboehmer]

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