"Noisy" tpsDOT
Posted: Thu Sep 15, 2011 6:10 pm
Been a while since I posted anything code/design related, the last being the epic on "noisy" RPM values. Like in that thread, I am running the risk of being told that I'm looking at this stuff too closely and, once again, I'm going to be saying that it's not me but the MS code that's looking too closely.
I'm sure I'm not the only one here to look at the TP values at idle, fluctuating around between 0 and 1. Like this:
and compare it with the corresponding tpsDOT values which seem very volatile for such small movements. Like this:
The name tpsDOT relates to calculus. The mathematical ideal of this is the *instantaneous* rate of change, approached by looking at average change over ever smaller time intervals.
But just because it's mathematically ideal doesn't mean that it's ideal for our purposes. For deciding how much extra fuel to squirt in (or whatever) the instantaneous change is irrelevant. What is really relevant is the average change over some meaningful interval.
I'm afraid I don't have the training to say what that meaningful interval would be. One cylinder stroke? The time it takes the gas, or a sound wave, to travel along the intake tract? I don't know, and this might make a talking point for those with some engineering training. What I feel reasonably confident in saying is that MS is looking at too short an interval.
Here's another graph, two different estimates of part of a sine curve:
The red curve samples the sine curve, truncated to integer, every unit. The blue curve samples the integer truncated sine curve only every fourth unit. tpsDOT is the slope of the curve -- which slope better estimates the slope of the real sine curve? IOW, sampling less frequently is a win. Oversampling leads to successive over and under estimates of the actual slope. This will be worst at areas of slow change.
Time to cut to the chase. The interval that the 3.1.1 code uses is 10ms -- 100 times per second. I have put in a small change in ms2_extra_main.c to only sample every 40ms -- 25 times per second. The car still seems to run fine (on a few revs in neutral test) and the noise in tpsDOT has fallen quite a bit, with typical jitter of around 20 being reduced to around 4, but the peak values still looking much the same as before.
I don't think the chief benefit of this is in reducing noise on fixed throttle, but in slightly more accurately estimating the real rate of change of throttle position thus improving throttle based enrichment.
Here's a patch file which applies my changes. Most of the changes are to indent, or adding comments, the meat of it is to wrap appropriate lines in "if (tpssample_time > 320) { }".
Grrr. Maximum 3 attachments. I'll post the patch in a followup.
Have fun,
Rob.
I'm sure I'm not the only one here to look at the TP values at idle, fluctuating around between 0 and 1. Like this:
and compare it with the corresponding tpsDOT values which seem very volatile for such small movements. Like this:
The name tpsDOT relates to calculus. The mathematical ideal of this is the *instantaneous* rate of change, approached by looking at average change over ever smaller time intervals.
But just because it's mathematically ideal doesn't mean that it's ideal for our purposes. For deciding how much extra fuel to squirt in (or whatever) the instantaneous change is irrelevant. What is really relevant is the average change over some meaningful interval.
I'm afraid I don't have the training to say what that meaningful interval would be. One cylinder stroke? The time it takes the gas, or a sound wave, to travel along the intake tract? I don't know, and this might make a talking point for those with some engineering training. What I feel reasonably confident in saying is that MS is looking at too short an interval.
Here's another graph, two different estimates of part of a sine curve:
The red curve samples the sine curve, truncated to integer, every unit. The blue curve samples the integer truncated sine curve only every fourth unit. tpsDOT is the slope of the curve -- which slope better estimates the slope of the real sine curve? IOW, sampling less frequently is a win. Oversampling leads to successive over and under estimates of the actual slope. This will be worst at areas of slow change.
Time to cut to the chase. The interval that the 3.1.1 code uses is 10ms -- 100 times per second. I have put in a small change in ms2_extra_main.c to only sample every 40ms -- 25 times per second. The car still seems to run fine (on a few revs in neutral test) and the noise in tpsDOT has fallen quite a bit, with typical jitter of around 20 being reduced to around 4, but the peak values still looking much the same as before.
I don't think the chief benefit of this is in reducing noise on fixed throttle, but in slightly more accurately estimating the real rate of change of throttle position thus improving throttle based enrichment.
Here's a patch file which applies my changes. Most of the changes are to indent, or adding comments, the meat of it is to wrap appropriate lines in "if (tpssample_time > 320) { }".
Grrr. Maximum 3 attachments. I'll post the patch in a followup.
Have fun,
Rob.