Karter16's Silbergrau E46 M3 Journal

[Bry5on]

Wow that came out miraculously well. Nice job.

[rtrules]

Nice job! But maybe you will have the same problem as I do, you can't properly open the false floor now, because it could get stuck against the bracing.
Only a problem if you often want to access the tools below or store some stuff between there.
But I will have to make bigger cutouts sometime because it's little bit annoying.

[karter16]

Nice job! But maybe you will have the same problem as I do, you can't properly open the false floor now, because it could get stuck against the bracing.
Only a problem if you often want to access the tools below or store some stuff between there.
But I will have to make bigger cutouts sometime because it's little bit annoying.

Yeah it's a good point - I accounted for this enough with mine to mean I can lift the floor up enough to get the tray out without having to remove the floor, but you can't tip it all the way up to the trunk lid. Good point though to remember this when doing your cutouts.

[davidinnyc]

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

I might need to borrow this…

[karter16]

After a bit of a prolonged shambles the second USBJTAG uLink NT FINALLY arrived yesterday, so this afternoon after work I put together an adapter cable and BDM'd the DME to recover it. Aside from Microsoft causing me grief all was straightforward and I can now connect to the DME with INPA. I restored to the base CSL program and tune so tomorrow morning I'll flash my latest program and tune files and get up and running.

Why did this take so long?

I ordered the first uLink NT from USBJTAG at the beginning of November. about two weeks later I stopped seeing any updates on tracking. I chased them up (6 weeks after ordering) and was told to be patient, chased them again (10 weeks after ordering) asking for a resolution and they simply never replied. I generally don't like doubling down on a poor experience but in this case didn't have too many alternative options so I ordered a second one which thankfully made it here. I still have had no resolution from them regarding the first one that went missing in transit.

The device and software is great, very easy to use and now that I have it I'm very happy with it, but I do advise caution/realism around the shipping side of things. Hopefully mine is an outlier experience in this regard and others don't encounter it as this is a very simple and clean solution for those of us with ST eeproms.

[karter16]

With my DME recovered I was able to finally finish off the last little bit of something I've been working on for a while: MSS54HP CSL 0401 Community Patch Binaries

These binaries wrap up a bunch of QoL improvements into a single package. I was very close to having this done when I messed up a memory reference and that's what bricked my DME. With my DME recovered I've been able to complete testing on this, very pleased to have this done and out there.

As noted in the post I need to swap over to the CSL boot loader and test that version before I make it available. I'm extremely confident it is correct as it's the exact same as the version for the 2300 boot loader minus the additional changes needed to get the 2300 boot loader working, but unless someone volunteers to test it it'll need to wait until I get a chance.

[0-60motorsports]

With my DME recovered I was able to finally finish off the last little bit of something I've been working on for a while: MSS54HP CSL 0401 Community Patch Binaries

These binaries wrap up a bunch of QoL improvements into a single package. I was very close to having this done when I messed up a memory reference and that's what bricked my DME. With my DME recovered I've been able to complete testing on this, very pleased to have this done and out there.

As noted in the post I need to swap over to the CSL boot loader and test that version before I make it available. I'm extremely confident it is correct as it's the exact same as the version for the 2300 boot loader minus the additional changes needed to get the 2300 boot loader working, but unless someone volunteers to test it it'll need to wait until I get a chance.

Thats awesome! Thank you for doing that mate.

[karter16]

Spent the last week in bed with Covid, and only just re-emerging now.

Directly before I went down I completed building out the generalised configurable CAN message functionality for inclusion in the next version of Community Patch. This functionality is an extension of the custom program ROM I've been running for the last few months.

• Up to 3 configurable CAN messages for a total of 24 bytes of variables of your choice at 100hz.
• Ability to push up to 16 bytes of Slave-processor-only variables to the DPR (shared RAM) to make them available to then expose in the configurable CAN messages. This is something new I've been working on and means there's now no restriction on what variables can be exposed to CAN, if it exists in the DME you can push it on the CAN bus.
• Configuration validation on DME startup for both CAN message config and Slave-to-DPR config.
• New functionality off by default, must be configured to enable it (means backward compatibility with any 0401 Tune file)

If I get a chance this weekend I plan to flash the program and test it out. I'll then need to flash a bunch of different tune files to validate the various combinations of config validation, etc.

This feature is only fully useful to others when available alongside a list of DME variables. Obviously we don't know all of these, but I'm intending to extract a list from the disassembly, along with descriptions where we have them, that people can refer to. With that and some decent instructions it should be a fairly useful feature.

[0-60motorsports]

Glad you are feeling better!

[karter16]

Boom! AVAN1_SOLL (target exhaust vanos angle), which is a Slave-only variable, logged at 100Hz over CAN



Now to build out a bunch of test cases and work my way through them...

[karter16]

Life continues to be busy, have managed to make some progress in a few places.

I've finalised the design of the Gauge.S enclosure and done a final test assembly (see photos below). I have the final prints too ready to be sanded and painted.







I've also been putting the dev version of Community Patch V2 to full use. I've been doing more work on understanding the behaviours of the cylinder air mass calculations specific to the CSL and looking into a couple of interesting curiosities. I've been maxing out the 3 custom CAN messages as well as pulling across slave-only parameters. A lot of this investigation I'm doing would be pretty much impossible without the flexibility of being able to pull, at high data rate, the specific variables I need.


I also received my second-hand E86 front triangulation braces that I ordered while I saw them for cheap. Looking forward to getting heinzboehmer's front triangulation brace together and installed when I get the chance!

[karter16]

It was raining heavily today so I drove to work and took the opportunity to run some logs.

I've written previously about the CSL MAP sensor and its function. As a quick recap it performs 2 functions during normal operation. One is to act as a kind of running offset between calculated actual conditions and the AlphaN map, for this reason the MAP integrator value rf_psau_i is stored as a adaption in EEPROM. The second thing is does is act more instantaneously to address variations in realtime.

It's fairly commonly known that the integrator is limited to +-2.5%. As I've noted before it's actually +-2.5% of max RF, which in the range the integrator is active in is actually more like +-10% of current RF.

I've previously hypothesised that in normal operation the integrator doesn't bounce off its limits anyway, I just haven't actually got around to posting any evidence of this. So here we go

This is a normal drive home from work. rf_psau_i integrator is always applied to final RF, but the integrator is only updated once engine temp reaches 80 degrees, hence the straight line at the start of the log.

What we can see more generally though is that once the TMOT condition is reached the integrator is very active. We can also see that it hasn't got anywhere near its +-2.5 limits, sticking between +1.094 and -1.205.



I thought another way to understand how much of the time the MAP sensor is actively correcting RF would be to look for the percentage of time it's changing. So here we go:

Once TMOT=80 is reached in the log above there are 78,859 records captured at approximately 100Hz frequency.

Of the 78,859 records, 41,655 of them have an rf_psau_i value that differs in value from 10 records (100ms) earlier. By this measure the MAP integrator is active approximately 52.8% of my drive home. If we extend the measure to look where it differs in value from 100 records (1 second) earlier, the figure rises to 64.4%.

In short - for round town and highway commuting the MAP sensor is going to have a significant effect :-)

[Slideways]

Hmm, what happens if the thermostat is stuck open and it never reaches 80C? I really should get to fixing that

[karter16]

Hmm, what happens if the thermostat is stuck open and it never reaches 80C? I really should get to fixing that

Yup it'll not update and rf_psau_i will be stuck at whatever it was last set at as an adaption. Which, depending on whether conditions have changed, will either hinder or help.

[Slideways]

Yup it'll not update and rf_psau_i will be stuck at whatever it was last set at as an adaption. Which, depending on whether conditions have changed, will either hinder or help.

That would be a bit of a problem if the adaptations were reset lol

Maybe it is not a great idea to reset adaptations with the 75C, 70C and 55C thermostats.