Removing DC offset from ADC Buffer...

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

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

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

 

[Ricketty C]

On Monday, September 21, 2020 at 2:21:44 PM UTC-4, 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....

I think the DC is present to center the AC in the ADC range. If you remove the bias you get the positive half of the sine wave only.

Unless we know more about what he was measuring when he got the numbers he provided we won\'t know if he even needs to do any filtering or if he could just subtract 2048 from each sample.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[Lasse Langwadt Christensen]

tirsdag den 22. september 2020 kl. 02.50.53 UTC+2 skrev Phil Hobbs:

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.

you could say delta-sigma is nothing but dither and that is what makes
it work

 

[Lasse Langwadt Christensen]

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

 

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

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-21 21:30, Lasse Langwadt Christensen wrote:

tirsdag den 22. september 2020 kl. 02.50.53 UTC+2 skrev Phil Hobbs:
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.


you could say delta-sigma is nothing but dither and that is what makes
it work

Sort of, assuming that your noise has good properties, which it often
does not. Anyway, you can\'t usefully dither a 1-bit delta-sigma.

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

 

[Flyguy]

On Saturday, September 19, 2020 at 8:38:09 PM UTC-7, 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.
2- Sample the DC bias and average it.
3- Don\'t remove the DC bias. If I calculate RMS then I would get the DC value when there\'s no input signal.
4- Use a more sophisticated software high pass filter?

Example of DC bias readings:

ADC_buffer
[0] 2048
[1] 2046
[2] 2049
[3] 2051
[4] 2051
[5] 2052
[6] 2050
[7] 2050
[8] 2050
[9] 2047
[10] 2049
[11] 2050
[12] 2049

I appreciate any help or suggestion.

You didn\'t say how fast you want to converge on a solution. Or what is the bandwidth of your output? If your result is DC and has a long time to respond to a change, then just average. But if you need a quick response to a step change, then you will need to do more sophisticated digital filtering. A simple solution is an FIR highpass filter to get rid of the DC component. But you have to specify how fast and how accurately you need a result to design the filter.

 

[server]

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?

Right. You have to know the dither contribution to every sample, so
generate it with a DAC. Some people dither a lot, many ADC bits.

I generally used an async triangle wave as the dither in my electric
meters. I got utility-grade power metering, a huge dynamic range, with
a dithered 7-bit single-slope ADC. In power/energy metering, you
multiply the voltage and current samples and integrate that long-term,
so all sorts of errors just go away.

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.

Cheers

Phil Hobbs

--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Jasen Betts]

On 2020-09-21, Ricketty C <gnuarm.deletethisbit@gmail.com> wrote:

On Monday, September 21, 2020 at 12:30:52 AM UTC-4, 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:

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.

--
Jasen.

You mean to construct a straw man design and then shoot it down?

I\'m remarking on his wordplay on \"convoluted\": he describes a boxcar
filter implemneted as a convolution.

It struck me that John knows DSP better than that, but it took me a
while to catch his meaning.

--
Jasen.

 

[Ricketty C]

On Tuesday, September 22, 2020 at 4:30:53 AM UTC-4, Jasen Betts wrote:

On 2020-09-21, Ricketty C <gnuarm.deletethisbit@gmail.com> wrote:
On Monday, September 21, 2020 at 12:30:52 AM UTC-4, 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:

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.

--
Jasen.

You mean to construct a straw man design and then shoot it down?

I\'m remarking on his wordplay on \"convoluted\": he describes a boxcar
filter implemneted as a convolution.

It struck me that John knows DSP better than that, but it took me a
while to catch his meaning.

Ok, wordplay. Got it.

Yes, the sort of joke that is only humorous to an engineer and the more... extreme ones at that.

I have a math joke that has to be explained to most mathematicians, not because they don\'t understand the math aspects. They don\'t understand humor. It appears that when carried to an extreme \"math joke\" is a self contradiction. Not so much different from \"engineering joke\".

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

 

[Lasse Langwadt Christensen]

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?

 

[Ricketty C]

On Tuesday, September 22, 2020 at 1:35:58 PM UTC-4, 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?

The CIC filter is neither recursive or IIR. But it can be designed using a structure that is similar to an IIR for efficiency much in the same way the FFT utilizes patterns in the sine function to calculate the discrete version of the Fourier transform. The FFT is still calculating the same function as the DFT.

Not sure what the CICS filter is so I can\'t say anything about that.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

 

[Lasse Langwadt Christensen]

tirsdag den 22. september 2020 kl. 20.22.06 UTC+2 skrev Ricketty C:

On Tuesday, September 22, 2020 at 1:35:58 PM UTC-4, 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?

The CIC filter is neither recursive or IIR.

https://en.wikipedia.org/wiki/Recursive_filter

 

[Ricketty C]

On Tuesday, September 22, 2020 at 4:16:25 PM UTC-4, Lasse Langwadt Christensen wrote:

tirsdag den 22. september 2020 kl. 20.22.06 UTC+2 skrev Ricketty C:
On Tuesday, September 22, 2020 at 1:35:58 PM UTC-4, 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?

The CIC filter is neither recursive or IIR.

https://en.wikipedia.org/wiki/Recursive_filter

Not sure what your point is. The CIC is the sum of the last N samples, typically applied successively in small sections with decimation. That is not a recursive filter or an IIR. The fact that you can construct an equivalent filter using a recursive structure does not say anything about the nature of the filter.

If there is something someone wishes to say about recursive filters and then try to apply that to a CIC filter, I\'d like to hear it. Otherwise we are just counting angels dancing on the head of a pin.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

 

[Lasse Langwadt Christensen]

tirsdag den 22. september 2020 kl. 22.28.27 UTC+2 skrev Ricketty C:

On Tuesday, September 22, 2020 at 4:16:25 PM UTC-4, Lasse Langwadt Christensen wrote:
tirsdag den 22. september 2020 kl. 20.22.06 UTC+2 skrev Ricketty C:
On Tuesday, September 22, 2020 at 1:35:58 PM UTC-4, 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?

The CIC filter is neither recursive or IIR.

https://en.wikipedia.org/wiki/Recursive_filter

Not sure what your point is. The CIC is the sum of the last N samples, typically applied successively in small sections with decimation. That is not a recursive filter or an IIR. The fact that you can construct an equivalent filter using a recursive structure does not say anything about the nature of the filter.

If there is something someone wishes to say about recursive filters and then try to apply that to a CIC filter, I\'d like to hear it. Otherwise we are just counting angels dancing on the head of a pin.

CIC is a recursive implementation of specific FIR filter

 

[Joe Gwinn]

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

 

[Lasse Langwadt Christensen]

tirsdag den 22. september 2020 kl. 23.16.36 UTC+2 skrev Joe Gwinn:

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.

Here\'s a GPS receiver with a \"1-bit ADC\" (an LVDS receiver)

http://www.aholme.co.uk/GPS/Main.htm

 

[server]

On Tuesday, 22 September 2020 22:24:26 UTC+1, Lasse Langwadt Christensen wrote:

tirsdag den 22. september 2020 kl. 23.16.36 UTC+2 skrev Joe Gwinn:
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.


Here\'s a GPS receiver with a \"1-bit ADC\" (an LVDS receiver)

http://www.aholme.co.uk/GPS/Main.htm

Motorola were making GPS receivers with 1-bit adcs at least 20 years
ago, possibly considerably more.

John

 

[Ricketty C]

On Tuesday, September 22, 2020 at 5:10:31 PM UTC-4, Lasse Langwadt Christensen wrote:

tirsdag den 22. september 2020 kl. 22.28.27 UTC+2 skrev Ricketty C:
On Tuesday, September 22, 2020 at 4:16:25 PM UTC-4, Lasse Langwadt Christensen wrote:
tirsdag den 22. september 2020 kl. 20.22.06 UTC+2 skrev Ricketty C:
On Tuesday, September 22, 2020 at 1:35:58 PM UTC-4, 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?

The CIC filter is neither recursive or IIR.

https://en.wikipedia.org/wiki/Recursive_filter

Not sure what your point is. The CIC is the sum of the last N samples, typically applied successively in small sections with decimation. That is not a recursive filter or an IIR. The fact that you can construct an equivalent filter using a recursive structure does not say anything about the nature of the filter.

If there is something someone wishes to say about recursive filters and then try to apply that to a CIC filter, I\'d like to hear it. Otherwise we are just counting angels dancing on the head of a pin.


CIC is a recursive implementation of specific FIR filter

It has been many years since I implemented one of these filters, but I do recall reading Hoganhour\'s paper. I guess I\'m not recalling it correctly.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209