DC offset removal through FPGA
in [DSP]
|
Prev: SHARC debug
Next: Who Invented the Z Transform
From: Jerry Avins on 26 Jun 2005 09:55 Steve Underwood wrote: > robert bristow-johnson wrote: > >> in article d9eedv$lt1$1(a)nnews.pacific.net.hk, Steve Underwood at >> steveu(a)dis.org wrote on 06/23/2005 09:39: >> >> >>> ytregubov(a)yahoo.com wrote: >>> >>>> Use highpass filter. >>>> >>>> Regards, >>>> Yuri >>>> >>> >>> That's a really bad idea. A filter cutting off very low in the band is >>> not nice. Estimating the DC and subtracting it is the right approach. >> >> >> >> 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? Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý
From: Jerry Avins on 26 Jun 2005 10:07 Matt Timmermans wrote: > "robert bristow-johnson" <rbj(a)audioimagination.com> wrote in message > news:BEE0C183.8824%rbj(a)audioimagination.com... > >>so now i beg the question: so what? what's the difference? > > > It's the difference between a stop-band and a notch. What _is_ the difference between a notch and a stop-band; width? How do you measure percentage bandwidth at DC? Philosophy aside, what difference does it make to an effective implementation? Recall that the OP thought about using an FPGA to measure the "DC", generate an analog signal equal to it, and a summer to subtract that from the input of the ADC. He needs more help than mere philosophy. However it's described or achieved, he needs a simple implementation of a transfer function with one or more zeros at f=0. Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý
From: Jerry Avins on 26 Jun 2005 10:12 Dave Coffey wrote: > > shridhar(a)mistralsoftware.com wrote: > >>Hi, > > > One trick you could try would be to perform > your accumulation over a power of two number > of samples (e.g. 64, 128, etc). > > This would obviate the need for multiplication > since division by powers of two can be accomplished > by bit shifting to the right. Without having to use > a barrel shifter, you could for instance align the > read latch for your subtraction register such that > it's lsb is aligned with the Kth bit of the accumulator. > > For example,if you wanted to remove the running average of 64 > samples you simply align the latch with bit 7 > (assuming bit zero is the LSB) of your accumulator > thus discarding the lower 6 bits. 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. > Be careful, for instance if you are using a bipolar ADC, > that you do not neglect to implement the correct sign > extension logic and two's complement arithmetic. > > That said, you can work wonders with a simple CR filter > for DC removal though if the board is already fabricated > and your only 'free parameter' is the FPGA it may not be an option. Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý
From: Steve Underwood on 26 Jun 2005 11:58 Jerry Avins wrote: > Steve Underwood wrote: > >> robert bristow-johnson wrote: >> >>> in article d9eedv$lt1$1(a)nnews.pacific.net.hk, Steve Underwood at >>> steveu(a)dis.org wrote on 06/23/2005 09:39: >>> >>> >>>> ytregubov(a)yahoo.com wrote: >>>> >>>>> Use highpass filter. >>>>> >>>>> Regards, >>>>> Yuri >>>>> >>>> >>>> That's a really bad idea. A filter cutting off very low in the band is >>>> not nice. Estimating the DC and subtracting it is the right approach. >>> >>> >>> >>> >>> 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. The DC estimate you use in this case is based on lots of history and no future. In some cases, where conditions sometime hop, a windowed approach, balanced around the sample of interest, can be better. This can also be a pretty low compute solution, but does incur substantial delay. The simple shaped running IIR kills 99% of all known household DC offset problems. :-) ** Regards, Steve ** I always wondered why killing 99% of household germs was supposed to be good, when the remaining 1% are presumably the really tough guys. :-)
From: Jerry Avins on 26 Jun 2005 12:51
Steve Underwood wrote: > Jerry Avins wrote: > >> Steve Underwood wrote: >> >>> robert bristow-johnson wrote: >>> >>>> in article d9eedv$lt1$1(a)nnews.pacific.net.hk, Steve Underwood at >>>> steveu(a)dis.org wrote on 06/23/2005 09:39: >>>> >>>> >>>>> ytregubov(a)yahoo.com wrote: >>>>> >>>>>> Use highpass filter. >>>>>> >>>>>> Regards, >>>>>> Yuri >>>>>> >>>>> >>>>> That's a really bad idea. A filter cutting off very low in the band is >>>>> not nice. Estimating the DC and subtracting it is the right approach. >>>> >>>> >>>> >>>> >>>> >>>> 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. We're making different assumptions and I used a loose description. Subtracting a DC estimate _is_ a high-pass filter, and can be a very good one, especially with what I call "remainder saving" that avoids drift due to rounding. Computing DC offset with an FPGA, generating a voltage from the result, and subtracting it from the ADC input is "going around the barn". Even that mat be justified by large applied offsets that could overload the ADC. > The DC estimate you use in this case is based on lots of history and no > future. Necessary for any causal filter. What did you mean to convey by mentioning it? > In some cases, where conditions sometime hop, a windowed > approach, balanced around the sample of interest, can be better. This > can also be a pretty low compute solution, but does incur substantial > delay. I think I see now. Just a matter of viewpoint. > The simple shaped running IIR kills 99% of all known household DC offset > problems. :-) ** ... > ** I always wondered why killing 99% of household germs was supposed to > be good, when the remaining 1% are presumably the really tough guys. :-) Not only isn't it good, it's very harmful. Most of those bacteria protect us from serious infection. When we remove them, the baddies flourish. The process of removing them also strengthens the baddies. It's a lose-lose attack on the problem. (Without bacteria, having no cheese would be the least of our problems.) Jerry -- Engineering is the art of making what you want from things you can get. ýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý |