TTS - 96" with 255 cams

[Steve Cole]

Creating the back pressure is what allow HD to get away with how they mount the sensors. As with all things in life you need to take a system approach to it. Since you have now done the same thing as HD did with your exhaust it looks like the system is coming around. Hope it all works out and maybe a few others can learn from what you've gone through.

[07heri]

Well I hope nobody has to go through it but I look at it as a learning experience, as frustrating as it seems at times.  I'd rather go through the hassles and know/learn enough about the bike so I don't have to rely on whether a mechanic working on it. 

Anyway, I want to start getting my head around this timing phase.  It's still mid 90's here so I'd like to get this done before it gets cold.  If changes need to be made due to temperature then now's the time for me to get it done.

1)  I have read where some people attack timing spikes by adding fuel first.  I want to keep it in closed loop, other than maybe lowering the AFR in the 30kPa to 14.0 at idle, for cooling.  During the winter months I may turn this back to closed loop.  If I increase VE's in the cells right before I see a spike won't the ECM try to compensate for the increase and, in time, bring the AFR back to 14.6?  Does the ECM read the VE table first, then read the o2 sensor and make a correction to stay in line with the AFR table?  I'm asking this because I really haven't been able to find much info on how the ECM learns, what it learns, when it learns it, or how it apllies what it learns.  Seems like a big mystery.  I couldn't even find anything on the Delphi website that explains it.

2)  Let's say I make a data run tomorrow and I see no spikes.  My plan was to jack the table 2 degrees and make another run.  What areas of the table need to be increased.  I have read numerous opinions and none seem to come to one definite conclusion of which areas to increase.  Do I increase 0 - 80 kPa at all RPM's or are there certain RPM's to attack?

3)  In reference to #2) all the cals that I COULD have started with have different timing curves so there really isn't a solid baseline to start with.  Having no baseline, and not having a clue (lack of experience) is there a good starting point for the lower RPM's?

4)  How much change should I expect to see from a Stage 1 cal to a current Stage 2 bike with these cams?  I would guess there comes a point of diminishing returns at some point.  Without a dyno I guess all we can do is go by feel?

The biggest question mark above my head right now is where to make the adjustments when I find a spike (VE tables or spark tables)?   

[mayor]

The biggest question mark above my head right now is where to make the adjustments when I find a spike (VE tables or spark tables)?

there is no preset answer...you just have to do the best job you can at interpretting the data available. 

[Steve Cole]

I myself go after timing once the vtunes are done. Once the vtune is done the mixture should be very close and it's time to work on timing. You need to remember one thing and that is that the report of knock you see is after the fact. You cannot see where it really is due to the slow data rate coming from the ECM so when looking at the recording look at the area say 10 frames in front of the knock event and up to the knock event. This will give you an idea of where it is coming from. Make you adjustments in that area then go repeat the test and see if you solved it. If you like you can fine tune by going back after its solved and adding a little back one cell at a time to really zero it in but that is really not necessary unless you want too. Once you have timing handled I also recommend you going back and running a Vtune because as you change the timing the resulting fuel mixture in the exhaust will change a small amount.

[07heri]

So make the adjustments in the spark tables...or the VE's?  If I attempt to rid myself of a spike by increasing the VE cell will the ECM try bring it back to 14.6 today, tomorrow or at some point in time?  Doesn't the ECM read the o2 sensor after it pulls what it needs from the VE tables? 

I understand that the graph will show the spike a little after it happened, and I'll have to experiment with exactly where it happened, until it stops.  What I don't understand is if it's correct to adjust the VE table at all.  Or leave the VE tables as they are and just work the timing tables.  I can see tweaking the AFR a touch in open loop but I'm running closed loop so the AFR table is out of bounds for timing issues. 

One more time with this question...where is all the reading material being hidden that really gets into how the ECM reads, learns, stores, applies, etc. the info it obtains.  I have googled and googled and don't find much more than barely skimming the surface.

[glens]

The VE tables would be the last place you want to go to remedy this.  Look first in the spark tables outside the main one.  If you can't narrow it down to any certain condition which causes the problem (if it's more general than that) then address it in the main spark table.  If you still can't rein it in, only then would you look at the VEs.

If you're using an .mt8 calibration you probably want to mess with the EGR stuff to smooth out the VE tables as best you can anyway, and that in itself may fix your problem.  When any four VE table cells are too divergent from each other the ECM will have a harder time getting you just what you need out of that area outside the center points of those cells.

[mayor]

I take a much different approach than Steve or Glen when it comes to adjusting for knock retard events.  I generally go in with no preconceived notions of what caused the trigger on a vtuned bike, since at this point there is likely no external actual AFR confirmation of the tune.  I just let the data guide me in the decisions.     Adjusting the timing first is more of a certainty, when the afr is more of a certainty.   This works for dyno guys, since they have the ability to read actual afr.

I'm not suggesting that the vtune process isn't accurate, but it can only with with-in the boundaries of the data that is collected.  If the bung location or depth is not correct, the populated VE cell during the vtune process may not be as well.  The other issue is one VE cell can be both affected by EGR tables and not affected by the EGR tables (which is what Glen referred to), depending on the load at the time.  I would also rather be on the richer side, and allow the closed loop to trim than be lean during the transition from closed to open loop. 

[Steve Cole]

As you can see people go after it in different ways. To say one way is right and the other is wrong, if we both end up at the same place, doesn't work. I like to deal with spark after I know the mixture is close to being right and that's what you should have after Vtune. But, as Mayor has pointed out nothing is perfect so you have to deal with what works best for you.

[glens]

Well, Mayor, it may be that what the ECM is happy with in terms of VE isn't really resulting in the AFR it thinks it has; I'll grant you that.  But if the ECM is content with it and you go changing the VEs without changing spark, the ECM'll put the VEs (at least effectively) right back where they were, assuming closed-loop operation in the area under consideration.

[mayor]

.....the ECM'll put the VEs (at least effectively) right back where they were, assuming closed-loop operation in the area under consideration.

it's not the closed loop areas that I'm typically worried about.  I take for granted that the closed loop will do it's job in areas of closed loop and reduce if need be.  The part that generally concerns me is when the ECM switches to open loop, the transition between could and does go lean on occasion so I would rather hedge richer than leaner in that case.  When general statements are made about reducing timing first without reveiwing all the data, I get concerned that this might lead someone to continuously reducing the timing advance due to knock retard in an attempt to cover a fuel issue. 

[07heri]

Well, Mayor, it may be that what the ECM is happy with in terms of VE isn't really resulting in the AFR it thinks it has; I'll grant you that.  But if the ECM is content with it and you go changing the VEs without changing spark, the ECM'll put the VEs (at least effectively) right back where they were, assuming closed-loop operation in the area under consideration.

This is exactly what I was getting at.  I wasn't comfortable with tweaking a VE in the closed loop portion if the ECm was going to attempt to put it right back where it was.

Anyway, I think I will go off the spark tables and see how it pans out.

We have some mid/upper 90 degree weather next week so I will make a data run in the morning when it's cool.  Leave everything as it is.  Then make another data run at the highest temperature of the afternoon.  Then compare the two.  If I got some retard at the high temps of the day I will Tweak the temp chart so I don't lose timing in the fr/rr tables at different times/temps during the  year. 

Once I don't have any high temp retards I'll bump the fr/rr tables and adjust from there.

[07heri]

Been messing around with the timing this week.  So far not too bad.  I jacked the table 2 degrees to see what would happen and I did get a few spikes.  Got most of them worked out but still in the playing around stage.

The big thing I see is spikes when I do rollons.  Today I took 2 degrees out of the area of the spike.  I think it was pulling 4.  So I took out 2 to see what would happen.  Came back and it took out 6 this time, after I pulled 2.  After looking at the numbers I think that was from heat.  The engine temp was 30 degrees higher.  But, it happens on rollons.  Normal putting around no timing pulls, just rollons.  Map goes up...timing comes out.

Could this be a result of going a little lean when I get on the throttle?   I can see the increase when the bike was hotter.  What I need to experiment with is the ping I'm getting during rollons.  Should I increase the AE table?

[Steve Cole]

You might try to increase your Accel Enrichment fuel some to give it a shot of fuel when you roll on. Only increase it in the area you need it, as it is temperature it works from so if is OK at cooler temps only do the warmer temps.

[N-gin]

Could you post your current tune for us to see?

[07heri]

You might try to increase your Accel Enrichment fuel some to give it a shot of fuel when you roll on. Only increase it in the area you need it, as it is temperature it works from so if is OK at cooler temps only do the warmer temps.

That's what I did.  I went one cell above and one cell below the trouble spot based on the engine temp from the data log.  I'll try it both in the morning when it's cooler and then again in the afternoon heat to see how it responds.

[07heri]

Steve ....off topic but....when I change the data I want to see in the graph it never stays the way I set it, even after saving it.  DataM always reverts back to whatever is to the right side of the graph and what is above in the data section.

Is there a way to change what I want in the graph without it adding what's already there.  Example:  The right side of the graph has 6 items selected.  I get rid of all but the knock retard....set up.....preferences....display....save display assignments now.  Close DataM.  Open DataM and the crap comes back.  It's as if I can't set up what I want to view without it reverting back to what's there. 

Am I doing something wrong?  Glitch?  Not designed to allow what I'm asking?  I just dont want all that crap on the graph when all I need to see if the spark retard.  I know I can get rid of it after the data run but it's a pita every time.  I just can't seem to get it hold any set up changes I make.

[07heri]

Here is the DM for this afternoon.  Some cells have as much as 50 in the timing.  Is this excessive?  If someone can read follow this data run and let me know what they see I would really appreciate it.

[attachment removed after 60 days by system]

[mayor]

can you post the calibration that was used with that data recording?

[mayor]

there was quite a few areas that timing was being pulled on that data run.....here's as far as I got tonight though:

it appears that the rapid increase in timing on the front caused this knock retard event. 

[mayor]

I think this grouping of pulled timing is timing advance related as well:

[Steve Cole]

Steve ....off topic but....when I change the data I want to see in the graph it never stays the way I set it, even after saving it.  DataM always reverts back to whatever is to the right side of the graph and what is above in the data section.

Is there a way to change what I want in the graph without it adding what's already there.  Example:  The right side of the graph has 6 items selected.  I get rid of all but the knock retard....set up.....preferences....display....save display assignments now.  Close DataM.  Open DataM and the crap comes back.  It's as if I can't set up what I want to view without it reverting back to what's there. 

Am I doing something wrong?  Glitch?  Not designed to allow what I'm asking?  I just dont want all that crap on the graph when all I need to see if the spark retard.  I know I can get rid of it after the data run but it's a pita every time.  I just can't seem to get it hold any set up changes I make.

Display setting are saved into the file at the time you recorded it, so it will appear as it did when you recorded. I will look into it and see if there is anything that we can do about allowing them to be changed after the fact.

[glens]

While you're at it...

Is there any way you could please have your programs look for a text file in the user's home directory and grab preferences from it, you know, like unix does?  It really gets to be a pain to have to go through and do everything all over again every time there's a software update.  What I'm thinking is that such a text file could remain unmolested by the installer software whereas stuff in the "registry" seems to get wiped out completely during the process.  You could leave all the registry-reading/writing stuff entirely alone, just add the text file reading/writing. [edit: Of course, with no show-stopping faults if the file is not present, and if it doesn't exist at startup, don't create one when doing any writes.  A user could opt in by creating an empty file of the appropriate name (like .ttsrc or .ttsdmrc, .ttsmtrc, etc.) prior to program startup.]  Order wouldn't be important on the writing, but it'd be nice if the text file was read after the registry, so as to have final "say".

[edit: Also, some of us also use MLV, etc., not so much to manipulate data, but for other reasons.  Could you please incorporate into the "Export" function a "dump everything" checkbox so we don't have to trudge through the process of selection when we want all that we can get? (especially after a software update!)]

Thanks.

[WVULTRA]

While you're at it...

...........  Could you please incorporate into the "Export" function a "dump everything" checkbox so we don't have to trudge through the process of selection when we want all that we can get? (especially after a software update!

Thanks.

[07heri]

Mayor how are you getting the graph to open so nice width wise?  Sure makes it easier to read.

[07heri]

there was quite a few areas that timing was being pulled on that data run.....here's as far as I got tonight though:

it appears that the rapid increase in timing on the front caused this knock retard event.

I see timing on a downward trend...yet you see a rapid increase.  Elaborate on this.

Guys, for us trying to learn it doesn't do much good to make one sentence responses.  Explaining what you mean and what you see will help a bunch more.