[WhatsADSM]

Originally Posted by bahn

Alright, here we go:

This is not to be taken as a guide to tuning the N55. Below are my own anecdotal experiences and not to be interpreted as the only way/perfect way to tune the N55. I don't take responsibility for what you do with this information. My testing was done using the Commanded WGDC Strategy.

Limiters/Initial Setup
* If you're on a 3.5+ bar TMAP and plan on achieving boost levels over ~22 PSI: Increase "Boost ceiling" to 3.5.
* Increase "Boost Limit Multiplier Ceiling" to 3.5, same as above.
* Set the "Boost Limit Multiplier" table to be 4.0 throughout the entire table.
* Increase "WGDC Limit" to 100
* Set the "Torque Eff Divisor" table to be 1.0 for the entire table.
* Set the "Torque Request Ceiling" for your transmission type to be very high. I was using 900 across the entire table.
* Increase "Modeled Torque Limit 1 & 2" tables to be whatever high number you used for "Torque Request Ceiling" for the entire table. (900 in my case).
* To get around auto/dct torque limits you have two options with the "Load to torque limit" tables: 1) Use the stock breakpoints but lower the last two rows cell values until you're no longer hitting the limiter. 2) Use the stock cell values but increase the last two load breakpoints to be very high so the interpolated value is lower.
* Disable the catless CEL code 3106 if you have a catless DP.

Enable Commanded Wastegate
* Set "Commanded Wastegate Switch" to 1 - this enables the commanded wastegate strategy. (Note: Leave "Commanded Boost Switch" off)
* Rescale the "Commanded WGDC" Y axis breakpoints as shown in a previous post by Ken. At higher boost levels you will need to rescale the top end for higher boost setpoints.
* Rescale the "Commanded WGDC" cell values to something like the Cobb table Ken posted above. DO NOT FORGET TO DO THIS, IF YOU DONT YOU WILL BE TARGETING 100% WGDC ALMOST CONSTANTLY.

At this point you can start adjusting your main tables
* Increase "Load Ceiling Main" cell values to your "targeted" load to keep from going over load req.
* Modify your AFR targets (for both banks) and fuel scalar if needed for ethanol.
* Modify your Timing targets by pulling some out to start as you increase boost and rescaling the load axis as needed. Stay very conservative on timing, you'll need a dyno to dial this in safely.
* If your rail pressure starts dropping on higher ethanol mixes you can increase the rail pressure homogen table at the rpm before the crash to buffer it slightly.
* Adjust the "Commanded WGDC" cell values slowly. This will take A LOT of time to get dialed in for drive-ability and boost targets.

Datalog, datalog, datalog. Be very slow and conservative in the changes you make. Take the information above for what it is, my anecdotal experience. Be safe, if you don't know what you're changing STOP and pay for a custom map. The price of a custom map vs a new engine is a no brainer. I personally recommend WedgePerformance

Thanks for the info. I'm sure this will be a good reference for many of us.

I did have a question about your comment:

Originally Posted by bahn

To get around auto/dct torque limits you have two options with the "Load to torque limit" tables: 1) Use the stock breakpoints but lower the last two rows cell values until you're no longer hitting the limiter. 2) Use the stock cell values but increase the last two load breakpoints to be very high so the interpolated value is lower.

Can you elaborate on exactly what you mean by the auto/dct torque limits? I assume you are saying that if the DME reports a high enough torque to the TCU that the TCU will intervene and cause an issue?

If so is there a specific torque output that you know causes problems?

[bahn]

Originally Posted by WhatsADSM

Thanks for the info. I'm sure this will be a good reference for many of us.

I did have a question about your comment:


Can you elaborate on exactly what you mean by the auto/dct torque limits? I assume you are saying that if the DME reports a high enough torque to the TCU that the TCU will intervene and cause an issue?

If so is there a specific torque output that you know causes problems?

Correct. The actual number that causes the problem depends on if the TCU is flashed with Alpina or stock and if the car is xDrive. I've seen issues 490+ on my xDrive automatic.

[WhatsADSM]

Now is actually probably a good time to start talking about the load command side of the MEVD17. The COBB manual actually does a decent job of trying to explain the load command and its limiters however it definitely glosses over a few things:



The one thing that is never well defined is "Calibrated Load Request", as well as the exact purpose of the "Load To Torque Limit" table.

To me I see three separate load command paths. The first load path COBB calls the "Calibrated Load Request" and it seems to be drivetrain related as it is the minimum of the transmission torque ceiling and the gear-based torque ceiling put through yet another "Load To Torque Limit" table.

The next load path is "Load Request Max 3" which appears to be a load protection path as it includes boost limit factors, and temp (iat/clt) factors.

The final path, which appears to be the primary path, labelled by COBB as "Load Request Max 2". This is a direct load command from the Load Ceiling Main table which is referenced by RPM and IGN (essentially to pull back load under excessive knock).

The final load command is essentially the minimum of the command from any of the 3 paths listed above.

Not sure if anyone knows the answer to these questions ( BMWcurious ?) but I'll ask them anyways:
1) First things first, there is a clear omission here on exactly how the throttle tables tie into all this. I am *assuming* that the throttle tables provide a multiplier that is applied to the first table output of these paths (i.e. the load ceiling main, modelled torque limit, transmission torque ceiling)?
2) I am really trying to wrap my head around the purpose of the "Load to Torque Limit" table. Prior to using that table we have already defined a torque ceiling based on transmission type, rpm, and gear. We then have a table that we where we transform to load, lookup a torque limit, and then transform back to load again?! Why not just transfer to load and be done with it? Is that table also used else where?
3) The XDF defines a "Torque Reduction Factor (RPM)" (under limits category) which appears to be a multiplier that will scale back a torque command based on RPM. The factory tune uses a values of ~2 at 1000 RPM falling to 0.703 at 7100, so it certainly seems that it could be significant yet COBB never references it anywhere in their diagram. I would assume its somewhere in the "Load Request Max 3" (protection) path?!
4) Ditto for the "Load limiting factor (IAT)". There is a pretty steep drop-off in the multiplier for IAT as the temps increase over 65* C. I wonder where this one is applied.

[BMWcurious]

2) It is so that the ECU can combine all the load and torque limits. The "Load to torque limit" table should really be considered a load to torque and torque to load converter. It is used to convert in both directions, with an inverse lookup. Some Bosch ECUs without the BMW layers use a load to torque and a torque to load table that have to reasonably closely match each other to avoid torque interventions.

[bahn]

#4 is part of the Load Request Max 3 path. See the "Load limit factor temp compensations". #3 should also be part of that path.

As said above, "Load to torque limit" shouldn't be called a limit table because it's not. It's an inverse lookup table.

[WhatsADSM]

Originally Posted by BMWcurious

2) It is so that the ECU can combine all the load and torque limits. The "Load to torque limit" table should really be considered a load to torque and torque to load converter. It is used to convert in both directions, with an inverse lookup. Some Bosch ECUs without the BMW layers use a load to torque and a torque to load table that have to reasonably closely match each other to avoid torque interventions.

Originally Posted by bahn

#4 is part of the Load Request Max 3 path. See the "Load limit factor temp compensations". #3 should also be part of that path.

As said above, "Load to torque limit" shouldn't be called a limit table because it's not. It's an inverse lookup table.

Thank you both. This makes WAYYYYY more sense when you think of it simply as simply the general table that performs the transformations from load to torque (as well as the inverse transformation from torque to load). That diagram did a pretty poor job of explaining it that way for sure. If we ever get around to forking the XDF, I propose we move that table into the "Load" category as opposed to the "Limits" category.

Bahn..
Given what we just said doesn't it make more sense to simply leave the load to torque table alone and instead simply cap the Torque Request Ceiling (Auto/DCT) table to ensure that a request is never generated too high of a torque as to cause an issue with the TCM?

[bahn]

Originally Posted by WhatsADSM

Thank you both. This makes WAYYYYY more sense when you think of it simply as simply the general table that performs the transformations from load to torque (as well as the inverse transformation from torque to load). That diagram did a pretty poor job of explaining it that way for sure. If we ever get around to forking the XDF, I propose we move that table into the "Load" category as opposed to the "Limits" category.

Bahn..
Given what we just said doesn't it make more sense to simply leave the load to torque table alone and instead simply cap the Torque Request Ceiling (Auto/DCT) table to ensure that a request is never generated too high of a torque as to cause an issue with the TCM?

In theory you might be able to, however I'd be afraid if you fed it a small torque # to start you might get a lower calculated load and therefor fall into the "Load to torque limit" table at a lower Y axis which will return a lower torque value resulting in insufficient line pressure. You could probably do this but it would ultimately require editing of the "Load to torque limit" cell values imo.

[WhatsADSM]

Originally Posted by bahn

In theory you might be able to, however I'd be afraid if you fed it a small torque # to start you might get a lower calculated load and therefor fall into the "Load to torque limit" table at a lower Y axis which will return a lower torque value resulting in insufficient line pressure. You could probably do this but it would ultimately require editing of the "Load to torque limit" cell values imo.

I thought we just agreed that it is simply a translation table to move between load and torque, and if so then it really isn't there as a limiter at all. Instead it really is there to provide the load value given a specific torque from the transmission (or modelled torque) table. Again the COBB picture is pretty unclear/ambiguous.

If there is indeed a limiter which needs to be worked around in the TCU, its important that we understand exactly what value in the load path is used for reporting load/torque to the TCU. It will affect which tables we use to workaround it.

Ultimately what makes the most sense in my mind is that the torque value reported to the TCU would correlate with the final value that the DME is using for load (i.e. the minimum from all the paths). This way the transmission always understands the torque at that moment and can modify the shift profile accordingly. You don't want a slow low line pressure shift when we are at high boost, but remember we also don't want a fast hard shift when we are just putting around town either. The other possibility maybe is that the TCU only sees the load from the "Calibrated Load Request" path as to sort of isolate the transmission load/torque path from the actual load/torque path for more flexibility in the calibration?!

[bahn]

Originally Posted by WhatsADSM

I thought we just agreed that it is simply a translation table to move between load and torque, and if so then it really isn't there as a limiter at all. Instead it really is there to provide the load value given a specific torque from the transmission (or modelled torque) table. Again the COBB picture is pretty unclear/ambiguous.

If there is indeed a limiter which needs to be worked around in the TCU, its important that we understand exactly what value in the load path is used for reporting load/torque to the TCU. It will affect which tables we use to workaround it.

Ultimately what makes the most sense in my mind is that the torque value reported to the TCU would correlate with the final value that the DME is using for load (i.e. the minimum from all the paths). The other possibility that seems to make sense to me is that the TCU only sees the load from the "Calibrated Load Request" path.

Note I didn't say you'd hit a limit, I said your calculated load could be low BEFORE torque is looked up in the "Load to Torque limit" table. A low load % lookup would result in a low torque # from the L2T table and low line pressure. What isn't clear to me is if the L2T table is used for the initial Torque to Load conversion. It doesn't make sense to me that you would take torque, convert to load (using the L2T table), convert that load to torque (using the L2T table) and then convert it back to torque (using the L2T table). Maybe Cobb's diagram is wrong. If it was as described there's no point in the doing the last two conversions IMO as the interpolated value would be the same.

With the majority of decent tunes you shouldn't really see "Load Request Max 2" step in.

[WhatsADSM]

Originally Posted by bahn

With the majority of decent tunes you shouldn't really see "Load Request Max 2" step in.

You mean "calibrated load request" path?

[bahn]

Originally Posted by WhatsADSM

You mean "calibrated load request" path?

No, load request max 2. Wastegate tuning should keep you slightly below the ceiling.

[WhatsADSM]

Originally Posted by bahn

No, load request max 2. Wastegate tuning should keep you slightly below the ceiling.

Hmm. Not sure I follow you there. IMO I was expecting that the primary table the DME derives it's load COMMAND from is the "Load ceiling (main)". This is effectively the load request max 2. I would expect under normal conditions that all of the other load paths are actually much higher, but are limited by the load ceiling main. The Cobb documentation seems to suggest the same as it says "LOAD CEILING (MAIN) – In the OTS mapping strategy this is the primary table for load request ceiling".

IMO the intent of the wgdc tables is to hit the desired load (which resolves into boost set point commanded). It seems to me your approach is to simply open up all the limits and tune exclusively on the wgdc.

I will freely admit I have yet to even flash a different bin to my car but just trying to understand the theory behind the models at this point.

I am on stage 0 now and waiting for my emissions monitors to go active so I can take an emissions test. After that I'll start tweaking.

[bahn]

Originally Posted by WhatsADSM

Hmm. Not sure I follow you there. IMO I was expecting that the primary table the DME derives it's load COMMAND from is the "Load ceiling (main)". This is effectively the load request max 2. I would expect under normal conditions that all of the other load paths are actually much higher, but are limited by the load ceiling main. The Cobb documentation seems to suggest the same as it says "LOAD CEILING (MAIN) – In the OTS mapping strategy this is the primary table for load request ceiling".

IMO the intent of the wgdc tables is to hit the desired load (which resolves into boost set point commanded). It seems to me your approach is to simply open up all the limits and tune exclusively on the wgdc.

I will freely admit I have yet to even flash a different bin to my car but just trying to understand the theory behind the models at this point.

I am on stage 0 now and waiting for my emissions monitors to go active so I can take an emissions test. After that I'll start tweaking.

No worries, I'm still learning as well and I do not claim to be a pro, just an enthusiast. The load ceiling is just that, a maximum. If you hit the load ceiling you'll have a throttle cut and wgdc will drop. It's an important part to get out of the way, think of it as a load limit. In both OTS & Commanded WGDC strategies you need to increase it and tune your WGDC to keep from hitting that load. Most tuners try to keep Load Act. and Load Req. about 10% off of each other to keep the throttle plate open 100% of the time. I'd still set it to be a reasonable number to be used as a safety system.

[bahn]

Also something I just noticed. It would appear somewhere along the line the DME is increasing and decreasing the torque act. number with timing. You can clearly see that here: http://www.e90post.com/forums/showpo...1&postcount=88

[WhatsADSM]

Originally Posted by bahn

No worries, I'm still learning as well and I do not claim to be a pro, just an enthusiast. The load ceiling is just that, a maximum. If you hit the load ceiling you'll have a throttle cut and wgdc will drop. It's an important part to get out of the way, think of it as a load limit. In both OTS & Commanded WGDC strategies you need to increase it and tune your WGDC to keep from hitting that load. Most tuners try to keep Load Act. and Load Req. about 10% off of each other to keep the throttle plate open 100% of the time. I'd still set it to be a reasonable number to be used as a safety system.

Yea I think we are saying similar things, just looking at it different ways. I guess I just wanted to point out that the normal path for the load request (which is closely related to the boost setpoint used in the WGDC calcs) is based on the load ceiling main table. And yea that table in conjunction with the WGDC is will set the boost level and ultimately load actual.

I do notice that most of the logs of tunes I see out there purposely have a load request that is considerably larger than load actual (Presumably to ensure no throttle closures). I agree with what you said I would personally want it such that load request is nominally around 10% greater than load actual. I've also noticed that many of the tunes also have a boost target considerably higher than boost actual, part of this is the tiny little turbo at high RPM, but some of this is just in the tune. Not sure how much I like just having the boost target way way above the actual. Not much point in a PID loop (or even just an I term) if its just wound up to the max all the time, its not a feedback loop anymore so much as it's just a static adder. For reference here are two bone stock logs I did on stage 0. The stock tune looks very good IMHO load actual just a few percent less than the request, and boost nearly on target the whole time. There is a small throttle closure right at boost onset when it overshoots a small bit, but it doesn't seem to hurt anything and one could argue its actually a good thing as it allowed boost to come in as quick as possible. IMHO *ideally* this is how I would want my logs to look, just scaled up a bit

http://datazap.me/u/whatsadsm/log-1490511960

[WhatsADSM]

I passed emissions. Yay.

So I was able to do a little tinkering, and verified a few things.

1) The primary load map is in fact the load ceiling main. The others (namely the drivetrain ones) are higher and out of the picture, at least in the stock tune. When I get a chance I would like to verify that the scaling makes sense on those as well (my stock bin shows 700NM which seems a bit high for the DCT).
2) The throttle progression table scalars are effectively applied at the output of the load ceiling main. Very clear. The only thing that doesn't make total sense there is that the stock throttle maps show over 100% yet in my tinkering I found that it clips to 100 anyways, so there doesn't appear to be any reason to have those columns over 100%. Possibly an indicator in some other model in the DME that over-boost should be active?

The one thing that truly does suck is that when you have DTC single pressed or fully off the DME automatically reverts back to the non-sport (soft) map. My M3 never did that. At the track I always drive with DTC full off so that limits me to only a single throttle map. I would prefer to have a "kill" map which is slightly higher than my normal power level that I could run (with a push of a button) if I truly felt the need to push every last bit out.

[maddmatth]

Originally Posted by WhatsADSM

2) The throttle progression table scalars are effectively applied at the output of the load ceiling main. Very clear. The only thing that doesn't make total sense there is that the stock throttle maps show over 100% yet in my tinkering I found that it clips to 100 anyways, so there doesn't appear to be any reason to have those columns over 100%. Possibly an indicator in some other model in the DME that over-boost should be active?

Possibly triggers auto/DCT kickdown as well?

Originally Posted by WhatsADSM

The one thing that truly does suck is that when you have DTC single pressed or fully off the DME automatically reverts back to the non-sport (soft) map.

Maybe there's a variable in there to switch that off...

[weehe126]

So anyone try and vanos spool changes? Looking to improve my PS2 spool and not sure where to start. I think increasing max spool RPM is a good start, but not sure what it does.

[bahn]

Originally Posted by WhatsADSM

I passed emissions. Yay.

So I was able to do a little tinkering, and verified a few things.

1) The primary load map is in fact the load ceiling main. The others (namely the drivetrain ones) are higher and out of the picture, at least in the stock tune. When I get a chance I would like to verify that the scaling makes sense on those as well (my stock bin shows 700NM which seems a bit high for the DCT).
2) The throttle progression table scalars are effectively applied at the output of the load ceiling main. Very clear. The only thing that doesn't make total sense there is that the stock throttle maps show over 100% yet in my tinkering I found that it clips to 100 anyways, so there doesn't appear to be any reason to have those columns over 100%. Possibly an indicator in some other model in the DME that over-boost should be active?

The one thing that truly does suck is that when you have DTC single pressed or fully off the DME automatically reverts back to the non-sport (soft) map. My M3 never did that. At the track I always drive with DTC full off so that limits me to only a single throttle map. I would prefer to have a "kill" map which is slightly higher than my normal power level that I could run (with a push of a button) if I truly felt the need to push every last bit out.

In the stock/ppk tune yes, the "load ceiling main" table can be the primary "load request". However this setup will induce throttle closures, WGDC drops and timing drops (which are very prevalent in the stock tunes) when load act. goes above load req. seen here:
http://datazap.me/u/whatsadsm/log-14...7&mark=145-174

Most custom tunes keep a differential between load act and load req to keep throttle closures, wgdc drops and timing drops from occurring. This is a better way to tune these IMO.

[WhatsADSM]

Originally Posted by bahn

In the stock/ppk tune yes, the "load ceiling main" table can be the primary "load request". However this setup will induce throttle closures, WGDC drops and timing drops (which are very prevalent in the stock tunes) when load act. goes above load req. seen here:
http://datazap.me/u/whatsadsm/log-14...7&mark=145-174

Most custom tunes keep a differential between load act and load req to keep throttle closures, wgdc drops and timing drops from occurring. This is a better way to tune these IMO.

The point is that table generates the load request/command. The DME always generates the load request/command no matter how you have your tune configured (stock, ots, or even custom). Load actual is another story.

As for the throttle closures that is an interesting topic. Within the community it seems that there is a huge aversion to any form of closure, much of this is somewhat unfounded in my opinion.

I certainly see the very brief "closure" in those logs however there are no ill effects from it. The control loop around the boost request and load request are fairly hot and you see a small amount of overshoot followed by a quick regulation. There is nothing inherently wrong with that, and there is certainly no "timing drop" present in that log at all.

I brought this up a while back but IMO the best way to tune a control system like this would be to treat load request and boost request like a real request and let the system close out error as it should. If we are truly worried about throttle closures then the best thing to do would be to increase the allowable error and/or decrease the response to it in relation to a small overshoot. The "Load Difference Ceiling" table would seem to be an option here. COBBs documentation briefly touches upon it and describes it as "Allowable difference between actual and requested load." It appears that the Throttle Threshold - Major Closures table can also be used to fine tune the behavior during overload. When I get a chance I would like to play with these tables a bit. Ultimately I would like to think of myself as a realist and if we can not finely tune the behavior of the response then I agree you want to tune the system such that there is a small nominal delta between load request and load actual. This ensures that we ride through small overshoots. However even in that case I wouldn't simply open up the load limits on the load ceiling main to something arbitrarily high.

[WhatsADSM]

Originally Posted by weehe126

So anyone try and vanos spool changes? Looking to improve my PS2 spool and not sure where to start. I think increasing max spool RPM is a good start, but not sure what it does.

Yea I wish we knew more about the spool tables. We really don't know when they are active and when it transitions to the normal tables. I would also like to know if the spool tables are even active at all if you switch to commanded wgdc.

[bbnks2]

Originally Posted by WhatsADSM

The point is that table generates the load request/command. The DME always generates the load request/command no matter how you have your tune configured (stock, ots, or even custom). Load actual is another story.

As for the throttle closures that is an interesting topic. Within the community it seems that there is a huge aversion to any form of closure, much of this is somewhat unfounded in my opinion.

I certainly see the very brief "closure" in those logs however there are no ill effects from it. The control loop around the boost request and load request are fairly hot and you see a small amount of overshoot followed by a quick regulation. There is nothing inherently wrong with that, and there is certainly no "timing drop" present in that log at all.

I brought this up a while back but IMO the best way to tune a control system like this would be to treat load request and boost request like a real request and let the system close out error as it should. If we are truly worried about throttle closures then the best thing to do would be to increase the allowable error and/or decrease the response to it in relation to a small overshoot. The "Load Difference Ceiling" table would seem to be an option here. COBBs documentation briefly touches upon it and describes it as "Allowable difference between actual and requested load." It appears that the Throttle Threshold - Major Closures table can also be used to fine tune the behavior during overload. When I get a chance I would like to play with these tables a bit. Ultimately I would like to think of myself as a realist and if we can not finely tune the behavior of the response then I agree you want to tune the system such that there is a small nominal delta between load request and load actual. This ensures that we ride through small overshoots. However even in that case I wouldn't simply open up the load limits on the load ceiling main to something arbitrarily high.

What you're doing makes entirely more sense if safety is a concern and you want to tune things "right."

There is a reason why COBB said one thing but did another... In reality, they tuned using commanded WG and set an unobtainable load ceiling for the given mapping (aggressive custom tunes used what COBB referred to as "race logic"). The ceiling was still set at a reasonable enough level so that in the event of a major problem the DME could still react... but, they used a high ceiling to avoid having to "fine tune" all those other reactive tables. It's a waste of time and effort unless you think there are some other components to it that should be better understood?