On Tuesday 14 June 2005 01:58 pm, Scott Dattalo scribbled:
> If the least significant digit is fluttering around, then this
> hysteresis will reduce the flicker rate. If the sample is bouncing
> around by more than 1-count but less than the threshold, then this
> routine will not necessarily track the change. That's because it *is* a
> hysteresis filter. You may wish to examine the routine again. Here's the
> behavior for sample data for a THRESHOLD = 2:
>
> curr displayed
>   283    ???
>   283    283
>   285    285
>   284    285
>   285    285
>   286    285
>   287    287
>   286    287
>   286    286
>
> In this contrived example, the value 285 remains steady even though the
> data bounces around it. Only when the data exceeds the threshold do we
> see the displayed value change.
>
> Scott


Okay, now I got ya.  I was interpreting your "last_sample" variable to mean 
"last displayed" sample.  What I now see here it that this is exactly what I 
was doing initially, but got noticeable digit toggling still.  This is when I 
extended it to 3 cycles.  I'm guessing at this point, that extending the 
testing out to more than 3 cycles will help a lot.  When I posted the 
question originally, I was really hoping there was some algorithm that I had 
not heard of before that would take care of this (expectedly common) problem. 
:-(

On the side, since you mention abs(), is there a neat trick/way in PIC 
assembly to calculate abs(x-y)?  I'm currently doing the subtraction, and 
then explicitly comparing for -1 or +1.  (Actually, I'm adding 1 after the 
subtraction, then comparing for 0 or 2).

Cheers,
-Neil.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist