Karter16's Silbergrau E46 M3 Journal

[Arclitgold]

Does this help in the meantime? https://cad.onshape.com/documents/40...f5b6a01462b639

YES! Thank you Bry5on!

also looking forward to see how yours pans out karter16

[karter16]

Finally! v7467 (exaggerated) is the one!



Now that I've got the placement spot on I'll take those datum planes/points and model up a final clean version.

[Bry5on]

Any chance you’d share the STL of that ash tray insert once it’s done? I’ve been looking to print something similar!

Does this help in the meantime? https://cad.onshape.com/documents/40...f5b6a01462b639

[karter16]

Any chance you'd share the STL of that ash tray insert once it's done? I've been looking to print something similar!

Yep for sure, will be happy to share once I've got it sorted. Worth noting that the version I'm currently working on is for RHD Cars. I could do a LHD one fairly easily, just would need to be mirrored and have the layout of the retainer changed to accommodate the fact the board itself stays the same (ie not mirrored).

Also thought I saw a post here from Avedis but it seems to have disappeared. Anyway, the answer is that I'm planning to measure the size of the tray and cut the insert to fit. Happy to share the measurements once I've got it nailed.


Sent from my iPhone using Tapatalk

[Arclitgold]

Any chance you’d share the STL of that ash tray insert once it’s done? I’ve been looking to print something similar!

[karter16]

So I ordered some Alcantara soft today to make myself an insert for the CSL centre console. Shelling out for a genuine one seems excessive so will go the route of making my own. I'm planning to 3D print a template to trace with a blade to cut the piece out.

The other thing that I'm planning to look into on a (literal) rainy day is a script to intercept files coming across FTP from the Gauge.S and to rename them sequentially. One of the issues with Gauge.S is that if it doesn't have the current time from a time server it reverts to an incrementation-based naming convention based on what files already exist on the SD card. This means you end up with a bunch of files named something like GaugeS-1.csv with no easy way to tell which is which. If you happen to be connected to wifi at the time the log starts it's all good. The other way to address this is to use the GPS module to acquire the current time.

I suggested to Sorek that a useful little option would be to store a global variable on the SD card with the current file increment. That way it could persistently assign the next increment, regardless of what files still existed on the SD card. Unfortunately Sorek advised he wouldn't be doing this as he considers it "clutter" and that his solution is to buy the GPS module. Given I have no other need for the GPS module I refuse to use that much hardware to solve such a simple problem so will look to solve this server-side on the FTP server.

[karter16]

Big fillets all around and print it sideways! They're for sure gonna snap if you print it like it's oriented in your screenshot. Printing sideways will make the screw holes super easy to split open, so grab yourself some big washers or maybe open up the holes a bit and press/glue in some metal sleeves.

Could also print at 45 deg for to give strength to both the tabs and screw holes. You'd probably want to model in your own supports though, otherwise you're gonna be printing out an entire forest under that part.

Also, for a second I thought you were gonna gut the small screen radio and design a retainer to hold the Gauge.S inside. Would honestly be pretty cool, but you'd have to figure out what to replace the audio components with. Gauge.S + BlueBus + some custom board to handle I bus commands for the buttons + modern amp stuffed in there sounds neat.

Yeah definitely planning to print sideways. True that it might make the screw holes split, but those ones are thru-holes anyway so hopefully won't be seeing enough load to be split by an M2.6 screw. I figured I'd print this version to test the fitment etc. and then can beef up where I need to for the final print.

Gutting the radio would actually be a really cool project. I'm already running an Xtrons the same as Bryson, but if I wasn't this would be a cool option.

[heinzboehmer]

Big fillets all around and print it sideways! They're for sure gonna snap if you print it like it's oriented in your screenshot. Printing sideways will make the screw holes super easy to split open, so grab yourself some big washers or maybe open up the holes a bit and press/glue in some metal sleeves.

Could also print at 45 deg for to give strength to both the tabs and screw holes. You'd probably want to model in your own supports though, otherwise you're gonna be printing out an entire forest under that part.

Also, for a second I thought you were gonna gut the small screen radio and design a retainer to hold the Gauge.S inside. Would honestly be pretty cool, but you'd have to figure out what to replace the audio components with. Gauge.S + BlueBus + some custom board to handle I bus commands for the buttons + modern amp stuffed in there sounds neat.

[karter16]

Looks very nice! Are you worried about snapping off those little PCBA mounts on the retaining triangular piece? They look pretty fragile.

Yeah I certainly am - as you say they're very tiny. This next prototype will hopefully give me a feel for how much they need to be beefed up. I need them to be flexible enough, but strong enough.


Sent from my iPhone using Tapatalk

[Bry5on]

Looks very nice! Are you worried about snapping off those little PCBA mounts on the retaining triangular piece? They look pretty fragile.

[karter16]

Another CAD design project I've been working on has been my own take on the Ashtray insert for the Gauge.S.


Firstly, I wanted to inset the screen at an angle in the same way the displays are on the OE dash components (radio, aircon, etc.). I used the 8385074 radio for inspiration as the screen is not a completely dissimilar size and aspect ratio to the SSD1309 that the Gauge.S uses.





This is what it looks like in Gauge.S ash-tray insert form:



The welcome side-effect of positioning the screen at a slight angle is that it also makes for a less cramped install of the display, and less sharp bending of the ribbon cable.

The screen is held in place by the yellow retainer which I've opted to screw into place. The screws add complexity, however give me better and stronger retention, allowing me to use the other side of the retainer to hold the board. (note the lower left retaining clip is a different shape to the others due to the location of a resistor on the board at that location)





The other significant addition I've made is to add a TE AMP 5 pin header on the back so that the unit is much easier to install and remove.:



The header attaches to a sub-cover which is installed after the display and board are in place allowing for easy assembly. There's enough space underneath the sub-cover for the GPS module (not that I have one), and there is enough space next to the header to put a second one next to it, or indeed 1 larger one if so desired (I am logging everything over CANbus so I only have need of the single 5 pin connector).

I've tested fitted the display into a first prototype of the main body, and have this second prototype out for printing now.

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