Timing Creep.. Advanced Discussion ONLY

Guys.. I need some help here. To give a quick update I played ALOT with a 2 bar MAP on a LT1 PCM (on my expensive block) and got it running consistent with TC's help (by adding a table for BARO RESET - to basically disable it from resetting under boost).

Now, unrealted to boost but still one last an annoying problem we all have is timing creep (timing increase vs RPM). I've done everything I can to test MAP and BARO on timing and simply put MAP (baro or MAP values) do not cause any Timing change, and it is strictly linked to RPM.. results below.. with TC's feedback below that...

I know this was brought up before.. I really want to put it to rest.. TC says they were not aware of it.

Loaded a file with 10 degrees of timing in all tables beyond 50kpa at all RPM. Set all temp offsets to 0, set all min timing to 1.

1) Ran 50kpa MAP (0 boost) from 400-6375rpm, showed the following:
400-700rpm = 10 degrees timing
800-2100rpm = 11 degrees timing
2200-3700rpm = 12 degrees timing
3700-5300rpm = 13 degrees timing
5300-6300rpm = 14 degrees timing

2) Ran 75kpa MAP (7.5psi) at same RPM's as above with same timing results:
400-700rpm = 10 degrees timing
800-2100rpm = 11 degrees timing
2200-3700rpm = 12 degrees timing
3700-5300rpm = 13 degrees timing
5300-6300rpm = 14 degrees timing

3) Ran 100kpa MAP (14psi) at same rpms as above with same timing results:
400-700rpm = 10 degrees timing
800-2100rpm = 11 degrees timing
2200-3700rpm = 12 degrees timing
3700-5300rpm = 13 degrees timing
5300-6300rpm = 14 degrees timing

4) I then ran "stock" 100kpa BARO Key On with 100kpa load... same results (so I wont post them).

5) Ran Variable RPM with variable MAP AND BARO (50 vs 100kpa initial values) with 0 change in timing. It is ALWAYS as listed above.. linked to RPM.

Sent an email to TC and got this response...

Hi Dan,

Hmm, strange. I can't think of anything that would add advance (timing) based on RPM like that but if you get a chance, send me the calibration (.bin) file you are working with so I can take a look at it.

Best regards,

TC

PCM base code adds a degree of timing approximately every 1500 rpms which looks like what you are experiencing. I don't think any tuning software allows you to change this behavior.

Isnt it basically the "same" timing since you need to start the combustion event sooner since everything is moving faster?

The most important thing is consistency... as long as no other factors contribute to the base timing adds then it's ok. This discussion was started to see if anybody noticed other factors that influence the base PCM timing adds... so far the only factor at play here is RPM and it's consistent from run to run.

One day soon here I plan to test the affect of the LT1 IAT sensor and it's contribution to the Timing values posted below, if anyone else wants/has checked this would be a good place to post results...

I plan to re-run the below test with a cold (~50F) IAT sensor and a hot (140F) sensor since the below test was run cold only.

So far:
RPM - Changes Timing
MAP - Does not change Timing

I plan to re-run the below test with a cold (~50F) IAT sensor and a hot (140F) sensor since the below test was run cold only.

How about putting a pot in place of the IAT sensor, so you can immediately change the value instead of doing separate runs?

Isn't it basically the "same" timing since you need to start the combustion event sooner since everything is moving faster? Yes, but that's the whole idea of a RPM table to start with. (there's a real gnawing feeling about not having control of every variable isn't there :))

This is a known behavior of the LT1 PCM... the mystery 4* of timing. The issue really is that it doesn't affect tuning... any tuning adjustments already take this into consideration.

I suspect you're correct about why GM entered this "creeping advance" in the programing... probably a small safeguard during tuning to prevent the dyno guys or future "tuners" (dealerships?) from nuking things by starting over with a single value in an RPM table. At low RPMS that 1500RPM window is a significant timing difference, while at high RPMs (decreasing VE/TQ curve areas) you can afford to run a bit more advance or a bit lean AF. Two different adjustments, on either end of the RPM range... I always assumed those were the main reasons beyond this small adjustment factor.

I'm told -- by an excellent tuner I've met -- that he discussed this with Ed Wright once and the code was in there... but accessing it and changing it was pointless. Just tune like you normally do. :)


YMMV.

How about putting a pot in place of the IAT sensor, so you can immediately change the value instead of doing separate runs?


Steven, that's a good idea. makes much sense for two reasons, first it's easier, second (what u said) you can change IAT's without wondering if all the variables of a seperate run impact results.

Thanks

Isnt it basically the "same" timing since you need to start the combustion event sooner since everything is moving faster?

Yea, and when the air temp in the combustion chamber is hot, the whole "ignition process" occurs much faster, if it's too hot it takes place all by itself (pre-ignition). What we need (yes, can happen, but wont in these threads) is combustion chamber temp along with one heck of a fast acting PCM!! :) Simply monitor cylinder air temp + primary tube AFR in realtime and compare to historic cylinder pressure to calculate optimal fuel and ignition to optimize power, anti-knock, and efficiency. (little pressure/knock history will have to be learned with regards to what cyl air temp + primary tube AFR causes it) Anyway...

Mystery timing is not an unknown to GM, just it hasnt been a real problem for anybody so it hasnt been worth figuring out.

It's there, hidden somewhere just dont know where yet.. really that's Tunercat's job to figure that out, thing is if we link "creep" to something like IAT or other we can help them figure it out, but again not really solving any problem since "Creep" isnt really a problem cause your changing values relative to how the engine performs.