Losing Spark Somewhere

[ferocity02]

Been having an issue with my spark advance not matching the high-octane table. It's usually 1/2 degree lower, but can sometimes be 1-2 degrees lower without KR and with ASPARK at 100%. I'm not sure what else could be pulling spark. I've looked through all of the spark tables and nothing should be pulling spark. I've had this issue for awhile now with the stock OS and with COS5 I'm running now.

Could someone look through the tune and log and see where it could be pulling spark? I have logged spark pids before and didn't see anything pulling spark.

With COS5, DYNCYLAIR_DMA isn't a valid PID, so is it okay to use DYNCYLAIR instead? It looks like it's linking it automatically to the spark tables even though the column indicates DYNCYLAIR_DMA.

I'm most concerned with timing in boost. I'm trying to keep the tune safe as a turn up the boost to get the boost VE table dialed in. Once it's dialed in then I will add water/meth and raise the timing.

Thanks!

[joecar]

GM.DYNCYLAIR is ok to use.

Try logging the pids GM.EST_xxxx_DMA, those may reveal where spark timing is going.

And of course you can use scantool->tunetool linking to see the operating cell in each of the spark related tables.

Also, did you look at the Burst Knock tables...?

[Wheelz]

What about ect and iat modifiers pulling timing?

[ferocity02]

GM.DYNCYLAIR is ok to use.

Try logging the pids GM.EST_xxxx_DMA, those may reveal where spark timing is going.

And of course you can use scantool->tunetool linking to see the operating cell in each of the spark related tables.

Also, did you look at the Burst Knock tables...?

When I look through the log in the scan tool using the cursor, there will be a cell highlighted in the tune tool in gray showing the operating point. Is this what you mean by the linking? If so it's doing this automatically.

I'm in steady state so burst knock should not be happening, but I will log it along with the other spark pids.



What about ect and iat modifiers pulling timing?

According to the tables they should not be pulling any timing.

[ddnspider]

It definitely looks like a blend between the high and low octane timing tables. In your log you posted GM.ASPARK wasnt a pid that was logged. An easy way to rule it out is to copy the high octane table to the low octane table briefly to see if thats what its doing. Just be careful for knock.

[ferocity02]

In my experience ASPARK is always 100% unless knock is detected, in which case ASPARK starts dropping but usually no lower than 90%. After KR returns to zero ASPARK will go back too 100% relatively quickly. I'll try making the low octane table equal to the high octane and see what the spark becomes.

[ddnspider]

In my experience ASPARK is always 100% unless knock is detected, in which case ASPARK starts dropping but usually no lower than 90%. After KR returns to zero ASPARK will go back too 100% relatively quickly. I'll try making the low octane table equal to the high octane and see what the spark becomes.

I would disagree with your comment about ASPARK always being 100%.....and I say this because it happened to me where it was reverting to a mix of high/low octane tables and SLOWLY worked its way back up to the high octane table. It had something to do with knock that was picked up combined with flashing the PCM and having not filled up in a certain period of time. I filled up, drove around on the tank and also changed the decrement of the octane scalar and voila, back to the high octane table.

http://forum.efilive.com/showthread.php?20837-Updated-tune-now-stuck-on-low-octane-table

I would be curious to see what happens when you copy the octane table like you posted, let us know.

[ferocity02]

I tried logging the EST pids today, and none of them are supported w/ COS5 it looks like. Is this correct? I have logged them before with 12212156 but not with COS5.

I made the low octane table equal to the high octane table and logged ASPARK, it never left 100% but I never got KR either. Something is still funny with the timing. At WOT it will be at the correct 13* and then occasionally drop down to 11*. I seem to be losing a small amount of spark everywhere else. My burst knock table is stock and removes 1.9* of timing for a delta air mass above 0.02g. I'm not sure if I'm meeting this requirement or not. At WOT DYNCYLAIR is fairly steady when the timing drops to 11*.

Here is a log from today with the low and high octane tables equal.

[ddnspider]

Try logging the other knock pids, i.e. GM.KNKRET which i think logs real as well as burst knock and see if it picks up levels that GM.KR doesnt.

[ferocity02]

Try logging the other knock pids, i.e. GM.KNKRET which i think logs real as well as burst knock and see if it picks up levels that GM.KR doesnt.

It's also not supported in COS5.

[ferocity02]

I'll try disabling burst KR, I did some reading that in an FI application the turbo/sc can flow enough to set off burst KR. It seems like many people disable it without issues. If it's the issue then I might enable it but raise the delta airmass table.

[ddnspider]

I'll try disabling burst KR, I did some reading that in an FI application the turbo/sc can flow enough to set off burst KR. It seems like many people disable it without issues. If it's the issue then I might enable it but raise the delta airmass table.

Stock 98 tunes have all the burst knock tables set to zero anyways, and most people who are making decent HP have them disabled anyways for exactly the reason you stated, large airflow changes will trip burst knock.

[ferocity02]

Disabling burst knock seems to have fixed the issue.

[joecar]

Disabling burst knock seems to have fixed the issue.Good deal :cheers: a new log file;

so basically in Log_0106.efi (in post #1 above) BKR was showing up independently of KR...