I had a really good result with the CCP duty cycle and its influence on throttle response (from my thread a few weeks ago).

But coming off idle, I'd like the duty cycle to come in faster. There seems to be a ramp rate to get up to 100%, even though I have the CCP duty cycle vs airflow table set to 100% for all values.

There's also a table for time between DC updates, and even the factory AUJP is set to the minimum of 100 msec, which I kept.

Nothing I've tried seems to get it to come in faster off idle. It takes about 10 seconds or so to ramp up to 100%. But given the improvement in throttle feel once it gets to 100%, I'd like to see if I can get it to 100% faster...

Or is this ramp rate somehow hard coded and I can't alter it?

Once rhe DC gets to 100% then it simply goes from 0 to 100 instantaneously as l let my foot off the gas and then press the gas... Just trying to see how can get it to do that just off idle too.

 

Check the anht disassembly file. Press control F, CCP, enter. Read the description of what it does. Scroll up to the section header description to see what section of the code Youre in. Start in any area you think may be where your issue is.

if you find a potential parameter that isnt defined, define it. I think in one of these threads I did a walkthrough for how to do it. Ask for help doing so if needed.
And if you see a potential fix thats code let me know. I’ll tell you how to fix it.

 

I think I found the existing parameter in SAUJP_v7 that does it...

CCP, If INT > 125, Increase DC% by This Amount 0x2E4

If I make this 100%, I get the effect of the CCP going to 100% duty cycle as soon as leave idle.

However, ironically it doesn't have the throttle response effect I was looking for, so I'm going to leave it stock.

Appreciate the reply.

 

Anht will tell you how it works if you search for that address.

 

I can find two instances of the 2E4 location that relate to this scalar, but frankly it's like reading hieroglyphics.... lol...

 

It ramps in increments following a routine using the integrator;

Set $82E1 to 00
Set $82E4 to FF

This will remove the 0.1 delay between updates and force the first update to reach max allowed duty...

AUJP uses the same CCP logic.

- Rob

 

I played with that one earlier on and didn't really get much of a change.

I can try it again out of curiosity at some point just to make sure.

 

These values are ignored for a few reasons.
82EE = Disable if <= .9 MPH.
82EF = Disable if <= 0 KPA.
82F0 = Disable if <= 2.3% TPS.
Disable if IGN off
Disable if in DFCO
Disable if Acceleration enrichment

 

Is acceleration enrichment delaying your DC updates?

Edit: I see you got it to 100% quickly so there's no need for me to look further.

 

Those three addresses are just the min enable thresholds for CCP vs MPH, MAP, and TPS. CCP is held off below those values, and also any time the key is off, or when DFCO is active, or when AE is active. They’re not being ignored, they’re literally the gates. The “2.3% TPS” example is just what this bin happens to be set to. Change the calibration and that number, as well as the behavior... moves with it.

- Rob

 

That is what I said.

There’s also enable thresholds for hysteresis. There’s also BLM thresholds. Theres an open loop switch. There’s a decrease step amount. Theres all sorts of things in the code.

 

Right... all of those other items are part of the overall CCP routine, but they don’t change the fact that those three addresses are the enable gates. Everything else happens after those conditions are satisfied...

- Rob

 

No.

But for arguments sake sure.

 

To answer this question... no, I've never encountered the DC being reduced at all during AE.

I know the data rate is pretty slow on this ECM (why I can't count on the "In AE" flags in the TP data as I believe the AE events are faster than the data rate from what I've read and heard).

But I've never even seen the DC flinch during a throttle transition

 

Leave it to GM to make things probably a lot more complicated than it needs to be.

 

No, AE doesnt change DC, it halts positive (I think it can allow lowering but don’t remember) changes to CCP DC. So while getting in and out of AE it will slow the opening.

Unlike AEs minor check bypass, DFCO bypasses the entire ccp routine. Including the checks mentioned prior.

 

You’re right about the data rate, the AE events happen much faster than the ALDL stream, so the “in AE” flag is almost impossible to catch in real time. AE can come and go between frames, so relying on the data-stream to essentially see AE is basically a losing battle. As for the CCP DC not flinching during throttle transitions, that actually lines up with how the AUJP logic behaves. AE doesn’t directly change the purge duty cycle; it just blocks upward stepping while AE is active. Downward stepping is still allowed, but unless the integrator is trying to pull DC down at that exact moment, you won’t see movement. If you’ve got the usual thresholds met and the ramp‑rate values at 82E1/82E4 are still stock, the stepping is slow enough that a quick throttle snap won’t show anything noticeable in the datastream. The ECM simply doesn’t have time to increment DC before AE ends again. Once you zero out the delay and max out the step rate like I mentioned above, the DC will jump immediately off‑idle, and AE becomes almost irrelevant because the ramp happens in a single loop instead of over multiple frames...

- Rob

 

Thanks Vanilla and Street Lethal!

Glad we still have some of the old gurus still participating and contributing on this board!!!