[Ænema]

Me and rader1 have been working together on a simplified walkthrough of ATR describing how to fix common issues or how to dial in boost/timing curves. He posted a short and general DIY the other day and i thought i'd share it here for you guys that are seeing boost overshoots in your logs. Expect a much more detailed walkthrough that covers this and more subjects in the next couple weeks.
Cheers.

Originally Posted by rader1

Add "Boost setpoint factor" and "MAF requested(WGDC)" to your datalog list. Then grab a couple more logs and where the boost overshoots are occuring in relation to the above logging channels pull a little WGDC out. The general consensus is to make reductions 10% at a time so as not to pull too much out.

An important thing to note is to be sure ATR is setup to display the MAF REQ(WGDC) in (GS) rather than (KG/m)

(Keep in mind the following is all just for example)
So, for example, if your overshoots are happening at:
Boost setpoint factor= 2.1
MAF REQ(WGDC)= 180

Then you open ATR, go to the WGDC base table and find the cells that correlate best.



Then pull some DC out


Then, save the map. Transfer to the AP and relog and see how it looks.
Give it a few pulls after flashing so that the logs have calmed down. You don't want to end up chasing your tail over an issue that may not really be there.

Also, when using this method it's possible that you may run into boost oscillations. If that happens it means you're getting close to where you wan't to be.

One thing I would like to add to this is that if you are consistently UNDER boost target(usually it will be in the higher RPMs) you can ADD some DC into the base table using the same process until you hit target.

[themyst]

This platform is quite forgiving on base WGDC due to the wide correction range of the PID. You'd rather pull too much from the base table than too little.

[Ænema]

To be honest, I really don't like the PID tables. I've zeroed mine out just as an experiment and I haven't seen any I'll effects yet.

[Fully_Bolted]

Originally Posted by Ænema

To be honest, I really don't like the PID tables. I've zeroed mine out just as an experiment and I haven't seen any I'll effects yet.

I would think temperature or elevation changes would cause the biggest issues.

[Ænema]

Originally Posted by Fully_Bolted

I would think temperature or elevation changes would cause the biggest issues.

That's my line of thinking. I tried it a couple weeks ago and the weather has been pretty constant since then, i'm hoping for a cold snap to see what happens lol. I did it to an OTS stage 2+ map and it's the only change, so when/if anything goofy happens i'll know for sure what caused it.

[Ænema]

Ok, so i finally got the cold sweather(~38F) i was waiting on to test out what happens when you zero out the PID tables....

HOLY THROTTLE CLOSURE BATMAN!!!!

I have to admit, this was not unexpected. However, I was expecting to see a lot of throttle plate action but not not a constant 30%-40% TPS.

(I can't seem to find the logs i took a couple weeks ago as a comparo. New netbook so they may have gotten lost while i was transfering all my files, but i'll keep looking.)

Something else interesting to note is that even with the PID tables at zero the WGDC base and after PID are not the same.

Logs attached

[Joshboody]

Nice and ballsy with zeroing PID. Can you attached the ATR map?

Couple things I noticed... I expected WGDC base and "after PID" to match, but this is not the case. "Boost" channel is factoring throttle position (pressure differential)

If you had MAP and req MAP matching more closely before compared to the attached logs due to temperature I assume, then this would be a good time to play with the "Cyl Temp Comp" tables which I am guessing directly control WGDC per temps (FYI: I have not played with these). This way you could theoretically map WG per all conditions and PID would play a more secondary role in boost control.

Next logs maybe add WGDC temp

[Ænema]

Yeah, I think the WG temp channel/table will definitely one the next things I experiment with. First, I think I will try zeroing out individual P, I and D tables to see what happens.

Admittedly, this is entirely an experiment for me to try and figure out some of the less used tables. In no way would I advise someone to try to make a map after zeroing out the PID tables. It will just lead to a constant battle IMHO.

As far as the map goes, I just took the OTS stage 2+ drive map and zeroed out the PID factor tables. No other changes.

[Monster335]

I sent a datalog to cobb running e30 map v403 and they said i have to adjust because of throttle closures. Will someone be kind enough to look at my datalog and show me what Im needing to adjust. Im such a novice at this....sorry

[Ænema]

Originally Posted by Monster335

I sent a datalog to cobb running e30 map v403 and they said i have to adjust because of throttle closures. Will someone be kind enough to look at my datalog and show me what Im needing to adjust. Im such a novice at this....sorry

Sure, just attach a datalog

[Monster335]

here is the file...thanks

[Ænema]

Originally Posted by Monster335

here is the file...thanks

Yeah, there is definitely some overboosting going on there. However, you have to add "boost setpoint factor" and "MAF requested(WGDC)" to the logging list before you can be sure where to make changes.

[Monster335]

how about this one

[n54door]

Overboosting is an inhearant issue with the DME when using a performance flashed tune, such as Cobb. And, the reason why people are using piggybacks as a method to counter the DME logic from exceeding the intended boost target due to the DME's design to acheive load target.

IMO - Cobb is not a good choice by itself when running any aggressive tunes to allow for larger turbos, higher octain/meth.

It would be great to see a workaround, but my feeling is it is simply not possible to counter the DME login in flash tune.

Flash tunes by themselves seem far too dangerous in the summer when the DME wants to overboost to hit load target.

[Joshboody]

You can control load based on IATs which will keep boost lower in the summer. The issue isn’t necessarily that its tough to control boost, but that its tough to limit DME intervention based on calculated torque. I have some ideas, but no one wants to be my guinea pig.

There’s a couple issues and 1 of them is post-shift flatline… others, timing retard during torque overshoots, throttle plate closing. One of the best ways to test is “stepping the throttle”... would love to see some pro-tunes do this. When you pull back on throttle closure sensitivity, you increase timing intervention which is much worse for performance.

I did some limited testing, but I really don’t care except out of curiosity… my stacked setup runs great.

Why do the pro-tunes run so great on the dyno and ¼ mile. The answer is how they tune. They set a very high load target which will never be reached at WOT. They also now have the “race logic” which is a more linear req boost to load relationship. They max out req boost (never reaching load target), and tune in WGDC limits. This runs fine (albeit a little aggressive in some cases) at WOT for the most part. BUT at part throttle the tuning isn’t dialed in and the DME intervenes trying to regulate torque.

Much of this is speculation based on what I know about ATR. And pro-tuners could have further advantages (in addition to race logic) that ATR peeps do not… kinda sucks cause ATR was touted as having the same tuning features as the pro version.

End of random rant

[Fully_Bolted]

Originally Posted by n54door

Overboosting is an inhearant issue with the DME when using a performance flashed tune, such as Cobb. And, the reason why people are using piggybacks as a method to counter the DME logic from exceeding the intended boost target due to the DME's design to acheive load target.

IMO - Cobb is not a good choice by itself when running any aggressive tunes to allow for larger turbos, higher octain/meth.

It would be great to see a workaround, but my feeling is it is simply not possible to counter the DME login in flash tune.

Flash tunes by themselves seem far too dangerous in the summer when the DME wants to overboost to hit load target.

Ramblings like these are why people that haven't used Cobb should just stay out of the conversations. My boost is consistent whether its summer, winter, fall, etc. only thing that will effect that is altitude - just like all tunes.

[Ænema]

Originally Posted by n54door

Overboosting is an inhearant issue with the DME when using a performance flashed tune, such as Cobb. And, the reason why people are using piggybacks as a method to counter the DME logic from exceeding the intended boost target due to the DME's design to acheive load target.

IMO - Cobb is not a good choice by itself when running any aggressive tunes to allow for larger turbos, higher octain/meth.

It would be great to see a workaround, but my feeling is it is simply not possible to counter the DME login in flash tune.

Flash tunes by themselves seem far too dangerous in the summer when the DME wants to overboost to hit load target.

I have zero issues dialing in any boost curve I want. On my most aggressive meth map I run ~18.5psi tapering to ~13psi but I am ALSO am running a higher than factory timing curve(something piggys can't do.)

There are no workarounds going on here. It is actual DME logic you use to "target" boost through load. I would rather use a tuning software that incorporates fueling, timing, boost, VANOS etc... than rely on sensor biasing to hit targets(usually not when running the PROcede if were talking fueling.)

The truth is that the same old sang and dance routine certain tuners have been doing is, in fact, bullshit.

[Ænema]

Originally Posted by Monster335

how about this one

I'll take a look at it as soon as I get home from work.

[n54door]

Originally Posted by Ænema

I have zero issues dialing in any boost curve I want. On my most aggressive meth map I run ~18.5psi tapering to ~13psi but I am ALSO am running a higher than factory timing curve(something piggys can't do.)

There are no workarounds going on here. It is actual DME logic you use to "target" boost through load. I would rather use a tuning software that incorporates fueling, timing, boost, VANOS etc... than rely on sensor biasing to hit targets(usually not when running the PROcede if were talking fueling.)

The truth is that the same old sang and dance routine certain tuners have been doing is, in fact, bullshit.

But what happens when the weather temp increases 70+ degrees, does the DME not increase load to compensate for the loss in air density, thus adding more boost? And in reverse, removing load/boost, if the air is cold?

[Ænema]

Originally Posted by n54door

But what happens when the weather temp increases 70+ degrees, does the DME not increase load to compensate for the loss in air density, thus adding more boost? And in reverse, removing load/boost, if the air is cold?

There are temp compensation tables and a boost cap that prevent over boosting and if the DME is able to hit target with less boost than that is what it will do. Remember, boost isn't what's important for power, air mass is. If I can make the same power running 16psi in the winter as I could at18psi ij the summer then I would rather run 16psi. However, I still wanted 18psi in the winter that's still perfect do-able. Like joshboody described above, if you set the load target above the boost cap.

[Joshboody]

Well my little rant was more about how the supposed premier Cobb tuners do it wrong. Anyway... boost can be limited per IATs with this table.

[n54door]

very interesting, this is the first time I've heard of this.