"Noisy" tpsDOT

[ol boy]

He had a mystery MAP spike which added fuel and caused a short rich condition. There wasn't any reason for the spike, TPS was steady, BatV was steady, all was at a steady state when a MAP spike hit. I suggested changing C2 to something larger like 10uF to filter out sudden unexplained spikes(noise). 750ish Hz and higher would get filtered if I did the math right.

I wounder if he had a intake valve issue where one got hung up and didn't seat right. Or just noise...

[robs]

Whew, this thread has fairly taken off. I haven't had a chance to do any modelling of the moving anchor mk2 algorithm I was talking about. May get to it later today. Just a quick response to Jason's last question for now.

Sorry I missed following this thread in the middle part. Would you be so kind as to save me reading 7 pages by typing a brief explanation of "same example as robs mystery MAP issue"?

Ryan was referring to a different thread -- Momentary jump in MAP. You can read about it there but, in summary, my log file would very occasionally have a huge spike in mapDOT in situations which I knew were light cruise. All evidence is that this is an occasional misreading of the AD line in question. I have removed some MAP sampling code that didn't make much sense to me and haven't seen any spikes since.

My car particularly highlighted this problem because the mapDOT is calculated from the raw values but it probably is there under the surface for everyone. I assume (and hope) that Ken's new approach to MAP sampling has got rid of the unnecessary restarting of the AD cycle. I'm glad that I took the approach of tracking down the real problem rather than applying (say) a median(3) filter to hide it.

Jason, I'm from a technical maths/computing background, not EE, and I think this is why I'm having bother understanding some of your suggestions. I welcome them, but I'd be grateful if you could flesh them out a bit more -- it's not just that I don't want to wear out Google looking everything up, sometimes I'm not too sure just what I need to look up.

For example, in one of your postings you said:

2 of the "lag" filters in cascade (each having the same lag factor) also implement a 2-pole Bessel.

My reading of this is that, given a function lag(a, b, p), to compute the MS style lag factor p% on the interval between values a and b, then

Code: Select all

lag(lag(a, b, p1), b, p2)


with p1 == p2 implements a 2-pole Bessel filter. At least this is what I would think a "cascade" of the filters might be. Problem is I don't even need to do any algebra to see that the above is equivalent to

Code: Select all

lag(a, b, p3)


for some p3. Geometrically the result of the first lag function is a proportion of the way from a to b, and the second lag function goes the same proportion along the remaining interval. This fixed proportion of a fixed proportion is obviously itself a fixed proportion and can be implemented with a single lag function.

So either I have misunderstood what you mean by cascading, or maybe there is some other lag function you have in mind.

Have fun,

Rob.

[JasonC SBB]

lag(lag(a, p1), p2)

... is not the same as

lag(a, p3)

The first is a 2-pole lopass filter, the 2nd is a 1-pole filter with a (presumably) slower (p3) time constant.

The momentary spike in MAP - how many samples wide was it? Single-sample spikes like that btw will be completely filtered out by a 3-element median filter.
This is why I suggest having both some kind of nonlinear filter, and a 2-pole bessel. They are good at filtering different types of noise, and you usually need them both for a robust system.

BTW the dot operation should NOT be done on the raw MAP data. It should be done on the (properly) filtered MAP signal.

[JasonC SBB]

Just to be sure, could you post a snippet of the lag filter code?

[robs]

Just to be sure, could you post a snippet of the lag filter code?

Sure, here's the code:

Code: Select all

    __asm__ __volatile__ (
       "ldd    %1\n"
       "subd   %3\n"
       "tfr    d,y\n"
       "clra\n"
       "ldab    %2\n"      // it is a uchar
       "emuls\n"
       "ldx     #100\n"
       "edivs\n"
       "tfr     y,d\n"
       "addd    %3\n"
       : "=d"(outpc.tps)
       : "m"(tmp1),
       "m"(flash4.tpsLF),
       "m"(outpc.tps)
       : "x", "y" );


As you can see, this sets the new tps value to be, as I described earlier, lag factor percent of the way from the previous tps value to the most recent sample. You can indeed "cascade" as many of these as you want and, assuming all the lag factors are fixed, you will always end up with something that could be done with a single lag evaluation.

Can you just say what you mean by a lag function?

On the MAP spike question, I am not absolutely sure (since the RS232 doesn't log everything), but I think it's one sample wide. I already said that a median(3) would have hidden the spike. That was my point. It would have hidden a code problem that is better fixed.

A bald statement on the desirability of applying the dot operation on filtered rather than raw data is not terribly convincing (just my bald statements to the contrary haven't convinced anybody). This needs to come down to specifics. The sort of filtering which corrupts dot calculations is averaging operations that blend previous samples with the most recent (e.g. lag averaging). Those corrupt the sample for dot calculation. However, in the case of the new MAP sampling algorithm, I have no issue at all with taking the mean of all the samples over the stroke, as long as we calculate dot values between strokes. In this case the averaging isn't filtering, it is simply the way to construct the input value, just as the previous method was to take the lowest MAP reading in the sampling window.

I won't argue against your statement, but without a definition of "properly" it says nothing.

Have fun,

Rob.

[robs]

Pretty dismal result on my "inspiration". Need hardly have bothered.

Here are the results. Firstly, a rerun of the last simulation adding moving anchor v2.

noiseslow.pdf

Slow movement noise tolerance

(61.05 KiB) Downloaded 30 times

The new algorithm no longer requires a PERSIST argument to decide how long a sensor should have had no significant change before we decide that it isn't changing at all. The new approach keeps a trend line of recent changes and only recomputes that trend line when the values have deviated from it. It's not a bad result, but my worries that this algorithm might tend to "bounce off the sides" were justified after all. There is an inherent decay factor, but it just doesn't look as good as v1.

The dot graph now uses a stairstep plot rather than the simple join the dots that I used before. The less the area between the stair step and the ideal line, the better. I think this gives a feel for which algorithm performs best.

Grant suggested that median(5) would be more realistic, so that's included.

The above all represent a movement that is relatively close to the noise level. These are the hardest to extract from a noisy input. In TPS terms that plot would represent someone moving the throttle at a pretty slow rate -- 0-100% in 5 seconds. So here are a set of plots of ten times faster movements: 0-100% in 0.5 seconds.

noisefast.pdf

Fast movement noise tolerance

(62.63 KiB) Downloaded 27 times

The jitter is much less visible on the Raw plot, and it is pretty well the best fit in the dot graph. Median has once again just introduced a delay. Lag lives up reasonably well to its name, but isn't a bad result. Moving anchor doesn't respond very quickly. Moving window LSQ is slow to respond. Moving anchor 2 responds magnificently, but then bounces off the walls at the end trying to find out that nothing's happening.

This run was done with a different random number seed from the first set.

Once again, a somewhat equivocal result. For fast movements I guess I'd rank them raw, lag, moving anchor, moving anchor 2, moving window LSQ, with median bringing up the rear. For slow movements I suppose it'd be moving anchor, moving window LSQ, lag 50, moving anchor 2, raw and median being very consistent.

Happy to provide the updated R code if anyone wants.

Have fun,

Rob.

[JasonC SBB]

Thanks but can you post C or pseudocode? That looks like assembly I'm not familiar with.

"A bald statement on the desirability of applying the dot operation on filtered rather than raw data is not terribly convincing"

If you read my posts a couple of pages back, I explained how the characteristics of the signal, the information therein, and the noise all need to be understood before a proper filter can be spec'd, designed, and tested. And this includes the rate of change information. Because the signals (MAP, TPS) are going to be used with a dot operation, then the filtering has to be designed accordingly. I also explained why a 2-pole filter (run through a lag filter twice) is superior when the filter output needs to pass through a dot operation. I explained that the rise time to step input and delay time from a ramp input are important figures of merit for measuring filter performance. WRT an engine's operation, one needs to think about how much delay and rise time a throttle enrichment operation can tolerate and not result in a misfire or hesitation.

"Can you just say what you mean by a lag function?"

Last time I looked at it it looked to me like a single-tap "IIR" filter. Specifically the 2 examples on the first page, with coefficients between 0 and 1:
http://www.lavryengineering.com/white_papers/iir.pdf

[robs]

Thanks but can you post C or pseudocode? That looks like assembly I'm not familiar with.

Here's how I described it earlier in this thread:

...The tuner gets to specify a lag percentage. The output of the lag calculation is the value that percentage of the way between the last output value and the most recent raw value. So a lag value of 0 locks the input forever where it started. A lag of 100 simply gives the most recent sample. A lag value of (say) .75 gives you T(n) = T(n-1) + .75[T(n)-T(n-1)]. Since T(n-1) depends similarly on T(n-2), there is actually a little feedback from everything that has ever happened, except that truncation of fractions soon wipes that out.

I left out the fairly intuitive fact that the lag percentage had to be in [0:100].

The lag filter can be viewed as blending the previous lagged value with the most recent sample, so a lag value of 40% is 6 parts previous value to 4 parts latest. Since the earlier geometric explanation didn't convince you, here is the algebra to show that cascaded MS lag filters are equivalent to a single MS lag filter with a different lag percentage:

Code: Select all

The MS lag filter can be expressed as:
    (1) T(n) = pT(n-1) + qSn
where p is in [0:1]; q is 1-p, and Sn is the nth sample (i.e. the most recent).  A MS lag value of 40% would be p=0.6, q=0.4.  If you cascade this filter twice you get:
    (2) T(n) = p[pT(n-1) + qSn] + qSn
             = (p^2)T(n-1) + pqSn + Sn
             = (p^2)T(n-1) + [p(1-p)+1]Sn
             = (p^2)T(n-1) + (1-p^2)Sn
Which can clearly be expressed in one iteration of equation (1).


If you read my posts a couple of pages back, I explained how the characteristics of the signal, the information therein, and the noise all need to be understood before a proper filter can be spec'd, designed, and tested. And this includes the rate of change information. Because the signals (MAP, TPS) are going to be used with a dot operation, then the filtering has to be designed accordingly. I also explained why a 2-pole filter (run through a lag filter twice) is superior when the filter output needs to pass through a dot operation. I explained that the rise time to step input and delay time from a ramp input are important figures of merit for measuring filter performance. WRT an engine's operation, one needs to think about how much delay and rise time a throttle enrichment operation can tolerate and not result in a misfire or hesitation.

I have read all your posts and agree with the general thrust of much that you say, or at least that portion which made sense to me. Referring to your paragraph above, I agree that we need to understand the nature of what is to be measured, what should be treated as signal, what as noise. However I don't believe you have ever explained why running values through a lag filter twice is superior for the dot operation, you merely asserted it. But I'm not that fussed about the theory. If you have specific software filter suggestions, stated in terms that a mathematically literate electronic incompetent might understand, this mathematically literate electronic incompetent will be happy to code them up in R and test them against Gaussian noise, or other suggested test scenarios.

Last time I looked at it it looked to me like a single-tap "IIR" filter. Specifically the 2 examples on the first page, with coefficients between 0 and 1

Yes, the examples with positive ratios look very much like a MS lag filter. Interesting notion to use negative ratios, but I'm afraid the document quickly becomes difficult for me. While I know most of the terms, they aren't second nature. As soon as it gets going on "attenuation" and "cutoff frequencies", I spend so much effort translating it into my concepts that I lose track of where it's all headed.

Have fun,

Rob.

[robs]

I think you misunderstood. I wasn't talking about what you were doing specifically, but instead talking about filtering both the main signals themselves and additionally filtering the "dots" (all of them). More filters of more signals means more work. Considerably more depending on the type of filter used.

I don't think I misunderstood, I was pointing out that, at least in this instance, a simple check to see whether it was worth calculating a new dot value was necessary can reduce the burden on the processor.

I wouldn't say they have to be perfect though you are correct that any noise in the original signal is magnified. However, my statement is one of what is *necessary*. With limited CPU resources, I want to make sure we do the least amount of work possible in the code while maintaining good results.

Which doesn't really say anything one way or the other. "Necessary" is a woolly word -- anything from the heroic, "we'll do whatever it takes", to the stingy "we'll cover the bare essentials".

Anyhow, as I've said, the moving anchor approach gives better results while using less CPU cycles. It uses the same amount of RAM, and a handful or two extra bytes of flash.

However, the piece you're missing is "is the delay a problem?"

Heh.

? That comment was aimed at gslender not you.

Indeed. I was just reminded of our discussions in the old "noisy RPM" thread a while back.

I think maybe you misunderstood my point there. I wasn't saying that anything was happening too soon. I was just saying that there are requirements for how quickly the "dot" data is updated after the actual events themselves happen, and in many cases, getting the data faster doesn't help. For example, we can only inject fuel so often. Getting the data more often than that is not necessarily important as long as we have good data just before the injection event is scheduled. Does that make more sense?

That is a very legimate point, and could lead to a far superior result for tpsDOT from the current approach to TPS sampling. I made my changes the way I did because I thought it might be accepted if it was a minimal disruption to the code.

In light of what you say above, I think it'd be wise to consider a similar approach for TPS to the new approach for MAP. If TPS was sampled (say) prior to each injection event, rather than blindly every 0.01s, you'd get the cumulative movements of throttle -- the dy value -- essentially for nothing. If this is greater than some sort of noise threshold you divide it by the elapsed time and there's your tpsDOT. At low engine speeds this would be a small fraction of the work currently being done by the CPU. High speeds would need a bit of consideration as the ratio would -> 0/0, which isn't good. But then enrichment will have trailed off by then anyway.

Well, I'll leave you to think about that.

To be honest I would just like to arrive at a filtering method that avoids requiring the user to tune anything. The lag filters have in the past been a source of confusion and of tuning problems, so I'd like to avoid that in the future. I'm not saying your method lacks technical merit or that it doesn't work. I'm just saying that I think we can come up with something that doesn't require the tuning parameters.

I don't think it's possible in the world that MS currently inhabits. You've got bikes with feeble electrical systems, people who don't solder well, people who can't follow a circuit diagram, people (like me) who just reused existing harness wires. While some of these should be fixed at the source of the problem, some problems are intrinsic in the application.

Rather than have a tunable parameter for the noise threshold, you might have a calibration period when the engine first starts, and we just tell everyone "don't touch the throttle for 3 seconds after starting". Except then someone with his experimental engine says "but I have to run my double-deplenerator for the first five seconds after starting and it's as noisy as all get out -- can't I have a tuning parameter?"

Have fun,

Rob.

[piledriver]

"don't touch the throttle for 3 seconds after starting"

Note that will be a PITA until you have your cranking fuel/ASE etc perfect at all temperatures and can always just bump the key.
I realize that's just an example, but still...

Code that could adaptively check and set a noise threshold within a reasonable band would be nice, but would also probably be larger than the available space with my luck.

[muythaibxr]

Which doesn't really say anything one way or the other. "Necessary" is a woolly word -- anything from the heroic, "we'll do whatever it takes", to the stingy "we'll cover the bare essentials".

I hear what you're saying, but in the context I was using the word, it's pretty well defined. Do the minimum that must be done to get a signal that gives you both response and smoothness.

I don't think it's possible in the world that MS currently inhabits. You've got bikes with feeble electrical systems, people who don't solder well, people who can't follow a circuit diagram, people (like me) who just reused existing harness wires. While some of these should be fixed at the source of the problem, some problems are intrinsic in the application.

I'm just not willing to give up that easily. There are a lot of smart people here discussing the problem. If we get to the point where there really isn't anything that can be done, we'll gladly use the "moving anchor" setup, but as I said I think it makes the most sense to filter the main signal and use that to generate the "dot" calcs.

As far as making TPS sampling the same as MAP, it's worth a shot.

Ken

[muythaibxr]

"don't touch the throttle for 3 seconds after starting"

Note that will be a PITA until you have your cranking fuel/ASE etc perfect at all temperatures and can always just bump the key.
I realize that's just an example, but still...

Code that could adaptively check and set a noise threshold within a reasonable band would be nice, but would also probably be larger than the available space with my luck.

I don't think that solution is really a viable solution either. I just don't think we should give up on something that doesn't require tuning.

Robs may be right, making it work like the current MAP sampling works may help. James had some ideas on ways to make it better as well that we've discussed off the forums.

Ken

[robs]

"don't touch the throttle for 3 seconds after starting"

Note that will be a PITA until you have your cranking fuel/ASE etc perfect at all temperatures and can always just bump the key.
I realize that's just an example, but still...

As you say, it was an example of what might be tried to avoid having user configurable parameters. I think it'd be pretty bad in practice. Some day you happen to start your car near high voltage transmission lines or near some NSA snooping site or some such and you get dismal response until you restart.

I don't think that solution is really a viable solution either. I just don't think we should give up on something that doesn't require tuning.

Robs may be right, making it work like the current MAP sampling works may help. James had some ideas on ways to make it better as well that we've discussed off the forums.

It seems plausible that, going with the "sample when it's about to be used" approach for TPS, you could take (say) four samples just when the squirt is about to happen. The mean of four can be efficiently calculated and this would probably get the noise reasonably under control without needing a parameter. Of course you wouldn't want it to average over the whole stroke as per MAP. With MAP you're interested in the area under the curve, with TPS it's the latest sample we're after.

As far as making TPS sampling the same as MAP, it's worth a shot.

I'll leave you to do the shooting. It'll probably be pretty good if/when you get to it.

Have fun,

Rob.

[muythaibxr]

It seems plausible that, going with the "sample when it's about to be used" approach for TPS, you could take (say) four samples just when the squirt is about to happen. The mean of four can be efficiently calculated and this would probably get the noise reasonably under control without needing a parameter. Of course you wouldn't want it to average over the whole stroke as per MAP. With MAP you're interested in the area under the curve, with TPS it's the latest sample we're after.

This is a fair suggestion.

Ken

[JasonC SBB]

...The tuner gets to specify a lag percentage. The output of the lag calculation is the value that percentage of the way between the last output value and the most recent raw value. So a lag value of 0 locks the input forever where it started. A lag of 100 simply gives the most recent sample. A lag value of (say) .75 gives you T(n) = T(n-1) + .75[T(n)-T(n-1)].

OK it indeed is a single tap IIR lopass filter. It creates a single pole lopass filter. Just like the first 2 examples in the linked PDF with the positive values.

2 identical "lag" (or 1st order lopass) filters in cascade is NOT the same as a single 1st order lopass filter with some equivalent "lag factor" (aka time constant aka pole frequency)

The math (using laplace transforms) is like this

1-pole transfer function: 1 / (k1*s + 1) <-- denominator is 1st order
2-pole transfer function: 1 / (k2*s^2 + k3*s + 1) <-- denominator is a 2nd order polynomial... and 2-pole Bessel degenerates into two identical 1-pole filters in cascade

Here is an example of a step response of the former vs. the latter filter. There is no way to make the step responses match by adjusting the lag factor of the 1-pole filter:

The 1-pole filter has a 25% lag factor, the 2-pole has 40% each.


The difference you see in my example may be subtle, but I purposely adjusted them so that they matched partway up. The 2-pole lag filter output rejects high frequency noise much better (see below)

However I don't believe you have ever explained why running values through a lag filter twice is superior for the dot operation, you merely asserted it. But I'm not that fussed about the theory.

A single pole lopass filter will filter out frequencies above its "corner frequency" at a rate of -6 dB per octave, meaning the noise voltage is halved for every doubling in frequency.
For example, if the corner frequency is 100 Hz, noise at 200 Hz will be halved, noise at 400 Hz will be 1/4th in size, and at 800 Hz will be 1/8th in size.. and so on.

For a 2-pole lopass filter, or 2 identical 1-pole lopass filters in cascade, the noise voltage is reduced to *1/4th* for every doubling in frequency.
For example if the corner frequency is 100 Hz, noise at 200 Hz will be 1/4th in size, noise at 400 Hz will be 1/16th in size, and and at 800 Hz will be 1/64th in size.

When you perform a dot operation (differentiation) on a signal, you increase the size of the signal at +6 dB per octave, meaning any signal or noise voltage will be DOUBLED for every doubling in frequency.
Thus a signal or noise at 200 Hz will be double the size of a 100 Hz signal, noise at 400 Hz will be 4x the size, and at 800 Hz will be 8x in size.

If you do the dot operation after 1-pole filtering, the attenuation of the lopass filtering will be canceled by the high frequency amplification of the dot operation. The resulting frequency response is flat. That is, the dot operation and the lag operation will cancel, with the result that signals and noise above the lopass cutoff frequency will neither grow in size with frequency, nor shrink.

If you had done 2-pole lopass filtering before the dot operation, the resulting frequency response will be that of a 1-pole lopass filter. (Every doubling in frequency halves the noise amplitude). Thus high frequency noise attenuated.

If you have specific software filter suggestions, stated in terms that a mathematically literate electronic incompetent might understand, this mathematically literate electronic incompetent will be happy to code them up in R and test them against Gaussian noise, or other suggested test scenarios.

You can write a piece of R code to test it. Try it comparing a 1-pole lag filter with 25% lag factor and a 2 lag filters cascaded, each with 40% lag factor (this matches up their ramp delay times)
You can test it with a 1-sample wide spike of noise, and with gaussian noise.
You can also make it very long, then do an FFT and plot the spectra before, and after filtering.

[robs]

...The tuner gets to specify a lag percentage. The output of the lag calculation is the value that percentage of the way between the last output value and the most recent raw value. So a lag value of 0 locks the input forever where it started. A lag of 100 simply gives the most recent sample. A lag value of (say) .75 gives you T(n) = T(n-1) + .75[T(n)-T(n-1)].

OK it indeed is a single tap IIR lopass filter. It creates a single pole lopass filter. Just like the first 2 examples in the linked PDF with the positive values.

2 identical "lag" (or 1st order lopass) filters in cascade is NOT the same as a single 1st order lopass filter with some equivalent "lag factor" (aka time constant aka pole frequency)

Jason, I have provided an algebraic proof that when a MS lag averaging operation is applied a second time to its own output the combined result can be expressed as another MS lag average. Your reasoning appears to hinge on the fact that this is not the case. It is clear to me that there is no point proceeding with this conversation until this contradiction is resolved. I have shown my work. Please review that and track down where the misunderstanding is.

As a suggestion, I find it suspicious that you earlier referred to a lag function as lag(a,p3). There are three inputs to a MS lag filter: the previous lagged value, the latest sample value, the lag percentage. Perhaps if you can explain how just two arguments are enough I'll understand better.

Have fun,

Rob.

[robs]

It seems plausible that, going with the "sample when it's about to be used" approach for TPS, you could take (say) four samples just when the squirt is about to happen. The mean of four can be efficiently calculated and this would probably get the noise reasonably under control without needing a parameter. Of course you wouldn't want it to average over the whole stroke as per MAP. With MAP you're interested in the area under the curve, with TPS it's the latest sample we're after.

This is a fair suggestion.

An interesting potential benefit is that timing it synchronously with injection, we might see much less interference from flyback current, much as they eventually realised it'd be a good idea to synchronise the machine gun to the propeller in WWI fighters.

Have fun,

Rob.

[JasonC SBB]

Jason, I have provided an algebraic proof that when a MS lag averaging operation is applied a second time to its own output the combined result can be expressed as another MS lag average. Your reasoning appears to hinge on the fact that this is not the case.

Your "cascade" operation is wrong. See attached Excel file for what I mean by "cascade". You were thinking of cascading the math of one line of code, rather than having the output data stream of the first "lag" operation, be the input data stream of the 2nd "lag" operation.

As a suggestion, I find it suspicious that you earlier referred to a lag function as lag(a,p3).

That's because I defined a "lag" function not as a line of code but defined as taking 2 inputs - the input data stream, and the "lag factor". This is what cascading transfer functions means in signal and filter theory.

[piledriver]

It seems plausible that, going with the "sample when it's about to be used" approach for TPS, you could take (say) four samples just when the squirt is about to happen. The mean of four can be efficiently calculated and this would probably get the noise reasonably under control without needing a parameter. Of course you wouldn't want it to average over the whole stroke as per MAP. With MAP you're interested in the area under the curve, with TPS it's the latest sample we're after.

This is a fair suggestion.

An interesting potential benefit is that timing it synchronously with injection, we might see much less interference from flyback current, much as they eventually realised it'd be a good idea to synchronise the machine gun to the propeller in WWI fighters.

Have fun,

Rob.

Peanut galley here, tossing out a possible nugget...
(I suck at math so I'm just mostly nodding my head and saying "hmmmm" occasionally)

It certainly helped MAP sampling on sequential, at least for me.
(I just wish MS2 had the table like MS3 to deal with the various MAP peaks over RPM, but I digress)

If we limit the sample angle/width as we do MAP (at least on sequential) to a "quiet" time electrically, the one possibility left is a bit of logic to throw out samples that are out of range, perhaps simply based on tossing out the high/low samples of a small set...

That combination would make for pretty robust digital filtering of pure noise spikes, and likely with very minimal overhead code/computation wise.

[jsmcortina]

the one possibility left is a bit of logic to throw out samples that are out of range, perhaps simply based on tossing out the high/low samples of a small set...

That's the "median filter" that's been mentioned already. It works just as you suggest.

James