Karter16's Silbergrau E46 M3 Journal

[karter16]

Do you have the part numbers for the titan shadow shifter trim and dash trim kit? I'm trying to replace my brushed aluminum interior to a CSL lookalike trim and having a hard time figuring out the difference between the titan shadow trim and the titan trim. Yours looks to be what came in the CSL unless I'm incorrect in thinking that's what the CSLs came with.

Hey I do indeed - yes correct, the Titan Shadow trim is what came on the CSL (and what my car was originally spec'd with) - however my car is a RHD so unless you're also RHD the part numbers will be different:

RHD parts are:

Genuine BMW Bottom panel, storage partition, Titan	51167904342
Genuine BMW Decor strip,paint. tita.,instr.panel lft	51417904349
Genuine BMW - Decor strip,paint.tita.,instr. panel ri.	51457904350
Genuine BMW Decor str.,paint. tita.,instr.panel cntr	51457904352

If you search RealOEM for LHD M3 CSL you'll get the correct part numbers for an LHD.

[Kipjames3]

Hey I do indeed - yes correct, the Titan Shadow trim is what came on the CSL (and what my car was originally spec'd with) - however my car is a RHD so unless you're also RHD the part numbers will be different:

RHD parts are:

Genuine BMW Bottom panel, storage partition, Titan	51167904342
Genuine BMW Decor strip,paint. tita.,instr.panel lft	51417904349
Genuine BMW - Decor strip,paint.tita.,instr. panel ri.	51457904350
Genuine BMW Decor str.,paint. tita.,instr.panel cntr	51457904352

If you search RealOEM for LHD M3 CSL you'll get the correct part numbers for an LHD.

Oh yeah I forgot you can search that way on there. I just always put my VIN in. Thank you!

[karter16]

FYI (in particular ugaexploder and wahsm) I've published the STL for the MAP sensor adapter - new post in the sticky: https://nam3forum.com/forums/forum/main-forum/e46-2001-2006/271707-e46-m3-community-designed-cad-files-master-list?p=290245#post290245

[ugaexploder]

FYI (in particular ugaexploder and wahsm) I've published the STL for the MAP sensor adapter - new post in the sticky: https://nam3forum.com/forums/forum/main-forum/e46-2001-2006/271707-e46-m3-community-designed-cad-files-master-list?p=290245#post290245

really appreciate it, can’t wait to get it installed!

[wahsm]

FYI (in particular ugaexploder and wahsm) I've published the STL for the MAP sensor adapter - new post in the sticky: https://nam3forum.com/forums/forum/main-forum/e46-2001-2006/271707-e46-m3-community-designed-cad-files-master-list?p=290245#post290245

Much appreciated, thank you!

[0-60motorsports]

Hey so just again with the caveat that I haven't done this yet, and what I'm doing is just based on my own research (I am not an expert).

Yeah that's my understanding. The original CSL MAP sensor (13627833561) is ideal but is NLA. The BMW replacement (12528091765) is a bit of a hack job and an aesthetic disaster. As you note the discussion on CSL register identifies 0261230101 as a possible replacement and I've decided to go down that path. It should be noted that in that discussion Tom notes that the nose on the sensor is approx 1.5mm too long. The sensor also has 1x mounting hole rather than 2. Once I have the parts in hand I plan to check this, and if it is indeed the case that it needs to be stood off slightly, I intend to CAD design a spacer which the sensor can be glued to to hold it in the right position. If this works out then yes, I think it will be a better option than the BMW replacement item, but that depends on me being able to make it fit properly.

Does anyone have a picture of the new part number 12528091765 installed on the CSL rail?

[karter16]

Does anyone have a picture of the new part number 12528091765 installed on the CSL rail?

The only one I've seen is this closeup Tom shared on cslregister: http://www.cslregister.com/forum/showpost.php?s=e577eebadd58ef42641b29ff5af9ace1&p= 202139&postcount=5

[0-60motorsports]

The only one I've seen is this closeup Tom shared on cslregister: http://www.cslregister.com/forum/showpost.php?s=e577eebadd58ef42641b29ff5af9ace1&p= 202139&postcount=5

Oh yeah thats pretty bad! Thanks for the reply. I am trying to see who can locally print me your adapter in the right material. Thanks for that design!

[proto.corsa]

Killer build.

[M3Garand]

This is a nice clean build

[karter16]

I was back to work this week running v5 of my tune with 5 rounds of VE tuning on top of it. It's given me the opportunity to drive a familiar route and get some good comparisons, as most of my recent driving has been VE tuning runs.

Firstly - low rpm, round town drivability is now, believe it or not, BETTER than it was for me with stock airbox and stock program/tune! (to be fair I also cleaned the TBs, ICV, etc. at the same time so need to consider the impact this will have had also). Needless to say I'm extremely happy with how this is turning out. Drivability concerns are what put me off doing the CSL airbox for so long, so I'm stoked that this approach has turned out so well. I'm not sure if it's that just my car wasn't completely happy with the standard 1901 tune my car came with or what, but I guess I'd got used to avoiding certain RPMs at certain loads and speeds and all that is gone. I can cleanly and smoothly run up and down the range in first gear in stop start traffic, I can stay in higher gears at lower speeds than I would have and it's smooth sailing. SMG shifts and downshifts are excellent and repeatable. On the euro software (both with and without the CSL255 parameters) I couldn't be completely confident that I wouldn't get a bit of a jolt sometimes downshifting from 2nd to 1st with my foot off the accelerator. Now all that is gone completely. Not to make out that there aren't still improvements I can make, there's a couple of rpm/load spots I need to smooth out some more, but there's not many of them left at this point. Another scenario I often encountered previously was the tendency for the car to jerk under anything more than mild acceleration for the first 30 seconds or so after startup when completely cold. That's gone as well and drivability is smooth from completely cold.

When starting out with this I would have been stoked to have ended up with the drivability being no worse than it was on the Euro tune, to have ended up with something even better is magic. I'm looking forward to continuing to fine tune.


Relatedly I've been making some good progress with disassembly and have started looking at options around pushing more useful values onto the CANBUS. Looking at the address tables, functions, etc there doesn't seem to be any particular reason why it wouldn't be possible to add a function for an additional ARBID to be inserted onto the bus. If given an appropriately low priority ARBID it shouldn't get in the way of more critical signals. The bit that would be most difficult to figure out (apart from the bit where you DON'T brick your DME) is the easiest way to inject the additional function call into the flow. Looking at the 10ms task it would probably be easiest to take an existing function, move that function and use it's original address to build out a new function that calls both it and the additional function for the new ARBID. Unless I can find some spare bytes somewhere to inject an additional JSR (no doubt there's others here with more skills than me at identifying injection points for patches, so sing out if you have any suggestions). Other pre-reqs to this include tracing the variables that would be useful to send (things like lambda integrators, rpm, relative opening) and following the program flow to confirm the actual internal refresh rates for those variables (some of these are defined in the funktionsrahmen, but some aren't so I'd like to confirm for peace of mind).

[Bry5on]

Hell yeah! This reads like I felt.

Did you get through high load, low rpm testing? Specifically around 2k rpm? There might be a gem waiting for you to discover.

Those were also my thoughts exactly on how to get more CAN variables transmitted. RPM and speeds (vehicle, individual wheels), as well as a whole host of other DSC data are already on the CAN bus. I’d say the most useful to add would be relative opening, lambda integrators and the engine and ambient temperature/pressure parameters that aren’t already on the CAN bus somewhere else. Honestly they might all fit in a single CAN transmission.

edit: here’s a json config file that you might enjoy perusing because it has all of the CAN values I log in it

config-11-20-24_moreCAN_clean.txt

[karter16]

Hell yeah! This reads like I felt.

It's so good and so satisfying when it comes together and you see what the car is capable of when it's tuned right.

Did you get through high load, low rpm testing? Specifically around 2k rpm? There might be a gem waiting for you to discover.

So it's almost there - the pinging is resolved, there's just a bit of a lump there still which I have to figure out - this is probably the gem you're referring to

Those were also my thoughts exactly on how to get more CAN variables transmitted. RPM and speeds (vehicle, individual wheels), as well as a whole host of other DSC data are already on the CAN bus. I’d say the most useful to add would be relative opening, lambda integrators and the engine and ambient temperature/pressure parameters that aren’t already on the CAN bus somewhere else. Honestly they might all fit in a single CAN transmission.

edit: here’s a json config file that you might enjoy perusing because it has all of the CAN values I log in it

Yeah I've been looking most closely at the lambda integrators and RO, as you say the additional temp/pressure params would be good as well. Only other thing I realised is the lambda functions at least are executed on the Slave CPU and I'm not sure yet whether they are sent to the shared bus/memory space for the Master CPU to access. If they aren't that will be another complexity to figure out as I haven't dived into exactly how that shared bus/memory space works and if there's any room left on it.

Thanks very much for the config file - that's very useful!

[karter16]

On the way to a much more complete disassembly of the 0401 software, bmwfnatic and I have been working on disassembling the 1801 software first as being an MSS54HP version it should be more closely aligned with the 0401 software and help reduce the unknowns for us to deal with when we get to 0401.

As part of this one of the things I've been working on is validating a lot of the characteristics (parameters/curves/maps) for the 1801 partial against the public XDF, disassembled code, etc. plus referring to the 0901 A2L and binary to map as many of the SMG characteristics as possible (given these are almost all wrong in the 1801 public XDF). In total I've identified 246 characteristics in the XDF that are incorrect, and an additional 226 characteristics to be added which aren't in the XDF currently. My plan is to build out an updated and corrected XDF which corrects all known characteristics, adds additional known characteristics, removes known no-longer-existing characteristics (e.g. were in the 0901 code but are gone as of 1801) and specifically identifies characteristics which exist but are unknown, along with what information is known about them (e.g. module, etc). There's about 20 of these in general, plus another 65 or so specific to the SMG module (the SMG module appears to have undergone heavy development between 0901 and 1801).

Once this is done I'll publish the updated 1801 XDF for everyone's reference.

[karter16]

Well after 9 years of flawless SMG ownership the car threw SMG codes 36 and 37 on the way to work this morning and again on the way home. Not the worst timing as was planning to have the car in the air soon for the RACP brace install, so can do the gear position sensor at the same time. I look forward to spending 500 Euro on a new one…


Sent from my iPhone using Tapatalk