AC Current Measurement Strategy

[mmitton]

Hi All,

We are busy with a project that takes measurements from a Current Transformer (CT) to track current usage in attached appliances. The CT is connected through an amplifier circuit to a micro-controller ADC pin. The AC wave (positive cycle only) is sampled at 100us intervals (there are a few channels to sample) and a snapshot of the positive half of a wave is recorded. From this snapshot we hope to calculate the current usage of the attached load.

We understand that in order to get an accurate power reading of the attached load we need to get an RMS current value from the CT, an RMS voltage value of the supply and the power factor (measure the phase angle difference between the supply voltage and load current).

Step 1 is to convert the ADC reading from the CT to a current value that is consistent with a Digital Multimeter (DMM) or within a small margin of error.

We believe that it should be possible to take snapshots (ADC values) of various types of loads with similar current ratings and the calculation employed should yield values that correspond to DMM readings. ie. If the DMM measures 2 different types of 15W loads and sees a current of 69mA and 58mA respectively (ratio of 1.19), then our calculation using ADC values should yield a similar ratio between the 2 loads.

Here are the values recorded for each load, 15W Incandescent and 15W LED lighting. (see graph)

The various measurement strategies yield the following results and ratios: (see table)

Where we calculate these values using the following formulas:

ADC sum = sum of all values
ADC Ave = average of all values
ADC RMS = peak * 0.707
ADC True RMS = Square root of the average of the sum of the squares

As you can see the sum/ave have a similar ratio but in the opposite direction and the RMS / True RMS calculations are way off.

Is the strategy to get the AC current employed here correct or valid?
What is the DMM using (Doesn't say it's a True RMS meter)?
Is the phase angle difference the issue here and do we need it for an accurate current measurement?
What are we missing?

Thank you for any insights.
Mark

 

[crutschow]

Perhaps of note, is that this simple "running average" routine only requires one storage register for the average value, and whatever are required to do the simple math for each sample of the incoming data.

 

[KlausST]

Hi,

Crutschow, what you did is not wrong. And your filter isn't wrong. And that it just uses one register still isn't wrong.
Still "running average" is the wrong name for the filter. It's just a simple first order low pass filter.

My personal opinion:
Should we teach newbies up to experienced forum members to use the wrong name?
For me the animal with two legs and two wings still is a bird, even if someone calls it a dog.

But in times where humans born with a p**is call themselfes a woman to beat naturally born women in sports...
Maybe I'm just old-fashioned. ;-)

Klaus

 

[crutschow]

Still "running average" is the wrong name for the filter. It's just a simple first order low pass filter.

And does not a simple low-pass RC filter perform a "running average" of the input signal?

 

[barry]

And does not a simple low-pass RC filter perform a "running average" of the input signal?

No.

If you write the mathematical equations of an RC filter and a running average (which i’m too lazy to do) you’ll see that they’re different. Basically, an RC output is an integral from t=0, a running average is calculated over a fixed block of time.

 

[crutschow]

No.

If you write the mathematical equations of an RC filter and a running average (which i’m too lazy to do) you’ll see that they’re different. Basically, an RC output is an integral from t=0, a running average is calculated over a fixed block of time.

Ok, so semantically it does not conform to the mathematical definition of a "running average" even though it performs an average over time of the input signal, similar to a mathematical running average (albeit they can give somewhat different results).

And if we are being semantical, an RC output is not basically an integral of the signal over time. as that would lead to an infinite voltage for a DC input, it's the average over time (sometimes called a leaky integrator).

So if there are good reasons to use a mathematical running average over a digital-emulated RC average for the requirements of averaging the power samples that is subject of this post, then I would like to know what that is.

 

[KlausST]

Hi

Already explained. Now again in short:
* your filter: is a first order low pass. Don't call it "averaging" at all.
* the running average is a true, equally weighted average over n samples.

Please, please do an internet search.

Klaus

 

[crutschow]

your filter: is a first order low pass. Don't call it "averaging" at all.

Sorry but last I checked, you are not in charge of what I call something.
It does an average of the signal over time, so I will continue to call it "averaging" even if it's not technically a "running average".

I did an internet search and understand what a "mathematical" running average is.
That does not mean it has to be a mathematical running average to be called an average over time.

 

[KlausST]

Sorry but last I checked, you are not in charge of what I call something.

Call a bird a dog if you feel better then. It just spreads confusion. There are definitions, and a technician should follow them. Especially in a forum where new members like to learn correct phrasing.

Mathematically your dog filter does not even average correctly over time. It always leaves an error. About 37% after 1 tau, about 10% after 2 tau, about 3% after 3 tau. Infinitely. So in finite time it does not average correctly ... it just comes close.

...In opposite to true averaging filter. It has a limited time and does correct - error free - averaging.

But I guess there is truth and there is your truth.

I've known you as valuable member..interested in helping people with truth and founded information.

Klaus

 

[barry]

Sorry but last I checked, you are not in charge of what I call something.
It does an average of the signal over time, so I will continue to call it "averaging" even if it's not technically a "running average".

I did an internet search and understand what a "mathematical" running average is.
That does not mean it has to be a mathematical running average to be called an average over time.

Since you stubbornly refuse to accept reality, here's a thought experiment for you: Say you have a dc signal of 1 microvolt, and there's a transient of 50000000000000000 volts. The effect of that transient will persist forever in your RC filter; it will disappear once the moving-average window moves past that time.

 

[crutschow]

Call a bird a dog if you feel better then. It just spreads confusion. There are definitions, and a technician should follow them.

I agree on the technical definition of a running average.
But I seen no problem with saying that an RC filter performs an average of the input over time.
It's used frequently in the analog domain for that purpose, so I see no problem with using in for that purpose in the digital domain.
I'm not calling a bird a dog, just two different breeds of birds.

--- Updated Apr 20, 2023 ---

Since you stubbornly refuse to accept reality,

I already said I understood the difference.
You are the one who pedantically is insisting that a RC filter does not perform an average of the signal, so it would seem that is avoiding reality.
It may be different than the mathematical definition of a "moving average" but it certainly performs an average over time.

And your pathological example hardly applies to a real signal processing example, certainly not for this thread's requirements.

So let's leave personal insults out of this.

 

[The Electrician]

And does not a simple low-pass RC filter perform a "running average" of the input signal?

A running average (moving average): https://en.wikipedia.org/wiki/Moving_average

subjects the input signal to a very different inpulse response
than a low pass filter: https://en.wikipedia.org/wiki/Low-pass_filter

The universally understood meaning of "moving average" is that the incoming signal is subjected to equal weighting for the samples. If the weights are not equal then it would be called a "weighted moving average".

Saying: "an RC filter performs an average of the input over time." fails to say what kind of "average" an RC filter performs. The details of the weights applied (the average) to the incoming signal is exactly what distinguishes one filter from another--low pass from band pass from high pass from notch. The averages applied are specified by the impulse response.

The phrase "moving average" is used by practitioners of the art to mean specifically, "equal weights", which is not the same kind of response given by a: https://en.wikipedia.org/wiki/Low-pass_filter

 

[KlausST]

Hi,

O.K. same breed. Then a penguin is the same as a dove? A man is the same as a woman?
There are differences .. and not to confuse them one has different names.

But I seen no problem with saying that an RC filter performs an average of the input over time.

Yes, I know: You see no problem.
I don't want to make you upset .. just to change the viewpoint:
Some people don't see a problem in telling the earth is flat. They are convinced they say the truth.
So what do you say to them? Agree? Ignore? Correct them?

There is a technical/mathematical definition what "averaging" means. (You don't need to believe in my "opinion")
Then I guess you can give the mathematical formula to prove that your filter really does "averaging".
Alternatively a digital simulation with (random) input values. Simple Excel should be sufficient.

As already said, I regularily use both filters. But the low pass is just an approach for an averaging filter.
It always causes errors. It has it's limitations in lower cutoff frequency and it has it's limitations in the time you need to wait for it to settle.

***
An example from one of my designs:
I've build a true RMS measurement device for mains frequency (50Hz). It squares all input values, calculates the (what I call "true" running) average. Calculates the square root.
If you do the "averaging" with your filter, you either get a lot of ripple, or it takes long time to settle.
With my FIR averaging it takes less than 26ms to settle to less than 0.1% (ripple)
(Mathematically it should be perfect (no ripple and 20ms settling time) but only for perfect 50.000Hz. My solution needs 26ms because it also takes care for small frequency deviations)
If one uses the first order low pass to do the averaging you need an fc of 100Hz/500 = 0.2Hz to get the 0.1% ripple.
And thus it takes about 5s to settle to 0.1%. --> 5s vs 26ms!
Additionally it does the true averaging of the non squared values to get the DC component of the past 20ms.
So it is able to extremely fast and can even visualize the saturation effects of a switched on transformer.
One could not do this with standard low pass filters.

The code runs on an ATMEGA328. The running average code is quite fast.

I guess you should try it to find out about the benefit.

Klaus

 

[The Electrician]

Not the way I do it, but perhaps this is not called a "running average", although it acts the same as an RC low-pass filter running averager.
You take a sample and add a small percentage (typically some factor of 2 to simplify the math) of the difference (with sign) between that and the previous average value to give a new average value (emulating an RC low-pass filter).
There is no window size, and the averaging "time-constant" is determined by the sample frequency and what percentage of the difference that you add.

This is a "weighted moving average". If you don't include the word "weighted", people who read what you have written will assume that you mean that the weights are equal. That is what is commonly understood. If you just called your procedure a "weighted moving average" nobody could complain.

 

[crutschow]

This is a "weighted moving average". If you don't include the word "weighted", people who read what you have written will assume that you mean that the weights are equal. That is what is commonly understood. If you just called your procedure a "weighted moving average" nobody could complain.

Okay, thanks for posting that.
So this little verbal kerfuffle was from no-one else knowing the correct term for the averaging technique I suggested.

The code runs on an ATMEGA328. The running average code is quite fast.

How many lines of code does it require and how many samples per second is it calculating?

I guess you should try it to find out about the benefit.

I see that it certainly has a settling time benefit if that is needed in the application.

 

[KlausST]

How many lines of code does it require and how many samples per second is it calcul

It's ADC data rate is 2 channels 3600samples/s 24bit resolution. Continously real time processing. Surely losing not a single sample
It's output data rate via UART is up to 400/s. I_RMS, U_RMS, P_true.
On a +/- 600V range it is stable to about 10mV.

Imagine: it clearely detects the DC voltage caused by an unsymmetrical load "diode with 4kOhms in series" connected to an AC outlet.

Can't say the code line count of the whole project, because it was many years ago.
A running average needs (for n samples of window size):
* ring data buffer for n samples
* a (large) sum buffer
* 1 pointer increment (and wrap around)
* 1 add "new sample to the sum buffer"
* 1 subtract "oldest sample" from the sum buffer
* 1 store of new sample into the place of the oldest sample in the ring buffer
That's all for the "running sum". Not much processing power.
To get the average you need to divide the sum by n. But I do this with one single multiplication where all the scaling (to get Volts from LSBs) is done.

For the RMS I did some "optimisation". Squaring of a 24 bit input gives 47 bits. My sum buffer is 64 bits wide.
So I have 17 bits left. So one could calculate 128k samples of DC or 256k samples of sine, but I did 3600Smpls/s x 20ms = 72 samples only.
My optimized square root function scales the 64 bit down to 32 bit. And calculates a 16 bit result with +/- 1 LSB accuracy in very short time.
Mind: all done with a ATMEGA328 in C. ( plus 2 way serial communication and display)

Klaus

 

[KerimF]

I've build a true RMS measurement device for mains frequency (50Hz). It squares all input values, calculates the (what I call "true" running) average. Calculates the square root.
If you do the "averaging" with your filter, you either get a lot of ripple, or it takes long time to settle.
With my FIR averaging it takes less than 26ms to settle to less than 0.1% (ripple)
(Mathematically it should be perfect (no ripple and 20ms settling time) but only for perfect 50.000Hz. My solution needs 26ms because it also takes care for small frequency deviations)

For instance, the window in my current meters is dynamic. My code for this, written in AVR8 assembly, is based on what I may call 'time division loop'. The clock of this loop is the chosen rate of the ADC free running whose period is set usually to 104 us (or if necessary 52 us). While a new sample is read, a new function could be run as long its cycles (and the cycles of the common codes, entry and end, of all loops) won't exceed 832 cycles (8 MHz * 104 us). In this time division loop, the jump to every function (to run between the common entry and end codes) is done by the IJMP instruction (using register Z as the indirect address to 256 RJMP's list). The common end code senses (by reading the external interrupt flag) the start of a new mains cycle (around 50 Hz) and this gives the number of samples of the previous cycle (a dynamic window) which could be used for averaging (the squared inputs).

Notes about accuracy:
[1] If we assume 54 Hz (Freq) is the highest mains frequency, the number of samples in one cycle is 178 samples.
[2] In the worst case, the error of this number is 1 sample over 1,000,000/Freq/104 samples. That is 1/178 = 0.56%.
[3] Knowing that, at zero voltage crossings, a current could be close to zero ampere, but it also could be at its maximum if the impedance of the load is not real, likely inductive. I usually delay (by a simple RC LPF) the attenuated mains voltage at the MCU interrupt pin by 2 to 3ms (the current zero crossing when the load is just a transformer close to saturation). By doing this, the final error is much less than 0.56% because the square of the sample value at this delayed zero crossing still is much lower than of the current peak reading. This also applies in in measuring the RMS voltage.