[themyst]

Since we got information from Cobb regarding how they have defeated every load limit barrier they have encountered thus far, I was hoping I could get the two main piggyback reps to chime in regarding this information (Shiv, Mike)

I was having a long discussion with Clap135 about this issue, and I am still not quite grasping the concept. He states that piggybacks are limited in real-world performance due to the engine dumping air/fuel when the load limit has been reached. Not ever having tuned a car before on other platforms (every car I've owned before this one was NA) I am not trying to pretend I know everything about this point.

Knowing this isn't my field of expertise, in theory, piggybacks are intercepting and manipulating various signals, including cps offsetting for advancing and retarding ignition and feeding the DME a stock boost level so that it does not trigger an underboost code. My question is, being that the stock DME is receiving stock output in every way conceivable to stay happy, how does this theory come into play?

I bet if this theory were true, we could throw a car with a piggyback on a load dyno, such as a Mustang or DD, and the piggyback units would perform significantly worse than their flash-based counterparts.

Maybe I'm completely stupid. I really want to understand how this could potentially affect real-world performance from a piggyback standpoint, so I was hoping the various reps could chime in regarding this question.

Thanks in advance if you answer.

[OpenFlash]

I think the misunderstanding comes from what one believes "load" to be. In terms of speed density based engine management systems (such as the DME in the n54), engine load is how much calculated airflow is being consumed at any given time. Or to put simply, manifold pressure corrected by intake charge temp. That is all the DME needs to calculate engine load at any given time.

I think people confuse load with the "load" term used when it comes to dynos. In the case of dynos, load is basically the acceleration rate of the run. it's somewhat of a misnomer. Dyno "load" can be zero, which represents a steady state load (ie, engine not accelerating but holding a constant engine speed. Or it can be positive which indicates a typical acceleration run. But the ENGINE load has nothing to do with the DYNO load. They are two separate things. Often confused.

For example, a load-bearing dyno can load the engine to maintain a fixed RPM. This RPM can remain constant at a variety of ENGINE loads (ie, from several inches of vacuum to full boost).

As for the piggyback/flash question, it becomes apparent that both tuning approaches calculate engine load from the same sensors. In the case of the Procede, it reads both actual load (actual MAP corrected by air temp) and the DME perceived load. Unlike traditional piggybacks, the Procede uses this DME data (via CAN) to induces a consistent and predictable DME output by managing the relationship between DME boost targets and DME perceived boost. With a predictable input/output relationship, one can effectively implement the tuning adjustments. It's pretty simple. There is no "load barrier" to defeat. The DME sees the load it expects to see. The only barrier to the tune is the response range of the actual engine load sensor (~22psi).

Feel free to ask for any clarification as I may not have presented the most understandable explanation. It's late and I've had at least one eye on my laptop screen since 9am and the other eye on the road. If only my insurance company knew....

shiv

[ianbiz]

i understand how procede does what it does, but can i ask why you(or the other Piggyback companies) have never really ventured into a flash?

i can see it being a case of evolution, (starting with the old school proceed/JB1, the the V2/JB2 etc), but wouldnt one flash solve most of the issues with trying to work around on board systems?

[themyst]

Shiv - so you are saying the load targets are fed to the DME as boost and CPS offset are? In essence, the car's load level (not sure on terminology) is significantly higher than what the DME is getting fed by the Procede?

[ETS Michael]

Subscribed

[OpenFlash]

Originally Posted by ianbiz

i understand how procede does what it does, but can i ask why you(or the other Piggyback companies) have never really ventured into a flash?

i can see it being a case of evolution, (starting with the old school proceed/JB1, the the V2/JB2 etc), but wouldnt one flash solve most of the issues with trying to work around on board systems?

In my opinion, the basic DME logic is not ideal for a high power application. We are know at the point were we expect a tune to double or even triple factory boost pressure. On a DME that tends to target the similar ignition advance value and boost target regardless of historical knock activity. Kind of silly.

By comparison, modern DMEs designed to support high boost/high specific output turbo engines (evo, sti, porsche, etc,.), almost always rely a multiple timing/fuel/boost maps (high det and low det) and constantly updating knock activity coefficient that dictates what values, within these wide ranges of maps, the DME will output/target. The MSD80/81, by comparison was structured to support an 100bhp/liter engine that only runs 5-6psi on a cold night. Adding 10psi of boost on top of that (with little or no hardware changes) benefits from some additional smarts in my opinion.

Not entirely by coincidence given our tuning background, Procede autotuning logic is based upon what Evo and Sti ECUs do in response to history knock activty/calculated tune aggression. But with a much wider authority range and user definable limits.

Shiv

[OpenFlash]

Originally Posted by themyst

Shiv - so you are saying the load targets are fed to the DME as boost and CPS offset are? In essence, the car's load level (not sure on terminology) is significantly higher than what the DME is getting fed by the Procede?

Correct. The procede feeds the DME a stock intended load target. Even when supporting 100+ more hp and running 10psi more boost, the DME stays happy which is what ensures predictable DME output upon which it offsets. There are few things more misunderstood in this industry than how a a proper piggyback works. I recall having a discussion with Steve Dinan on a the phone and he didn't fully understand this either

[Rob@Cobb]

Originally Posted by shiv@vishnu

In my opinion, the basic DME logic is not ideal for a high power application. We are know at the point were we expect a tune to double or even triple factory boost pressure. On a DME that tends to target the similar ignition advance value and boost target regardless of historical knock activity. Kind of silly.

By comparison, modern DMEs designed to support high boost/high specific output turbo engines (evo, sti, porsche, etc,.), almost always rely a multiple timing/fuel/boost maps (high det and low det) and constantly updating knock activity coefficient that dictates what values, within these wide ranges of maps, the DME will output/target. The MSD80/81, by comparison was structured to support an 100bhp/liter engine that only runs 5-6psi on a cold night. Adding 10psi of boost on top of that (with little or no hardware changes) benefits from some additional smarts in my opinion.

Not entirely by coincidence given our tuning background, Procede autotuning is based upon what Evo and Sti ECUs do with respect to constantly adjusting the tune based upon history knock activty/calculated tune aggression. But with a wider authority range.

Shiv

Generally the Subaru and Mitsu ECUs tend to run multiple maps due to a lack of logic and processing power to properly calculate a precise and efficient tune for the conditions they are in at the time. In simple terms the engineers are betting they guessed well at the conditions the car will be in. As we have seen with both the Subaru and Mitsubishi factory tunes, they most certainly were off at factory power levels.

The MSD8x ECUs are able to calculate what the engine needs real-time from a good base data at 2psi or 20psi. They don't work on pressure alone as it is only one variable in equation. Instead they work heavily on sensor input of the conditions inside and outside the motor compensating for different conditions to most accurately and efficiently run the motor. Bosch publishes an expansive amount of data they have collected and put into their engine electronics, and mechanical parts for that matter, if you ever want to take a peek to get a gist of the logic involved.

Either way, having multiple sets of the same table has little bearing on the capabilities of the hardware or software.

As time goes on the power of factory ECU will continue to evolve to the point where there is no longer a need for tables. Everything will be calculated real time.

Cheers,
Rob

[OpenFlash]

Originally Posted by Rob@Cobb

Generally the Subaru and Mitsu ECUs tend to run multiple maps due to a lack of logic and processing power to properly calculate a precise and efficient tune for the conditions they are in at the time. In simple terms the engineers are betting they guessed well at the conditions the car will be in. As we have seen with both the Subaru and Mitsubishi factory tunes, they most certainly were off at factory power levels.

The MSD8x ECUs are able to calculate what the engine needs real-time from a good base data at 2psi or 20psi. They don't work on pressure alone as it is only one variable in equation. Instead they work heavily on sensor input of the conditions inside and outside the motor compensating for different conditions to most accurately and efficiently run the motor. Bosch publishes an expansive amount of data they have collected and put into their engine electronics, and mechanical parts for that matter, if you ever want to take a peek to get a gist of the logic involved.

Either way, having multiple sets of the same table has little bearing on the capabilities of the hardware or software.

As time goes on the power of factory ECU will continue to evolve to the point where there is no longer a need for tables. Everything will be calculated real time.

Cheers,
Rob

Hi Rob,
I completely agree that the MSD80/1 DME is very fast reacting and very capable. If that wasn't the case, one couldn't get away with hooking up a boost controller and increase boost pressure by 100-200%. Doing something like that in a Mitsu/Sti application would be an expensive and short-lived exercise. However, I have yet to see an unassisted MSD80/81 DME proactively adjust timing and boost targets based upon historical knock retard activity. At most, I've seen it adjust ignition retard decay and richen lambda targets. But the nominal ignition advance setpoint remains essentially unchanged which is understandable given the relatively low output/stress level of the factory tune.

Maybe one day the state of the art will get to the point were DME output based upon an internally calculated combustion model is so spot on that we see max power without ever crossing over the knock threshold. But I don't think that day is coming any time soon. But when it does come, I'm sure it will be from the Germans.

Regards,
Shiv

[OpenFlash]

Originally Posted by Rob@Cobb

Quite honestly I have not tuned a piggieback or attempted to trick the ECU. It's a feat they can push the motors as hard as they do while telling the ECU life is peachy. They have my respect for the number of hours spend modeling what the ECU needs to hear.

Also, from your other thread, I just wanted to point out that not all piggybacks require modeling of ECU demands. In the case of the Procede, heaps of data is continuously read through the PT-CAN. As you can imagine, knowing real-time ignition advance, boost target, throttle blade angle, calc torque output, lambda, etc,. this eliminates the guesswork and input/output channel limitations that conventional piggybacks have to contend to.

That said, every tuning medium has it's strengths and weaknesses.

[Rob@Cobb]

Originally Posted by shiv@vishnu

Hi Rob,
I completely agree that the MSD80/1 DME is very fast reacting and very capable. If that wasn't the case, one couldn't get away with hooking up a boost controller and increase boost pressure by 100-200%. Doing something like that in a Mitsu/Sti application would be an expensive and short-lived exercise. However, I have yet to see an unassisted MSD80/81 DME proactively adjust timing and boost targets based upon historical knock retard activity. At most, I've seen it adjust ignition retard decay and richen lambda targets. But the nominal ignition advance setpoint remains essentially unchanged which is understandable given the relatively low output/stress level of the factory tune.

Regards,
Shiv

Simply removing ignition timing hurts efficiency, ruins emissions, and kills cats. Why only use one tool in the chest when the ECU has many at it's discretion? The ECU is setup to be able to react fast enough to the impending detonation events with proper internal ECU mapping by removing/adding load, fuel, and/or spark at stock power and beyond.

There is a history of what timing the ECU requests on individual cylinders, but it's much faster than the Subaru and Mitsu ECUs you speak of. They generally are very slow and require a reset to get your timing back in any kind of timely fashion. The BMW is trying hard to run what the calibrators set as MBT and will continue to try to get back to those values asap. It just happens the ECU is good enough to pull the timing in near real-time conditions not leaving a history clearly visible. As a matter of fact the system is so sensitive it likely will pull 2-3 degrees on a cylinder on stock mapping when running good gas. All the cylinders will start talking when the detonation threshold gets closer. I believe your device listens to one of the cylinders which happens to be a quieter cylinder. Either way the BMW/Seimens/Bosch logic (not sure who all had their hands in the logic ) used is safe, effective, and efficient when the ECU knows what is actually going on.

Strapping a device to the outside of of the ECU which tells the ECU it's running at a stock load level, when the motor is really seeing 40% more load, is simply pushing outside of where it can protect itself. Calling the ECU "silly" or "not ideal for high power applications" for not being able to handle a 40% bump in load when it expect stock load may not be entirely accurate.

Taking what the ECU is requesting and feeding back is a neat trick for riding the line of what the ECU will allow. Lots of good effort and engineering there for sure. It's also fantastic that you can remove timing with the Procede. There might be a few more hurt motors trying to run 14-15psi on the stock timing curve. You should see what timing on all the cylinders does when trying to run higher boost on the stock timing curve. It's not pretty.

As I'm sure you have seen I have played with the Procede. It's a nice tool and provides good power.

Originally Posted by shiv@vishnu

Also, from your other thread, I just wanted to point out that not all piggybacks require modeling of ECU demands. In the case of the Procede, heaps of data is continuously read through the PT-CAN.

You should see what is available though logging beyond the base BMW PIDs. The information is pretty cool for nerds like us.

Cheers,
Rob

[OpenFlash]

Originally Posted by Rob@Cobb

Simply removing ignition timing hurts efficiency, ruins emissions, and kills cats. Why only use one tool in the chest when the ECU has many at it's discretion? The ECU is setup to be able to react fast enough to the impending detonation events with proper internal ECU mapping by removing/adding load, fuel, and/or spark at stock power and beyond.

The ECU can only do this if the mapping is consistent with the operating conditions/fuel quality. Pushed far enough beyond that and the engine will audibly knock. We have seen this on all overly aggressive tunes, regardless of tuning medium. Some, yourself included I believe, compensate for an overly aggressive tune (ie, standard tune used in especially harsh conditions or with low qualify fuel) by running octane booster or water injection. Others, like myself, would rather have a tune that automatically adjusts tune aggression proactively based upon historic knock retard activity. Also, keep in mind that our ignition target reduction is a short-term correction. What follows is a boost reduction which allow advance to creep up to desired levels. So efficiency reduction, elevated cat temps and elevated emissions aren't a concern

There is a history of what timing the ECU requests on individual cylinders, but it's much faster than the Subaru and Mitsu ECUs you speak of. They generally are very slow and require a reset to get your timing back in any kind of timely fashion. The BMW is trying hard to run what the calibrators set as MBT and will continue to try to get back to those values asap. It just happens the ECU is good enough to pull the timing in near real-time conditions not leaving a history clearly visible. As a matter of fact the system is so sensitive it likely will pull 2-3 degrees on a cylinder on stock mapping when running good gas. All the cylinders will start talking when the detonation threshold gets closer. I believe your device listens to one of the cylinders which happens to be a quieter cylinder. Either way the BMW/Seimens/Bosch logic (not sure who all had their hands in the logic ) used is safe, effective, and efficient when the ECU knows what is actually going on.

I think that is where the misunderstanding arises. Using a properly integrated piggyback doesn't not rob the DME of any of it's safety-related functionality. Nor is, in my opinion, the acceptable knock retard activity at stock power levels equal to the acceptable knock retard activity at 50% higher power levels. Which is why running a static DME flashed 15psi in harsh conditions usually results in audible knock.

Strapping a device to the outside of of the ECU which tells the ECU it's running at a stock load level, when the motor is really seeing 40% more load, is simply pushing outside of where it can protect itself. Calling the ECU "silly" or "not ideal for high power applications" for not being able to handle a 40% bump in load when it expect stock load may not be entirely accurate.

Clearly the DME can "handle" a 40% bump in power. The question is whether it can do that with a greater safety margin. Or more power gains with the same safety margin. In a variety of different conditions. I'm sure we can agree that the next several months will be interesting for all.

And I have to say, it is refreshing debating these topics with another tuner, such as yourself, instead of a salesperson.

Cheers,
shiv

ps. On that note, it's late and I desperately need (or so I'm told) my beauty sleep.

[cwg]

Rob and Shiv - great exchange - very educational and fascinating discussion. appreciate the insight into how these cars work

[chris b.]

[D.B.S]

I won't even say I understand what half of what they talked about, but... I do like the interaction (and civil) these two tuners are having... I feel like I've educated myself just by reading these few posts.

NOW what would be really interesting is if the two tuners teamed up and created a combo piggy/flash... Best of both worlds, with none of the weakness that either may or may not have... I know, In my dreams...

[mithiral67]

Originally Posted by Army335xi

I won't even say I understand what half of what they talked about, but... I do like the interaction (and civil) these two tuners are having... I feel like I've educated myself just by reading these few posts.

NOW what would be really interesting is if the two tuners teamed up and created a combo piggy/flash... Best of both worlds, with none of the weakness that either may or may not have... I know, In my dreams...

A civil informational discussion between tuners . . . . amazing.

Yes, a combo tune would be amazing. A flash to handle the up in power and a piggy back to read changing inputs and adjust the flash tables on the fly while also giving us the fun piggyback options that just aren't available at this time on a flash.

[atlharry]

best. thread. ever.

[Clap135]

Wow, a normal conversation?

Ben knows my standing on load limits and piggybacks/flashes. I have seen this multiple times on many platforms. Techinically speaking, the recent discovery made by Shiv and his team allows for removal of a form of "load limit" which it hasnt been able to do so before. What worries me personally, is that as the procede or other smarter piggy backs begin to encounter new ways around limits, the amount of sensor that are getting fed bs signals to stay happy rises. That in it self just does not sit well with me, but that is just my opinion. Rob also brought up an intresting topic of monitoring timing on all 6 cylinders. I believe the procede/bt tool/jb all use cylinder 1 as a reference piont. As many know, there are vast tolerance difference btwn these cars in terms of hardware. For example injector 1 is different than inject 6, one fuel pump lasts 50k, the other 800 miles. To safely make smooth power, one needs to start taking into consideration everything they can before making aggressive tunes. Hopefully ATR lets me do that. This might not be the solution to most on here as it does involve a little bit of knowledge, nothing crazy though.

[Javier]

... i learned a lot from this thread

[**335i**]

nice reading

[itsbrokeagain]

good reading

[Boostin335]

Looks like only 2 showed up to discuss... would love for more interaction of other significant parties in the n54 modding world to hear their input.