Post by thread:[PIC]: Antijitter digital display filter

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Antijitter digital display filter'
2001\04\26@060846 by Russell McMahon

I'll put this under [PIC]: although it obviously has more general application. I'm looking for good ways to reduce "LSB jitter" in a digital display. Jitter is due both to LSB quantisation and genuine process jitter. Has anyone got any better suggestions than the following???? I effectively wish to display a varying process output on a digital display. With stable input the LSB "hunts" and in some cases there is a slow semirandom variation of process output. I wish to minimise LSB hunting and "smooth" genuine variations while not excessively compromising accuracy or response time. (As usual, choose any two :-) ). The genuine process output varies more rapidly and widely than is desirable for user viewing. A significant amount of filtering has already been carried out as part of the overall processing. This portion relates entirely to user-sanitising a genuine data variation. The display is 3 digits, 0 <= DISPLAY <= 500 Accuracy of result is to some extent less important than display stability. The various median and averaging filters discussed here may be applicable but something cruder and simpler may suffice. I have run several simulations and get quite good results from the following 2 simple filters. FILTER1 IF NEW > (OLD+x) then OLD = NEW-x IF NEW < (OLD+x) then OLD = NEW+x DISPLAY OLD ie if the input differs from the display by more than X move the display to within 2 counts of input Setting X = 2 produces quite impressive improvements without adding excessive "flat spots". X=1 is still too jittery The filter FILTER2 IF NEW > (OLD+x) then OLD = NEW IF NEW < (OLD+x) then OLD = NEW DISPLAY OLD ie if Input differs from display by more than X then set display to input. is substantially inferior in display stabilisation. It frequently pulls the display to the peak value on a short local peak rather than reducing the range of fluctuation as in FILTER1 Russell McMahon _____________________________ -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

2001\04\26@063546 by Bob Ammerman

One technique I like for this is to maintain an 'integrated error', when this exceeds a certain limit I update the display: To make it concrete, assume we have a new value of the process variable 10 times per second. integrated_error = 0 displayed_value = process_variable for each sample of the process variable (1/10 seconds): error = process_variable - displayed_value integrated_error = integrated_error + error if (integrated_error > ERROR_LIMIT) or (integrated_error < -ERROR_LIMIT) then integrated_error = 0 displayed_value = process_variable endif end for This has the advantage not only that large changes in the process value are reported quickly, but also that even small long term changes are reported eventually. ERROR_LIMIT controls the tradeoff between displayed jitter and responsiveness. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) {Original Message removed}

2001\04\26@074035 by Alan B. Pearce

>The display is 3 digits, 0 <= DISPLAY <= 500 >Accuracy of result is to some extent less important than display stability. I suppose you cannot run a 10 bit A/D and divide the result by 2 as the obvious first hit to get rid of +/-1 LSB jitter. -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

2001\04\26@083504 by Russell McMahon

> >The display is 3 digits, 0 <= DISPLAY <= 500 > >Accuracy of result is to some extent less important than display stability. > > I suppose you cannot run a 10 bit A/D and divide the result by 2 as the > obvious first hit to get rid of +/-1 LSB jitter. Effectively that an quite a bit more has already happened. A PWM has been read as a digtal word, applied to a FET as a higher frequency PWM to control a load to a variable power source, the resultant load current read by a Sigma Delta software A2D, a square wave speed input has been read as a digital word representing the period, 1/16 of this is added to 15/16 of the prior accumulated result giving an averaging filter - this result is then divided into the A2D result and the answer scaled and turned into a PWM output which is read by another processor to produce a digital word which gives them the dispaly value of concern. The result is as stable as it ought to be but the client would now like it slightly more so. Good eh? :-) Russell McMahon -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

2001\04\26@083917 by Alan B. Pearce

>The result is as stable as it ought to be but the client would now like it >slightly more so. >Good eh? :-) Oh, OK, so you can charge double the price for all the extra work :)) -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

2001\04\26@120731 by Olin Lathrop

> I'll put this under [PIC]: although it obviously has more general > application. > > I'm looking for good ways to reduce "LSB jitter" in a digital display. > Jitter is due both to LSB quantisation and genuine process jitter. I've used a two pole low pass filter for this. The end product is a digital display meant to be interpreted by humans, so there is a certain minimum time constant and update rate you can use. Humans can't make sense of digital displays updating too frequently. I would try 1 to 4 updates per second. Given that, you can easily apply two low pass filters with each set to time constants around 50 to 400 mS without cutting into apparent response time. I had similar problems displaying live measured data on an LCD. My standard approach is now a two pole low pass filter. Different applications require different tweaking of the update rate and the filter time constants. It is also convenient if you can pick the nearest time constant such that the filter fraction multiply just becomes a right shift. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, EraseMEolinspam_OUTTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

2001\04\26@201724 by Russell McMahon

> >The result is as stable as it ought to be but the client would now like it > >slightly more so. > >Good eh? :-) > > Oh, OK, so you can charge double the price for all the extra work :)) Done almost wholly on royalty basis. The customer can change his mind as much as he likes until, between us all, we get it right :-) An interesting way to do business. Hopefully compensated fro by the ultimate result. Hopefully. I'll tell you about the final product when/if it gets into US stores. Russell McMahon. -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

2001\04\27@050437 by Peter L. Peres

Imho, add a median filter to FILTER #1 (the one that works better). This will throw out values that exceed x before the filter is reached. You can implement this by lengthening the 'storage' in filter1. Make it a small vector instead of just 'old' and allow the update iff the new value exceeds the old by x for more than one sample. A two long 'store' vector may be enough but plan for three and surprize yourself. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2001\04\27@050442 by Peter L. Peres

> I suppose you cannot run a 10 bit A/D and divide the result by 2 as the > obvious first hit to get rid of +/-1 LSB jitter. No. Consider the case 1999 and 2000. Divided by two it is 999 and 1000. The last digit is still jumping. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2001\04\27@081322 by Alan B. Pearce

>> I suppose you cannot run a 10 bit A/D and divide the result by 2 as the >> obvious first hit to get rid of +/-1 LSB jitter. >No. Consider the case 1999 and 2000. Divided by two it is 999 and 1000. >The last digit is still jumping. well I think you also need to consider the part I did not quote, and that was the maximum displayed value is 500, so I was working on using a 10 bit converter to be scaled to 1000 at the point the display would be 500, and so the division would eliminate most of the +/-1 LSB jitter. However I take your point that there are boundaries where jumps will still happen, but I think you will find that they happen somewhat less frequently, and so filtering is needed as others suggest. I did also suggest that this would be only a "first hit" at the problem. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2001\04\27@093144 by Paul Hutchinson

> No. Consider the case 1999 and 2000. Divided by two it is 999 and 1000. > The last digit is still jumping. Only true if you truncate the result. If you round the result: 1999/2 = 999.5 999.5 rounded = 1000 No jumping. Paul Hutchinson -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2001\04\28@053418 by Peter L. Peres

(about divide by two to eliminate LSB jitter) > I did also suggest that this would be only a "first hit" at the problem. Dividing by two eliminates exactly one half of the jitter cases. Dividing by four eliminates 3/4 or the cases etc. In general when the input jumps between K*modulo and K*(modulo-1) you lose (where modulo is the number you divided by). Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2001\04\28@053439 by Peter L. Peres

Paul Hutchinson <KILLspamphutchinsonKILLspamIMTRA.COM> wrote: >> No. Consider the case 1999 and 2000. Divided by two it is 999 and 1000. >> The last digit is still jumping. > >Only true if you truncate the result. > >If you round the result: >1999/2 = 999.5 >999.5 rounded = 1000 >No jumping. Ah, good idea!. And simple to implement too. Why is this not mentioned in books ?! (I know: I have the wrong ones). So all you need to do is store the LSB, shift right (with C reset at start and propagating down through bytes) and then increment all by 1 with carry if the stored LSB was 1. Neat. thanks, Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2001\04\28@093759 by Bob Ammerman

This still doesn't work. What about the case of 1998 to 1999. 1998/2 = 999 rounded you get 999 1999/2 = 999.5 rounded you get 1000 [Did anybody see my 'integrated error' solution to this problem. I have implemented it and it works _very_ well!] Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) {Original Message removed}

2001\04\28@104523 by Roman Black

Bob Ammerman wrote: > > This still doesn't work. What about the case of 1998 to 1999. > > 1998/2 = 999 > > rounded you get 999 > > 1999/2 = 999.5 > > rounded you get 1000 > > [Did anybody see my 'integrated error' solution to this problem. I have > implemented it and it works _very_ well!] Yep I saw it and straight away thought it looked similar to the way we stop servomoters hunting when they are at rest but still allow for good speed transitions. But I never would have thought of suggesting it for a method of stopping display jittering... Very clever! :o) -Roman -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2001\04\28@111122 by Russell McMahon

> [Did anybody see my 'integrated error' solution to this problem. I have > implemented it and it works _very_ well!] Yep - I seen ! My method is effectively adding hysteresis with some extra decision making in one version. I have since implemented method 1 on an 8 bit A2D input with an 8.5 bit worst case accuracy and it also works extremely well. This is NOT the system I asked about - it is in the test system for auto-testing the system I asked about :-) Your version has advantages and disadvantages compared. A combination will work even better than either (I think). I will be trying this tomorrow. My method is well modelled by going walkies with a kangaroo on a 2 metre leash along a path. The kangaroo jumps in 1 metre leaps. You follow as it leads. The kangaroo reverses direction pseudo randomly or sometimes jumps up and down on the spot :-) (What a strange kangaroo). Plot kangaroo and walker paths. Your method either "zeros in " fairly early (large error) or has a potentially long period when it is in error (small offset). The error delay is inversely proportional to the error distance. Sometimes you do not want an inverse linear error-distance/response time model. My method can have you 2 units (typically) off for an indefinite period (kangaroo at leash end and jumping on spot). By adding your version to mine I get my immediate following for a moving trend and your exact track after a period of standstill. Russell McMahon] -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2001\04\28@145729 by Bob Ammerman

{Quote hidden}> Bob Ammerman wrote: > > > > This still doesn't work. What about the case of 1998 to 1999. > > > > 1998/2 = 999 > > > > rounded you get 999 > > > > 1999/2 = 999.5 > > > > rounded you get 1000 > > > > [Did anybody see my 'integrated error' solution to this problem. I have > > implemented it and it works _very_ well!] > > > Yep I saw it and straight away thought it looked > similar to the way we stop servomoters hunting > when they are at rest but still allow for good > speed transitions. > > But I never would have thought of suggesting it > for a method of stopping display jittering... > Very clever! :o) > -Roman My original application for it was for reporting data from a remote data acquisition device back to a master computer over a limited bandwidth link using a 'report-by-exception' scheme. This is often done with a simple 'deadband' scheme, but that a value that differs from the last reported value by less than the deadband is never reported. Hence the integrated error scheme. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

'[PIC]: Antijitter digital display filter'
2001\05\01@030635 by David Cary

Dear Russell McMahon, If a display is updating more rapidly than it can be read, the most common thing to do is to update that display more slowly. Then you can be sure that the value displayed is a real value, perhaps not the current one this instant but sometime during the last update time. if (next_update_time - now) < 0 ; // does the Right Thing when timer wraps around, unlike (next_update_time < now). displayed_value = process_variable next_update_time = next_update_time + update_time Is that simple and crude enough ? I've seen lots of graphics rendering engines with a "benchmark" of 400 frames / second, but a properly written video game doesn't update the screen faster than about 30 frames / second. (Sunday morning cartoons only have 15 frames/s). If you have changing numbers or text, you can't even read them at 5 updates / second. I've seem many displays that update the display about 1 or 2 times/second. I've even seen a few displays (typically weather-related) that only update once per day, but rather than just showing 1 random point in that time, they show both the peak and the valley during that time. ---- Russell McMahon <RemoveMEapptechTakeThisOuTCLEAR.NET.NZ> on 2001-04-26 05:04:25 AM suggested: FILTER1 IF NEW > (OLD+x) then OLD = NEW-x IF NEW < (OLD+x) then OLD = NEW+x DISPLAY OLD ie if the input differs from the display by more than X move the display to within 2 counts of input ---- This looks like classic hysteresis. It's reminiscent of the "dead band" on RC servomotors. I think this is great when X is less than the precision of your display. For example, say your display is 0 to 500, X is 2, and the last (decimal) digit is rounded to either 0 or 5. But if I needed X to be greater than my display precision, then I don't like this kind of hysteresis, because the display would be misleading -- the value displayed isn't a real value; it's above or below some real value by X. In that case, I think I like the technique suggested by Bob Ammerman a little better, because it always displays a real value of the process. ---- Bob Ammerman <spamBeGoneRAMMERMANspamBeGonePRODIGY.NET> on 2001-04-26 05:32:57 AM suggested: One technique I like for this is to maintain an 'integrated error', when this exceeds a certain limit I update the display: To make it concrete, assume we have a new value of the process variable 10 times per second. integrated_error = 0 displayed_value = process_variable for each sample of the process variable (1/10 seconds): error = process_variable - displayed_value integrated_error = integrated_error + error if (integrated_error > ERROR_LIMIT) or (integrated_error < -ERROR_LIMIT) then integrated_error = 0 displayed_value = process_variable endif end for This has the advantage not only that large changes in the process value are reported quickly, but also that even small long term changes are reported eventually. ---- Russell McMahon later suggested combining these 2 filters. Sounds fine to me, although maybe a bit complicated. -- David Cary -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...