You are correct ... less restriction in the intake opens up some available flow ... I plan to upgrade to a cone filter when I have some extra cash floating around.

 

Speaking of intake restriction, back when I installed my FPgreen. I couldn't get over 350whp on our dyno no matter what I tried. Nothing worked. I thought the turbo was bunk.

I took off my stock airbox with drop-in filter and installed a open filter.

Wham, 20whp, 24whp after tuning for it. Same AFR's in the end, little more boost on the top end.

I guess you can say, an open filter can work miracles. I was about to throw in the towel on that turbo.



You just have to be good about somehow still getting fresh air to the filter. On track days, the hot intake air kicked temp compensation in and the car would richen up by almost a full point.

That's when I hacked my airbox to bring in cooler/fresher air to the open filter:






Problem solved.

Stock turbo Evo 9's with open filters regularly output 10-15whp more than stock airbox equipped Evo 9's on our dyno.

 

Okay, so the fix I mentioned didn't exactly work. The issue seems better, but it's not completely fixed. Now it kind of seems that the ECU is allowing itself to slowly build up to the desired load ...



Pay attention to the load error, actual load and desired load at RPM points 4600, 5800 and 6400 ... things just don't add up ... and I mean that literally. Load error shows load being on target at 6400 RPM, but it is actually ~20% below target. This is obviously the problem, but why is this happening?

(BTW, that boost curve is looking a little better ...)

 

Here is a comparison of tonight vs last night ... the load targets didn't change but the actuals did. The curves are very similar aside from the fluctuation caused by the TBEC settings ...

The darker lines are from tonights log ...

 

TouringBubble,

Humor me, if you have the time. I'll make it as easy as possible too.

1. Turn off error correction, run the same WGDC table you are running now.
2. Log the car
3. Change your BDEL at each RPM to match what the log shows.
4. Turn back on error correction

Do a log and see if it does the same thing.

I personally think it is because of the large swing of Error correction at the beginning and since it's on a timer and you are using the stock BCS, it doesn't have time to ever catch up to the target load during the pull. Since you have a pretty flat WGDC table, it's ALWAYS hunting from the first error correction event on, since you are depending more on error correction to set your boost curve than wgdc. Even with the update variable set pretty high (low number).

If you try out the experiment I outlined above, the WGDC will be inline more with your target load and the error correction won't have to work as hard.

Just humor me.

 

I've seen you talk about this before. But is this for IXs only or is this for VIIIs as well? I realise that it seems a lot of the more active people here mess with IXs and its not clear if all of these things apply to the VIIIs as well .

 

I've seen it on both for sure. Post #47 is a 05 Evo 8.

 

Bryan - that's a NICE clean engine bay

ps what brand is that pod?

 

I might give that a try tonight ... I do see what you are suggesting. But, that still doesn't explain the load error obviously shooting for the wrong target (negative correction while load is below target). Also, if you revisit the first post and look at the second graph, the WGDC was making HUGE changes to try to correct and was still aiming for the correct load value.

I've got a feeling that I could leave the car as is and log again tonight and it would aim to the correct target ... if it is still off, I'll try your suggestion.

 

I can reaffirm that 3-port holds more boost up top.

Also TouringBubble, you have friends with evo 9s right? Try borrowing one of their ECUs and flashing your rom to it. Yours is acting weird, subtracting duty cycle when the load is under target. It's like it switched positives and negatives.

Other than that, I agree with Razorlab about the BCS not being able to correct fast enough.

 

That is not what he is concerned with. He is wondering why he was 20% load lower then he should be with no signs that the ecu was trying to correct it.

 

that's kind of how it seems, except that the TBEC is actually correcting in the right direction, just no to the correct desired load. The load curve rises and TBEC adjusts down ... it falls and TBEC corrects up. It's working as intended.

And it seems that my tweaks to the TBEC table last night helped the unstable boost a little ... the only issue is the big spike down low. After that it is very stable. After you have a stable TBEC table, the BWGDC shouldn't really be a huge factor if it's set at a decent median value.

I'm aiming to have the TBEC work much like a shock absorber ... Boost spikes, the TBEC pulls it down with maybe just a tad of overcorrection (-5% or so) and then stabilizes. That's currently how it is acting. I just need to make some small adjustments. I don't in any way intend for this method to completely rid the load curve of all spikes/dips.

 

And i believe that is the intent of a TBEC. I doubt it was designed to really take control all the time. Plus i personally would rather have good values hard coded versus depending on the ecu to sample, correct, sample, correct, ect.

 

I'm basically taking the opposite approach though ... I want the ECU to sample and correct a lot. What I've found is that tuning a really good BWGDC makes for really nice, stable boost. But, it also allows for a slightly lacking TBEC table since correction isn't really depended on.

When the seasons change the required WGDC for a given boost also changes, and therefore your nicely tuned BWGDC table is not longer correct and TBEC starts to control more and more ... this exposes any flaws in the TBEC and can easily cause erratic boost levels.

My approach is to have a really solid TBEC table that can essentially control boost on its own. Now, this will never be as good as a great BWGDC table tuned for that specific altitude and temp, but it should be more stable year round.

At least that is my approach ... If it will work or not has yet to be decided (by me at least). I haven't seen proof to heavily support one method over the other just yet. Now, if my issue is in fact caused by this approach, then that will be obvious proof that it just doesn't work. But evidence so far doesn't seem to support that.

 

Or just have a summer and winter map for BWGDC