Post by thread:[PIC] Hysteresis routine?

Hey folks, Got a problem here with a PIC application where the lowest (rightmost) digit of a numerical value is "toggling" back and forth between 2 (consecutive) values rapidly -- example it will jump back and forth between 283 and 284 rapidly (like 3-4 times a second, which is the update rate on the display). The app repeatedly samples values from an A/D port, performs calcs and displays the result on the numerical LED's. It also has some averaging and a software IIR filter, which after some experimentation, has significantly reduced the occassions when it toggles, but has not eliminated it. An error of +/-1 is not a problem, so a hysteresis routine should work well. Is there such a thing? I've come up with a routine that is somewhat crude -- it keeps track of the last 3 calculated values (sort of a FIFO), and if a new value varies by exactly +/-1 from the last displayed value, then it does not immediately update the display -- it waits until that new value is the result for 3 consecutive cycles. If it goes back to the last displayed value within the next 2 cycles, then no change will be seen. If the change is more than 1 at any time, it updates the display immediately. But I'm guessing there's a better way -- is there? Cheers, -Neil.

At 01:03 AM 6/14/2005 -0500, you wrote: >I've come up with a routine that is somewhat crude -- it keeps track of the >last 3 calculated values (sort of a FIFO), and if a new value varies by >exactly +/-1 from the last displayed value, then it does not immediately >update the display -- it waits until that new value is the result for 3 >consecutive cycles. If it goes back to the last displayed value within the >next 2 cycles, then no change will be seen. If the change is more than 1 at >any time, it updates the display immediately. But I'm guessing there's a >better way -- is there? > >Cheers, >-Neil. How about not updating the display unless the difference from the displayed value is > x, (and set x = 1) ? >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" spam_OUTspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

At 11:57 AM 6/14/2005 +0100, you wrote: > >How about not updating the display unless the difference > >from the displayed value is > x, (and set x = 1) ? > >Trouble is you do want it to show a drift in value, and I think he has it >set about right, but possibly needs to expand the count out to about 5 or 6 >from 3, for the number of counts where it needs to be 1 different from the >current display value. I guess it depends on the application whether a trend is important. If it's something like a weigh scale, it might not be important. Once the number settles, that's it. I am wary of the "number of counts the same" because it changes the behavior based on the noise in the signal, which could be different in the field. He could also implement a slow low-pass filter and preload it to improve the response to large step changes (nonlinear filter). Obviously the internal calculations would be done to a higher resolution than the display. I usually work very hard to make the system much better than the display, usually throwing away a decimal digit or more of resolution to get a good solid display, but then I'm a persnickety instrument engineer type. I don't want the user to lose confidence in the instrument. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam@spam@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

PicDude wrote: > Got a problem here with a PIC application where the lowest (rightmost) > digit of a numerical value is "toggling" back and forth between 2 > (consecutive) values rapidly -- example it will jump back and forth > between 283 and 284 rapidly (like 3-4 times a second, which is the > update rate on the display). That is expected when taking real world measurements. No amount of linear filtering can prevent the resulting signal from going back and forth accross a specific threshold. > I've come up with a routine that is somewhat crude -- it keeps track of > the last 3 calculated values (sort of a FIFO), and if a new value > varies by exactly +/-1 from the last displayed value, then it does not > immediately update the display -- it waits until that new value is the > result for 3 consecutive cycles. If it goes back to the last displayed > value within the next 2 cycles, then no change will be seen. If the > change is more than 1 at any time, it updates the display immediately. > But I'm guessing there's a better way -- is there? The first thing to ask is why the display update needs to be so fast. If numbers changing every update is annoying or diffucult to read, then it sounds like the display is being updated to quickly. Try every 250-500mS. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

olin_piclist@embedinc.com (Olin Lathrop) wrote: > Mike Hord wrote: > > Median filter? Take, say, 5 samples, put them in increasing order > > from least to greatest, then take sample 3. > > That still can't gurantee no bounces from sample to sample. You can always come up with a series of samples to defeat any filter. A median-value filter is a fairly standard approach to this problem. It tends to preserve the underlying signal "waveform" fairly well while filtering out glitches that are less than half the filter length. Its primary drawback is the delay it introduces -- half the filter length, just like any other symmetric FIR filter. Since the implementation involves a sorting operation instead of a dot product (multiply-add), it is well suited to smaller processors with no hardware multiplier. -- Dave Tweed

At 12:03 PM 6/14/2005 -0300, you wrote: >Spehro Pefhany wrote: > > > How about not updating the display unless the difference from the displayed > > value is > x, (and set x = 1) ? > >This may get you calls from the customer why for slowly changing signals >the display always updates in increments of 2 :) If the difference is less than, say, 3, you could have it change a maximum of one per update. ;-) >I actually think Neil's schema makes sense. > >Gerhard Maybe, it's pretty situational, IMHO. I'm trying to simulate a "sticky (meter) needle". >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

Very interesting. I have denounced a lot of switches and led detectors, but never "data". The difference being that switches have two states and data has many states depending on the number of bits. There for, your data can be bouncing the LSB (Least significant Bit) and then get go to a value that changes some of the other bits. And you will ignore the new value as long as the LSB keeps bouncing in the new value. That would be bad. To keep this from happening, would use a counter that was reset every time the display was refreshed with new data and count down the timer every time the data was not refreshed due to it bouncing. The data may go from one unstable value to another unstable and not be considered good data. To keep this from happing, be sure to use the current data (stable or not) every so often.. A simplest way of denouncing would be to shift into a byte the LSB of the data and if the resulting 3 or four bits are all 1's or 0"s then it is stable. Or more demanding and less simple is to compare the 4 LSB's of the current reading to previous readings. While thinking of buffers to hold a history of data, the normal way seems to be to use a FIFO (First In First Out) buffer. And the data has to be bumped up each time, which takes time. What if a rotating buffer was used where the new data was place in the next spot and a counter (modulo the buffer size) was incremented. But instead of incrementing the counter, increment a state flag and have the program test this flag each time and run code customized for that state (where things are in the buffer). That would require more code but less code would run each time. Hummm Bill {Original Message removed}

On Tuesday 14 June 2005 05:57 am, Alan B. Pearce scribbled: > Trouble is you do want it to show a drift in value, and I think he has it > set about right, but possibly needs to expand the count out to about 5 or 6 > from 3, for the number of counts where it needs to be 1 different from the > current display value. Hey! I just said this in another email 2 seconds ago. Great minds.... :-) I'm probably going to have to experiment with this, but I can't right now -- the code is about 4 bytes short of the first page boundary (and I've gone thru it quite a bit to try and clean up/optimize), so any other new code will require some mods to move some routines to the next code-page. First time I have ever needed to go past the 2k boundary, so it will require some careful planning on my part. Cheers, -Neil.

>Prob here will be that if a value legitimately changes by 1 and stays there, >the display will never show it. Now that 1 is not critical, but the routine >I have now will eventually put it there. Perhaps I should stretch that out >to wait a longer number of cycles before deciding that it's okay....hmmm? > >Cheers, >-Neil. Suppose you low-pass filter the value (calculating to a resolution of, say, 1/8 or 1/16 count count)? Will that respond too slowly? Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam.....interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

On Tuesday 14 June 2005 06:51 am, Spehro Pefhany scribbled: > He could also implement a slow low-pass filter and preload it to improve > the response to large step changes (nonlinear filter). Obviously the > internal calculations would be done to a higher resolution than the > display. Sounds interesting, but I'm not sure that I'm totally clear on what you mean here. Are you referring to the IIR software filter? I have implemented this in the code, which does make things a lot nicer than the previous circular-buffer averaging routine, but after much tweaking I've come up with the value of K that lets the display be responsive enough. That left me with a bit of toggling on the last digit still. I would think that a smaller K would reduce/eliminate the toggling, but would also make changes in general less responsive. If by "nonlinear", you mean that K would vary depending on the amount of the change, then that sounds awesome here on paper. Is there a recommendation on how to do this and derive decent initial values of K? Or am I way off track here? Another thought that this brings up is that I might try changing the *rate* of display updates based on the amount of the change. The lower the change, the longer the display holds before changing. This might be easy-ish to implement by adding successive change amounts and allowing the display to change only after the total reaches a certain value. I'll have to think about this more. Cheers, -Neil.

PicDude wrote: > Got a problem here with a PIC application where the lowest (rightmost) digit > of a numerical value is "toggling" back and forth between 2 (consecutive) > values rapidly -- example it will jump back and forth between 283 and 284 > rapidly (like 3-4 times a second, which is the update rate on the display). Neil, Here's a 2-sample hysteresis filter: current_sample = filtered_data(); if ( (current_sample == last_sample) || (abs(current_sample - displayed_sample) > THRESHOLD)) displayed_sample = current_sample; last_sample = current_sample; This cuts the flicker rate in half. To reduce it more, you can increase the number of required consecutive samples from 2 to N and save the last N-1 samples in an array. Scott

Peter Onion wrote: > If you already have the code in place for IIR filter, and it has > improved things, then I would try increasing the number of taps in your > filter so that more samples are taken into account. Personally IIR > filters give me nightmares so I stick to FIR ones where I can make a > reasonable prediction of their behaviour with nothing more that a pencil > and a sheet of squared paper ;-) Not all IIR filters are hard to analize or finnicky. Consider FILT <-- FILT + FF*(NEW - FILT) This is a simple single pole low pass filter, and the equivalent of an analog R/C filter. That's about as easy as it gets. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Tuesday 14 June 2005 10:22 am, Bill & Pookie scribbled: > Very interesting. I have denounced a lot of switches and led detectors, > but never "data". The difference being that switches have two states and > data has many states depending on the number of bits. Interesting perspective -- I would not have thought to analogize it with debouncing a switch. But now it has me thinking about the similarities. [ For switch debouncing, I have a timer set a flag indicating it's time to read switches. When the main code loop sees the flag, it reads all inputs and shifts each into a byte that is setup as a shift register for a particular switch. At that point, the switch processing routine compares the latest 2 bits for "00" (no change), "11" (switch still held down), "01" (switch just pressed), and "10" (switch just released), and acts accordingly depending on what's needed. Controlling debouncing is just a matter of setting the correct timer 1 frequency. Works beautifully! ] One of the big diffs I see here is that with a switch, when the input changes to a value (say from 0/OFF to 1/ON), I know for a fact that the switch was pressed, no matter how short the duration. In the case of data, a change can mean noise based on the duration. So I don't think these are really analogous. > There for, your data can be bouncing the LSB (Least significant Bit) and > then get go to a value that changes some of the other bits. And you will > ignore the new value as long as the LSB keeps bouncing in the new value. > That would be bad. Not sure what you exactly mean here -- are you referring to the data bouncing between say 99 and 100? Where a change in the LSB will affect all the other bits to the left? If so, this is not a problem in my existing routine, since I'm comparing the last vs. current *values* and looking for a change of +/-1 -- not just a change in the LSB. {Quote hidden}> To keep this from happening, would use a counter that was reset every time > the display was refreshed with new data and count down the timer every time > the data was not refreshed due to it bouncing. > > The data may go from one unstable value to another unstable and not be > considered good data. To keep this from happing, be sure to use the > current data (stable or not) every so often.. > > A simplest way of denouncing would be to shift into a byte the LSB of the > data and if the resulting 3 or four bits are all 1's or 0"s then it is > stable. Or more demanding and less simple is to compare the 4 LSB's of the > current reading to previous readings. How does this differ then the routine I'm experimenting with now (where it waits to see if a value (with a change of just +/-1) holds for 3 cycles currently before sending it to the display)? > While thinking of buffers to hold a history of data, the normal way seems > to be to use a FIFO (First In First Out) buffer. And the data has to be > bumped up each time, which takes time. What if a rotating buffer was used > where the new data was place in the next spot and a counter (modulo the > buffer size) was incremented. But instead of incrementing the counter, > increment a state flag and have the program test this flag each time and > run code customized for that state (where things are in the buffer). That > would require more code but less code would run each time. Hummm You are referring to a circular buffer, right? Since I was checking only 3 cycles for now, I did this manually for now. A circular buffer would've taken more code space, which I was trying to squeeze to stay within the first 2k code page. But if I stretch this out to more cycles, I will probably have to convert to this. Cheers, -Neil.

On Tue, 14 Jun 2005, PicDude wrote: > Got a problem here with a PIC application where the lowest (rightmost) digit > of a numerical value is "toggling" back and forth between 2 (consecutive) > values rapidly -- example it will jump back and forth between 283 and 284 > rapidly (like 3-4 times a second, which is the update rate on the display). > better way -- is there? Not really. This problem is inherent with noise on A/D converters. You did a low pass filter with an override rule. It will solve the problem only for high frequency noise, as you seem to have. What you can do is take each two consecutive values and average them. This yields one extra bit of precision (at half the ad rate). The extra bit will 'toggle' as above but at half the speed. This is a basic low pass filter. You can extend this as you did to three or more samples. It depends on the type of noise you have. Overriding the low pass filter is not necessarily a good idea. For example if the signal is then used in a pid loop the 'extra' rule of changing the output immediately if it changes by more than 1 count is equivalent with extra (nonlinear) D gain in the pid loop. Then if you adjust the loop for correct coefficients for fast change it will have too low D for small changes and precision will not be good near the setpoint. taintstafl. The fix consists in allowing the noise into the pid and setting a deadband at the *output* of the pid in this case. Peter

At 09:30 PM 6/14/2005 +0300, you wrote: >On Tue, 14 Jun 2005, Spehro Pefhany wrote: > >>How about not updating the display unless the difference from the displayed >>value is > x, (and set x = 1) ? > >In that case, how do you adjust the value precisely (assume it has to be >adjusted to the nearest LSB with a screwdriver and a trimmer, the display >shows 125 and you need to adjust 126). Exercise in frustration ? Yes, indeed, unless you have a bypass for calibration. >Low pass filtering is the only viable solution. A display should not >change more than 4 times per second if someone is to make sense of it >anyway, slower for most physical values. Usually you can low pass enough >to achieve this since ad frame rate is often hundreds of times faster than >this. Low pass with 8 or more steps is usually drastic enough. > >Peter Depends. I've has some applications where a simple LPF would never do the trick. Large process variable variation (due to constraints on the actuator) and excessively fine display resolution (customer imposed constraint) and an integrating process. >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

PicDude wrote: {Quote hidden}> On Tuesday 14 June 2005 11:29 am, Scott Dattalo scribbled: > >>Neil, >> >>Here's a 2-sample hysteresis filter: >> >> current_sample = filtered_data(); >> >> if ( (current_sample == last_sample) || >> (abs(current_sample - displayed_sample) > THRESHOLD)) >> displayed_sample = current_sample; >> >> last_sample = current_sample; >> >>This cuts the flicker rate in half. To reduce it more, you can increase >>the number of required consecutive samples from 2 to N and save the last >>N-1 samples in an array. > > > > That's pretty much what I'm doing now (except in assembly), except that it > seems in this case, a change of <= THRESHOLD which never get updated on the > display no matter how long that value holds. 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

At 11:02 AM 6/14/2005 -0500, you wrote: >If by "nonlinear", you mean that K would vary depending on the amount of the >change, then that sounds awesome here on paper. Is there a recommendation on >how to do this and derive decent initial values of K? Or am I way off track >here? No, you're not off track. You could take the reading (with minimal LPF) and compare it to the displayed variable. If the difference exceeds a threshold you preload the variable (essentially set K = 0). That way you can tolerate a very long filter time constant because it only affects the last few counts. You could try more levels than just two but it might not be necessary. As Olin points out, it's possible with any of the "non-sticky" schemes that the variable sits on the edge of a threshold long term and flickers back and forth. You can make that less likely, but it's still probably possible. If you added a smidge of stickiness you could eliminate even that, but that adds some complexity. For example, suppose for the moment you have the number y = x * 10 available and are going to display d, to approximate x /10; (d is the previous display variable). y += ((y-10*d)> 5) ? -2:+2; d = y/10; Will give you just a whisper of stickyness. Probably enough to be irritating if you're using pots to calibrate the old-fashioned and time-tested way. ;-) If you're doing calibration in EEPROM, of course, you just use the original value of y. Of course you'd probably prefer to do this in powers of two and maybe in assembly, the C code and base-10 is just for pedagogic piclist purposes. >Another thought that this brings up is that I might try changing the >*rate* of >display updates based on the amount of the change. The lower the change, the >longer the display holds before changing. This might be easy-ish to >implement by adding successive change amounts and allowing the display to >change only after the total reaches a certain value. I'll have to think >about this more. Might be the equivalent of some other schemes that have been discussed. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

PicDude wrote: >> So how fast are you updating the display? > > IIRC about 4-5 times a second. Why so fast? It takes a certain amount of time to see a bunch of blinky lights, recognize them as a number, comprehend that number, then do something with the information. If you go too fast, you annoy people that the number changed before they had fully internalized the previous one. I think 5Hz is probably over that limit or at least near it. Take a look at a normal digital voltmeter. I think you'll find the update rate is more like 2-3Hz. I'm sure Fluke and other put some thought into this. Why not just do what they did? If your display bounced between adjacent numbers every 500mS, I doubt it would be all that annoying. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Tuesday 14 June 2005 01:58 pm, Scott Dattalo scribbled: {Quote hidden}> 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.

On Tuesday 14 June 2005 02:27 pm, Spehro Pefhany scribbled: > No, you're not off track. You could take the reading (with minimal LPF) and > compare it to the displayed variable. If the difference exceeds a threshold > you preload the variable (essentially set K = 0). That way you can tolerate > a very long filter time constant because it only affects the last few > counts. You could try more levels than just two but it might not be > necessary. > > As Olin points out, it's possible with any of the "non-sticky" schemes that > the variable sits on the edge of a threshold long term and flickers back > and forth. You can make that less likely, but it's still probably possible. Exactamundo. And I am still noticing this. > If you added a smidge of stickiness you could eliminate even that, but that > adds some complexity. For example, suppose for the moment you have the > number y = x * 10 available and are going to display d, to approximate x > /10; (d is the previous display variable). > > y += ((y-10*d)> 5) ? -2:+2; > d = y/10; > Maybe it's late, I'm hungry, or both, but I can't get a clear picture of the result of this in my head. I need to plot some values on paper and track this.... after dinner though. > Will give you just a whisper of stickyness. Probably enough to be > irritating if you're using pots to calibrate the old-fashioned and > time-tested way. ;-) If you're doing calibration in EEPROM, of course, you > just use the original value of y. No pots here. > Of course you'd probably prefer to do this in powers of two and maybe in > assembly, > the C code and base-10 is just for pedagogic piclist purposes. Gotcha. Cheers, -Neil.

On Tuesday 14 June 2005 04:21 pm, Olin Lathrop scribbled: > PicDude wrote: > >> So how fast are you updating the display? > > > > IIRC about 4-5 times a second. > First a correction. Since posting that, I measured it and it seems to be about 3.5-4 times per second. > Why so fast? It takes a certain amount of time to see a bunch of blinky > lights, recognize them as a number, comprehend that number, then do > something with the information. If you go too fast, you annoy people that > the number changed before they had fully internalized the previous one. I > think 5Hz is probably over that limit or at least near it. Take a look at > a normal digital voltmeter. I think you'll find the update rate is more > like 2-3Hz. I'm sure Fluke and other put some thought into this. Why not > just do what they did? If your display bounced between adjacent numbers > every 500mS, I doubt it would be all that annoying. Yes and no. The display output goes to both a numerical output and a bargraph (24 leds). The bargraph output looks really sluggish if slowed down more, but you're correct that the numerical output gets jumpy. So far though, with the filtering, the numerical output is not that bad/annoying for quick changes when it is following a trend and going towards one direction. But the digit toggling is a royal pain. I can probably guess what you are thinking now, and I have been fearing doing that -- ie: using independent IIR filters for the bargraph and numerical outputs. :-( Cheers, -Neil.

On Tuesday 14 June 2005 08:36 pm, Spehro Pefhany scribbled: > At 07:43 PM 6/14/2005 -0500, you wrote: > >I can probably guess what you are thinking now, and I have been fearing > > doing that -- ie: using independent IIR filters for the bargraph and > > numerical outputs. :-( > > Do it. ;-) Isn't that the words of the great philisopher Nike?... Just do it. I'm looking at that code again, and it's a can of worms to do that, mostly because of a lot of required mods to move into another 2k code page. But I guess I'll have to do this sometime. > Typical DMMs with bar-graph displays do maybe 3 measurements/second on the > digital display and 20 per second on the bar-graph. I have a raw version of a similar app with no filtering whatsoever -- none in hardware, none in software. But it is bargraph only. The display updates so fast that it's not at all annoying -- it's a smooth transition from one stage to the next with the effect of the topmost LED fading on/off during the transition. Cheers, -Neil.,

PicDude wrote: > Yes and no. The display output goes to both a numerical output and a > bargraph (24 leds). The bargraph output looks really sluggish if > slowed down more, but you're correct that the numerical output gets > jumpy. So far though, with the filtering, the numerical output is not > that bad/annoying for quick changes when it is following a trend and > going towards one direction. But the digit toggling is a royal pain. > > I can probably guess what you are thinking now, and I have been fearing > doing that -- ie: using independent IIR filters for the bargraph and > numerical outputs. :-( That's exactly what I was thinking when reading your first paragraph. What's the big deal though unless you are using an overly complex IIR filter? Use maybe a two pole filter with maybe 10Hz rolloff on each pole for the bar graph, then add another pole or two at 1-2Hz for the numeric display and update that twice per second or maybe a little faster. There is nothing complicated here. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

PicDude wrote: > I'm > looking at that code again, and it's a can of worms to do that, mostly > because of a lot of required mods to move into another 2k code page. You probably won't like hearing this, but shame on you. If you had written the code properly in the first place, this wouldn't even be noticeable. Maybe now you're ready to see the light and write code so that none of this matters in the future. It may sound like a lot of work now, but frankly anything that fits in 2K code space isn't that big a deal. After all, we're only talking about 2000 instructions. Take a look at my PIC development environment at http://www.embedinc.com/pic. The GCALL, GJUMP, GLBSUB, and related macros make it easy to write code so that modules can be arbitrarily assigned different pages. There's also a lot of other good stuff in there that may look like a silly hassle at first, but will save you a lot of trouble in the long run. Take the time now to do things right, and in a month from now you won't understand how you ever tolerated writing code the old way before. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

I was referring to when treating data as switches and bits change other than the ones you are watching. But you not doing that, so "never mind". So that problem does not exist, but the solution still has value. With the >1 test, you will not see any wiggle in the data nor will you see a single step of 1. A routine that insures that the data display is refreshed with new data at least every so often would overcome theses concerns.. Also if the display device is external then this would insure that if it lost it little bitty mind, it would get back on the right track again. As you increase the complexity of your test, there may be introduced a bug where the new data does not pass the test even though you expected it to pass and update the data display. You could also add code to check for such a software error and log it. This would help in ensuring such a bug did not exist. Now the fun part. If you have a spare LED, you could pulse it each time the data wiggled. Or two LED's with one pulsed for positive wiggles and the other for negative wiggles. Or even a two tone LED with red for a wiggle, green for a swigged and yellow for "shimmy like my sister Kate". Bill . {Original Message removed}

Or move to the 18F.....no paging issues...... Olin Lathrop <KILLspamolin_piclistKILLspamembedinc.com> wrote:PicDude wrote: > I'm > looking at that code again, and it's a can of worms to do that, mostly > because of a lot of required mods to move into another 2k code page. You probably won't like hearing this, but shame on you. If you had written the code properly in the first place, this wouldn't even be noticeable. Maybe now you're ready to see the light and write code so that none of this matters in the future. It may sound like a lot of work now, but frankly anything that fits in 2K code space isn't that big a deal. After all, we're only talking about 2000 instructions. Take a look at my PIC development environment at http://www.embedinc.com/pic. The GCALL, GJUMP, GLBSUB, and related macros make it easy to write code so that modules can be arbitrarily assigned different pages. There's also a lot of other good stuff in there that may look like a silly hassle at first, but will save you a lot of trouble in the long run. Take the time now to do things right, and in a month from now you won't understand how you ever tolerated writing code the old way before. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Tue, 2005-06-14 at 19:34 -0500, PicDude wrote: <snipped trivial example illustrating the hysteresis algorithm> > 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. Part of the issue here is that you have conflicting goals: on the one hand you want to update your display if the data changes but on the other you don't want to update the display if the data changes. Filters are good at discriminating between the two goals as long as the two can be differentiated. And I think you're finding that for each filter you've tried, there are either side effects or ways to spoof it! I tried to answer your specific question about hysteresis filters. Other have suggested different ways to approach the problem. Here are a couple of more approaches you may wish to consider: - Median + Low pass Collect the last N raw samples into a sorted array. Low-pass filter the array by ignoring the extremes. E.g. If you have 5 sorted samples, throw away the high and low and average the remaining 3. - Increased dynamic range The internal representation of the displayed data can have a higher dynamic range then the displayed data. In general, you'll want at least LOG2(FIR taps) more bits. E.g. if your FIR filter is 4 taps then maintaining an extra 2 bits on the filtered output is useful. (Note that LOG2 is only an estimate, a more precise relationship for an averaging filter is sqrt(number of samples).) The benefits of increased dynamic range is that it can give you more precise control of your thresholding and can minimize quantization errors. > 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). This is off the top of my head, for the midrange family: absoluteDifference_14bitcore: movf var1,W subwf var2,W ; W = var2 - var1 skpnc ; If result is non-negative C=1 goto ad14_done xorlw 0xff ; 2's complement of W. Note you'll pass addlw 0x01 ; through here if var1==var2, but the 2's ; complement of 0 is 0. ad14_done: And for the 18F family: absoluteDifference_16bitcore: movf var1,W ; subwf var2,W ; WREG = var2-var1 bnn ad16_done negf WREG,F I'm not sure if these can be classified as neat or not... Scott

Sure, but it wasn't even relevant in the first place -- the project was based on a working PIC16F872 app and used about 1.1k of it's 2k code space. There was no chance of that ever needing more. There was also another piece of code running on a 16F627, and I integrated both into 1 PIC16F874 last week. The port was a very simple matter of changing constants that pointed to specific pins and ports. Perhaps you'll say that it should've been made multi-page compliant when I ported it, but that's where I'm at now. Cheers, -Neil. On Wednesday 15 June 2005 07:17 am, Olin Lathrop scribbled: {Quote hidden}> PicDude wrote: > > I'm > > looking at that code again, and it's a can of worms to do that, mostly > > because of a lot of required mods to move into another 2k code page. > > You probably won't like hearing this, but shame on you. If you had written > the code properly in the first place, this wouldn't even be noticeable. > Maybe now you're ready to see the light and write code so that none of this > matters in the future. It may sound like a lot of work now, but frankly > anything that fits in 2K code space isn't that big a deal. After all, > we're only talking about 2000 instructions. > > Take a look at my PIC development environment at > http://www.embedinc.com/pic. The GCALL, GJUMP, GLBSUB, and related macros > make it easy to write code so that modules can be arbitrarily assigned > different pages. There's also a lot of other good stuff in there that may > look like a silly hassle at first, but will save you a lot of trouble in > the long run. Take the time now to do things right, and in a month from > now you won't understand how you ever tolerated writing code the old way > before. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com

On Wednesday 15 June 2005 06:56 am, Olin Lathrop scribbled: > > I can probably guess what you are thinking now, and I have been fearing > > doing that -- ie: using independent IIR filters for the bargraph and > > numerical outputs. :-( > > That's exactly what I was thinking when reading your first paragraph. > What's the big deal though unless you are using an overly complex IIR > filter? Use maybe a two pole filter with maybe 10Hz rolloff on each pole > for the bar graph, then add another pole or two at 1-2Hz for the numeric > display and update that twice per second or maybe a little faster. There > is nothing complicated here. And I have now done this over the past couple days -- the bargraph has a different display update rate than the numerical digits (bargraph is 4 times faster), and each has it's own IIR filter factor. I set up the filter factors to be independently adjustable from 0 to 7/8 in 1/8 increments, when the app is in operation (ie: without re-programming). I also extended the LSD toggling routine (as I previously described) to check back to the last 4 samples. I need to get it in operation and experiment with the IIR factors. I've looked a bit into non-linear IIR filters, but could not find much. But some thinking on a whiteboard has me believing that I might get much improved results with as simple a scheme as having one threshold for the absolute amount of the change and above/below that would each have a separate IIR-filter factor. Pretty much... if (abs(new_sample - last_result) > threshold) then k = larger_value else k = smaller_value call IIR_routine I need to experiment with this to see if it really will work as I think it should, without having to go to a more proper non-linear system where IIR factor varys thru multiple values over multiple change levels. Cheers, -Neil.

PicDude wrote: >>> it's a can of worms to do that, mostly >>> because of a lot of required mods to move into another 2k code page. >> >> You probably won't like hearing this, but shame on you. If you had >> written the code properly in the first place, this wouldn't even be >> noticeable. > > Sure, but it wasn't even relevant in the first place -- the project was > based on a working PIC16F872 app and used about 1.1k of it's 2k code > space. There was no chance of that ever needing more. But that's the point. Clearly not, else we wouldn't be having this discussion. Part of good software engineering is realizing that many pieces of code can and probably will have a life well beyond the immediate intended use. Writing 16F PIC code so that it can run accross the family is very easy. As I said before, fortunately you've only got code for at most 2000 instructions to clean up. This shouldn't take long. Then you can move forward and write code that can be move from one 16F PIC to another with few or no changes. The good news is that you bumped into this issue while you only had a trivial amount of legacy code. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com