Trying to hunt down all ignition corrections

Reply to topic
    Reply with quote

Trying to hunt down all ignition corrections

drtalon Tue May 05, 2020 12:01 am

Hi guys, hopefully this is a quick answer and I'm interpreting things correctly here.

Doing some street datalogging, and have a question about Table vs Actual ignition timing being different.

I get that Actual will always be different than Table where operational modifiers like IAT, ECT, Tip-In, etc. are enabled and are actively trimming the Table value to provide the final Actual value.

But in looking through my timing correction areas, almost all modifiers for ignition related adjust are either retarded or zeroed out when at operating temperatures, pulling timing or not modify it at all. Yet I still see a significant Advance timing contrast between Table vs Actual ignition.

The only one modifier that appears to suggest any kind of modification to timing that would provide an Advance value compared to all other areas providing a zero or Retard value is listed under the Ignition Dwell section.

In this Section, all modifier tables are housed under an overarching box called "Dwell Control". I know what dwell is, but the first table that appears is something called "RPM Based Ignition Adjustment", then you have RPM breakpoints, as well as Ignition Adjustment values below. Are these actual degrees ignition (°) adjustments as the table seems to suggest, or does this still have something to do with coil dwell?

If this is actual ignition adjustment, the values in that table appear to be able to explain the contrasts in Table vs Actual ignition timing I'm seeing in my datalogs. Other than this one area, is there maybe somewhere else where ignition could be being trimmed to such an extreme that I don't see?


Areas I've checked looking for a place where significant timing advance is being applied, but are not:

IAT Corrections - Everything here between 100-120F should be 0 to negligable advance adjustment, and beyond 120F begins to retard, except for Constant Ignition Trim and High Load Ignition Corrections that are either zero or begin to retard.
ECT Corrections - In the ECT Ignition Correction window, the modifier stops modifying timing above 168 degrees, and becomes 0
Idle Ignition Adjustments - These corrections honestly should only apply to timing cells in the Idle RPM ranges right? I have ignored this area as not being a potential high load ignition correction modifier
Tip-In Ignition Corrections - This modifier only deals with tip-in corrections, and should not really correlate with extended length high load pulls, correct? (provided my TPS is not glitching/malfunctioning, which it is not)
Cell Based Ignition Limitations - Cell based ignition limits are disabled and not being used
Sensor Adjustments - I am using this area with a Flex Fuel sensor/converter box setup, but have pulled all Ignition and PWM corrections out of this to try and narrow down where the large timing advance gap is coming from. Everything except Fuel% corrections are zeroed.

Thats it. Other than the area under the Ignition Dwell section, I can't come up with a reason for my Actual vs Table to be different by so much. Here's an example.


In a recent datalog with all modifiers listed above basically zeroed or applying a tiny bit of retard, here are some numbers from a single high load row:

RPM: 6087
MAP(mBar):2080
TPS: 99%
ECT: 178F
Table Ign: 6.25
Actual Ign: 12.75


I can't logically look at any of the modifiers listed above, except for the one labeled "RPM Based Ignition Adjustment" under Ignition Dwell, as being able to provide an almost 6.5 degree advance correction to the Table Ignition values. Here is a snippet of this correction table in my Neptune parameters:

RPM Based Ignition Adjustment

RPM: 4875, 7325
Ign Adj: 5.75, 9.25



The interpolated value in this table for my above RPM CSV example lines up almost perfectly with my "missing" 6.5 degrees of additional advance shown in my CSV. Am I looking at this ignition modifier area and interpreting it correctly in this case?




Thanks,
Talon.

drtalon

 
Posts: 18
Joined: 11 Feb 2017
    Send private message View user's profile

    Reply with quote

HRTuning Tue May 05, 2020 4:06 pm

If you're confused about the dwell output being added to actual to compensate for ECU hardware delays, focus on Table + Standard Corrections.

_________________
Like us on Facebook.
http://www.facebook.com/NepTuneEngineManagement

HRTuning

 
Posts: 10424
Joined: 05 Sep 2004
Location: Phoenix, AZ
    Send private message View user's profile Visit poster's website AIM Address

    Reply with quote

drtalon Wed May 06, 2020 2:23 am

Ok, that makes a bit more sense, compensation for hardware delays, etc.

I just didn't know if that contrast in Actual vs Table that I'm seeing with all other modifiers basically zeroed, was really coming from that dwell advance adjustment or not. Based on your response, I'm going to assume that is what I'm seeing provide the difference between Actual and Table in my example.

drtalon

 
Posts: 18
Joined: 11 Feb 2017
    Send private message View user's profile

    Reply with quote

HRTuning Wed May 06, 2020 2:19 pm

If all other corrections are zero then the difference should match the dwell at a given RPM.

_________________
Like us on Facebook.
http://www.facebook.com/NepTuneEngineManagement

HRTuning

 
Posts: 10424
Joined: 05 Sep 2004
Location: Phoenix, AZ
    Send private message View user's profile Visit poster's website AIM Address


Reply to topic

NepTune RTP Software

 

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum