RMS calculation - synchronisation of sampling and mains frequency

In the normal version without 3 phase / solar diverter, no PLL is used, and the readings are not synchronised with the crossing point of the wave form. Since the mains frequency varies, shouldn’t the sampling be synchronized with the the waveform? Could we use the LPF as it is, if the variables are long enough to hold the data?

filtered_value = 0.996 × (last_filtered_value + sample - last_sample)

long n = filtered_value + sample - last_sample;
filtered_value = ((n<<8)-n)>>8;

Are you thinking about the real power calculation or rms current only?

That’s not true for the start and end points of the real power calculation; and for rms current, how can you when there might be more than two crossings per cycle? Had you considered that possibility?

And what has the software filter got to do with the title of the post? I can’t see the point or the question you’re getting at.

1 Like

Thank you sir, for the reply::sweat_smile:

Trying to implement this in stm32. I am calculating rms voltage, current, frequency,real power and apparent power.

  1. I am using the same code. Trying 100 samples per wave. Using only voltage wave form for timing reference, and sampling the current wave form with that time reference ie: detect the crossing after one round of sampling, and adjust a)either the sampling period - shorter or longer time - or b) to change the number of samples. Is this correct? In the solar diverter, I can see a pll implemented, and an hpf used. But in the normal version, there doesn’t seem to be a PLL. Could you please throw some light on this?

  2. LPF question was not directly connected. Sorry for the confusion :blush:. But it is connected to rms measurement. To remove the dc offset, 2 methods are discussed. a)the same one used in AVR465 with modification to avoid rounding errors and b)hpf used in the diverter. Can I use the same lpf without modification? (filtered_value = 0.996 × (last_filtered_value + sample - last_sample) )

Thanking you again.

Current waveform, I am expecting arbitrary wave, within the voltage waveform. Voltage waveform, should be with normal crossings, but with varying frequency especially if input is from generarator.

There is no need to synchronise the samples to mains frequency. The average power, or the rms average current, can be measured over any time period with any number of samples. The problem comes when you have an incomplete cycle at the end of the sampling period. With the ‘discrete samples’ sketch, which is the one I think that you are using, the Atmel 328P is capable of about 50 sample pairs (voltage and current) per cycle. If you start the sampling period as close as possible to a zero crossing (of voltage), you will be at most 360/50 = 7.2° beyond the crossing. At that point, the amplitude is about 9% of the rms value. If you do the same at the end of the sampling period, the same applies. Therefore at best, you have zero error because you had exactly a whole number of cycles, and at worst, you have one sample that is at most 9% too big or too small. If you have enough cycles - we aim at 10 (200 ms), then that’s one sample in 500, and the possible error that this one sample introduces is very small. (Had you started and ended the measurement period at the waveform peak, the error would very clearly have been much larger.)

If you try the PLL, you need to be sure that the frequency of your generator remains within the lock range of the loop (or vice versa), otherwise it will fail. The unlocked sampling method cannot have this problem.
Theoretically, the PLL should be more accurate because there is no ‘end effect’ from including a partial cycle in the measurement. In terms of practical engineering in the real world, if you make the error small enough, it doesn’t matter because it will be swamped by other errors that you have no control over.

You can use either filter, but the low pass filter to extract the d.c. bias, followed by a simple subtraction to remove the bias, allows a longer time constant to be used, but more importantly it allows the filter to be pre-loaded at start-up with the nominal offset, removing the need to wait for the filter to settle before the readings are usable. Look at Wikipedia and check your maths - your “lpf” is in fact a high pass filter.

1 Like

Thank you Robert!

  1. " Atmel 328P is capable of about 50 sample pairs (voltage and current) per cycle. If you start the sampling period as close as possible to a zero crossing (of voltage), you will be at most 360/50 = 7.2° beyond the crossing"

Isn’t this correct only if input frequency is fixed? If voltage frequency varies from 45 to 55 Hz, (or may be 60 hz system with variations) then isn’t there a need to either (a) change the sample period ie: time between 2 adjacent samples or b) change the number of samples ie: keep the time same but change the number of samples (may be 49 or 51 etc) dynamically?

Forgive me for asking again, but a little of confusion lingers…:stuck_out_tongue:

I live in a real world, and we’re talking rough numbers here. I’m sure you can do the calculation accurately, for your particular case or cases, now that I’ve shown you what to consider. I live in a 50 Hz ± 1% world; if yours is different (and you’re using a different processor, are you not, that will sample at a different speed anyway) then you must adjust the numbers accordingly.

As I wrote at the beginning, (read it again, then play with the numbers in a spreadsheet?), the number of samples doesn’t matter when you’re calculating an average. All that matters, and this is because of the wavy nature of the voltage, current or power, is that you have as nearly as possible a whole number of complete waves. And if you can’t be assured of that for any number of reasons, then you do what you can to make the error insignificant. Stop thinking about the details and take a step back to look at the overall picture.

1 Like

Thanks Robert. Will adjust the numbers accordingly. I am scanning one cycle, and moving to the next - (instead of longer term averaging) which I think is prone to errors caused by frequency changes. Input frequency changes are generally a concern for us, when input is from a generator. Thank you again!