Karter16's Silbergrau E46 M3 Journal

[Arclitgold]

Awesome! I need to get some of these for myself

[karter16]

I'm continuing to have very little spare time outside of work and family, but did find some time yesterday and today between meetings to prep and paint the Bryson fender braces. light scuff and clean, etch primer and then the e-coat colour matched top coat that I have.

(biggest achievement in this photo is finding an area of carpet that hasn't been completely destroyed by my children).








The plan is to epoxy-bond (3M 7333 or similar) and bolt. I will of course be stripping the paint where the surfaces bond, but given I won't know the exact bounds of that area until I am in the middle of the install I opted to paint entire now, and will wire brush the appropriate area when the time comes.

For now these can go into storage and the paint can fully harden.

[karter16]

Playing catch-up (again): Glad that the hint about deactivating TEV was worthwhile. It's one of the key influences on fuel-precontrol.

Re idle oscilations as a result of lambda controller oscilations: A tryout i wanted to perform (and didn't manage to do before winter hibernation..) is to just deactivate the PI-controller and run open-loop. That way, one should theoretically be able to isolate the issue to the idle controller.

Yeah very interesting looking at the logs of the valve - it's a lot more transient and active that I would have expected. What I find interesting is that the CSL air mass calculations have a correction factor that take TETV into account, yet it doesn't seem to actually be particularly accurate. When I get a chance I want to to look at the correction factor and see how much it's improving things.

Re the idle oscillations - that's an interesting idea, I know Bryson found that the MAP sensor tuning resulted in a big improvement for him, but I haven't found the same thing yet.

[MC346]

Made a bunch of progress over the weekend.

As I've been rounding out understanding the different variables that can impact the VE tuning process (using the narrowband sensors) I've been getting closer to re-enabling the MAP sensor input to RF.

The VE tuning process is impacted by a range of factors, so I've found in order to get really repeatable results it's necessary to do at least the following:

• Disable the MAP sensor input to RF.
• Ensure that you're using aq_rel_rf not the standard AQ_REL variable.
• Ensure that you filter out accel enrichment BA_F_TI (this is transient but certainly has an impact, I log it and then exclude records where it is active)
• Disable TETV (tank ventilation) during logging runs. This has an enormous, and non-predictable/repeatable impact on lambda measurements. (Important to note that after each such run I immediately follow with a drive where TETV is enabled to allow the tank to vent).
• Take rf_korr into account. In order to do this I calculated an adjusted version of LA_F_REGLER1 that has been multiplied by logged rf_korr.

I also exclude records where lambda == 1.000. The reason for this is that the vast vast majority of these are where the DME is running open loop. They have the effect of making every cell appear closer to 1 than it actually is. I could log ZUSTAND_MOTOR instead and use that, but I can use that byte for something else with the lambda == 1.000 approximation instead. This is really just a way to get to the end result quicker. If you don't do this it will just take longer to get to the same end result.

Having settled on this procedure I have excellent repeatability between runs.

This weekend the temperature was bang on 20C so I decided I would take the opportunity to do a couple of final VE tuning runs focusing on the area the MAP sensor is active in so that I can then re-enable the MAP sensor. I reconfigured my CAN logging for the necessary parameters and did a test drive. I noticed the following in the logs:



Those spikes that don't have a corresponding aq_rel_rf spike are the MAP sensor input going floating. Interestingly the effect got worse the more the engine warmed up. So seemed pretty clear it was going to be a mechanical connection issue in the wiring harness. I replaced all the connectors on the harness extension (fortunately I had these on hand as spares). And did another check:


Much better! I couldn't find any obvious issue with the old connectors, but clearly the issue was there somewhere!

With that sorted I then did my final VE tuning runs to lock in the area of kf_rf_soll that the MAP sensor will operate in.

The MAP sensor input itself is used to calculate an actual m (airmass) value which is then divided by nominal m to get rf_p_saug (rf from MAP sensor). The MAP sensor input to RF calculation is only active in this area:

X axis is N (RPM) and Y axis is p_saug (MAP pressure)



At idle the sensor is active through to light-medium load, and at higher RPM it's active only at light load. Why would BMW go to all that effort and limit it to that range? Because that's where it's needed, and it's where it's effective.

Below is two slightly different views of the same data. We can see that at aq_rel between 0 and 1.5 (out of 100!) the MAP to aq_rel response is linear and at a slope that provides good definition. Above this (1.5-100) the slope flattens out a lot and pretty much anything high load starts to look the same. We can see there is slight shift based on N (RPM).

The area of the curve that kf_rf_p_saug_i_gain targets is the first part where the MAP sensor input is useful. At higher loads where the MAP sensor slope is too flat the RF calculation relies on aq_rel_rf alone.



Why do we bother with all of this? Because calculating rf_soll (CSL Alpha N table) is just a calculated value based on throttle opening. It doesn't properly take into account real world conditions. The MAP sensor measures the actual pressure in the ITBs at a moment in time and therefore can calculate the actual airmass. This is why the MAP sensor gives smoother response at idle/part throttle driving.

When running M3 cams the MAP sensor calculations actually need to be adjusted to account for the different cams. Otherwise the MAP integrator tends to bounce off one or other of it's limits (I've got a log somewhere from nearly a year ago that demonstrates this, but can't find it at the moment). This doesn't mean it isn't helping, but it's not able to fully adjust (also the end result it's targeting is based on CSL cams not M3 cams).

With this adjusted for we can see rf_p_saug_i sitting comfortably within its limits, able to adjust up/down as needed. We can also see in this snapshot evidence of rf_p_saug_i (the integral) change being suspended under load conditions.



Very cool.

Where to next? I'll do some more logging on this, In particular I want to get some more logs of idle conditions, etc. to see if I can reproduce the same very steady idle that Bry5on is finding. I'll also log a range of driving conditions to observe how the MAP sensor influences RF calculation (basically real-world logging of the behavior I'm expecting to see based on the disassembly work).

Playing catch-up (again): Glad that the hint about deactivating TEV was worthwhile. It's one of the key influences on fuel-precontrol.

Re idle oscilations as a result of lambda controller oscilations: A tryout i wanted to perform (and didn't manage to do before winter hibernation..) is to just deactivate the PI-controller and run open-loop. That way, one should theoretically be able to isolate the issue to the idle controller.

[karter16]

Well the crazy busy-ness has continued on my side - haven't had much time to keep up with car stuff at all. Hopefully things will settle down as we get closer to Christmas - I've got some projects I want to finish off over the break.

To add to it all my 4 year old managed to knock over a cup which perfectly directed iced tea through the air intakes on my laptop. Fortunately this happened 3 weeks before my AppleCare+ warranty ran out as the repair bill ran to $7500 (which is several thousand more than I paid new for the laptop 3 years ago).

The programmer is still in transit for me to bench-flash the DME and recover from my mistake. Will post more on that when I get to it.

In brighter news though I now have a set of Bryson's fender braces ready to go. I was expecting I'd need to politely ask Bryson for the files so that I could get a set made locally as SendCutSend don't ship internationally. Then I happened to see Ethan's for sale post and reached out to ask if he'd be prepared to ship to NZ. He very kindly sent them my way and I'm now all set to go with that project when I, hopefully, get some time over the Christmas break.

[Bry5on]

We've all been there!

[karter16]

I haven't had much time the last few weeks, but did have a little bit of time yesterday and, finally, the inevitable happened and I bricked my DME 🙃. Honestly kinda amazed I got as far as I did before screwing something up. Kind of a dumb mistake too. I miscalculated how much space I needed to leave in a struct in RAM. Just so happens the RAM I've effectively corrupted is used by OBD (because of course) so recovery with WinKFP isn't an option here.

Anyway - BDM stuff is on its way. I have a DME with ST chips so am going to give this route a try https://nam3forum.com/forums/forum/s...jtag-u-link-nt

I needed to get setup for this anyway as this was bound to happen at some point, so will be good to get the stuff and get it up and running.

Have managed to join both the flatbed gang and the bricked DME gang in the same calendar year!

[ac427]

Small job today after work - replaced the xenon bulbs with new Osram Nightbreakers. Pretty sure the ones in it were the original items and they were getting so dim I thought it probably wouldn't pass the next warrant of fitness.

I used to own a Subaru Outback (for which the official procedure to replace the front left bulb was to remove the wheel and wheel lining) and could replace those by hand from the top, so doing this on the e46 was overwhelmingly spacious in comparison so it was a quick job.

No comment yet on the difference as it is not night time. Will update on this when I next drive at night.

They make a great difference. I think mine might have been the originals too. I could see the Osram's illumination while driving in daylight!

The only issue is making sure the bulbs are genuine.

[karter16]

Small job today after work - replaced the xenon bulbs with new Osram Nightbreakers. Pretty sure the ones in it were the original items and they were getting so dim I thought it probably wouldn't pass the next warrant of fitness.

I used to own a Subaru Outback (for which the official procedure to replace the front left bulb was to remove the wheel and wheel lining) and could replace those by hand from the top, so doing this on the e46 was overwhelmingly spacious in comparison so it was a quick job.

No comment yet on the difference as it is not night time. Will update on this when I next drive at night.

[karter16]

Amazing work, as always!

Also, gotta love having data to pinpoint bugs. I bet that connection issue would have haunted you for a long time had you not had those logs

Oh man absolutely! Having 100Hz data is huge, there's so much more you can see, it's aided my understanding massively. (not to mention the improved accuracy for tuning).

[heinzboehmer]

Amazing work, as always!

Also, gotta love having data to pinpoint bugs. I bet that connection issue would have haunted you for a long time had you not had those logs

[karter16]

Made a bunch of progress over the weekend.

As I've been rounding out understanding the different variables that can impact the VE tuning process (using the narrowband sensors) I've been getting closer to re-enabling the MAP sensor input to RF.

The VE tuning process is impacted by a range of factors, so I've found in order to get really repeatable results it's necessary to do at least the following:

• Disable the MAP sensor input to RF.
• Ensure that you're using aq_rel_rf not the standard AQ_REL variable.
• Ensure that you filter out accel enrichment BA_F_TI (this is transient but certainly has an impact, I log it and then exclude records where it is active)
• Disable TETV (tank ventilation) during logging runs. This has an enormous, and non-predictable/repeatable impact on lambda measurements. (Important to note that after each such run I immediately follow with a drive where TETV is enabled to allow the tank to vent).
• Take rf_korr into account. In order to do this I calculated an adjusted version of LA_F_REGLER1 that has been multiplied by logged rf_korr.

I also exclude records where lambda == 1.000. The reason for this is that the vast vast majority of these are where the DME is running open loop. They have the effect of making every cell appear closer to 1 than it actually is. I could log ZUSTAND_MOTOR instead and use that, but I can use that byte for something else with the lambda == 1.000 approximation instead. This is really just a way to get to the end result quicker. If you don't do this it will just take longer to get to the same end result.

Having settled on this procedure I have excellent repeatability between runs.

This weekend the temperature was bang on 20C so I decided I would take the opportunity to do a couple of final VE tuning runs focusing on the area the MAP sensor is active in so that I can then re-enable the MAP sensor. I reconfigured my CAN logging for the necessary parameters and did a test drive. I noticed the following in the logs:



Those spikes that don't have a corresponding aq_rel_rf spike are the MAP sensor input going floating. Interestingly the effect got worse the more the engine warmed up. So seemed pretty clear it was going to be a mechanical connection issue in the wiring harness. I replaced all the connectors on the harness extension (fortunately I had these on hand as spares). And did another check:


Much better! I couldn't find any obvious issue with the old connectors, but clearly the issue was there somewhere!

With that sorted I then did my final VE tuning runs to lock in the area of kf_rf_soll that the MAP sensor will operate in.

The MAP sensor input itself is used to calculate an actual m (airmass) value which is then divided by nominal m to get rf_p_saug (rf from MAP sensor). The MAP sensor input to RF calculation is only active in this area:

X axis is N (RPM) and Y axis is p_saug (MAP pressure)



At idle the sensor is active through to light-medium load, and at higher RPM it's active only at light load. Why would BMW go to all that effort and limit it to that range? Because that's where it's needed, and it's where it's effective.

Below is two slightly different views of the same data. We can see that at aq_rel between 0 and 1.5 (out of 100!) the MAP to aq_rel response is linear and at a slope that provides good definition. Above this (1.5-100) the slope flattens out a lot and pretty much anything high load starts to look the same. We can see there is slight shift based on N (RPM).

The area of the curve that kf_rf_p_saug_i_gain targets is the first part where the MAP sensor input is useful. At higher loads where the MAP sensor slope is too flat the RF calculation relies on aq_rel_rf alone.



Why do we bother with all of this? Because calculating rf_soll (CSL Alpha N table) is just a calculated value based on throttle opening. It doesn't properly take into account real world conditions. The MAP sensor measures the actual pressure in the ITBs at a moment in time and therefore can calculate the actual airmass. This is why the MAP sensor gives smoother response at idle/part throttle driving.

When running M3 cams the MAP sensor calculations actually need to be adjusted to account for the different cams. Otherwise the MAP integrator tends to bounce off one or other of it's limits (I've got a log somewhere from nearly a year ago that demonstrates this, but can't find it at the moment). This doesn't mean it isn't helping, but it's not able to fully adjust (also the end result it's targeting is based on CSL cams not M3 cams).

With this adjusted for we can see rf_p_saug_i sitting comfortably within its limits, able to adjust up/down as needed. We can also see in this snapshot evidence of rf_p_saug_i (the integral) change being suspended under load conditions.



Very cool.

Where to next? I'll do some more logging on this, In particular I want to get some more logs of idle conditions, etc. to see if I can reproduce the same very steady idle that Bry5on is finding. I'll also log a range of driving conditions to observe how the MAP sensor influences RF calculation (basically real-world logging of the behavior I'm expecting to see based on the disassembly work).

[karter16]

Mine is rock steady in closed loop except for occasionally on hot starts, +/-4rpm or so. Weird.

That's with the MAP sensor enabled and tuned right? The logging I'm currently doing is with MAP sensor adjustment to RF disabled. I was thinking last night about the fact you have rock solid idle rpm and have been trying to get clear in my head how the MAP sensor is influencing that positively. There's so many things at play at once so I haven't quite got it clear in my brain, but I'm presuming that the variation in fuelling from the lambda oscillation is driving a corresponding difference in airflow which the MAP sensor identifies and effectively cancels out. But that's conjecture cause I haven't figured out yet exactly how it's happening.

Anyway - if I re-enable the MAP sensor and get it appropriately tuned I should be able to confirm this.

[Bry5on]

Mine is rock steady in closed loop except for occasionally on hot starts, +/-4rpm or so. Weird.

[karter16]

Very interesting find! PI gains could definitely create a nice oscillator.

Yeah it'll be interesting to see if anything comes of it. I think to a large degree the issue is at idle the plant lag means it takes longer for changes in fuelling to reach the O2 sensor and flip it from lean to rich and vice versa. Which is why, I think, at idle the Lambda integrator period is 3.5 to 4 seconds and the magnitude is much higher than at load, so not sure how much is able to be done about it. Not even sure if it's a problem to be solved so to speak, it's interesting/annoying though seeing N nice and flat during open loop warm up, and it then starting to oscillate when closed loop kicks in.