Electronics-Related.com
Forums

Removing DC offset from ADC Buffer

Started by Gold_Spark September 20, 2020
On Wed, 23 Sep 2020 19:44:05 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>On 2020-09-23 18:56, Lasse Langwadt Christensen wrote: >> torsdag den 24. september 2020 kl. 00.36.18 UTC+2 skrev Phil Hobbs: >>> On 2020-09-23 18:19, Lasse Langwadt Christensen wrote: >>>> onsdag den 23. september 2020 kl. 23.58.40 UTC+2 skrev Phil Hobbs: >>>>> On 2020-09-22 13:35, Lasse Langwadt Christensen wrote: >>>>>> tirsdag den 22. september 2020 kl. 03.47.59 UTC+2 skrev Phil Hobbs: >>>>>>> On 2020-09-21 21:32, Lasse Langwadt Christensen wrote: >>>>>>>> tirsdag den 22. september 2020 kl. 02.47.37 UTC+2 skrev Phil Hobbs: >>>>>>>>> On 2020-09-21 00:06, Jasen Betts wrote: >>>>>>>>>> On 2020-09-21, jlarkin@highlandsniptechnology.com >>>>>>>>>> <jlarkin@highlandsniptechnology.com> wrote: >>>>>>>>>>> On Sun, 20 Sep 2020 16:29:30 -0700 (PDT), whit3rd >>>>>>>>>>> <whit3rd@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Sunday, September 20, 2020 at 2:01:05 PM UTC-7, >>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>> On Sun, 20 Sep 2020 13:33:11 -0700 (PDT), whit3rd >>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sunday, September 20, 2020 at 3:26:13 AM UTC-7, >>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>> On Sun, 20 Sep 2020 00:26:47 -0700 (PDT), whit3rd >>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>>> On Saturday, September 19, 2020 at 9:49:47 PM UTC-7, >>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Just average the samples and subtract that average from >>>>>>>>>>>>>>>>> each new sample. There are several ways to do that >>>>>>>>>>>>>>>>> average: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sum the last N samples and divide by N. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that's a FIR filter (finite impulse response) ... if you >>>>>>>>>>>>>>>> choose the sample size and know the likely interference >>>>>>>>>>>>>>>> sources (like, 60 Hz ripple), it allows you to place a >>>>>>>>>>>>>>>> null appropriately >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Exponential smoothing: Avg = Avg + (new-Avg) / N >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that's a IIR filter (infinite impulse response); usually >>>>>>>>>>>>>>>> not a great choice >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why not? I see a lot of irrational prejuduce against simple >>>>>>>>>>>>>>> IIR filters, in code and in FPGAs. Some people would rather >>>>>>>>>>>>>>> write a hundred lines of code instead of one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oh, it's simple, all right, but it has a long startup >>>>>>>>>>>>>> transient. >>>>>>>>>>>>> Any lowpass filter or averager does. Just poke a starting value >>>>>>>>>>>>> into the integrator node if you're in a hurry, ADC midscale in >>>>>>>>>>>>> this case. >>>>>>>>>>>> >>>>>>>>>>>> A lowpass needn't be considered appropriate during startup (and >>>>>>>>>>>> brute-force setting a starting value helps). FIR has a >>>>>>>>>>>> time-limit on its history, which is often completely appropriate >>>>>>>>>>>> and useful. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> That means it doesn't deal with lightning-strike artifacts >>>>>>>>>>>>>> well, either. >>>>>>>>>>>>> Presumably an ADC rails on a huge transient. Why would an IIR >>>>>>>>>>>>> filter be worse than a FIR for a spike? >>>>>>>>>>>> >>>>>>>>>>>> Small signal in big digitizer range, of course. Your 'rails' >>>>>>>>>>>> scenario is a measurement failure, and there's multiple ways to >>>>>>>>>>>> treat such a thing, which FIR does by... ignoring the spike a few >>>>>>>>>>>> samples afterward. IIR doesn't do that, so saturating the >>>>>>>>>>>> digitizer is an alternate solution that you don't seem to >>>>>>>>>>>> dislike. >>>>>>>>>>>> >>>>>>>>>>>>> It's impressive... >>>>>>>>>>>> >>>>>>>>>>>> I'm pleased that my response impresses you. >>>>>>>>>>>> >>>>>>>>>>>>> how many convoluted arguments people make to avoid IIR digital >>>>>>>>>>>>> filters. Most of them reduce to "It's too simple and I don't >>>>>>>>>>>>> like it." >>>>>>>>>>>> >>>>>>>>>>>> But not any that I mentioned; what ARE those other "convoluted >>>>>>>>>>>> arguments"? I'd like to judge their merits for myself... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was just thinking how crazy it woud be to use, say, a 5000-tap >>>>>>>>>>> FIR filter to compute a good autozero average value of the last >>>>>>>>>>> 5000 samples. >>>>>>>>>>> >>>>>>>>>>> Those 5000 multiply-by-1-and-add blocks will need a lot of logic. >>>>>>>>>> >>>>>>>>>> Clearly not the best way to make a boxcar filter... LOL. I see what >>>>>>>>>> you did there. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You still need a bunch of memory, because on each cycle you have to add >>>>>>>>> the new sample and subtract the one from 5000 cycles ago. IIR avoids >>>>>>>>> that problem. >>>>>>>>> >>>>>>>> >>>>>>>> https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter >>>>>>>> >>>>>>> >>>>>>> CICS is an IIR filter. >>>>>>> >>>>>> >>>>>> it is recursive but is it IIR? ;) >>>>>> >>>>> >>>>> IIRs don't _have_ to have infinitely-long impulse responses. >>>> >>>> it is in the the name >>>> >>>> IIR and recursive is not the same thing >>>> >>>> >>>> >>> Depends whom you ask. IIR (C) Oppenheim and Shafer don't use the term >>> "IIR" on account of the terminological confusion. >>> >>> Anyway, because your definition is inaccurate for any given filter. >>> Because of limited resolution even an "IIR" filter doesn't really have >>> an infinite impulse response even in theory, unless it exhibits a limit >>> cycle. A simple 1-pole rolloff such as >>> >>> y_N = 0.5 (x_N + y_N-1) >>> >>> is an 'IIR' if that means recursive, but at N bit precision it goes to >>> zero in at most N cycles after the input goes to 0. Even in IEEE quad >>> precision with denormals, which has a 15-bit exponent and 112-bit >>> significant, it'll go to zero after at most 64k + 112 cycles. >>> >> >> then it becomes more philosophical like what is zero Hz > >Nice try. The filter output goes to zero exponentially with time, vs. >frequency resolution increasing only linearly. > >Cheers > >Phil Hobbs
Depends on what the definition of IS is. :) As I undersand it, the recursiveness of an IIR filter topology is what would allow it to be "infinite". It the total recursive gains are less than 1.0 and the input stops, the output will stop. Kind of like the coronavirus
On Wed, 23 Sep 2020 16:24:27 -0700, John Larkin
<jlarkin@highland_atwork_technology.com> wrote:

>On Wed, 23 Sep 2020 15:13:30 -0700, John Larkin ><jlarkin@highland_atwork_technology.com> wrote: > >>On Wed, 23 Sep 2020 17:58:27 -0400, Phil Hobbs >><pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>>On 2020-09-22 13:35, Lasse Langwadt Christensen wrote: >>>> tirsdag den 22. september 2020 kl. 03.47.59 UTC+2 skrev Phil Hobbs: >>>>> On 2020-09-21 21:32, Lasse Langwadt Christensen wrote: >>>>>> tirsdag den 22. september 2020 kl. 02.47.37 UTC+2 skrev Phil Hobbs: >>>>>>> On 2020-09-21 00:06, Jasen Betts wrote: >>>>>>>> On 2020-09-21, jlarkin@highlandsniptechnology.com >>>>>>>> <jlarkin@highlandsniptechnology.com> wrote: >>>>>>>>> On Sun, 20 Sep 2020 16:29:30 -0700 (PDT), whit3rd >>>>>>>>> <whit3rd@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On Sunday, September 20, 2020 at 2:01:05 PM UTC-7, >>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>> On Sun, 20 Sep 2020 13:33:11 -0700 (PDT), whit3rd >>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Sunday, September 20, 2020 at 3:26:13 AM UTC-7, >>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>> On Sun, 20 Sep 2020 00:26:47 -0700 (PDT), whit3rd >>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>> On Saturday, September 19, 2020 at 9:49:47 PM UTC-7, >>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>> Just average the samples and subtract that average from >>>>>>>>>>>>>>> each new sample. There are several ways to do that >>>>>>>>>>>>>>> average: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sum the last N samples and divide by N. >>>>>>>>>>>>>> >>>>>>>>>>>>>> that's a FIR filter (finite impulse response) ... if you >>>>>>>>>>>>>> choose the sample size and know the likely interference >>>>>>>>>>>>>> sources (like, 60 Hz ripple), it allows you to place a >>>>>>>>>>>>>> null appropriately >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Exponential smoothing: Avg = Avg + (new-Avg) / N >>>>>>>>>>>>>> >>>>>>>>>>>>>> that's a IIR filter (infinite impulse response); usually >>>>>>>>>>>>>> not a great choice >>>>>>>>>>>> >>>>>>>>>>>>> Why not? I see a lot of irrational prejuduce against simple >>>>>>>>>>>>> IIR filters, in code and in FPGAs. Some people would rather >>>>>>>>>>>>> write a hundred lines of code instead of one. >>>>>>>>>>>> >>>>>>>>>>>> Oh, it's simple, all right, but it has a long startup >>>>>>>>>>>> transient. >>>>>>>>>>> Any lowpass filter or averager does. Just poke a starting value >>>>>>>>>>> into the integrator node if you're in a hurry, ADC midscale in >>>>>>>>>>> this case. >>>>>>>>>> >>>>>>>>>> A lowpass needn't be considered appropriate during startup (and >>>>>>>>>> brute-force setting a starting value helps). FIR has a >>>>>>>>>> time-limit on its history, which is often completely appropriate >>>>>>>>>> and useful. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> That means it doesn't deal with lightning-strike artifacts >>>>>>>>>>>> well, either. >>>>>>>>>>> Presumably an ADC rails on a huge transient. Why would an IIR >>>>>>>>>>> filter be worse than a FIR for a spike? >>>>>>>>>> >>>>>>>>>> Small signal in big digitizer range, of course. Your 'rails' >>>>>>>>>> scenario is a measurement failure, and there's multiple ways to >>>>>>>>>> treat such a thing, which FIR does by... ignoring the spike a few >>>>>>>>>> samples afterward. IIR doesn't do that, so saturating the >>>>>>>>>> digitizer is an alternate solution that you don't seem to >>>>>>>>>> dislike. >>>>>>>>>> >>>>>>>>>>> It's impressive... >>>>>>>>>> >>>>>>>>>> I'm pleased that my response impresses you. >>>>>>>>>> >>>>>>>>>>> how many convoluted arguments people make to avoid IIR digital >>>>>>>>>>> filters. Most of them reduce to "It's too simple and I don't >>>>>>>>>>> like it." >>>>>>>>>> >>>>>>>>>> But not any that I mentioned; what ARE those other "convoluted >>>>>>>>>> arguments"? I'd like to judge their merits for myself... >>>>>>>>> >>>>>>>>> >>>>>>>>> I was just thinking how crazy it woud be to use, say, a 5000-tap >>>>>>>>> FIR filter to compute a good autozero average value of the last >>>>>>>>> 5000 samples. >>>>>>>>> >>>>>>>>> Those 5000 multiply-by-1-and-add blocks will need a lot of logic. >>>>>>>> >>>>>>>> Clearly not the best way to make a boxcar filter... LOL. I see what >>>>>>>> you did there. >>>>>>>> >>>>>>> >>>>>>> You still need a bunch of memory, because on each cycle you have to add >>>>>>> the new sample and subtract the one from 5000 cycles ago. IIR avoids >>>>>>> that problem. >>>>>>> >>>>>> >>>>>> https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter >>>>>> >>>>> >>>>> CICS is an IIR filter. >>>>> >>>> >>>> it is recursive but is it IIR? ;) >>>> >>> >>>IIRs don't _have_ to have infinitely-long impulse responses. >> >>But, but, but, IIR means Infinite Impulse Response. >> >> And CICS >>>filters can have, if you start and end with an integrator. ;) >> >>I'm still perplexed by the sinc3 filter (commonly used for delta-sigma >>recovery) that is a string of integrators and differentiators. I of >>course wanted to use an IIR filter, but I'm just the boss so nobody >>listens to me. >> >>We have an isolated delta-sigma measuring a current shunt in our PM >>alternator simulator, and it feeds into a programmable impedance >>algorithm, so it's in a pretty hairy feedback loop. An FIR was easier >>to Spice. > >No, I meant IIR. > >I suppose that one could Spice a FIR filter from a lot of tapped delay >lines and some resistors.
I seem to remember that some of the first audio Delta-Sigma A/D converters used an FIR filter for a flat group delay.
On 2020-09-23 23:49, boB wrote:
> On Wed, 23 Sep 2020 19:44:05 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 2020-09-23 18:56, Lasse Langwadt Christensen wrote: >>> torsdag den 24. september 2020 kl. 00.36.18 UTC+2 skrev Phil Hobbs: >>>> On 2020-09-23 18:19, Lasse Langwadt Christensen wrote: >>>>> onsdag den 23. september 2020 kl. 23.58.40 UTC+2 skrev Phil Hobbs: >>>>>> On 2020-09-22 13:35, Lasse Langwadt Christensen wrote: >>>>>>> tirsdag den 22. september 2020 kl. 03.47.59 UTC+2 skrev Phil Hobbs: >>>>>>>> On 2020-09-21 21:32, Lasse Langwadt Christensen wrote: >>>>>>>>> tirsdag den 22. september 2020 kl. 02.47.37 UTC+2 skrev Phil Hobbs: >>>>>>>>>> On 2020-09-21 00:06, Jasen Betts wrote: >>>>>>>>>>> On 2020-09-21, jlarkin@highlandsniptechnology.com >>>>>>>>>>> <jlarkin@highlandsniptechnology.com> wrote: >>>>>>>>>>>> On Sun, 20 Sep 2020 16:29:30 -0700 (PDT), whit3rd >>>>>>>>>>>> <whit3rd@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Sunday, September 20, 2020 at 2:01:05 PM UTC-7, >>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>> On Sun, 20 Sep 2020 13:33:11 -0700 (PDT), whit3rd >>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sunday, September 20, 2020 at 3:26:13 AM UTC-7, >>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>> On Sun, 20 Sep 2020 00:26:47 -0700 (PDT), whit3rd >>>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>>>> On Saturday, September 19, 2020 at 9:49:47 PM UTC-7, >>>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just average the samples and subtract that average from >>>>>>>>>>>>>>>>>> each new sample. There are several ways to do that >>>>>>>>>>>>>>>>>> average: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sum the last N samples and divide by N. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> that's a FIR filter (finite impulse response) ... if you >>>>>>>>>>>>>>>>> choose the sample size and know the likely interference >>>>>>>>>>>>>>>>> sources (like, 60 Hz ripple), it allows you to place a >>>>>>>>>>>>>>>>> null appropriately >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Exponential smoothing: Avg = Avg + (new-Avg) / N >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> that's a IIR filter (infinite impulse response); usually >>>>>>>>>>>>>>>>> not a great choice >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why not? I see a lot of irrational prejuduce against simple >>>>>>>>>>>>>>>> IIR filters, in code and in FPGAs. Some people would rather >>>>>>>>>>>>>>>> write a hundred lines of code instead of one. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Oh, it's simple, all right, but it has a long startup >>>>>>>>>>>>>>> transient. >>>>>>>>>>>>>> Any lowpass filter or averager does. Just poke a starting value >>>>>>>>>>>>>> into the integrator node if you're in a hurry, ADC midscale in >>>>>>>>>>>>>> this case. >>>>>>>>>>>>> >>>>>>>>>>>>> A lowpass needn't be considered appropriate during startup (and >>>>>>>>>>>>> brute-force setting a starting value helps). FIR has a >>>>>>>>>>>>> time-limit on its history, which is often completely appropriate >>>>>>>>>>>>> and useful. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> That means it doesn't deal with lightning-strike artifacts >>>>>>>>>>>>>>> well, either. >>>>>>>>>>>>>> Presumably an ADC rails on a huge transient. Why would an IIR >>>>>>>>>>>>>> filter be worse than a FIR for a spike? >>>>>>>>>>>>> >>>>>>>>>>>>> Small signal in big digitizer range, of course. Your 'rails' >>>>>>>>>>>>> scenario is a measurement failure, and there's multiple ways to >>>>>>>>>>>>> treat such a thing, which FIR does by... ignoring the spike a few >>>>>>>>>>>>> samples afterward. IIR doesn't do that, so saturating the >>>>>>>>>>>>> digitizer is an alternate solution that you don't seem to >>>>>>>>>>>>> dislike. >>>>>>>>>>>>> >>>>>>>>>>>>>> It's impressive... >>>>>>>>>>>>> >>>>>>>>>>>>> I'm pleased that my response impresses you. >>>>>>>>>>>>> >>>>>>>>>>>>>> how many convoluted arguments people make to avoid IIR digital >>>>>>>>>>>>>> filters. Most of them reduce to "It's too simple and I don't >>>>>>>>>>>>>> like it." >>>>>>>>>>>>> >>>>>>>>>>>>> But not any that I mentioned; what ARE those other "convoluted >>>>>>>>>>>>> arguments"? I'd like to judge their merits for myself... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I was just thinking how crazy it woud be to use, say, a 5000-tap >>>>>>>>>>>> FIR filter to compute a good autozero average value of the last >>>>>>>>>>>> 5000 samples. >>>>>>>>>>>> >>>>>>>>>>>> Those 5000 multiply-by-1-and-add blocks will need a lot of logic. >>>>>>>>>>> >>>>>>>>>>> Clearly not the best way to make a boxcar filter... LOL. I see what >>>>>>>>>>> you did there. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You still need a bunch of memory, because on each cycle you have to add >>>>>>>>>> the new sample and subtract the one from 5000 cycles ago. IIR avoids >>>>>>>>>> that problem. >>>>>>>>>> >>>>>>>>> >>>>>>>>> https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter >>>>>>>>> >>>>>>>> >>>>>>>> CICS is an IIR filter. >>>>>>>> >>>>>>> >>>>>>> it is recursive but is it IIR? ;) >>>>>>> >>>>>> >>>>>> IIRs don't _have_ to have infinitely-long impulse responses. >>>>> >>>>> it is in the the name >>>>> >>>>> IIR and recursive is not the same thing >>>>> >>>>> >>>>> >>>> Depends whom you ask. IIR (C) Oppenheim and Shafer don't use the term >>>> "IIR" on account of the terminological confusion. >>>> >>>> Anyway, because your definition is inaccurate for any given filter. >>>> Because of limited resolution even an "IIR" filter doesn't really have >>>> an infinite impulse response even in theory, unless it exhibits a limit >>>> cycle. A simple 1-pole rolloff such as >>>> >>>> y_N = 0.5 (x_N + y_N-1) >>>> >>>> is an 'IIR' if that means recursive, but at N bit precision it goes to >>>> zero in at most N cycles after the input goes to 0. Even in IEEE quad >>>> precision with denormals, which has a 15-bit exponent and 112-bit >>>> significant, it'll go to zero after at most 64k + 112 cycles. >>>> >>> >>> then it becomes more philosophical like what is zero Hz >> >> Nice try. The filter output goes to zero exponentially with time, vs. >> frequency resolution increasing only linearly. >> >> Cheers >> >> Phil Hobbs > > > Depends on what the definition of IS is. :) > > As I undersand it, the recursiveness of an IIR filter topology is what > would allow it to be "infinite". It the total recursive gains are > less than 1.0 and the input stops, the output will stop. > > Kind of like the coronavirus
Hopefully not--lots of recursive filters have limit cycles, so the output never goes away. That's probably the reason for their bad reputation in some circles. Or maybe it's the likelihood of overflow of intermediate results, much like railing and slew limiting in poorly-designed active continuous-time filters. A simple example of an IIR filter with a limit cycle is another one-pole lowpass implemented in integers, which can get stuck at a nonzero DC output if the decrement per cycle is less than 0.5. More complicated filters can exhibit AC limit cycles. (Of course a limit cycle isn't an impulse response either.) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On Thu, 24 Sep 2020 00:35:02 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>On 2020-09-23 23:49, boB wrote: >> On Wed, 23 Sep 2020 19:44:05 -0400, Phil Hobbs >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>> On 2020-09-23 18:56, Lasse Langwadt Christensen wrote: >>>> torsdag den 24. september 2020 kl. 00.36.18 UTC+2 skrev Phil Hobbs: >>>>> On 2020-09-23 18:19, Lasse Langwadt Christensen wrote: >>>>>> onsdag den 23. september 2020 kl. 23.58.40 UTC+2 skrev Phil Hobbs: >>>>>>> On 2020-09-22 13:35, Lasse Langwadt Christensen wrote: >>>>>>>> tirsdag den 22. september 2020 kl. 03.47.59 UTC+2 skrev Phil Hobbs: >>>>>>>>> On 2020-09-21 21:32, Lasse Langwadt Christensen wrote: >>>>>>>>>> tirsdag den 22. september 2020 kl. 02.47.37 UTC+2 skrev Phil Hobbs: >>>>>>>>>>> On 2020-09-21 00:06, Jasen Betts wrote: >>>>>>>>>>>> On 2020-09-21, jlarkin@highlandsniptechnology.com >>>>>>>>>>>> <jlarkin@highlandsniptechnology.com> wrote: >>>>>>>>>>>>> On Sun, 20 Sep 2020 16:29:30 -0700 (PDT), whit3rd >>>>>>>>>>>>> <whit3rd@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sunday, September 20, 2020 at 2:01:05 PM UTC-7, >>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>> On Sun, 20 Sep 2020 13:33:11 -0700 (PDT), whit3rd >>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sunday, September 20, 2020 at 3:26:13 AM UTC-7, >>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>>> On Sun, 20 Sep 2020 00:26:47 -0700 (PDT), whit3rd >>>>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>>>>> On Saturday, September 19, 2020 at 9:49:47 PM UTC-7, >>>>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Just average the samples and subtract that average from >>>>>>>>>>>>>>>>>>> each new sample. There are several ways to do that >>>>>>>>>>>>>>>>>>> average: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sum the last N samples and divide by N. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that's a FIR filter (finite impulse response) ... if you >>>>>>>>>>>>>>>>>> choose the sample size and know the likely interference >>>>>>>>>>>>>>>>>> sources (like, 60 Hz ripple), it allows you to place a >>>>>>>>>>>>>>>>>> null appropriately >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Exponential smoothing: Avg = Avg + (new-Avg) / N >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that's a IIR filter (infinite impulse response); usually >>>>>>>>>>>>>>>>>> not a great choice >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Why not? I see a lot of irrational prejuduce against simple >>>>>>>>>>>>>>>>> IIR filters, in code and in FPGAs. Some people would rather >>>>>>>>>>>>>>>>> write a hundred lines of code instead of one. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Oh, it's simple, all right, but it has a long startup >>>>>>>>>>>>>>>> transient. >>>>>>>>>>>>>>> Any lowpass filter or averager does. Just poke a starting value >>>>>>>>>>>>>>> into the integrator node if you're in a hurry, ADC midscale in >>>>>>>>>>>>>>> this case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A lowpass needn't be considered appropriate during startup (and >>>>>>>>>>>>>> brute-force setting a starting value helps). FIR has a >>>>>>>>>>>>>> time-limit on its history, which is often completely appropriate >>>>>>>>>>>>>> and useful. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That means it doesn't deal with lightning-strike artifacts >>>>>>>>>>>>>>>> well, either. >>>>>>>>>>>>>>> Presumably an ADC rails on a huge transient. Why would an IIR >>>>>>>>>>>>>>> filter be worse than a FIR for a spike? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Small signal in big digitizer range, of course. Your 'rails' >>>>>>>>>>>>>> scenario is a measurement failure, and there's multiple ways to >>>>>>>>>>>>>> treat such a thing, which FIR does by... ignoring the spike a few >>>>>>>>>>>>>> samples afterward. IIR doesn't do that, so saturating the >>>>>>>>>>>>>> digitizer is an alternate solution that you don't seem to >>>>>>>>>>>>>> dislike. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's impressive... >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm pleased that my response impresses you. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> how many convoluted arguments people make to avoid IIR digital >>>>>>>>>>>>>>> filters. Most of them reduce to "It's too simple and I don't >>>>>>>>>>>>>>> like it." >>>>>>>>>>>>>> >>>>>>>>>>>>>> But not any that I mentioned; what ARE those other "convoluted >>>>>>>>>>>>>> arguments"? I'd like to judge their merits for myself... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I was just thinking how crazy it woud be to use, say, a 5000-tap >>>>>>>>>>>>> FIR filter to compute a good autozero average value of the last >>>>>>>>>>>>> 5000 samples. >>>>>>>>>>>>> >>>>>>>>>>>>> Those 5000 multiply-by-1-and-add blocks will need a lot of logic. >>>>>>>>>>>> >>>>>>>>>>>> Clearly not the best way to make a boxcar filter... LOL. I see what >>>>>>>>>>>> you did there. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You still need a bunch of memory, because on each cycle you have to add >>>>>>>>>>> the new sample and subtract the one from 5000 cycles ago. IIR avoids >>>>>>>>>>> that problem. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter >>>>>>>>>> >>>>>>>>> >>>>>>>>> CICS is an IIR filter. >>>>>>>>> >>>>>>>> >>>>>>>> it is recursive but is it IIR? ;) >>>>>>>> >>>>>>> >>>>>>> IIRs don't _have_ to have infinitely-long impulse responses. >>>>>> >>>>>> it is in the the name >>>>>> >>>>>> IIR and recursive is not the same thing >>>>>> >>>>>> >>>>>> >>>>> Depends whom you ask. IIR (C) Oppenheim and Shafer don't use the term >>>>> "IIR" on account of the terminological confusion. >>>>> >>>>> Anyway, because your definition is inaccurate for any given filter. >>>>> Because of limited resolution even an "IIR" filter doesn't really have >>>>> an infinite impulse response even in theory, unless it exhibits a limit >>>>> cycle. A simple 1-pole rolloff such as >>>>> >>>>> y_N = 0.5 (x_N + y_N-1) >>>>> >>>>> is an 'IIR' if that means recursive, but at N bit precision it goes to >>>>> zero in at most N cycles after the input goes to 0. Even in IEEE quad >>>>> precision with denormals, which has a 15-bit exponent and 112-bit >>>>> significant, it'll go to zero after at most 64k + 112 cycles. >>>>> >>>> >>>> then it becomes more philosophical like what is zero Hz >>> >>> Nice try. The filter output goes to zero exponentially with time, vs. >>> frequency resolution increasing only linearly. >>> >>> Cheers >>> >>> Phil Hobbs >> >> >> Depends on what the definition of IS is. :) >> >> As I undersand it, the recursiveness of an IIR filter topology is what >> would allow it to be "infinite". It the total recursive gains are >> less than 1.0 and the input stops, the output will stop. >> >> Kind of like the coronavirus > >Hopefully not--lots of recursive filters have limit cycles, so the >output never goes away. That's probably the reason for their bad >reputation in some circles. Or maybe it's the likelihood of overflow of >intermediate results, much like railing and slew limiting in >poorly-designed active continuous-time filters. > >A simple example of an IIR filter with a limit cycle is another one-pole >lowpass implemented in integers, which can get stuck at a nonzero DC >output if the decrement per cycle is less than 0.5. More complicated >filters can exhibit AC limit cycles. > >(Of course a limit cycle isn't an impulse response either.) > >Cheers > >Phil Hobbs
Not sure if I have heard of "limit cycles" in this context but I can certainly imagine a software failsafe. So it can be implemented with a LPF eh ? Will have to look that up. I use IIR filters (type I II or whatever) but I haven't had a problem with unrestricted feedback. My filters are rather simple and haven't had any DC offset runaway so far. It has been a very long time since I've used an FIR filter. Was used in a telephone hybrid around 1990. Worked great ! 128 taps as I remember
On 2020-09-24 02:38, boB wrote:
> On Thu, 24 Sep 2020 00:35:02 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 2020-09-23 23:49, boB wrote: >>> On Wed, 23 Sep 2020 19:44:05 -0400, Phil Hobbs >>> <pcdhSpamMeSenseless@electrooptical.net> wrote: >>> >>>> On 2020-09-23 18:56, Lasse Langwadt Christensen wrote: >>>>> torsdag den 24. september 2020 kl. 00.36.18 UTC+2 skrev Phil Hobbs: >>>>>> On 2020-09-23 18:19, Lasse Langwadt Christensen wrote: >>>>>>> onsdag den 23. september 2020 kl. 23.58.40 UTC+2 skrev Phil Hobbs: >>>>>>>> On 2020-09-22 13:35, Lasse Langwadt Christensen wrote: >>>>>>>>> tirsdag den 22. september 2020 kl. 03.47.59 UTC+2 skrev Phil Hobbs: >>>>>>>>>> On 2020-09-21 21:32, Lasse Langwadt Christensen wrote: >>>>>>>>>>> tirsdag den 22. september 2020 kl. 02.47.37 UTC+2 skrev Phil Hobbs: >>>>>>>>>>>> On 2020-09-21 00:06, Jasen Betts wrote: >>>>>>>>>>>>> On 2020-09-21, jlarkin@highlandsniptechnology.com >>>>>>>>>>>>> <jlarkin@highlandsniptechnology.com> wrote: >>>>>>>>>>>>>> On Sun, 20 Sep 2020 16:29:30 -0700 (PDT), whit3rd >>>>>>>>>>>>>> <whit3rd@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sunday, September 20, 2020 at 2:01:05 PM UTC-7, >>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>> On Sun, 20 Sep 2020 13:33:11 -0700 (PDT), whit3rd >>>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sunday, September 20, 2020 at 3:26:13 AM UTC-7, >>>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>>>> On Sun, 20 Sep 2020 00:26:47 -0700 (PDT), whit3rd >>>>>>>>>>>>>>>>>> <whi...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> On Saturday, September 19, 2020 at 9:49:47 PM UTC-7, >>>>>>>>>>>>>>>>>>> jla...@highlandsniptechnology.com wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Just average the samples and subtract that average from >>>>>>>>>>>>>>>>>>>> each new sample. There are several ways to do that >>>>>>>>>>>>>>>>>>>> average: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sum the last N samples and divide by N. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> that's a FIR filter (finite impulse response) ... if you >>>>>>>>>>>>>>>>>>> choose the sample size and know the likely interference >>>>>>>>>>>>>>>>>>> sources (like, 60 Hz ripple), it allows you to place a >>>>>>>>>>>>>>>>>>> null appropriately >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Exponential smoothing: Avg = Avg + (new-Avg) / N >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> that's a IIR filter (infinite impulse response); usually >>>>>>>>>>>>>>>>>>> not a great choice >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Why not? I see a lot of irrational prejuduce against simple >>>>>>>>>>>>>>>>>> IIR filters, in code and in FPGAs. Some people would rather >>>>>>>>>>>>>>>>>> write a hundred lines of code instead of one. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Oh, it's simple, all right, but it has a long startup >>>>>>>>>>>>>>>>> transient. >>>>>>>>>>>>>>>> Any lowpass filter or averager does. Just poke a starting value >>>>>>>>>>>>>>>> into the integrator node if you're in a hurry, ADC midscale in >>>>>>>>>>>>>>>> this case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A lowpass needn't be considered appropriate during startup (and >>>>>>>>>>>>>>> brute-force setting a starting value helps). FIR has a >>>>>>>>>>>>>>> time-limit on its history, which is often completely appropriate >>>>>>>>>>>>>>> and useful. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That means it doesn't deal with lightning-strike artifacts >>>>>>>>>>>>>>>>> well, either. >>>>>>>>>>>>>>>> Presumably an ADC rails on a huge transient. Why would an IIR >>>>>>>>>>>>>>>> filter be worse than a FIR for a spike? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Small signal in big digitizer range, of course. Your 'rails' >>>>>>>>>>>>>>> scenario is a measurement failure, and there's multiple ways to >>>>>>>>>>>>>>> treat such a thing, which FIR does by... ignoring the spike a few >>>>>>>>>>>>>>> samples afterward. IIR doesn't do that, so saturating the >>>>>>>>>>>>>>> digitizer is an alternate solution that you don't seem to >>>>>>>>>>>>>>> dislike. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It's impressive... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm pleased that my response impresses you. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> how many convoluted arguments people make to avoid IIR digital >>>>>>>>>>>>>>>> filters. Most of them reduce to "It's too simple and I don't >>>>>>>>>>>>>>>> like it." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But not any that I mentioned; what ARE those other "convoluted >>>>>>>>>>>>>>> arguments"? I'd like to judge their merits for myself... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was just thinking how crazy it woud be to use, say, a 5000-tap >>>>>>>>>>>>>> FIR filter to compute a good autozero average value of the last >>>>>>>>>>>>>> 5000 samples. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Those 5000 multiply-by-1-and-add blocks will need a lot of logic. >>>>>>>>>>>>> >>>>>>>>>>>>> Clearly not the best way to make a boxcar filter... LOL. I see what >>>>>>>>>>>>> you did there. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You still need a bunch of memory, because on each cycle you have to add >>>>>>>>>>>> the new sample and subtract the one from 5000 cycles ago. IIR avoids >>>>>>>>>>>> that problem. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> CICS is an IIR filter. >>>>>>>>>> >>>>>>>>> >>>>>>>>> it is recursive but is it IIR? ;) >>>>>>>>> >>>>>>>> >>>>>>>> IIRs don't _have_ to have infinitely-long impulse responses. >>>>>>> >>>>>>> it is in the the name >>>>>>> >>>>>>> IIR and recursive is not the same thing >>>>>>> >>>>>>> >>>>>>> >>>>>> Depends whom you ask. IIR (C) Oppenheim and Shafer don't use the term >>>>>> "IIR" on account of the terminological confusion. >>>>>> >>>>>> Anyway, because your definition is inaccurate for any given filter. >>>>>> Because of limited resolution even an "IIR" filter doesn't really have >>>>>> an infinite impulse response even in theory, unless it exhibits a limit >>>>>> cycle. A simple 1-pole rolloff such as >>>>>> >>>>>> y_N = 0.5 (x_N + y_N-1) >>>>>> >>>>>> is an 'IIR' if that means recursive, but at N bit precision it goes to >>>>>> zero in at most N cycles after the input goes to 0. Even in IEEE quad >>>>>> precision with denormals, which has a 15-bit exponent and 112-bit >>>>>> significant, it'll go to zero after at most 64k + 112 cycles. >>>>>> >>>>> >>>>> then it becomes more philosophical like what is zero Hz >>>> >>>> Nice try. The filter output goes to zero exponentially with time, vs. >>>> frequency resolution increasing only linearly. >>>> >>>> Cheers >>>> >>>> Phil Hobbs >>> >>> >>> Depends on what the definition of IS is. :) >>> >>> As I undersand it, the recursiveness of an IIR filter topology is what >>> would allow it to be "infinite". It the total recursive gains are >>> less than 1.0 and the input stops, the output will stop. >>> >>> Kind of like the coronavirus >> >> Hopefully not--lots of recursive filters have limit cycles, so the >> output never goes away. That's probably the reason for their bad >> reputation in some circles. Or maybe it's the likelihood of overflow of >> intermediate results, much like railing and slew limiting in >> poorly-designed active continuous-time filters. >> >> A simple example of an IIR filter with a limit cycle is another one-pole >> lowpass implemented in integers, which can get stuck at a nonzero DC >> output if the decrement per cycle is less than 0.5. More complicated >> filters can exhibit AC limit cycles. >> >> (Of course a limit cycle isn't an impulse response either.) >> >> Cheers >> >> Phil Hobbs > > > Not sure if I have heard of "limit cycles" in this context but I can > certainly imagine a software failsafe.
Not sure what you mean by that.
> > So it can be implemented with a LPF eh ? Will have to look that up. > I use IIR filters (type I II or whatever) but I haven't had a problem > with unrestricted feedback. My filters are rather simple and haven't > had any DC offset runaway so far.
The offset doesn't run away in a stable filter, it just doesn't decay to 0 in general. For a toy example, consider a 1-pole IIR lowpass with a decrement of 1/256 per cycle, implemented in integers, i.e. y_n+1 = y_n + (x_n - y_n-1) >> 8. It gets stuck at a value of 127 with correct rounding and 255 with truncation.
> > It has been a very long time since I've used an FIR filter. Was used > in a telephone hybrid around 1990. Worked great ! 128 taps as I > remember
FIR filters have some really good properties, and can be implemented efficiently using FFTs if you don't mind the extra delay. Symmetrical FIR filters have exactly linear phase, which is sometimes a huge help. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com