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.
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.
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.
I think the facts have to be faced - I’m thinking about the SCT-013-000 - it is a ‘budget’ device that simply does not have a value of phase error specified. That to me indicates that it’s not a parameter that is controlled in manufacture.
There are two choices. The first is to use a higher specification device, one that does have an adequately tight tolerance on the phase error, and presumably on the amplitude error too. The second is to make calibration and removal of the effect of the phase error easy for the user. When this was essentially a ‘constructors’ website, it could almost be taken for granted that the user would have adequate instrumentation to perform at least some calibration, but I think the balance has tipped away from that concept, and the majority of today’s users expect a product that lives up to their impression of “digital” accuracy.
But if you go for the first option, and only list “revenue” grade or near revenue-grade devices in the list of options, then that approach is entirely feasible. As it is, our ‘standard’ c.t. and v.t. combined come with a manufacturing tolerance of ±6%. It’s not a promising start. That was the thinking behind the discussion about offering a set of calibrated components. I must add that no conclusion was reached.
Hi,
I recently purchased an emontx for use in an off grid power system operating nominally at 240V 50Hz. The system is ‘AC coupled’ and a technique called ‘Frequency Shift Power Control’ (FSPC) is used to control the output of the PV inverters in response to the load on the system and the state of charge of the batteries. As a result the mains frequency is regularly as low as 49Hz (for most of the dark hours during summer) and approaches 52Hz as the batteries are topped up (many hours a day during summer).
The EmonLibCM library appears to use cycles_per_second to calculate the datalogging interval.
Does anyone know what the effects of the regular changes in frequency across the day would be on the datalogging interval or the acuracy of the measurements when using EmonLibCM.
As an aside, I am also interested in accessing the measured frequency of the supply as it is a very good indication of the spare generation capacity in the PV panels when they are being limited. Any help in including average frequency in the measurements available would also be appreciated.
It is fairly obvious: because the interval is a count of cycles, it will lengthen and shorten in inverse proportion to the frequency. If you specify a 5 s reporting interval, that implies 250 cycles. At 49 Hz (that’s outside the permitted UK frequency tolerance for most systems that I’m aware of, which is why it’s not been considered relevant), the interval becomes 250 × 0.020408 = 5.102 s. Or 4.808 s at 52 Hz.
It cannot directly affect accuracy. (Why might it? The average knows the sample count over the reporting interval, which is all that matters.)
You could change the interval timing to clock-based rather than cycle-based, but that would in turn introduce problems with the temperature measurement (that’s triggered on a cycle count in advance of the report so that the reported value is timely) and possibly other things that don’t immediately spring to mind.
I think there are two ways you could extract the mains frequency.
The obvious one: there’s likely to be enough spare processing capacity to time the reporting interval using the crystal clock and the normal millis( ) or micros( ) functions. I can’t say (without looking it up) whether these will be affected when interrupts are turned off - which they are while data is transferred out of the interrupt handler. That would give you the actual duration of your nominal reporting interval from which you could derive the mains frequency.
The slightly less obvious one: the sampling rate is determined by the processor clock, therefore the number of samples per reporting interval - which is used in calculating the averages - could be used as the clock, which should give you an indication of frequency.
[Edit: I’ve got a working version of the “less obvious” solution. At a 1s update rate, it agrees within 0.01 Hz with my multimeter, so I think it’s OK. I can’t release it publicly yet, there is another addition I’m working on, and it needs to be documented.]
[Edit - 2: Here is a graph of mains frequency as recorded by the UK National Grid as a screenshot from their website (blue trace) and, overlaid on it in red, as recorded by emonLibCM with a 1 minute averaging time - the same as NG’s refresh interval.]
Presumably there is an inaccuracy in either reported power or energy levels if the system is actually sampling over a time period that is not what is specified? (I’m sorry, I don’t know enough about the sketch to work out which is inaccurate)
