DC offset removal through FPGA
in [DSP]
|
Prev: SHARC debug
Next: Who Invented the Z Transform
From: Jon Harris on 27 Jun 2005 13:30 "Steve Underwood" <steveu(a)dis.org> wrote in message news:d9mjai$hbr$1(a)nnews.pacific.net.hk... > Jerry Avins wrote: > > Steve Underwood wrote: > >>> > >>> > >>> but Steve, if it's a continuous running real-time system, how do you > >>> continuously estimate DC? only way i know is with a LPF. then when you > >>> take the "DC" output of the LPF and subtract it from the input > >>> signal, what > >>> functionally have is an HPF. > >>> > >>> now there are many different HPFs with different orders and cutoff > >>> frequencies and filter shape, etc. but essentially, when you do DC > >>> blocking, you're doing HPFing. > >>> > >> Sure. A low pass filter and subtraction gives a high pass filter. > >> However, when someone says use a high pass filter, and the previous > >> post talked about subtracting a DC estimate, I rather think they mean > >> a direct HPF implementation. > > > > > > Why is direct superior to going around the other side of the barn? If > > the final result is the same, the simplest approach is usually to be > > preferred. Are there hidden assumptions we don't share? > > I don't follow you. Going around the other side of the barn is the > better and simpler solution here. You estimate the DC with a cheapo > single pole IIR, which can be easily shaped, implemented without a > single multiply, and inserts no delay. A directly implemented high pass > would be maybe a massive FIR, or a bunch of bi-quads with horrible > things happening in the dynamics of the numbers. Why couldn't the directly implemented high pass be just a single pole IIR as well? As Robert has pointed out, doing that is mathematically equivalent to using a LP with the same cut-off and subtracting it.
From: Jerry Avins on 27 Jun 2005 15:11 Dave Coffey wrote: > > Jerry Avins wrote: > >>Ouch! You want to discard the lower bits of the sum, but not of the >>addends. For some purposes, it's even a good idea to save the >>"discarded" bits (including sign) and add them to the next computed >>average before truncating. It depends on which errors you want to minimize. > > Hi Jerry, > That wasn't entirely the case. I suggested that the latch feeding > the DAC be aligned to discard bits, not the actual accumulator itself. > Guess I should have been more explicit. Dave, I got your point. However the bits are discarded -- your alignment idea is elegant, even if old hat in some circles -- the information they carried is lost. Add them to the accumulator. They may cause carries where zeros would not, and if they almost do, the retained remainder may help to do it next time. Those low bits carry useful information. Discarding them is worse than truncating. Using them (and keeping them by saving the remainder) adds significant precision. A similar technique in IIR filters can avoid limit cycling. Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý
From: Jerry Avins on 27 Jun 2005 15:12 ytregubov(a)yahoo.com wrote: > I've mentioned LPF mostly because such signal filtering is a GENERIC > thing and many signal processing tricks are in fact DFs. > > Kind russian regards, > Yuri DF? Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý
From: ytregubov on 28 Jun 2005 09:11 Jerry, >DF ? digital filter Yuri
From: Jerry Avins on 28 Jun 2005 11:39
ytregubov(a)yahoo.com wrote: > Jerry, > > >>DF ? > > digital filter > > Yuri Thank you. Damn Fool -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý |