Shop OBEX P1 Docs P2 Docs Learn Events
How to discard hi/low in averaging - Page 2 — Parallax Forums

How to discard hi/low in averaging

2»

Comments

  • yisiguroyisiguro Posts: 52
    edited 2019-04-10 14:44
    DS18B20 consumes almost about 100ms for conversion in worst case even at 9bit mode, the lowest resolution. Acquiring 10 times a second is too fast, I think.

    I found that DS18B20 has default temperature value of +85 degree celsius on Power-On-Reset. Interesting.
  • T ChapT Chap Posts: 4,198
    edited 2019-04-10 01:24
    Are you guys doing 3 back to back reads then applying median and then discarding those 3? Or taking 1 read, shifting out the oldest, adding in latest, then applying median? In a loop with a lot of other stuff taking place what’s best. I am working on a method to take an average of a motor driver current.
  • T Chap wrote:
    ... Or taking 1 read, shifting out the oldest, adding in latest, then applying median?

    In my example, yes.

    -Phil
  • The datasheet says the DS18B20 is configurable from 9 to 12 bits. Lower resolution 'might' help.
  • Larry
    I'm using 9 bits but didn't help. But my post from 2019-04-05 - 09:12:30 seems to have solved the problem.
    Thanks all
    Aaron
  • That should have been 2019-04-05 - 16:04:46
  • Here to emphasize that all 8 or whatever number of sensors on a string can be asked to convert all at once. So the conversion times overlap all in parallel. After that, it is relatively fast to read out the results one at a time.
    ow.reset                                ' send convert temperature command
      ow.writebyte(SKIP_ROM)        '$CC
      ow.writeByte(CONVERT_T)     ' $44 asking all sensors to convert in parallel
    

    I like to use a three- (or more) point median in a circular buffer, so the most recent reading replaces the oldest--There is one output sample from the filter for each input. That chains into another filter or average.

    The median does have a delay, phase lag, to a step at the input, 1/2 the length of the buffer. So the sample rate needs to be high enough to where that delay doesn't matter. Sometimes you want to start seeing steps quickly after they happen, and for that an adaptive response is desirable. For example, I have a "freezer", an environmental chamber, that uses liquid CO2 for cooling. The temperature can drop very fast and the PID controller has to keep up.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2019-04-12 22:00
    The median does have a delay, phase lag, to a step at the input, 1/2 the length of the buffer.

    Tracy,

    Doesn't the median have a variable lag, depending upon the values in the buffer? For example, if the most recent reading happens to be the median, the phase lag will be zero. OTOH, if the least recent reading happens to be the median, the phase lag will be the length of the buffer, minus one.

    Of course, if the readings are noiselessly monotonic, the phase lag will always be half the buffer length.

    -Phil
  • Phil, lag is lag even if you are fortunate to have a signal that doesn't make it noticeable. Lag is only noticeable if the signal is changing. If it is steady, lag cannot even be detected. And lag is determined by comparing with a signal that cannot be produced in the real world; for example, the "perfect" median signal would use N/2 past samples and N/2 future samples to determine the current moment's value, but since we can't get signals from the future, there's lag.
  • localroger,

    What you're saying is true of any linear filter. But the median is not a linear filter. Because of the way it's constructed, its lag will vary dynamically from sample to sample. On average, of course, the lag will be n/2.

    -Phil
  • Well Phil you could say the same thing of my increment/decrement approach, which is also nonlinear; it has no lag at all unless the signal is changing too fast for it to follow, in which case it has whoa bigtime lag. I suppose it is fair to say that "lag" is one of those things that depends in a big way on the nature of the signal you're processing.

    In the case of the OP it's the temperature of a large physical object, which by its nature can't possibly change very fast. That provides a lot of options for signal processing which wouldn't be appropriate in another situation, such as the active drive train of an automobile.
  • Phil,

    I was referring specifically to the response to a step input, which is a standard and very practical test for a filter scheme, be it parametric, non-parametric, or whatever. Certainly there is no delay if the signal is not changing. A real deterministic change takes that same 1/2 length time to propagate to become the median.

    Maybe the signal is known to be a series of steps interspersed with flat areas, and the whole thing is subject to whitish noise plus pops or sampling errors. How then to tune the filters to respond as fast as possible to the steps, but to be as quiet as possible on the flats? The freezer in the example isn't that kind of signal necessarily, but it might be if someone walks away and leaves the door open.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2019-04-15 17:57
    I was referring specifically to the response to a step input, which is a standard and very practical test for a filter scheme, be it parametric, non-parametric, or whatever.
    That's sensible, since it allows filters to be compared on an equal footing.

    Pursuant to logalroger's increment/decrement method, I came up with a technique that varies the step size dynamically, in order to reduce the lag. Here's the formula:

    yi = yi-1 + sign(xi - yi-1) * min(abs(xi - yi-1), abs(xi - yi-2) / 2, abs(xi-1 - yi-2))

    Here's a graph of the result:

    step_filter.png

    It eliminates the singleton outliers, and any lag is not noticeable until you get to the step input, whereupon it becomes equal to two.

    -Phil
    774 x 488 - 17K
  • Nice work, Phil! I may end up using that one day myself.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2019-04-15 23:00
    Thanks!

    It occurs to me that it might be better to use the sign of the increment you end up using, rather than

    sign(xi - yi-1)

    in all cases. That does complicate things a bit, though.

    -Phil
Sign In or Register to comment.