[BMWcurious]

I'm with you WhatsADSM. If a throttle closure triggers a timing correction, or you get ignition retard to avoid a torque cap, that should be fixed. Otherwise, I would prefer to try to work with the closed loop systems rather than push targets out the way. Limits should be set to values that leave a safety margin too, not just pushed to max. Each target and limit has a purpose, usually modelling one aspect like the torque limit for a transmission or clutch, or to prevent compressor overspeed, or for other component protection from thermal or structural damage. You can stretch some or most of these, but it should be approached with a view to the minimal necessary intervention to get what you think is safe. Every map change should be justifiable. That is difficult in the aftermarket, but should still be an aim. Arguably though, I'm guilty of hypocrisy as on simpler ECUs than this I have ripped out a load of complexity and had only a wastegate table as the boost and load control, with no target table, just the slope of the table gave some feedback. It gots cars to the low 7s, quadruple their standard output, and drivers either didn't notice a lack of finesse or preferred the smoothness. But I actually did it this way as it was more feasible to code.

So we all make our solutions, there is certainly more than one way to do this.

[bahn]

Originally Posted by BMWcurious

I'm with you WhatsADSM. If a throttle closure triggers a timing correction, or you get ignition retard to avoid a torque cap, that should be fixed. Otherwise, I would prefer to try to work with the closed loop systems rather than push targets out the way. Limits should be set to values that leave a safety margin too, not just pushed to max. Each target and limit has a purpose, usually modelling one aspect like the torque limit for a transmission or clutch, or to prevent compressor overspeed, or for other component protection from thermal or structural damage. You can stretch some or most of these, but it should be approached with a view to the minimal necessary intervention to get what you think is safe. Every map change should be justifiable. That is difficult in the aftermarket, but should still be an aim.

As do I, using the entire PID system would be ideal. I think the complexity of this system is what scares people into tuning it using a more old school boost controller approach. But at the same time there's tons of cars operating on boost controllers safely and easily. It's a trade off.

[BMWcurious]

Agree bahn. Of course the boost controllers (if we are talking about this platform specifically or any modern torque based ECU) is that they only work if they read the target pressure from the CAN bus and tell the DME that is what the pressure presently is or thereabouts. Some would like the idea of the tuner telling the DME what the boost target should be, but you'd also have to back calculate appropriate load and torque values to go with it, including all the efficiencies related to temperatures, throttle opening or valve lift, valve overlap, ignition and lambda efficiencies, exhaust manifold pressure and temperature, drivetrain losses.

[WhatsADSM]

Originally Posted by bbnks2

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?

The biggest reason I think it is worth it to at least attempt to getting working this way is that you still have a feedback loop in place. If you effectively just move the load/boost targets out of the way then what really goes on is the the feedback loop saturates and is essentially just some added value in the chain. So this means that as conditions change, the DME isn't truly compensating.

Originally Posted by BMWcurious

I'm with you WhatsADSM. If a throttle closure triggers a timing correction, or you get ignition retard to avoid a torque cap, that should be fixed. Otherwise, I would prefer to try to work with the closed loop systems rather than push targets out the way. Limits should be set to values that leave a safety margin too, not just pushed to max. Each target and limit has a purpose, usually modelling one aspect like the torque limit for a transmission or clutch, or to prevent compressor overspeed, or for other component protection from thermal or structural damage. You can stretch some or most of these, but it should be approached with a view to the minimal necessary intervention to get what you think is safe. Every map change should be justifiable. That is difficult in the aftermarket, but should still be an aim. Arguably though, I'm guilty of hypocrisy as on simpler ECUs than this I have ripped out a load of complexity and had only a wastegate table as the boost and load control, with no target table, just the slope of the table gave some feedback. It gots cars to the low 7s, quadruple their standard output, and drivers either didn't notice a lack of finesse or preferred the smoothness. But I actually did it this way as it was more feasible to code.

So we all make our solutions, there is certainly more than one way to do this.

Agreed, in my experience while you may want to relax certain models (most obviously like compressor speeds, and engine load limits) it is nice to still keep the overall system model in place. It is always best to at least understand the theory as much as possible, even if in reality you can't understand everything or don't have access to all of the tools you need.

I probably should have mentioned before, my day job is writing firmware for industrial motor drives (primarily servo). So while not exactly the same as a mechanical engine, I have a reasonable background on control theory and similar systems. That's probably why when I am attacking this problem I am at least trying to first attempt to do it with the same theory and toolset.

I totally agree with you though. In the end there is reality. And usually that reality is, we don't fully understand all of the models in the DME and/or we don't have access to all of the tools/equipment that we would need to properly set them anyways (like say the compressor characteristic map). So we use what is at our disposal and do the best we can.

On another note:
I still have (free) dyno access to the shop where I used to help out. I'm hoping to try to find some time that works for my wife/kids and the shop owner and get my car out there so I can at least get a baseline on it, and play around for a few hours in a more controlled environment. Once I have the opportunity I'll be sure to update the thread!

[bahn]

I've got a question, does anyone know why it would appear the DME goes into an open-loop fueling strategy on spool & post shift (on autos at least)? It would appear the DME sets STFT's to 0% and runs purely off of a table for fueling during these conditions.

Look at this log between the marks:
http://www.datazap.me/u/bellium/torq...rk=28-15-51-59

If this was just the Fuel Spool table being used I'd expect it to still utilize the O2 sensors, not to mention post-shift is above the "Max Spool RPM" parameter.

BMWcurious MHD Tuning WedgePerformance

[WhatsADSM]

Originally Posted by bahn

I've got a question, does anyone know why it would appear the DME goes into an open-loop fueling strategy on spool & post shift (on autos at least)? It would appear the DME sets STFT's to 0% and runs purely off of a table for fueling during these conditions.

Look at this log between the marks:
http://www.datazap.me/u/bellium/torq...rk=28-15-51-59

If this was just the Fuel Spool table being used I'd expect it to still utilize the O2 sensors, not to mention post-shift is above the "Max Spool RPM" parameter.

BMWcurious MHD Tuning WedgePerformance

Yea I saw that in your log before. It's a little weird. I can't quite understand the logic behind it changing to open loop as it seems to stay in open loop for a not-insignificant amount of time that seems to vary. Only pattern I seem to notice is that it seems to do it when the load is changing more dramatically.

[bahn]

Originally Posted by WhatsADSM

Yea I saw that in your log before. It's a little weird. I can't quite understand the logic behind it changing to open loop as it seems to stay in open loop for a not-insignificant amount of time that seems to vary. Only pattern I seem to notice is that it seems to do it when the load is changing more dramatically.

It's apparent in the PPK tune as well and probably the stock log but the spool time to target boost is shorter so it's not noticed as easily. I wonder why they did that.

http://www.datazap.me/u/bellium/n55-...9-19-20&solo=2

[BMWcurious]

I haven't studied this aspect of this ECU, but it makes sense that closed loop lambda control is suspended during rapid transients because the phase delay between combustion and the lambda sensor reading is probably too long. The N54 pre production functional description included a technique to use this phase delay to estimate lambda per cylinder using two sensors. Same applies to MAF sensor readings on transients - they read inlet manifold filling and emptying spikes that benefit from filtering or feeding the results into an inlet manifold model if using a conventional throttle. Valvetronic doesn't do this though.

[WhatsADSM]

Originally Posted by bahn

It's apparent in the PPK tune as well and probably the stock log but the spool time to target boost is shorter so it's not noticed as easily. I wonder why they did that.

http://www.datazap.me/u/bellium/n55-...9-19-20&solo=2

Not to change the subject too much, but I am starting to play a little bit more again and reviewed your earlier post about a recommended strategy. One of your points was:

"Set the "Boost Limit Multiplier" table to be 4.0 throughout the entire table."

I am still a little fuzzy on the DMEs translation from load to boost, and really the whole boost model (that occurs prior to WGDC). What exactly does this boost limit multiplier do?

[WhatsADSM]

Originally Posted by BMWcurious

I haven't studied this aspect of this ECU, but it makes sense that closed loop lambda control is suspended during rapid transients because the phase delay between combustion and the lambda sensor reading is probably too long. The N54 pre production functional description included a technique to use this phase delay to estimate lambda per cylinder using two sensors. Same applies to MAF sensor readings on transients - they read inlet manifold filling and emptying spikes that benefit from filtering or feeding the results into an inlet manifold model if using a conventional throttle. Valvetronic doesn't do this though.

Yea there is probably a somewhat significant latency and possibly limited sensor bandwidth as well. When it defaults back to open-loop one has to assume that it is then relying (primarily) on the MAF table for fueling right? I mean the whole valvetronic thing pretty much means MAF has to be the primary tool for reading air mass right?

[BMWcurious]

They decouple estimation of air mass from sensors for redundancy, modularity and diagnostics. Air mass can also be estimated from air pressure sensors and throttle angle or valvetronic lift along with temperatures and other values/calcs.

Fuel mass has a pilot calculation based on desired lambda and estimated air mass. Closed loop feedback from lambda sensor optionally comes later.

It is so much more complex than an ECU of 20 years ago where you could write the entire equation for injector pulse back to the MAF sensor on the back of a small envelope. Slightly simplified leaving out closed loop lambda: IPW = lookup(injdeadtime) + constant * lookup(MAFvolts) / RPM / lambdatarget.

[bahn]

Originally Posted by WhatsADSM

Not to change the subject too much, but I am starting to play a little bit more again and reviewed your earlier post about a recommended strategy. One of your points was:

"Set the "Boost Limit Multiplier" table to be 4.0 throughout the entire table."

I am still a little fuzzy on the DMEs translation from load to boost, and really the whole boost model (that occurs prior to WGDC). What exactly does this boost limit multiplier do?

Boost limit multiplier is used by the DME for boost ceiling calculations, the output is the log parameter boost set limit.

[WhatsADSM]

Originally Posted by BMWcurious

They decouple estimation of air mass from sensors for redundancy, modularity and diagnostics. Air mass can also be estimated from air pressure sensors and throttle angle or valvetronic lift along with temperatures and other values/calcs.

Fuel mass has a pilot calculation based on desired lambda and estimated air mass. Closed loop feedback from lambda sensor optionally comes later.

It is so much more complex than an ECU of 20 years ago where you could write the entire equation for injector pulse back to the MAF sensor on the back of a small envelope. Slightly simplified leaving out closed loop lambda: IPW = lookup(injdeadtime) + constant * lookup(MAFvolts) / RPM / lambdatarget.

Yea I get that. With the MAF you essentially get a (semi) calibrated air mass directly.

This ECU can go the speed density approach as well but its far more complicated at least in relation to a more conventional engine without valvetronic. Now you need inlet pressure, valvelift, and throttle plate. Along with the normal RPM, VE, and charge air conditions. I guess my real question is... Does this ECU actually use a "speed density" model at all, or at least in the normal case? I don't see any tables related to it, and it seems pretty difficult to do, relative to a working MAF sensor just sitting there waiting to be used. That doesn't mean it doesn't exist, could just be omitted from the XDF.

[WhatsADSM]

Originally Posted by bahn

Boost limit multiplier is used by the DME for boost ceiling calculations, the output is the log parameter boost set limit.

The more I look at the boost model the more I realize I don't understand. Lots of questions here. But first I will state what I "know". Up to the boost request, and simplifying, we have (and I plan to draw this up later for a better review):

Component Load Models --(Load Max)--> Throttle Models --(Load Request)--> Load Control Modelling --(Boost Request)--> Boost/WGDC Models

So with that said let's take the "boost request" as golden.

Beyond this point things go all fuzzy on me.

At this point I know there is (in a BMW provided tune) a PID feedback loop run on the boost setpoint/request/command.

1) What exactly is that setpoint/request/command? It appears that it is "boost request" parameter, is that correct?
2) Even after scaling the "boost request" parameter doesn't actually match the "boost setpoint factor" used in a majority of the wgdc tables. The two values are loosely tied but with some factor between them. Maybe the ECU is trimming the command to the WGDC tables (boost setpoint factor) based on some charge air conditions?
3) What is the boost multiplier/boost set limit for then? A separate value (ceiling) used to pull back on throttle/wgdc if it ever exceeds? If so see point #2, how do I know what value that is in boost pressure?


As an aside I started to play with commanded WGDC last night. As mentioned before both the axis need to be rescaled. While I was in there I also fixed the conversion factors in my XDF for the Y-axis (Bin Value/8192). It makes zero sense that the "boost setpoint factor (commanded)" would be 0.5 under the no-boost case. That should really be 1. Essentially the whole thing should be scaled similar to the compressor characteristic table. (I.e. Starts at 1 and goes from there). This allows you to use the normal "Boost Setpoint Factor" instead of the commanded one and makes everything look a lot nicer:

[BMWcurious]

No speed density model in the conventional sense. It is something I wanted to get into but haven't prioritised, but it looks more like a residual gas model based on valve overlap. Thankfully it seems not to need alteration for tuning as people are not really changing the VE of the engine at part load (where VE gradients are great) from aftermarket cams.

[WhatsADSM]

Originally Posted by BMWcurious

No speed density model in the conventional sense. It is something I wanted to get into but haven't prioritised, but it looks more like a residual gas model based on valve overlap. Thankfully it seems not to need alteration for tuning as people are not really changing the VE of the engine at part load (where VE gradients are great) from aftermarket cams.

Residual gas would work as well I guess, similar concept in practice anyways... Probably a bit more abstracted than a generic "VE" coefficient.

Do you know if it references this model over the MAF at all? I know many ecus like GM (Delphi?), will blend the two models with a bias to use speed density under transients and MAF under steady state.

[BMWcurious]

Not sure if blend or plausibility check and switch, or virtual sensor situation.

[bahn]

Originally Posted by WhatsADSM

The more I look at the boost model the more I realize I don't understand. Lots of questions here. But first I will state what I "know". Up to the boost request, and simplifying, we have (and I plan to draw this up later for a better review):

Component Load Models --(Load Max)--> Throttle Models --(Load Request)--> Load Control Modelling --(Boost Request)--> Boost/WGDC Models

So with that said let's take the "boost request" as golden.

Beyond this point things go all fuzzy on me.

At this point I know there is (in a BMW provided tune) a PID feedback loop run on the boost setpoint/request/command.

1) What exactly is that setpoint/request/command? It appears that it is "boost request" parameter, is that correct?
2) Even after scaling the "boost request" parameter doesn't actually match the "boost setpoint factor" used in a majority of the wgdc tables. The two values are loosely tied but with some factor between them. Maybe the ECU is trimming the command to the WGDC tables (boost setpoint factor) based on some charge air conditions?
3) What is the boost multiplier/boost set limit for then? A separate value (ceiling) used to pull back on throttle/wgdc if it ever exceeds? If so see point #2, how do I know what value that is in boost pressure?


As an aside I started to play with commanded WGDC last night. As mentioned before both the axis need to be rescaled. While I was in there I also fixed the conversion factors in my XDF for the Y-axis (Bin Value/8192). It makes zero sense that the "boost setpoint factor (commanded)" would be 0.5 under the no-boost case. That should really be 1. Essentially the whole thing should be scaled similar to the compressor characteristic table. (I.e. Starts at 1 and goes from there). This allows you to use the normal "Boost Setpoint Factor" instead of the commanded one and makes everything look a lot nicer:

Yeah the boost setpoint factor (commanded) parameter is also incorrectly scaled when compared to the PID boost setpoint factor =/ for tuning purposes keep the original Y-axis conversion but rescale the Y-axis.

[WhatsADSM]

Was an odd day at the dyno.

Long story short I was on my normal Mustang load cell dyno, and its pretty clear that it doesn't load the car the same as it does on the street. It almost surely wasn't providing enough load, and that wrecks absolute havoc on tuning turbo cars. Especially if you are in commanded wastegate since there is no PID loop to resolve any errors. The only tune that looked like it was running correctly was stock. The OTS Stage 1 tune from MHD made no more power and the ECU seemed utterly confused by it all. My quick street commanded wgdc tune made even less then them all as it just couldn't hold any boost with the commanded WGDC curve that worked well on the street.

I ended up doing a quick tune based on the stock (lightly tweaked) compressor characteristic map and PID and it actually worked out pretty well, but still was having a bit of trouble holding boost in the upper RPM range on the dyno. It made what I expected for torque, but a little short on horsepower because it still couldn't hit the boost targets over ~5500RPM. However it is fantastic on the street and hits all its targets! IMO I kind of like keeping the stock WGDC strategy, at least for a true "Stage 1" (i.e. stock hardware) car. Was super easy to add a decent chunk of power/torque and keep a similar curve to stock, all while having great part throttle response and all of the safe guards in place.

Just as an interesting thought. Assuming MHD has everything scaled properly in the XDF I *think* you theoretically could treat kW as duty cycle. You could then use the compressor map as a commanded duty cycle. Additionally because you are still using the non-commanded WG model you could also use the PID tables. Then in the "wastegate position model" (which I believe it uses to translate from power to duty cycle), put in a linear 1:1 scaling of "power" in the Z cells to duty cycle in the X axis. Be sure obviously to scale the X axis out to 100.
Other tables that work in kW would likely need to be scaled around as well (or simply zero'd). Not sure if I want to be the guinea pig trying this though!

[MHD Tuning]

I came here to help last week, read the first page, got a bit offended by the ridiculous accusations put on me or Justin. I gave up after that.

Anyways, feel free to tag me so I can either correct the xdf, or justify why it's scaled as it is.

[JETmn]

Originally Posted by MHD Tuning

I came here to help last week, read the first page, got a bit offended by the ridiculous accusations put on me or Justin. I gave up after that.

Anyways, feel free to tag me so I can either correct the xdf, or justify why it's scaled as it is.

I think what you were seeing was the frustration from your customers at not having enough information to be able to self-tune. I don't think anything was malicious, but you do need to give some more information to the self tuners. You advertise that you can self tune, but the information is not there to be able to do so.

That is what this thread is about, getting everyone together to try and figure it out since that information isn't there. Pushing away a problem is not the way to support your product (I am an aftermarket manager).

[bahn]

Originally Posted by MHD Tuning

I came here to help last week, read the first page, got a bit offended by the ridiculous accusations put on me or Justin. I gave up after that.

Anyways, feel free to tag me so I can either correct the xdf, or justify why it's scaled as it is.

I could see how that would bother you, however please don't let one persons statement deter you from sharing information with the rest of us.