effect of degrading CAS on data logs?
#1
effect of degrading CAS on data logs?
I've been doing a bit of tuning for someone, and in his EvoScan WOT logs, I've been seeing instances where the RPM jumps backwards and then forwards. An example is attached below. It becomes more prominent at higher engine loads. I'm kinda thinking its being caused by a degraded CAS sensor. Has anyone else seen this before and figured out what is causing it?
#3
Evolving Member
I have heard of AfterMarket Ignition Systems causing interfere with the Hall-Effect CAS. With DSMs we would switch to the older optical CAS when this happens, but you don't have that option. Could there a be missing the ground wire to the block or does he have a upgraded ignition?
#4
Evolving Member
iTrader: (7)
Join Date: Jul 2007
Location: montgomery, al
Posts: 299
Likes: 0
Received 0 Likes
on
0 Posts
mine does this as well, I asked about it elsewhere and got crickets. I have not replaced either sensor yet, but I noticed it starting to happen after I turned the logging speed up & attributed it to that, the car does not behave like it's losing sync anywhere.
I've got completely stock (& more or less original) ignition on mine.
I've got completely stock (& more or less original) ignition on mine.
#7
Evolved Member
iTrader: (18)
I don't know if the sample rate of evoscan is doing this, but I get the same and it is very annoying.
I remember with zietronix data log software the raw sample rate was so high per channel (over 70 smples per channel)that when the data is displayed as a scatter diagram it would get the same reverse and jumping of rpm, boost and AFR, if I displayed as such graph type. The same behaviour was seen on datalogs from the xede.
Logworks uses a moving average at 12hz per channel and this does not happen (just the skipping (out of phase?)) of 2 byte load.
I remember with zietronix data log software the raw sample rate was so high per channel (over 70 smples per channel)that when the data is displayed as a scatter diagram it would get the same reverse and jumping of rpm, boost and AFR, if I displayed as such graph type. The same behaviour was seen on datalogs from the xede.
Logworks uses a moving average at 12hz per channel and this does not happen (just the skipping (out of phase?)) of 2 byte load.
Trending Topics
#8
I don't know if the sample rate of evoscan is doing this, but I get the same and it is very annoying.
I remember with zietronix data log software the raw sample rate was so high per channel (over 70 smples per channel)that when the data is displayed as a scatter diagram it would get the same reverse and jumping of rpm, boost and AFR, if I displayed as such graph type. The same behaviour was seen on datalogs from the xede.
Logworks uses a moving average at 12hz per channel and this does not happen (just the skipping (out of phase?)) of 2 byte load.
I remember with zietronix data log software the raw sample rate was so high per channel (over 70 smples per channel)that when the data is displayed as a scatter diagram it would get the same reverse and jumping of rpm, boost and AFR, if I displayed as such graph type. The same behaviour was seen on datalogs from the xede.
Logworks uses a moving average at 12hz per channel and this does not happen (just the skipping (out of phase?)) of 2 byte load.
#11
Evolved Member
iTrader: (90)
Join Date: Jul 2005
Location: Roselle, IL
Posts: 1,917
Likes: 0
Received 0 Likes
on
0 Posts
I've seen something like this before as well. RPM jumps around 5k where it advances a few hundred RPMs and then kicks back and forth. This is seen under 100% throttle above 25psi with meth, (not a failsafe issue). IPW is shown to act goofy by getting down to around ~1.xx ms as well. Car almost feels like its fuel cutting.
#15
Evolving Member
You could edit the MUT Table to log TCAS(Time between CAS interrupts)
TCAS goes on to make RPMs, they are the inverse of each other.
I believe the CAS analog signal is completely handled by hardware, you would need a scope to view it.
TCAS goes on to make RPMs, they are the inverse of each other.
I believe the CAS analog signal is completely handled by hardware, you would need a scope to view it.