Karter16

TunerPro have a bunch of xdf's (definition files for tunes) for the Motronics as well as binary reads of the tunes - might be worth poking in to: https://www.tunerpro.net/downloadBinDefs.htm#BMW

Yeah absolutely. I was going to reply to your thread when I got a chance. The key thing is to figure out what processor your ECU runs - I think you're Motronic 1.0 right which is some derivative of the Intel 8051 I believe. Ghidra has def files for the 8051 I believe so you might be in luck. The second thing which is really needed is some sort of definition file which describes the locations in memory of parameters, etc. so you've got something to start with. From there it's a case of loading in Ghidra, trying to find code blocks, data blocks, etc. In terms of other tools it's pretty much just been Excel, TextEdit, and the like. Do you have a read of the program ROM from your ECU?

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.

Well I placed the order with Apex last night. I've taken some good 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 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!

Thanks for this - great review!

Thanks heaps for this - obviously my searching last night sucked! Given I've put less than 25,000km on the car in the last 10 years I'd say the 40,000km life won't be a problem lol. Great idea! hadn't thought of that - thank you!

What I really want is the PSS5 but they're not released in anything under 20 inches yet 😛 General consensus from what I've read is that the PS4S is the one to have, so plan to stick with that.

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.

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 🙂

Finally made it to this thread! As soon as I saw your car I knew today was the day! here’s the matching photo I took:

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.

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.

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.

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

Well 2 days of driving an excavator, 4 months of weekends, 300m of rebar, 14 tonnes of concrete, 232 CMU blocks, and a lot of manual labour my retaining wall is complete - finished backfilling it today. Starting to get a bit wet here for the winter so great timing. Bit of a general update on the car. The latest version of the SMG reservoir bracket is in use, I've got some more tweaks to make to it so will do that and print the latest iteration. The MAP sensor adapter in CF-PETG shows some evidence of softening. It seems, under the clamping force of the bolts, it's not quite up to the ~100 degree C temperature that the rail hits. Plan is to get this printed in GF-Nylon which should be able to handle beyond 150 degree C temps. I'm doing some preliminary work on the reinstallation of the trunk interior with the RACP brace in place. Working through a few things to get to a lightweight, high-quality solution that meets my need to make it look as OE as possible. The version of the CSL tune I've been running the last while seems super stable. Even as it's got colder here it's remained super smooth. Seems I've got the warm-up maps pretty much spot on. I still want to do some more fine-tuning, and in particular am keen to try out running the fuel tuning process with the MAP sensor integrator turned off, but it's not top of the priority list given what I'm currently running is so good. Planning to get the headliner out and off to the pros to redo with the BM-134 fabric that I have stashed. I've also got brand new A/B/C pillars to go in once it's reinstalled. Intend to make more progress with the 0401 disassembly as well - especially as the days get shorter and the weather gets worse. Lots of little bits and pieces on the go. I've also been enjoying driving the car. The refreshed diff bushes have eliminated any remaining clunk in the drivetrain. Combined with the smoothness of the CSL tune it makes for lots of enjoyable downshifts with no need for the manual throttle modulating that I'd previously gotten used to to minimize the thunk. Secondly the RACP brace has, in addition to providing top-side support to the RACP, made an enormous difference to the torsional rigidity of the rear of the car. It's a very significant improvement and I'm getting itchy to give the front of the car similar treatment 😛