I have created this topic for any comments or support queries about EmonLibCM - Version 2.2.1 (Released 30/10/2021) and subsequent revisions.
I was having a look at how the new more efficient phase error adjustment stuff works and got stuck on this line of code in EmonLibCM_Init()
double phase_shift = ((double)phaseCal_CT[i] + (double)ADC_Sequence[i] * ADCDuration * cycles_per_second/MICROSPERSEC) * two_pi / 360.0 ;
It looks like the intent is to take the phase error introduced by the sensors (4.2Ā° say), add in the phase error introduced by the ADC sampling lag, and then convert the lot to radians for the subsequent trig maths.
Are those two terms in the same units? The first one looks to be in degrees while the second appears to be in ācyclesā. Is there a missing āx 360ā on the second term?
Iāll check. It looks as if youāre right (inevitably). Iāll see what I think the best solution is, unless youāve already thought about it?
Yes, Iām afraid thereās a ā360ā missing. It means that there is effectively no compensation for the position in the scan cycle.
double phase_shift = ((double)phaseCal_CT[i] / 360.0 + (double)ADC_Sequence[i] *
ADCDuration * cycles_per_second/MICROSPERSEC) * two_pi;
Now the big question is, how did everybody miss it?
Yes, that had me wondering whether it was compensated for somewhere else.
At 50Hz, a 104 usec lag is 1.872Ā°, so thatās a pretty big phase error for the last one in the scan cycle - 9.36Ā°?
It also got me wondering if the default 4.2Ā° is truly just the sensor error or might have some ADC lag error inadvertently built into to it too? Could it be the sensor error is 2.3Ā°? Was the 4.2Ā° measured independently, or was it arrived at by calibration while assuming the ADC lag compensation was working as intended?
1 Like
Donāt ask me now - all this was done a very long time, about 2 years ago - then left in limbo when I didnāt have an emonPi set up to run long-term tests and I thought Trystan was testing when in fact he wasnāt. I started long-term testing in July, with Bill Thomson testing more or less in parallel on a 60 Hz system.
Iām going to have to go back and recheck all those numbers, but I suspect they came from the tests I did separately on the transformers.
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.