At best an only slightly relevant datapoint since I was using an Aussie/Jaycar VT on the stm32 experiments, but I found there I needed 269 usecs (~4.8°) to compensate for the net VT/CT induced phase error at 50Hz. I knew that was all down to the sensors because I had synchronised dual ADCs, one for V and one for I.
Recent samples of the c.t. go from about 2.5° to about 4.5° depending on the current, and the UK v.t. from around 3° to around 4.5° depending on the voltage. So it’s not easy to find a value that is a good compromise. In my testing against the supplier’s meter optical pulses, I found I could set the calibration so that the accumulated kWh see-sawed against the pulse count, (I forget which way round it was now) one would lead at low powers and lag at high powers - I couldn’t isolate the cause, I suspect it was this, but it could have been the c.t’s amplitude error as well (I’m talking about a standing load of a 100 - 200 W compared to 1 - 2 kW).
Yes, that see-saw effect is one reason I remain unconvinced by metrics like “long term agreement with revenue meter to within 1%” especially for per-breaker monitors. That all the individual channels add up to within 1% of the revenue meter over a month doesn’t really put any upper limit on the errors in individual instantaneous power readings from each channel, and surely the whole reason for per-breaker monitoring is so you can determine how much energy circuit x uses.
And in three phase installations, per circuit monitoring with “derived voltage references” (i.e. only one VT) is particularly vulnerable. In that situation I think the “long term agreement with revenue meter to within 1%”, while no doubt true, is close to meaningless for anything but the grand totals. But if that’s the only measurement you can rely on, you could have saved yourself a lot of CTs and just measured the main feed.
Quite so. But you’re up against accuracy vs perceived accuracy. And as most users don’t have access to high quality test gear, comparison with the supplier’s meter is their only yardstick. Then, if your total consumption is to 1%, then that implies that while minor loads might be significantly worse, at least you know to within probably 10%, maybe 5%, what those loads actually are - and until some sort of monitoring is present, that’s been a total unknown. I’m not pretending it’s good, but if the user is happy with it and it’s better than nothing, then it’s OK for their purpose.
I’ve been asking for a 3-phase emonTx (i.e. 3 v.t’s) for a long time, but despite the continuing interest - notably from mainland Europe as well as your part of the world, there’s been no reaction. Hopefully, the STM will put that to rights; we shall see.
Yes, fair comments. I think in some quarters there’s a tendency to just mention the 1% total without any qualification, so the end user is perhaps thinking they’re getting that on each of their channels.
With “derived” 3 phase monitoring, I think even the larger loads can be significantly out. Most loads here are single phase regardless of whether the house is single phase or three phase, and in a three phase house it’s common for the sparkie to distribute the larger loads across different phases. Add to that the observation that it’s common to see 10% variation in phase voltages and it becomes a big fuzzy soup of measurements. Tweak enough knobs often enough and you might happen across a combo that results in a < 1% error in the grand total, but I’d have little confidence in the per-circuit measurements (large or small).
It also varies a lot from distribution transformer to distribution transformer, so one intall’s ability to achieve 1% on the total is no indication that another one in a different location will, or even that the original one will continue to when some change is made in a neighbouring property (like installing PV).
Energex recently installed monitoring on the LV side of my local distro transformer (which I think services about 20-30 houses). They monitor both voltage and current on each phase. They’re due to sweep through and replace all the ageing 80A service fuses on top of the telegraph poles and I heard while they’re at it, they’ll potentially moves houses onto different phases to keep things better balanced based on their acquired data … they know which houses have PV, how big their inverters are and which phase they’re currently on.
I tested both my IDEAL 9V AC-AC transformer (US) and four SCT-013-000 current transformers for phase offsets. This is on the US side, so typical is ~120 Vac on a given standard outlet.
My single IDEAL transformer had an AC offset of 3.41 deg.
The four CTs had additional offsets of +0.54 deg, +0.67 deg, +1.01 deg, and -4.65 deg. Yes, that last one was a bit of an odd-ball.
The ADC lag between V and I can be important, but of course depends on the details. I compensate for it within my own continuous monitoring firmware with real phasor rotations. (Emontx3-continuous - New continuous monitoring firmware)
[edited 2018-12-06 to put correct AC-AC transformer phase offset]
That’s to be expected - the 120 Ω burden gives rise to a huge phase error because it’s heading towards being overloaded. All c.t’s are more accurate the closer their burden is to a short circuit - but measuring the burden voltage becomes harder.
True, thanks… but I forgot to mention that I replaced the 120 Ω surface mount resistor with a 22 Ω through-hole resistor. The fourth CT had the same lag behavior no matter which input channel was used.
In that case, it’s probably from a different batch. Measuring c.t’s independently of the emonTX, I’ve observed a significant variation in phase error over the years. It’s obviously a parameter that’s not kept under strict control in the way that it is in the more costly ‘revenue grade’ devices.
I’ve found another error in that part of the code, so I’ll be providing an update when I’m satisfied with the correction.
7 posts were split to a new topic: Derived voltage reference (three-phase) and utility meter accuracy comparison
Well Glyn, if you’re going to move my comments, how about the above comments that prompted them? I think it’s pretty clear now that this isn’t about the CM.
Apologies to anyone with a comment or question about emonLibCM. Until this thread can be re-opened, please PM me if you need my prompt attention.
Your comments were moved since they did not relate directly to emonLib CM.
This thread is now open again. Pleae keep all discussions on the public forum and this thread is for discussion of EmonLibCM.
That doesn’t bode well for simply using a drop-down menu to specify the CT model in order to “calibrate” the relevant phase error. I wonder if CT model + batch number would work, assuming we could collect the necessary data.