I’d like to point out that the we referenced above does not include me. I was censored. I had posted a rebuttal to the suggestion that frequent random sampling was inaccurate and pointed out that it was lacking practical evidence. At first they changed the subject to this oversampling argument, then removed my post completely.
Regarding the oversampling argument. I get that there is no significant energy in the harmonics and that capturing them does little to the prima fascie power measurement. The reason for high sample rates in IoTaWatt has nothing to do with that.
After following this forum for some time, I came to understand that the bulk of the discussion at the time (2017) was about how to connect different CTs and VTs and how to calibrate for better results. The solutions almost always required the user to recompile the firmware and upload it to the Arduino. I thought there could be a better way and that a plug-and-play solution was due. As a programmer rather than an electronics guy, I could see the forest.
One major design goal was to be able to use any VT and any combination of CTs in the 14 inputs without the need to reprogram. This required a different approach to phase correction. The buzz at the time was a paper that described a method that I think may still be in use in some of the Emon devices. I’m not finding fault with the method as used, but it doesn’t really lend itself to the any-to-any approach. That paper starts out by explaining that the method described is needed if resolution of the samples is not fine enough to correct phase errors by simple sample shifting.
So, IoTaWatt’s per-cycle sample rate at 50Hz is about 760 sample pairs per cycle. That translates to .47° per sample. If the net phase shift between the VT and CT is known, the voltage and current sample arrays can be shifted to align within an average of about .24°. IoTaWatt goes a step further and does a linear interpolation for the fraction, but I’ll concede that may be overkill.
Contrast that with a device that is taking maybe 50 samples per cycle or 7.2°. To correct a typical 1° or 2° net, some form of interpolation must be used. I recall a discussion where a seemingly knowledgeable contributor found fault with the linear method being used. I think it was purely academic and didn’t go anywhere.
I understand that the STM project is looking at using time-delays to accomplish the correction. That may be the holy grail but the devil is in the details when there is so much going on and the CT shift is changing with load.
I’ll reiterate that I think the argument for sampling every cycle vs two per second is overkill. Even when the individual cycles vary, and that is rare, random sampling will capture the average within less than 1%. There is a tendency to worship these technologies as if they make or break the effort when there are so many other important criteria like cost, ease of use, reliability, upgradeability, and complexity.