TTS...Dummy list for timing?

[07heri]

Is there a dummy list for timing out there anywhere.  The guides are weak in this area.  Tons of info on fuel but very little on timing.

In the Datamaster console under the data type heading which type should be selected...Generic Data or Spark Data?

When I set up the chart all I need to see is lines for Knock Retard Front and Knock Retard Rear?  Map and RPM is showing on the upper portion so I don't need it on the graph...my thought.

Does the knock retard kick in at a certain temperature?

If after a data run I still get straight graph lines should I bump the entire chart up a degree at a time until it start seeing some spikes and then tune out those spikes?  Then back it off 3 across the entire table?

I wish there was more info on timing in the guides.  I used Spark Data as the type from the pull down, set the graph up to only show front and rear knock retard and the line is dead straight, no peaks like shown in the guide.  Based on my reading I should be running the most timing I can without pinging and then back it off 3 degrees as a safety net.  But if I don't see anything but a straight line how do I know how far away I am from optimum timing?

07heri 

[rbabos]

Hmmm. Could this be a topic where both closed and open loopers can get along?
I agree, there should be a nuts and bolts session on this since it's at the end of the basic tuning and really needs to be done. Optimum timing could be a problem since it's not always max timing. I'd like to know how a DIYer can deal with this aspect since without a dyno there's no data to validate the correct timing.
Ron

[05Train]

Timely thread.  My new mufflers will be here tomorrow, and I noticed a little bit of ping today with the stockers on.  I'll be VTuning tomorrow night or Saturday, but I'd really like to address timing before I leave on my road trip next week.

[7remmag]

This will be a good thread, I hope with a lot of input. I've been trying to follow along with mayor while he is helping with my tune.  I get the AFR tables and I would have probably quit there without his help and can honestly say that I would have been missing a bunch of power without his patience of doing the timing for me. 
7

[mayor]

Discusing the adjustment of timing is much different than discussing adjusting afr.  AFR has fixed values, and most engines will deliver with-in 95% or more of it's power potential over a very broad range (say around 12.8-13.8 afr). Generally with afr the goal is to be just rich enough in a lean condition at cruise not to cause spark knock and excess heat, but not too rich to cause build ups of carbon in the combustion chambers.  Too little fuel builds heat in the engine, too much fuel will cool the engine but ruins efficiency and creates carbon build ups.  With timing, too little will build heat...and too much will build heat. That's problem number one, what do you use to base whether you have the "correct" amount of timing since either too much or too little will build heat.   If any of you think that there are hard numbers to follow in regards to timing, you might as well stop reading now. 

Timing is similar to afr in that for a given engine there is a window of opportunity. The problem is that window can be a different sizes for each bike, since engine builds will affect how much room for error you have in optimal timing.  One variable that comes to play is the more efficient the combustion process, the smaller that window is and the less advance the engine needs.  Items like squish and corrected compression will affect the timing window, as will pipes and cam profiles...along with gearing, etc... This is problem number two, generally the more power potential of an engine the less margin of error you have on your engine timing.   

In days of old, the standard practice when adjusting wide open throttle was to advance the timing to the point where you heard an audible ping then retard the timing 2-3 degrees.  The problem comes in is you have lots of noises happening when doing a wide open throttle blast, and hearing a split second worth of ping is one thing...but figuring out exactly where to adjust on the rpm chart is another.  With the Delphi system, we now have adaptive knock retard which will alert the tuner that the timing is at the verge of creating a knock condition.  This is a great tool, but advancing the timing to the maximum amount before knock conditions does not necessarily translate into making the most power.  This is problem number three, how do you know when the timing adjustments are creating the most power or when the timing is in the range to create the most efficient power?

Most DYI guys use seat of pants (SOP) and feel to determine whether or not timing changes were affective.  This relies on the senses to relay accurate unbiased information to the brain.  This is problem number four, counting on your senses not to provide unbiased data.  The brain can be easily tricked, items like more noise- (loud muffler) will sometimes convince the brain that there's more power, quiet muffler systems like what's available from Supertrapp will often convince the brain that you lost power.  On a related topic, the brain can be tricked by the wallet as well....the more money you spend, the faster you think the bike is...   This is where unbiased external measuring equipment (dyno's in laymen terms) are worth their weight in gold....well, maybe not gold at todays gold prices...but worth while none the less. 

OK, I outline some of the problem that DYI fellows face when adjusting timing.  The simple truth is timing is as much art as it is science, and I think one of the biggest advantages that the professional tuners have over us DYI'ers is experience.  The more timing charts you see, the more you start to see trends and can pick out when the expected trends aren't there.  The more timing adjustments you make, the more you can predict what those changes will do.   

I'm far from an expert, but generally I adjust timing based on feel.  I try to find the engines comfort level, looking for the lower timing limit and the upper timing limit at cruise..using engine smoothness as a gauge. I prefer to be near the upper end of the smooth operating range. One word of caution though, the smoothest engine does not necessarily mean the most efficient, but it does usually mean that I'm more comfortable. teeth: Generally when you get too much timing at cruise conditions, the engine starts to vibrate more and is most noticeable through the floorboard/foot pegs (this is the mothod I use with the T-max since it does not have adaptive knock retard).  I noticed I can make the floorboards vibrate 2-4 degrees before I can get an audible ping. Generally when you get to little timing the engine will buck a little, and will not have smooth throttle response.  Since the Delphi system has MAP controlling the timing, I also use gear selection to control the load on the engine during my evaluation.  I systematically ride at my cruising rpm's in various gears, and I pay attention to smoothness.  I then make adjustments based on the data I "felt".   

I adjust wide open throttle timing slightly different.  I use wide open blast starting at 2,400 (generally full WOT occurs around 2,600) in 5th gear to check max speed on a fixed section of road. I do this in conjunction with viewing data recordings for spark knock. I also have a section of road near me that has enough of an incline that I can test my timing at longer intervals at peak tq (meaning, 5th gear around 4,000 rpm).  As you can imagine, there is rather high rates of speed involved with my methods...so a closed course is necessary.   

My efi bikes are low compression and low HP, so my margin of error is large enough that a hack like myself can generally produce nice results by getting the timing somewhere in the ball park.  Higher compression builds, higher HP potential builds, and higher cubic inch engines are not as simple.  I think one area that I see where folks get carried away with higher compression builds is in the total advance at wide open throttle. If you are advancing the timing until you hear audible ping, you went too far.    As a rule of thumb, if you're squeezing the combustion chamber tight...you don't need to advance the timing as much. 

[whittlebeast]

A totally stock BT motor has a timing map that is almost always based on RPM and MAP only.  This is very different from what my stock Sporty looked like.

see http://www.ncs-stl.com/SertTune/StockBaggerTimingMap.jpg

Very strange.  The more you learn, the less you will be sure that you really understand. 

[07heri]

Thanks Mayor.  Your posts and responses are always enlightening.  Now if you or someone could post a step by step process of how to set up Datamaster, similar to the flowchart for doing VTune runs it would help me alot.  "Screenshots For Dummies" would be great.  My first post has a few questions that I could not find an answer to in the TTS guide.

Firstly, if nothing else, for me anyway, I'd like to be able to make the data run, educate myself on interpreting the data, and know that there's not something going on that my ears aren't hearing.  I guess for a little peace of mind in this 95 degree weather. 

And secondly, if I can squeek a little more out the engine that would be a bonus too.

[mayor]

here's some more issues I forgot to mention: 

The quality of gas will greatly affect the timing requirements of an engine.  Case in point- take two identical bikes, one in the "Big Sky" area...the other in "Gold Rush" country. The fuel blends in these two areas are different.  The bike in Big Sky was much more willing to take additional timing advance, than the Gold Rush bike.  This is problem number five, how do you know whether what the engine doesn't like is the timing or the gas? 

The ambient temperature will factor into how much timing an engine will take as well.  The warmer the ambient, the warmer the engine is operating (generally).  This could lead into unnecessarily removing timing on your main timing chart to account for knock retard or audible ping, which could mean that you are not running the most efficient when the ambient is cooler.  This is problem number six, how do you know when to pull timing from the main timing charts as opposed to adjusting the Spark Temperature Correction?

There's two basic variables in tuning an engine, air/fuel ratio and timing. If you get either out of the engines comfort zone knock retard or audible ping can occur.  Do not take for granted that the AFR is a constaint when reviewing data recordings.  TTS only operates in closed loop for a portion of your riding ranges, which means there are other areas that are VE chart controlled.  As with any computer software, garbage in means garbage out.  If you don't do a good job of allowing the software to tune as much of the VE tables as possible while Vtuning, you could mistakenly pull timing to correct for knock retard to account for afr issues.   The worst part is sometimes when you have done a good job at vtuning, the VE's still might not be right.    For more information on this, read this thread: http://harleytechtalk.com/htt/index.php/topic,38047.100.html (read reply #119 and down, this is covered extensively)
This is problem number seven, how do you know when the timing is too far advanced based on the actual timing rate or actual afr?

if you add up all the variables I've outlined already, you'll start to get an idea of why there are no specifics to adjusting timing.  Often you need to use SWAG (scientific wild ass guess) to make tuning decisions, then you test your guess, then you evaluate the results, then you repeat as necessary.  The benefit that the pro tuners have is they can take problem number 7 out of the equation with the AFR measuring equipment that they have available.  Use DYI guys do not always have such luxuries (although, some us do have AFR meters  ). 

The trick is pay attention to the data that you do have, and make an informed decisions based on that data.  The problem with that is, there is way too many variables to make those decisions easier. That means there is no "for dummies" short cuts, since you have to understand as much as you can on how the system works before you can evaluate the changes needed.  I think the thing that gets lost when folks evaluate the cost of a professional tune is part of the money you are spending is to cover the applied knowledge that you are buying (applied to your tune, not necessarily your person).  The way I see it you are paying for three things- labor, equipment, and knowledge.  Of the three, the labor is probably the cheapest...and usually that's what folks focus on.    

[rbabos]

It's been mentioned several times that viewing a knock event in datamaster the detonation has begun slightly before where the graph is indicating. Is there a general guideline on where to pull timing prior to this viewed hit?
Ron

[Hilly13]

More on Ron's question as I have noticed a lot of retard events follow a thottle chop off followed by whacking it back on, how do you deal with that?

[mayor]

It's been mentioned several times that viewing a knock event in datamaster the detonation has begun slightly before where the graph is indicating.

I've read Steve mention this several times.  After reviewing hours of recorded data, I do not totally agree that it is this simple.  He's right that the problem may have occurred earlier, but the tricky thing is sometimes the reason is almost as spontaneous as the knock retard point and sometimes the reason can be found afterwards.  In a nut shell, the cause for knock retard can be related to events recorded prior, events recorded at the time, or events recorded afterward.

here's an example of an event that was causing knock retard that was recorded after the event:
Here's an example of pulling timing as soon as leaving closed loop:




Recording 658 is still in closed loop, but 659 is now open.  The rpm's went up as did the throttle position, but the VE's went down.  This could be a knock retard trigger caused by a lean condition.  Also, I don't think that you can be totally sure that the 14.6 desired afr reading is an absolute indication of closed loop operation.  I don't know how the software works enough to say for sure, but that particular reading could have been averaged at 14.6 (meaning 14.55...indicating open loop).   

When viewing areas that timing is being pulled, you want to look backwards and forwards to spot trends. Look for things like- did the afr just go from closed loop to open, did the timing just take a drastic advance, does the VE's look like they are trending correctly, was there adequate information provided to the Vtune software for the the open loop area that timing was pulled from, etc.

The very first step in making sure you make good decisions on adjusting timing is to make sure that you did the best job you could when you adjusted the AFR portion of your tune (this does not mean AFR tables, but rather Vtune population of VE cells).  The biggest mistake that people make is the try to account for lean AFR timing pulls by retarding timing.  This makes the bike inefficient, lazy, hot and just plain irritable.  Here's an example of why some AFR areas might be issues with Vtuned bikes (this example is lambda based):


1. notice the blue circled area.  There is a lack of data here, anything developed from this will be suspect.  It might be perfect, but it might not.  The reason this area lack hits is the operator was riding like he normally would and just buzzed right through this area on his way to normal riding rpm's.

2. notice the red circled areas.  This area was not filled in because the operator did not use all the gears available to populate the chart.  Remember, the higher the gear the more the load applied on the engine (the higher the MAP). Another trick is to use controlled acceleration (meaning no rapid twists) to increase the MAP in the higher rpm's if you are not comfortable riding at Autobahn speeds.   

3. Notice the yellow circled area.  This is an area that is absolutely important that you collect data the whole way through out, since this is where you will be spending the majority of your time riding.   

If this data is an example of how the bike's VE tables were tune, any pulled timing would be suspect (review problem number seven).  Keep in mind, anytime that you are no longer in closed loop the ecm is using the data that is written in the VE tables.  If you did not tune that data to the actual bike, that data can be wrong no matter how close your build matches the calibration. 

[Blackcherry Low]

It's been mentioned several times that viewing a knock event in datamaster the detonation has begun slightly before where the graph is indicating. Is there a general guideline on where to pull timing prior to this viewed hit?
Ron

Yeah, it blows for us Sportster guys that they (MOCO) didn't employ this feature on the XLs.

[Steve Cole]

One thing that many of you have missed and I have tried to get you to understand is the system data rate. If the engine is accelerating and the system will only send out data 4 times per second what happens in between those 4 times that you do get data?

The second thing one needs to remember is that the system can only report what it has seen already occur. It cannot and does not report what happens in the future.

So now how do these two things effect what you see?

[rbabos]

One thing that many of you have missed and I have tried to get you to understand is the system data rate. If the engine is accelerating and the system will only send out data 4 times per second what happens in between those 4 times that you do get data?

The second thing one needs to remember is that the system can only report what it has seen already occur. It cannot and does not report what happens in the future.

So now how do these two things effect what you see?

I understand the event happened just prior to the shown data, but at 4 times per second rate it would seem to be a best guess, since depending on how fast the throttle was applied would change the actual and indicated spread. In this case areas of steady ping and throttle should show up as actual and indicated as being the same location? Most of us DIYer's will likely only see roll on ping rather than steady state.
One can view the rpm and kpa in the log for reference but is there a ballpark rule that works most of the time to determine where the knock happened prior to what the graph shows?
Ron

[mayor]

One thing that many of you have missed and I have tried to get you to understand is the system data rate. If the engine is accelerating and the system will only send out data 4 times per second what happens in between those 4 times that you do get data?

if an event happens with in a 1/4 second interval and doesn't show up on a recording, I am perfectly willing to over look that.     I believe that when one is OCD like me, you can get paralysis from analysis by viewing too much data.  I see no reason to increase the collection rate, afterall....we're not talking rocket science here.      

The second thing one needs to remember is that the system can only report what it has seen already occur. It cannot and does not report what happens in the future.

with all due respect, we are talking recordings...everything we view is from the past.     If you are referring to what I posted, I still stand by that.  The trigger for a knock retard my not be evident on the current screen or previous screen, but could actually become apparent on the next later screen.  This does not mean that the knock retard sensed an event was going to happen and acted preemptively, only that the actual trigger wasn't recorded until after the event occurred. 

[Steve Cole]

One thing that many of you have missed and I have tried to get you to understand is the system data rate. If the engine is accelerating and the system will only send out data 4 times per second what happens in between those 4 times that you do get data?

if an event happens with in a 1/4 second interval and doesn't show up on a recording, I am perfectly willing to over look that.     I believe that when one is OCD like me, you can get paralysis from analysis by viewing too much data.  I see no reason to increase the collection rate, afterall....we're not talking rocket science here.      

The second thing one needs to remember is that the system can only report what it has seen already occur. It cannot and does not report what happens in the future.

with all due respect, we are talking recordings...everything we view is from the past.     If you are referring to what I posted, I still stand by that.  The trigger for a knock retard my not be evident on the current screen or previous screen, but could actually become apparent on the next later screen.  This does not mean that the knock retard sensed an event was going to happen and acted preemptively, only that the actual trigger wasn't recorded until after the event occurred.

We have a winner! When data is coming as slow as it is in this type of a system it is possible for the data you see NOT to all go together. We only report what the ECM is sending us and it has plenty of other things that must get done so data is low on the list. So it is possible the ECM was getting data ready to send but got an interrupt to do something else and then came back and complete the data gathering then sent it out. It is also possible to miss data, so you must review the data and understand the possibility of missing or incorrect data. With a higher data rate these issues do not happen as often.

[Hilly13]

Steve, given that data rate and the low priority level of the stream on the ecm's list of priorities would there be any advantage of just gathering one type of data per run so it is less for the ecm to report and therefore more likely not to be delayed.....maybe?

Hilly

[FLTRI]

A totally stock BT motor has a timing map that is almost always based on RPM and MAP only.  This is very different from what my stock Sporty looked like.

IIRC, Sporty's are based on RPM and MAP as well?
What are you refering to as far as being very different?
Bob

[Steve Cole]

Steve, given that data rate and the low priority level of the stream on the ecm's list of priorities would there be any advantage of just gathering one type of data per run so it is less for the ecm to report and therefore more likely not to be delayed.....maybe?

Hilly

That is just why we have various data types. We only gather the necessary data for that function. If you record Spark data you will be missing lots of other things but it keeps the data rate up as high as we could and gives us what we need just for evaluating Spark stuff. If you gather Dyno data we can get the data rate up to 10 frames per second on most PC's. While not high speed it's double the speed of other data types. Typical data rates in the automotive industry are 40 frames per second for engine functions and 400 frames per second for braking and suspension systems.

[exrn]

Selecting Spark Data misses valuable information such as VE and Lambda, which would seem to assist pinning down the cause of a retard. If one selected Generic (which does give good information), then removed unwanted data such as Battery Volts, Desired Idle etc. before starting the scan, would this work?. Or are these data points collected anyway, and it is only during the playback that they can be filtered out?. If so it would be nice to be able to selectively state what data points would be collected during a Datascan.

[Sporty 48]

As it goes, Sportsters are programed differently.
I have a different pulse than my buddy with a BT.
Do not know another way of describing the difference.

A totally stock BT motor has a timing map that is almost always based on RPM and MAP only.  This is very different from what my stock Sporty looked like.

IIRC, Sporty's are based on RPM and MAP as well?
What are you refering to as far as being very different?
Bob

[FLTRI]

As it goes, Sportsters are programed differently.
I have a different pulse than my buddy with a BT.
Do not know another way of describing the difference.

Well I think most of the pulse is taken up with the compensating sprocket on the BT.
Folks with BT's can simply remove their compensator and they too can have the Sportster pulse.
Bob

[lonewolf]

Selecting Spark Data misses valuable information such as VE and Lambda,

But it gives you map,rpm and tps.

[07heri]

Selecting Spark Data misses valuable information such as VE and Lambda, which would seem to assist pinning down the cause of a retard. If one selected Generic (which does give good information), then removed unwanted data such as Battery Volts, Desired Idle etc. before starting the scan, would this work?. Or are these data points collected anyway, and it is only during the playback that they can be filtered out?. If so it would be nice to be able to selectively state what data points would be collected during a Datascan.

This is EXACTLY why I asked the question!  Initially, what I was after was the basics of setting up the software BEFORE making the data run, and then a what to look for while replaying the data.  But the thread turned into a pretty indepth discussion of different timing situations and theories. 

I'm all about learning the software and getting a better understanding of what's happening with the bike...but us newbies need to start at the beginning of the learning curve and work up.

But anyway, is there punch list out there, similar to the VTune punch list, to at least get some data recorded.  I have the cal...now I want to make a few runs and see if there's any pinging or obvious timing issues that my old ears aren't hearing.  I'm not saying I need to make any changes or will.  All I would like to know, or see, is if I have any places where timing is being being taken out.  If I see areas where it's happening I'd post it here for assistance, and also for other beginners to pick up some knowledge.

[Steve Cole]

Select Spark Data under the Data Type and go make a recording, it's just that simple. The reason for us creating Spark Data was to get the recording speed up as much as possible when trying to evaluate spark data. Getting the data as accurate as possible within the limits of the system to help identify where the knock is really occurring. If your looking for Fuel information do not use Spark Data, as it was desing for this task only.