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.)

This article also came up on an Internet search.

https://www.securemeters.com/uk/white_papers/kvah-metering-magic-solution-or-an-aberration/

So what loads in a domestic installation may need power factor correction?

My comment about joules may appear random, but I did a job for a customer who worked for a energy supplier and he explained they actually work in joules rather then kWh.

Canada bills for gas in joules.

www.directenergyregulatedservices.com/.../joules-gigajoules-and-your-energy-bill

This is how my gas bill ends up in kWh, why is it divided by 3.6?

1 W s = 1 J. 1 W h = 3600 J = 3.6 kJ. 1 kWh = 3.6 MJ. So to go from MJ to kWh, divide by 3.6.

So:

gas units used X calorific value X volume correction = mega joules 

mega joules divided by 3.6 = kWh

which is what I was thinking, just checking others thinking the same.

If you look at that Canadian link I posted they work it out from the BTU British Thermal Units of the appliances, Boris and Lord Snooty will have us doing the same soon, that will confuse the kids.

Do then be aware that the north American BTU, based on the American units,  is not the same as our old one, but differs by a % or so. The therm is also not the same.

It is indeed set out to catch the unwary. There is  a lot to be said for joules.

Mike

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

I'd been mulling over the best way to handle it with limited digital processing power - one thought was to go back to the old Analogue Computing techniques and get some linear electronics (mostly op-amps) to do the hard work of calculating the instantaneous I * V and integrate it over time -  leaving the digital side to just do a leisurely A-to-D on the resulting power quantity. Not without it's challenges, not least that the power scale is a lot wider than current or voltage individually, so likely a lot more precision needed (especially in the A-to-D itself), but might be worth a mull over still.

   - Andy.

Probably worth taking this onto a thread on its own - I too have messed a little with this sort of thing, though that was over a decade ago, I was monitoring I and V on a 3 phase genset (and the levels in a sewage tank...) with a modest PIC, and generating Ethernet traffic  a few bytes at a time, and not having enough memory.

As an example of the memory constrained thinking, I do recall a problem that IP packets have the checksum at the front, and the way I created and sent the data almost live, I did not have enough buffer to store the whole packet and post calculate that.  I do recall the 'aha' moment of realizing I could send any known checksum, and then the live data, just keeping a counter running and at the end append a dummy word of the right value to make the error checking work so the checksums  of all the packets the unit ever sent were identical...

I suspect that the analogue way will reveal more, and you will end up compensating for the non idealities of the current transformer. From memory the voltage waveforms are quite well behaved in comparison to the currents even on a genset.

Mike.