You must know what the scaling should be for each of the inputs, for the c.t., it will be kWh to within a few percent, for the pulses it could be anything but the energy that a pulse represents will be on the front of your meter (probably as the reciprocal: pulses per kWh). You should have incorporated that when you scaled the input processes. For many meters, it’s 1000 pulses per kWh, so 1 pulse represents 1 Wh. If you didn’t divide by 1000 somewhere, you need to set the pulse side of the graph to (say) bottom = 2400 & top = 3600 while the c.t side is 2.4 to 3.6 respectively. If you started pulse counting when the c.t. side had reached 520 Wh, you’d need to offset both top and bottom of the pulses scale by 520.
My emonPi that’s got some examples on is disassembled at present, so I can’t provide an illustration.
The graphs never seem to match in normal use - that’s because the timing can be slightly different as Brian explained (also, the c.t. responds to a change up to a few seconds before the pulse count can) and because of the automatic scaling - and that’s what you override when setting the limits of the axes.
Thanks Robert - in the process list for pulse, I setup for Pulsecount 1600 imp/kWh which was on the front of the meter. Brain pointed out an extra 0 I had in my kWh calculation, which I adjusted. In the applcations to show the feed from CT and PULSE, I cant work out why the PULSE APP (for Wh) has essentially 2 extra digits on the pulse Wh count (LEFT ONE)… They seem to be off quite a bit and trying to understand if I have my processes for the input setup correct
This is one problem with pulse counts: they are historical. If the pulse rate is too slow, i.e. there is not at least one pulse for every set of data, you cannot reliably infer power from the pulse rate (because it’s either 1 pulse’s worth of energy every 10 s or none). You really need to use the c.t. data, i.e. power, not energy, when you don’t have a guaranteed reasonable number of pulses per reporting interval - “reasonable” meaning that the difference when a pulse falls into the next reporting period because of the “beat” effect or a processing delay isn’t too significant.
I didn’t have an emonPi running 6 days ago, here now is an illustration of the problem with pulses:
Is the Power2 value 0, 360 or 400 W (according to the pulse count) or 145 and 45 W according to the c.t’s? If I zoom in on 11 pulses in the 50 W section, it shows a mean of 53 W and Std. Dev. of 128. You are seeing one pulse every 2nd or 3rd, or every 6th or 7th, reporting interval.
(I’m using kWh to Power on the pulse count out of emonLibCM to obtain pulsecountPower2. 1 pulse = 1 Wh. And I count 45 W as being OK for 53 W - if that indeed is accurate - because the inputs aren’t calibrated.)
Yes Im afraid this app is only designed to support the combination of a power feed and a cumulative kWh feed and the kWh to power process doesnt really work when the pulses are less frequent than the feed interval as @Robert.Wall discusses.
Accurate conversion of pulses to power values requires precise timing on the pulse counting hardware itself to measure the time between pulses which is not something we currently have implemented in our firmware Im afraid.
There’s no easy solution - partly because the “system” was designed as it is because of the split between the emonTx or the emonPi Shield where the pulses are received and a report is generated every 10 s; and emonHub/emonCMS that receives that report, records and interprets the data.
Taking my 53 W load above, what value should be sent to emonCMS for logging at each of the 5 or so 10 s ticks (or records in the PHPFina database) between pulses? There are probably as many answers as people who want a solution. I can think of two contenders: the average between the last two pulses - but what happens when I turn the load off and there isn’t another pulse - when do you know there won’t be another pulse; or wait until the next pulse and then back-fill the database with either the average, or some other mathematical function that assures that the requirement for the integral over time to equate to the pulse count is met - and then what function is “correct”?
We must not lose sight of the fact that the registers on an energy meter - or the pulses - are designed as and are primarily a billing mechanism. If you want power, the way to do it is to measure instantaneous power and average it over a small and (ideally) fixed interval, if you want energy you integrate that power over time. Starting with fixed quanta of energy and variable time, then trying to get back to power, just makes life hard.
If you can come up with better kWh to Power process, let’s discuss it and see if it can be implemented.
