Removing DC offset from ADC Buffer...

[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. And CICS
filters can have, if you start and end with an integrator.

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

 

[Phil Hobbs]

On 2020-09-22 17:16, Joe Gwinn wrote:

On Mon, 21 Sep 2020 20:50:42 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-09-21 19:12, John Larkin wrote:
On Mon, 21 Sep 2020 15:36:26 -0700 (PDT), jrwalliker@gmail.com wrote:

On Monday, 21 September 2020 19:21:44 UTC+1, Kevin Aylward wrote:
\"Ricketty C\" wrote in message
news:97ab1d7f-07cf-4caa-9faa-1e66f2b86b4eo@googlegroups.com...

On Saturday, September 19, 2020 at 11:38:09 PM UTC-4, Gold_Spark wrote:
I\'m using a STM32 Cortex M0+ to read an AC signal from a CT. I\'m sampling
at 6kHz and storing 400 samples. The signal has a DC bias equal to Vcc/2 =
1.65V. In the digital domain this is 2048. In hardware this DC value is
very precise, but when sampling it, it varies from 2044 to 2052 inside the
buffer. Now >if I want to do RMS in that set of data, I need to find a way
to deal with this DC bias variation.

I have been thinking the following:

1- Subtract a fixed value of 2048 from each ADC reading. This is no so
good as I said above this value may vary slightly. Also, if I want to
read zero cross it >>may cause errors to choose exactly 2048 as
reference.

4- Use a more sophisticated software high pass filter?

Funny that people propose you use a low pass filter and subtract. A high
pass would just provide the AC without the DC. It would take some time to
start >up, but can work very effectively. If this sampling is continuous
that would work fine.

Yeah... seems like the twilight zone here. All this FIR, averaging and
$hit... seems to be... the plot is lost....

From the description the poster is measurement an AC signal, thus stick a
cap on the input to block the DC and you\'re done....

There is no dc to remove from the input. Its a current transformer.
The problem is that the ADC needs to be biased at the midpoint of
the positive-only supply so that it can digitise positive and negative
outputs from the CT. The converted values of that midpoint bias are
not completely stable and need to be removed before the rms calculation, otherwise small alternating signals are swamped by the offset error.

John

Exactly. You can auto-zero to a fraction of an ADC LSB. Then your RMS
measurement is limited by ADC quantization and linearity. ADC offset
usually drifts slowly, so the autozero can use tons of samples and
need not be especially fast. Averaging the last 65536 samples at your
6K rate would work fine. You\'d get a new az value every 10 seconds.

I did software az in my electric meters. And added a little noise
dither to the ADC front end. That added a little baseline offset to
the reported RMS currents, but vastly improved low-level power
measurement. It\'s actually hard to design electronics that\'s as good
as an old disk-type meter. The only spec I really beat them on was
tilt.

There\'s a trick to adding dither without increasing the apparent RMS
floor much. The nuclear guys do that in pulse-height spectroscopy.

Subtracting the dither off again digitally?

Dithering is surprisingly subtle occasionally--for instance, you can\'t
do a good job dithering a 1-bit delta-sigma because it has no linear range.

Hmm. The Sonar folk used one-bit correlators twenty or thirty years
ago, and were able to reach very deep into the background noise (the
oceans are very noisy from biological sources). That noise acted as a
dither source.

Joe Gwinn

Yeah, you can do 1-bit correlators, but it costs you at least 3 dB in
SNR compared with linear or multibit ones. Hanbury Brown tried it in
the \'60s, and it doubled the required measurement time.

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

 

[John Larkin]

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.

 

[Lasse Langwadt Christensen]

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

 

[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.

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

 

[Lasse Langwadt Christensen]

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

 

[Joe Gwinn]

On Wed, 23 Sep 2020 18:00:36 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-09-22 17:16, Joe Gwinn wrote:
On Mon, 21 Sep 2020 20:50:42 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-09-21 19:12, John Larkin wrote:
On Mon, 21 Sep 2020 15:36:26 -0700 (PDT), jrwalliker@gmail.com wrote:

On Monday, 21 September 2020 19:21:44 UTC+1, Kevin Aylward wrote:
\"Ricketty C\" wrote in message
news:97ab1d7f-07cf-4caa-9faa-1e66f2b86b4eo@googlegroups.com...

On Saturday, September 19, 2020 at 11:38:09 PM UTC-4, Gold_Spark wrote:
I\'m using a STM32 Cortex M0+ to read an AC signal from a CT. I\'m sampling
at 6kHz and storing 400 samples. The signal has a DC bias equal to Vcc/2 =
1.65V. In the digital domain this is 2048. In hardware this DC value is
very precise, but when sampling it, it varies from 2044 to 2052 inside the
buffer. Now >if I want to do RMS in that set of data, I need to find a way
to deal with this DC bias variation.

I have been thinking the following:

1- Subtract a fixed value of 2048 from each ADC reading. This is no so
good as I said above this value may vary slightly. Also, if I want to
read zero cross it >>may cause errors to choose exactly 2048 as
reference.

4- Use a more sophisticated software high pass filter?

Funny that people propose you use a low pass filter and subtract. A high
pass would just provide the AC without the DC. It would take some time to
start >up, but can work very effectively. If this sampling is continuous
that would work fine.

Yeah... seems like the twilight zone here. All this FIR, averaging and
$hit... seems to be... the plot is lost....

From the description the poster is measurement an AC signal, thus stick a
cap on the input to block the DC and you\'re done....

There is no dc to remove from the input. Its a current transformer.
The problem is that the ADC needs to be biased at the midpoint of
the positive-only supply so that it can digitise positive and negative
outputs from the CT. The converted values of that midpoint bias are
not completely stable and need to be removed before the rms calculation, otherwise small alternating signals are swamped by the offset error.

John

Exactly. You can auto-zero to a fraction of an ADC LSB. Then your RMS
measurement is limited by ADC quantization and linearity. ADC offset
usually drifts slowly, so the autozero can use tons of samples and
need not be especially fast. Averaging the last 65536 samples at your
6K rate would work fine. You\'d get a new az value every 10 seconds.

I did software az in my electric meters. And added a little noise
dither to the ADC front end. That added a little baseline offset to
the reported RMS currents, but vastly improved low-level power
measurement. It\'s actually hard to design electronics that\'s as good
as an old disk-type meter. The only spec I really beat them on was
tilt.

There\'s a trick to adding dither without increasing the apparent RMS
floor much. The nuclear guys do that in pulse-height spectroscopy.

Subtracting the dither off again digitally?

Dithering is surprisingly subtle occasionally--for instance, you can\'t
do a good job dithering a 1-bit delta-sigma because it has no linear range.

Hmm. The Sonar folk used one-bit correlators twenty or thirty years
ago, and were able to reach very deep into the background noise (the
oceans are very noisy from biological sources). That noise acted as a
dither source.

Joe Gwinn


Yeah, you can do 1-bit correlators, but it costs you at least 3 dB in
SNR compared with linear or multibit ones. Hanbury Brown tried it in
the \'60s, and it doubled the required measurement time.

You are exactly right, but the Sonar folk were doing hideously large
correlation windows (I sort-of recall that it was like a million
bits), which could only be done with one-bit correlators with the
hardware of the day. I think one application was beamforming. For
detecting submarines, the correlation window width was more important
than the 3 dB.

..<https://en.wikipedia.org/wiki/SOSUS>

Joe Gwinn

 

[John Larkin]

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.

 

[Phil Hobbs]

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

--
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

 

[Phil Hobbs]

On 2020-09-23 18:59, Joe Gwinn wrote:

On Wed, 23 Sep 2020 18:00:36 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-09-22 17:16, Joe Gwinn wrote:
On Mon, 21 Sep 2020 20:50:42 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-09-21 19:12, John Larkin wrote:
On Mon, 21 Sep 2020 15:36:26 -0700 (PDT), jrwalliker@gmail.com wrote:

On Monday, 21 September 2020 19:21:44 UTC+1, Kevin Aylward wrote:
\"Ricketty C\" wrote in message
news:97ab1d7f-07cf-4caa-9faa-1e66f2b86b4eo@googlegroups.com...

On Saturday, September 19, 2020 at 11:38:09 PM UTC-4, Gold_Spark wrote:
I\'m using a STM32 Cortex M0+ to read an AC signal from a CT. I\'m sampling
at 6kHz and storing 400 samples. The signal has a DC bias equal to Vcc/2 =
1.65V. In the digital domain this is 2048. In hardware this DC value is
very precise, but when sampling it, it varies from 2044 to 2052 inside the
buffer. Now >if I want to do RMS in that set of data, I need to find a way
to deal with this DC bias variation.

I have been thinking the following:

1- Subtract a fixed value of 2048 from each ADC reading. This is no so
good as I said above this value may vary slightly. Also, if I want to
read zero cross it >>may cause errors to choose exactly 2048 as
reference.

4- Use a more sophisticated software high pass filter?

Funny that people propose you use a low pass filter and subtract. A high
pass would just provide the AC without the DC. It would take some time to
start >up, but can work very effectively. If this sampling is continuous
that would work fine.

Yeah... seems like the twilight zone here. All this FIR, averaging and
$hit... seems to be... the plot is lost....

From the description the poster is measurement an AC signal, thus stick a
cap on the input to block the DC and you\'re done....

There is no dc to remove from the input. Its a current transformer.
The problem is that the ADC needs to be biased at the midpoint of
the positive-only supply so that it can digitise positive and negative
outputs from the CT. The converted values of that midpoint bias are
not completely stable and need to be removed before the rms calculation, otherwise small alternating signals are swamped by the offset error.

John

Exactly. You can auto-zero to a fraction of an ADC LSB. Then your RMS
measurement is limited by ADC quantization and linearity. ADC offset
usually drifts slowly, so the autozero can use tons of samples and
need not be especially fast. Averaging the last 65536 samples at your
6K rate would work fine. You\'d get a new az value every 10 seconds.

I did software az in my electric meters. And added a little noise
dither to the ADC front end. That added a little baseline offset to
the reported RMS currents, but vastly improved low-level power
measurement. It\'s actually hard to design electronics that\'s as good
as an old disk-type meter. The only spec I really beat them on was
tilt.

There\'s a trick to adding dither without increasing the apparent RMS
floor much. The nuclear guys do that in pulse-height spectroscopy.

Subtracting the dither off again digitally?

Dithering is surprisingly subtle occasionally--for instance, you can\'t
do a good job dithering a 1-bit delta-sigma because it has no linear range.

Hmm. The Sonar folk used one-bit correlators twenty or thirty years
ago, and were able to reach very deep into the background noise (the
oceans are very noisy from biological sources). That noise acted as a
dither source.

Joe Gwinn


Yeah, you can do 1-bit correlators, but it costs you at least 3 dB in
SNR compared with linear or multibit ones. Hanbury Brown tried it in
the \'60s, and it doubled the required measurement time.

You are exactly right, but the Sonar folk were doing hideously large
correlation windows (I sort-of recall that it was like a million
bits), which could only be done with one-bit correlators with the
hardware of the day. I think one application was beamforming. For
detecting submarines, the correlation window width was more important
than the 3 dB.

..<https://en.wikipedia.org/wiki/SOSUS

That I believe.

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

 

[boB]

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.

 

[Phil Hobbs]

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