Karter16's Silbergrau E46 M3 Journal

[heinzboehmer]

Ah that's annoying. Hopefully it doesn't take too long to resolve!

[karter16]

Ah that's annoying. Hopefully it doesn't take too long to resolve!

yeah - not an ideal situation to be dealing with but it is what it is. Will see how I get on when I hear back from Sorek (think he was on vacation until today). I appreciate it's a tough one with this sort of product. As far as he's concerned I equally could have done something wrong to fry the board so will see how it goes.

[heinzboehmer]

yeah - not an ideal situation to be dealing with but it is what it is. Will see how I get on when I hear back from Sorek (think he was on vacation until today). I appreciate it's a tough one with this sort of product. As far as he's concerned I equally could have done something wrong to fry the board so will see how it goes.

He's pretty cool about replacing HW. He sent me a couple boards when we were debugging the FW for the latest HW. They cost nothing to manufacture, so retaining the client is likely worth a lot more than one board.

Also, he's pretty active on the Gauge.S discord, in case you need to reach him quicker.

[karter16]

He's pretty cool about replacing HW. He sent me a couple boards when we were debugging the FW for the latest HW. They cost nothing to manufacture, so retaining the client is likely worth a lot more than one board.

Also, he's pretty active on the Gauge.S discord, in case you need to reach him quicker.

You were spot on with this advice. He did some quick troubleshooting with me over email to confirm the board is at fault and he's shipping me out a new unit this week :-)

[karter16]

So it was in fact the display that was at fault!



Stoked to have this sorted and have captured a test log.

The harness extension I'd made up worked perfectly. Simply intercepts at the steering angle sensor. I will be logging everything I need over CAN, so no need to do anything with the K-line. The 12V power to the steering angle sensor is from Terminal 15 so perfect for this use.

[karter16]

Now that I'm setup for CAN logging I finally got a chance to try out my custom program and tune ROMs that allow for configuration of the additional CAN messages (7D0 and 7D1) in the partial binary (see here for the background: https://nam3forum.com/forums/forum/s...454#post310454).

The good news is that it all worked first time! (to be fair I put a lot of effort into checking and rechecking the code to make sure it was right)

First up I flashed the custom program to the DME and ran it with the standard tune. I've designed this such that if someone uses the custom program with a tune file not designed for it the additional functionality is simply disabled. Likewise if someone uses the custom tune with the standard program it is also gracefully handled.

I then verified that DME functionality was as expected. E.g. normal function and no additional CAN message activity. All was well.

I then added the new parameters to my tune file:



and flashed the tune. Sure enough everything still worked, and the 7D0 CAN message was present on the CANbus.

Here are the values being logged.



I've got some more scenario testing to do. e.g. test the 7D1 message as well, intentionally put bad data into the config parameters and make sure it's handled gracefully etc. but super stoked all is working so far as this is the most complex change I've made to the program so far!

Onwards and upwards - this functionality will be very useful to me as I dive into more refinement of my tune now I have high-frequency CAN logging available!

[karter16]

Well I'm finding the ability to configure the CAN messages very useful as I dive into understanding the RF calculations in more detail. I'm currently looking to understand the effect that things like TETV (tank ventilation), BA (fuel enrichment), etc. have on the repeatability of the lambda logging, and being able to easily swap around what I'm logging is a massive time saver. It's simply a case of:

1: look up the variable I want to log
2: update the address into the tune file parameter
3: update the Gauge.S config with the parameter name and conversion factor.


I also came across the first thing (DKBA - After-Spray) I want to log that is only available on the Slave CPU (it was only a matter of time), so the CAN logging feature now needs to be expanded to handle that. I confirmed a couple of weeks ago that the DPR (dual-ported RAM) is only about half full, so there's room for sure to use. I plan to prove the concept in a very similar way to what I did for the CAN send. I'll replace an existing function call in the Slave 10ms Task with a new function call which then calls both the original function and my additional function. That function will then copy the relevant memory address to the DPR.

Once I've proven it out I'll probably then look to build out the ability to configure a set number of bytes to be pushed to the DPR so they can in turn be inserted into the CAN messages. The approach would be the same, parameters in the tune file that configure which Slave-only variables to push to the DPR. The parameters would be checked for valid address same as I am doing for the CAN parameters. I imagine 8 bytes (e.g. 1 whole CAN message) would be enough for all practical purposes.

[karter16]

I've had a few weeks of being very busy with work and family, and now myself, sick.

I've still found some time to work on projects - progressing my tune under heavy closed-loop load, figuring out my persistent lean condition with aircon on (and finding a bug in the Terra full binary in the process), getting more done on the XDF, etc.

This evening I found myself without much energy to do anything, so took the opportunity to do something I've been wanting to for ages. A direct comparison of KF_RF_N_AQ_REL and kf_rf_soll.

Quick reminder:
KF_RF_N_AQ_REL: The AlphaN map for the standard M3.
kf_rf_soll: The larger AlphaN map for the CSL.

The comparison is not entirely straightforward as the two tables differ in size in both dimensions. This means interpolating both axes. Once that is done then you have to account for the fact that the y-axis for KF_RF_N_AQ_REL is AQ_REL, whereas for kf_rf_soll it's aq_rel_rf which is a variably modified version of AQ_REL under 2400rpm.

A bunch of excel later (which I'm sure would have been quicker if my brain was sharper) and I was able to spit the result out.

Here's a comparison of the two maps (y axis in aq_rel_rf). number less than 1 means KF_RF_N_AQ_REL has more fuel in that cell and likewise greater than 1 means kf_rf_soll has more fuel.



It's important to note that the two still aren't entirely directly comparable as the injection tables differ somewhat between the CSL and standard M3. I will do these adjustments next, but I'm more just interested to see the patterns and if there's anything that can be extrapolated into the VE table for cells that are hard to hit in VE tuning. Interesting as well to run this comparison against my current VE table and see the areas of convergence, etc.

[karter16]

I've been experimenting with some changes to my tune. In particular some of the differences in the idle controller parameters. There's some fairly subtle differences between the standard M3 and CSL which are almost certainly due to the CSLs different cams and exhaust valves. Given I'm running pretty much standard M3 VANOS/ignition/fuelling in this area it makes sense to me to port these differences across as well. I'm going to do a VE tuning run and then drive on these parameters for a bit and see if I can notice any difference/improvement/degradation. I am seeing a little bit of difference in the VE measurements before and after but very hard to tell whether that's due to these changes or just environmental variability.

The second thing I've been experimenting with is the lambda PI controller gains. These are fairly different between the standard M3 and the CSL. In general both I and P gain is higher in the CSL than standard M3. I've been looking at the logs and am pretty confident that this is what's responsible for the oscillation of N (rpm) at idle between about 860 and 890 rpm. N rises and falls in phase with the same period as the (intentional) oscillation of the lambda controller. As fuelling is varied based on instantaneous lambda it has the effect of driving N high then low.

Initial logging suggests that the end result between the standard M3 and CSL gains is fairly similar (again which makes sense) but will probably play around with this some more to experiment. It also occurs to me that before I go too far further down this path I should probably replace my O2 sensors with new ones.

Anyway interesting stuff.

[Bry5on]

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

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

[Bry5on]

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

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

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

[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