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.
True.
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.
That is correct.
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.]
1 Like
Thereās a fascinating article at
https://wwwhome.ewi.utwente.nl/~ptdeboer/misc/mains.html
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)
Iāve seen that Dutch data before, but itās not directly applicable to the UK. Although the UK and European systems are linked, power is transferred by direct current. Therefore itās not necessary for the two systems to run synchronously, and indeed they do not.
There is a known problem with timing drift when reporting to emonCMS, but emonCMS was not mentioned in the original question.
Yes I appreciate that.
Agreed, but cycles canāt substitute for time if the frequency can vary, so whatever numbers are obtained from the emonTX canāt have any obviously useful physical meaning if the frequency is not known. Note that Iām not criticising here, just making an observation that when operated outside of its spec/normal operating conditions then the results canāt be relied upon, which I would take as affecting accuracy as the word is usually used in English conversation.
Far from criticising, Iām very impressed that youāre well on the way to extending the system to deal with this new operating environment. 
Can you explain exactly what youāre getting at there? As I understand averages, the average is the total of all measurements divided by the number of measurements. If the measured quantity varies over time, and the interval between samples also varies over time, then I can see that there will be a second-order effect as each individual measurement is slewed somewhat. But in our case the sample rate is constant, and not synchronous with the repetition rate of the signal nor governed by the averaging period. The fact that the averaging period might be a few percent longer or shorter, or double or half, wonāt make a difference. The average is still the average.
What I suspect you might be thinking is the case where the maths of energy accumulation is on a different timebase (e.g., in emonCMS). emonLibCM accumulates energy internally, so even though the accumulated total arrives at irregular intervals, it still represents the true value because the underlying sample rate is constant.
Thank you for your thoughts and assistance here.
To provide some more context as to why the frequency of the supply varies to the extent I described, I live remote from the mains supply and we generate our own electricity using PV panels and store energy in a set of lead acid batteries. The heart of the system is a bidirectional inverter (SMA Sunny Island) which produces 240V nominal 50Hz supplied to the house. The PV output is inverted using fairly standard gird interactive inverters (SMA Sunny Boy) which are configured to reduce their output in response to the grid frequency they are feeding into. This allows the Sunny Island to limit the production of the Sunny Boy when the batteries are full (and not have to dump the additional energy as heat somewhere). The Sunny Boy has a droop response to frequencies above 51Hz, steadily limiting its output as frequency is increased up to 52Hz where the output is reduced to zero. To support the use of devices that use the mains frequency as a timing base, the frequency is lowered to 49Hz as required to correct the effects of the above. (The cumulative effect is usually only the order of a few minutes in winter but can compound out to half an hour during the summer months). My interest in measuring the frequency of the supply is that it is a very good indication of the spare capacity in the PV generation and we have used this in the past to identify opportunities to use discretionary loads such as washing machines and dishwashers without cycling the batteries.
[Edit: To complete the picture for design considerations, I should have also added that the response of the system to a change in load is such that the frequency can vary by 1.5Hz in 3-5 seconds in response to a cycling load such as the thermostat operation in an electric oven. Shorter timeframe load changes such as starting currents for induction motors do not result in frequency changes with these load changes handled by cycling the battery even when it is notionally full.]
This is the area I was thinking could be effected with my frequency variations. The energyNow calculations use datalog_period_in_seconds as the timebase which appears to only be set in configuring the library. As you pointed out above, the datalog period will vary with the actual frequency and so I think the energy calculation will carry this effect through. As per the less obvious solution above, could the actual samples in the specific reporting interval be used to correct for the effect here to?
Yes, thatās what I was looking for - and missed it. At that point, I have now calculated the average mains frequency, so the ratio of the frequencies (actual to nominal) should correct that give real time rather than mains time.
As you can see from the graph I added to the earlier post, we donāt have that much variation - by law itās limited to 0.5 Hz (1%) and they try to keep it inside 0.2 Hz.
I am planning on using emonCMS with local logging on an emonBase although I have not implemented anything yet. I was studying the capability of emonTx which was supplied with the discrete sampling firmware when the post was made that new units were being shipped with continuous sampling firmware. I have not established the scope of what I can achieve with this system yet. The initial scope for this was limited to power and energy measurement for awareness as described above.
My previous foray into this area was an arduino based an inline switching arrangement to control simple discretionary loads (eg water pump or a heat pump) for operation when there was spare generating capacity. SMAās frequency shift power control provided the ability to estimate the spare capacity in the system from the line frequency. emonCMS might be able to be put to use in this context but that is a topic for another thread and I think I need a frequency measurement to enable it.
Me too.
Regarding extending the system to deal with a new operating environment, I have also been looking at the energy accumulation calculation in emonLibCM with the possibility of estimating the battery charge state. The functionality is possibly quite specific to A/C coupled off grid systems using frequency shift power control, so it might be outside the scope of the intended functionality of the emonTx.
Batteries have a round trip efficiency of less than one. If the rate of energy accumulation in emonLibCM was varied based on the direction of flow, there is the possibility of using the energy accumulation calculation to estimate a battery charge state based around energy counting on the A/C side of the bidirectional inverters. My inverters measure the difference between charge in and charge out of the battery and currently report a number of approximately 1.11 units in for every unit out. I think this is on the DC side. There is some self consumption that would also need to be accounted for. Such an estimate would drift over time however the full charge state is reached regularly and can be identified when the inwards flow of power is less than 100W and the line frequency indicates limiting of the generating capacity. This would providing the opportunity to correct the drift each time the batteries are full. (My system takes steps to ensure this happens at least once every 10 days). I have not looked closely at emonCMS yet - maybe there is the possibility to do this state of charge estimation there, however frequency first, battery state of charge estimate maybe later.
Thinking about it, this basic functinaity could also be used to estimate the overall supply charge in a normal grid interactive setup where (at least in Australia) the charge for consumption is different from the payment you recieve for injecting power back into the grid.
While I appreciate your need, that is not something for emonLibCM per se, that must remain as a general-purpose library. And to be fair, the majority of our users donāt run off-grid. You could derive your own code that would do that of course, but I think most people would use the sign of the power to know whether or not to scale the energy to account for charging efficiency, and apply that in the sketch rather than expect the library to do it.
I thought as much. Just thought I would ask.
@Jaddache I think youāll do better to look at emoncms to process the data. Just look at the emonTX as a way to capture the basic data, not quite raw, but not fully-cooked either. If Robert can arrange to deliver the frequency to you as well as the energy readings* you should be able to do all the calculations you want on the emoncms system. Probably just using the built in processing capabilities or you can interface to a system like Node-RED or even a custom-written program if necessary.
*I just thought, presumably as an alternative to reporting the frequency it would be just as useful to report the actual clock time that the 250 (or whatever) cycles took?