Archived Forum

Hi Chris,

Sorry for the lack of info. These sketches are still in development and are being worked on by Trystan Lea. He is away this week attending some energy monitoring events in Europe. I know he is planning on documenting the continues sampling with Kwh/d on his return. The continous sampling using PLL method which is documented in a series of excellent posts by Robert Wall http://openenergymonitor.org/emon/pvdiversion/pll 

Hi Glyn,

No problem. I assume that I can keep using the "emonTxV3_RFM12B_DiscreteSampling" sketch until the new sketches are completed, and that this will still work with ecmoncms 8?

Thanks for the link- looks really useful, I'll have a read (and thanks Robert).

Chris

I assume you've separated the concepts of continuous monitoring; and sending accumulated energy readings vs sending instantaneous power readings! The two are entirely separate - they just happen to have got tackled at the same time in the same sketches!

I think so...depends what you mean! As I understand it;

The "emonTxV3_RFM12B_DiscreteSampling" sketch sends instantaneous power readings to emoncms, which then uses these to calculate energy usage (kWh per day, week etc).

But there are concerns as to the accuracy of this method , so new sketches are being developed which calculate accumulated energy (Wh) readings, which emoncms can then use to calculate kWh per day etc. Instantaneous power readings will be sent to emoncms as usual for the purpose of knowing the power usage at any time.

So I was checking that the current version of emoncms will still work with the established  "emonTxV3_RFM12B_DiscreteSampling" sketch?

Chris

Yes, it all depends (as we are well aware) on the messages getting through, where the integration to get from power to energy happens, and what approximations are acceptable.

In the discrete sample sketch, which is a development of the initial concept, the power is sampled for a short period every few seconds. The reason for this is battery life, and it remains the best method if battery power is all that is available. But the downside is, whatever the power source, there is an assumption that the sample is representative of the time when the monitor is sleeping. If however you monitor continuously, you can sample power every few hundred microseconds and integrate to give the total energy over whatever period you like, then divide by the period to get back to power - it this time it is an accurate average power and not a sample.

So continuous monitoring (which implies a mains power supply) removes the inaccuracy that is particularly serious if you have a switched load such as the immersion controller.

But you can also carry on accumulating energy and transmit the total accumulated since time zero - exactly replicating how your tariff meter, the meter reader and the energy supplier all interact. This means that should a message not get through, you might lose a peak or a trough that the missing reading would have conveyed, but the total and the long-term average remains accurate. This is in contrast to sending power, where if a reading fails to make it, all you can do is make an assumption about the total and the long-term average.

So, as I started off, it's a case of where and when you do the maths, and what errors you can accept when abnormal things happen. If you send energy totals, you can send instantaneous power as well (because you already know it), or you can differentiate energy to get power. If you send power, you integrate to get energy.

I can't see the likelihood, at least in the immediate future, that emonCMS won't be able to accept power readings.

I posted some 'Mk2' code a few days ago on this thread which routinely transmits a combination of power and energy data. 

The power data is intended for emonCMS where summation of the individual values can take place.  The energy data is intended for use with an emonGLCD or similar display so that accumulated data is available from switch-on.

Both sets of data are obtained by continuously monitoring the flow of energy - no gaps. 

Thanks both. 

I'm going to stick with the discrete option for now, but will try and get to grips with the continuous methods as this does seem the way forward where the node has an external power supply (which all mine do).

Chris