N54 Exhaust Burble XDF Tables

[corbanistan]

Interesting. I'll have some results tomorrow regarding the tq reduction bit flip.

I'm also 6mt as well w/o cats

Some other things I did was set the shift bog category back to stock, because I had been messing with those. And I used the 1M trailing throttle values in my bin, then adjusted the minimum delay, minimum delay for clutch pressed, and minimum ignition angle to what I wanted to try out.

 

[KClemente]

Okay depending on how you setup your minimum delay for clutch pressed, that will 100% affect shift pops. I have mine set specifically to inject fuel at midrange rpm and not inject at anything above 6000rpm as to not induce any rev-hang.

 

[corbanistan]

Okay depending on how you setup your minimum delay for clutch pressed, that will 100% affect shift pops. I have mine set specifically to inject fuel at midrange rpm and not inject at anything above 6000rpm as to not induce any rev-hang.



View attachment 62499

I have all 3 columns set to 2.00, and didn't change x-axis values. Haven't noticed rev hang but you make a good point about that. I'll fiddle around different values, could be why I get gunshots at full load shifts.

 

[JohnDaviz]

Can somebody point me to the Hex Adress for the rpm table on INA0S?

I have to admit i don´t know how this works I added the Hex in General and edited the Conversion. Values look correct.
But the RPM hex i think was not mentioned here. (I never used WinOLS tbh)

 

[carabuser]

Can somebody point me to the Hex Adress for the rpm table on INA0S?

I have to admit i don´t know how this works I added the Hex in General and edited the Conversion. Values look correct.
But the RPM hex i think was not mentioned here. (I never used WinOLS tbh)

View attachment 62504

There's no clutch switch with the DCT so not sure that table is much use for you.

 

[JohnDaviz]

There's no clutch switch with the DCT so not sure that table is much use for you.

oh shoot. I thought this was also going to work for the DCT.

 

[corbanistan]

oh shoot. I thought this was also going to work for the DCT.

There is a way to get that DCT shift rumbly sound like what you'd hear on Porsche for example, but I'm not exactly sure how they did it. Make sure that the 2048 limiter is deleted in MHD settings. Maybe somebody can chime in for the rest who has DCT

 

[JohnDaviz]

With XHP a more notable shift sound was introduced. But i have the feeling that it still is not as good as on other cars.
Also it seems that it is randomly there.

So something was "enabled" on XHP side and i was wondering if there are tables on DME side which increase the effect.

 

[corbanistan]

With XHP a more notable shift sound was introduced. But i have the feeling that it still is not as good as on other cars.
Also it seems that it is randomly there.

So something was "enabled" on XHP side and i was wondering if there are tables on DME side which increase the effect.

Isn't it possible to load PPK or M3 firmware onto N54 DCTs? Maybe try doing that. I'm sure a cat delete would help. Other than that I'm not sure since I don't have the DCT. You'd have to change how overrun works during shift, I'm guessing currently it fast-cuts fuel to help with smooth and quick shifts, and that's preventing the Porsche-like shift sounds. Someone else would have to chime in about this...

 

[corbanistan]

It's definitely possible man

 

[carabuser]

There shouldn't be any overrun during shift so none of these tables will have an effect.

The determining factor for noise when shifting is the reduction the dct calls for. You shouldn't get fuel cut during a WOT DCT shift, only ignition reduction, if you see lambda spike during shift then that's a tune issue.

Also the ignition reduction should be rapid. When tuned properly you should only occasionally see it in logs as typically it's active for much less than the 100ms MHD logging interval so sometimes it should just appear flat.

I've never recorded my shifts from outside the car but i'd be mortified if they sounded like that video. From listening just with the window down they are more of a single crack.

 

[JohnDaviz]

It's definitely possible man

Sounds to me like it could exactly be the XHP DCT stuff. You hear it bang on one shift but on the others not so much anymore.

 

[JohnDaviz]

There shouldn't be any overrun during shift so none of these tables will have an effect.

The determining factor for noise when shifting is the reduction the dct calls for. You shouldn't get fuel cut during a WOT DCT shift, only ignition reduction, if you see lambda spike during shift then that's a tune issue.

Also the ignition reduction should be rapid. When tuned properly you should only occasionally see it in logs as typically it's active for much less than the 100ms MHD logging interval so sometimes it should just appear flat.

I've never recorded my shifts from outside the car but i'd be mortified if they sounded like that video. From listening just with the window down they are more of a single crack.

I can confirm that i sometimes here this single crack/bang/pop noise.

On my car i see these timing reductions during logging. I don´t feel any issues.

But i n my log i also see these little lambda spikes on one bank. So you say. This is an actual issue?
But the lambda spikes are not always there. Added a second log pic

 

[carabuser]

That's what most tuned N54 DCT shifts look like and what mine used to be like. It's not a bad shift like you'd expect in limp mode but it's much slower than what a DCT should be.

This is what I think a DCT shift should look like: https://datazap.me/u/rich/z4-v299?log=0&data=2-3-4-14-15-28-30&solo=4&zoom=784-862

I've overlayed the tq_gs_fast_bn logging channel which shows the torque target from coming from the DCT. You can see the reduction request comes in for 1 scan and the timing dips for only 1 scan and there's no spike in lambda.

In other logs it's quite common to see no reduction at all as this process takes tens of milliseconds rather than the 100ms MHD logging interval so it's quite often missed completely.

 

[JohnDaviz]

That's what most tuned N54 DCT shifts look like and what mine used to be like. It's not a bad shift like you'd expect in limp mode but it's much slower than what a DCT should be.

This is what I think a DCT shift should look like: https://datazap.me/u/rich/z4-v299?log=0&data=2-3-4-14-15-28-30&solo=4&zoom=784-862

I've overlayed the tq_gs_fast_bn logging channel which shows the torque target from coming from the DCT. You can see the reduction request comes in for 1 scan and the timing dips for only 1 scan and there's no spike in lambda.

In other logs it's quite common to see no reduction at all as this process takes tens of milliseconds rather than the 100ms MHD logging interval so it's quite often missed completely.

Interesting. But i think the 1mil question is. Do you know the root cause or can it be reduced to few tables being responsible to that?

 

[carabuser]

Interesting. But i think the 1mil question is. Do you know the root cause or can it be reduced to few tables being responsible to that?

The root cause is a combination of the original BMW code and a logic change that MHD added to the code.

The original code that writes the values that are sent to the DCT is a hack job. I don't think the MSD81 was ever intended for use with the DCT when it was developed, it's one of the few parts of the logic that BMW kept trying to improve as you can see it changes across the various MSD81 revisions. The DCT requires around 8 different torque values from the engine, things like calculated torque, optimal torque, driver requested torque, maximum and minimum possible torque and torque losses. Since the MSD81 was written with the more simplistic slushbox in mind they had to add extra logic that works out those params. The logic works OK normally but you start to see problems like those slow elongated torque reductions when you tune the car without paying attention to torque modelling.

You can't fix it from the DCT side. Olza looked at how the torque reduction from the DCT is calculated and it's all done on the fly so there's no tables that will fix anything at that end, it all comes from the DME side.

To fix in the DME you can do it with calibration changes only but it's not just one table, it's several that interract with those reported torque values I mentioned. I think it would also be possible to make another logic change to bring things back in check but I haven't tested it yet and probably won't until I get time off over Christmas.

 

[KClemente]

Just wanted to post an update for those who may be following this thread or just came upon it.
In terms of "Disable Tq Reduction by Ign", I had to switch it back to factory value to get Trailing Throttle tables to work, which in my case for I8A0S MSD80 was 00. Did lots of testing and 00 definitely keeps this value enabled. The way it's worded in the XDF is confusing, so I'd reword it to make more sense. These tables definitely work for me now, 100%.
I also enabled the Port Injection safety option in MHD, which will require a full rewrite if you hadn't enabled it prior.
With all of this I get burbles on trailing throttle AND shifts (I have MT).

Tested out 00 on my I8A0S just now and can verify that it did not do a thing. It was mostly just crackles and sounded the same when the toggle was set to 02.

 

[corbanistan]

Tested out 00 on my I8A0S just now and can verify that it did not do a thing. It was mostly just crackles and sounded the same when the toggle was set to 02.

Huh... this is weird. I had some natural pops on overrun before getting the extra tables to work, but changing that value to 00 is definitely letting me use them. The change is very noticeable, for example pulling timing or adjusting the duration. Maybe you have other values elsewhere affecting it, or maybe try 02 and 00 with more aggressive changes. I'm stumped. I can send you over my bin if you'd like I suppose

 

[RSL]

*IF* that's the one I'm thinking of, there are supposedly three values: 0, 1, 2.

0 - enabled
1 - inhibited
2 - calculated "old" way

That would seem to indicate both 0 and 2 are "on" for constant calc, not on/off.

 

[KClemente]

*IF* that's the one I'm thinking of, there are supposedly three values: 0, 1, 2.

0 - enabled
1 - inhibited
2 - calculated "old" way

That would seem to indicate both 0 and 2 are "on" for constant calc, not on/off.

Yep that's on page 1949 on the functions doc. I've got a couple more tests I've got to run before I get completely stumped