Karter16's Silbergrau E46 M3 Journal

[karter16]

Manufacturing for my design is close to being done! Should be in my hands in a couple weeks. Once finalized, installed and validated, I'll make it available for all.

Not sure what your plans are for the front end, but I guess I'm just excited to get my braces installed

Very much looking forward to seeing it installed!


Sent from my iPhone using Tapatalk

[karter16]

Well yesterday and today I tackled a job I've long been putting off.

Yesterday I took the headlining out of the car, and dropped it (along with the sunroof cover, etc) plus the BM-134 fabric off to a professional headliner upholsterer. The dude was a legend and had it ready for me to pick up this morning (think he was grateful that I'd done the hard work of taking it out of the car!). He was very complementary of the BM-134 fabric - he said it's a quality fabric with quality foam and was lovely to work with.

I'll tackle pretty much any job on the car, but this is one of those few things I'm very happy to leave to a professional - the work is flawless and it looks incredible.

For those wondering about the fabric match - I took some photos of the re-wrapped headliner against one of the interior trim pieces which has the original BMW fabric on it (non-foam-backed):







It's a very close match and certainly once it's in the car you can't tell at all - the slight difference really only shows up in photos.


Likewise it matches well against the new A/B/C pillar trim I bought (which fortunately all match each other as well - as that was a problem for a while):




While the headliner was out I took the opportunity to pull out the wiring a PO had put in for a radar scanner - I removed the T-Tap connectors, insulated the wires and wrapped in Tessa tape:







In order to remove the sunroof cover to retrim it I also had to remove the sunroof glass - I took the opportunity while it was out to give the frame a good clean and re-lubricate with graphite lubricant:




I reinstalled the headliner and then got on to installing the new pillar trim - shiny new B-pillar covers:





Then the C-pillars, along with the foam insulated clips:



And lastly the A-pillar trims and inserts with the airbag logo on them. Notably the A pillar inserts are a significantly different shade to everything else. (which is hilarious given this is all new OE parts). If it annoys me too much I might order replacements and hope for a better match.

I'm very happy to have this done - it's not a particularly fun job but very satisfying to have everything refreshed and like new.







You can see the huge difference in shade between the new a-pillar and the insert 🙄.

[karter16]

The MAP sensor adapter printed in CF-reinforced Nylon arrived today. Minimum order value applied so I'm now the proud owner of 12 of these.

I'll try to install in the next couple of days. HDT is significantly higher than the CF-PETG I used previously.

[0-60motorsports]

The MAP sensor adapter printed in CF-reinforced Nylon arrived today. Minimum order value applied so I'm now the proud owner of 12 of these.

I'll try to install in the next couple of days. HDT is significantly higher than the CF-PETG I used previously.

I can always take one off of your hands. Let me know brother.

[bmwfnatic]

The MAP sensor adapter printed in CF-reinforced Nylon arrived today. Minimum order value applied so I'm now the proud owner of 12 of these.

I'll try to install in the next couple of days. HDT is significantly higher than the CF-PETG I used previously.

Yeah send me one as well since you said not to use the previous one 😂

[ugaexploder]

that would be awesome, sign me up as well

[karter16]

Whole family (including myself) are sick this weekend so took the opportunity to try out doing a VE table tuning run with the MAP sensor turned off. I've been wanting to do this for a while as theoretically it's another variable that can be removed from the process. With the MAP sensor taken out of the RF calculation path the car is essentially running in "Alpha-N Mode". My theory behind this is that depending on point in time conditions the MAP sensor is adjusting the final RF either up or down from what's calculated from the VE table. While this is desirable in day to day use, for the VE tuning process it's an unwelcome additional variable.

Unfortunately I can't really think of an objective way to measure the impact of it to the VE tuning process, so it's really just a subjective assessment I guess.

The difference with the MAP sensor disabled is immediately noticeable in the part-throttle conditions the MAP sensor targets. The car is less responsive and throttle input is jerkier and less consistent. I found a couple of RO/RPM conditions which I hadn't previously been able to flush out.

I intend to do another tuning run tomorrow or Monday on a day when I can get further out and up the RPM range more to get a more complete test.

It would need more people to try this out and get their subjective feedback as well as to whether disabling the MAP sensor positively influences the VE tuning process (I think it will mostly be about the speed at which one arrives at the end result), but I am pleased to have finally proven out that changing the configuration byte from 0x12 to 0x02 does behave as expected.

Oh and also gave the nylon MAP sensor adapter a couple of good heat cycles and then took it off and inspected it - appears to be unaffected by the heat so far, so off to a good start.

[Bry5on]

Whole family (including myself) are sick this weekend so took the opportunity to try out doing a VE table tuning run with the MAP sensor turned off. I've been wanting to do this for a while as theoretically it's another variable that can be removed from the process. With the MAP sensor taken out of the RF calculation path the car is essentially running in "Alpha-N Mode". My theory behind this is that depending on point in time conditions the MAP sensor is adjusting the final RF either up or down from what's calculated from the VE table. While this is desirable in day to day use, for the VE tuning process it's an unwelcome additional variable.

Unfortunately I can't really think of an objective way to measure the impact of it to the VE tuning process, so it's really just a subjective assessment I guess.

The difference with the MAP sensor disabled is immediately noticeable in the part-throttle conditions the MAP sensor targets. The car is less responsive and throttle input is jerkier and less consistent. I found a couple of RO/RPM conditions which I hadn't previously been able to flush out.

I intend to do another tuning run tomorrow or Monday on a day when I can get further out and up the RPM range more to get a more complete test.

It would need more people to try this out and get their subjective feedback as well as to whether disabling the MAP sensor positively influences the VE tuning process (I think it will mostly be about the speed at which one arrives at the end result), but I am pleased to have finally proven out that changing the configuration byte from 0x12 to 0x02 does behave as expected.

Oh and also gave the nylon MAP sensor adapter a couple of good heat cycles and then took it off and inspected it - appears to be unaffected by the heat so far, so off to a good start.

Now I'm curious to try this! Good thinking.

[karter16]

Now I'm curious to try this! Good thinking.

Very keen to hear how you get on if you do this!

[karter16]

Pretty sure I've finally found a source for the male MAF sensor connector that allows for MOQ of 1 (and it's cheap to boot).

This is what I'm talking about:



I've ordered a couple to check and confirm, but if it is then this is the missing piece for people to be able to build their own harness extensions (and IAT relocation extensions I guess, not that I think they're good idea) without having to pay Turner mark-up. It also means anyone wanting to do what I did (keep the MAF connector and wire up for MAP sensor) doesn't have to buy a Turner extension just to then hack it up to add on the Bosch MAP sensor connector, etc.

I'll wait til these arrive and I've confirmed and then put up a post with all the various part numbers needed to do this.

[0-60motorsports]

Pretty sure I've finally found a source for the male MAF sensor connector that allows for MOQ of 1 (and it's cheap to boot).

This is what I'm talking about:



I've ordered a couple to check and confirm, but if it is then this is the missing piece for people to be able to build their own harness extensions (and IAT relocation extensions I guess, not that I think they're good idea) without having to pay Turner mark-up. It also means anyone wanting to do what I did (keep the MAF connector and wire up for MAP sensor) doesn't have to buy a Turner extension just to then hack it up to add on the Bosch MAP sensor connector, etc.

I'll wait til these arrive and I've confirmed and then put up a post with all the various part numbers needed to do this.

Awesome thanks mate

[karter16]

Time for a quick update on a few things.

I've been doing a bunch of playing around with the VE tuning process for a couple of reasons:

Firstly when I was working through documenting how the CSL MAP Sensor is used in the DME it occurred to me that it was probably a good idea to take the MAP Sensor out of the loop of the RF calculation while performing the VE tuning process, as otherwise it would be compensating for underlying inaccuracies in the VE table and otherwise masking and making things more difficult.

Secondly when going through the disassembly in detail I uncovered that the AQ_REL value that is logged from DS2 (in TestO) is not in fact the value that is used for the CSL AlphaN table. Rather a modified form of AQ_REL is used which inflates the AQ_REL value by a varying amount below 2400 RPM.

Addressing the first piece is a case of changing a parameter in the partial binary to disable the MAP sensor, and I solved the second piece with a spreadsheet to convert TestO logs before putting them through the rest of the VE tuning process.

This has been a great success. In the space of 3 tuning runs I've gone from something that (even after earlier VE tuning without addressing these two things) felt like an AlphaN tune (which it absolutely is with the MAP sensor turned off), to something so good, it feels like the MAP sensor is enabled, even though it isn't. (of course this won't extend to changing atmospheric conditions, etc. but gives you an idea of the improvement). Particularly low RPM rev matching is superb now with the AQ_REL values that are logged being accurately used to adjust the VE table.

After just 3 runs everything is consolidating beautifully around a lambda of 1.0. (the couple of cells that show greater change are cells that I didn't manage to hit in previous runs).




I've also been doing some investigation into adding an additional CANBUS message for the DME to send to allow for high data rate acquisition of key variables that currently aren't on CAN. This is a project that requires modifying the program ROM and as such will be a decent chunk of work to get done, but there are a few people keen for this and it seems like a fun winter challenge to figure out. I do want to spend some time working through the safety concept mechanisms to ensure that the safeguards in place in the DME would appropriately handle any edge case bugs or timing/performance issues that might be inadvertently introduced by such a change, but both the Master and Slave CPUs independently handle all key safety functionality, so given the changes will be only to the Master program ROM the risk should be manageable.


I'm also satisfied now that the CF-Nylon version of the MAP sensor adapter is up to the job. I'll try mailing (rather than couriering) one to bmwfnatic as a test to see if the postal service accept it (it's right on the 10mm thickness limit). If that all goes okay then it will be practical to make these available to others at a reasonable price (no one will want to pay the $$$ for courier shipping from New Zealand). I'm pretty staunchly of the view that I don't want to make money out of this hobby and its community. I'd much rather contribute in ways that we can all openly benefit and learn from. But also I have a bag of these things sitting on my desk that won't get used otherwise and it seems a few people are keen. I'm thinking that I'll work out a price that covers the portion of the printing cost + postage + a few bucks to cover my time to package and send (and share that cost breakdown with everyone for transparency) and that way people who would find it easier to pay to get one of these can. Important to note that the CAD file for this is freely available here so if you have a printer / have a mate who has a printer / want to order your own from somewhere else you should totally go do that instead :-)