Timing issues? 16197427 93 TBI

[Fast355]

OKay Fast 355.

I am better understanding the spark timing scheme now and your comment about raising the tables in that area are jiving now.

If I am wrong here, please correct me.

The main spark Bias is always subtracted in the timing calculation. I was not understanding that initially. I was thinking it is only applied under certain circumstances. In fact, it is always used and the effect shifts depending on the spark table it is looking at. This way it is not required to have many spark bias' set up to handle the varying conditions.

Anyway, question now is, WHEN does the Altitude Spark Bias come into play? I put the Main Spark Bias back into the program without negative effect but I have not put the Altitude Spark bias in yet. Is there a specific table it is associated with in $OD?

I am glad I pulled the Bias' out because it quantified a problem and even gladder I didn't melt anything. Maybe not the best plan I ever had.

Thanks,
Jeremy

A bias value is used so that you can have a negative value in the table. I would have to dig up the whole hac but I am certain from memory there is a baro correction of the spark advance in the calibration. That would be where the altitude spark bias comes up. The higher in altitude you get the lower your baro kpa. Also keep in mind that reported spark advance from the datastream will be innacurate if the initial or base timing is any value other than zero. On my definition I had to alter the equation to add the 10° initial back into the calculation. Otherwise it reported the timing 10° lower than actual. Add the altitude bias back in and ignore changing any bias values. They are all used, otherwise they would not have a valie other than zero. When I added IAT compensation in, I had to add a 10° bias to allow the IAT table to retard the timing in hot weather.