Karter16's Silbergrau E46 M3 Journal

[karter16]

Well it's been an exciting weekend.

On Thursday I got stuck into the additional CAN message project. As a recap the idea here is to add an additional function into the 0401 program binary to send an additional CAN message.

I've given the new message the ARBID of 0x7D0 which makes it lower priority than all other CAN messages. The format of the message is:




There's basically 4 parts to achieving this:

1: Create a new function that replicates the existing function to send CAN messages from the DME. It needs to be recreated as we need space for the extra instructions to call an additional CAN message.
2: Modify the 10ms task to point to our new function instead of the original.
3: Load our new CAN message definition into the CAN config table in the program ROM.
4: Create a new function to assemble the new CAN message and push the frame to the CAN buffer.

The fun part is that this needs to be done by modifying the machine code in the binary, no easy way to write assembly or C here!

I got the above done on Thursday, spent code-checking it and then flashed it to my car on Saturday morning. As soon as I turned the ignition on I could tell something was wrong as the DSC light was flashing. All modules relying on outbound CAN were throwing errors. A review of what I'd done revealed a dumb mistake. I was trying to use slot 17 of a 15 slot buffer 🤦♂️. Anyway it was an easy fix and v1.1 ran without issue, and I connected to the MK60 with INPA and could view live CAN data, so I knew the standard CAN messages were working fine.

I'm not actually set up for CAN logging so at this point I shipped the binary off to Bryson for further testing.

I was very excited to get this back from him showing the new message being logged:



Bryson then setup his logger with the appropriate conversion factors and has been able to log AQ_REL, Lambda Integrator, etc. at 100Hz instead of the 5Hz or so that you get over DS2. He's posted a link to the log which you can find in his post here

I'm super stoked that this has worked out. In addition to being very useful for tuning, it also proves that these sorts of modifications are possible and that the disassembly work is good enough to understand what's going on to the degree that it's possible to make working changes and additions to the program.

Also - the new wheels are in the country and should hopefully arrive end of next week. Tomorrow's job is sorting out tires.

[George Hill]

I run 255 on 9" et42 wheels on a lot of swaps, no issues with strut clearance and Konis so your 245 should have miles of clearance.

[karter16]

Well I placed the order with Apex last night. I've taken Bry5on 's advice and gone with 18x9 up front (245/40) and 18x9.5 (255/40) at the back, which gets closer to square, while also getting me a good offset (ET42) at the front. Why not go fully square? Firstly, I don't drive the car enough km's for it to really matter from a tyre wear perspective - these new tyres will likely go the way of the old ones before I wear them out. Secondly it means I don't have to worry about spacers on the rear wheels like I would really need to if I went square to suit the fronts. In NZ wheel spacers automatically mean you need a low volume vehicle cert which, as previously covered, I am intending to avoid.

I used willtheyfit.com (thanks George Hill!) to compare this setup with the various stock M3/CSL setups, and got a little concerned about how close the edge of the tyre tread will end up to the front spring perch on the Koni's. As has been identified by others the shape of the perch on the front right strut lends itself to running slightly closer to the tyre, and it's very close indeed. Although the new setup is a few mm shorter it's also closer to the strut and I was concerned it might be too close. When I compared the measurements against my car I couldn't see how it was going to work. Then when running the comparison for the 3rd time I realised I had made the amateur mistake of relying on a (top-google-ranked) post on another forum where that person had misquoted the offset on the 19in Style 67's. With the correct offset keyed in I was then satisfied that the new wheels should be an appropriate fit.

The wheels are coming UPS expedited, so will likely be the usual case of arriving in New Zealand in a week or so and then spending the next week sitting in the distribution centre in Takanini. I'll get some quotes for tires this week so that they're ready to go when the wheels get here.

Thanks everyone for your thoughts and advice on this, suddenly urgent, project!

[karter16]

I think offset is most important, then rim width, then tire width. You can run a pretty good offset with a 9” wide wheel which means a 245 tire. I run 17x9 et45 with 245/40/17 and I find it’s really nice, doesn’t give up anything over a narrower tire by my hand. I think either way you’ll be happy, but personally I prefer a little closer to square for a tire with 50/50 weight distribution. If I had an M3, I’d probably be running either that setup, or an 18x9.5 et41 front with a 255/40/18 square. But there are no wheels in that spec, so 245

Awesome thank you so much for this - I really appreciate the guidance. This seems like the perfect option for me!

[Bry5on]

Interesting - This wasn't one of the options I looked at last night. Thanks for this. I hadn't really thought to go wider than an 18x8.5 up front but willtheyfit shows the end result from a circumference perspective is very close. If you're suggesting it you presumably thing that the bit of extra rubber up front would be an improvement in handling? ( I'm not an expert at all in this space so very happy to take your advice)

I think offset is most important, then rim width, then tire width. You can run a pretty good offset with a 9” wide wheel which means a 245 tire. I run 17x9 et45 with 245/40/17 and I find it’s really nice, doesn’t give up anything over a narrower tire by my hand. I think either way you’ll be happy, but personally I prefer a little closer to square for a tire with 50/50 weight distribution. If I had an M3, I’d probably be running either that setup, or an 18x9.5 et41 front with a 255/40/18 square. But there are no wheels in that spec, so 245

[heinzboehmer]

Yep, tire rack has them, as do a bunch of other vendors in the US. Maybe just not as readily available in NZ.

I hope they start discontinuing them soon, I'm excited to try the new PSS5, but so far they have only released them in R20 and R21.

Edit: Wait! They actually do have them in R18 now, amazing: https://www.michelinman.com/auto/tir...-pilot-sport-5

Sizes are still a bit limited, but that should improve as time goes on. Now I'm excited for my next set of tires.

Maybe look for those instead of PS4Ss.

Edit 2: Nope, those are PS5 not PSS5. Damn. I have to say, their new naming scheme is confusing.

[karter16]

Unconventional suggestion: run 18x9 et42 245/40/18 front with 18x9.5 255/40/18 rear

Interesting - This wasn't one of the options I looked at last night. Thanks for this. I hadn't really thought to go wider than an 18x8.5 up front but willtheyfit shows the end result from a circumference perspective is very close. If you're suggesting it you presumably thing that the bit of extra rubber up front would be an improvement in handling? ( I'm not an expert at all in this space so very happy to take your advice)

[karter16]

Hmm, they definitely do. Have a set on my car right now

So this is the thing - I can't find them anywhere. So I don't know if they've stopped making them? There not listed as a size on Michelin's website (either their NZ one or USA) likewise every tire supplier I check doesn't have that size listed. If you have a source I'd be very interested.

Edit: I obviously didn’t look hard enough last night and someone else has sent me a tire rack link with 235/40R18. Thanks for this!


Sent from my iPhone using Tapatalk

[heinzboehmer]

Apex suggest 235/40 for the fronts and 265/35 for the rears, but Michelin PS4S's don't come in a 235/40R18

Hmm, they definitely do. Have a set on my car right now

[Bry5on]

Unconventional suggestion: run 18x9 et42 245/40/18 front with 18x9.5 255/40/18 rear

[karter16]

Well I found a circumferential crack in the inside wall of the front right today... The tires are old and I've been keeping an eye on them for this exact reason. I was hoping to get another 6-12 months out of them, but that's not going to happen and I need to get this sorted.

My plan was (and probably still is) to shelve the 19in Style 67's and get some 18in ARC-8's (original I know, but quite simply can't come up with a better weight/quality/value/looks combination) and buy the new rubber for those rather than the 19s. I'm focused on driving experience and the 18s will be much better suited to Auckland roads than the 19s plus the weight savings will be very welcome.

I'm thinking to go with 8.5" fronts and 9.5" rears with ETs to match to keep close to CSL spec. Apex suggest 235/40 for the fronts and 265/35 for the rears, but Michelin PS4S's don't come in a 235/40R18, so I'm wondering whether 225/45 and 255/40 would be a suitable option as that's very close to OE specs as it pertains to circumference.

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

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

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.

[karter16]

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

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