> I found the two stage filter to be too fast for my application so I added 6 > more > stages (cascaded). The responsetime is approx 1 sec now, still way too fast > ! > As I add more and more stages I notice the responsetime gets a little > longer for > each stage. Wonder if that is because the mainloop gets bigger or its due > to the > filter gets more stages... hmm... I'd expect the responsetime to increase > very much > with so many stages. The response times for each pole do not add linearly. A two pole filter has considerably less than twice the response time of a one pole filter, assuming all poles at the same frequency. The two pole low pass filter I suggested was for converting the stream of 1 bit values into a nice and smooth 8 bit averaged value. The purpose of this filter was not to deliberately slow the response, although these types of filters can be used for that. I would leave the original two pole filter alone. This provides you with a nice and smooth tank level. If you want to make a value with slower response, use a timer to run that value thru an additional one or two pole filter at regular intervals. An additional two poles will give you a 50% step response time of about 425 iterations. If you do one of these every 10mS, then the 50% response time will be 4.25 seconds and the 90% response time about 10 seconds. Note that as long as you are sampling the bit stream fast enough, the ultimate response time will be decoupled from the sampling rate and will only be a function of how often the last two filter poles are updated. This all being said, you may want to re-evaluate why you want a slowed tank level. It is probably better to adjust the response of the control algorithm than to artificially introduce lag into the measured tank level. In fact, the latter can lead to control instability. Simply damping the control response actually increases stability. > As u can see I use a new variable for each stage, is that really necessary Yes. Each filter pole requires its own state. > All my attemts to use a sub or just re-use the same variables seems to make > the filter response faster than if using many variables! That makes sense. If each filter pole doesn't have its own private state, then it isn't really a filter pole and therefore won't add the expected delay. In short, don't do that. > I also need slower decay when the sensor reads 0, and not as now symetrical > responstime. The fill-up-time is 2-4 sec, but the time until empty is 20-30 > secs. I still don't believe this. As I said above, this is something to address in the control algorithm, and not by cooking the measurements. > With a simple box filter I could put more 'weight' on the 1:s by adding 2 > or 3 > to the filter for each 1 that is read. That would yield a faster response > for 1 and > keep same response for the 0 level. Cant really see howto do that using a > cascaded single pole filter. You weren't really getting what you think there. All you were doing was multiplying the overall result by a constant. The resulting shift in the 1/2 full level gave you the appearance of different time constants up and down when in fact they were really the same. Do the math. > My implementation: > > FILTER_A ; new = old - old/256 + input/256 > ; *** FILTER: STEG 1 > ; > ; Subtract from FILT1 > ; > movf FilterA1H, W ;get FILT1/255 > subwf FilterA1L, F ;make the new low byte > btfss STATUS, C ;no borrow from high byte ? > decf FilterA1H, F ;propagate the borrow > ; > ; Add to the filter > ; > btfss sample, plutt ;the input bit is 1 ? > goto done_inbitA ;input bit is 0, skip this section > movlw h'FF' ;get value implied by input bit / 256 > addwf FilterA1L, F ;make new low byte > btfsc STATUS, C ;no carry to high byte ? > incf FilterA1H, F ;propagate the carry > done_inbitA ;done dealing with input bit contribution > > > ; *** FILTER: STEG 2 > ; > ; Subtract from FILT2 > ; > movf FilterA2H, W ; get > subwf FilterA2L, F ; make the new low byte > btfss STATUS, C ; need to borrow from high byte ? > decf FilterA2H, F ; yes, propagate the borrow > ; > ; Add to the filter > ; > movf FilterA1H, W ;get FILT1/256 > addwf FilterA2L, F ;make new low byte > btfsc STATUS, C ;no carry to high byte ? > incf FilterA2H, F ;propagate the carry Yes, this is what I meant. Looks good. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, olin@embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu