# calcIrms computing by time, not by number of samples?

Hi, sorry but I can’t answer to this topic: https://openenergymonitor.org/emon/node/11143 (I don’t know why, and also I can’t register in that page)

After reading how emonlib Works, I am trying to understand it

I have seen that calcIV check zero-crossing and evalute correctly the RMS value after detecting several cycles.

Otherwise, calcIrms is calculated by number of samples.

The “problem” here is that the number of samples, as far as I know, works with one type of IC with a known frecuency of 16 MHz.

What about any other IC, or an different or externa ADC, or ATMEGA328P but at 8Mhz ?

I think the value could be calculated with these two options:

First option: calculate every loop how much time take a ADC Reading, and compute how many samples to get 10 or whatever complete cycles you want.
(pseudo code)

``````start=micros();
calculate whatever;
end=micros();

time = end-start;
samples = (1/50Hz*10cycles)/time;
counter=0;
for (counter to samples) {
calculate whatever:
};
``````

Second option and which I like most (the option 1 could be wrong as may be that all the readings doesn’t last the same microseconds)

This options monitorize the time so you will always get 10 complete cycles (or what you like)

(pseudo code)

``````totalTime = 1/50Hz * 10cycles;
counter=0;
begin = micros();
while micros() < (begin + totalTime) {
calculate whatever:
counter++;
};
``````

I think this way calcIrms will be ok for whatever IC or IC’s frecuency or ADC (ADS1115, ACS712, internal ATMEGA ADC, and so on). You always need to check that samples per cycle it is ok for your needs.

Also, with option 2 it won’t be necessary to dectec zero crossing in calcVI, will it ? It won’t be necessary, will it?

I have done a simple Excel with a “perfect sine wave” and evaluate the RMS value by getting samples from zero crossing point and from other point, but always getting complete cycles. The RMS calculated value is always the same.

I am sure that “I haven’t discover the wheel” so I think I am doing mistakes.

Please, tell us what you think and/or check my mistakes.

Regards,

What is required is a integral number of cycles, and an integral number of samples to fit within the number of cycles that you choose. How does time relate to the number of cycles, when the frequency is subject to possible variation of ±1%?

That’s the problem, and emonLib minimises (not removes) the effect of both by (a) for calcVI, attempting to ensure that the start and end of the measuring period falls close to the zero crossing so that the ‘end effect’ is small, or (b) for calcIrms by using a large number of samples so that again the error from reading a part of a cycle is minimised.

Also, remember that the current wave may have more than two zero crossings per cycle.

That of course will always be true. The mathematics doesn’t care where the wave “starts” or “ends”, as long as you have an exact whole number of cycles. Try the same with (say) 51.29 samples per cycle, and you’ll see the problem.

We live in a real world, and unless you have a phase locked loop as MartinR did with his energy diverter, which overcomes this problem by adjusting the clock divider so that both conditions are satisfied simultaneously, then you will always have to make some sort of a compromise. Real-world engineering is all about making the appropriate compromises so that you end up with a result that is ‘good enough’.

1 Like

As usual thanks a lot for your clear and good explanations.

I understand that if you want to avoid that 1% of frecuency error you use calcVI, perfect.
And also, for a very well known hardware, as emonTX is, I think now that the best option is to use in calcIrms a number of samples.

But do you think that, in case of calcIrms only, will be better my second option for getting a function “independen” of hardware ?

I agree you. My problem is that I haven’t explained it well. In real word, we have also different hardware, even bad or good crystal, differents ADCs converters, so for people that only want to use calcIrms with different IC or hardware than emonTX, I think that “time option” is a good one, isn’t it ?

Thanks a lot for your clear answer. I am only thinking in my next little project (standalone atmega85 or atmega328 without crystal, 8Mhz internal oscillator and a ACS712)

Regards,

And that is exactly the reason why the “time option” will not be any better than any other - because your crystal’s idea of time is not the same as the electricity companies’. It will be the best you can have, but it will not be exact, and unless you try to calculate the mains frequency before each reading, it cannot take account of frequency variations. And that begs the question: how do you determine the mains frequency when you don’t have a reliable (meaning voltage) waveform to measure?

Let us do some mathematics for calcIrms just to see what the error is likely to be:

Suppose you have a 50 or 60 Hz supply, and 5000 samples per second. So that you have an exact number of cycles in your measurement period, you want 5 or 6 cycles, or a multiple of that. We chose 10 and 12, taking 200 ms. Therefore, you aim to take 1000 samples. Suppose your crystal is exact but the mains frequency is wrong so that those 10 or 12 cycles actually span 1001 (or 999) samples, and you start and end at the peak value. Your total I2 will be wrong because it will have one sample too few or too many, so it will be wrong by the value of the last sample squared, or (√2 × the rms value)2. But there are 1000 values whose average is the rms value. So the total I2 without the error is 1000 × I2, and with the error is 1002 (or 998) × I2. I think that error in the rms value is not very different from 0.1%.

But that error is the maximum per sample, it will change (not linearly) with the number of samples making up the “end effect” and it’s not a systematic one: its magnitude and sign depend on what is essentially a random factor - where the measurement starts in relation to the mains wave. What you will see in practice will be a fluctuating value as the samples included or excluded by the “end effect” are greater or smaller than the rms value.

1 Like

Even the precision energy IC manufacturers struggle with RMS readings somewhat. The ones I’m most familiar with have a small 2ω ripple passing through their RMS reading. They used to recommend syncing your reading of the RMS register with the zero-crossing detector to always land on the same place in that ripple, but then realised that’s not always practical. These days they recommend taking the mean of lots of consecutive readings of the RMS registers, and I think some of their later ICs actually do that for you on the on-chip DSP.

1 Like

@Robert.Wall and @dBC, as always thanks a lot for your explanations. It is clear now for me. It will be always an error, “we” have to choose the best option for our case.

Regards,