EmonLib: Number_of_Samples in calcIrms function defaults to 1480 but why?

In the emonlib library we have the function

calcIrms(unsigned int Number_of_Samples)

to calculate the Irms without having a voltage sensor (AC adaptor) so using a fixed value.

The standard value of the argument Number_of_Samples is 1480. What is the rationale behind this?

When you do have a voltage sensor the library will sample for 20 half wavelengths and because it can apparently handle approximately 53 samples you will end up with around 530 samples (calcVI function).

Is the sampling rate increased (because you don't need to calculate the Vrms) exactly by that much that 1480 is 20 half wavelengths? That would mean 148 samples per cycle, but it seems odd that it almost triples, you would expect somewhere along the lines of 53*2 samples/cycle...

And one additional question: how would it effect the accuracy if I reduce the number of samples in calcIrms ? (I would like to meausure 6 current inputs during 1 second, with the default value the 6 calcIrms functions take +/- 1516 milliseconds, I would like to reduce it to 1000)

Robert Wall's picture

Re: EmonLib: Number_of_Samples in calcIrms function defaults to 1480 but why?

It seemed a good idea at the time!

It was based on the speed at which samples were taken and was an attempt to have a whole number of cycles (so that there would be minimal "end effect" of an incomplete cycle that would introduce error) and large enough so that the influence of an incomplete cycle, which will probably happen anyway, would be minimal. However, over time the code has been altered and I don't think anyone has checked to see what the optimum now is. Clearly, the default should be a whole number of cycles at both 50 Hz and 60 Hz. Equally clearly, that won't work if the frequency drifts. In the UK the tolerance limit is ±1%, though normally it is held within much tighter limits.

If you want to take fewer samples, you need to time the sample loop and base your decision on how you want to balance the things I've mentioned.

Of course, it's done as the number of samples because you can't reliably count cycles if only the current wave is available.

[Edit]
Having timed the present version of emonLib, I've got it as running at 162.8 μs per sample, timed over 1000 samples. That equates to 614.25 samples per 100 ms, which is 5 cycles or 6 cycles, depending on your system frequency.

Therefore a good default value would seem to be 1228 samples (10 or 12 complete cycles, taking 200 ms).

humphrey's picture

Re: EmonLib: Number_of_Samples in calcIrms function defaults to 1480 but why?

Thanks for the explanation!

Hmm, testing on my arduino UNO it takes +/-167 μs per sample resulting in +/-600 samples per 100ms.

Maybe we could write a function to determine the sample speed at startup..and calculate the no of samples based on that..

Robert Wall's picture

Re: EmonLib: Number_of_Samples in calcIrms function defaults to 1480 but why?

But that will still be wrong if / when your mains frequency changes!

What you really need is a nice steady voltage wave to count cycles with, and that solves the problem!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.