I did my first log today and I noticed something that I cannot explain with Evoscan. At the same rpm point the software logs TWO different timing reading. Is that normal? Which timing point do we go with?

2437.5--16
2437.5--15
2593.75--14
2593.75--12
2656.25--12
2656.25--11
2812.5--11
2812.5--10
2906.25--9
2906.25--8

 

have you compared the time index between the duplicate entries?

 

Look at the MAF reading, it should be going up with the readings that you posted ... meaning that you were probably tipping into the gas and building up load/boost, which is why the RPM suddenly stop climbing as fast while load increases and timing drops.

l8r)

 

I edited the log and took the time index out before I discovered this issue. But I fail to see the difference if the time index was more or less per rpm. It still leaves the issue as to which one I should use, the time index that is lower or higher even when the rpm is the same.

 

I did not log the MAF readings, I only logged timing, KS, and TPS. But from what you are saying there should be a different MAF reading even at the same rpm point? Which brings the question which timing is the correct one, the one with the lower or higher MAF reading?

 

The RPM log is heavily quantised because of limited resolution in the logs - we're only dealing with byte value requests. The points with the same RPM readings are not the same RPM at all, internally the ECU has far more resolution you don't see on 8 bit logs.

 

http://en.wikipedia.org/wiki/Quantiz..._processing%29

 

Guys,

I am not trying to understand why this happens. I am not fortunate enough to be that technical. All I want to know is which timing data point to use when I have the same rpm and two different timing data points

I have attached and highlighted the relevant sections in the log so you can see that it happens at all rpm points.

 

In the simplest way I can put it: The RPM points are not the same even though they show the same in the log. So you'll need to consider all the timing points it appears to hit.

The ECU is using the 4 surrounding values to interpolate as well. The simple explanation of this is imagine a square room with a timing value in each corner. Kick a ball through that room in an arc or however you want and the ECU will work out the correct timing based on the values in all corners. It will be influenced more by the corner it is nearest to.

 

By plotting out your timing vs RPM and then putting a smoothing line over it will give an idea of the limits of logging byte values. It is like drawing a staircase to represent a smooth ramp.

 

Dont worry about it the timing is decreasing like its suppossed too.

 

Thanks for the help guys. It turned out to be something really simple. When you log all the parameters that Evoscan is able to log, then it slows down. Today I logged with all the parameters check marked. Yesterday, I logged with only RPM, tim, TPS and temp.

Yesterday I got 172 data points in the WOT part of the log and today I only got 68 data points. That is a 104 data points LESS in today's log than yesterday's log. I did the log at the same place and same time.

When the logging slowed down there were less errors and less redundency in the log. You would think that faster logging speed produces less errors, but it seems to be the opposite here.

 

I don't agree with your interpretation. Logging slower is losing data (unless you need the other items) and not reducing errors. Your time resolution could be said to better match the data resolution. Your two rows at for example 2812.5 RPM are not really at the same RPM. The ECU is stripping at least 3 bits off its internal representation of RPM that is used on the fuel and timing maps (1 bit = 3.9 RPM) to contain the output within 8 bits (1 bit = 31.25 RPM). Just because Evoscan reports to 0.25 RPM, it doesn't mean that this is the resolution, this is just what it shows when the value is converted to decimal. Be clear that "2812.5" RPM just means that the real RPM was between 2812.5 and 2843.74 RPM. I don't think it is rounding to the nearest, stripping the least significant bits rounds down. I'm sorry if this is too technical, but sometimes you have to be to be precise and not misleading. Faster logging is good, but the data as always needs interpretation.

 

I am not going to argue with you on the technical issues involved since I am lacking in that area. All I cared about was a simple answer as to which data timing point to use when you have the same rpm point and time stamp in your log.

 

The simple answer then, is that you use ALL data points, even when they have the same or (gasp) lower RPM values and use the logged time to offset them. So you'd end up graphing against Elapsed_Time, RPM, and Timing.

l8r)