Smart meters

But even though that is true, some digital power meters that are the basis of the new smart meters are not as good at correcting for power factor due to funny wave-forms, compared to the traditional poor power factor where both the current and voltages are nice sinewaves, just offset in time.

Funnily enough I've been looking into something that could be related to this. It's not the smart meter that's questionable this time, but an energy monitor (an 'open source' system - https://openenergymonitor.org/ - I just got the Arduino shield and put it together with a spare Uno and Pi). What I've noticed is that while the emon and smart meter display pretty much agree when large (resistive) loads are in use, (oven, kettle etc), and agree with nothing on at all, when there's just my baseload (200W-ish) - I guess mostly things with electronic PSUs - the emon overestimates by comparison with the smart meter display by a large percentage - maybe 70% (showing say 440W instead of 270W). As a result the total energy usage per day is typically way out. The emon does try to take power factor into account (otherwise the power readings would be even higher!) but it seem to me that there's still something not quite right.  I'm still perusing the source code for the firmware, but it's looking so far that it estimates the PF on the basis of the time difference between I and V zero-crossing - which I suspect is similarly based on an assumption of sinusoidal currents - whereas I'm guessing at lot of the cheap SMPSUs are likely to be concentrating their loads near the peaks.

   - Andy.

Do you have a scope ? It may be interesting to look at the CT waveforms, and for that matter the voltage of the 9V AC used as a voltage probe -  neither will accurately handle audio frequencies, though there could well be more wrong in the firmware as well. I have not checked but do the burden resistor and RC poles give the same HF roll-off for the CT as for the voltage probe?

As an aside, zero crossings are not normally what we look for in the comms world, but the points of inflection, i,e, where things reverse, as there are two many things that give a DC offset in the receive chain.

  Sadly both methods scan be easily fooled by different sorts of waveform distortion. If you have the processing grunt then a complex FFt is the ultimate way out, but it is not so easy in limited processing power, or perhaps the creation of the product waveform.

Mike.

(another useful quantity to consider /calculate on extracted waveforms, for however may samples you have is an RMS error vector magnitude - once you think you know the sine wave amplitude, how far off from the ideal sine are the other points that were sampled - a sort of measure of distortion.)

Do you have a scope ? It may be interesting to look at the CT waveforms, and for that matter the voltage of the 9V AC used as a voltage probe -  neither will accurately handle audio frequencies, though there could well be more wrong in the firmware as well. I have not checked but do the burden resistor and RC poles give the same HF roll-off for the CT as for the voltage probe?

As an aside, zero crossings are not normally what we look for in the comms world, but the points of inflection, i,e, where things reverse, as there are two many things that give a DC offset in the receive chain.

  Sadly both methods scan be easily fooled by different sorts of waveform distortion. If you have the processing grunt then a complex FFt is the ultimate way out, but it is not so easy in limited processing power, or perhaps the creation of the product waveform.

Mike.

(another useful quantity to consider /calculate on extracted waveforms, for however may samples you have is an RMS error vector magnitude - once you think you know the sine wave amplitude, how far off from the ideal sine are the other points that were sampled - a sort of measure of distortion.)