A few more thoughts on this stuff, then I'll give you peace for a while again.
Despite the way that I might come across, I think it is important not to pretend this is some sort of rock solid science. MS bases its core fueling decisions on the ideal gas law, but I don't think there is anything so solid for accel enrichment. As I said earlier, what you want is to use the throttle change as advance warning of an upcoming change in the airflow. But exactly how big a change and how much advance warning it gives will vary according to the engine design, engine speed and load, and a squillion other things. And that's why it comes down to tweaking magic numbers, whether you use old-style AE or EAE.
Just as an aside, one thing that I wondered about on my morning walk today was: are all percentages of TPS equivalent? By geometry, roughly the first 60° (i.e. 2/3 of a right angle) of butterfly spindle rotation is required to open up half the cross sectional area of the throttle body. The next 30° doubles the amount of air that can get in. I haven't taken the time to check how my TPS voltage varies with rotation, but if it is just proportional to rotation it means that the first 5% TPS increment isn't the same as the last 5%.
Well, let's set that rambling aside. What I want to post is a few simulated accel events with "perfect" and "noisy" TPS sensors and compare the current approach with my patched approach.
Firstly, here is the noise-free version.
quiet.jpg
On the left is the fast-polling standard algorithm, on the right is the 1/4 sampled "patched" version. Each event is 0.1 seconds long, they look similar, but the first is only opening the throttle a little, the last going all the way from closed to wide open. Bear in mind, what is important is the slope of each line segment. At each each "o" in the graph, the slope of the line before it is going to be applied after it. It's quite clear that the patched version is inferior. It underestimates the slope at the start of the event and then overestimates at the end. Mind you, if you look closely at the third row you can see the alternating under and over estimating of the slope in the blue graph.
All in all though, for noise-free TPS, the existing code is better.
Now let's try it with a random normal wiggle added (std deviation 0.5%) which makes the graph look reasonably like my own TPS.
noisy.jpg
This time the winner is not so clear cut. For slow events, the patched version is much better. It still has the slow ramp in and out, but the slope in the middle of the event is much closer to the money. It's a bit of a toss-up which is better in the middle row and the traditional algorithm gets the nod in the third case.
Here is the R code for this (R is a freely available statistical analysis language).
- Code: Select all
par(mfrow=c(3,2))
showit<-function(x, y, c='black') {
plot(x, floor(y)/10, type='b', col=c, ylab='TP', xlab='t (0.01s)', xlim=c(0,31));
}
pairplot<-function(x, y, r) {
showit(x, y, 'blue')
showit(x[r], y[r], 'red');
}
set.seed(1);
w<-5 # amplitude of "noise"
x<-0:30
qr<-(0:7)*4
b<-15
# Slow opening rate -- 100% in 1.0 seconds
y<-(c(rep(b,10),b+(0:10)*(10/11), rep(b+10,10)))*10 + w*rnorm(31)
pairplot(x, y, qr)
# Typical opening rate -- 100% in 0.5 seconds
y<-c(rep(b,10),b+(0:10)*(20/11), rep(b+20,10))*10 + w*rnorm(31)
pairplot(x, y, qr)
# Fast opening rate -- 100% in 0.1 seconds
y<-c(rep(0,10),(0:10)*(100/11)+rnorm(11), rep(100,10))*10 + w*rnorm(31)
pairplot(x, y, qr)
If you get rid of the set.seed(1), you'll get different plots from the above. Dropping the noise value from w<-5 to w<-0 changes the standard deviation of the Gaussian noise, getting you the noise-free versions.
I seeded it with 1 just to show that I didn't go out of my way to generate convincing graphs. You soon see much worse cases if you generate a few at random. The red column generally looks the same where the blue column can be quite a deal noisier than shown here.
CONCLUSION
It's a toss up. If your TPS is noisy, the patched version is probably better. If not, stick with the original. For now, I'll continue with the patched version -- bear in mind that I drive like a granny.
I agree that getting rid of the noise is a good thing. But an algorithm that is looking for significant movements shouldn't be as sensitive to relatively small amounts of noise as the current one.
The code currently waits a particular amount of time and checks the throttle position. It then comes up with a tpsDOT value. How would it be if this was turned on its head: the code could wait until a particular (configurable) amount of throttle position change has occurred, then determine tpsDOT from the amount of time that has passed? Seems to me this would be a lot more tolerant of noise, while still allowing for a rapid response to changes.
Have fun,
Rob.