WGDC ceiling OFT stage 1 map

[DCAFS]

Hi guys:

I'm currently running the OFT stage 1 map stacked with Procede for meth control.

I have been trying to get my boost target 1 psi higher between 5K and 5.5K rpms.....but it's been a struggle.

I upped the load table in that rpm range from 200 to 205.....but found it did nothing to help increase boost.

Then while reading the Cobb "How-to" sticky I found a reference to the WGDC % limit table and increased the value in this table from the original 57% up 70% duty cycle.

So it seems that should have provided some more headroom for additional duty cycle in order to hit higher boost.

But when I look at the WGDC Ceiling Adder table......I see that cap of 57 again .

Do these two tables need to match in order for my change of 70% to work in order to raise the boost target?
.
.
.

[lulz_m3]

Hi guys:

I'm currently running the OFT stage 1 map stacked with Procede for meth control.

I have been trying to get my boost target 1 psi higher between 5K and 5.5K rpms.....but it's been a struggle.

I upped the load table in that rpm range from 200 to 205.....but found it did nothing to help increase boost.

Then while reading the Cobb "How-to" sticky I found a reference to the WGDC % limit table and increased the value in this table from the original 57% up 70% duty cycle.

So it seems that should have provided some more headroom for additional duty cycle in order to hit higher boost.

But when I look at the WGDC Ceiling Adder table......I see that cap of 57 again .

Do these two tables need to match in order for my change of 70% to work in order to raise the boost target?
.
.
.

The WGDC limit table is not your issue, its increasing WGDC in the upper RPM's to meet requested load. Try increasing the WGDC Adder & WGDC Airflow in the higher cells and see if that helps.

[DCAFS]

The WGDC limit table is not your issue, its increasing WGDC in the upper RPM's to meet requested load. Try increasing the WGDC Adder & WGDC Airflow in the higher cells and see if that helps.

Hmmmm.....here is the base table and what I think is the adder table.

Seems that adjustments to the base table are made up to an airflow of 400.

On the adder table, the value at 400 is 0 so maybe that is a good place to start?

Any suggestions on values to place into the adder table because they seem awful small to start with.
.
.
.

[lulz_m3]

The column headers represents MAF requested in KGH, so the higher the number, the larger the volume of air that is being requested. Lower RPMs equal lower volume or air being moved, one of the reasons our turbos have no problem hitting 18psi, but in higher RPM's a much larger volume of air is being moved AND ingested by the engine. You will want to increase the cells in the higher MAF area.

What options do you have available for logging MAF related channels with the OFT? You may also need to increase your WGDC base table in the bottom right hand corner(ish) area, as that represents MAF requested at higher RPM's.

[DCAFS]

What options do you have available for logging MAF related channels with the OFT? You may also need to increase your WGDC base table in the bottom right hand corner(ish) area, as that represents MAF requested at higher RPM's.

Lol....there are no options as far as I can see.

In fact making a small change to a single table takes me half an hour by the time I upload the change to the tablet and then upload from the tablet to the DME.

Promises made by Vishnu to shorten that writing time down to a few minutes like BB flash......but so far nada.

Of course I could always use the BB flash but so much FUD spread about not using the tablet I'm hesitant to do so.

So anyways.....seems like increasing the base table a bit in the higher MAF area is a good place to start......maybe increase the circled area by +5 and see if there is any improvement.

.
.
.

[JoshBoody]

If you are stacking, boost is controlled by Procede and has NOTHING do to with flash, except for the boost floor which is 1psi over flash target. You need to adjust procede boost target.

[JoshBoody]

For flash only:
- you do NOT need to adjust WG cap... at least not initially. The 57% translates to more like 75% final WGDC
- If you are not meeting req boost, then increase last 2 cells of WGDC Ceiling adder. depending on results, may need some other table refinement.
- Overboost is more base table issue and potentially PID, but focus on base first.
- To increase the boost per load, I am unsure but could give some one by one steps for experiment. I don't think its possible though. Would love to have someone log, while I specify individual table changes to see differences... never had the patients to do it myself.

Lulz, what are you hitting at 6k with ATR? req boost per req load?

[lulz_m3]

16.5 psi @ 6k
Load requested = 190, load actual = 180
MAF requested = 425 g/s

[JoshBoody]

16.5 psi @ 6k
Load requested = 190, load actual = 180
MAF requested = 425 g/s

oh ok, that's plenty for stock turbos. Using regular ATR? For some reason I thought the curve at 200ish req load was lower than 16psi at 6k. Did you have to raise the boost limit multipler from Cobb's 2.6?

[lulz_m3]

@JoshBoody, boost limit multiplier is 2.7. This map was created using regular ATR, but i have both the boosa and 3D fuel scalar version to play with, but haven't committed to creating a map in it yet. Requested load/load ceiling of 200 means little at higher RPM's. If you aren't getting close to load target, increasing it wont get you any closer without adding in some WGDC.

[JoshBoody]

The boosa seems nice. It basically doesn’t yield a curve based on rpm but a more consistent relationship between req load/boost. I guess some MAF factors were altered.

I was just curious what high load translated to in req boost… my top end high boost mapping is through stacking so I lack some direct experience flash only. My current summer conditions 15psi at 6k is somewhat of a struggle.

[DCAFS]

The boosa seems nice. It basically doesn’t yield a curve based on rpm but a more consistent relationship between req load/boost. I guess some MAF factors were altered.

I was just curious what high load translated to in req boost… my top end high boost mapping is through stacking so I lack some direct experience flash only. My current summer conditions 15psi at 6k is somewhat of a struggle.

Josh.....are you currently running a stacked setup?

[DCAFS]

If you are stacking, boost is controlled by Procede and has NOTHING do to with flash, except for the boost floor which is 1psi over flash target. You need to adjust procede boost target.

Yes you mentioned previously that a stacked Procede will control the WG duty cycle - I understand that part, but I had the impression that the boost targets were still defined by the flash rather than the boost tables in the Procede piggy.

The user adjustable boost targets are set to 10% in the procede = literally turned off in a stacked setup, so where are the boost setpoint targets coming from if not the flash?

[JoshBoody]

yeah, I still use the flash/procede combo. Procede controls boost in target and WGDC... adjust boost as you always have in the procede tables and boost %. The only time flash has some say in boost target is when flash is targeting more to 1psi less boost then procede. If you set the tables at lowest setting for example, the curve (procede boost setpoint) will be 1psi + flash req boost. This is only based on req boost... nothing to do with WGDC, as procede decides DC based on boost setpoint.

[DCAFS]

yeah, I still use the flash/procede combo. Procede controls boost in target and WGDC... adjust boost as you always have in the procede tables and boost %. The only time flash has some say in boost target is when flash is targeting more to 1psi less boost then procede. If you set the tables at lowest setting for example, the curve (procede boost setpoint) will be 1psi + flash req boost. This is only based on req boost... nothing to do with WGDC, as procede decides DC based on boost setpoint.

OMG....I feel so stupid!

So you are saying that all this time I have been spending on upping the flash boost setpoints can easily be solved by simply using the user adjustable boost tables in the Procede to dial in the exact boost target I want?

The flash and piggy won't interfere with each other?

[DCAFS]

So just a follow up on boost control and stacking.

As Josh indicated Procede will control the WGDC's under all stacked circumstances so no point in massaging the flash wgdc tables.

If you turn on boost control via the piggy.....the piggy will also determine the boost control setpoints (as long as procede boost targets are higher than flash boost targets).

So I am able to easily dial in an extra psi at 5.5K using the procede boost tables.

BUT....the lag on the piggy is more noticeable when it is running the entire boost show.

I get the best boost response by turning off boost control in the procede and letting the flash set the boost targets.

I tell you, It's night and day....probably because the duty cycles the procede is providing to the flash are most likely on the high side.

But I love how it feels (except for the lack of linear throttle...sigh).

So I am back to square one now.

All I want to do is add an extra psi of boost at 5.5K rpms in the flash boost target setpoint.

Load is already set to 200 in that cell AND I don't think it's a wastegate duty cycle issue because I am hitting target no problem.

The issue is the boost target itself.

It's sitting at 15.8 psi at 5.5K and I would like to raise it to 17.0 psi.

Any ideas on how to raise the boost target at that rpm only would be a godsend.

[JoshBoody]

Between the 2 procede settings lower/higher boost, I can’t see boost response being much different since you are still using the same static PID values. I can however see how the flash response could be better due to the dynamic PID tables… specifically p-factor. Take 2 logs for comparison stabbing it around 3k rpm.

For procede tuning you can try increasing p-factor to 0.5 (have to reset procede with each PID change) and make sure WG default is 100%.

For your boost target in the flash… seems like you are targeting less the Lulz. Still have some room to up the load at 6k (from the OP) which effects 5.5-6 of course. Other than this and if you are hitting target, I’m not sure as I don’t have the experience others do. Potentially there could be an IAT difference between you 2.

BTW: log DME actual boost to see what the flash is targeting.

[DCAFS]

Between the 2 procede settings lower/higher boost, I can’t see boost response being much different since you are still using the same static PID values. I can however see how the flash response could be better due to the dynamic PID tables… specifically p-factor. Take 2 logs for comparison stabbing it around 3k rpm.

For procede tuning you can try increasing p-factor to 0.5 (have to reset procede with each PID change) and make sure WG default is 100%.

For your boost target in the flash… seems like you are targeting less the Lulz. Still have some room to up the load at 6k (from the OP) which effects 5.5-6 of course. Other than this and if you are hitting target, I’m not sure as I don’t have the experience others do. Potentially there could be an IAT difference between you 2.

BTW: log DME actual boost to see what the flash is targeting.

Here are my Procede PID settings.....the Proportional factor = 0.4 so increasing it to 0.5 will get to target faster then?
.
.

.
.
And here is a datalog showing boost setpoint only.

Target boost (with the flash controlling boost - not procede) is 15.7 @ 5.5K and I would like to increase that to 17.0.....that's all!
Not asking a lot but it's driving me crazy

Good suggestion to increase the load value @ 6K rpm. I hadn't thought of that but it may help to reduce the amount of taper from 5.5K to 6K.

But I still would like to adjust the target @ 5.5K as I usually shift just below 6K anyways so as to keep duty cycle below the 70's.


.

[lulz_m3]

@DCAFS, did you try this yet?

- If you are not meeting req boost, then increase last 2 cells of WGDC Ceiling adder. depending on results, may need some other table refinement.

[DCAFS]

@DCAFS, did you try this yet?

No lulz......the problem seems to be that the boost target it too low. I have no problem hitting the current target - in fact procede stack exceeds it by 1 psi.

Also it's my understanding that duty cycle is controlled by the procede and not the flash (when stacked). So there would be little point in playing with the flash wgdc tables then no?

What did Josh mean when he said my load targets are still lower than yours?

Here are mine currently and I am already using a 200 load in the cells I need more boost in. Tried higher numbers in those cells, but it didn't seem to do anything (I think Wedge found the same issue)
.
.

[lulz_m3]

Under Limit tables, try raising Boost limit multiplier and see if that helps. I'm running 2.7 across the board on my cobb map, not sure how well that will translate to OFT.

[DCAFS]

Under Limit tables, try raising Boost limit multiplier and see if that helps. I'm running 2.7 across the board on my cobb map, not sure how well that will translate to OFT.

It's already set to 3.00 straight out of the box

.

[JoshBoody]

maybe there's some background differences in MAF calcs between Cobb and a raw ROM... it seems the boost curves have gotten flatter since Cobb was released. But we really don't have enough info to compare in this thread. we need logs at similar conditions/mapping to compare preferably with load (between Cobb and OFT)... potentially IAT and baro is the difference.

Attach your flash map/Def files for review, to see if anything stands out.

[DCAFS]

Attach your flash map/Def files for review, to see if anything stands out.

Here is my modified stage 1 OTF bin file and the original.xdf file it was married with. The bin is adjusted to stack with a piggy in order to run meth.

More load in the upper rpms and more timing advance midrange. Also leaned out the AFR's to 12.2

Fuel scaler was increased to 1.1 so that trims would not max out.

That's about it
.
OTS Stg 1 AFR12.zip
IJE0S_Stage 1.zip

[JoshBoody]

the only thing that really stands out is the load to torque limit. If this directly effects boost per load, then not really a limit but a correlation to each. So torque would be calculated in the DME and load is a reference through this table... I always just assumed the opposite. I used the Cobb table in the attached map. Only the bottom right portion of the OFT was altered and possibly the bulk of the curve taper. Log and compare DME boost actual between the 2 maps if you try it (while keeping the same load table). This is a good experiment, but maybe ATR peeps already knew this. I've played with this table before, but more pertaining to timing intervention (since I thought it was a limit) then focusing on req boost.

Disclaimer: I take no responsibility for what may happen. I'm NO expert and most times think I know more than I really do... this is dangerous for anyone that listens to me.