Close

Page 1 of 2 12 LastLast
Results 1 to 25 of 46
  1. #1
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12


    Yes Reputation No

    Cobb/Procede Stack - Severe Tiiming Drop During Partial Throttle on WOT

    Hey guys,

    I've been battling this for the last week. During partial throttle (log shows throttle easing into WOT), I'll get 6+ degrees of a timing drop. Sometimes it goes from 12 to 6, then back to 12, other times it goes from 6 to 0 and back to 6 almost immediately. You can definitely feel it, and its annoying and likely bad for the engine.

    The log is with a Cobb/Procede stack, but it happens with Cobb only. I'm not a Cobb guru by any means, but I don't see any tables which would pull timing that much except for:

    1) Unk Base Throttle Safe
    2) Unk Throttled

    Thinking it has something to do with these tables, why is the DME kicking into what looks like failsafe tables? It happens at maybe 2-3psi and 14* of timing, nothing that the engine cant handle.

    Something is awry. Any help is much appreciated.

    Log: http://datazap.me/u/tzu/timing-issue...0-757&mark=522

    Edit: Basics:
    1) Cobb is basically a stg 0 ST Cobb map with Vanos, timing, fuel and fuel scaler controlled by the DME. DME targets ~12 PSI
    2) Procede is adjusted typically, no fuel bias, minimal timing control on Map 1 only, meth control at 16ish PSI.
    Last edited by Tzu; 05-27-2014 at 09:03 PM.

  2. #2
    Join Date
    Feb 2012
    Location
    south florida
    Posts
    1,989
    Rep Points
    2,386.1
    Mentioned
    96 Post(s)
    Rep Power
    24


    1 out of 1 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by Tzu Click here to enlarge
    Hey guys,

    I've been battling this for the last week. During partial throttle (log shows throttle easing into WOT), I'll get 6+ degrees of a timing drop. Sometimes it goes from 12 to 6, then back to 12, other times it goes from 6 to 0 and back to 6 almost immediately. You can definitely feel it, and its annoying and likely bad for the engine.

    The log is with a Cobb/Procede stack, but it happens with Cobb only. I'm not a Cobb guru by any means, but I don't see any tables which would pull timing that much except for:

    1) Unk Base Throttle Safe
    2) Unk Throttled

    Thinking it has something to do with these tables, why is the DME kicking into what looks like failsafe tables? It happens at maybe 2-3psi and 14* of timing, nothing that the engine cant handle.

    Something is awry. Any help is much appreciated.

    Log: http://datazap.me/u/tzu/timing-issue...0-757&mark=522

    Edit: Basics:
    1) Cobb is basically a stg 0 ST Cobb map with Vanos, timing, fuel and fuel scaler controlled by the DME. DME targets ~12 PSI
    2) Procede is adjusted typically, no fuel bias, minimal timing control on Map 1 only, meth control at 16ish PSI.
    look for a vac leak. sounds dumb but i had same issue and i found it
    - Proven Power Tampa built 6466 ST -
    - N54 6AT WR 711whp 637wtq-
    -N54 WR 1/4mile trap: 133.57mph- -

  3. #3
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    Just replaced all vacuum lines, vacuum at idle is good and wastegates are adjusted correctly, a little on the tight side.

  4. #4
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    Cobb base timing table:
    Attachment 38432

  5. #5
    Join Date
    Nov 2010
    Posts
    937
    Rep Points
    562.7
    Mentioned
    52 Post(s)
    Rep Power
    6


    Yes Reputation No
    I kinda battled this before and went with the theory that DME had some calc post throttle plate at <full open. This was very low boost though that the 1.5 bar MAP could see. I reduced my WG targets in the lower ranges and seemed to work. Of course any over shoot can have an effect. I didn't look at your logs though.

  6. #6
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    There is a slight overshoot on the Cobb side of maybe 1 PSI during spool, and a little bit of WG oscillations during the pull that contribute as well. I'm going to compare some timing tables, but I don't think thats the issue currently. Anyone have the stock timing table handy?

  7. #7
    Join Date
    Dec 2011
    Location
    Roanoke VA
    Posts
    1,632
    Rep Points
    2,248.3
    Mentioned
    54 Post(s)
    Rep Power
    23


    1 out of 1 members liked this post. Yes Reputation No
    Even mild overboosts can contribute to timing issues. My advice is to make boost control solid and if the timing issues is still present then go from there.
    Click here to enlarge
    MOTIV750, MOTIV P-1000 PI, MOTIV/FUEL-IT! low pressure fuel system, AEM EMS/COBB AP, Aquamist HFS-3, ETS FMIC, SPEC stage 3+ clutch/SS flywheel, BC Racing coilovers and VMR wheels wrapped in Hankook RS3s.

  8. #8
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    While stacked, I was under the impression that the piggy is reporting DME Target Boost as Actual boost as part of the manipulation process. Shouldn't the DME be seeing NO overshoot? I'll have to log CAN DME Boost Target and CAN DME Boost and check.

  9. #9
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    See attachment for my timing table between zero and bull DME Target Boost. The DME Main Timing table drops from 17* -> 12.5* -10.5* between Load cells 60 -> 75 -> 90. Is dropping timing that quickly during boost onset causing the DME to freak out and go into a failsafe? Is it worth trying a more gradual timing reduction at boost onset?
    Attached Images Attached Images  

  10. #10
    Join Date
    Nov 2010
    Posts
    937
    Rep Points
    562.7
    Mentioned
    52 Post(s)
    Rep Power
    6


    1 out of 1 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by Tzu Click here to enlarge
    While stacked, I was under the impression that the piggy is reporting DME Target Boost as Actual boost as part of the manipulation process. Shouldn't the DME be seeing NO overshoot? I'll have to log CAN DME Boost Target and CAN DME Boost and check.
    Yes, but only pre-throttle map... DME still sees manifold at low boost. And at part throttle may expect some differential.

    I noticed this at light throttle targeting steady 2-4psi for example... not really on spool at WOT. My fix was to more accurately hit my target... the base WG mapping is fairly aggressive at the lower targets erroring for response. Tight would exacerbate it.

  11. #11
    Join Date
    May 2012
    Location
    Jacksonville, FL
    Posts
    2,942
    Rep Points
    2,873.1
    Mentioned
    78 Post(s)
    Rep Power
    29


    1 out of 1 members liked this post. Yes Reputation No
    I don't think the issue is your timing target, rather the boost ramp up. DME seems to be very sensitive to overshooting requested load during spool up. I've seen countless logs flatline timing during tip-in.

    "While stacked, I was under the impression that the piggy is reporting DME Target Boost as Actual boost as part of the manipulation process."

    I know this is true for the Jb4, but i honestly know very little about how the 'Cede goes about its business. One thing you could try is modifying the "Boost Limit Multiplier" table in the lower RPM's.
    2011 E90 M3 \ Melbourne Rot Metallic

    Click here to enlarge

  12. #12
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,065
    Rep Points
    9,039.0
    Mentioned
    637 Post(s)
    Rep Power
    91


    Yes Reputation No
    To do any analysis you would need to look at what we call DME PSI in the JB4. The spoofed TMAP signal back to the DME. This is what everything within the DME is indexed off.
    Burger Motorsports
    Home of the Worlds fastest N20s, N54s, N55s, N63s, S55s, and S63s!

    It is the sole responsibility of the purchaser and installer of any BMS part to employ the correct installation techniques required to ensure the proper operation of BMS parts, and BMS disclaims any and all liability for any part failure due to improper installation or use. It is the sole responsibility of the customer to verify that the use of their vehicle and items purchased comply with federal, state and local regulations. BMS claims no legal federal, state or local certification concerning pollution controlled motor vehicles or mandated emissions requirements. BMS products labeled for use only in competition racing vehicles may only be used on competition racing vehicles operated exclusively on a closed course in conjunction with a sanctioned racing event, in accordance with all federal and state laws, and may never be operated on public roads/highways. Please see http://www.burgertuning.com/emissions_info.html for more information on legal requirements related to use of BMS parts.

  13. #13
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    Right. You guys are describing it perfectly. I'll try and grab some data tongiht and review.

  14. #14
    Join Date
    Jul 2012
    Posts
    217
    Rep Points
    305.2
    Mentioned
    7 Post(s)
    Rep Power
    4


    2 out of 2 members liked this post. Yes Reputation No
    You've got a lot more complexity going on than I'm used to due to the stacking. But I know that when I see that behavior on just a Cobb it's because the actual load is getting close to the requested/allowed load limit or is approaching it very quickly. I've had good results in regard to this behavior from raising the load request/limit but leaving the boost multiplier low enough that you stay well below the higher load limit. This means I'm only using the boost multiplier to control everything rather than letting the load limit control it.

  15. #15
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    Took a couple logs this afternoon. The first link is with Cobb backend only, and the second is the stack showing CAN DME Boost Target and CAN DME Boost Actual. Each link has two logs in it. I apologize for the huge logs, but since it's a part throttle issue, I replicated it many times while cruising.

    Cobb Only:
    http://datazap.me/u/tzu/cobb-base-st...9&mark=582-545

    Cobb/Procede Stack:
    http://datazap.me/u/tzu/procede-stac...15&mark=84-266

    At times, it looks like its a load exceedence issue, other times CAN DME Boost Actual shoots over target and there is no impact on timing.

    Kind of at a loss here. Does the WGDC Base map in ATR have an impact on the DME Boost Target transients? Ie higher WGDC and the DME predicts a faster response?
    Last edited by Tzu; 05-28-2014 at 06:41 PM.

  16. #16
    Join Date
    Nov 2010
    Posts
    937
    Rep Points
    562.7
    Mentioned
    52 Post(s)
    Rep Power
    6


    Yes Reputation No
    Logs are fun… no logs with my new ride yet.

    This is a common issue with most flashes, and 1 of my reasons for hounding the pro-tuners for part throttle logs in the past… which they never produced. I remember a little better now my experiences. Once I parted from Cobb to BT Flash, the timing interventions subsided substantially. I believe it has to do with the specific ROMs and all Cobb tunes are based on a few files. Tuning from TP, you change your original file. But if you start with a “bad” ROM then you are screwed unless you use other software to load a different one.

    Cobb was looking into the torque monitors… wonder if there’s any progress.

  17. #17
    Join Date
    Jun 2010
    Posts
    644
    Rep Points
    684.9
    Mentioned
    34 Post(s)
    Rep Power
    7


    Yes Reputation No
    Never had problems stacking procede and BT in various configs.
    LEMANS BLUE M-TECH E92->PROCEDE REV3::ETS 7" FMIC::RACELAND DPS::WAVETRAC DIFF::DEFIV DIFF LOCKDOWN::DEFIV OCC::DEFIV INTAKE::RB PCV

  18. #18
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    After reviewing the logs this morning, I'm less convinced it's a load issue. With the stack, the DME seems to give timing BACK when the Actaul Boost exceeds the Target Boost.

  19. #19
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    So it seems like most people are disinterested, but I made some good progress tonight. Will post a more comprehensive analysis over the next few days.

    Tonights question:

    If the DME is pulling timing in response to MAF overshoots, is there any way to reduce the DME reliance on timing on these circumstances? ie. can the DME do minor throttle plate trimming (or similar, please advise of other related tables) instead of timing corrections in order to correct MAF or torque overshoots?
    @dzenno@protuningfreaks

  20. #20
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,065
    Rep Points
    9,039.0
    Mentioned
    637 Post(s)
    Rep Power
    91


    Yes Reputation No
    I would try to help but reading procede logs is too much work for me. Sorry. Click here to enlarge

    Do keep in mind the DME keeps the motor over advanced and knock sensors overly sensitive during low throttle to improve gas mileage. As a test you might try setting timing in all related areas to say 3 degrees to see if you continue to get drops. That would indicate it is knock sensor based rather than torque management based.
    Burger Motorsports
    Home of the Worlds fastest N20s, N54s, N55s, N63s, S55s, and S63s!

    It is the sole responsibility of the purchaser and installer of any BMS part to employ the correct installation techniques required to ensure the proper operation of BMS parts, and BMS disclaims any and all liability for any part failure due to improper installation or use. It is the sole responsibility of the customer to verify that the use of their vehicle and items purchased comply with federal, state and local regulations. BMS claims no legal federal, state or local certification concerning pollution controlled motor vehicles or mandated emissions requirements. BMS products labeled for use only in competition racing vehicles may only be used on competition racing vehicles operated exclusively on a closed course in conjunction with a sanctioned racing event, in accordance with all federal and state laws, and may never be operated on public roads/highways. Please see http://www.burgertuning.com/emissions_info.html for more information on legal requirements related to use of BMS parts.

  21. #21
    Join Date
    Jun 2010
    Posts
    644
    Rep Points
    684.9
    Mentioned
    34 Post(s)
    Rep Power
    7


    Yes Reputation No
    @Tzu, have you examined the procede backend flashes in tunerpro to see what limits tables et al are being modified? Also post up both maps.
    LEMANS BLUE M-TECH E92->PROCEDE REV3::ETS 7" FMIC::RACELAND DPS::WAVETRAC DIFF::DEFIV DIFF LOCKDOWN::DEFIV OCC::DEFIV INTAKE::RB PCV

  22. #22
    Join Date
    Oct 2011
    Posts
    1,058
    Rep Points
    1,149.6
    Mentioned
    39 Post(s)
    Rep Power
    12



    Yes Reputation No
    Still doing a shotgun type approcah to this, since I'm just not well versed with Cobb. I have fellow users Vishnu backend flash on my comp, havnt looked at it yet. On Friday and Saturday I made about 15 maps, with minor changes to timing and WGDC/boost tables to dial in the WGs, little to no overshoot exists now. As an experiment, I took the Stage 0 Cobb OTS map (which works fine stacked), and added one table at a time to see if I could isolate the offending table. Low and behold, Stg 0 with any one modified table (even just the fuel scaler lol) would cause these tip-in timing dropouts, where Stage 0 works fine.

  23. #23
    Join Date
    Jul 2013
    Location
    London and USA
    Posts
    2,061
    Rep Points
    1,444.9
    Mentioned
    44 Post(s)
    Rep Power
    15


    Yes Reputation No
    Click here to enlarge Originally Posted by Tzu Click here to enlarge
    After reviewing the logs this morning, I'm less convinced it's a load issue. With the stack, the DME seems to give timing BACK when the Actaul Boost exceeds the Target Boost.
    Can you log with Injection timing and see if you are running high DC %.... my car was doing this exact thing because it was running out of fuel
    2005 Porsche 996 TTS RWD - Eurodyne 60-130 in 6.50s
    2015 Audi A3 2.0 TFSI - Eurodyne 0 - 100 in 10.67s
    2015 McLaren 650S (RHD) - UK - 1/3rd owner yet to drive


    Click here to enlarge



  24. #24
    Join Date
    Apr 2010
    Posts
    254
    Rep Points
    328.3
    Mentioned
    11 Post(s)
    Rep Power
    4


    Yes Reputation No
    Click here to enlarge Originally Posted by Tzu Click here to enlarge
    Still doing a shotgun type approcah to this, since I'm just not well versed with Cobb. I have fellow users Vishnu backend flash on my comp, havnt looked at it yet. On Friday and Saturday I made about 15 maps, with minor changes to timing and WGDC/boost tables to dial in the WGs, little to no overshoot exists now. As an experiment, I took the Stage 0 Cobb OTS map (which works fine stacked), and added one table at a time to see if I could isolate the offending table. Low and behold, Stg 0 with any one modified table (even just the fuel scaler lol) would cause these tip-in timing dropouts, where Stage 0 works fine.
    That's why I changed my original ROM file with just the basic tables needed.......Timing/AFR/Load.

    When I was messing around with the other Load based tables there seemed to be side effects such as the timing drop on throttle tip in that you were experiencing.....as well as a little bit of AT tranny slippage post shift.

    Seems that you really have to know all the interdependencies among all the torque management tables, otherwise if you change only one of them it seems to have a ripple effect on the other interdependent tables and seems to muck up the end result of the equations.

    Right as of now, the only torque table I have modifed in my backend ROM file is the Torque Max Index Array table = set to 110 across all cells. It doesn't seem to have had any negative side effects thus far.

    But as others mentioned previously......boost overshoots seemed to trigger a timing drop for me as well (when logging DME requested to DME actual boost). So I reduced my Boost Control Gain setting in the user adjustables and it seemed to give a smoother boost ramp up without overshooting.

    I have upped the stock load values from 120-130 up to 140 for the flash backend while setting up the Procede to boost around 18 psi.

    Seems to be working well at this point, but I usually start throttle tip in at 3K hitting WOT around 4.5K.......so I might be skirting around the area where timing drops due to too much torque.

    Click here to enlarge
    Last edited by DCAFS; 06-02-2014 at 01:55 PM.

  25. #25
    Join Date
    Apr 2010
    Posts
    254
    Rep Points
    328.3
    Mentioned
    11 Post(s)
    Rep Power
    4


    Yes Reputation No
    Tzu.....also another thing.

    My understanding is that as long as the procede boost target is at least 1 psi greater than the DME boost target, then Procede will dictate the target and use it's own wastegate duty cycle table.

    So if you are stacking, it seems pointless to try and tune the wastegates via flash tables as they will be bypassed. Click here to enlarge

Page 1 of 2 12 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may post replies
  • You may not post attachments
  • You may not edit your posts
  •