5 replies to this topic

[Duncan]

I have my stock TPS sensor run into my AIM MXL logger. When the car is off, the sensor works perfectly. Holding the throttle all the way down gives a clear consistent 100% throttle, however when the engine is running the data seems to have significantly more noise. I've attached a small trace from my TPS channel that shows about a 3-4 % variation in signal with the throttle open 100%.

Was hoping somebody else who has experience with either this system or tapping the stock TPS sensor could comment.

thanks,

Duncan


TPS graph by duncanrellis, on Flickr

[Jim Boemler]

My system (on a 1.6) has only a switch, but I could speculate. Three to four percent isn't really a lot, if you consider how much difference in throttle position that really represents. The car has a lot of vibration when running, which could be shaking the potentiometer around. Also, the voltage for the stock TPS is probably fed direct from battery voltage, which means it fluctuates a LOT while on track. You can't regulate the voltage (that would be illegal), but you can add filtering in RaceStudio. If the fluctuation really bothers you, you could move to an external sensor. But my guess is that it just doesn't matter much.

In a driving sense, what matters is when you're getting on the throttle. It's very doubtful that you're holding your foot less than all the way down, and if you did you would see much larger dips than 4 percent. I'd say reduce the scale so you see the entire range of TPS motion, watch for the leading edges of throttle motion, and ignore the ripples entirely.

[dtfastbear]

I'll bet someone smarter than I could devise a math channel to do what Jim suggests. Perhaps a step function that makes everything over 95 equal to 100 and it'll make the data much easier to read. Of course you'll lose some resolution and insight into the *tiny* lift you make in some pucker corners. I tend to drive my SM with an almost binary throttle, so this would provide 95% (or is that 100?) of what I'd need.

Cheers,

Dean

[Jim Boemler]

The math channel would be possible and easy. I agree about the "binary" nature in most situations, and my own data is entirely binary. I don't miss having analog TPS info at all. Same with brakes, BTW, although I'll admit that a better driver *MAY* be able to get some small benefit from analog data.

[Duncan]

The math channel would be possible and easy. I agree about the "binary" nature in most situations, and my own data is entirely binary. I don't miss having analog TPS info at all. Same with brakes, BTW, although I'll admit that a better driver *MAY* be able to get some small benefit from analog data.

Great idea Jim. For anyone else that wants it, here's the formula in AIM speak.

IF(GT(TPS,95),100,TPS)

Basically, if the value of the TPS signal is > 95, display 100, otherwise display the actual value of the channel. The use of GT instead of >= (more common in computing languages) almost takes you back to the old days of Fortran (or GAMS, which still uses the outdated notation)


TPS_Math_Channel by duncanrellis, on Flickr

Duncan

[dtfastbear]

Duncan,

A small but useful tip for looking at TPS traces is to set the scale at just slightly higher than 100 when you're viewing it. Otherwise, the time at 100% (the line, that is) lays right on top of the top of the graph. I've found that it is just a little easier to view when you can clearly see the colored horizontal lines representing WFO. But maybe I have a hard time seeing it because I'm color blind?

Thanks for the formula!

Cheers,

Dean